From owner-mpls@UU.NET Thu Feb 1 01:13:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08090 for ; Thu, 1 Feb 2001 01:13: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 QQkalk07661; Thu, 1 Feb 2001 06:12:48 GMT Received: by mail-control.mail.uu.net id QQkalk01575 for mpls-outgoing; Thu, 1 Feb 2001 06:12: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 QQkalk01568 for ; Thu, 1 Feb 2001 06:12: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 QQkalk09376 for ; Thu, 1 Feb 2001 06:11:54 GMT Received: from wiproecmx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiproecmx2.wipro.com [164.164.31.6]) id QQkalk26703 for ; Thu, 1 Feb 2001 06:11:51 GMT Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id LAA04326 for ; Thu, 1 Feb 2001 11:51:25 GMT Received: from ecvwall1.wipro.com ([192.168.181.23]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA67B7 for ; Thu, 1 Feb 2001 11:41:22 +0530 Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA4E13 for ; Thu, 1 Feb 2001 11:38:22 +0530 Message-ID: <3A78FED2.A31E30D6@wipro.com> Date: Thu, 01 Feb 2001 11:44:42 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: LDP Specification draft - Loop detection. References: <200101311407.JAA16628@rhthomas-sun2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi bob, [1] In that case why Label Release Message in 3.5.11 does not contain Status TLV as optional parater. For that matter, accroding to 3.4.6 last para every message should have Status TLV as optional. shouldn't this be updated in the rfc. [2] In section 3.5.11 Label Release Message and 3.5.10 Label withdraw message - Label TLV (optional) field is present as well as in the optional parameters list Label TLV is present. Is this wrong or does it have any implicit meaning..... ???? Thanks in advance Amar Bob Thomas wrote: > Amar, > > Please review Section 3.4.6, especially the last paragraph, and > Section 3.4.5, especially 3.4.5.1.2. > > Thanks, > Bob > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > A.1.11. Receive Notification / Loop Detected > > > > Summary: > > > > When an LSR receives a Loop Detected Status Code from an LDP peer > > in response to a Label Request message or a Label Mapping message, > > > > it behaves as if it had received a No Route notification. > > > > Context: > > > > See "Receive Notification / No Route". > > > > Algorithm: > > > > See "Receive Notification / No Route" > > > > Notes: > > > > 1. When the Loop Detected notification is in response to a Label > > Request message, it arrives in a Status Code TLV in a > > Notification message. When it is in response to a Label > > Mapping message, it arrives in a Status Code TLV in a Label > > Release message. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > [1] In the above section, Notes 1., It is told that When it is in > > response to a Label mapping message, it arrives in Status Code TLV of > > Label Release message, But Label Release message does not have Status > > Code TLV -not even as optional parameter ????? > > > > Regards > > Amar > > From owner-mpls@UU.NET Thu Feb 1 13:42:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06682 for ; Thu, 1 Feb 2001 13: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 QQkani17903; Thu, 1 Feb 2001 18:40:23 GMT Received: by mail-control.mail.uu.net id QQkani06432 for mpls-outgoing; Thu, 1 Feb 2001 18:40:06 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 QQkani06415 for ; Thu, 1 Feb 2001 18:40:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkani08581 for ; Thu, 1 Feb 2001 18:38:24 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkani13911 for ; Thu, 1 Feb 2001 18:38:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA07573 for mpls@uu.net; Thu, 1 Feb 2001 13:38:22 -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 QQkani06179 for ; Thu, 1 Feb 2001 18:37:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkani00870 for ; Thu, 1 Feb 2001 18:35:43 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 QQkani28416 for ; Thu, 1 Feb 2001 18:35:43 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA20871; Thu, 1 Feb 2001 10:35:30 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14969.44142.345000.601771@gargle.gargle.HOWL> Date: Thu, 1 Feb 2001 10:35:26 -0800 To: mpls@UU.NET Cc: tli@procket.com, dkatz@juniper.net, swallow@cisco.com Subject: Handling multiple IP addresses on PPP interfaces with RSVP-TE X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am kind of curiuos about what people are doing to handle multiple IP addresses on PPP interfaces when they are establishing LSPs with RSVP-TE? Also, how are these multiple IP addresses per physical link advertised in ISIS-TE or OSPF-TE? I see not that much value in assigning multiple IP addresses (paired) on PPP interfaces, but the fact that you can means that both the IGPs and MPLS signaling must support it. Thanks Bora From owner-mpls@UU.NET Thu Feb 1 16:48:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12238 for ; Thu, 1 Feb 2001 16:48:57 -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 QQkanv15645; Thu, 1 Feb 2001 21:46:32 GMT Received: by mail-control.mail.uu.net id QQkanv00452 for mpls-outgoing; Thu, 1 Feb 2001 21:45: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 QQkanv00447 for ; Thu, 1 Feb 2001 21:45: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 QQkanv19367 for ; Thu, 1 Feb 2001 21:45:22 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe48.law10.hotmail.com [64.4.14.20]) id QQkanv18712 for ; Thu, 1 Feb 2001 21:45:21 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Feb 2001 13:45:21 -0800 X-Originating-IP: [12.124.181.202] From: "Frank Hujber" To: "MPLS Group" Subject: Bandwidth Encoding Date: Thu, 1 Feb 2001 16:49:07 -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: 01 Feb 2001 21:45:21.0110 (UTC) FILETIME=[4670F760:01C08C98] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I note in "Generalized MPLS Signaling - RSVP-TE Extensions" that the bandwidth encoding does not include a clear channel option. That it, if a provider is simply offering a service that is rate independent, he still must specify a discrete bit rate. Has there been a value identified for this field that specifies a clear-channel offering? Frank Hujber fhujber@hotmail.com From owner-mpls@UU.NET Thu Feb 1 17:10:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12787 for ; Thu, 1 Feb 2001 17:10: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 QQkanw27111; Thu, 1 Feb 2001 22:08:33 GMT Received: by mail-control.mail.uu.net id QQkanw14855 for mpls-outgoing; Thu, 1 Feb 2001 22:07: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 QQkanw14831 for ; Thu, 1 Feb 2001 22:07:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkanw17427 for ; Thu, 1 Feb 2001 22:06:56 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkanw28732 for ; Thu, 1 Feb 2001 22:06:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA25349 for mpls@uu.net; Thu, 1 Feb 2001 17:06:41 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkanw14642 for ; Thu, 1 Feb 2001 22:06:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkanw16479 for ; Thu, 1 Feb 2001 22:05:22 GMT Received: from netmail2.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkanw21145 for ; Thu, 1 Feb 2001 22:05:22 GMT Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA02440 for ; Thu, 1 Feb 2001 16:05:40 -0600 (CST) Received: from postal.adn.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id QAA09369 for ; Thu, 1 Feb 2001 16:05:18 -0600 (CST) Received: from adn.alcatel.com ([198.205.41.68]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA2464 for ; Thu, 1 Feb 2001 17:16:56 -0500 Message-ID: <3A79DC38.3ECC7A99@adn.alcatel.com> Date: Thu, 01 Feb 2001 16:59:20 -0500 From: "Rao Vadlamani" Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: RE: LMP MIB Content-Type: multipart/mixed; boundary="------------E1C38FA53C6CEEAEF083E6F8" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------E1C38FA53C6CEEAEF083E6F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >That would be the TE-MIB not the MPLS-TE-MIB; there is >a difference. The latter is in WG last call, so the addition >of new stuff like link bundling is not an option at this point. >I have heard that the TE-MIB was requested to go into last call >shortly as well. Therefore, I would recommend doing link bundling >in a separate document which can augment the MPLS-TE-MIB's interface >table and can be tracked separately as the work progresses. > --Tom I have a question.What is the difference between the TE-MIB and MPLS-TE-MIB ? Are they serving two different purposes ? I am sorry if this question is already asked and addressed in the list. Thanks Rao --------------E1C38FA53C6CEEAEF083E6F8 Content-Type: text/x-vcard; charset=us-ascii; name="Rao.Vadlamani.vcf" Content-Description: Card for Rao Vadlamani Content-Disposition: attachment; filename="Rao.Vadlamani.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vadlamani;Rao tel;cell:(703)-282-7399 tel;fax:(703)-679-6450 tel;home:(703)-390-1174 tel;work:(703)-679-6430 x-mozilla-html:FALSE url:www.alcatel.com org:Alcatel USA version:2.1 email;internet:rao.vadlamani@adn.alcatel.com adr;quoted-printable:;;15036 Conference Center Drive=0D=0A=0D=0A=0D=0A;Chantilly;VA;20151;USA fn:Rao Vadlamani end:vcard --------------E1C38FA53C6CEEAEF083E6F8-- From owner-mpls@UU.NET Fri Feb 2 01:55:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27293 for ; Fri, 2 Feb 2001 01:55: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 QQkapf10013; Fri, 2 Feb 2001 06:54:31 GMT Received: by mail-control.mail.uu.net id QQkapf05507 for mpls-outgoing; Fri, 2 Feb 2001 06:54:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkapf05502 for ; Fri, 2 Feb 2001 06:54:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkapf14992 for ; Fri, 2 Feb 2001 06:52:47 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 QQkapf23588 for ; Fri, 2 Feb 2001 06:52:45 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 MAA13277 for ; Fri, 2 Feb 2001 12:18:25 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id MAA09267 for ; Fri, 2 Feb 2001 12:22:43 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Fri, 2 Feb 2001 12:22:43 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: test Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk test _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Fri, 2 Feb 2001 02:19: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 QQkaph03483; Fri, 2 Feb 2001 07:18:55 GMT Received: by mail-control.mail.uu.net id QQkaph20254 for mpls-outgoing; Fri, 2 Feb 2001 07:18:30 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 QQkaph20249 for ; Fri, 2 Feb 2001 07:18:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkaph20466 for ; Fri, 2 Feb 2001 07:16:18 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 QQkaph09530 for ; Fri, 2 Feb 2001 07:16:17 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 XAA26233; Thu, 1 Feb 2001 23:16:17 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id XAA05444; Thu, 1 Feb 2001 23:14:07 -0800 (PST) Date: Thu, 1 Feb 2001 23:14:07 -0800 (PST) From: Kireeti Kompella Message-Id: <200102020714.XAA05444@kummer.juniper.net> To: hshah@tenornetworks.com, kireeti@juniper.net Subject: Re: question on kompell draft for L2VPN Cc: mpls@UU.NET In-Reply-To: <6B190B34070BD411ACA000B0D0214E563A81B0@newman.tenornet.com> Sender: owner-mpls@UU.NET Precedence: bulk > I was wondering if there was any particular reason why 2-byte Q922 header > is stripped from data packet at ingress PE when encap is frame relay. A new DLCI gets put on at the far end, so why keep the old one? > I would think it might be beneficial to preserve the header > (for FECN/BECN, DE info) than not. Keep 16 bits because 4 may be useful? There was a proposal to encode these bits in the inner label, using a combination of the EXP bits, and the label itself. This was vetoed in favor of carrying these bits in the (optional) control word. One may argue, why 32 bits when 16 would do? Since the control word is optional, if < 50% of the users of Frame Relay over MPLS want these bits, this approach comes out ahead. Since 0% of the (admittedly small) sample of folks I know who use FR/MPLS need these bits, the universe is ahead (so far). Rest assured however that there will be protocol mechanisms to preserve these bits. Note too that ATM AAL5 encap throws away the cell headers -- this is entirely identical. There are useful bits in the cell header besides the VPI/VCI. > If there is any overwhelming reason to strip the header, how about adding > another encapsulation type of "frame relay with q922-header"? What is the overwhelming reason to carry the dlci? Kireeti. From owner-mpls@UU.NET Fri Feb 2 09:50:23 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10812 for ; Fri, 2 Feb 2001 09:50: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 QQkaql10215; Fri, 2 Feb 2001 14:47:44 GMT Received: by mail-control.mail.uu.net id QQkaql21251 for mpls-outgoing; Fri, 2 Feb 2001 14:47: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 QQkaql21240 for ; Fri, 2 Feb 2001 14:47: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 QQkaql06593 for ; Fri, 2 Feb 2001 14:46:45 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 QQkaql08287 for ; Fri, 2 Feb 2001 14:46: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 GAA10504 for ; Fri, 2 Feb 2001 06:46:58 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA07957 for mpls@uu.net; Fri, 2 Feb 2001 09:46:42 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkaoi28375 for ; Fri, 2 Feb 2001 01:00:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkaoi14000 for ; Fri, 2 Feb 2001 01:00:26 GMT Received: from exchange-west.photuris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.3.135.228]) id QQkaoi15163 for ; Fri, 2 Feb 2001 01:00:26 GMT Received: by EXCHANGE-WEST with Internet Mail Service (5.5.2650.21) id <1AAYBHT3>; Thu, 1 Feb 2001 16:49:35 -0800 Message-ID: <2350AC684549D41193CA00D0B773E84F1F2FF0@EXCHANGE-WEST> From: Samir Sanghani To: "'mpls@uu.net'" Cc: Samir Sanghani Subject: VRRP in MPLs world? Date: Thu, 1 Feb 2001 16:49:33 -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: VRRP protocol was developed to provide redundancy; primarily for IP routers over a multi-access link. In MPLS world, do LSRs implement VRRP? How do they achieve redundancy? - analogous to a conventional IP router? Can someone please comment? regards, Samir Sanghani From owner-mpls@UU.NET Fri Feb 2 11:45:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14908 for ; Fri, 2 Feb 2001 11: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 QQkaqs04106; Fri, 2 Feb 2001 16:43:17 GMT Received: by mail-control.mail.uu.net id QQkaqs01305 for mpls-outgoing; Fri, 2 Feb 2001 16:42:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqs01300 for ; Fri, 2 Feb 2001 16:42:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkaqs28520 for ; Fri, 2 Feb 2001 16:42:17 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQkaqs02539 for ; Fri, 2 Feb 2001 16:42:17 GMT Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 2 Feb 2001 11:39:31 -0500 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 1D19WN0N; Fri, 2 Feb 2001 11:39:16 -0500 Received: from americasm01.nt.com (philipma-1.ca.nortel.com [47.129.70.233]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y9V1VT9Y; Fri, 2 Feb 2001 11:39:12 -0500 Message-ID: <3A7AE2F0.B84C24F1@americasm01.nt.com> Date: Fri, 02 Feb 2001 11:40:16 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: Bob Thomas Subject: Loop detection in DU-Liberal mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Two questions: 1) Am I correct in saying that Loop Detection doesn't make sense in DU Liberal mode? (Here I am assuming Ethernet or POS interfaces only; no ATM or FR). As I understand it, in DU Liberal mode, a node should expect to receive label mappings for a given FEC on all its interfaces. The node then uses its routing table to decide which one of these labels it will actually use at any given time. Ignoring transient conditions, the IGP should ensure that no routing loops and thus there are no LDP-LSP loops. 2) Given that node does _not_ support the Loop Detection procedure in DU Liberal mode, what should a node do when it receives a Label Mapping message with a Hop Count or Path Vector TLV? In this case, is the support of these TLVs optional, or must a node support these TLVs even though it does not support Loop Detection? - Philip From owner-mpls@UU.NET Fri Feb 2 12:03:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16098 for ; Fri, 2 Feb 2001 12:03: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 QQkaqu00292; Fri, 2 Feb 2001 17:01:24 GMT Received: by mail-control.mail.uu.net id QQkaqu05951 for mpls-outgoing; Fri, 2 Feb 2001 17:00:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqu05899 for ; Fri, 2 Feb 2001 17:00:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkaqt06732 for ; Fri, 2 Feb 2001 16:59:40 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 QQkaqt27500 for ; Fri, 2 Feb 2001 16:59:40 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 IAA20926; Fri, 2 Feb 2001 08:59:09 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id IAA07122; Fri, 2 Feb 2001 08:56:57 -0800 (PST) Date: Fri, 2 Feb 2001 08:56:57 -0800 (PST) From: Kireeti Kompella Message-Id: <200102021656.IAA07122@kummer.juniper.net> To: akyol@pluris.com, mpls@UU.NET Subject: Re: Handling multiple IP addresses on PPP interfaces with RSVP-TE Cc: dkatz@juniper.net, swallow@cisco.com, tli@procket.com In-Reply-To: <14969.44142.345000.601771@gargle.gargle.HOWL> Sender: owner-mpls@UU.NET Precedence: bulk Hi Bora, > I am kind of curiuos about what people are doing to handle > multiple IP addresses on PPP interfaces when they are > establishing LSPs with RSVP-TE? As I see it, the ERO will have *one* of the multiple addresses on the link. However, RSVP must do admission control and bandwidth accounting per *link*, not per *address*. Is that what you meant? > Also, how are these multiple IP addresses per physical link > advertised in ISIS-TE or OSPF-TE? IS-IS already specifies this: 5.2 Sub-TLV 6: IPv4 interface address This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times. ... 5.3 Sub-TLV 8: IPv4 neighbor address This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times. It behooves OSPF to say a few words on this subject, if for no other reason than to keep up in the ISIS-OSPF arms race. > I see not that much value in assigning multiple IP addresses > (paired) on PPP interfaces, but the fact that you can means that > both the IGPs and MPLS signaling must support it. I don't see what changes are needed in signalling to handle this. Kireeti. From owner-mpls@UU.NET Fri Feb 2 12:17:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16558 for ; Fri, 2 Feb 2001 12:17: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 QQkaqu10688; Fri, 2 Feb 2001 17:08:24 GMT Received: by mail-control.mail.uu.net id QQkaqu16289 for mpls-outgoing; Fri, 2 Feb 2001 17:07:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqu16284 for ; Fri, 2 Feb 2001 17:07:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkaqu23971 for ; Fri, 2 Feb 2001 17:07:35 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 QQkaqu09413 for ; Fri, 2 Feb 2001 17:07: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 JAA11543 for ; Fri, 2 Feb 2001 09:07:45 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA08360 for mpls@uu.net; Fri, 2 Feb 2001 12:07:33 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkaqt02452 for ; Fri, 2 Feb 2001 16:57:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkaqt19102 for ; Fri, 2 Feb 2001 16:57:23 GMT Received: from motgate2.mot.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate2.mot.com [136.182.1.10]) id QQkaqt12101 for ; Fri, 2 Feb 2001 16:57:22 GMT Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA21379 for ; Fri, 2 Feb 2001 09:57:21 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA28797 for ; Fri, 2 Feb 2001 09:53:20 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 2 Feb 2001 10:57:20 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D94D@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'mpls'" Subject: Multicast and MPLS Date: Fri, 2 Feb 2001 10:56:57 -0600 X-MS-TNEF-Correlator: <01FAF65DEA16D4119B95009027E78F3149D94D@il02exm26.comm.mot.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C08D39.271F0310" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C08D39.271F0310 Content-Type: text/plain; charset="iso-8859-1" All, I have been doing some research on the status of multicast with MPLS. I've been following the last call comments for the multicast framework document and I remember seeing some related email that made a mention of some existing multicast implementations of MPLS. I was wondering if anyone knew what vendors are supporting multicast using MPLS. I have done extensive searches on Cisco's and Nortel's website and have failed to come up with any information regarding this. I noticed that Lucent has kept the IP Navigator that they got from Ascend.. they talk about multicast MPLS support, yet it is somewhat unclear whether they support PIM-SM or DVMRP functionality in full. A couple of years ago, when Ascend was still around, their imlementation supported MOSPF, but also had the BR functionality for some other multicast routing protocols. I was wondering if anyone could throw some light into whether they now support other multicast routing protocols. I am also trying to get a sense of where the IETF is going with the rest of the expired drafts related to multicast and MPLS. Are those drafts not refreshed because they are not viewed as being viable or it is just a matter of time before more work is done in this area? Basically, where is multicast in the list of priorities for the MPLS WG? Thanks, Vidya ------_=_NextPart_000_01C08D39.271F0310 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhUQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcCAAIACgA4ADkABQBcAQEggAMADgAAANEHAgAC AAoAOAA5AAUAXAEBCYABACEAAABBQzE1NzQ4ODI2RjlENDExOUJEMjAwOTAyN0U3OEYzMQAHBwEE gAEAFAAAAE11bHRpY2FzdCBhbmQgTVBMUyAAhQYBDYAEAAIAAAACAAIAAQOQBgCICQAAMgAAAAIB cQABAAAAFgAAAAHAjTknC3Y9KDL5JBHUvcQAEKTFY/4AAAMA3j+vbwAAAwAAgAggBgAAAAAAwAAA AAAAAEYAAAAAUoUAAPATAAAeAAGACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUA CwACgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAB hQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAFgAggBgAAAAAAwAAAAAAA AEYAAAAADoUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAA AMAAAAAAAABGAAAAABGFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAmA CCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYA AAAAN4UAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAA AAALAAyACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsADYALIAYAAAAAAMAAAAAAAABGAAAA AAWIAAAAAAAAAgEJEAEAAAD4AwAA9AMAAMAFAABMWkZ1JX6O2AMACgByY3BnMTI1FjIA+Atgbg4Q MDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGAeYwBQCwMLtRFgbGwsEwqi CoBJIBDwdmUgImIJ4SBkbwuAZyB+cwNwFMAJcBEgCsAQ4CBRAiAgdGgUwHMBkHQCdQQgb2YgbXVs 6nQN4GEW4CAD8BagBdCAUExTLiBJJxS2+wIQE+BvA/AVYRaiC2AX8f8X0BPgGpADcAeAAjAEIAIQ rwXAFqIXiANQYQeAdwWwUmsVIWN1GyIgAHBk/xjAFdEHgAbQBJAVgAngFVn1C2B0CYAgHkALcAMg FqB7FwAXcGEBAB3AF3AbMWnnFnEXURWTZXgEABewFWH/F4gHcAtQHkECMBcAIWEXM/8YdRgQF+AY EAIgBIEVUgaQbR3BeQIgFMBrJlAH4Hd/IHIUsBKABbAEIArAFsF1/HBwCREifBcgFVIkhhST/xUw JlEiIB/AAIEUsRYEB5FtFnFDBAAFoCcngR3hTscJER+QLGF3ZWIAkB/Amx3DFJNmICEf0XRvGuLf FMAn8BgUJhEjQG4bgQDAeyFTCXBnCxEZ1AQAJMJu7m8XsS6yIHJMEsAdkhDwmQQga2UFMRaiSVAH sP0UoGkxAC7gG6IggRahMAB+ZzIQHJEDcBFgBPAnMS73GLA1MwGQbB0gAaAIYCCRxxeXGHIn1iwg eREwI0CPIzEEIBWSJtN1bmMjgH8KwSbQETAWsBujMAAn5SDAUElNLVNNFmAFwNBEVk1SNCBmOlEh Ur8HQBgwMAI9ERPgGLBBGuH/J/AjgBdCOSARAR3ANYA5AP860QOgNhQk8yJRGsEKwAhg9xKAOQAW oWkFwAdwI4kn1kEf0U1PU1BGOQBiPzdxB0AVkBSBMmIUwEJS/z0dG4IVkzIQOxIXiEFxImP+cANg LuAI4TGzJQ8mFT6xPmwyYgNgB+AVkz2wZ2j/IzECMC7wOtsyAEtRO7VG7z9H/wrjCoQUUhzARGR0 cvZ5GdMu8Gc5MSEAESAAgI8/AzrRJ7Ez00VURjmC/zWAFVIYIxaiFeFN4RdgFqLtIiBwQhAf0WQc sAGABCB/H4Yu4ReIHdIYdAcQU2Jv/1LBVnUyARXRA1AHkBawHfD/FOAX0BcgU2MwACeiWeISIv8f 0UlBFOAVUhIgAaA+8kIh/TlzahcgUlIwcR/ABcBVgv8HcRTRG4Eb4V+iHPM5kSpj5z4BMYInkmE/ RTAX4BfB/RPgeT/jJ7E5kSK5FoQ9sP9VVEhgIWAFEBewB5EbhjhDLFdHYcBQOlQQ8G5rgnMUBVZp ZHlhFBQFEeEAaPAeAHAAAQAAABQAAABNdWx0aWNhc3QgYW5kIE1QTFMgAAsAAgABAAAAAwD9P+QE AABAADkAEAMfJzmNwAEDAPE/CQQAAB4AMUABAAAABwAAAENWTjA2NQAAAwAaQAAAAAAeADBAAQAA AAcAAABDVk4wNjUAAAMAGUAAAAAAAwAmAAAAAAADADYAAAAAAAMAgBD/////CwDyEAEAAAACAUcA AQAAAC8AAABjPVVTO2E9IDtwPW1vdDtsPUlMMDJFWE0yNi0wMTAyMDIxNjU2NTdaLTEzNTQ5AAAC Afk/AQAAAEcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TU9UL09VPUxNUFNJTDAy L0NOPVJFQ0lQSUVOVFMvQ049Q1ZOMDY1AAAeAPg/AQAAABcAAABOYXJheWFuYW4gVmlkeWEtQ1ZO MDY1AAAeADhAAQAAAAcAAABDVk4wNjUAAAIB+z8BAAAARwAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAvTz1NT1QvT1U9TE1QU0lMMDIvQ049UkVDSVBJRU5UUy9DTj1DVk4wNjUAAB4A+j8B AAAAFwAAAE5hcmF5YW5hbiBWaWR5YS1DVk4wNjUAAB4AOUABAAAABwAAAENWTjA2NQAAQAAHMDJN Gic5jcABQAAIMNppHyc5jcABHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAFAAAAE11bHRpY2FzdCBh bmQgTVBMUyAAHgA1EAEAAABAAAAAPDAxRkFGNjVERUExNkQ0MTE5Qjk1MDA5MDI3RTc4RjMxNDlE OTREQGlsMDJleG0yNi5jb21tLm1vdC5jb20+AAsAKQAAAAAACwAjAAAAAAADAAYQYqqL2AMABxA4 BAAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEFMTCxJSEFWRUJFRU5ET0lOR1NPTUVSRVNF QVJDSE9OVEhFU1RBVFVTT0ZNVUxUSUNBU1RXSVRITVBMU0lWRUJFRU5GT0xMT1dJTkdUSEVMQVNU Q0FMTENPTU1FTlRTRk9SVEgAAAAAAgF/AAEAAABAAAAAPDAxRkFGNjVERUExNkQ0MTE5Qjk1MDA5 MDI3RTc4RjMxNDlEOTREQGlsMDJleG0yNi5jb21tLm1vdC5jb20+AJY1 ------_=_NextPart_000_01C08D39.271F0310-- From owner-mpls@UU.NET Fri Feb 2 12:27:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16976 for ; Fri, 2 Feb 2001 12:27: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 QQkaqv06490; Fri, 2 Feb 2001 17:26:01 GMT Received: by mail-control.mail.uu.net id QQkaqv18393 for mpls-outgoing; Fri, 2 Feb 2001 17:25:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqv18381 for ; Fri, 2 Feb 2001 17:25:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkaqv02167 for ; Fri, 2 Feb 2001 17:25:28 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkaqv01568 for ; Fri, 2 Feb 2001 17:25:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA23413 for mpls@uu.net; Fri, 2 Feb 2001 12:25:25 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqv18220 for ; Fri, 2 Feb 2001 17:24:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkaqv29801 for ; Fri, 2 Feb 2001 17:24:27 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 QQkaqv29839 for ; Fri, 2 Feb 2001 17:24:27 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 MAA07968; Fri, 2 Feb 2001 12:24:03 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABJ77460; Fri, 2 Feb 2001 12:24:24 -0500 (EST) Message-Id: <4.3.2.7.2.20010202122455.029ef960@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Feb 2001 12:29:44 -0500 To: Narayanan Vidya-CVN065 , "'mpls'" From: "Thomas D. Nadeau" Subject: Re: MPLS VPN work In-Reply-To: <01FAF65DEA16D4119B95009027E78F3149D94C@il02exm26.comm.mot. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Please pardon my ignorance, but, could anyone tell me where all the MPLS >VPN work is being done? PPVPN. >I didn't find any drafts under the MPLS working group and the PPVPN >working group link is broken. The CCAMP working group does not have any >I-Ds or RFCs associated with it yet. From the last IETF, I gathered that >CCAMP would be closely related to some other WGs including the PPVPN one, >but, as of now, I am unable to figure out the home for VPN related work. Go here and search for "MPLS VPN": http://search.ietf.org/search/brokers/internet-drafts/query.html --Tom From owner-mpls@UU.NET Fri Feb 2 12:44:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17770 for ; Fri, 2 Feb 2001 12:44: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 QQkaqw01255; Fri, 2 Feb 2001 17:41:53 GMT Received: by mail-control.mail.uu.net id QQkaqw20245 for mpls-outgoing; Fri, 2 Feb 2001 17:41:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqw20169 for ; Fri, 2 Feb 2001 17:41:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkaqw04738 for ; Fri, 2 Feb 2001 17:40:04 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 QQkaqw11852 for ; Fri, 2 Feb 2001 17:40: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 JAA04195 for ; Fri, 2 Feb 2001 09:40:17 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA08462 for mpls@uu.net; Fri, 2 Feb 2001 12:40:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqw19373 for ; Fri, 2 Feb 2001 17:33:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkaqw16735 for ; Fri, 2 Feb 2001 17:31:55 GMT Received: from motgate2.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate2.mot.com [136.182.1.10]) id QQkaqw15561 for ; Fri, 2 Feb 2001 17:31:55 GMT Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA20852 for ; Fri, 2 Feb 2001 10:31:49 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA02030 for ; Fri, 2 Feb 2001 10:31:47 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 2 Feb 2001 11:31:46 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D94F@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'Thomas D. Nadeau'" , "'mpls'" Subject: RE: MPLS VPN work Date: Fri, 2 Feb 2001 11:31:44 -0600 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 Thank you, Tom. I do have the drafts from doing that search, but since I didn't find the related working group, I was a little confused as to where the work was being done. Thanks for the clarification. Vidya > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, February 02, 2001 11:30 AM > To: Narayanan Vidya-CVN065; 'mpls' > Subject: Re: MPLS VPN work > > > > > >Please pardon my ignorance, but, could anyone tell me where > all the MPLS > >VPN work is being done? > > PPVPN. > > >I didn't find any drafts under the MPLS working group and the PPVPN > >working group link is broken. The CCAMP working group does > not have any > >I-Ds or RFCs associated with it yet. From the last IETF, I > gathered that > >CCAMP would be closely related to some other WGs including > the PPVPN one, > >but, as of now, I am unable to figure out the home for VPN > related work. > > Go here and search for "MPLS VPN": > > > http://search.ietf.org/search/brokers/internet-drafts/query.html > > --Tom > > > > From owner-mpls@UU.NET Fri Feb 2 13:23:33 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20302 for ; Fri, 2 Feb 2001 13:23: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 QQkaqz10166; Fri, 2 Feb 2001 18:22:11 GMT Received: by mail-control.mail.uu.net id QQkaqz08075 for mpls-outgoing; Fri, 2 Feb 2001 18:21: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 QQkaqz08051 for ; Fri, 2 Feb 2001 18:21:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkaqz19384 for ; Fri, 2 Feb 2001 18:17:57 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkaqz17427 for ; Fri, 2 Feb 2001 18:17:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA28288 for mpls@uu.net; Fri, 2 Feb 2001 13:17: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 QQkaqz07804 for ; Fri, 2 Feb 2001 18:17:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkaqz15381 for ; Fri, 2 Feb 2001 18:16:26 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 QQkaqz29852 for ; Fri, 2 Feb 2001 18:16:25 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA28041; Fri, 2 Feb 2001 10:16:02 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14970.63841.958000.230501@gargle.gargle.HOWL> Date: Fri, 2 Feb 2001 10:16:01 -0800 To: Kireeti Kompella Cc: akyol@pluris.com, mpls@UU.NET, dkatz@juniper.net, swallow@cisco.com, tli@procket.com Subject: Re: Handling multiple IP addresses on PPP interfaces with RSVP-TE In-Reply-To: <200102021656.IAA07122@kummer.juniper.net> References: <14969.44142.345000.601771@gargle.gargle.HOWL> <200102021656.IAA07122@kummer.juniper.net> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti> It behooves OSPF to say a few words on this Kireeti> subject, if for no other reason than to keep up in Kireeti> the ISIS-OSPF arms race. Anyone from the OSPF land willing to take this on and comment on whether we can advertise multiple IP addresses per interface with TE extensions? Bora From owner-mpls@UU.NET Fri Feb 2 14:51:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24676 for ; Fri, 2 Feb 2001 14:51: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 QQkaqu02934; Fri, 2 Feb 2001 17:07:41 GMT Received: by mail-control.mail.uu.net id QQkaqu16255 for mpls-outgoing; Fri, 2 Feb 2001 17:07:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaqu16220 for ; Fri, 2 Feb 2001 17:06:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkaqu22160 for ; Fri, 2 Feb 2001 17:06:44 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 QQkaqu08211 for ; Fri, 2 Feb 2001 17:06:44 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 JAA10805 for ; Fri, 2 Feb 2001 09:06:54 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA08351 for mpls@uu.net; Fri, 2 Feb 2001 12:06:40 -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 QQkaqt01977 for ; Fri, 2 Feb 2001 16:48: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 QQkaqt09988 for ; Fri, 2 Feb 2001 16:46:22 GMT Received: from ftpbox.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ftpbox.mot.com [129.188.136.101]) id QQkaqt08778 for ; Fri, 2 Feb 2001 16:46:22 GMT Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA22077 for ; Fri, 2 Feb 2001 09:46:21 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA22616 for ; Fri, 2 Feb 2001 09:42:19 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 2 Feb 2001 10:46:19 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D94C@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'mpls'" Subject: MPLS VPN work Date: Fri, 2 Feb 2001 10:45:55 -0600 X-MS-TNEF-Correlator: <01FAF65DEA16D4119B95009027E78F3149D94C@il02exm26.comm.mot.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C08D37.9C793240" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C08D37.9C793240 Content-Type: text/plain; charset="iso-8859-1" All, Please pardon my ignorance, but, could anyone tell me where all the MPLS VPN work is being done? I didn't find any drafts under the MPLS working group and the PPVPN working group link is broken. The CCAMP working group does not have any I-Ds or RFCs associated with it yet. From the last IETF, I gathered that CCAMP would be closely related to some other WGs including the PPVPN one, but, as of now, I am unable to figure out the home for VPN related work. Thanks for any pointers. Vidya ------_=_NextPart_000_01C08D37.9C793240 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhUQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcCAAIACgAtADcABQBPAQEggAMADgAAANEHAgAC AAoALQA3AAUATwEBCYABACEAAAA1MTE0NzQ4ODI2RjlENDExOUJEMjAwOTAyN0U3OEYzMQDoBgEE gAEADgAAAE1QTFMgVlBOIHdvcmsAMwQBDYAEAAIAAAACAAIAAQOQBgB4BwAAMQAAAAMAAIAIIAYA AAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgABgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAE AAAAOC41AAsAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAA AEYAAAAAAYUAAAAAAAALAASACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsABYAIIAYAAAAA AMAAAAAAAABGAAAAAA6FAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeA CCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAA AAAAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ACoAIIAYAAAAAAMAA AAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAA AAEAAAAAAAAACwAMgAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAA2ACyAGAAAAAADAAAAA AAAARgAAAAAFiAAAAAAAAAIBCRABAAAA+AEAAPQBAAB5AgAATFpGdcOgceoDAAoAcmNwZzEyNRYy APgLYG4OEDAzM08B9wKkA+MCAGNoCsBzsGV0MCAHEwKAfQqBknYIkHdrC4BkNAxgHmMAUAsDC7UR YGxsLEMKogqAUGxlYREgIAMLAgIgIG15IGlnBm4FsABwY2UsIGIMdXQWEAWgdWxkIM0AcHkCIBTA dGUT4BVAeRTAd2gEkBTAB0ADIHQTF+AF0FBMBfBWUE6bF8AFsGsVcAQgYmULgIRnIBURZT8gSRoQ 0GlkbicFQGYScRbS7xoQFcABgAQgdRKABJAYaO8ZQhniCcAIYHAW0RbAGHLsUFAZBh1IbAuAGXQD YCJrCfAuIFQYgUND/kEYsBz9FRAHkRWgBUAQ8MZ2GBEbcUktRAQgBbEYUkZDBCAUoHNvY38HMBdQ FsAD8BhwFXAFQHm7ETAggEYDYRhjC2BzBUCwSUVURhYQGoBnJHD/F+IeAiRwINcWohnAFnAJAD0R IGwVYAlwC2AkgnRvHiAkMBehIoAX4SBXR/cEIAuAKMB1GqAZ8R4oFxFXFhUUoCOAZiJhdyayYb8l wBwQAaAUgCmyGxBnCHD3KiEWQBhjaCoCAhAFwBkCeylGGUIuFBQUFCCgAHBr5wQgL6IbYnBvC4AX UBEQZTDlVhqweWEUFBHhAAE0gB4AcAABAAAADgAAAE1QTFMgVlBOIHdvcmsAAAACAXEAAQAAABYA AAABwI03nGx2PSgv+SQR1L3EABCkxWP+AAALAAIAAQAAAAMA3j+vbwAAQAA5AEAyeZw3jcABAwDx PwkEAAAeADFAAQAAAAcAAABDVk4wNjUAAAMAGkAAAAAAHgAwQAEAAAAHAAAAQ1ZOMDY1AAADABlA AAAAAAMA/T/kBAAAAwAmAAAAAAADADYAAAAAAAMAgBD/////AgFHAAEAAAAvAAAAYz1VUzthPSA7 cD1tb3Q7bD1JTDAyRVhNMjYtMDEwMjAyMTY0NTU1Wi0xMzI4OAAAAgH5PwEAAABHAAAAAAAAANyn QMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPU1PVC9PVT1MTVBTSUwwMi9DTj1SRUNJUElFTlRTL0NO PUNWTjA2NQAAHgD4PwEAAAAXAAAATmFyYXlhbmFuIFZpZHlhLUNWTjA2NQAAHgA4QAEAAAAHAAAA Q1ZOMDY1AAACAfs/AQAAAEcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TU9UL09V PUxNUFNJTDAyL0NOPVJFQ0lQSUVOVFMvQ049Q1ZOMDY1AAAeAPo/AQAAABcAAABOYXJheWFuYW4g VmlkeWEtQ1ZOMDY1AAAeADlAAQAAAAcAAABDVk4wNjUAAEAABzB4i4cZN43AAUAACDAYT36cN43A AR4APQABAAAAAQAAAAAAAAAeAB0OAQAAAA4AAABNUExTIFZQTiB3b3JrAAAAHgA1EAEAAABAAAAA PDAxRkFGNjVERUExNkQ0MTE5Qjk1MDA5MDI3RTc4RjMxNDlEOTRDQGlsMDJleG0yNi5jb21tLm1v dC5jb20+AAsAKQAAAAAACwAjAAAAAAADAAYQzaAtsAMABxCLAQAAAwAQEAAAAAADABEQAAAAAB4A CBABAAAAZQAAAEFMTCxQTEVBU0VQQVJET05NWUlHTk9SQU5DRSxCVVQsQ09VTERBTllPTkVURUxM TUVXSEVSRUFMTFRIRU1QTFNWUE5XT1JLSVNCRUlOR0RPTkU/SURJRE5URklOREFOWURSQUYAAAAA AgF/AAEAAABAAAAAPDAxRkFGNjVERUExNkQ0MTE5Qjk1MDA5MDI3RTc4RjMxNDlEOTRDQGlsMDJl eG0yNi5jb21tLm1vdC5jb20+AAZ3 ------_=_NextPart_000_01C08D37.9C793240-- From owner-mpls@UU.NET Fri Feb 2 17:27:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02585 for ; Fri, 2 Feb 2001 17:27: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 QQkarp25533; Fri, 2 Feb 2001 22:24:33 GMT Received: by mail-control.mail.uu.net id QQkarp21797 for mpls-outgoing; Fri, 2 Feb 2001 22:24:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkarp21764 for ; Fri, 2 Feb 2001 22:24: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 QQkarp11109 for ; Fri, 2 Feb 2001 22:22:53 GMT Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkarp11110 for ; Fri, 2 Feb 2001 22:22:52 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f12MMmJ10829; Fri, 2 Feb 2001 17:22:48 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; FRI, 2 Feb 2001 17:21:40 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Feb 2001 17:21:40 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A81D0@newman.tenornet.com> From: "Shah, Himanshu" To: "'Kireeti Kompella'" , "'Chandru Sargor'" Cc: mpls@UU.NET, nbvpn@bbo.com Subject: RE: question on kompell draft for L2VPN Date: Fri, 2 Feb 2001 17:21:40 -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 Kireeti, Chandru, It seems rather odd of wanting to conserve on 2-bytes in the payload when in fact we are adding a lot more bytes using MPLS header and 2 labels, etc. Translating this info into inner label (or in optional control word) at ingress and back into q922 header at egress PE is stretching it too far - just for sake of conserving 2-bytes!! at the expense of adding more processing overhead at 2 ends.. In a typical frame-relay switch, only DLCI bits get replaced from ingress interface to egress interface. L2VPN is nothing but a 2 half switches separated by MPLS cloud (as far as data packet processing is concerned). There is no reason why we could not remain as close to the switch architecture as possible. Also, I had like to draw your attention to following text from draft-martini-l2circuit-encap-mpls-00.txt (Encapsulation Methods for Transport of Layer 2 Frames Over MPLS). According to this text we would have compliancy issue. I highly recommend we drop the 'q922 stripping' requirement... Himanshu Shah Tenor networks Acton, MA ----------- text from draft-martini-l2circuit-encap-mpls-00.txt ------- "5. Protocol-Specific Issues 5.1. Frame Relay A Frame Relay PDU is transported in its entirety, including the Frame Relay header. The sequencing control word is OPTIONAL. The BECN and FECN signals are carried unchanged across the network in the Frame Relay header. These signals do not appear in the MPLS header, and are unseen by the MPLS network. The Label Edge Routers that implement this document MAY, when either adding or removing the encapsulation described herein, change a zero to a one in either or both of these bits in order to reflect congestion in the MPLS network that is known to the LERs. The BECN and FECN bits MUST NEVER be changed from one to zero. The ingress LSR MAY consider the DE bit of the Frame Relay header when determining the value to be placed in the EXP fields of the MPLS label stack. In a similar way, the egress LSR MAY consider the EXP field of the VC label when queuing the packet for egress." -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, February 02, 2001 2:14 AM To: hshah@tenornetworks.com; kireeti@juniper.net Cc: mpls@UU.NET Subject: Re: question on kompell draft for L2VPN > I was wondering if there was any particular reason why 2-byte Q922 header > is stripped from data packet at ingress PE when encap is frame relay. A new DLCI gets put on at the far end, so why keep the old one? > I would think it might be beneficial to preserve the header > (for FECN/BECN, DE info) than not. Keep 16 bits because 4 may be useful? There was a proposal to encode these bits in the inner label, using a combination of the EXP bits, and the label itself. This was vetoed in favor of carrying these bits in the (optional) control word. One may argue, why 32 bits when 16 would do? Since the control word is optional, if < 50% of the users of Frame Relay over MPLS want these bits, this approach comes out ahead. Since 0% of the (admittedly small) sample of folks I know who use FR/MPLS need these bits, the universe is ahead (so far). Rest assured however that there will be protocol mechanisms to preserve these bits. Note too that ATM AAL5 encap throws away the cell headers -- this is entirely identical. There are useful bits in the cell header besides the VPI/VCI. > If there is any overwhelming reason to strip the header, how about adding > another encapsulation type of "frame relay with q922-header"? What is the overwhelming reason to carry the dlci? Kireeti. From owner-mpls@UU.NET Fri Feb 2 22:15:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12079 for ; Fri, 2 Feb 2001 22:15: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 QQkasi03254; Sat, 3 Feb 2001 03:14:23 GMT Received: by mail-control.mail.uu.net id QQkasi24542 for mpls-outgoing; Sat, 3 Feb 2001 03:13:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkasi24531 for ; Sat, 3 Feb 2001 03:13:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkasi16624 for ; Sat, 3 Feb 2001 03:12:42 GMT Received: from lima.md.photuris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.122.226.193]) id QQkasi22584 for ; Sat, 3 Feb 2001 03:12:40 GMT Received: from lima.md.photuris.com (gopal@localhost) by lima.md.photuris.com (8.11.0/8.11.0) with ESMTP id f133Cdb00955; Fri, 2 Feb 2001 22:12:39 -0500 Message-Id: <200102030312.f133Cdb00955@lima.md.photuris.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mpls@UU.NET cc: gopal@photuris.com Subject: Questions on draft-martini-l2circuit-encap-mpls-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Feb 2001 22:12:39 -0500 From: Gopal Kailad Sender: owner-mpls@UU.NET Precedence: bulk Section 3: It is not clear why padding is *required* ? We would need the length in case of small packets, but I think padding can be taken care of at the lower layer? There is a requirement that PDUs carrying the control word MUST NOT be delivered out of order. This control word also carries the length. So, if in order delivery is not required for a Frame Relay connection, but small packets are expected, should in order delivery be forced? Also, consider the case of VCC transport mode described in section 5.2. If a combination of ATM cells (OAM) and AAL5-CPCS PDUs are to be carried over a connection, we need to use the control word as we need the T-bit to differentiate cells from frames. But then this forces in order delivery, which may not be required. (If cell level sequencing is required, one has to anyways use only cell encapsulation and transport each cell individually.) One solution would be to add a bit to indicate if the control word contains a valid sequence number, and remove the restriction that PDUs carrying control word should be delivered in order. According to the draft, the endpoints should be configured with the knowledge of whether a control word will be used for a specific virtual circuit. But then, if a virtual circuit is set up to carry a Frame Relay DLCI without the control word, and a small packet is received to be encapsulated, should it be dropped because there is no control word to contain the length? Of course, the control word can always be enabled when a circuit is set up, but then it may not be needed except in case of occasional small packets. One solution would be to use one of the EXP bits in the encapsulating label to indicate the presence/absence of the control word. This bit will be set (and a control word will follow) for all packets on a virtual circuit if in-order delivery is required. Otherwise, it will be set only when control word is necessary - in case of small packets, for example. Section 5.1: The draft states that FCS will not be carried in case of Ethernet, cisco HDLC and PPP. But in section 5.1 (Frame Relay) there is no mention of FCS. Is there any reason to carry FCS in case of Frame Relay? Section 5.2: There seems to be a contradiction: "The ATM Cell encapsulation consists of an MPLS label stack, a required generic sequencing control word, a 4 byte ATM cell header, and the ATM cell payload." Later in the same section, "VPC transport mode may only be used to transport ATM *cells*. The sequencing control word is *optional* in VPC transport mode." Also, note that the sequence number is only 16 bits - the rollover would be every 64 K cells in VPC mode. 32 bits would be better. Cheers, Gopal From owner-mpls@UU.NET Mon Feb 5 05:58:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03110 for ; Mon, 5 Feb 2001 05:58: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 QQkbax11591; Mon, 5 Feb 2001 10:57:33 GMT Received: by mail-control.mail.uu.net id QQkbax26374 for mpls-outgoing; Mon, 5 Feb 2001 10:57:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbax26368 for ; Mon, 5 Feb 2001 10:57:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbax29219 for ; Mon, 5 Feb 2001 10:56:55 GMT From: richard.crouch@vf.vodafone.co.uk Received: from igate2.vodafone.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: igate2.vodafone.co.uk [194.62.232.10]) id QQkbax25348 for ; Mon, 5 Feb 2001 10:56:53 GMT Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id KAA29874; Mon, 5 Feb 2001 10:56:52 GMT Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 05 Feb 2001 10:56:54 +0000 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2448.0) id <1C034YV6>; Mon, 5 Feb 2001 10:54:42 -0000 Message-Id: <1763F57BB8BAD211B06500A0C9E5D9200366C643@barking.vfl.vodafone> To: giles@level3.net Cc: mpls@UU.NET Subject: Cell-based MPLS can't do fast-reroute ? Date: Mon, 5 Feb 2001 10:54:40 -0000 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 Giles, your statement :- "TE and fast-reroute however are a different story, since labels are being pushed and popped in the middle of the path. I can't see how this can be done with ATM MPLS?" confirms my *intuition* that in an IP-only (i.e. no ships-in-the-night going on)MPLS network with a core built soley from ATM-LSRs, then the inability of an ATM-LSR to be able to push and pop labels in the middle of the path renders it incapable of performing fast-reroute in the core. However, intuition is not always enough and I am interested if there are any parts of the MPLS IDs/RFCs that contain mandatory requirements that would specifically *prevent* ATM-LSRs from performing the fast-reroute. Surely this renders the cell-based variant of MPLS as an inferior implementation (compared to packet-based MPLS) if high survivability through use of path recovery within the core is deemed a necessary requirement ? Or, is there a method by which ATM-LSRs can achieve the path-recovery function in an interoperable method ? -----Original Message----- From: Giles Heron [mailto:giles@level3.net] Sent: 19 January 2001 17:01 To: richard.crouch@vf.vodafone.co.uk Cc: mpls@UU.NET Subject: Re: Implications of cell-based or frame-based MPLS richard.crouch@vf.vodafone.co.uk wrote: > > Given two homogenous carrier MPLS networks providing only IP services :- > > Network A : where "cell-based" MPLS is used (e.g. an ATM network got > upgraded to include MPLS, -> label carried in the VPI/VCI) and > Network B : where "frame/packet-based" MPLS is used (e.g. a router network > got upgraded to include MPLS -> label shimmed between L2 and L3 headers) > > then apart from the additional time to complete convergence in the event of > link failure for the cell-based MPLS network (due to additional convergence > time of LDP where conservative label retention mode is used by the > "cell-based" MPLS network), That's a pretty good reason to prefer frame-based for starters! > (1) What are the other major differences in performance/capabilities as a > consequence of these two different implementations of MPLS (cell versus > packet-based) ? Frame-based should be faster (no SAR bottlenecks, plus ready support for trunk interfaces above OC-48), and more efficient (no "cell tax"). It's also nice to be able to mix media types (e.g. GigE for the LAN and POS for the WAN). One major issue with cell-based MPLS is support for LSP-merge. In a frame-based MPLS network with LDP label distribution you require only O(n) labels, where n is the number of PE devices. With cell-based you require O(n squared) - unless you have a VC-merge capable ATM switch (where the switch buffers cells from different frames to ensure they don't get interleaved). So that's a major scalability issue for cell-based MPLS. With frame-based you'd also have the option of doing IP forwarding at wire-speed if required, since most routers will forward IP and MPLS in the same fast path. > (2) In the area of MPLS applications such as MPLS-VPNs, MPLS > traffic-engineering and fast-reroute, what impacts are caused by the > inability of an ATM-LSR to pop/push labels in the label stack compared to a > "frame/packet-based" LSR (which can pop/push labels in the label stack) ? I don't think VPN is impacted by this? The VPN label should only be in the AAL5 frame (and not in the cell header) since it is carried unchanged from PE to PE? TE and fast-reroute however are a different story, since labels are being pushed and popped in the middle of the path. I can't see how this can be done with ATM MPLS? > In a most crude form, I am asking the question "what's better : cell-mode or > frame/packet-mode MPLS" I guess you can figure out my answer from the above? ;-) Giles -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Mon Feb 5 14:57:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16107 for ; Mon, 5 Feb 2001 14:57: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 QQkbch02039; Mon, 5 Feb 2001 19:54:47 GMT Received: by mail-control.mail.uu.net id QQkbch10396 for mpls-outgoing; Mon, 5 Feb 2001 19:54:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbch10390 for ; Mon, 5 Feb 2001 19:54:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbch21304 for ; Mon, 5 Feb 2001 19:54:11 GMT Received: from gw.tropicnetworks.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.tropicnetworks.com [209.87.233.9]) id QQkbch19869 for ; Mon, 5 Feb 2001 19:54:09 GMT Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for cmr1.ash.ops.us.uu.net [198.5.241.39]) with SMTP; 5 Feb 2001 19:55:16 UT Received: from PCNEUSTADTER ([10.1.2.74]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAA5D13 for ; Mon, 5 Feb 2001 14:56:06 -0500 From: "Udo Neustadter" To: "mpls@uu.net" Subject: LSP-ID limit of 16 bit Date: Mon, 5 Feb 2001 14:51:24 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, CR-LDP and RSVP-TE ID define an identifier for a path in the network. Both definitions include an end point address and a 16 bit local path identifier. I would appreciate any comments on the following issues: 1) do people consider the 16 bit (64K) limitation acceptable? 2) what would be an interoperable way to initiate more that 64K explicitly routed paths from the same system (unique IP address)? 3) is this issue considered in GMPLS? Thanks, Udo From owner-mpls@UU.NET Mon Feb 5 15:19:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16614 for ; Mon, 5 Feb 2001 15:19: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 QQkbcj26076; Mon, 5 Feb 2001 20:16:03 GMT Received: by mail-control.mail.uu.net id QQkbcj26371 for mpls-outgoing; Mon, 5 Feb 2001 20:15:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbcj26363 for ; Mon, 5 Feb 2001 20:15:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbci11191 for ; Mon, 5 Feb 2001 20:14:11 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbci23064 for ; Mon, 5 Feb 2001 20:14:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA14081 for mpls@uu.net; Mon, 5 Feb 2001 15:14:10 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbci25914 for ; Mon, 5 Feb 2001 20:13:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbci04747 for ; Mon, 5 Feb 2001 20:13:24 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 QQkbci08129 for ; Mon, 5 Feb 2001 20:13:23 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA22062; Mon, 5 Feb 2001 12:13:33 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f15KDLd26877; Mon, 5 Feb 2001 12:13:21 -0800 (PST) Received: from chmetz-pc.cisco.com ([10.19.239.35]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA03181; Mon, 5 Feb 2001 12:13:19 -0800 (PST) Message-Id: <4.3.1.2.20010205151031.02645e70@sj-email.cisco.com> X-Sender: chmetz@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 05 Feb 2001 15:11:11 -0800 To: Narayanan Vidya-CVN065 From: Chris Metz Subject: RE: MPLS VPN work Cc: "'Thomas D. Nadeau'" , "'mpls'" In-Reply-To: <01FAF65DEA16D4119B95009027E78F3149D94F@il02exm26.comm.mot. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Narayanan- See: http://nbvpn.francetelecom.com/ Thanks ... At 11:31 AM 02/02/2001 -0600, Narayanan Vidya-CVN065 wrote: >Thank you, Tom. I do have the drafts from doing that search, but since I >didn't find the related working group, I was a little confused as to where >the work was being done. > >Thanks for the clarification. >Vidya > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, February 02, 2001 11:30 AM > > To: Narayanan Vidya-CVN065; 'mpls' > > Subject: Re: MPLS VPN work > > > > > > > > > > >Please pardon my ignorance, but, could anyone tell me where > > all the MPLS > > >VPN work is being done? > > > > PPVPN. > > > > >I didn't find any drafts under the MPLS working group and the PPVPN > > >working group link is broken. The CCAMP working group does > > not have any > > >I-Ds or RFCs associated with it yet. From the last IETF, I > > gathered that > > >CCAMP would be closely related to some other WGs including > > the PPVPN one, > > >but, as of now, I am unable to figure out the home for VPN > > related work. > > > > Go here and search for "MPLS VPN": > > > > > > http://search.ietf.org/search/brokers/internet-drafts/query.html > > > > --Tom > > > > > > > > Chris Metz Lead IP Architect Solutions Integration Service Provider Line of Business Cisco Systems email: chmetz@cisco.com offic phone: 408-525-3275 home office: 914-241-0423 pager: 800-365-4578 Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm From owner-mpls@UU.NET Mon Feb 5 17:19:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19128 for ; Mon, 5 Feb 2001 17:19: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 QQkbcq07694; Mon, 5 Feb 2001 22:14:38 GMT Received: by mail-control.mail.uu.net id QQkbcq04464 for mpls-outgoing; Mon, 5 Feb 2001 22:14:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbcq04409 for ; Mon, 5 Feb 2001 22:14:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbcq28880 for ; Mon, 5 Feb 2001 22:12:21 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: parker2.sprint.com [199.14.91.106]) id QQkbcq03352 for ; Mon, 5 Feb 2001 22:12: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 f15MKEl00991 for ; Mon, 5 Feb 2001 16:20:14 -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 f15MCKv05662 for ; Mon, 5 Feb 2001 16:12:20 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id QAA24910 for ; Mon, 5 Feb 2001 16:12:20 -0600 (CST) X-OpenMail-Hops: 1 Date: Mon, 5 Feb 2001 16:12:19 -0600 Message-Id: Subject: MPLS interoperability MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-1ad13fa8-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1ad13fa8-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Mon, 5 Feb 2001 16:12:19 -0600" Content-Transfer-Encoding: 8bit Hi All, Any drafts about RSVP-TE & CR-LDP interoperability? What happened to "draft-wright-mpls-crldp-rsvpte-iw-00"? Any concern about interoperability in other areas than signaling/label distribution? I appreciate any feedback. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations & Evaluation Group Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --openmail-part-1ad13fa8-00000001 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf" ;Creation-Date="Mon, 5 Feb 2001 16:12:19 -0600" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --openmail-part-1ad13fa8-00000001-- From owner-mpls@UU.NET Tue Feb 6 01:24:32 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28492 for ; Tue, 6 Feb 2001 01:24: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 QQkbdx23360; Tue, 6 Feb 2001 06:19:05 GMT Received: by mail-control.mail.uu.net id QQkbdx00818 for mpls-outgoing; Tue, 6 Feb 2001 06:18:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbdx00803 for ; Tue, 6 Feb 2001 06:18:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbdx21886 for ; Tue, 6 Feb 2001 06:17:45 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkbdx20686 for ; Tue, 6 Feb 2001 06:17:44 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 06 Feb 2001 11:53:39 +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 f16BpHF00721; Tue, 6 Feb 2001 17:21:18 +0530 Received: by localhost with Microsoft MAPI; Tue, 6 Feb 2001 11:33:06 +1100 Message-Id: <01C09030.92D77E80.mohanvak@future.futsoft.com> From: Mohan Varma K Reply-To: "mohanvak@future.futsoft.com" To: "'Udo Neustadter'" Cc: "'mpls@uu.net'" Subject: RE: LSP-ID limit of 16 bit Date: Tue, 6 Feb 2001 11:33:05 +1100 Organization: FSPL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-mpls@UU.NET Precedence: bulk Hi, As per mpls-te-mib-5 the index to a tunnel is also an EgressRtrID. So the limitation of 64k tunnels is between the Ingress(LSR1) and say with Egress(LSR3) Another 64k tunnels can be established between LSR1 and Egress(LSR4). LSR1 ---------- LSR2 ------------------LSR3---------LSR4. However if we do stacking at LSR1 as mentioned in CRLDP-4 we can only mention an ERHop with the IngressId of LSR1 and the Tunnel ID.So Actually the number of tunnels that can be stacked at LSR1 will be 64k. So if in case the Erhop of type LSPID is able to carry the EgressId of the tunnels at LSR1 there are merely enough number of tunnels for stacking or splicing of tunnels. Thanks Mohan Varma Hi, CR-LDP and RSVP-TE ID define an identifier for a path in the network. Both definitions include an end point address and a 16 bit local path identifier. I would appreciate any comments on the following issues: 1) do people consider the 16 bit (64K) limitation acceptable? 2) what would be an interoperable way to initiate more that 64K explicitly routed paths from the same system (unique IP address)? 3) is this issue considered in GMPLS? Thanks, Udo From owner-mpls@UU.NET Tue Feb 6 04:54:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10470 for ; Tue, 6 Feb 2001 04:54: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 QQkbel01638; Tue, 6 Feb 2001 09:52:35 GMT Received: by mail-control.mail.uu.net id QQkbel29489 for mpls-outgoing; Tue, 6 Feb 2001 09:52: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 QQkbel29484 for ; Tue, 6 Feb 2001 09:52: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 QQkbel22915 for ; Tue, 6 Feb 2001 09:51:59 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbel24096 for ; Tue, 6 Feb 2001 09:51:59 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA20857 for mpls@uu.net; Tue, 6 Feb 2001 04:51: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 QQkbel29450 for ; Tue, 6 Feb 2001 09:51:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbel19554 for ; Tue, 6 Feb 2001 09:50:39 GMT Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.dataconnection.com [192.91.191.8]) id QQkbel23391 for ; Tue, 6 Feb 2001 09:50:38 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Feb 2001 09:50:36 -0000 Message-ID: <37701240971DD31193970000F6CCB9F70125D4EF@duke.datcon.co.uk> From: Edward Harrison To: "'jcucchiara@brixnet.com'" Cc: "'mpls@uu.net'" Subject: Question on Generic Label Range Table in LDP MIB Date: Tue, 6 Feb 2001 09:50:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Joan, I have a question regarding the use of the mplsLdpEntityConfGenericIfIndexOrZero object within the LDP MIB (draft-ietf-mpls-ldp-mib-07.txt). My understanding is that it is possible to have multiple interfaces using the generic label space and that, typically, each of these interfaces would advertise the same label ranges. Furthermore, I thought that it was possible to have a single (non-targeted) LDP Entity for the generic label range - this entity being associated with all the interfaces using the generic label range. If this is correct then I believe one ends up with a single row in the Generic Label Range Table which corresponds to more than one interface - for each interface the LDP ID, Entity Index and Label Range will all be the same as each interface uses the same LDP entity and shares the same label range. In this scenario what should the value of mplsLdpEntityConfGenericIfIndexOrZero be (as there are multiple possible interface indices that are appropriate)? Should it be zero, meaning the index is unknown, or should it correspond to one of the interfaces for the Entity? Thanks very much for your help, Ed ---------------- Ed Harrison Network Convergence Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 Email: eph@dataconnection.com Web:http://www.dataconnection.com From owner-mpls@UU.NET Tue Feb 6 07:47:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11625 for ; Tue, 6 Feb 2001 07:47: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 QQkbew29343; Tue, 6 Feb 2001 12:43:00 GMT Received: by mail-control.mail.uu.net id QQkbew19248 for mpls-outgoing; Tue, 6 Feb 2001 12:42: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 QQkbew19243 for ; Tue, 6 Feb 2001 12:42: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 QQkbew20365 for ; Tue, 6 Feb 2001 12:41:18 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkbew04554 for ; Tue, 6 Feb 2001 12:41:17 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f16Cf5c03085; Tue, 6 Feb 2001 13:41:06 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569EB.0045A858; Tue, 6 Feb 2001 13:40:50 +0100 Message-ID: <3A7FF056.AECB9014@alcatel.be> Date: Tue, 06 Feb 2001 13:38:46 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Narayanan Vidya-CVN065 CC: "'mpls'" Subject: Re: Multicast and MPLS References: <01FAF65DEA16D4119B95009027E78F3149D94D@il02exm26.comm.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Narayanan, Alcatel has Multicast/MPLS running in the lab. It isn't in any product yet because it hasn't been requested by customers, but if there is a demand we can put it in fast. dirk Narayanan Vidya-CVN065 wrote: > > All, > I have been doing some research on the status of multicast with MPLS. I've been following the last call comments for the multicast framework document and I remember seeing some related email that made a mention of some existing multicast implementations of MPLS. I was wondering if anyone knew what vendors are supporting multicast using MPLS. I have done extensive searches on Cisco's and Nortel's website and have failed to come up with any information regarding this. I noticed that Lucent has kept the IP Navigator that they got from Ascend.. they talk about multicast MPLS support, yet it is somewhat unclear whether they support PIM-SM or DVMRP functionality in full. A couple of years ago, when Ascend was still around, their imlementation supported MOSPF, but also had the BR functionality for some other multicast routing protocols. I was wondering if anyone could throw some light into whether they now support other multicast routing protocols. > > I am also trying to get a sense of where the IETF is going with the rest of the expired drafts related to multicast and MPLS. Are those drafts not refreshed because they are not viewed as being viable or it is just a matter of time before more work is done in this area? Basically, where is multicast in the list of priorities for the MPLS WG? > > Thanks, > Vidya > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/ms-tnef > Encoding: base64 -- Dirk Ooms mailto:dirk.ooms@alcatel.be tel:+32 3 2404732 Network Strategy Group (NSG) http://www.rc.bel.alcatel.be/nsg Alcatel http://www.alcatel.com From owner-mpls@UU.NET Tue Feb 6 08:55:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13843 for ; Tue, 6 Feb 2001 08:55: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 QQkbfb05192; Tue, 6 Feb 2001 13:53:45 GMT Received: by mail-control.mail.uu.net id QQkbfb07118 for mpls-outgoing; Tue, 6 Feb 2001 13:53:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbfb07111 for ; Tue, 6 Feb 2001 13:53:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbfb16365 for ; Tue, 6 Feb 2001 13:52:48 GMT From: djiang1@lucent.com Received: from hoemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkbfb02323 for ; Tue, 6 Feb 2001 13:52:48 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA00788 for ; Tue, 6 Feb 2001 08:52:47 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA00772 for ; Tue, 6 Feb 2001 08:52:47 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA07988; Tue, 6 Feb 2001 08:52:46 -0500 (EST) Subject: ATM SVC encoding To: mpls@UU.NET Date: Tue, 6 Feb 2001 08:49:32 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/06/2001 08:49:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I have a question regarding ATM SVC label encoding. Would any one know whether that will prevent from label merging? Thanks. Jane D. Jiang Lucent Technologies Phone: (301) 809-4497 From owner-mpls@UU.NET Tue Feb 6 09:17:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14654 for ; Tue, 6 Feb 2001 09:17: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 QQkbfc14314; Tue, 6 Feb 2001 14:14:52 GMT Received: by mail-control.mail.uu.net id QQkbfc21641 for mpls-outgoing; Tue, 6 Feb 2001 14:14: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 QQkbfc21636 for ; Tue, 6 Feb 2001 14:14:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbfc14259 for ; Tue, 6 Feb 2001 14:14:20 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbfc09305 for ; Tue, 6 Feb 2001 14:14:19 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA02638 for mpls@uu.net; Tue, 6 Feb 2001 09:14:19 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbfc21607 for ; Tue, 6 Feb 2001 14:13:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbfc01708 for ; Tue, 6 Feb 2001 14:13:01 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 QQkbfc10308 for ; Tue, 6 Feb 2001 14:13:01 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 GAA09902; Tue, 6 Feb 2001 06:12:59 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <11AQHFBA>; Tue, 6 Feb 2001 06:15:40 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A3C@BBY1EXM01> From: Shahram Davari To: "'djiang1@lucent.com'" , mpls@UU.NET Subject: RE: ATM SVC encoding Date: Tue, 6 Feb 2001 06:15: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, The label merging could be done in ATM SVC label encoding, and is very similar to VC merge in ATM. Yours, -Shahram > -----Original Message----- > From: djiang1@lucent.com [mailto:djiang1@lucent.com] > Sent: Tuesday, February 06, 2001 8:50 AM > To: mpls@UU.NET > Subject: ATM SVC encoding > > > Hi All, > > I have a question regarding ATM SVC label encoding. Would > any one know > whether that will prevent from label merging? > > Thanks. > > Jane D. Jiang > Lucent Technologies > Phone: (301) 809-4497 > From owner-mpls@UU.NET Tue Feb 6 09:22:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14818 for ; Tue, 6 Feb 2001 09:22: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 QQkbfd09726; Tue, 6 Feb 2001 14:20:07 GMT Received: by mail-control.mail.uu.net id QQkbfd22176 for mpls-outgoing; Tue, 6 Feb 2001 14:19: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 QQkbfd22169 for ; Tue, 6 Feb 2001 14:19:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbfd28186 for ; Tue, 6 Feb 2001 14:19:25 GMT Received: from typhoon.mail.pipex.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: typhoon.mail.pipex.net [158.43.128.27]) id QQkbfd16389 for ; Tue, 6 Feb 2001 14:19:24 GMT Received: (qmail 28383 invoked from network); 6 Feb 2001 14:19:23 -0000 Received: from userdm09.uk.uudial.com (HELO alten.co.uk) (62.188.4.29) by smtp-2.dial.pipex.com with SMTP; 6 Feb 2001 14:19:23 -0000 Received: from alten.co.uk ([198.192.42.61]) by alten.co.uk ( IA Mail Server Version: 3.1.3. Build: 1065 ) ) ; 06 Feb 2001 14:24:21 UT Message-ID: <3A800914.3469DEBD@alten.co.uk> Date: Tue, 06 Feb 2001 14:24:20 +0000 From: Darren Freeland X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: ip-optical@lists.bell-labs.com Subject: G-MPLS on all-optical switches? References: <004d01c08d1e$2d4c8a20$8001a8c0@oleane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can any vendor give me some information on exactly how they intend to run G-MPLS on FULLY optical switches? For the control signals, will you use optical splitters or the like to tap off some of the lightpath inband (amplifying to compensate for the power loss), or will you use an outband network? Any info much appreciated .... Darren. From owner-mpls@UU.NET Tue Feb 6 10:51:59 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19066 for ; Tue, 6 Feb 2001 10:51: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 QQkbfj06936; Tue, 6 Feb 2001 15:48:27 GMT Received: by mail-control.mail.uu.net id QQkbfj15847 for mpls-outgoing; Tue, 6 Feb 2001 15:47: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 QQkbfj15817 for ; Tue, 6 Feb 2001 15:47:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbfj03283 for ; Tue, 6 Feb 2001 15:45:15 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQkbfj29527 for ; Tue, 6 Feb 2001 15:45:14 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 6 Feb 2001 10:41:50 -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.2653.13) id 1M3L5N5L; Tue, 6 Feb 2001 10:41:49 -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 Y9V1VZBJ; Tue, 6 Feb 2001 10:41:47 -0500 Message-ID: <3A801B38.A5356BF1@americasm01.nt.com> Date: Tue, 06 Feb 2001 10:41:47 -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: Bora Akyol CC: Kireeti Kompella , mpls@UU.NET, dkatz@juniper.net, swallow@cisco.com, tli@procket.com Subject: Re: Handling multiple IP addresses on PPP interfaces with RSVP-TE References: <14969.44142.345000.601771@gargle.gargle.HOWL> <200102021656.IAA07122@kummer.juniper.net> <14970.63841.958000.230501@gargle.gargle.HOWL> Content-Type: multipart/alternative; boundary="------------2E1FACCB011EDA4AD3DD522A" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk --------------2E1FACCB011EDA4AD3DD522A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bora Akyol wrote: > Kireeti> It behooves OSPF to say a few words on this > Kireeti> subject, if for no other reason than to keep up in > Kireeti> the ISIS-OSPF arms race. > > Anyone from the OSPF land willing to take this on and comment on > whether we can advertise multiple IP addresses per interface > with TE extensions? > > Bora I am not from OSPF land :) and I don't have the latest version of the OSPF TE Extensions draft handy but I recall a statement in the draft indicating that each sub-TLV of the Link TLV may occur only once. Two of such sub-TLVs are used to specify link addresses: localIfAddress and remoteIfAddress. This implies that to advertise a link with multiple addresses then multiple Link TLVs are needed which in turn implies that other info specified in the Link TLV (b/w, color, metric) would need to be duplicated, i.e. for a link with 5 addresses, 5 Link TLVs are needed with the only difference between the Link TLVs being the addresses while b/w, color and metric info would be the same. This is not an efficient way to advertise info about multi-address links. The question to the authors of OSPF TE Extensions draft therefore is whether the restriction of "may occur only once" be lifted. This would bring OSPF TE Extensions closer to the same extensions for ISIS (I believe the OSPF TE Extensions were supposed to mirror exactly the extensions to ISIS). In addition, the OSPF TE Extensions draft states that only a single Link TLV may occur in an Opaque LSA of Type 10 implying multiple Opaque LSAs for multiple Link TLVs. This again has a potential for a negative impact to OSPF operation in particular flooding. The question therefore is whether this restriction can also be lifted, i.e. Opaque LSA may carry more than one Link TLV. Unless these issues are resolved I can see operation of OSPF lag behind the operation of ISIS with respect to TE extensions and multi-address links. Please note that I am not trying to stir up yet another debate about OSPF vs ISIS :). Cheers, Darek -- Darek Skalecki Nortel (613) 765-2252 --------------2E1FACCB011EDA4AD3DD522A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bora Akyol wrote:
    Kireeti> It behooves OSPF to say a few words on this
    Kireeti> subject, if for no other reason than to keep up in
    Kireeti> the ISIS-OSPF arms race.

Anyone from the OSPF land willing to take this on and comment on
whether we can advertise multiple IP addresses per interface
with TE extensions?

Bora

I am not from OSPF land :) and I don't have the latest version of the OSPF TE Extensions draft handy but I recall a statement in the draft indicating that each sub-TLV of the Link TLV may occur only once. Two of such sub-TLVs are used to specify link addresses: localIfAddress and remoteIfAddress. This implies that to advertise a link with multiple addresses then multiple Link TLVs are needed which in turn implies that other info specified in the Link TLV (b/w, color, metric) would need to be duplicated, i.e. for a link with 5 addresses, 5 Link TLVs are needed with the only difference between the Link TLVs being the addresses while b/w, color and metric info would be the same. This is not an efficient way to advertise info about multi-address links. The question to the authors of OSPF TE Extensions draft therefore is whether the restriction of "may occur only once" be lifted. This would bring OSPF TE Extensions closer to the same extensions for ISIS (I believe the OSPF TE Extensions were supposed to mirror exactly the extensions to ISIS).

In addition, the OSPF TE Extensions draft states that only a single Link TLV may occur in an Opaque LSA of Type 10 implying multiple Opaque LSAs for multiple Link TLVs. This again has a potential for a negative impact to OSPF operation in particular flooding. The question therefore is whether this restriction can also be lifted, i.e. Opaque LSA may carry more than one Link TLV.

Unless these issues are resolved I can see operation of OSPF lag behind the operation of ISIS with respect to TE extensions and multi-address links. Please note that I am not trying to stir up yet another debate about OSPF vs ISIS :).

Cheers,

Darek 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------2E1FACCB011EDA4AD3DD522A-- From owner-mpls@UU.NET Tue Feb 6 14:38:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29238 for ; Tue, 6 Feb 2001 14:38: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 QQkbfy18596; Tue, 6 Feb 2001 19:36:45 GMT Received: by mail-control.mail.uu.net id QQkbfy03195 for mpls-outgoing; Tue, 6 Feb 2001 19:36: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 QQkbfy03113 for ; Tue, 6 Feb 2001 19:35:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbfy20148 for ; Tue, 6 Feb 2001 19:33:50 GMT Received: from blueyonder.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pcow029o.blueyonder.co.uk [195.188.53.123]) id QQkbfy12731 for ; Tue, 6 Feb 2001 19:33:49 GMT Received: from MADELEINE ([62.30.168.156]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 6 Feb 2001 19:35:24 +0000 Message-ID: <001201c09073$b2368490$0b0110ac@MADELEINE> From: "Alec Myers" To: "'mpls@uu.net'" Cc: "Darren Freeland" References: <004d01c08d1e$2d4c8a20$8001a8c0@oleane.com> <3A800914.3469DEBD@alten.co.uk> Subject: Re: G-MPLS on all-optical switches? Date: Tue, 6 Feb 2001 19:33:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bearing in mind: 1. The crudity of pure optical memory (fibre delay lines) 2. The lack of pure-optical logic 3. The lack of a fast (packet rate) wavelength switching technology 4. The delay in line clock-recovery between differing transmitter/receivers pairs at the start of each packet 5. The difficulty in dynamically recovering from non-linear effects in optical paths whose length varies per-packet I wouldn't expect to see a real FULLY optical switch any time soon. There are a few papers around that describe possible control schemes, but they are all rather crude, and make only passing reference to MPLS. If you're interested I can forward the references. -A ----- Original Message ----- From: "Darren Freeland" To: Cc: Sent: Tuesday, February 06, 2001 2:24 PM Subject: G-MPLS on all-optical switches? > Hi, > > Can any vendor give me some information on exactly how they intend to > run G-MPLS on FULLY optical switches? For the control signals, will you > use optical splitters or the like to tap off some of the lightpath > inband (amplifying to compensate for the power loss), or will you use an > outband network? > > Any info much appreciated .... > > Darren. > > From owner-mpls@UU.NET Tue Feb 6 14:59:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29943 for ; Tue, 6 Feb 2001 14:59: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 QQkbfz00673; Tue, 6 Feb 2001 19:57:17 GMT Received: by mail-control.mail.uu.net id QQkbfz05127 for mpls-outgoing; Tue, 6 Feb 2001 19:56:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbfz05109 for ; Tue, 6 Feb 2001 19:56:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbfz27125 for ; Tue, 6 Feb 2001 19:55:25 GMT Received: from mx1.snet.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1.snet.net [204.60.3.117]) id QQkbfz29786 for ; Tue, 6 Feb 2001 19:55:25 GMT Received: from DAVESC600 (wtrb-sh6-port136.snet.net [204.60.56.136]) by mx1.snet.net (8.11.1/8.11.1/SNET-mx-1.4/D-1.10/O-1.7) with SMTP id f16JtKv03756 for ; Tue, 6 Feb 2001 14:55:21 -0500 (EST) Reply-To: From: "Dave Danenberg" To: "'mpls@uu.net'" Subject: MPLS LSR MIB (draft-ietf-mpls-lsr-mib-07.txt) Date: Tue, 6 Feb 2001 14:56:26 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC0305BF@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C0904C.FC0BF450" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C0904C.FC0BF450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Has anyone tried compiling this MIB? There is a reference to AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB. I've seen this referenced in a few other MIBs, but I can not find the RFC that defines it. Does anyone know what RFC defines IANA-ADDRESS-FAMILY-NUMBERS-MIB? Thanx, Dave ------=_NextPart_000_0016_01C0904C.FC0BF450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS LSR MIB (draft-ietf-mpls-lsr-mib-07.txt)

Has anyone tried compiling this MIB? There is a = reference to AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB. = I've seen this referenced in a few other MIBs, but I can not find the = RFC that defines it.

Does anyone know what RFC defines = IANA-ADDRESS-FAMILY-NUMBERS-MIB?

Thanx,
Dave

------=_NextPart_000_0016_01C0904C.FC0BF450-- From owner-mpls@UU.NET Tue Feb 6 15:00:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29985 for ; Tue, 6 Feb 2001 15:00: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 QQkbfz05523; Tue, 6 Feb 2001 19:57:45 GMT Received: by mail-control.mail.uu.net id QQkbfz05167 for mpls-outgoing; Tue, 6 Feb 2001 19:57:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbfz05156 for ; Tue, 6 Feb 2001 19:56:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbfz29323 for ; Tue, 6 Feb 2001 19:56:22 GMT Received: from schilling.ucdavis.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: schilling.ucdavis.edu [169.237.105.1]) id QQkbfz29218 for ; Tue, 6 Feb 2001 19:56:21 GMT Received: from syao (d96-121.orchard2.ucdavis.edu [169.237.96.121]) by schilling.ucdavis.edu (8.11.1/8.11.0/IT4.4.8) with SMTP id f16JuDZ22680; Tue, 6 Feb 2001 11:56:13 -0800 (PST) Reply-To: From: "Shun Yao" To: "'Alec Myers'" , "'mpls@uu.net'" Cc: "'Darren Freeland'" Subject: RE: G-MPLS on all-optical switches? Date: Tue, 6 Feb 2001 11:58:37 -0800 Message-ID: <000d01c09077$323de900$7960eda9@ucdavis.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <001201c09073$b2368490$0b0110ac@MADELEINE> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I believe Darren was referring to all-optical ~circuit~ switch, not packet switch. Up to now we haven't seen one working ~fully-optical~ (no transponders, strictly non-OEO data plane) switch in the market, although many companies are claiming to be building one. In-band signaling is not as simple as split/amplify. First of all cascaded amplification add noise and other physical impairments, then when you push the data rate higher, all sorts of things will happen to the signal. If out-of-band signaling is used, performance monitoring of the data path will be difficult. I would think twice even if a vendor throws me a definite answer, because there is no working product yet. Shun > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Alec > Myers > Sent: Tuesday, February 06, 2001 11:34 AM > To: 'mpls@uu.net' > Cc: Darren Freeland > Subject: Re: G-MPLS on all-optical switches? > > > Bearing in mind: > > 1. The crudity of pure optical memory (fibre delay lines) > 2. The lack of pure-optical logic > 3. The lack of a fast (packet rate) wavelength switching technology > 4. The delay in line clock-recovery between differing > transmitter/receivers > pairs at the start of each packet > 5. The difficulty in dynamically recovering from non-linear effects in > optical paths whose length varies per-packet > > I wouldn't expect to see a real FULLY optical switch any time soon. > > There are a few papers around that describe possible control > schemes, but > they are all rather crude, and make only passing reference to MPLS. If > you're interested I can forward the references. > > -A > > > ----- Original Message ----- > From: "Darren Freeland" > To: > Cc: > Sent: Tuesday, February 06, 2001 2:24 PM > Subject: G-MPLS on all-optical switches? > > > > Hi, > > > > Can any vendor give me some information on exactly how they > intend to > > run G-MPLS on FULLY optical switches? For the control > signals, will you > > use optical splitters or the like to tap off some of the lightpath > > inband (amplifying to compensate for the power loss), or > will you use an > > outband network? > > > > Any info much appreciated .... > > > > Darren. > > > > > From owner-mpls@UU.NET Tue Feb 6 15:25:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00933 for ; Tue, 6 Feb 2001 15:25: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 QQkbgb13164; Tue, 6 Feb 2001 20:22:07 GMT Received: by mail-control.mail.uu.net id QQkbgb20825 for mpls-outgoing; Tue, 6 Feb 2001 20:21:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbgb20812 for ; Tue, 6 Feb 2001 20:21:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbgb20530 for ; Tue, 6 Feb 2001 20:18:18 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkbgb03334 for ; Tue, 6 Feb 2001 20:18:18 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05435; Tue, 6 Feb 2001 15:18:15 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02956; Tue, 6 Feb 2001 15:18:18 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LC73T>; Tue, 6 Feb 2001 15:18:11 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01E77543@whq-msgusr-02.pit.comms.marconi.com> From: "Sathappan, Senthilkumar" To: "'dave_danenberg@litchfieldcomm.com'" , "'mpls@uu.net'" Subject: RE: MPLS LSR MIB (draft-ietf-mpls-lsr-mib-07.txt) Date: Tue, 6 Feb 2001 15:18:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09079.EFFBC0F0" 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_01C09079.EFFBC0F0 Content-Type: text/plain; charset="iso-8859-1" Dave, Here is a place to get the MIB http://www.aciri.org/fenner/mibs/extracted/IANA-ADDRESS-FAMILY-NUMBERS-MIB-i anaaddressfamilynumbers.txt Senthil. -----Original Message----- From: Dave Danenberg [mailto:dave_danenberg@litchfieldcomm.com] Sent: Tuesday, February 06, 2001 2:56 PM To: 'mpls@uu.net' Subject: MPLS LSR MIB (draft-ietf-mpls-lsr-mib-07.txt) Has anyone tried compiling this MIB? There is a reference to AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB. I've seen this referenced in a few other MIBs, but I can not find the RFC that defines it. Does anyone know what RFC defines IANA-ADDRESS-FAMILY-NUMBERS-MIB? Thanx, Dave ------_=_NextPart_001_01C09079.EFFBC0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS LSR MIB (draft-ietf-mpls-lsr-mib-07.txt)
Dave,
 
Here=20 is a place to get the MIB
 
http://www.aciri.org/fenner/mib= s/extracted/IANA-ADDRESS-FAMILY-NUMBERS-MIB-ianaaddressfamilynumbers.txt=
 
Senthil.
-----Original Message-----
From: Dave Danenberg=20 [mailto:dave_danenberg@litchfieldcomm.com]
Sent: Tuesday, = February=20 06, 2001 2:56 PM
To: 'mpls@uu.net'
Subject: MPLS = LSR MIB=20 (draft-ietf-mpls-lsr-mib-07.txt)

Has anyone tried compiling this MIB? There is a = reference to=20 AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB. I've seen = this=20 referenced in a few other MIBs, but I can not find the RFC that = defines=20 it.

Does anyone know what RFC defines=20 IANA-ADDRESS-FAMILY-NUMBERS-MIB?

Thanx,
Dave=20

------_=_NextPart_001_01C09079.EFFBC0F0-- From owner-mpls@UU.NET Tue Feb 6 15:48:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01519 for ; Tue, 6 Feb 2001 15:48:21 -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 QQkbgd18440; Tue, 6 Feb 2001 20:46:56 GMT Received: by mail-control.mail.uu.net id QQkbgd23086 for mpls-outgoing; Tue, 6 Feb 2001 20:46: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 QQkbgd23078 for ; Tue, 6 Feb 2001 20:46: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 QQkbgd17275 for ; Tue, 6 Feb 2001 20:46:13 GMT Received: from auemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkbgd13109 for ; Tue, 6 Feb 2001 20:46:13 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA03637 for ; Tue, 6 Feb 2001 15:46:12 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA03623 for ; Tue, 6 Feb 2001 15:46:12 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 21:46:11 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B15A9D8@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'mpls@uu.net'" , dave_danenberg@litchfieldcomm.com Subject: RE: MPLS LSR MIB (draft-ietf-mpls-lsr-mib-07.txt) Date: Tue, 6 Feb 2001 21:46:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk You can find that MIB at: ftp://www.isi.edu/mib/ianaaddressfamilynumbers.mib Or you can get there from the www.iana.org/numbers.htm Under the letter I. Bert > ---------- > From: Dave Danenberg[SMTP:dave_danenberg@litchfieldcomm.com] > Reply To: dave_danenberg@litchfieldcomm.com > Sent: Tuesday, February 06, 2001 8:56 PM > To: 'mpls@uu.net' > Subject: MPLS LSR MIB (draft-ietf-mpls-lsr-mib-07.txt) > > Has anyone tried compiling this MIB? There is a reference to > AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB. I've seen this > referenced in a few other MIBs, but I can not find the RFC that defines > it. > > Does anyone know what RFC defines IANA-ADDRESS-FAMILY-NUMBERS-MIB? > > Thanx, > Dave > > From owner-mpls@UU.NET Wed Feb 7 00:27:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11755 for ; Wed, 7 Feb 2001 00:27: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 QQkbhl16705; Wed, 7 Feb 2001 05:26:29 GMT Received: by mail-control.mail.uu.net id QQkbhl06914 for mpls-outgoing; Wed, 7 Feb 2001 05:25:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbhl06904 for ; Wed, 7 Feb 2001 05:25:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbhl28189 for ; Wed, 7 Feb 2001 05:24:07 GMT Received: from web10511.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web10511.mail.yahoo.com [216.136.172.143]) id QQkbhl28162 for ; Wed, 7 Feb 2001 05:24:06 GMT Message-ID: <20010207052406.29485.qmail@web10511.mail.yahoo.com> Received: from [198.206.187.100] by web10511.mail.yahoo.com; Tue, 06 Feb 2001 21:24:06 PST Date: Tue, 6 Feb 2001 21:24:06 -0800 (PST) From: Mahadevan Iyer Subject: VC merge question To: mpls@UU.NET In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A3C@BBY1EXM01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello, When using VC merge to support heirarchial LSP type capabilities is it possible to stack more then 2 levels(i.e. reuse the VPI for the outer VC). If this has been discussed before, please send me a pointer to the thread Thanks __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From owner-mpls@UU.NET Wed Feb 7 09:49:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00604 for ; Wed, 7 Feb 2001 09:49: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 QQkbix01146; Wed, 7 Feb 2001 14:47:04 GMT Received: by mail-control.mail.uu.net id QQkbix18574 for mpls-outgoing; Wed, 7 Feb 2001 14:46: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 QQkbix18561 for ; Wed, 7 Feb 2001 14:46: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 QQkbiw17180 for ; Wed, 7 Feb 2001 14:41:07 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkbiw28470 for ; Wed, 7 Feb 2001 14:41:06 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 07 Feb 2001 20:17:06 +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 f17EepF22490; Wed, 7 Feb 2001 20:10:52 +0530 Received: by localhost with Microsoft MAPI; Wed, 7 Feb 2001 19:56:40 +1100 Message-Id: <01C09140.162609E0.mohanvak@future.futsoft.com> From: Mohan Varma K Reply-To: "mohanvak@future.futsoft.com" To: "'Edward Harrison'" Cc: "'mpls@uu.net'" Subject: RE: Question on Generic Label Range Table in LDP MIB Date: Wed, 7 Feb 2001 19:56:39 +1100 Organization: FSPL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-mpls@UU.NET Precedence: bulk Hi, Yes, creation of row will be a problem if we go with the assumption of the earlier ldp-mibs. As per ldp-mib 7 they have defined a generic label range on a per Interface level. If we ensure a slight different label range in configuration( for eg 16-10000 (mplsLdpEntityConfGenericIfIndexOrZero 1), 17-10000 (mplsLdpEntityConfGenericIfIndexOrZero 2) we have almost same labels available on each interface,which we don't have earlier. However if we want to create a row wth the similar label range we can have additional index to this table. with regards Mohan Varma Hi Joan, I have a question regarding the use of the mplsLdpEntityConfGenericIfIndexOrZero object within the LDP MIB (draft-ietf-mpls-ldp-mib-07.txt). My understanding is that it is possible to have multiple interfaces using the generic label space and that, typically, each of these interfaces would advertise the same label ranges. Furthermore, I thought that it was possible to have a single (non-targeted) LDP Entity for the generic label range - this entity being associated with all the interfaces using the generic label range. If this is correct then I believe one ends up with a single row in the Generic Label Range Table which corresponds to more than one interface - for each interface the LDP ID, Entity Index and Label Range will all be the same as each interface uses the same LDP entity and shares the same label range. In this scenario what should the value of mplsLdpEntityConfGenericIfIndexOrZero be (as there are multiple possible interface indices that are appropriate)? Should it be zero, meaning the index is unknown, or should it correspond to one of the interfaces for the Entity? Thanks very much for your help, Ed ---------------- Ed Harrison Network Convergence Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 Email: eph@dataconnection.com Web:http://www.dataconnection.com From owner-mpls@UU.NET Wed Feb 7 11:39:39 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03194 for ; Wed, 7 Feb 2001 11:39: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 QQkbje12717; Wed, 7 Feb 2001 16:35:50 GMT Received: by mail-control.mail.uu.net id QQkbje28406 for mpls-outgoing; Wed, 7 Feb 2001 16:35: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 QQkbje28401 for ; Wed, 7 Feb 2001 16:35: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 QQkbje03440 for ; Wed, 7 Feb 2001 16:35:10 GMT Received: from mercury.polarisnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQkbje03730 for ; Wed, 7 Feb 2001 16:35:10 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 7 Feb 2001 08:36:54 -0800 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <1N85JQTZ>; Wed, 7 Feb 2001 08:34:06 -0800 Message-ID: From: "Huang, Thomas" To: Serge Maskalik , James_Huang@Mitel.COM Cc: Bora Akyol , mpls@UU.NET Subject: RE: PHP negotiation Date: Wed, 7 Feb 2001 08:34:06 -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 Hello Serge: I am not sure what you really mean when you say you don't see a need for a negotiation mechanism. Let's assume the egress responded to a "PHP" lsr with a null label that it desires to use. Without some type of signaling back to the egress LSR, how does it know if the data packets come later have the labels popped already or not and process them. Maybe Bora's embedded comment is useful. This PHP knowledge has to be passed to peers administratively by operators, which is kind of awarkward. After all, we have rsvp-te/ldp for signaling. why none of these signaling address this issue? /Thomas -----Original Message----- From: Serge Maskalik [mailto:serge@ivmg.net] Sent: Monday, January 29, 2001 10:11 AM To: James_Huang@Mitel.COM Cc: Bora Akyol; mpls@UU.NET Subject: Re: PHP negotiation Believe it or not, this used to be a major inter-operability problem between two major vendors. One major vendor singalled implicit null for all LSPs, _unless_ it was a single hop LSP in which case the explicit null was signalled to preserve the EXP field. The fact that the other vendor treated label 0 as implicit null did not help either ;) I think most folks would agree that php is a good default behavior. If folks want to do L-LSPs and not have to look at DSCPs for the sake of keeping policies equal across the board or want to maintain the encapsulation to the last hop for other reasons, global or per-LSP configuration options could exist. I do not see a need for a negotiation mechanism. - Serge Thus spake James_Huang@Mitel.COM (James_Huang@Mitel.COM): > > > From: James Huang@MITEL on 01/24/2001 02:06 PM PST > I found in sec 6 of RFC 3036 that PHP negotiation is an area of future study for > LDP. Is it also an area of future study for RSVP-TE? Before this negotiation > mechanism becomes available, I presume we can only reply on manual > configuration on a per peer basis. > > -- James Huang > > > > > > Bora Akyol on 01/24/2001 12:33:03 PM > > To: James Huang/USA/Mitel@Mitel > cc: Bora Akyol , mpls@UU.NET > > Subject: Re: PHP negotiation > > > > There is no such mechanism. The assumption is that the network > operator knows how to configure their equipment and they know > their network. > > Bora > > > >>>>> "James" == James Huang writes: > > James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi > James> Bora: Maybe I did not express my concern clear > James> enough. As you said, the LSP setup will fail when > James> the egress LSR assigns an Implicit NULL label to the > James> penultimate hop, if the penultinate hop does not > James> support PHP. So there should be some negotiation > James> mechanism in LDP or RSVP/TE such that an egress > James> router will know not to assign an Implicit NULL label > James> to a penultimate hop that does not support PHP. But > James> I can not find such mechanism in the documents. > > James> -- James Huang > > > > > > James> Bora Akyol on 01/23/2001 08:24:45 > James> PM > > James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET > > James> Subject: PHP negotiation > > > > > James> You should also read the label encapsulation > James> RFC. What happens is that the egress LSR assigns an > James> (...) NULL label (I think it should be Implicit Null) > James> to the penultimate hop, if penultimate hop does not > James> support this, then LSP setup should fail. > > James> There was a LOOONG discussion on this sometime last > James> year. > > James> Some people think this stuff is really clear. I think > James> that it is in about three different RFCs, and someone > James> needs to write a BCP that explains common usage and > James> tricks that network operators that use MPLS should > James> use. > > James> BTW, this question comes up about once a month on the > James> list, maybe we should have an MPLS FAQ. > > James> Bora > > > >>>>> "James" == James Huang writes: > > James> Hi all, The following paragraph is from Section > James> 3.16. (Penultimate Hop Popping) of RFC3031. > > > James> "Initial label distribution protocol negotiations > James> MUST allow each LSR to determine whether its > James> neighboring LSRS are capable of popping the label > James> stack. A LSR MUST NOT request a label distribution > James> peer to pop the label stack unless it is capable of > James> doing so." > > James> However, I can not find any mechanism in LDP/CR-LDP > James> or RSVP-TE to accomplish this PHP negotiation. > > James> Am I missing something here? > > > > James> -- James Huang > > > > > > > > > > > From owner-mpls@UU.NET Wed Feb 7 12:45:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04624 for ; Wed, 7 Feb 2001 12:45: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 QQkbji28236; Wed, 7 Feb 2001 17:43:01 GMT Received: by mail-control.mail.uu.net id QQkbji18939 for mpls-outgoing; Wed, 7 Feb 2001 17:42:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbji18928 for ; Wed, 7 Feb 2001 17:42:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbji06811 for ; Wed, 7 Feb 2001 17:41:52 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbji11300 for ; Wed, 7 Feb 2001 17:41:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA15016 for mpls@uu.net; Wed, 7 Feb 2001 12:41:50 -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 QQkbji18759 for ; Wed, 7 Feb 2001 17:41:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbjg03999 for ; Wed, 7 Feb 2001 17:00:44 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 QQkbjg07821 for ; Wed, 7 Feb 2001 17:00:44 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 JAA16458; Wed, 7 Feb 2001 09:00:35 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <11AQH82Z>; Wed, 7 Feb 2001 09:00:35 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A46@BBY1EXM01> From: Shahram Davari To: "'Mahadevan Iyer'" , mpls@UU.NET Subject: RE: VC merge question Date: Wed, 7 Feb 2001 09:03:16 -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 Yes. This kind of LSP merge is similar to VP-merge in ATM. Check RFC3035. -Shahram > -----Original Message----- > From: Mahadevan Iyer [mailto:iyermahadevan@yahoo.com] > Sent: Wednesday, February 07, 2001 12:24 AM > To: mpls@UU.NET > Subject: VC merge question > > > Hello, > > When using VC merge to support heirarchial LSP type > capabilities is it possible to stack more then 2 > levels(i.e. reuse the VPI for the outer VC). > > If this has been discussed before, please send me > a pointer to the thread > > Thanks > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Auctions - Buy the things you want at great prices. > http://auctions.yahoo.com/ > From owner-mpls@UU.NET Wed Feb 7 13:09:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05171 for ; Wed, 7 Feb 2001 13:09: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 QQkbjk19100; Wed, 7 Feb 2001 18:07:20 GMT Received: by mail-control.mail.uu.net id QQkbjk04032 for mpls-outgoing; Wed, 7 Feb 2001 18:06:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbjk04016 for ; Wed, 7 Feb 2001 18:06:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbjk05333 for ; Wed, 7 Feb 2001 18:05:37 GMT Received: from mercury.polarisnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQkbjk17343 for ; Wed, 7 Feb 2001 18:05:36 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 7 Feb 2001 10:07:21 -0800 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <1N85JQV5>; Wed, 7 Feb 2001 10:04:32 -0800 Message-ID: From: "Huang, Thomas" To: djiang1@lucent.com Cc: Serge Maskalik , James_Huang@Mitel.COM, Bora Akyol , mpls@UU.NET Subject: RE: PHP negotiation Date: Wed, 7 Feb 2001 10:04:31 -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 Hello Jane: Thanks for your kind msg. I made an error in confusing you. I meant to say the egress router sends msg with a null label to a PHP router upstream. But your msg still gave useful explanations. I realized that it sounds easy in two lookup scenario you described as well as by others when the upstream LSR did not pop the label as requested. However, when implementing it, i am not sure about it. Let's assume we have only 1 level label. At egress we receive eithter labelled or a l3 packet if the previous lsr is capable of popping. The egress router has to program the fabric before the data traffic comes. If it's deterministic, the egress can be programmed just to do one lookup to forward the l3 packet. Otherwise, at least 2 lookups needed... I guess it's a matter of efficiency. both rsvp and ldp can signal the upstream lsr to do penultimate hop popping. It appears to me PHPoping is not that difficult. Why the spec says a LSR may or may not capable of doing it? The harder thing is to do the two lookups if the downstream egress lsr does not know if the packet has had its label popped.. /Thomas -----Original Message----- From: djiang1@lucent.com [mailto:djiang1@lucent.com] Sent: Wednesday, February 07, 2001 9:33 AM To: Huang, Thomas Cc: Serge Maskalik; James_Huang@Mitel.COM; Bora Akyol; mpls@UU.NET Subject: RE: PHP negotiation Hi Thomas, Actually, RFC3031 implied that the penultimate hop popping should only be requested by the LSP egress router, rather than LSP egress router responding to a request by its upstream LSP peer. At the time egress LSP router receives a packet, it will either have a shim header or only the IP header. If it still have a shim header, by looking up the label in the ILM table, it will know whether this router is an egress router (As we know the so mentioned egress LSP router is only egress relative to the top of the label stack. After the top label being popped, the previous LER is now a regular LSR for the new top label.) If it is, then it means that no PHP has been done and the top label must first been popped and a second round of label/IP header lookup needs to be taken care. If it is not an egress router, then PHP has been done. So, it is not hard to distinguish whether PHP has been done or not. However, not all routers can do penultimate hop popping though it is powerful to have penultimate hop popping. A signalling mechanism is needed for a LER to ask its upstream LSR to do PHP. Thanks, Jane D. Jiang "Huang, Thomas" @UU.NET on 02/07/2001 11:34:06 AM Sent by: owner-mpls@UU.NET To: Serge Maskalik , James_Huang@Mitel.COM cc: Bora Akyol , mpls@UU.NET Subject: RE: PHP negotiation Hello Serge: I am not sure what you really mean when you say you don't see a need for a negotiation mechanism. Let's assume the egress responded to a "PHP" lsr with a null label that it desires to use. Without some type of signaling back to the egress LSR, how does it know if the data packets come later have the labels popped already or not and process them. Maybe Bora's embedded comment is useful. This PHP knowledge has to be passed to peers administratively by operators, which is kind of awarkward. After all, we have rsvp-te/ldp for signaling. why none of these signaling address this issue? /Thomas -----Original Message----- From: Serge Maskalik [mailto:serge@ivmg.net] Sent: Monday, January 29, 2001 10:11 AM To: James_Huang@Mitel.COM Cc: Bora Akyol; mpls@UU.NET Subject: Re: PHP negotiation Believe it or not, this used to be a major inter-operability problem between two major vendors. One major vendor singalled implicit null for all LSPs, _unless_ it was a single hop LSP in which case the explicit null was signalled to preserve the EXP field. The fact that the other vendor treated label 0 as implicit null did not help either ;) I think most folks would agree that php is a good default behavior. If folks want to do L-LSPs and not have to look at DSCPs for the sake of keeping policies equal across the board or want to maintain the encapsulation to the last hop for other reasons, global or per-LSP configuration options could exist. I do not see a need for a negotiation mechanism. - Serge Thus spake James_Huang@Mitel.COM (James_Huang@Mitel.COM): > > > From: James Huang@MITEL on 01/24/2001 02:06 PM PST > I found in sec 6 of RFC 3036 that PHP negotiation is an area of future study for > LDP. Is it also an area of future study for RSVP-TE? Before this negotiation > mechanism becomes available, I presume we can only reply on manual > configuration on a per peer basis. > > -- James Huang > > > > > > Bora Akyol on 01/24/2001 12:33:03 PM > > To: James Huang/USA/Mitel@Mitel > cc: Bora Akyol , mpls@UU.NET > > Subject: Re: PHP negotiation > > > > There is no such mechanism. The assumption is that the network > operator knows how to configure their equipment and they know > their network. > > Bora > > > >>>>> "James" == James Huang writes: > > James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi > James> Bora: Maybe I did not express my concern clear > James> enough. As you said, the LSP setup will fail when > James> the egress LSR assigns an Implicit NULL label to the > James> penultimate hop, if the penultinate hop does not > James> support PHP. So there should be some negotiation > James> mechanism in LDP or RSVP/TE such that an egress > James> router will know not to assign an Implicit NULL label > James> to a penultimate hop that does not support PHP. But > James> I can not find such mechanism in the documents. > > James> -- James Huang > > > > > > James> Bora Akyol on 01/23/2001 08:24:45 > James> PM > > James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET > > James> Subject: PHP negotiation > > > > > James> You should also read the label encapsulation > James> RFC. What happens is that the egress LSR assigns an > James> (...) NULL label (I think it should be Implicit Null) > James> to the penultimate hop, if penultimate hop does not > James> support this, then LSP setup should fail. > > James> There was a LOOONG discussion on this sometime last > James> year. > > James> Some people think this stuff is really clear. I think > James> that it is in about three different RFCs, and someone > James> needs to write a BCP that explains common usage and > James> tricks that network operators that use MPLS should > James> use. > > James> BTW, this question comes up about once a month on the > James> list, maybe we should have an MPLS FAQ. > > James> Bora > > > >>>>> "James" == James Huang writes: > > James> Hi all, The following paragraph is from Section > James> 3.16. (Penultimate Hop Popping) of RFC3031. > > > James> "Initial label distribution protocol negotiations > James> MUST allow each LSR to determine whether its > James> neighboring LSRS are capable of popping the label > James> stack. A LSR MUST NOT request a label distribution > James> peer to pop the label stack unless it is capable of > James> doing so." > > James> However, I can not find any mechanism in LDP/CR-LDP > James> or RSVP-TE to accomplish this PHP negotiation. > > James> Am I missing something here? > > > > James> -- James Huang > > > > > > > > > > > From owner-mpls@UU.NET Wed Feb 7 13:18:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05431 for ; Wed, 7 Feb 2001 13: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 QQkbjl19471; Wed, 7 Feb 2001 18:15:46 GMT Received: by mail-control.mail.uu.net id QQkbjl05663 for mpls-outgoing; Wed, 7 Feb 2001 18:15:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbjk05536 for ; Wed, 7 Feb 2001 18:14:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbjk03501 for ; Wed, 7 Feb 2001 18:14:00 GMT Received: from smtp.snet.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.snet.net [204.60.6.55]) id QQkbjk08175 for ; Wed, 7 Feb 2001 18:14:00 GMT Received: from DAVESC600 (wtrb-sh6-port136.snet.net [204.60.56.136]) by smtp.snet.net (8.11.1/8.11.1/SNET-mx-1.4/D-1.10/O-1.7) with SMTP id f17IDvL14387 for ; Wed, 7 Feb 2001 13:13:58 -0500 (EST) Reply-To: From: "Dave Danenberg" To: "'mpls@uu.net'" Subject: MPLS LSR MIB usage question: Label Stack Table Date: Wed, 7 Feb 2001 13:15:04 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC031240@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C09107.FCC82E70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0B15A9D8@nl0006exch002u.nl.lucent.com> Importance: Normal 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_0012_01C09107.FCC82E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Can someone enlighten me? By description, the label stack provides for pushing multiple labels (beneath the top label) onto a packet. However, it's not entirely clear to me how the Primary and Secondary indexes are used to create a list of labels. I would think that there would be 1 primary index per cross-connect, the secondary index would then be used to traverse the list (based on the same primary index). The reason I'm not sure is the description under mplsLabelStackIndexNext which says: "This object contains an appropriate value to be used for mplsLabelStackIndex when creating entries in the mplsLabelStackTable." To better describe my understanding, it would say: "This object contains an appropriate value to be used for mplsLabelStackIndex (primary index) when creating a new set of entries in the mplsLabelStackTable." Thoughts? Thanx, Dave ------=_NextPart_000_0012_01C09107.FCC82E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS LSR MIB usage question: Label Stack Table

Can someone enlighten me?

By description, the label stack provides for pushing = multiple labels (beneath the top label) onto a packet. However, it's not = entirely clear to me how the Primary and Secondary indexes are used to = create a list of labels. I would think that there would be 1 primary = index per cross-connect, the secondary index would then be used to = traverse the list (based on the same primary index). The reason I'm not = sure is the description under mplsLabelStackIndexNext which = says:

"This object contains an appropriate value to be = used for mplsLabelStackIndex when creating entries in the = mplsLabelStackTable."

To better describe my understanding, it would = say:

"This object contains an appropriate value to be = used for mplsLabelStackIndex (primary index) when creating a new set of = entries in the mplsLabelStackTable."

Thoughts?

Thanx, Dave

------=_NextPart_000_0012_01C09107.FCC82E70-- From owner-mpls@UU.NET Wed Feb 7 13:35:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06025 for ; Wed, 7 Feb 2001 13:35:02 -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 QQkbjm24539; Wed, 7 Feb 2001 18:32:33 GMT Received: by mail-control.mail.uu.net id QQkbjm07621 for mpls-outgoing; Wed, 7 Feb 2001 18:31: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 QQkbjm07608 for ; Wed, 7 Feb 2001 18:31:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbjl19432 for ; Wed, 7 Feb 2001 18:26:23 GMT Received: from smtp.snet.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.snet.net [204.60.6.55]) id QQkbjl27304 for ; Wed, 7 Feb 2001 18:26:20 GMT Received: from DAVESC600 (wtrb-sh6-port136.snet.net [204.60.56.136]) by smtp.snet.net (8.11.1/8.11.1/SNET-mx-1.4/D-1.10/O-1.7) with SMTP id f17IQHL21180 for ; Wed, 7 Feb 2001 13:26:18 -0500 (EST) Reply-To: From: "Dave Danenberg" To: "'mpls@uu.net'" Subject: Draft IETF MPLS TE MIB 05 usage question: Tunnel Table Date: Wed, 7 Feb 2001 13:27:24 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC031241@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C09109.B5EBDA40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C09109.B5EBDA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Question on the Tunnel Instance. By description, the Tunnel Table provides for multiple tunnel instances - in the case where you have backup or parallel tunnels. When using multiple instances, I would think the TunnelIndex would stay the same value while the TunnelInstance increments (1, 2, and so on). The reason I'm not sure that this is right is the description under mplsTunnelIndexNext which says: "This object contains the next appropriate value to be used for mplsTunnelIndex when creating entries in mplsTunnelTable." To better describe my understanding, it would say: "This object contains the next appropriate value to be used for mplsTunnelIndex when creating an entry (or, in the case of multiple instances, a set of entries ) in the mplsTunnelTable." Help? Thanx, Dave Dave Danenberg VP of Engineering Litchfield Communications Inc. www.litchfieldcomm.com Princeton Building East 76 Westbury Park Rd Watertown CT 06795 USA Tel: (860) 945 1573 x3180 Fax: (860) 945 1578 ------=_NextPart_000_0018_01C09109.B5EBDA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft IETF MPLS TE MIB 05 usage question: Tunnel Table

Question on the Tunnel Instance.

By description, the Tunnel Table provides for multiple = tunnel instances - in the case where you have backup or parallel = tunnels. When using multiple instances, I would think the TunnelIndex = would stay the same value while the TunnelInstance increments (1, 2, and = so on). The reason I'm not sure that this is right is the description = under mplsTunnelIndexNext which says:

"This object contains the next appropriate value = to be used for mplsTunnelIndex when creating entries in = mplsTunnelTable."

To better describe my understanding, it would = say:

"This object contains the next appropriate value = to be used for mplsTunnelIndex when creating an entry (or, in the case = of multiple instances, a set of entries ) in the = mplsTunnelTable."


Help?
Thanx, Dave

Dave Danenberg
VP of Engineering
Litchfield Communications Inc.
www.litchfieldcomm.com

Princeton Building East
76 Westbury Park Rd
Watertown CT 06795 USA

Tel: (860) 945 1573 x3180
Fax: (860) 945 1578

------=_NextPart_000_0018_01C09109.B5EBDA40-- From owner-mpls@UU.NET Wed Feb 7 14:25:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07227 for ; Wed, 7 Feb 2001 14:25: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 QQkbjp01835; Wed, 7 Feb 2001 19:22:59 GMT Received: by mail-control.mail.uu.net id QQkbjp25798 for mpls-outgoing; Wed, 7 Feb 2001 19:22:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbjp25775 for ; Wed, 7 Feb 2001 19:21:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbjp17943 for ; Wed, 7 Feb 2001 19:20:37 GMT From: djiang1@lucent.com 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 QQkbjp26909 for ; Wed, 7 Feb 2001 19:20:36 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 OAA23405 for ; Wed, 7 Feb 2001 14:20:35 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA23222; Wed, 7 Feb 2001 14:20:31 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA00459; Wed, 7 Feb 2001 14:20:26 -0500 (EST) Subject: RE: PHP negotiation To: "Huang, Thomas" Cc: djiang1@lucent.com, Serge Maskalik , James_Huang@Mitel.COM, Bora Akyol , mpls@UU.NET Date: Wed, 7 Feb 2001 14:16:59 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/07/2001 14:17:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Thomas, I understand the problem you mentioned when PHP is not deterministic. The LER has to be prepared to deal with both situations, with or without a label. If you think that is too much for your LER, you can decide just not to ask for PHP across the platform. That is what we can be sure. PHP cannot always be done. In case of IP/ATM, the labels are carried in the VPI/VCI field of the ATM header. ATM switches cannot remove the ATM header to pass the IP packet to the LER. Sometimes, processing speed at one router can be a concern that prevent it from peeling off one label layer. So, requiring all routers be capable of doing PHP is not possible. LER will only do two lookups if PHP is not done and LER will know whether two lookups is needed when it does the first one(if there is a label). Session 3.16 of RFC3031 gives the detail. Regards, Jane "Huang, Thomas" on 02/07/2001 01:04:31 PM To: djiang1@lucent.com cc: Serge Maskalik , James_Huang@Mitel.COM, Bora Akyol , mpls@UU.NET Subject: RE: PHP negotiation Hello Jane: Thanks for your kind msg. I made an error in confusing you. I meant to say the egress router sends msg with a null label to a PHP router upstream. But your msg still gave useful explanations. I realized that it sounds easy in two lookup scenario you described as well as by others when the upstream LSR did not pop the label as requested. However, when implementing it, i am not sure about it. Let's assume we have only 1 level label. At egress we receive eithter labelled or a l3 packet if the previous lsr is capable of popping. The egress router has to program the fabric before the data traffic comes. If it's deterministic, the egress can be programmed just to do one lookup to forward the l3 packet. Otherwise, at least 2 lookups needed... I guess it's a matter of efficiency. both rsvp and ldp can signal the upstream lsr to do penultimate hop popping. It appears to me PHPoping is not that difficult. Why the spec says a LSR may or may not capable of doing it? The harder thing is to do the two lookups if the downstream egress lsr does not know if the packet has had its label popped.. /Thomas -----Original Message----- From: djiang1@lucent.com [mailto:djiang1@lucent.com] Sent: Wednesday, February 07, 2001 9:33 AM To: Huang, Thomas Cc: Serge Maskalik; James_Huang@Mitel.COM; Bora Akyol; mpls@UU.NET Subject: RE: PHP negotiation Hi Thomas, Actually, RFC3031 implied that the penultimate hop popping should only be requested by the LSP egress router, rather than LSP egress router responding to a request by its upstream LSP peer. At the time egress LSP router receives a packet, it will either have a shim header or only the IP header. If it still have a shim header, by looking up the label in the ILM table, it will know whether this router is an egress router (As we know the so mentioned egress LSP router is only egress relative to the top of the label stack. After the top label being popped, the previous LER is now a regular LSR for the new top label.) If it is, then it means that no PHP has been done and the top label must first been popped and a second round of label/IP header lookup needs to be taken care. If it is not an egress router, then PHP has been done. So, it is not hard to distinguish whether PHP has been done or not. However, not all routers can do penultimate hop popping though it is powerful to have penultimate hop popping. A signalling mechanism is needed for a LER to ask its upstream LSR to do PHP. Thanks, Jane D. Jiang "Huang, Thomas" @UU.NET on 02/07/2001 11:34:06 AM Sent by: owner-mpls@UU.NET To: Serge Maskalik , James_Huang@Mitel.COM cc: Bora Akyol , mpls@UU.NET Subject: RE: PHP negotiation Hello Serge: I am not sure what you really mean when you say you don't see a need for a negotiation mechanism. Let's assume the egress responded to a "PHP" lsr with a null label that it desires to use. Without some type of signaling back to the egress LSR, how does it know if the data packets come later have the labels popped already or not and process them. Maybe Bora's embedded comment is useful. This PHP knowledge has to be passed to peers administratively by operators, which is kind of awarkward. After all, we have rsvp-te/ldp for signaling. why none of these signaling address this issue? /Thomas -----Original Message----- From: Serge Maskalik [mailto:serge@ivmg.net] Sent: Monday, January 29, 2001 10:11 AM To: James_Huang@Mitel.COM Cc: Bora Akyol; mpls@UU.NET Subject: Re: PHP negotiation Believe it or not, this used to be a major inter-operability problem between two major vendors. One major vendor singalled implicit null for all LSPs, _unless_ it was a single hop LSP in which case the explicit null was signalled to preserve the EXP field. The fact that the other vendor treated label 0 as implicit null did not help either ;) I think most folks would agree that php is a good default behavior. If folks want to do L-LSPs and not have to look at DSCPs for the sake of keeping policies equal across the board or want to maintain the encapsulation to the last hop for other reasons, global or per-LSP configuration options could exist. I do not see a need for a negotiation mechanism. - Serge Thus spake James_Huang@Mitel.COM (James_Huang@Mitel.COM): > > > From: James Huang@MITEL on 01/24/2001 02:06 PM PST > I found in sec 6 of RFC 3036 that PHP negotiation is an area of future study for > LDP. Is it also an area of future study for RSVP-TE? Before this negotiation > mechanism becomes available, I presume we can only reply on manual > configuration on a per peer basis. > > -- James Huang > > > > > > Bora Akyol on 01/24/2001 12:33:03 PM > > To: James Huang/USA/Mitel@Mitel > cc: Bora Akyol , mpls@UU.NET > > Subject: Re: PHP negotiation > > > > There is no such mechanism. The assumption is that the network > operator knows how to configure their equipment and they know > their network. > > Bora > > > >>>>> "James" == James Huang writes: > > James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi > James> Bora: Maybe I did not express my concern clear > James> enough. As you said, the LSP setup will fail when > James> the egress LSR assigns an Implicit NULL label to the > James> penultimate hop, if the penultinate hop does not > James> support PHP. So there should be some negotiation > James> mechanism in LDP or RSVP/TE such that an egress > James> router will know not to assign an Implicit NULL label > James> to a penultimate hop that does not support PHP. But > James> I can not find such mechanism in the documents. > > James> -- James Huang > > > > > > James> Bora Akyol on 01/23/2001 08:24:45 > James> PM > > James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET > > James> Subject: PHP negotiation > > > > > James> You should also read the label encapsulation > James> RFC. What happens is that the egress LSR assigns an > James> (...) NULL label (I think it should be Implicit Null) > James> to the penultimate hop, if penultimate hop does not > James> support this, then LSP setup should fail. > > James> There was a LOOONG discussion on this sometime last > James> year. > > James> Some people think this stuff is really clear. I think > James> that it is in about three different RFCs, and someone > James> needs to write a BCP that explains common usage and > James> tricks that network operators that use MPLS should > James> use. > > James> BTW, this question comes up about once a month on the > James> list, maybe we should have an MPLS FAQ. > > James> Bora > > > >>>>> "James" == James Huang writes: > > James> Hi all, The following paragraph is from Section > James> 3.16. (Penultimate Hop Popping) of RFC3031. > > > James> "Initial label distribution protocol negotiations > James> MUST allow each LSR to determine whether its > James> neighboring LSRS are capable of popping the label > James> stack. A LSR MUST NOT request a label distribution > James> peer to pop the label stack unless it is capable of > James> doing so." > > James> However, I can not find any mechanism in LDP/CR-LDP > James> or RSVP-TE to accomplish this PHP negotiation. > > James> Am I missing something here? > > > > James> -- James Huang > > > > > > > > > > > From owner-mpls@UU.NET Wed Feb 7 14:27:58 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07261 for ; Wed, 7 Feb 2001 14:27: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 QQkbjp04942; Wed, 7 Feb 2001 19:25:24 GMT Received: by mail-control.mail.uu.net id QQkbjp26051 for mpls-outgoing; Wed, 7 Feb 2001 19:24: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 QQkbjp26030 for ; Wed, 7 Feb 2001 19:24: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 QQkbjp13593 for ; Wed, 7 Feb 2001 19:15:29 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbjp09173 for ; Wed, 7 Feb 2001 19:15:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA23977 for mpls@uu.net; Wed, 7 Feb 2001 14:15:27 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbjp24892 for ; Wed, 7 Feb 2001 19:15:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbjo00512 for ; Wed, 7 Feb 2001 19:13:23 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 QQkbjo21207 for ; Wed, 7 Feb 2001 19:13:22 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 LAA19481; Wed, 7 Feb 2001 11:12:00 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <11AQ2AYR>; Wed, 7 Feb 2001 11:14:38 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A4A@BBY1EXM01> From: Shahram Davari To: "'Huang, Thomas'" , djiang1@lucent.com Cc: Serge Maskalik , James_Huang@Mitel.COM, Bora Akyol , mpls@UU.NET Subject: RE: PHP negotiation Date: Wed, 7 Feb 2001 11:14:38 -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 Thomas, 1)PHP is not as straight forward as it looks. PHP is different from terminating an LSP tunnel, because in PHP you need to route based on top label and then pop that label, while in LSP termination, you need to pop and then route based on lower label or IP header. If the MPLS processing is based on a pure hardware solution, then being able to do LSP termination does not mean that you can do PHP. 2) If the penultimate LSR can't do PHP, it sends a RSVPErr message and the LSP won't be established. So there is no way to receive a non-popped packet for the LSP that PHP was requested for. You either receive a popped packet for that LSP or you don't receive any packet at all. 3) There is no need to differentiate between penultimate hop popped and non-popped packets. Because the egress always processes the top label, and if the top label indicates a tunnel termination then another lookup must be done. This holds even if an egress LSR randomly asks for PHP. Yours, -Shahram > -----Original Message----- > From: Huang, Thomas [mailto:THuang@PolarisNetworks.com] > Sent: Wednesday, February 07, 2001 1:05 PM > To: djiang1@lucent.com > Cc: Serge Maskalik; James_Huang@Mitel.COM; Bora Akyol; mpls@UU.NET > Subject: RE: PHP negotiation > > > Hello Jane: > Thanks for your kind msg. I made an error in confusing you. I > meant to say > the egress router sends msg with a null label to a PHP router > upstream. > > But your msg still gave useful explanations. > > I realized that it sounds easy in two lookup scenario you > described as well > as by others when the upstream LSR did not pop the label as requested. > > However, when implementing it, i am not sure about it. Let's > assume we have > only 1 level label. At egress we receive eithter labelled or > a l3 packet if > the previous lsr is capable of popping. The egress router has > to program the > fabric before the data traffic comes. If it's deterministic, > the egress can > be programmed just to do one lookup to forward the l3 packet. > Otherwise, at > least 2 lookups needed... > > I guess it's a matter of efficiency. both rsvp and ldp can signal the > upstream lsr to do penultimate hop popping. > > It appears to me PHPoping is not that difficult. Why the spec > says a LSR may > or may not capable of doing it? The harder thing is to do the > two lookups if > the downstream egress lsr does not know if the packet has had > its label > popped.. > > /Thomas > > > > -----Original Message----- > From: djiang1@lucent.com [mailto:djiang1@lucent.com] > Sent: Wednesday, February 07, 2001 9:33 AM > To: Huang, Thomas > Cc: Serge Maskalik; James_Huang@Mitel.COM; Bora Akyol; mpls@UU.NET > Subject: RE: PHP negotiation > > > > Hi Thomas, > > Actually, RFC3031 implied that the penultimate hop popping > should only be > requested by the LSP egress router, rather than LSP egress router > responding to a request by its upstream LSP peer. > At the time egress LSP router receives a packet, it will > either have a shim > header or only the IP header. If it still have a shim > header, by looking > up the label in the ILM table, it will know whether this router is an > egress router (As we know the so mentioned egress LSP router > is only egress > relative to the top of the label stack. After the top label > being popped, > the previous LER is now a regular LSR for the new top label.) > If it is, > then it means that no PHP has been done and the top label > must first been > popped and a second round of label/IP header lookup needs to > be taken care. > If it is not an egress router, then PHP has been done. So, > it is not > hard to distinguish whether PHP has been done or not. > > However, not all routers can do penultimate hop popping though it is > powerful to have penultimate hop popping. > > A signalling mechanism is needed for a LER to ask its > upstream LSR to do > PHP. > > Thanks, > Jane D. Jiang > > > > > "Huang, Thomas" @UU.NET on > 02/07/2001 11:34:06 > AM > > Sent by: owner-mpls@UU.NET > > > To: Serge Maskalik , James_Huang@Mitel.COM > cc: Bora Akyol , mpls@UU.NET > Subject: RE: PHP negotiation > > > Hello Serge: > I am not sure what you really mean when you say you don't see > a need for a > negotiation mechanism. > > Let's assume the egress responded to a "PHP" lsr with a null > label that it > desires to use. Without some type of signaling back to the > egress LSR, how > does it know if the data packets come later have the labels > popped already > or not and process them. > > Maybe Bora's embedded comment is useful. This PHP knowledge has to be > passed > to peers administratively by operators, which is kind of > awarkward. After > all, we have rsvp-te/ldp for signaling. why none of these > signaling address > this issue? > > /Thomas > > -----Original Message----- > From: Serge Maskalik [mailto:serge@ivmg.net] > Sent: Monday, January 29, 2001 10:11 AM > To: James_Huang@Mitel.COM > Cc: Bora Akyol; mpls@UU.NET > Subject: Re: PHP negotiation > > > > Believe it or not, this used to be a major inter-operability > problem between two major vendors. One major vendor singalled > implicit null for all LSPs, _unless_ it was a single hop LSP > in which case the explicit null was signalled to preserve the > EXP field. The fact that the other vendor treated label 0 as > implicit null did not help either ;) > > I think most folks would agree that php is a good default > behavior. If folks want to do L-LSPs and not have to look at > DSCPs for the sake of keeping policies equal across the board > or want to maintain the encapsulation to the last hop for other > reasons, global or per-LSP configuration options could exist. > > I do not see a need for a negotiation mechanism. > > > - Serge > > Thus spake James_Huang@Mitel.COM (James_Huang@Mitel.COM): > > > > > > > From: James Huang@MITEL on 01/24/2001 02:06 PM PST > > I found in sec 6 of RFC 3036 that PHP negotiation is an > area of future > study for > > LDP. Is it also an area of future study for RSVP-TE? Before this > negotiation > > mechanism becomes available, I presume we can only reply on manual > > configuration on a per peer basis. > > > > -- James Huang > > > > > > > > > > > > Bora Akyol on 01/24/2001 12:33:03 PM > > > > To: James Huang/USA/Mitel@Mitel > > cc: Bora Akyol , mpls@UU.NET > > > > Subject: Re: PHP negotiation > > > > > > > > There is no such mechanism. The assumption is that the network > > operator knows how to configure their equipment and they know > > their network. > > > > Bora > > > > > > >>>>> "James" == James Huang writes: > > > > James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi > > James> Bora: Maybe I did not express my concern clear > > James> enough. As you said, the LSP setup will fail when > > James> the egress LSR assigns an Implicit NULL label to the > > James> penultimate hop, if the penultinate hop does not > > James> support PHP. So there should be some negotiation > > James> mechanism in LDP or RSVP/TE such that an egress > > James> router will know not to assign an Implicit NULL label > > James> to a penultimate hop that does not support PHP. But > > James> I can not find such mechanism in the documents. > > > > James> -- James Huang > > > > > > > > > > > > James> Bora Akyol on 01/23/2001 08:24:45 > > James> PM > > > > James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET > > > > James> Subject: PHP negotiation > > > > > > > > > > James> You should also read the label encapsulation > > James> RFC. What happens is that the egress LSR assigns an > > James> (...) NULL label (I think it should be Implicit Null) > > James> to the penultimate hop, if penultimate hop does not > > James> support this, then LSP setup should fail. > > > > James> There was a LOOONG discussion on this sometime last > > James> year. > > > > James> Some people think this stuff is really clear. I think > > James> that it is in about three different RFCs, and someone > > James> needs to write a BCP that explains common usage and > > James> tricks that network operators that use MPLS should > > James> use. > > > > James> BTW, this question comes up about once a month on the > > James> list, maybe we should have an MPLS FAQ. > > > > James> Bora > > > > > > >>>>> "James" == James Huang writes: > > > > James> Hi all, The following paragraph is from Section > > James> 3.16. (Penultimate Hop Popping) of RFC3031. > > > > > > James> "Initial label distribution protocol negotiations > > James> MUST allow each LSR to determine whether its > > James> neighboring LSRS are capable of popping the label > > James> stack. A LSR MUST NOT request a label distribution > > James> peer to pop the label stack unless it is capable of > > James> doing so." > > > > James> However, I can not find any mechanism in LDP/CR-LDP > > James> or RSVP-TE to accomplish this PHP negotiation. > > > > James> Am I missing something here? > > > > > > > > James> -- James Huang > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Wed Feb 7 15:26:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08244 for ; Wed, 7 Feb 2001 15:26: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 QQkbjt05599; Wed, 7 Feb 2001 20:22:57 GMT Received: by mail-control.mail.uu.net id QQkbjt15344 for mpls-outgoing; Wed, 7 Feb 2001 20:22: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 QQkbjt15333 for ; Wed, 7 Feb 2001 20:22: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 QQkbji24154 for ; Wed, 7 Feb 2001 17:36:15 GMT From: djiang1@lucent.com Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkbji18674 for ; Wed, 7 Feb 2001 17:36:12 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA07895 for ; Wed, 7 Feb 2001 12:36:12 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA07882; Wed, 7 Feb 2001 12:36:11 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA13695; Wed, 7 Feb 2001 12:36:09 -0500 (EST) Subject: RE: PHP negotiation To: "Huang, Thomas" Cc: Serge Maskalik , James_Huang@Mitel.COM, Bora Akyol , mpls@UU.NET Date: Wed, 7 Feb 2001 12:32:43 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/07/2001 12:32:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Thomas, Actually, RFC3031 implied that the penultimate hop popping should only be requested by the LSP egress router, rather than LSP egress router responding to a request by its upstream LSP peer. At the time egress LSP router receives a packet, it will either have a shim header or only the IP header. If it still have a shim header, by looking up the label in the ILM table, it will know whether this router is an egress router (As we know the so mentioned egress LSP router is only egress relative to the top of the label stack. After the top label being popped, the previous LER is now a regular LSR for the new top label.) If it is, then it means that no PHP has been done and the top label must first been popped and a second round of label/IP header lookup needs to be taken care. If it is not an egress router, then PHP has been done. So, it is not hard to distinguish whether PHP has been done or not. However, not all routers can do penultimate hop popping though it is powerful to have penultimate hop popping. A signalling mechanism is needed for a LER to ask its upstream LSR to do PHP. Thanks, Jane D. Jiang "Huang, Thomas" @UU.NET on 02/07/2001 11:34:06 AM Sent by: owner-mpls@UU.NET To: Serge Maskalik , James_Huang@Mitel.COM cc: Bora Akyol , mpls@UU.NET Subject: RE: PHP negotiation Hello Serge: I am not sure what you really mean when you say you don't see a need for a negotiation mechanism. Let's assume the egress responded to a "PHP" lsr with a null label that it desires to use. Without some type of signaling back to the egress LSR, how does it know if the data packets come later have the labels popped already or not and process them. Maybe Bora's embedded comment is useful. This PHP knowledge has to be passed to peers administratively by operators, which is kind of awarkward. After all, we have rsvp-te/ldp for signaling. why none of these signaling address this issue? /Thomas -----Original Message----- From: Serge Maskalik [mailto:serge@ivmg.net] Sent: Monday, January 29, 2001 10:11 AM To: James_Huang@Mitel.COM Cc: Bora Akyol; mpls@UU.NET Subject: Re: PHP negotiation Believe it or not, this used to be a major inter-operability problem between two major vendors. One major vendor singalled implicit null for all LSPs, _unless_ it was a single hop LSP in which case the explicit null was signalled to preserve the EXP field. The fact that the other vendor treated label 0 as implicit null did not help either ;) I think most folks would agree that php is a good default behavior. If folks want to do L-LSPs and not have to look at DSCPs for the sake of keeping policies equal across the board or want to maintain the encapsulation to the last hop for other reasons, global or per-LSP configuration options could exist. I do not see a need for a negotiation mechanism. - Serge Thus spake James_Huang@Mitel.COM (James_Huang@Mitel.COM): > > > From: James Huang@MITEL on 01/24/2001 02:06 PM PST > I found in sec 6 of RFC 3036 that PHP negotiation is an area of future study for > LDP. Is it also an area of future study for RSVP-TE? Before this negotiation > mechanism becomes available, I presume we can only reply on manual > configuration on a per peer basis. > > -- James Huang > > > > > > Bora Akyol on 01/24/2001 12:33:03 PM > > To: James Huang/USA/Mitel@Mitel > cc: Bora Akyol , mpls@UU.NET > > Subject: Re: PHP negotiation > > > > There is no such mechanism. The assumption is that the network > operator knows how to configure their equipment and they know > their network. > > Bora > > > >>>>> "James" == James Huang writes: > > James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi > James> Bora: Maybe I did not express my concern clear > James> enough. As you said, the LSP setup will fail when > James> the egress LSR assigns an Implicit NULL label to the > James> penultimate hop, if the penultinate hop does not > James> support PHP. So there should be some negotiation > James> mechanism in LDP or RSVP/TE such that an egress > James> router will know not to assign an Implicit NULL label > James> to a penultimate hop that does not support PHP. But > James> I can not find such mechanism in the documents. > > James> -- James Huang > > > > > > James> Bora Akyol on 01/23/2001 08:24:45 > James> PM > > James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET > > James> Subject: PHP negotiation > > > > > James> You should also read the label encapsulation > James> RFC. What happens is that the egress LSR assigns an > James> (...) NULL label (I think it should be Implicit Null) > James> to the penultimate hop, if penultimate hop does not > James> support this, then LSP setup should fail. > > James> There was a LOOONG discussion on this sometime last > James> year. > > James> Some people think this stuff is really clear. I think > James> that it is in about three different RFCs, and someone > James> needs to write a BCP that explains common usage and > James> tricks that network operators that use MPLS should > James> use. > > James> BTW, this question comes up about once a month on the > James> list, maybe we should have an MPLS FAQ. > > James> Bora > > > >>>>> "James" == James Huang writes: > > James> Hi all, The following paragraph is from Section > James> 3.16. (Penultimate Hop Popping) of RFC3031. > > > James> "Initial label distribution protocol negotiations > James> MUST allow each LSR to determine whether its > James> neighboring LSRS are capable of popping the label > James> stack. A LSR MUST NOT request a label distribution > James> peer to pop the label stack unless it is capable of > James> doing so." > > James> However, I can not find any mechanism in LDP/CR-LDP > James> or RSVP-TE to accomplish this PHP negotiation. > > James> Am I missing something here? > > > > James> -- James Huang > > > > > > > > > > > From owner-mpls@UU.NET Wed Feb 7 15:37:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08415 for ; Wed, 7 Feb 2001 15:37: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 QQkbju25149; Wed, 7 Feb 2001 20:35:59 GMT Received: by mail-control.mail.uu.net id QQkbju17472 for mpls-outgoing; Wed, 7 Feb 2001 20:35:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbju17459 for ; Wed, 7 Feb 2001 20:35:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbju03223 for ; Wed, 7 Feb 2001 20:34:58 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbju15025 for ; Wed, 7 Feb 2001 20:34:58 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA02600 for mpls@uu.net; Wed, 7 Feb 2001 15:34:57 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbju17306 for ; Wed, 7 Feb 2001 20:34:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbju17003 for ; Wed, 7 Feb 2001 20:33:50 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 QQkbju11706 for ; Wed, 7 Feb 2001 20:33:49 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA00117; Wed, 7 Feb 2001 12:33:42 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14977.45350.52000.804184@gargle.gargle.HOWL> Date: Wed, 7 Feb 2001 12:33:42 -0800 To: Shahram Davari Cc: mpls@UU.NET Subject: RE: PHP negotiation In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A4A@BBY1EXM01> References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A4A@BBY1EXM01> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I would have to add to this that when you have an MPLS diffserv network that uses a combination of E and L_LSPs and PHP is enabled, implementation of PHP in hardware becomes quite complex due to amount of tables, exception cases and remapping. I think that PHP is a hack that was useful when routers could not do at least two lookups when doing a POP. I think it is an architectural mis-feature and hopefully with time, it will be used less and eventually deprecated. Bora From owner-mpls@UU.NET Wed Feb 7 20:26:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13585 for ; Wed, 7 Feb 2001 20: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 QQkbkn02027; Thu, 8 Feb 2001 01:24:32 GMT Received: by mail-control.mail.uu.net id QQkbkn20087 for mpls-outgoing; Thu, 8 Feb 2001 01:24: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 QQkbkn20078 for ; Thu, 8 Feb 2001 01: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 QQkbkn21835 for ; Thu, 8 Feb 2001 01:23:49 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbkn17784 for ; Thu, 8 Feb 2001 01:23:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA19304 for mpls@uu.net; Wed, 7 Feb 2001 20:23: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 QQkbkn20037 for ; Thu, 8 Feb 2001 01:23: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 QQkbkn20091 for ; Thu, 8 Feb 2001 01:23:14 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 QQkbkn17157 for ; Thu, 8 Feb 2001 01:23:14 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 UAA06940; Wed, 7 Feb 2001 20:22:39 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch-janeiro-p33.cisco.com [171.69.209.237]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB01688; Wed, 7 Feb 2001 20:23:00 -0500 (EST) Message-Id: <4.3.2.7.2.20010207202236.023a5768@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Feb 2001 20:23:55 -0500 To: , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: Draft IETF MPLS TE MIB 05 usage question: Tunnel Table Cc: Cheenu Srinivasan , Arun Viswanathan In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC031241@WATERTOWN.litchfiel dcomm.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6477904==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_6477904==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >By description, the Tunnel Table provides for multiple tunnel instances - >in the case where you have backup or parallel tunnels. When using multiple >instances, I would think the TunnelIndex would stay the same value while >the TunnelInstance increments (1, 2, and so on). The reason I'm not sure >that this is right is the description under mplsTunnelIndexNext which says: Correct. >"This object contains the next appropriate value to be used for >mplsTunnelIndex when creating entries in mplsTunnelTable." > >To better describe my understanding, it would say: > >"This object contains the next appropriate value to be used for >mplsTunnelIndex when creating an entry (or, in the case of multiple >instances, a set of entries ) in the mplsTunnelTable." This is a good point. It is possible that one would want to manually configure a tunnel instance. We will modify the text a bit to make this clearer. --Tom --=====================_6477904==_.ALT Content-Type: text/html; charset="us-ascii"

By description, the Tunnel Table provides for multiple tunnel instances - in the case where you have backup or parallel tunnels. When using multiple instances, I would think the TunnelIndex would stay the same value while the TunnelInstance increments (1, 2, and so on). The reason I'm not sure that this is right is the description under mplsTunnelIndexNext which says:

        Correct.

"This object contains the next appropriate value to be used for mplsTunnelIndex when creating entries in mplsTunnelTable."

To better describe my understanding, it would say:

"This object contains the next appropriate value to be used for mplsTunnelIndex when creating an entry (or, in the case of multiple instances, a set of entries ) in the mplsTunnelTable."

        This is a good point. It is possible that one would want
to manually configure a tunnel instance. We will modify the
text a bit to make this clearer.

        --Tom


--=====================_6477904==_.ALT-- From owner-mpls@UU.NET Wed Feb 7 20:29:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13625 for ; Wed, 7 Feb 2001 20:29: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 QQkbkn07091; Thu, 8 Feb 2001 01:28:01 GMT Received: by mail-control.mail.uu.net id QQkbkn20484 for mpls-outgoing; Thu, 8 Feb 2001 01:27:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbkn20468 for ; Thu, 8 Feb 2001 01:27:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbkn26524 for ; Thu, 8 Feb 2001 01:27:18 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbkn05980 for ; Thu, 8 Feb 2001 01:27:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA19738 for mpls@uu.net; Wed, 7 Feb 2001 20:27:16 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbkn20420 for ; Thu, 8 Feb 2001 01:26:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbkn07912 for ; Thu, 8 Feb 2001 01:26:47 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 QQkbkn21770 for ; Thu, 8 Feb 2001 01:26:45 GMT Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA27701; Wed, 7 Feb 2001 17:26:30 -0800 (PST) Received: from jlawrenc-pc.cisco.com (dhcp-64-104-222-77.cisco.com [64.104.222.77]) by bulkrate.cisco.com (Mirapoint) with ESMTP id ABE00043; Wed, 7 Feb 2001 17:16:00 -0800 (PST) Message-Id: <4.3.2.7.2.20010208114929.00b08e50@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Feb 2001 12:15:21 +1100 To: "'Mahadevan Iyer'" From: Jeremy Lawrence Subject: RE: VC merge question Cc: mpls@UU.NET, Shahram Davari In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A46@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk To expand this comment: At 09:03 02/07/2001 -0800, Shahram Davari wrote: >Yes. This kind of LSP merge is similar to VP-merge in ATM. Check RFC3035. If the top-most label is VC-based, then there may be an arbitrary number of additional labels carried inside packet within the ATM payload [RFC3035 section 9]. I'm not sure if that's the answer to the question though: >> -----Original Message----- >> From: Mahadevan Iyer [mailto:iyermahadevan@yahoo.com] >> Sent: Wednesday, February 07, 2001 12:24 AM >> To: mpls@UU.NET >> Subject: VC merge question >> >> >> Hello, >> >> When using VC merge to support heirarchial LSP type >> capabilities I'm confused about the question. VC merge supports aggregation of ATM VC-based LSPs of a common FEC, e.g. to a common destination. VC merge is not, in itself, a way of supporting hierarchy. VC merge does not preclude the use of hierarchy, but it need do nothing to support it. >is it possible to stack more then 2 >> levels(i.e. reuse the VPI for the outer VC). That's a separate issue. It is, in theory, possible to carry two MPLS labels in an ATM header, one in the VPI and one in the VCI. There was work on this in the working group, but it lapsed. (At the time, I argued strongly against the use of VP labels for hop-by-hop routed MPLS, because a label space of 4096 VPIs (12 bits) is too small to be scalable for general use. The combined VPCI space of 28 bits available to VC-based labels is more obviously sufficient.) Jeremy Lawrence From owner-mpls@UU.NET Thu Feb 8 02:20:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02231 for ; Thu, 8 Feb 2001 02:20:42 -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 QQkbll25315; Thu, 8 Feb 2001 07:18:46 GMT Received: by mail-control.mail.uu.net id QQkbll10702 for mpls-outgoing; Thu, 8 Feb 2001 07:18:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbll10688 for ; Thu, 8 Feb 2001 07:18:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbll16500 for ; Thu, 8 Feb 2001 07:18:01 GMT Received: from galileo5.galileo.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pop3.galileo.co.il [199.203.130.130]) id QQkbll05039 for ; Thu, 8 Feb 2001 07:17:58 GMT Received: from galileo.co.il ([10.2.2.39]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id JAA10741; Thu, 8 Feb 2001 09:18:16 +0200 (GMT-2) Message-ID: <3A824895.735E32EA@galileo.co.il> Date: Thu, 08 Feb 2001 09:19:49 +0200 From: David Melman Reply-To: davidm@galileo.co.il Organization: Galileo Technology Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: mpls@UU.NET Subject: Re: PHP negotiation References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A4A@BBY1EXM01> <14977.45350.52000.804184@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > I would have to add to this that when you have an MPLS diffserv > network that uses a combination of E and L_LSPs and PHP is > enabled, implementation of PHP in hardware becomes quite > complex due to amount of tables, exception cases and remapping. Bora, can you elaborate a bit on the complexity that you refer to in implementing PHP in hardware in an MPLS diffserv network? Thanks, David > > > I think that PHP is a hack that was useful when routers > could not do at least two lookups when doing a POP. I think it > is an architectural mis-feature and hopefully with time, it will be > used less and eventually deprecated. > > Bora From owner-mpls@UU.NET Thu Feb 8 03:56:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03008 for ; Thu, 8 Feb 2001 03:56:29 -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 QQkblq01615; Thu, 8 Feb 2001 08:34:30 GMT Received: by mail-control.mail.uu.net id QQkblq00828 for mpls-outgoing; Thu, 8 Feb 2001 08:33:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkblq00798 for ; Thu, 8 Feb 2001 08:33:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkblq25862 for ; Thu, 8 Feb 2001 08:32:13 GMT Received: from web10510.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web10510.mail.yahoo.com [216.136.172.142]) id QQkblq27349 for ; Thu, 8 Feb 2001 08:32:13 GMT Message-ID: <20010208083212.71092.qmail@web10510.mail.yahoo.com> Received: from [198.206.187.100] by web10510.mail.yahoo.com; Thu, 08 Feb 2001 00:32:12 PST Date: Thu, 8 Feb 2001 00:32:12 -0800 (PST) From: Mahadevan Iyer Subject: RE: VC merge question To: Jeremy Lawrence Cc: mpls@UU.NET, Shahram Davari In-Reply-To: <4.3.2.7.2.20010208114929.00b08e50@bulkrate.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk --- Jeremy Lawrence wrote: > >is it possible to stack more then 2 > >> levels(i.e. reuse the VPI for the outer VC). > This was the question > That's a separate issue. It is, in theory, possible > to carry > two MPLS labels in an ATM header, one in the VPI and > one in > the VCI. There was work on this in the working > group, but it lapsed. > (At the time, I argued strongly against the use of > VP labels > for hop-by-hop routed MPLS, because a label space of > 4096 VPIs > (12 bits) is too small to be scalable for general > use. The > combined VPCI space of 28 bits available to VC-based > labels is > more obviously sufficient.) > Thanks > Jeremy Lawrence > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Feb 8 04:37:30 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03464 for ; Thu, 8 Feb 2001 04:37: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 QQkblu03250; Thu, 8 Feb 2001 09:34:52 GMT Received: by mail-control.mail.uu.net id QQkblu19355 for mpls-outgoing; Thu, 8 Feb 2001 09:34: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 QQkblu19325 for ; Thu, 8 Feb 2001 09:34:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkblu23751 for ; Thu, 8 Feb 2001 09:33:19 GMT From: neil.2.harrison@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 QQkblu22521 for ; Thu, 8 Feb 2001 09:33:18 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Thu, 8 Feb 2001 09:32:52 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id <1PC3LSBH>; Thu, 8 Feb 2001 09:33:00 -0000 Message-ID: To: akyol@pluris.com, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: PHP negotiation Date: Thu, 8 Feb 2001 09:32:57 -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 I agree Bora....if you allow PHP, then where (in a functional architecture sense) is the LSP trail termination point? This has implications for: - defect detection - server->client layer adapatation - performance monitoring - protection switching neil > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: 07 February 2001 20:34 > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: PHP negotiation > > > > I would have to add to this that when you have an MPLS diffserv > network that uses a combination of E and L_LSPs and PHP is > enabled, implementation of PHP in hardware becomes quite > complex due to amount of tables, exception cases and remapping. > > I think that PHP is a hack that was useful when routers > could not do at least two lookups when doing a POP. I think it > is an architectural mis-feature and hopefully with time, it will be > used less and eventually deprecated. > > Bora > > From owner-mpls@UU.NET Thu Feb 8 08:03:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05832 for ; Thu, 8 Feb 2001 08:03: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 QQkbmi17406; Thu, 8 Feb 2001 13:01:37 GMT Received: by mail-control.mail.uu.net id QQkbmi20502 for mpls-outgoing; Thu, 8 Feb 2001 13:01: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 QQkbmi19833 for ; Thu, 8 Feb 2001 13:00:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbmi01988 for ; Thu, 8 Feb 2001 13:00:26 GMT Received: from thick.mail.pipex.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: thick.mail.pipex.net [158.43.192.95]) id QQkbmi04874 for ; Thu, 8 Feb 2001 13:00:25 GMT Received: (qmail 4135 invoked from network); 8 Feb 2001 12:56:55 -0000 Received: from userdx17.uk.uudial.com (HELO alten.co.uk) (62.188.8.110) by smtp-3.dial.pipex.com with SMTP; 8 Feb 2001 12:56:55 -0000 Received: from alten.co.uk ([198.192.42.61]) by alten.co.uk ( IA Mail Server Version: 3.1.3. Build: 1065 ) ) ; 08 Feb 2001 13:05:07 UT Message-ID: <3A829982.6ECDF0C9@alten.co.uk> Date: Thu, 08 Feb 2001 13:05:06 +0000 From: Darren Freeland X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: shyao@ece.ucdavis.edu CC: "'Alec Myers'" , "'mpls@uu.net'" Subject: Re: G-MPLS on all-optical switches? References: <000d01c09077$323de900$7960eda9@ucdavis.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Shun, Shun Yao wrote: > I believe Darren was referring to all-optical ~circuit~ switch, not packet > switch. Yes, that's what I was referring to. How will G-MPLS run on an optical switch with MEMs technology for example (indeed any fabric that is transparent to user plane traffic). Still haven't heard any real answers from vendors. Does this mean that there's a number of vendors building transparent optical switches, but they're not sure how they will control them? ;) Vendors, if it's a proprietary thing that you don't want to share with the exploder list, please feel free to mail me offline with some info! Thanks, Darren. > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Alec > > Myers > > Sent: Tuesday, February 06, 2001 11:34 AM > > To: 'mpls@uu.net' > > Cc: Darren Freeland > > Subject: Re: G-MPLS on all-optical switches? > > > > > > Bearing in mind: > > > > 1. The crudity of pure optical memory (fibre delay lines) > > 2. The lack of pure-optical logic > > 3. The lack of a fast (packet rate) wavelength switching technology > > 4. The delay in line clock-recovery between differing > > transmitter/receivers > > pairs at the start of each packet > > 5. The difficulty in dynamically recovering from non-linear effects in > > optical paths whose length varies per-packet > > > > I wouldn't expect to see a real FULLY optical switch any time soon. > > > > There are a few papers around that describe possible control > > schemes, but > > they are all rather crude, and make only passing reference to MPLS. If > > you're interested I can forward the references. > > > > -A > > > > > > ----- Original Message ----- > > From: "Darren Freeland" > > To: > > Cc: > > Sent: Tuesday, February 06, 2001 2:24 PM > > Subject: G-MPLS on all-optical switches? > > > > > > > Hi, > > > > > > Can any vendor give me some information on exactly how they > > intend to > > > run G-MPLS on FULLY optical switches? For the control > > signals, will you > > > use optical splitters or the like to tap off some of the lightpath > > > inband (amplifying to compensate for the power loss), or > > will you use an > > > outband network? > > > > > > Any info much appreciated .... > > > > > > Darren. > > > > > > > > From owner-mpls@UU.NET Thu Feb 8 09:10:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07480 for ; Thu, 8 Feb 2001 09:10: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 QQkbmm24781; Thu, 8 Feb 2001 14:07:07 GMT Received: by mail-control.mail.uu.net id QQkbmm17090 for mpls-outgoing; Thu, 8 Feb 2001 14:06:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbmm17081 for ; Thu, 8 Feb 2001 14:06:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbmm24421 for ; Thu, 8 Feb 2001 14:06:27 GMT Received: from mxtlv1.corrigent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.203.64.33]) id QQkbmm04147 for ; Thu, 8 Feb 2001 14:06:25 GMT Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id <1AKWMN1C>; Thu, 8 Feb 2001 16:04:27 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B35316867D@mxtlv1.corrigent.com> From: Jaakov Berkovitch To: "'mpls@uu.net'" Subject: CORBA interface for MPLS Date: Thu, 8 Feb 2001 16:04:20 +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 Hello, Do anybody knows if there is already standardized CORBA interface / CORBA model for the MPLS world ? Perhaps, working groups are working on this. Thanks for any tips. Yaakov Berkovitch Tel: 972 + 36945298 E-mail: jaakovb@corrigent.com WEB site: http://www.corrigent.com From owner-mpls@UU.NET Thu Feb 8 11:54:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12905 for ; Thu, 8 Feb 2001 11:54: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 QQkbmw24176; Thu, 8 Feb 2001 16:40:00 GMT Received: by mail-control.mail.uu.net id QQkbmw29015 for mpls-outgoing; Thu, 8 Feb 2001 16:39:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbmw29010 for ; Thu, 8 Feb 2001 16:39:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbmw06607 for ; Thu, 8 Feb 2001 16:39:11 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkbmw22482 for ; Thu, 8 Feb 2001 16:39:10 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f18Gd8J24634 for ; Thu, 8 Feb 2001 17:39:09 +0100 (MET) Received: from alcatel.be ([138.203.169.199]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569ED.005B7389; Thu, 8 Feb 2001 17:38:53 +0100 Message-ID: <3A82CB92.56803582@alcatel.be> Date: Thu, 08 Feb 2001 17:38:42 +0100 From: Paul Moore Organization: Alcatel Bell X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS-TE SESSION_ATTRIBUTE question Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In section 4.7.4 of the RSVP-TE draft, it states (in the final paragraph of the section):

   "All RSVP routers, whether they support the SESSION_ATTRIBUTE object
   or not, SHALL forward the object unmodified.  The presence of non-
   RSVP routers anywhere between senders and receivers has no impact on
   this object."

This implies that non-RSVP routers should pass-through the PATH message. However, section 4.2.5 states:

   "RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."

Is there a contradiction between these two statements? I suppose the second statement in the first quoted paragraph above should simply be removed. Or is there something I missed?

Also, an editorial comment concerning Section 4.7.4. The third-last paragraph is incomplete.

Paul

--
Paul Moore
Alcatel Bell
+32 3 450 3536
paul-patrick.moore@alcatel.be
  From owner-mpls@UU.NET Thu Feb 8 12:05:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13218 for ; Thu, 8 Feb 2001 12:05: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 QQkbmy28447; Thu, 8 Feb 2001 17:02:50 GMT Received: by mail-control.mail.uu.net id QQkbmy04189 for mpls-outgoing; Thu, 8 Feb 2001 17:02: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 QQkbmy03941 for ; Thu, 8 Feb 2001 17:02: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 QQkbmy02470 for ; Thu, 8 Feb 2001 17:01:33 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQkbmy15634 for ; Thu, 8 Feb 2001 17:01:33 GMT Received: from iris.cs.ucf.edu (iris [132.170.108.55]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f18H1Wc15101 for ; Thu, 8 Feb 2001 12:01:32 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by iris.cs.ucf.edu (8.9.3/8.9.0) id LAA09694 for mpls@uu.net; Thu, 8 Feb 2001 11:59:53 -0500 (EST) Message-Id: <200102081659.LAA09694@iris.cs.ucf.edu> Subject: PL send email in Ascii format To: mpls@UU.NET Date: Thu, 8 Feb 2001 11:59:53 -0500 (EST) 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 Hi: Please send emails in Ascii format Regards Arturo Nunez From owner-mpls@UU.NET Thu Feb 8 13:31:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15949 for ; Thu, 8 Feb 2001 13:31: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 QQkbnd11225; Thu, 8 Feb 2001 18:28:53 GMT Received: by mail-control.mail.uu.net id QQkbnd04726 for mpls-outgoing; Thu, 8 Feb 2001 18:28: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 QQkbnd04713 for ; Thu, 8 Feb 2001 18:28:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbnd24777 for ; Thu, 8 Feb 2001 18:27:22 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkbnd17853 for ; Thu, 8 Feb 2001 18:27:21 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f18IRHf11780 for ; Thu, 8 Feb 2001 19:27:17 +0100 (MET) Received: from alcatel.be ([138.203.169.199]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569ED.006555CC; Thu, 8 Feb 2001 19:26:51 +0100 Message-ID: <3A82E4EB.C118399D@alcatel.be> Date: Thu, 08 Feb 2001 19:26:51 +0100 From: Paul Moore Organization: Alcatel Bell X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS-TE SESSION_ATTRIBUTE question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Resent in plain text format this time... My apologies, my first posting to this mail list. In section 4.7.4 of the RSVP-TE draft, it states (in the final paragraph of the section): "All RSVP routers, whether they support the SESSION_ATTRIBUTE object or not, SHALL forward the object unmodified. The presence of non- RSVP routers anywhere between senders and receivers has no impact on this object." This implies that non-RSVP routers should pass-through the PATH message. However, section 4.2.5 states: "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." Is there a contradiction between these two statements? I suppose the second statement in the first quoted paragraph above should simply be removed. Or is there something I missed? Also, an editorial comment concerning Section 4.7.4. The third-last paragraph is incomplete. Paul -- Paul Moore Alcatel Bell +32 3 450 3536 paul-patrick.moore@alcatel.be From owner-mpls@UU.NET Thu Feb 8 16:16:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19639 for ; Thu, 8 Feb 2001 16: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 QQkbno02656; Thu, 8 Feb 2001 21:12:34 GMT Received: by mail-control.mail.uu.net id QQkbno25423 for mpls-outgoing; Thu, 8 Feb 2001 21:12: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 QQkbno25415 for ; Thu, 8 Feb 2001 21:11:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbno23610 for ; Thu, 8 Feb 2001 21:09:46 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 QQkbno27028 for ; Thu, 8 Feb 2001 21:09: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 NAA15108 for ; Thu, 8 Feb 2001 13:09:57 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA29482 for mpls@uu.net; Thu, 8 Feb 2001 16:09:43 -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 QQkbnl09241 for ; Thu, 8 Feb 2001 20:26:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbnl03666 for ; Thu, 8 Feb 2001 20:24:43 GMT Received: from motgate.mot.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate.mot.com [129.188.136.100]) id QQkbnl27428 for ; Thu, 8 Feb 2001 20:24:42 GMT Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA15541 for ; Thu, 8 Feb 2001 13:24:38 -0700 (MST)] Received: [from il02exb01.comm.mot.com (il02exb01.comm.mot.com [145.1.204.17]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA09782 for ; Thu, 8 Feb 2001 13:24:38 -0700 (MST)] Received: by il02exb01.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Feb 2001 14:24:37 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D963@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'Dirk Ooms'" Cc: "'mpls'" Subject: RE: Multicast and MPLS Date: Thu, 8 Feb 2001 14:24:37 -0600 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 Dirk, What multicast routing protocols does your product support? If you support sparse mode receiver-initiated protocols, is your label distribution piggybacked on the multicast routing protocol control messages? I am interested in finding out which direction the industry is leaning towards - given that differet approaches are advantageous for dense and sparse mode protocols. Thanks, Vidya > -----Original Message----- > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > Sent: Tuesday, February 06, 2001 6:39 AM > To: Narayanan Vidya-CVN065 > Cc: 'mpls' > Subject: Re: Multicast and MPLS > > > Narayanan, > > Alcatel has Multicast/MPLS running in the lab. It isn't in > any product > yet because it hasn't been requested by customers, but if there is a > demand we can put it in fast. > > dirk > > Narayanan Vidya-CVN065 wrote: > > > > All, > > I have been doing some research on the status of multicast > with MPLS. I've been following the last call comments for the > multicast framework document and I remember seeing some > related email that made a mention of some existing multicast > implementations of MPLS. I was wondering if anyone knew what > vendors are supporting multicast using MPLS. I have done > extensive searches on Cisco's and Nortel's website and have > failed to come up with any information regarding this. I > noticed that Lucent has kept the IP Navigator that they got > from Ascend.. they talk about multicast MPLS support, yet it > is somewhat unclear whether they support PIM-SM or DVMRP > functionality in full. A couple of years ago, when Ascend was > still around, their imlementation supported MOSPF, but also > had the BR functionality for some other multicast routing > protocols. I was wondering if anyone could throw some light > into whether they now support other multicast routing protocols. > > > > I am also trying to get a sense of where the IETF is going > with the rest of the expired drafts related to multicast and > MPLS. Are those drafts not refreshed because they are not > viewed as being viable or it is just a matter of time before > more work is done in this area? Basically, where is multicast > in the list of priorities for the MPLS WG? > > > > Thanks, > > Vidya > > > > > -------------------------------------------------------------- > ---------- > > > > Part 1.2 Type: application/ms-tnef > > Encoding: base64 > > -- > Dirk Ooms mailto:dirk.ooms@alcatel.be > tel:+32 3 2404732 > Network Strategy Group (NSG) http://www.rc.bel.alcatel.be/nsg > Alcatel http://www.alcatel.com > From owner-mpls@UU.NET Thu Feb 8 17:03:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20652 for ; Thu, 8 Feb 2001 17:03: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 QQkbns11093; Thu, 8 Feb 2001 22:00:31 GMT Received: by mail-control.mail.uu.net id QQkbns29663 for mpls-outgoing; Thu, 8 Feb 2001 22:00: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 QQkbnr29622 for ; Thu, 8 Feb 2001 21:59: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 QQkbnr27072 for ; Thu, 8 Feb 2001 21:59:20 GMT Received: from beamer.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQkbnr08840 for ; Thu, 8 Feb 2001 21:59:19 GMT Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id WAA25827; Thu, 8 Feb 2001 22:59:18 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id WAA01621; Thu, 8 Feb 2001 22:59:17 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 22:59:17 +0100 Message-ID: From: Heiles Juergen To: Frank Hujber , MPLS Group Subject: AW: Bandwidth Encoding Date: Thu, 8 Feb 2001 22:59:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA20652 Note, that even WDM systems have a maximum bit rate per channel (e.g. a channel/wavelenth can only support a maximum bit rate due to the channel spacing/filter bandwidth). Furthermore the maximum distance in an pure optical system depends on the bit rate. Regards Juergen > -----Urspr> üngliche Nachricht----- > Von: Frank Hujber [SMTP:fhujber@hotmail.com] > Gesendet am: Donnerstag, 1. Februar 2001 22:49 > An: MPLS Group > Betreff: Bandwidth Encoding > > Folks, > > I note in "Generalized MPLS Signaling - RSVP-TE Extensions" that the > bandwidth encoding does not include a clear channel option. That it, if a > provider is simply offering a service that is rate independent, he still > must specify a discrete bit rate. > > Has there been a value identified for this field that specifies a > clear-channel offering? > > Frank Hujber > fhujber@hotmail.com From owner-mpls@UU.NET Thu Feb 8 17:07:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20701 for ; Thu, 8 Feb 2001 17:07: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 QQkbns17029; Thu, 8 Feb 2001 22:04:46 GMT Received: by mail-control.mail.uu.net id QQkbns12371 for mpls-outgoing; Thu, 8 Feb 2001 22:04: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 QQkbns12346 for ; Thu, 8 Feb 2001 22:03: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 QQkbns15142 for ; Thu, 8 Feb 2001 22:01:47 GMT Received: from mailer.syr.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailer.syr.edu [128.230.18.29]) id QQkbns19152 for ; Thu, 8 Feb 2001 22:01:46 GMT Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.0094A3E9@mailer.syr.edu>; Thu, 8 Feb 2001 17:00:42 -0500 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id RAA15574 for ; Thu, 8 Feb 2001 17:00:40 -0500 (EST) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Thu, 8 Feb 2001 17:00:40 -0500 (EST) From: Ibrahim Okumus X-Sender: iokumus@rodan.syr.edu To: mpls@UU.NET Subject: L-LSP incoming PHB Determination. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I was going through MPLS support of Diff-serv draft. I am not clear at one point about L-LSP incoming PHB determination. on pg 5 "A seperate LSP can be established for a single pair. With such LSPs, the PSC is explicitly signalled at label establishment time so that, after label establishment, the LSR can infer exclusively fromt he label value the PSC to be applied to a lebaled packet" Does this mean that certain label is bound to a certain PSC during path establishment and when the LSR sees that label it knows that packet belongs to that certain PSC? Is there a specific range of labels to be applied to specific PSCs or is it arbitrary? And I am also assuming that if a domain is using E-LSP it doesn't use L-LSP. I am correct? Thanks, _______________________________ Ibrahim Taner OKUMUS From owner-mpls@UU.NET Thu Feb 8 17:43:03 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21098 for ; Thu, 8 Feb 2001 17:43: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 QQkbnu15511; Thu, 8 Feb 2001 22:39:59 GMT Received: by mail-control.mail.uu.net id QQkbnu16070 for mpls-outgoing; Thu, 8 Feb 2001 22:39: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 QQkbnu16056 for ; Thu, 8 Feb 2001 22:39: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 QQkbnu29121 for ; Thu, 8 Feb 2001 22:38:56 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbnu14009 for ; Thu, 8 Feb 2001 22:38:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA03882 for mpls@uu.net; Thu, 8 Feb 2001 17:38: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 QQkbnu16011 for ; Thu, 8 Feb 2001 22:38: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 QQkbnu23583 for ; Thu, 8 Feb 2001 22:37:10 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 QQkbnu11438 for ; Thu, 8 Feb 2001 22:37:05 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 OAA13395; Thu, 8 Feb 2001 14:36:32 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BCR2W>; Thu, 8 Feb 2001 14:36:32 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A50@BBY1EXM01> From: Shahram Davari To: "'Ibrahim Okumus'" , mpls@UU.NET Subject: RE: L-LSP incoming PHB Determination. Date: Thu, 8 Feb 2001 14:36:31 -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, > I was going through MPLS support of Diff-serv draft. I am not > clear at one > point about L-LSP incoming PHB determination. > on pg 5 > "A seperate LSP can be established for a single > pair. With such > LSPs, the PSC is explicitly signalled at label establishment > time so that, > after label establishment, the LSR can infer exclusively > fromt he label > value the PSC to be applied to a lebaled packet" > > Does this mean that certain label is bound to a certain PSC > during path > establishment and when the LSR sees that label it knows that packet > belongs to that certain PSC? Yes. > Is there a specific range of labels to be applied to specific > PSCs or is > it arbitrary? It is arbitrary. > And I am also assuming that if a domain is using E-LSP it doesn't use > L-LSP. I am correct? No, you could have both L-LSP and E-LSP in a domain simultaneously. Yours, -Shahram > Thanks, > > > _______________________________ > Ibrahim Taner OKUMUS > > From owner-mpls@UU.NET Thu Feb 8 19:28:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21850 for ; Thu, 8 Feb 2001 19:28: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 QQkbob29188; Fri, 9 Feb 2001 00:24:39 GMT Received: by mail-control.mail.uu.net id QQkbob21658 for mpls-outgoing; Fri, 9 Feb 2001 00:24:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbob21652 for ; Fri, 9 Feb 2001 00:24:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbob10802 for ; Fri, 9 Feb 2001 00:22:14 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbob25876 for ; Fri, 9 Feb 2001 00:22:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA09446 for mpls@uu.net; Thu, 8 Feb 2001 19:22:13 -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 QQkbob21461 for ; Fri, 9 Feb 2001 00:21:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbob15059 for ; Fri, 9 Feb 2001 00:20:50 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQkbob28524 for ; Fri, 9 Feb 2001 00:20:49 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA06338; Thu, 8 Feb 2001 16:20:47 -0800 (PST) Message-Id: <200102090020.QAA06338@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3063 on MPLS Loop Prevention Mechanism Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 08 Feb 2001 16:20:47 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3063 Title: MPLS Loop Prevention Mechanism Author(s): Y. Ohba, Y. Katsube, E. Rosen, P. Doolan Status: Experimental Date: February 2001 Mailbox: yoshihiro.ohba@toshiba.co.jp, yasuhiro.katsube@toshiba.co.jp, erosen@cisco.com, pdoolan@ennovatenetworks.com Pages: 44 Characters: 93523 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-loop-prevention-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3063.txt This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path-vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010208161855.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3063 --OtherAccess Content-Type: Message/External-body; name="rfc3063.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010208161855.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Feb 8 21:47:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24579 for ; Thu, 8 Feb 2001 21:47: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 QQkbol13765; Fri, 9 Feb 2001 02:45:22 GMT Received: by mail-control.mail.uu.net id QQkbok00460 for mpls-outgoing; Fri, 9 Feb 2001 02:44:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbok00447 for ; Fri, 9 Feb 2001 02:44:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbok11010 for ; Fri, 9 Feb 2001 02:44:33 GMT Received: from evita2.cs.fredonia.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: evita2.cs.fredonia.edu [141.238.30.9]) id QQkbok12661 for ; Fri, 9 Feb 2001 02:44:33 GMT Received: from Zubairi.cs.fredonia.edu (zubairi.cs.fredonia.edu [141.238.30.211]) by evita2.cs.fredonia.edu (8.9.3/8.9.3) with ESMTP id VAA22043 for ; Thu, 8 Feb 2001 21:44:28 -0500 Message-ID: <004901c09242$7b653120$d31eee8d@cs.fredonia.edu> From: "Junaid Ahmed Zubairi" To: Subject: Call for Papers session on BANDWIDTH and SERVICE QUALITY management in the Internet Date: Thu, 8 Feb 2001 21:46:16 -0500 Organization: SUNY/Fredonia 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 CALL FOR PAPERS INVITED SESSION ON BANDWIDTH AND SERVICE QUALITY MANAGEMENT IN THE INTERNET 5th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI 2001) Orlando, Florida, USA July 22-25, 2001 Scope Internet is undergoing a major transformation from being a best effort network to a well organized and well managed system with built-in intelligent protocols to provide predictable performance. Internet Engineering Task Force (IETF) has developed and incorporated a number of new protocols and techniques for managing and allocating network bandwidth and supporting service quality. For bandwidth allocation and management, COPS (Common Open Policy Service) clients and servers work to convey policy decisions and allocate and recover bandwidth across a domain. For QoS, RSVP provides quantitative guarantees by reserved paths and Diffserv provides qualitative assurances by using PHB (per hop behavior) and PDB (per domain behavior) for packets marked with DSCP (DS codepoints). MPLS installs LSP's (Label Switched Path) that satisfy Traffic Engineering requirements. As LSP's are set up and released, the available bandwidth metrics for various links are updated to reflect the current state of the network. An invited session on managing bandwidth and service quality through these new protocols and techniques is being organized at the SCI'2001 conference. This session will serve as a forum to present and discuss the latest research and simulation results of works by researchers and developers across the world. Topics of interest include, but are not limited to: Bandwidth management with COPS and MPLS Effects of shaping and packet coloring on multimedia streams Integrated operation of Intserv and Diffserv Aggregation of flows for scaling of RSVP VoIP performance over Diffserv networks Traffic Engineering architecture for the Internet Impact of congestion resolution schemes on QoS traffic Voice over MPLS Performance of RSVP-MPLS architecture FR/MPLS Network and service interworking Inter-provider MPLS signaling and LSP routing Inter-domain tunneling rules COPS Policy Server/Bandwidth Broker implementation issues Paper Submission Extended abstracts or paper drafts should be sent as per the following format: 1. Extended abstract of 500 to 1500 words or paper drafts of 2000 to 2500 words, in English. 2. Names, addresses, telephone numbers, fax numbers and e-mail addresses of all authors, with the name of the contact author underlined. The abstracts or papers can be submitted in ps or pdf format to session organizer at zubairi@cs.fredonia.edu by March 2nd, 2001 via email. Proceedings Accepted papers, which should not exceed six single-spaced typed pages, will be published by means of paper and electronic proceedings. Best papers will be selected for awards and recommended for journal publications. Multiple author books will be published by IIIS, based on the best-invited sessions, the best focus symposia or the best mini-conferences Session Organizer: Dr. Junaid Ahmed Zubairi Department of Mathematics and Computer Science College at Fredonia, State University of New York Fredonia, NY 14063, USA Tel: +1-716-673-4694 Fax: +1-508-256-8324 Email: zubairi@cs.fredonia.edu WWW: http://www.cs.fredonia.edu/~zubairi Session Co-organizer: Wajdi Al-Khateeb Electrical and Computer Engineering Department Kulliyyah of Engineering, Intl' Islamic University Malaysia Jalan Gombak, Kuala Lumpur 53100, Malaysia Tel: +603-2056-4574 Fax: +603-2056-4853 Email: wajdi@iiu.edu.my Important Dates: Extended Abstract/Draft Paper due: March 2nd, 2001 Notification of Acceptance: March 16th, 2001 Camera read copy due: April 13th, 2001 If you have questions concerning session paper submission or session content, please contact the invited session organizers at the addresses above. If you have questions concerning conference paper submissions or program, please contact Conference General Chair Prof. Nagib Callaos by email at ncallaos@usb.ve (Academic) or ncallaos@aol.com (Personal). For further information, see conference web site at http://www.iiis.org/sci *********************************************************** Dr. Junaid Ahmed Zubairi Department of Mathematics and Computer Science SUNY/Fredonia, Fredonia, NY 14063 Tel: (716)673-4694 Fax:(508)256-8324 *********************************************************** From owner-mpls@UU.NET Fri Feb 9 08:50:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17052 for ; Fri, 9 Feb 2001 08:50: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 QQkbqd17370; Fri, 9 Feb 2001 13:45:32 GMT Received: by mail-control.mail.uu.net id QQkbqc07536 for mpls-outgoing; Fri, 9 Feb 2001 13:44: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 QQkbqc07524 for ; Fri, 9 Feb 2001 13:44:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbqc20733 for ; Fri, 9 Feb 2001 13:44:32 GMT Received: from dalyan.ee.bilkent.edu.tr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dalyan.ee.bilkent.edu.tr [139.179.12.25]) id QQkbqc16673 for ; Fri, 9 Feb 2001 13:44:04 GMT Received: from Ongun (pcee224.ee.bilkent.edu.tr [139.179.12.188]) by dalyan.ee.bilkent.edu.tr (8.9.3/8.9.3) with SMTP id PAA27724 for ; Fri, 9 Feb 2001 15:39:25 +0200 (EET) Message-ID: <002101c0929f$5b86f340$4592fea9@ee.bilkent.edu.tr> From: "Ongun Yucesan" To: Subject: GMPLS General Structure Date: Fri, 9 Feb 2001 15:51:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C092B0.1BDAD700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C092B0.1BDAD700 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Hi I am new at the protocol and GMPLS issues so can you suggest me some = introductory Paper at the beginning level, mainly on How does a packet = is treated thru out its travel over each packetized, TDM, Optical, Fiber = switeched layers. Thank you for your attention. Ongun YUCESAN M.Sc. stu at Bilkent University=20 EEE Dept. Ankara =20 ------=_NextPart_000_001E_01C092B0.1BDAD700 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

    Hi
 
I am new at the protocol and GMPLS = issues so can=20 you suggest me some introductory Paper at  the beginning level, = mainly=20 on How does a packet is treated thru out its travel over each=20 packetized, TDM, Optical, Fiber switeched layers. Thank you = for your=20 attention.
 
Ongun YUCESAN
M.Sc. stu at Bilkent University =
EEE Dept.
Ankara
   =
------=_NextPart_000_001E_01C092B0.1BDAD700-- From owner-mpls@UU.NET Fri Feb 9 09:39:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18544 for ; Fri, 9 Feb 2001 09:39: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 QQkbqg00679; Fri, 9 Feb 2001 14:36:45 GMT Received: by mail-control.mail.uu.net id QQkbqg24801 for mpls-outgoing; Fri, 9 Feb 2001 14:36:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbqg24790 for ; Fri, 9 Feb 2001 14:36:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbqg04791 for ; Fri, 9 Feb 2001 14:35:14 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 QQkbqg12033 for ; Fri, 9 Feb 2001 14:35:10 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 GAA13568 for ; Fri, 9 Feb 2001 06:35:26 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA01979 for mpls@uu.net; Fri, 9 Feb 2001 09:35:08 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbpp15746 for ; Fri, 9 Feb 2001 10:23:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbpp20140 for ; Fri, 9 Feb 2001 10:23:07 GMT Received: from correio.inescn.pt by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: correio.inescn.pt [192.35.246.2]) id QQkbpp27435 for ; Fri, 9 Feb 2001 10:23:06 GMT Received: from bart.inescn.pt (root@bart.inescn.pt [192.35.246.9]) by correio.inescn.pt (8.9.1/8.9.1/20) with ESMTP id KAA22374 for ; Fri, 9 Feb 2001 10:23:06 GMT Received: from inescporto.pt (cleopatra.inescn.pt [194.117.24.159]) by bart.inescn.pt (8.6.9/INESCP-V2.8) with ESMTP id KAA00591 for ; Fri, 9 Feb 2001 10:17:36 GMT Message-ID: <3A83C3A7.95192289@inescporto.pt> Date: Fri, 09 Feb 2001 10:17:11 +0000 From: Filipe Miguel Sousa Organization: INESC Porto X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Draft IETF MPLS TE MIB 05 usage question: Tunnel Table Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Question about the mplsTunnelXcPointer Object. Can someone clarify me on this issue? In the MPLS TE MIB the mplsTunnelTable as the mplsTunnelXcpointer. This object points to a row in the mplsXCTable in the MPLS LSR MIB. My question is how the MPLS TE MIB as all the XCsegments used by this tunnel if this pointer only points to one row in a specif mib? Best Regards, Filipe Sousa From owner-mpls@UU.NET Fri Feb 9 12:25:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24681 for ; Fri, 9 Feb 2001 12:25: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 QQkbqr03024; Fri, 9 Feb 2001 17:22:14 GMT Received: by mail-control.mail.uu.net id QQkbqr25622 for mpls-outgoing; Fri, 9 Feb 2001 17:21:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbqr25610 for ; Fri, 9 Feb 2001 17:21:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbqq00629 for ; Fri, 9 Feb 2001 17:14:29 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbqq20464 for ; Fri, 9 Feb 2001 17:14:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA28364 for mpls@uu.net; Fri, 9 Feb 2001 12:14: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 QQkbqq24708 for ; Fri, 9 Feb 2001 17:14:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbqq21645 for ; Fri, 9 Feb 2001 17:08:27 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 QQkbqq09170 for ; Fri, 9 Feb 2001 17:08:27 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id EE07C399; Fri, 9 Feb 2001 18:08:16 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp3.cisco.com [144.254.60.25]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id SAA29074; Fri, 9 Feb 2001 18:08:05 +0100 (MET) Message-Id: <200102091708.SAA29074@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 09 Feb 2001 18:04:37 +0100 To: mpls@UU.NET From: Francois Le Faucheur Subject: on its way ... Cc: diffserv@ietf.org, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, daha@ironbridgenetworks.com, murphy@juniper.net, curtis@avici.com, aatlas@avici.com, Vijay.Srinivasan@cosinecom.com, swallow@cisco.com, xiaoxipe@cse.msu.edu, telkamp@GBLX.net, Pierre.Merckx@sita.int, martin.tatham@bt.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, Subsequent to the MPLS WG Last Call, a special Diff-Serv WG Last Call was issued on at the request of the Area Directors. We received comments relating to two items. Below are the details of the planned resolution for both items. We will shortly post version 08.txt incorporating these resolutions. Cheers Francois L-LSPs EXP<-->PHB mapping ========================= We plan to incorporate Jim Murphy's suggestion to modify the EXP value corresponding to AFn3 L-LSPs. AFn3 would be mapped to EXP=011 (instead of 010). For memory, the rationale is that implementations which support only two drop priorities per AF class could determine the drop priority to be applied by looking at a single bit. Same idea was used for the DSCP encodings for AF. The EXP value will be changed accordingly in sections 4.2.1 (in the example), 4.2.1.1 (in the mapping table), 4.4.1 (in the example), 4.4.1.1 (in the mapping table). Incoming PHB Determination with Pipe Model =========================================== We received pretty much the same comment from several people (Service Providers as well as vendors) on one detailed aspect of the Pipe model: output scheduling at egress of a Pipe LSP. "xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming PHB determination based on the "inner header" (ie after the POP). We plan to: - keep such a behavior, but make it an optional variation of the Pipe model - define an alternative behavior where the egress LSR does incoming PHB determination based on the "outer header" (ie before the POP). This will be the normal egress behavior for the Pipe Model. All the other aspects of the Pipe model are unchanged. The rationale for using "outer header" by default on egress of Pipe is the following: - the typical application of the Pipe model is where a Service Provider (SP) transports traffic from a customer who uses a different Diff-Serv policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based on the outer header (and assuming no PHP) allows the Service Provider to configure scheduling based on its own Diff-Serv policy. Doing scheduling based on the inner header forces the Service Provider to be aware of each and every customer Diff-Serv policy and forces the SP to configure scheduling differently for each customer Diff-Serv policy. The most common situation will be that the SP does not want to be even aware of the Customer Diff-Serv policy and thus need to use the outer header. (There will be cases where the SP may accept the operational overhead of being aware of the customer's Diff-Serv policy and sell "egress scheduling based on customer's policy" as a value add; this is why we keep the use of inner header as an option. But this will be less common.) - again, use of inner header means that scheduling is based on customer Diff-SErv policy, which can be different for each egress port. For router platforms using some form of input queueing, this translates in additional sophistication since the input queueing must then be made aware of the Diff-Serv policy of every customer connected to an egress port (unless input queueing is performed on outer header even if egress scheduling is based on inner header, but that means performing classification twice: once on input and once on output). While this is implementable, it is undesirable to mandate such sophistication/cost as part of the mandatory Pipe mode. - use of outer header and use of inner header are both allowed in RFC2983 (from which the Uniform and Pipe models are inherited). This will result in corresponding text changes in section 2.6.2. >Message-ID: <3A1BE887.CB342532@hursley.ibm.com> >From: Brian E Carpenter >To: Diff Serv >Cc: George Swallow , Vijay Srinivasan > , Scott Bradner , Allison Mankin > , Rob Coltun , Kathleen Nichols > >Subject: [Diffserv] Special last call for draft-ietf-mpls-diff-ext-07.txt >Date: Wed, 22 Nov 2000 07:38:48 -0800 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2650.21) >Content-Type: text/plain > >Diffservers, > >draft-ietf-mpls-diff-ext-07.txt has passed Last Call in the MPLS working group, >but since it concerns Diffserv, this is a special last call at the request >of the Area Directors. > >If you have any issues and concerns with the document that have not >previously been raised on the MPLS list, please raise them before >December 6. > >Also, please direct your comments to the MPLS mailing list, not >the diffserv list, since it is their document, not ours! > >The MPLS list is at mpls@uu.net > >The draft is at http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-07.txt > >Regards > Brian + Kathie > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _________________________________________________________________ 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 Fri Feb 9 13:15:40 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27221 for ; Fri, 9 Feb 2001 13:15: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 QQkbqu14259; Fri, 9 Feb 2001 18:06:34 GMT Received: by mail-control.mail.uu.net id QQkbqu12102 for mpls-outgoing; Fri, 9 Feb 2001 18:05:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbqu12045 for ; Fri, 9 Feb 2001 18:05:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbqs00124 for ; Fri, 9 Feb 2001 17:39:41 GMT Received: from mercury.polarisnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQkbqs20358 for ; Fri, 9 Feb 2001 17:39:40 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Fri, 9 Feb 2001 09:41:43 -0800 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <1N85JRY6>; Fri, 9 Feb 2001 09:38:32 -0800 Message-ID: From: "Huang, Thomas" To: neil.2.harrison@bt.com, akyol@pluris.com, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: PHP negotiation Date: Fri, 9 Feb 2001 09:38: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 Bora and Neil: I would agree too. This entire PHP notion is not architecturally necessary. I studied Neil's oam document and the PHP would not help in terimating oam signals. /Thomas -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Thursday, February 08, 2001 1:33 AM To: akyol@pluris.com; Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: PHP negotiation I agree Bora....if you allow PHP, then where (in a functional architecture sense) is the LSP trail termination point? This has implications for: - defect detection - server->client layer adapatation - performance monitoring - protection switching neil > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: 07 February 2001 20:34 > To: Shahram Davari > Cc: mpls@UU.NET > Subject: RE: PHP negotiation > > > > I would have to add to this that when you have an MPLS diffserv > network that uses a combination of E and L_LSPs and PHP is > enabled, implementation of PHP in hardware becomes quite > complex due to amount of tables, exception cases and remapping. > > I think that PHP is a hack that was useful when routers > could not do at least two lookups when doing a POP. I think it > is an architectural mis-feature and hopefully with time, it will be > used less and eventually deprecated. > > Bora > > From owner-mpls@UU.NET Fri Feb 9 14:22:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29396 for ; Fri, 9 Feb 2001 14:22:42 -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 QQkbqz13441; Fri, 9 Feb 2001 19:19:06 GMT Received: by mail-control.mail.uu.net id QQkbqz03052 for mpls-outgoing; Fri, 9 Feb 2001 19:18:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbqz03033 for ; Fri, 9 Feb 2001 19:18:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbqz06942 for ; Fri, 9 Feb 2001 19:17:00 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbqz11148 for ; Fri, 9 Feb 2001 19:16:59 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA08857 for mpls@uu.net; Fri, 9 Feb 2001 14:16:58 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbqz02867 for ; Fri, 9 Feb 2001 19:16:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbqy28787 for ; Fri, 9 Feb 2001 19:13:21 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 QQkbqy28244 for ; Fri, 9 Feb 2001 19:13:21 GMT Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA23286; Fri, 9 Feb 2001 11:12:40 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f19JCS422740; Fri, 9 Feb 2001 11:12:28 -0800 (PST) Received: from chmetz-pc.cisco.com ([10.19.239.36]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA04609; Fri, 9 Feb 2001 11:12:19 -0800 (PST) Message-Id: <4.3.1.2.20010209141225.05509ba0@sj-email.cisco.com> X-Sender: chmetz@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 09 Feb 2001 14:14:35 -0800 To: "Ongun Yucesan" From: Chris Metz Subject: Re: GMPLS General Structure Cc: In-Reply-To: <002101c0929f$5b86f340$4592fea9@ee.bilkent.edu.tr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15443498==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_15443498==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Turner, B. et al., ""Generalized Multiprotocol Label Switching: An Overview of Routing and Management Enhancements", IEEE Communications, Feb. 2001 At 03:51 PM 02/09/2001 +0200, Ongun Yucesan wrote: > Hi > >I am new at the protocol and GMPLS issues so can you suggest me some >introductory Paper at the beginning level, mainly on How does a packet is >treated thru out its travel over each packetized, TDM, Optical, Fiber >switeched layers. Thank you for your attention. > >Ongun YUCESAN >M.Sc. stu at Bilkent University >EEE Dept. >Ankara > Chris Metz Lead IP Architect Solutions Integration Service Provider Line of Business Cisco Systems email: chmetz@cisco.com offic phone: 408-525-3275 home office: 914-241-0423 pager: 800-365-4578 Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm --=====================_15443498==_.ALT Content-Type: text/html; charset="us-ascii" Turner, B. et al., ""Generalized Multiprotocol Label Switching: An Overview of Routing and Management Enhancements", IEEE Communications, Feb. 2001


At 03:51 PM 02/09/2001 +0200, Ongun Yucesan wrote:
    Hi
 
I am new at the protocol and GMPLS issues so can you suggest me some introductory Paper at  the beginning level, mainly on How does a packet is treated thru out its travel over each packetized, TDM, Optical, Fiber switeched layers. Thank you for your attention.
 
Ongun YUCESAN
M.Sc. stu at Bilkent University
EEE Dept.
Ankara
  




Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: chmetz@cisco.com
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm  --=====================_15443498==_.ALT-- From owner-mpls@UU.NET Fri Feb 9 14:55:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00318 for ; Fri, 9 Feb 2001 14:55: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 QQkbrb17095; Fri, 9 Feb 2001 19:48:56 GMT Received: by mail-control.mail.uu.net id QQkbrb05856 for mpls-outgoing; Fri, 9 Feb 2001 19:48:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbrb05826 for ; Fri, 9 Feb 2001 19:47:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbrb17085 for ; Fri, 9 Feb 2001 19:46:48 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbrb14738 for ; Fri, 9 Feb 2001 19:46:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA11691 for mpls@uu.net; Fri, 9 Feb 2001 14:46:47 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbrb05732 for ; Fri, 9 Feb 2001 19:46:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbrb14568 for ; Fri, 9 Feb 2001 19:45:45 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 QQkbrb13525 for ; Fri, 9 Feb 2001 19:45:45 GMT Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA20687; Fri, 9 Feb 2001 11:45:15 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f19Jj6F25919; Fri, 9 Feb 2001 11:45:06 -0800 (PST) Received: from chmetz-pc.cisco.com ([10.19.239.36]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA18628; Fri, 9 Feb 2001 11:44:57 -0800 (PST) Message-Id: <4.3.1.2.20010209144327.05526c90@sj-email.cisco.com> X-Sender: chmetz@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 09 Feb 2001 14:44:54 -0800 To: ongun@ee.bilkent.edu.tr From: Chris Metz Subject: Re: GMPLS General Structure (Correction) Cc: In-Reply-To: <4.3.1.2.20010209141225.05509ba0@sj-email.cisco.com> References: <002101c0929f$5b86f340$4592fea9@ee.bilkent.edu.tr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17402670==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_17402670==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi- Apologies, referenced paper is from the Jan. 2001 issue. Thanks ... At 02:14 PM 02/09/2001 -0800, Chris Metz wrote: >Turner, B. et al., ""Generalized Multiprotocol Label Switching: An >Overview of Routing and Management Enhancements", IEEE Communications, >Feb. 2001 > > >At 03:51 PM 02/09/2001 +0200, Ongun Yucesan wrote: >> Hi >> >>I am new at the protocol and GMPLS issues so can you suggest me some >>introductory Paper at the beginning level, mainly on How does a packet >>is treated thru out its travel over each packetized, TDM, Optical, Fiber >>switeched layers. Thank you for your attention. >> >>Ongun YUCESAN >>M.Sc. stu at Bilkent University >>EEE Dept. >>Ankara >> > > > > >Chris Metz >Lead IP Architect >Solutions Integration >Service Provider Line of Business >Cisco Systems >email: chmetz@cisco.com >offic phone: 408-525-3275 >home office: 914-241-0423 >pager: 800-365-4578 >Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm Chris Metz Lead IP Architect Solutions Integration Service Provider Line of Business Cisco Systems email: chmetz@cisco.com offic phone: 408-525-3275 home office: 914-241-0423 pager: 800-365-4578 Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm --=====================_17402670==_.ALT Content-Type: text/html; charset="us-ascii" Hi-
Apologies, referenced paper is from the Jan. 2001 issue.

Thanks ...

At 02:14 PM 02/09/2001 -0800, Chris Metz wrote:
Turner, B. et al., ""Generalized Multiprotocol Label Switching: An Overview of Routing and Management Enhancements", IEEE Communications, Feb. 2001


At 03:51 PM 02/09/2001 +0200, Ongun Yucesan wrote:
    Hi
 
I am new at the protocol and GMPLS issues so can you suggest me some introductory Paper at  the beginning level, mainly on How does a packet is treated thru out its travel over each packetized, TDM, Optical, Fiber switeched layers. Thank you for your attention.
 
Ongun YUCESAN
M.Sc. stu at Bilkent University
EEE Dept.
Ankara
  




Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: chmetz@cisco.com
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm




Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: chmetz@cisco.com
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm  --=====================_17402670==_.ALT-- From owner-mpls@UU.NET Fri Feb 9 16:45:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02725 for ; Fri, 9 Feb 2001 16:45: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 QQkbri16422; Fri, 9 Feb 2001 21:42:35 GMT Received: by mail-control.mail.uu.net id QQkbri12410 for mpls-outgoing; Fri, 9 Feb 2001 21:42:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbri12398 for ; Fri, 9 Feb 2001 21:42:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbri14952 for ; Fri, 9 Feb 2001 21:41:29 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbri22183 for ; Fri, 9 Feb 2001 21:41:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA20126 for mpls@uu.net; Fri, 9 Feb 2001 16:41:28 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbri12294 for ; Fri, 9 Feb 2001 21:41:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbri11190 for ; Fri, 9 Feb 2001 21:39:53 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 QQkbri11839 for ; Fri, 9 Feb 2001 21:39: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 QAA28816; Fri, 9 Feb 2001 16:39:24 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch-janeiro-p7.cisco.com [171.69.209.211]) by bucket.cisco.com (Mirapoint) with ESMTP id AAD00740; Fri, 9 Feb 2001 16:39:49 -0500 (EST) Message-Id: <4.3.2.7.2.20010209223756.016cc680@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Feb 2001 22:40:58 -0500 To: Filipe Miguel Sousa , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Draft IETF MPLS TE MIB 05 usage question: Tunnel Table In-Reply-To: <3A83C3A7.95192289@inescporto.pt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Question about the mplsTunnelXcPointer Object. > >Can someone clarify me on this issue? > >In the MPLS TE MIB the mplsTunnelTable as the >mplsTunnelXcpointer. This object points to a row in the mplsXCTable >in the MPLS LSR MIB. My question is how the MPLS TE MIB as all >the XCsegments used by this tunnel if this pointer only points to >one row in a specif mib? I think that you could be asking two things above, so I will try to answer both questions. First, the XCindex is the major index for associated cross-connects on that particular LSR in the LSR MIB. If there are parallel links for example, then the XCindex notes the "group" of LSPs used for the tunnel. If you are asking why the totality of cross-connects (i.e.: throughout the network) is not available at the head-end LSR, then this is simple: because you need to go hop-by-hop checking the LSR MIB along the way. --Tom From owner-mpls@UU.NET Fri Feb 9 17:18:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03325 for ; Fri, 9 Feb 2001 17:18: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 QQkbrl23341; Fri, 9 Feb 2001 22:16:23 GMT Received: by mail-control.mail.uu.net id QQkbrl28856 for mpls-outgoing; Fri, 9 Feb 2001 22:15:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbrl28842 for ; Fri, 9 Feb 2001 22:15:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbrk02925 for ; Fri, 9 Feb 2001 22:14:49 GMT Received: from mailer.syr.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailer.syr.edu [128.230.18.29]) id QQkbrk21055 for ; Fri, 9 Feb 2001 22:14:49 GMT Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.00950FB3@mailer.syr.edu>; Fri, 9 Feb 2001 17:14:50 -0500 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id RAA17837 for ; Fri, 9 Feb 2001 17:14:48 -0500 (EST) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Fri, 9 Feb 2001 17:14:48 -0500 (EST) From: Ibrahim Okumus X-Sender: iokumus@rodan.syr.edu To: mpls@UU.NET Subject: Interdomain LSP setup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Does anybody know if there is any work done about 'interdomain LSP setup'? Thanks, _______________________________ Ibrahim Taner OKUMUS Electrical&Computer Eng. Dept. Syracuse University From owner-mpls@UU.NET Fri Feb 9 20:27:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05726 for ; Fri, 9 Feb 2001 20:27:34 -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 QQkbrx21692; Sat, 10 Feb 2001 01:25:33 GMT Received: by mail-control.mail.uu.net id QQkbrx23065 for mpls-outgoing; Sat, 10 Feb 2001 01:25:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbrx23052 for ; Sat, 10 Feb 2001 01:24:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbrx21765 for ; Sat, 10 Feb 2001 01:24:18 GMT Received: from evita2.cs.fredonia.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [141.238.30.9]) id QQkbrx19815 for ; Sat, 10 Feb 2001 01:24:17 GMT Received: from Zubairi.cs.fredonia.edu (zubairi.cs.fredonia.edu [141.238.30.211]) by evita2.cs.fredonia.edu (8.9.3/8.9.3) with ESMTP id UAA27592 for ; Fri, 9 Feb 2001 20:24:17 -0500 Message-ID: <00a501c09300$737c8f80$d31eee8d@cs.fredonia.edu> From: "Junaid Ahmed Zubairi" To: Subject: Attn Date: Fri, 9 Feb 2001 20:26:09 -0500 Organization: SUNY/Fredonia MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A1_01C092D6.89925860" 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_00A1_01C092D6.89925860 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A2_01C092D6.89925860" ------=_NextPart_001_00A2_01C092D6.89925860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable *********************************************************** Dr. Junaid Ahmed Zubairi Department of Mathematics and Computer Science SUNY/Fredonia, Fredonia, NY 14063 Tel: (716)673-4694 Fax:(508)256-8324 *********************************************************** ------=_NextPart_001_00A2_01C092D6.89925860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
***********************************************************
Dr. = Junaid=20 Ahmed Zubairi
Department of Mathematics and Computer=20 Science
SUNY/Fredonia, Fredonia, NY 14063
Tel:=20 (716)673-4694
Fax:(508)256-8324
***********************************= ************************
------=_NextPart_001_00A2_01C092D6.89925860-- ------=_NextPart_000_00A1_01C092D6.89925860 Content-Type: text/html; name="sci2001.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sci2001.htm" Content-Transfer-Encoding: quoted-printable sci'2001 call for papers

CALL FOR PAPERS
INVITED SESSION ON BANDWIDTH AND SERVICE QUALITY
MANAGEMENT IN THE INTERNET

5th World Multi-Conference on
Systemics, Cybernetics and Informatics (SCI = 2001)

Orlando, Florida, USA

July 22-25, 2001

Scope
Internet is undergoing a major transformation from being a best effort network to a well organized and well managed system with built-in intelligent protocols to provide predictable performance. Internet Engineering Task Force (IETF) has developed and incoporated a number of new protocols and techniques for managing and allocating network bandwidth and supporting service quality. For bandwidth allocation and management, COPS (Common Open Policy Service) clients and servers work to convey policy decisions and allocate and recover bandwidth across a domain. For QoS, RSVP provides quantitative guarantees by reserved paths and Diffserv provides qualitative assurances by using PHB (per hop behavior) and PDB (per domain behavior) for packets marked with DSCP (DS codepoints). MPLS installs LSP's (Label Switched Path) that satisfy Traffic Engineering requirements. As LSP's are set up and released, the available bandwidth metrics for various links are updated to reflect the current state of the network.

An invited session on managing bandwidth and service quality through these new protocols and techniques is being organized at the SCI'2001 conference. This session will serve as a forum to present and discuss the latest research and simulation results of works by researchers and developers across the world. Topics of interest include, but are not limited to:

Bandwidth management with COPS and MPLS
Effects of shaping and packet coloring on multimedia streams
Integrated operation of Intserv and Diffserv
Aggregation of flows for scaling of RSVP
VoIP performance over Diffserv networks
Traffic Engineering architecture for the Internet
Impact of congestion resolution schemes on QoS traffic
Voice over MPLS
Performance of RSVP-MPLS architecture
FR/MPLS Network and service interworking
Inter-provider MPLS signaling and LSP routing
Inter-domain tunneling rules
COPS Policy Server/Bandwidth Broker implementation issues

Paper = Submission
Extended abstracts or paper drafts should be sent as per the following format:
1. Extended abstract of 500 to 1500 words or paper drafts of 2000 to 2500 words, in English.
2. Names, addresses, telephone numbers, fax numbers and e-mail addresses of all authors, with the name of the contact author underlined.

The asbtracts or papers can be submitted in ps or pdf format to session organizer at zubairi@cs.fredonia.edu by March 2nd, 2001 via email.

Proceedings
Accepted papers, which should not exceed six single-spaced typed pages, will be published by means of paper and electronic proceedings. Best papers will be selected for awards and recommended for journal publications.
Multiple author books will be published by IIIS, based on the best-invited sessions, the best focus symposia or the best mini-conferences

Session Organizer:
Dr. Junaid Ahmed Zubairi
Department of Mathematics and Computer Science
College at Fredonia, State University of New York
Fredonia, NY 14063, USA
Tel: +1-716-673-4694
Fax: +1-508-256-8324
Email: zubairi@cs.fredonia.edu
WWW: http://www.cs.fredonia.edu/~= zubairi

Session = Co-organizer:
Wajdi Al-Khateeb
Electrical and Computer Engineering Department
Kulliyyah of Engineering, Intl' Islamic University Malaysia
Jalan Gombak, Kuala Lumpur 53100, Malaysia
Tel: +603-2056-4574
Fax: +603-2056-4853
Email: wajdi@iiu.edu.my

Important Dates:
Extended Abstract/Draft Paper due: March 2nd, 2001
Notification of Acceptance: March 16th, 2001
Camera read copy due: April 13th, 2001

If you have questions concerning session paper submission or session content, please contact the invited session organizers at the addresses above.

If you have questions concerning conference paper submissions or program, please contact Conference General Chair Prof. Nagib Callaos by email at ncallaos@usb.ve (Academic) or ncallaos@aol.com (Personal). For further information, see conference web site at
http://www.iiis.org/sci

 

------=_NextPart_000_00A1_01C092D6.89925860-- From owner-mpls@UU.NET Sun Feb 11 02:48:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21334 for ; Sun, 11 Feb 2001 02:48: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 QQkbwp14931; Sun, 11 Feb 2001 07:45:30 GMT Received: by mail-control.mail.uu.net id QQkbwo19766 for mpls-outgoing; Sun, 11 Feb 2001 07:44:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbwo19761 for ; Sun, 11 Feb 2001 07:44:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbwo06905 for ; Sun, 11 Feb 2001 07:43:36 GMT Received: from galileo5.galileo.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pop3.galileo.co.il [199.203.130.130]) id QQkbwo12194 for ; Sun, 11 Feb 2001 07:43:33 GMT Received: from galileo.co.il ([10.2.2.45]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id JAA15308 for ; Sun, 11 Feb 2001 09:43:52 +0200 (GMT-2) Message-ID: <3A86429B.FCA16BE9@galileo.co.il> Date: Sun, 11 Feb 2001 09:43:23 +0200 From: David Melman Reply-To: davidm@galileo.co.il Organization: Galileo Technology Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "'mpls'" Subject: MPLS Multicast - Forwarding Plane References: <01FAF65DEA16D4119B95009027E78F3149D963@il02exm26.comm.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit RFC 3031 MPLS Architecture briefly mentions the forwarding plane processing in section 4.8. "MPLS and Multicast": "When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children." Is this addressed in any more detail in any other draft? Thanks, David From owner-mpls@UU.NET Sun Feb 11 09:25:58 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09179 for ; Sun, 11 Feb 2001 09:25: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 QQkbxp06816; Sun, 11 Feb 2001 14:23:40 GMT Received: by mail-control.mail.uu.net id QQkbxp15771 for mpls-outgoing; Sun, 11 Feb 2001 14:23:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkbxp15761 for ; Sun, 11 Feb 2001 14:23:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbxp09002 for ; Sun, 11 Feb 2001 14:23:03 GMT Received: from mail.hkwebbank.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ipvpn085066.netvigator.com [203.198.158.66]) id QQkbxp15086 for ; Sun, 11 Feb 2001 14:23:00 GMT Received: from wchancsx1 (hkg-tgn-rwf-vty23.as.wcom.net [63.12.175.23]) by mail.hkwebbank.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DLK79KRZ; Sun, 11 Feb 2001 23:07:10 +0800 Message-ID: <023d01c09436$20097750$17af0c3f@jnpr.net> From: "Wayne" To: Subject: MPLS Label Space Date: Sun, 11 Feb 2001 22:08:05 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E7_01C09477.1B8E65F0" 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_01E7_01C09477.1B8E65F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Sorry for asking simple question. Why is there 2 label spaces for a LSR? Isn't the per interface label = space cover most of the cases? Why do we need the per platform space? = Could someone illustrate it with an example? Would a Ru and a Rd connect by several links one of the examples? Thanks very much. Wayne ------=_NextPart_000_01E7_01C09477.1B8E65F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Sorry for asking simple = question.
 
Why is there 2 label spaces for a LSR? = Isn't the=20 per interface label space cover most of the cases? Why do we need the = per=20 platform space? Could someone illustrate it with an = example?
 
Would a Ru and a Rd connect by several = links one of=20 the examples?
 
Thanks very much.
 
Wayne
------=_NextPart_000_01E7_01C09477.1B8E65F0-- From owner-mpls@UU.NET Sun Feb 11 09:40:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09328 for ; Sun, 11 Feb 2001 09:40: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 QQkbxq17071; Sun, 11 Feb 2001 14:38:06 GMT Received: by mail-control.mail.uu.net id QQkbxq16689 for mpls-outgoing; Sun, 11 Feb 2001 14:37:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbxq16682 for ; Sun, 11 Feb 2001 14:37:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkbxq07965 for ; Sun, 11 Feb 2001 14:37:17 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkbxq28399 for ; Sun, 11 Feb 2001 14:37:16 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id UAA21235 for ; Sun, 11 Feb 2001 20:14:51 GMT Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAAFB2; Sun, 11 Feb 2001 20:04:12 +0530 Date: Sun, 11 Feb 2001 20:23:20 +0530 (IST) From: "Nagabhushana Ramaswamy Nadig" X-Sender: bhushanr@boochi.alc.wipinfo.soft.net Reply-To: nagabhushana.ramaswamy@wipro.com To: Wayne cc: mpls@UU.NET Subject: Re: MPLS Label Space In-Reply-To: <023d01c09436$20097750$17af0c3f@jnpr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Why is there 2 label spaces for a LSR? >Isn't the per interface label space cover most of the cases? correct. >Why do we need the per platform space? Per platform is nothing but a generalised case of Per Interface where you will have a single LIB (Label Information Base) for all the interafces. To differentiate this we need a special value. It is the capability of your forwarding module that decides this behaviour of LDP. > Would a Ru and a Rd connect by several links one of the examples? > > Thanks very much. > > Wayne > From owner-mpls@UU.NET Sun Feb 11 10:28:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10069 for ; Sun, 11 Feb 2001 10:28: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 QQkbxt19275; Sun, 11 Feb 2001 15:27:07 GMT Received: by mail-control.mail.uu.net id QQkbxt02763 for mpls-outgoing; Sun, 11 Feb 2001 15:26:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkbxt02747 for ; Sun, 11 Feb 2001 15:26:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkbxt13736 for ; Sun, 11 Feb 2001 15:24:58 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkbxt17354 for ; Sun, 11 Feb 2001 15:24:53 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id VAA24021 for ; Sun, 11 Feb 2001 21:02:27 GMT Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA173F for ; Sun, 11 Feb 2001 20:51:48 +0530 Date: Sun, 11 Feb 2001 21:10:56 +0530 (IST) From: "Nagabhushana Ramaswamy Nadig" X-Sender: bhushanr@boochi.alc.wipinfo.soft.net Reply-To: Nagabhushana R To: mpls@UU.NET Subject: mpls over FR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is there any working implementation of mpls over a Frame Relay interface. If yes 1. Is the same frame relay interafce used for the LDP message (in general for any control plane message) exchange with some DLCI reservations or any other choice like using an Ethernet interface for control plane is deployed. 2. Similar thing holds for the multicast on FR as each packet with a multicast DLCI value has to be given to upper layers for processing. 3. Should the length of DLCI be carried in the Label field of a packet being forwarded. As it leads to new possibilities in ldp like distributing the same DLCI value to the same peer for different routes over the same session under different length categories and appropriate table look up can happen depending upon the length field. -- thanks for the reply Bhushana From owner-mpls@UU.NET Sun Feb 11 14:41:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12043 for ; Sun, 11 Feb 2001 14:41: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 QQkbyk15481; Sun, 11 Feb 2001 19:39:51 GMT Received: by mail-control.mail.uu.net id QQkbyk10463 for mpls-outgoing; Sun, 11 Feb 2001 19:39:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkbyk10456 for ; Sun, 11 Feb 2001 19:39:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkbyk16643 for ; Sun, 11 Feb 2001 19:39:14 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkbyk14533 for ; Sun, 11 Feb 2001 19:39:13 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id XAA27236 for ; Sun, 11 Feb 2001 23:00:55 GMT Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA25FB for ; Sun, 11 Feb 2001 22:50:16 +0530 Date: Sun, 11 Feb 2001 23:09:24 +0530 (IST) From: "Nagabhushana Ramaswamy Nadig" X-Sender: bhushanr@boochi.alc.wipinfo.soft.net Reply-To: Nagabhushana R To: mpls@UU.NET Subject: VC Directionality in FR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello *, I am a bit confused about the VC directionality in the FR session parameters(section 3.5.3 of LDP spec). What makes an FR interface uni-directional? Because assume a label 'X' is distributed in both the directions, still they will be appearing under different columns in my DLCI table and which entry I consider depends the direction of data flow! thanks for your reply Bhushana From owner-mpls@UU.NET Sun Feb 11 16:02:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12334 for ; Sun, 11 Feb 2001 16:02: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 QQkbyq07354; Sun, 11 Feb 2001 21:00:52 GMT Received: by mail-control.mail.uu.net id QQkbyq00632 for mpls-outgoing; Sun, 11 Feb 2001 21:00: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 QQkbyq29859 for ; Sun, 11 Feb 2001 21:00: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 QQkbyp11787 for ; Sun, 11 Feb 2001 20:59:16 GMT Received: from ex-imc2-corp.efi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.207.218.5]) id QQkbyp05210 for ; Sun, 11 Feb 2001 20:59:15 GMT Received: by ex-imc2-corp.efi.com with Internet Mail Service (5.5.2653.19) id <1VY41XS3>; Sun, 11 Feb 2001 12:59:15 -0800 Message-ID: From: Saurabh Shrivastava To: "'Wayne '" , "'mpls@UU.NET '" Subject: RE: MPLS Label Space Date: Sun, 11 Feb 2001 12:59:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0946D.7D5A9B50" 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_01C0946D.7D5A9B50 Content-Type: text/plain; charset="iso-8859-1" per platform label space will be used for protection switching. -----Original Message----- From: Wayne To: mpls@UU.NET Sent: 2/11/01 6:08 AM Subject: MPLS Label Space Hi all, Sorry for asking simple question. Why is there 2 label spaces for a LSR? Isn't the per interface label space cover most of the cases? Why do we need the per platform space? Could someone illustrate it with an example? Would a Ru and a Rd connect by several links one of the examples? Thanks very much. Wayne ------_=_NextPart_001_01C0946D.7D5A9B50 Content-Type: text/html; charset="iso-8859-1" RE: MPLS Label Space

per platform label space will be used for
protection switching.

-----Original Message-----
From: Wayne
To: mpls@UU.NET
Sent: 2/11/01 6:08 AM
Subject: MPLS Label Space

Hi all,
 
Sorry for asking simple question.
 
Why is there 2 label spaces for a LSR? Isn't the per interface label
space cover most of the cases? Why do we need the per platform space?
Could someone illustrate it with an example?
 
Would a Ru and a Rd connect by several links one of the examples?
 
Thanks very much.
 
Wayne

------_=_NextPart_001_01C0946D.7D5A9B50-- From owner-mpls@UU.NET Sun Feb 11 17:01:02 2001 Received: from cmr2.ash.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 RAA12945 for ; Sun, 11 Feb 2001 17:01: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 QQkbyt10104; Sun, 11 Feb 2001 21:59:16 GMT Received: by mail-control.mail.uu.net id QQkbyt15458 for mpls-outgoing; Sun, 11 Feb 2001 21:58: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 QQkbyt15453 for ; Sun, 11 Feb 2001 21:58: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 QQkbyt06111 for ; Sun, 11 Feb 2001 21:58:12 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkbyt14810 for ; Sun, 11 Feb 2001 21:58:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA29631 for mpls@uu.net; Sun, 11 Feb 2001 16:58:10 -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 QQkbyt15438 for ; Sun, 11 Feb 2001 21:57: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 QQkbyt22425 for ; Sun, 11 Feb 2001 21:57:19 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkbyt07203 for ; Sun, 11 Feb 2001 21:57:18 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA15698; Sun, 11 Feb 2001 13:57:17 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14983.2752.74000.497423@gargle.gargle.HOWL> Date: Sun, 11 Feb 2001 13:57:20 -0800 To: Saurabh Shrivastava Cc: "'Wayne '" , "'mpls@UU.NET '" Subject: RE: MPLS Label Space In-Reply-To: References: X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit It can also be used for LSPs established via targeted LDP. >>>>> "Saurabh" == Saurabh Shrivastava writes: Saurabh> per platform label space will be used for Saurabh> protection switching. Saurabh> -----Original Message----- From: Wayne To: Saurabh> mpls@UU.NET Sent: 2/11/01 6:08 AM Subject: MPLS Saurabh> Label Space Saurabh> Hi all, Saurabh> Sorry for asking simple question. Saurabh> Why is there 2 label spaces for a LSR? Isn't the Saurabh> per interface label space cover most of the cases? Saurabh> Why do we need the per platform space? Could Saurabh> someone illustrate it with an example? Saurabh> Would a Ru and a Rd connect by several links one of Saurabh> the examples? Saurabh> Thanks very much. Saurabh> Wayne Saurabh> Saurabh> Saurabh> RE: MPLS Label Saurabh> Space Saurabh>

per platform label space will be Saurabh> used for
protection Saurabh> switching.

Saurabh>

-----Original Message----- Saurabh>
From: Wayne
SIZE=2>To: mpls@UU.NET
SIZE=2>Sent: 2/11/01 6:08 AM
SIZE=2>Subject: MPLS Label Space

Saurabh>

Hi all,
SIZE=2> 
Sorry for Saurabh> asking simple question.
SIZE=2> 
Why is there Saurabh> 2 label spaces for a LSR? Isn't the per interface Saurabh> label
space cover most of Saurabh> the cases? Why do we need the per platform Saurabh> space?
Could someone Saurabh> illustrate it with an example?
SIZE=2> 
Would a Ru Saurabh> and a Rd connect by several links one of the Saurabh> examples?
  Saurabh>
Thanks very much.
SIZE=2> 
Wayne Saurabh>

Saurabh> Saurabh> From owner-mpls@UU.NET Mon Feb 12 06:47:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03771 for ; Mon, 12 Feb 2001 06:47: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 QQkcaw14326; Mon, 12 Feb 2001 11:44:10 GMT Received: by mail-control.mail.uu.net id QQkcaw09433 for mpls-outgoing; Mon, 12 Feb 2001 11:43:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcaw09425 for ; Mon, 12 Feb 2001 11:42:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcaw13229 for ; Mon, 12 Feb 2001 11:42:48 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkcaw13449 for ; Mon, 12 Feb 2001 11:42:47 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f1CBgJm09205; Mon, 12 Feb 2001 12:42:24 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569F1.00404483; Mon, 12 Feb 2001 12:41:58 +0100 Message-ID: <3A87CC05.A03B6265@alcatel.be> Date: Mon, 12 Feb 2001 12:41:57 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: davidm@galileo.co.il CC: "'mpls'" Subject: Re: MPLS Multicast - Forwarding Plane References: <01FAF65DEA16D4119B95009027E78F3149D963@il02exm26.comm.mot.com> <3A86429B.FCA16BE9@galileo.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Can you be more specific on the detail you are looking for? dirk David Melman wrote: > > RFC 3031 MPLS Architecture briefly mentions the forwarding plane processing in section 4.8. "MPLS and Multicast": > > "When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children." > > Is this addressed in any more detail in any other draft? > > Thanks, > > David -- From owner-mpls@UU.NET Mon Feb 12 08:00:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04833 for ; Mon, 12 Feb 2001 08:00: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 QQkcbb25629; Mon, 12 Feb 2001 12:57:42 GMT Received: by mail-control.mail.uu.net id QQkcbb27592 for mpls-outgoing; Mon, 12 Feb 2001 12:57:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcbb27587 for ; Mon, 12 Feb 2001 12:56:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcbb04180 for ; Mon, 12 Feb 2001 12:56:51 GMT Received: from server.nayna.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQkcbb06758 for ; Mon, 12 Feb 2001 12:56:50 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 EAA21109; Mon, 12 Feb 2001 04:56:48 -0800 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <3A87DFF2.7020403@nayna.com> Date: Mon, 12 Feb 2001 05:06:58 -0800 From: Sudheer Dharanikota Reply-To: sudheer@nayna.com Organization: Nayna Networks, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Ibrahim Okumus CC: mpls@UU.NET Subject: Re: Interdomain LSP setup References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Please look at draft-venkatachalam-interarea-mpls-te-01.txt draft-dharanikota-interarea-mpls-te-ext draft-kompella-mpls-multiarea-te draft-lee-mpls-te-exchange for your information. - sudheer Ibrahim Okumus wrote: > Hi, > Does anybody know if there is any work done about 'interdomain LSP setup'? > Thanks, > > _______________________________ > Ibrahim Taner OKUMUS > Electrical&Computer Eng. Dept. > Syracuse University From owner-mpls@UU.NET Mon Feb 12 09:04:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06643 for ; Mon, 12 Feb 2001 09:04: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 QQkcbf20945; Mon, 12 Feb 2001 13:59:45 GMT Received: by mail-control.mail.uu.net id QQkcbf15829 for mpls-outgoing; Mon, 12 Feb 2001 13:59:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcbf15812 for ; Mon, 12 Feb 2001 13:59:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcbf27058 for ; Mon, 12 Feb 2001 13:58:18 GMT Received: from WATERTOWN.litchfieldcomm.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 121.125.252.64.snet.net [64.252.125.121]) id QQkcbf23498 for ; Mon, 12 Feb 2001 13:58:18 GMT Subject: Question on Draft IETF MPLS LSR MIB 07: Segment and XC tables indexes Date: Mon, 12 Feb 2001 08:59:19 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC03124C@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: Question on Draft IETF MPLS LSR MIB 07: Segment and XC tables indexes Thread-Index: AcCU+/53ki08BD1DQgGudVjHAyI1hQ== From: "Dave Danenberg" content-class: urn:content-classes:message To: "mpls@uu.net" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Cc: "Thomas D. Nadeau" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA06643 I just noticed that Section 8 "Example of LSP Setup" and the MIB objects conflict. The example shows the XCTable referencing entries in the segmentTables, but the segment entries do not reference the XC table entry. then looking at the actual MIB you see the opposite: the in and out segment entries each reference the XC entry, but the XC entry does not reference the segments. I would think it would be useful for the XC entry to reference the segments as shown in the example. Starting from a tunnel entry, you can get to the XC entry, but then you can not get to the cross-connect segments. I would think that you would especially need the inSegment indexes for obtaining the inbound label. Is this something, that has been noted already? Will the Example vs MIB conflict be resolved? Will the segment indexes be added to the XC table? Thanx, Dave From owner-mpls@UU.NET Mon Feb 12 10:01:51 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09183 for ; Mon, 12 Feb 2001 10:01: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 QQkcbj11915; Mon, 12 Feb 2001 14:57:16 GMT Received: by mail-control.mail.uu.net id QQkcbj05694 for mpls-outgoing; Mon, 12 Feb 2001 14:56:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcbj05677 for ; Mon, 12 Feb 2001 14:56:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcbj11482 for ; Mon, 12 Feb 2001 14:55:46 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcbj19980 for ; Mon, 12 Feb 2001 14:55:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA07455 for mpls@uu.net; Mon, 12 Feb 2001 09:55:44 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcbj05443 for ; Mon, 12 Feb 2001 14:55:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcbj07251 for ; Mon, 12 Feb 2001 14:53:58 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 QQkcbj07391 for ; Mon, 12 Feb 2001 14:53:57 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 JAA11776; Mon, 12 Feb 2001 09:53:19 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAE02859; Mon, 12 Feb 2001 09:53:48 -0500 (EST) Message-Id: <4.3.2.7.2.20010212094906.07c05130@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Feb 2001 09:55:08 -0500 To: "Dave Danenberg" , "mpls@uu.net" From: "Thomas D. Nadeau" Subject: Re: Question on Draft IETF MPLS LSR MIB 07: Segment and XC tables indexes Cc: cheenu Srinivasan , Arun Viswanathan In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC03124C@WATERTOWN.litchfiel dcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >I just noticed that Section 8 "Example of LSP Setup" and the MIB objects >conflict. The example shows the XCTable referencing entries in the >segmentTables, but the segment entries do not reference the XC table >entry. then looking at the actual MIB you see the opposite: the in and >out segment entries each reference the XC entry, but the XC entry does >not reference the segments. > >I would think it would be useful for the XC entry to reference the >segments as shown in the example. Starting from a tunnel entry, you can >get to the XC entry, but then you can not get to the cross-connect >segments. I would think that you would especially need the inSegment >indexes for obtaining the inbound label. > >Is this something, that has been noted already? Will the Example vs MIB >conflict be resolved? In the example, the XC references (through its indexes) outSegment=1 and ifIndex=12,inSegment=21. There is no problem here as you can get back to the segments from the XCtable by simply looking at the indexes that you have for the object you are looking at in the XC table. From the InSegment table you can find all of the XCs which apply by looking at the XC indexes containing: (*,ifIndex,inSegmentIndex,*). From the other side you can do: (*,*,*,outSegmentIndex). >Will the segment indexes be added to the XC table? No; they are part of the indexes already. --Tom From owner-mpls@UU.NET Mon Feb 12 10:32:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10776 for ; Mon, 12 Feb 2001 10:32: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 QQkcbl13812; Mon, 12 Feb 2001 15:28:21 GMT Received: by mail-control.mail.uu.net id QQkcbl22520 for mpls-outgoing; Mon, 12 Feb 2001 15:27:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkcbl22515 for ; Mon, 12 Feb 2001 15:27: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 QQkcbl09567 for ; Mon, 12 Feb 2001 15:27:17 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 QQkcbl12470 for ; Mon, 12 Feb 2001 15:27:17 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 HAA24867 for ; Mon, 12 Feb 2001 07:27:33 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA10758 for mpls@uu.net; Mon, 12 Feb 2001 10:27:15 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcaw09580 for ; Mon, 12 Feb 2001 11:43:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcaw24972 for ; Mon, 12 Feb 2001 11:43:17 GMT Received: from mailgate.ul.ie by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ul.ie [136.201.1.23]) id QQkcaw14396 for ; Mon, 12 Feb 2001 11:43:16 GMT Received: from exch-staff3.ul.ie ([136.201.1.114]) by ul.ie (PMDF V5.2-32 #41949) with ESMTP id <0G8N006ON767C8@ul.ie> for mpls@UU.NET; Mon, 12 Feb 2001 11:42:07 +0000 (GMT) Received: from ul.ie (stone.staff9.ul.ie [136.201.148.76]) by exch-staff3.ul.ie with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1TDPS7VF; Mon, 12 Feb 2001 11:45:30 +0000 Date: Mon, 12 Feb 2001 11:42:21 +0000 From: Istvan Matyasovszki Subject: LS Table To: "mpls@UU.NET" Message-id: <3A87CC1D.52565451@ul.ie> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can you please give me one or more examples of LS Table(s) ? I apologise for putting this question which is for sure trivial to some people but I'm a newbie in the field of Label Switching. Thank You, Best Regards -istvan -- Istvan Matyasovszki ECE Department Istvan.Matyasovszki@ul.ie University of Limerick /* nur tote fische schwimmen mit dem strom */ From owner-mpls@UU.NET Mon Feb 12 10:45:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11493 for ; Mon, 12 Feb 2001 10:45: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 QQkcbm14722; Mon, 12 Feb 2001 15:42:28 GMT Received: by mail-control.mail.uu.net id QQkcbm23970 for mpls-outgoing; Mon, 12 Feb 2001 15:41:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcbm23951 for ; Mon, 12 Feb 2001 15:41:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcbm28451 for ; Mon, 12 Feb 2001 15:41:06 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkcbm12727 for ; Mon, 12 Feb 2001 15:41:06 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12321; Mon, 12 Feb 2001 10:41:04 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00512; Mon, 12 Feb 2001 10:41:05 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LJXM9>; Mon, 12 Feb 2001 10:40:49 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446C07@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Thomas D. Nadeau'" , mpls@UU.NET Subject: RE: Draft IETF MPLS TE MIB 05 usage question: Tunnel Table Date: Mon, 12 Feb 2001 10:40:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom! This is a follow-up question based on your reply. In your reply, you pointed-out "the XCindex notes the "group" of LSPs used for the tunnel". If this was the main reason for having the mplsXCIndex in the mplsXCTable, then I might have mis-interpreted the MIB definitions related to the mplsXCTable. I will appreciate, if you can clarify the following. Given the following context: --------------------------- (1) mplsLspId is not a part of the index into the mplsXCTable and is optional for implementation [LSR-MIB mplsXCTable definition and conformance statements] (1) "It supports point-to-point, point-to-multipoint and multipoint-to-point connections" [mplsXCTable description, in LSR-MIB] (2) "mplsTunnelTable does not define the in and out segments forming the tunnel. Instead, these are defined by creating rows in the in-segment and out-segment tables, defining relationships in the cross-connect table and referring to these rows in the mplsTunnelTable using a cross-connect index, mplsTunnelXCIndex. These segment and cross-connect related objects are defined in LSRMIB." [MPLS-TE-MIB Section 6.1] (3)"Uniquely identifies an instance of a tunnel. It is useful to identify multiple instances of tunnels for the purposes of backup and parallel tunnels." [Description of mplsTunnelInstance in MPLS-TE-MIB] I interpreted the following statement: ------------------------------------- "-cross-connect index mplsXCIndex that uniquely identifies a group of cross-connect entries" [Description in the mplsXCEntry] as: --- (a) cross-connect index mplsXCINdex uniquely identifies a group of cross-connects entries, that belong to the __same LSP___. [NOT a group of independent LSPs, as you pointed out in your reply.] (b) The main (and only) reason for having the mplsXCIndex, is to represent a LSP (inside the switch)with different cast types: point-to-point point-to-multipoint and multipoint-to-point. (c) mplsTunnelXCPointer is used to associated a particular LSP with the mpls tunnel defined in the mplsTunnelTable. (d) Parallel tunnels are abstracted in mplsTunnelTable using the mplsTunnelIndex and mplsTunnelInstance. Please correct me, if I mis-interpreted the MIB. Thanks, sanjay -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, February 09, 2001 10:41 PM To: Filipe Miguel Sousa; mpls@UU.NET Subject: Re: Draft IETF MPLS TE MIB 05 usage question: Tunnel Table >Question about the mplsTunnelXcPointer Object. > >Can someone clarify me on this issue? > >In the MPLS TE MIB the mplsTunnelTable as the >mplsTunnelXcpointer. This object points to a row in the mplsXCTable >in the MPLS LSR MIB. My question is how the MPLS TE MIB as all >the XCsegments used by this tunnel if this pointer only points to >one row in a specif mib? I think that you could be asking two things above, so I will try to answer both questions. First, the XCindex is the major index for associated cross-connects on that particular LSR in the LSR MIB. If there are parallel links for example, then the XCindex notes the "group" of LSPs used for the tunnel. If you are asking why the totality of cross-connects (i.e.: throughout the network) is not available at the head-end LSR, then this is simple: because you need to go hop-by-hop checking the LSR MIB along the way. --Tom From owner-mpls@UU.NET Mon Feb 12 11:30:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13612 for ; Mon, 12 Feb 2001 11:30: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 QQkcbp21140; Mon, 12 Feb 2001 16:26:39 GMT Received: by mail-control.mail.uu.net id QQkcbp12318 for mpls-outgoing; Mon, 12 Feb 2001 16:26:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcbp12298 for ; Mon, 12 Feb 2001 16:25:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcbp10456 for ; Mon, 12 Feb 2001 16:25:54 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcbp17224 for ; Mon, 12 Feb 2001 16:25:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA15790 for mpls@uu.net; Mon, 12 Feb 2001 11:25:52 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcbp12229 for ; Mon, 12 Feb 2001 16:25:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcbp07387 for ; Mon, 12 Feb 2001 16:23:40 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 QQkcbp16545 for ; Mon, 12 Feb 2001 16:23:40 GMT Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA22228; Mon, 12 Feb 2001 08:21:52 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1CGLju21836; Mon, 12 Feb 2001 08:21:45 -0800 (PST) Received: from chmetz-pc.cisco.com ([10.19.239.36]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA06989; Mon, 12 Feb 2001 08:21:36 -0800 (PST) Message-Id: <4.3.1.2.20010212111932.00e35900@sj-email.cisco.com> X-Sender: chmetz@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 12 Feb 2001 11:23:56 -0800 To: sudheer@nayna.com From: Chris Metz Subject: Re: Interdomain LSP setup Cc: Ibrahim Okumus , mpls@UU.NET In-Reply-To: <3A87DFF2.7020403@nayna.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi- Also check out: draft-ietf-mpls-bgp4-mpls-05.txt draft-rosen-rfc2547bis-02.txt Thanks ... At 05:06 AM 02/12/2001 -0800, Sudheer Dharanikota wrote: >Please look at > >draft-venkatachalam-interarea-mpls-te-01.txt >draft-dharanikota-interarea-mpls-te-ext >draft-kompella-mpls-multiarea-te >draft-lee-mpls-te-exchange > >for your information. > >- sudheer > >Ibrahim Okumus wrote: > >>Hi, >>Does anybody know if there is any work done about 'interdomain LSP setup'? >>Thanks, >> _______________________________ >> Ibrahim Taner OKUMUS >> Electrical&Computer Eng. Dept. Syracuse University > Chris Metz Lead IP Architect Solutions Integration Service Provider Line of Business Cisco Systems email: chmetz@cisco.com offic phone: 408-525-3275 home office: 914-241-0423 pager: 800-365-4578 Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm From owner-mpls@UU.NET Mon Feb 12 11:44:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14275 for ; Mon, 12 Feb 2001 11:44: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 QQkcbq13212; Mon, 12 Feb 2001 16:41:29 GMT Received: by mail-control.mail.uu.net id QQkcbq13912 for mpls-outgoing; Mon, 12 Feb 2001 16:41: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 QQkcbq13857 for ; Mon, 12 Feb 2001 16:40: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 QQkcbq27085 for ; Mon, 12 Feb 2001 16:39:52 GMT Received: from mail.hkwebbank.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ipvpn085066.netvigator.com [203.198.158.66]) id QQkcbq07614 for ; Mon, 12 Feb 2001 16:39:50 GMT Received: from wchancsx1 (hkg-tgn-rwf-vty20.as.wcom.net [63.12.175.20]) by mail.hkwebbank.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DLK79K4G; Tue, 13 Feb 2001 01:24:03 +0800 Message-ID: <002601c09512$68a4e1c0$14af0c3f@jnpr.net> From: "Wayne" To: "Bora Akyol" , "Saurabh Shrivastava" Cc: References: <14983.2752.74000.497423@gargle.gargle.HOWL> Subject: Re: MPLS Label Space Date: Tue, 13 Feb 2001 00:39:45 +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 One more example I found in the LDP spec is that an Ethernet interface also use per platform label space. Because it is not having any link identifier. But I wonder if a VLAN tagged interface can use per interface label space. Wayne Another situation would be where the LSR had two links to the peer, one of which is ethernet (and uses per platform labels) and the other of which is ATM. ----- Original Message ----- From: "Bora Akyol" To: "Saurabh Shrivastava" Cc: "'Wayne '" ; Sent: Monday, February 12, 2001 5:57 AM Subject: RE: MPLS Label Space > > It can also be used for LSPs established via targeted LDP. > > >>>>> "Saurabh" == Saurabh Shrivastava writes: > > Saurabh> per platform label space will be used for > Saurabh> protection switching. > > Saurabh> -----Original Message----- From: Wayne To: > Saurabh> mpls@UU.NET Sent: 2/11/01 6:08 AM Subject: MPLS > Saurabh> Label Space > > Saurabh> Hi all, > > Saurabh> Sorry for asking simple question. > > Saurabh> Why is there 2 label spaces for a LSR? Isn't the > Saurabh> per interface label space cover most of the cases? > Saurabh> Why do we need the per platform space? Could > Saurabh> someone illustrate it with an example? > > Saurabh> Would a Ru and a Rd connect by several links one of > Saurabh> the examples? > > Saurabh> Thanks very much. > > Saurabh> Wayne > > Saurabh> > Saurabh> > > Saurabh> RE: MPLS Label > Saurabh> Space > > Saurabh>

per platform label space will be > Saurabh> used for
protection > Saurabh> switching.

> > Saurabh>

-----Original Message----- > Saurabh>
From: Wayne
Saurabh> SIZE=2>To: mpls@UU.NET
Saurabh> SIZE=2>Sent: 2/11/01 6:08 AM
Saurabh> SIZE=2>Subject: MPLS Label Space

> > Saurabh>

Hi all,
Saurabh> SIZE=2> 
Sorry for > Saurabh> asking simple question.
Saurabh> SIZE=2> 
Why is there > Saurabh> 2 label spaces for a LSR? Isn't the per interface > Saurabh> label
space cover most of > Saurabh> the cases? Why do we need the per platform > Saurabh> space?
Could someone > Saurabh> illustrate it with an example?
Saurabh> SIZE=2> 
Would a Ru > Saurabh> and a Rd connect by several links one of the > Saurabh> examples?
  > Saurabh>
Thanks very much.
Saurabh> SIZE=2> 
Wayne > Saurabh>

> > Saurabh> > Saurabh> > > From owner-mpls@UU.NET Mon Feb 12 16:05:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21537 for ; Mon, 12 Feb 2001 16:05: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 QQkcci04276; Mon, 12 Feb 2001 21:02:46 GMT Received: by mail-control.mail.uu.net id QQkcci10059 for mpls-outgoing; Mon, 12 Feb 2001 21:02: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 QQkcci09781 for ; Mon, 12 Feb 2001 21:02:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcci22522 for ; Mon, 12 Feb 2001 21:00:59 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 QQkcci13785 for ; Mon, 12 Feb 2001 21:00:58 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 NAA26312 for ; Mon, 12 Feb 2001 13:01:12 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA11963 for mpls@uu.net; Mon, 12 Feb 2001 16:00:55 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcch02535 for ; Mon, 12 Feb 2001 20:50:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcch26284 for ; Mon, 12 Feb 2001 20:49:57 GMT Received: from motgate.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate.mot.com [129.188.136.100]) id QQkcch26774 for ; Mon, 12 Feb 2001 20:49:56 GMT Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA20177 for ; Mon, 12 Feb 2001 13:49:55 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA20718 for ; Mon, 12 Feb 2001 13:49:54 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 12 Feb 2001 14:49:51 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D971@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'mpls'" Subject: Multicast in Cisco/Nortel devices Date: Mon, 12 Feb 2001 14:49:51 -0600 X-MS-TNEF-Correlator: <01FAF65DEA16D4119B95009027E78F3149D971@il02exm26.comm.mot.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09535.586F2C20" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C09535.586F2C20 Content-Type: text/plain; charset="iso-8859-1" All, Do any of the Cisco or Nortel MPLS capable devices do multicast with MPLS? I have not found any reference to multicast with MPLS on their websites, although I have found a lot of info about MPLS support in general. I was wondering if all multicast traffic are still L3 routed, even if MPLS was enabled in general. Any pointers in this direction will be helpful. Thanks, Vidya ------_=_NextPart_000_01C09535.586F2C20 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjQUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcCAAwADgAxADMAAQBZAQEggAMADgAAANEHAgAM AA4AMQAzAAEAWQEBCYABACEAAAA1NzRBMzBBOTE4MDFENTExOUJEMjAwOTAyN0U3OEYzMQDkBgEE gAEAIgAAAE11bHRpY2FzdCBpbiBDaXNjby9Ob3J0ZWwgZGV2aWNlcwBkDAENgAQAAgAAAAIAAgAB A5AGAFAHAAAxAAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAAeAAGACCAGAAAAAADA AAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUACwACgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAA AAADAAOACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAA AAOFAAAAAAAACwAFgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAAAADAAAAA AAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAIgAggBgAA AAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAmACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEA AAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAA AMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAAyACyAGAAAAAADAAAAAAAAARgAAAAAAiAAA AAAAAAsADYALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAAgEJEAEAAACoAQAApAEAAAkCAABM WkZ1/1k9LwMACgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGS dgiQd2sLgGQ0DGAeYwBQCwMLtRFgbGwsIwqiCoBEbyAAcHkgAG9mIHRoZSBDrwQABaAU0AXATgkR ZQMgyE1QTAXwY2EKsAJgVxUwAQASIGMHkWQUgG3IdWx0DeBhcwVAA/BDFRAWQz8gSSAQ8HbZFTBu bwVAAhB1EoAUk/0JcGYEkAnwF2AVABe/FlOLAiAVAmkFwHdlYgCQWRYQcywUkBtgaAhgZ/cYoBkl GdUgCQAFQBThC4A3AhAUkAbgdQVAFlNzdcxwcAkRH5EgZwnwBJD1B0AuGRF3GDAYYAIgBIF9C4Bn H5AU8AdAAyAbSHT/IZABIA3gFJAJcCCQGAAjIfxMMxpgIBEJgB2QFzAJ8H8i0hZTIgIJ8BbSGhAh KkH/FLEg0AuAFhARECESFRAEAH8XEBzgBZAYAByBA/AjIWKjFTAVIGxwZhtQLhQUZRQUVBDwbmsd gBQUVrBpZHlhFBQR4QAtgB4AcAABAAAAIgAAAE11bHRpY2FzdCBpbiBDaXNjby9Ob3J0ZWwgZGV2 aWNlcwAAAAIBcQABAAAAFgAAAAHAlTVYI6DZhVcA+xHVvc8AEKTFY/4AAAsAAgABAAAAAwDeP69v AABAADkAICxvWDWVwAEDAPE/CQQAAB4AMUABAAAABwAAAENWTjA2NQAAAwAaQAAAAAAeADBAAQAA AAcAAABDVk4wNjUAAAMAGUAAAAAAAwD9P+QEAAADACYAAAAAAAMANgAAAAAAAwCAEP////8CAUcA AQAAAC8AAABjPVVTO2E9IDtwPW1vdDtsPUlMMDJFWE0yNi0wMTAyMTIyMDQ5NTFaLTk2NjI4AAAC Afk/AQAAAEcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TU9UL09VPUxNUFNJTDAy L0NOPVJFQ0lQSUVOVFMvQ049Q1ZOMDY1AAAeAPg/AQAAABcAAABOYXJheWFuYW4gVmlkeWEtQ1ZO MDY1AAAeADhAAQAAAAcAAABDVk4wNjUAAAIB+z8BAAAARwAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAvTz1NT1QvT1U9TE1QU0lMMDIvQ049UkVDSVBJRU5UUy9DTj1DVk4wNjUAAB4A+j8B AAAAFwAAAE5hcmF5YW5hbiBWaWR5YS1DVk4wNjUAAB4AOUABAAAABwAAAENWTjA2NQAAQAAHMEbd bFg1lcABQAAIMJBzUlg1lcABHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAIgAAAE11bHRpY2FzdCBp biBDaXNjby9Ob3J0ZWwgZGV2aWNlcwAAAB4ANRABAAAAQAAAADwwMUZBRjY1REVBMTZENDExOUI5 NTAwOTAyN0U3OEYzMTQ5RDk3MUBpbDAyZXhtMjYuY29tbS5tb3QuY29tPgALACkAAAAAAAsAIwAA AAAAAwAGEIwrRwADAAcQNQEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABBTEwsRE9BTllP RlRIRUNJU0NPT1JOT1JURUxNUExTQ0FQQUJMRURFVklDRVNET01VTFRJQ0FTVFdJVEhNUExTP0lI QVZFTk9URk9VTkRBTllSRUZFUkVOQ0VUT01VTFRJQ0FTAAAAAAIBfwABAAAAQAAAADwwMUZBRjY1 REVBMTZENDExOUI5NTAwOTAyN0U3OEYzMTQ5RDk3MUBpbDAyZXhtMjYuY29tbS5tb3QuY29tPgAJ ag== ------_=_NextPart_000_01C09535.586F2C20-- From owner-mpls@UU.NET Mon Feb 12 16:17:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21781 for ; Mon, 12 Feb 2001 16:17: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 QQkcci23930; Mon, 12 Feb 2001 21:14:33 GMT Received: by mail-control.mail.uu.net id QQkcci18819 for mpls-outgoing; Mon, 12 Feb 2001 21:14:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcci18803 for ; Mon, 12 Feb 2001 21:14:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcci17921 for ; Mon, 12 Feb 2001 21:13:52 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcci03471 for ; Mon, 12 Feb 2001 21:13:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA10677 for mpls@uu.net; Mon, 12 Feb 2001 16:13: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 QQkcci18772 for ; Mon, 12 Feb 2001 21:13: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 QQkcci27308 for ; Mon, 12 Feb 2001 21:12:19 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 QQkcci18121 for ; Mon, 12 Feb 2001 21:12:19 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA15928; Mon, 12 Feb 2001 13:12:34 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f1CLCFD19742; Mon, 12 Feb 2001 13:12:15 -0800 (PST) Received: from chmetz-pc.cisco.com ([10.19.239.36]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id NAA20221; Mon, 12 Feb 2001 13:12:13 -0800 (PST) Message-Id: <4.3.1.2.20010212161041.023341e0@sj-email.cisco.com> X-Sender: chmetz@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 12 Feb 2001 16:14:27 -0800 To: Narayanan Vidya-CVN065 From: Chris Metz Subject: Re: Multicast in Cisco/Nortel devices Cc: "'mpls'" In-Reply-To: <01FAF65DEA16D4119B95009027E78F3149D971@il02exm26.comm.mot. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Vidya- Check out: ftp://ftpeng.cisco.com/ipmulticast/index.html#Tagswitching Thanks ... At 02:49 PM 02/12/2001 -0600, Narayanan Vidya-CVN065 wrote: >All, >Do any of the Cisco or Nortel MPLS capable devices do multicast with MPLS? >I have not found any reference to multicast with MPLS on their websites, >although I have found a lot of info about MPLS support in general. I was >wondering if all multicast traffic are still L3 routed, even if MPLS was >enabled in general. Any pointers in this direction will be helpful. > >Thanks, >Vidya Chris Metz Lead IP Architect Solutions Integration Service Provider Line of Business Cisco Systems email: chmetz@cisco.com offic phone: 408-525-3275 home office: 914-241-0423 pager: 800-365-4578 Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm From owner-mpls@UU.NET Mon Feb 12 20:40:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25170 for ; Mon, 12 Feb 2001 20:40: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 QQkcda26031; Tue, 13 Feb 2001 01:37:19 GMT Received: by mail-control.mail.uu.net id QQkcda04675 for mpls-outgoing; Tue, 13 Feb 2001 01:36:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcda04664 for ; Tue, 13 Feb 2001 01:36:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcda02786 for ; Tue, 13 Feb 2001 01:36:07 GMT Received: from apollo.mctr.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQkcda23344 for ; Tue, 13 Feb 2001 01:36:06 GMT Received: from atlantis.mctr.umbc.edu (atlantis.mctr.umbc.edu [130.85.101.141]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id UAA24912 for ; Mon, 12 Feb 2001 20:36:05 -0500 (EST) Received: from localhost (mpls@localhost) by atlantis.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id UAA16838 for ; Mon, 12 Feb 2001 20:36:56 -0500 (EST) X-Authentication-Warning: atlantis.mctr.umbc.edu: mpls owned process doing -bs Date: Mon, 12 Feb 2001 20:36:56 -0500 (EST) From: MPLS X-Sender: mpls@atlantis.mctr.umbc.edu To: "'mpls'" Subject: Shared Risk Link Group (SRLG) In-Reply-To: <4.3.1.2.20010212161041.023341e0@sj-email.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I had a question regarding the SRLG identifier mentioned in the Generalized MPLS draft. Is this concept valid only for optical networks and links or can it be extended to non-optical networks as well ? In general, if I have a (non-optical) network, can I identify group(s) of links that might fail together ? Thanks Gargi From owner-mpls@UU.NET Mon Feb 12 23:26:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28707 for ; Mon, 12 Feb 2001 23:26: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 QQkcdl13761; Tue, 13 Feb 2001 04:25:00 GMT Received: by mail-control.mail.uu.net id QQkcdl26280 for mpls-outgoing; Tue, 13 Feb 2001 04:24: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 QQkcdl26275 for ; Tue, 13 Feb 2001 04:24:37 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 QQkcdl13305 for ; Tue, 13 Feb 2001 04:23:56 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 QQkcdl11508 for ; Tue, 13 Feb 2001 04:23:55 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 UAA20214; Mon, 12 Feb 2001 20:23:43 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id UAA15849; Mon, 12 Feb 2001 20:20:36 -0800 (PST) Date: Mon, 12 Feb 2001 20:20:36 -0800 (PST) From: Kireeti Kompella Message-Id: <200102130420.UAA15849@kummer.juniper.net> To: akyol@pluris.com, dareks@nortelnetworks.com Subject: Re: Handling multiple IP addresses on PPP interfaces with RSVP-TE Cc: dkatz@juniper.net, kireeti@juniper.net, mpls@UU.NET, swallow@cisco.com, tli@procket.com In-Reply-To: <3A801B38.A5356BF1@americasm01.nt.com> Sender: owner-mpls@UU.NET Precedence: bulk > I am not from OSPF land :) and I don't have the latest version of the > OSPF TE Extensions draft handy but I recall a statement in the draft > indicating that each sub-TLV of the Link TLV may occur only once. As you say, lifting this restriction is the easy way out, and makes OSPF compatible with ISIS. Forthcoming. > In addition, the OSPF TE Extensions draft states that only a single Link > TLV may occur in an Opaque LSA of Type 10 implying multiple Opaque LSAs > for multiple Link TLVs. This again has a potential for a negative impact > to OSPF operation in particular flooding. The question therefore is > whether this restriction can also be lifted, i.e. Opaque LSA may carry > more than one Link TLV. This is actually a Good Thing. Why would this affect flooding negatively? It would appear useful to decouple the flooding of independent TE links. Kireeti. From owner-mpls@UU.NET Tue Feb 13 01:36:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03665 for ; Tue, 13 Feb 2001 01:36: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 QQkcdu22288; Tue, 13 Feb 2001 06:34:36 GMT Received: by mail-control.mail.uu.net id QQkcdu01357 for mpls-outgoing; Tue, 13 Feb 2001 06:34:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcdu01343 for ; Tue, 13 Feb 2001 06:34:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcdu10642; Tue, 13 Feb 2001 06:32:53 GMT Received: from mx1out.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQkcdu28496; Tue, 13 Feb 2001 06:32:52 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id BAA27395; Tue, 13 Feb 2001 01:32:42 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id GAA1065773; Tue, 13 Feb 2001 06:32:41 GMT X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Tue, 13 Feb 2001 06:32:41 +0000 From: Vijay Gill X-X-Sender: To: , , cc: , , Subject: CCAMP charter and agenda items request for the Minneapolis IETF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk The CCAMP charter and mailing list information are at: http://www.ietf.org/html.charters/ccamp-charter.html We've requested a 2.5 hour slot at the Minn. IETF. Once we get the allocation, the information will be sent to the ccamp mailing list. Subscription information is in the charter at the URL above. Please send requests for agenda items to us. Priority will be given to new individual submissions, and works in progress that are being moved under CCAMP. thanks kireeti and vijay From owner-mpls@UU.NET Tue Feb 13 02:00:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06983 for ; Tue, 13 Feb 2001 02:00: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 QQkcdv13938; Tue, 13 Feb 2001 06:57:28 GMT Received: by mail-control.mail.uu.net id QQkcdv02771 for mpls-outgoing; Tue, 13 Feb 2001 06:57: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 QQkcdv02764 for ; Tue, 13 Feb 2001 06:57: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 QQkcdv22369 for ; Tue, 13 Feb 2001 06:56:48 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 QQkcdv12270 for ; Tue, 13 Feb 2001 06:56:48 GMT Received: from juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id WAA24500; Mon, 12 Feb 2001 22:56:16 -0800 (PST) Message-Id: <200102130656.WAA24500@red.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: MPLS cc: mpls@UU.NET Subject: Re: Shared Risk Link Group (SRLG) In-Reply-To: Your message of "Mon, 12 Feb 2001 20:36:56 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Feb 2001 22:53:08 -0800 From: Kireeti Kompella Sender: owner-mpls@UU.NET Precedence: bulk > I had a question regarding the SRLG identifier mentioned in the > Generalized MPLS draft. Is this concept valid only for optical networks > and links or can it be extended to non-optical networks as well ? Valid for all. > In general, if I have a (non-optical) network, can I identify > group(s) of links that might fail together ? Sure. Kireeti. From owner-mpls@UU.NET Tue Feb 13 02:15:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13664 for ; Tue, 13 Feb 2001 02:15: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 QQkcdw29814; Tue, 13 Feb 2001 07:12:08 GMT Received: by mail-control.mail.uu.net id QQkcdw17278 for mpls-outgoing; Tue, 13 Feb 2001 07:11:45 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 QQkcdw17269 for ; Tue, 13 Feb 2001 07:11:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcdw14491 for ; Tue, 13 Feb 2001 07:10:11 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkcdw26238 for ; Tue, 13 Feb 2001 07:10:10 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f1D7A9L11082 for ; Tue, 13 Feb 2001 08:10:09 +0100 (MET) Received: from alcatel.be ([138.203.253.198]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569F2.00275767; Tue, 13 Feb 2001 08:09:43 +0100 Message-ID: <3A88DC64.ADBB9866@alcatel.be> Date: Tue, 13 Feb 2001 08:04:04 +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: [Fwd: MPLS LSR MIB] Content-Type: multipart/mixed; boundary="------------9A7DFD14484E893929E40D61" Sender: owner-mpls@UU.NET Precedence: bulk Dit is een multi-gedeelten-bericht in MIME-formaat. --------------9A7DFD14484E893929E40D61 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any opinions? Francis. --------------9A7DFD14484E893929E40D61 Content-Type: message/rfc822 Content-Disposition: inline Received: from relay2.alcatel.be ([138.203.146.196]) by bemta001.net.alcatel.be (Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) with SMTP id C12569E0.00366BCF; Fri, 26 Jan 2001 10:54:25 +0100 Received: from mxin001.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with ESMTP id f0Q9pHR05864 for ; Fri, 26 Jan 2001 10:51:17 +0100 (MET) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by mxin001.alcatel.be (8.10.1/8.10.1) with ESMTP id f0Q9sNd11198 for ; Fri, 26 Jan 2001 10:54:23 +0100 (MET) 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 QQjznw05528; Thu, 25 Jan 2001 21:00:41 GMT Received: by mail-control.mail.uu.net id QQjznv06730 for mpls-outgoing; Thu, 25 Jan 2001 20:59: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 QQjznv06723 for ; Thu, 25 Jan 2001 20:59: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 QQjznv22839 for ; Thu, 25 Jan 2001 20:58:04 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjznv01079 for ; Thu, 25 Jan 2001 20:58:03 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0PKw2r08495; Thu, 25 Jan 2001 21:58:02 +0100 (MET) Received: from alcatel.be ([138.203.253.220]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569DF.007328A7; Thu, 25 Jan 2001 21:57:51 +0100 Message-ID: <3A709213.1470E652@alcatel.be> Date: Thu, 25 Jan 2001 21:52:36 +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 CC: Anand Gorti Subject: MPLS LSR MIB Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Looking into the MPLS LSR MIB I have a question concerning penultimate hop popping. In the case of penultimate hop popping, an out segment is created in the mplsOutSegmentTable with its mplsOutSegmentPushTopLabel object set to FALSE. According to my understanding of the MPLS LSR MIB * the mplsOutSegmentOctets object in this case should be incremented with the number of bytes of the mpls packet payload only (e.g. IP packet length), not including any MPLS header bytes. Is this what the MIB suggests to do in this case or am I missing something? Francis. --------------9A7DFD14484E893929E40D61-- From owner-mpls@UU.NET Tue Feb 13 03:02:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14100 for ; Tue, 13 Feb 2001 03:02: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 QQkcdz28460; Tue, 13 Feb 2001 07:59:42 GMT Received: by mail-control.mail.uu.net id QQkcdz20518 for mpls-outgoing; Tue, 13 Feb 2001 07: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 QQkcdz20513 for ; Tue, 13 Feb 2001 07:59:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcdz25560 for ; Tue, 13 Feb 2001 07:58:40 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 QQkcdz24625 for ; Tue, 13 Feb 2001 07:58:40 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id XAA26136; Mon, 12 Feb 2001 23:56:31 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id XAA27299; Mon, 12 Feb 2001 23:56:31 -0800 (PST) Date: Mon, 12 Feb 2001 23:56:31 -0800 (PST) Message-Id: <200102130756.XAA27299@cirrus.juniper.net> From: Dave Katz To: kireeti@juniper.net CC: akyol@pluris.com, dareks@nortelnetworks.com, kireeti@juniper.net, mpls@UU.NET, swallow@cisco.com, tli@procket.com In-reply-to: <200102130420.UAA15849@kummer.juniper.net> (message from Kireeti Kompella on Mon, 12 Feb 2001 20:20:36 -0800 (PST)) Subject: Re: Handling multiple IP addresses on PPP interfaces with RSVP-TE Sender: owner-mpls@UU.NET Precedence: bulk At one point in the life of the draft it allowed putting multiple chunks of stuff into a single LSA, but John Moy was fairly adamant that LSAs have the finest granularity possible, so that's what we ended up with. Date: Mon, 12 Feb 2001 20:20:36 -0800 (PST) From: Kireeti Kompella Cc: dkatz@juniper.net, kireeti@juniper.net, mpls@UU.NET, swallow@cisco.com, tli@procket.com > I am not from OSPF land :) and I don't have the latest version of the > OSPF TE Extensions draft handy but I recall a statement in the draft > indicating that each sub-TLV of the Link TLV may occur only once. As you say, lifting this restriction is the easy way out, and makes OSPF compatible with ISIS. Forthcoming. > In addition, the OSPF TE Extensions draft states that only a single Link > TLV may occur in an Opaque LSA of Type 10 implying multiple Opaque LSAs > for multiple Link TLVs. This again has a potential for a negative impact > to OSPF operation in particular flooding. The question therefore is > whether this restriction can also be lifted, i.e. Opaque LSA may carry > more than one Link TLV. This is actually a Good Thing. Why would this affect flooding negatively? It would appear useful to decouple the flooding of independent TE links. Kireeti. From owner-mpls@UU.NET Tue Feb 13 03:27:47 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14254 for ; Tue, 13 Feb 2001 03:27: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 QQkceb29524; Tue, 13 Feb 2001 08:26:00 GMT Received: by mail-control.mail.uu.net id QQkceb06968 for mpls-outgoing; Tue, 13 Feb 2001 08:25: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 QQkceb06954 for ; Tue, 13 Feb 2001 08:25:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkceb12505 for ; Tue, 13 Feb 2001 08:24:40 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 QQkceb00753 for ; Tue, 13 Feb 2001 08:24:40 GMT Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Tue, 13 Feb 2001 08:08:08 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <1RBRA6M2>; Tue, 13 Feb 2001 08:08:07 -0000 Message-ID: To: kireeti@juniper.net, mpls@apollo.mctr.umbc.edu Cc: mpls@UU.NET Subject: RE: Shared Risk Link Group (SRLG) Date: Tue, 13 Feb 2001 08:08:00 -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 > > In general, if I have a (non-optical) network, can I identify > > group(s) of links that might fail together ? > > Sure. > > Kireeti. > NH=> Only if you have full knowledge of the physical infrastructure (ie duct layer network). A client layer link connection (ie 1 element of connectivity of a client layer trail between 2 adjacent nodes in the client layer) is created by a server layer trail (ie end-end path in the server layer, composed of several concatenated server layer link connections).....this is how one constructs client layer topology and is the fundamental aspect of network design/TE. The disjoint degree of connectivity of the duct network is inherited by all (client) layer networks above this.....noting that this is a recursive relationship between server/client layers, and so the actual diversity of a layer N (client) network is a function of (server) layer N+1, layer N+2, layer N+3, etc to the duct. If you lease server layer capacity (at any layer, including the duct) you may not have this knowledge. From owner-mpls@UU.NET Tue Feb 13 05:04:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14829 for ; Tue, 13 Feb 2001 05:04: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 QQkcei15985; Tue, 13 Feb 2001 10:00:36 GMT Received: by mail-control.mail.uu.net id QQkcei28490 for mpls-outgoing; Tue, 13 Feb 2001 10:00:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcei28377 for ; Tue, 13 Feb 2001 10:00:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkceh10598 for ; Tue, 13 Feb 2001 09:59:45 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 QQkceh14568 for ; Tue, 13 Feb 2001 09:59:44 GMT Received: from juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id BAA29897; Tue, 13 Feb 2001 01:59:40 -0800 (PST) Message-Id: <200102130959.BAA29897@red.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: neil.2.harrison@bt.com cc: mpls@UU.NET Subject: Re: PHP negotiation In-Reply-To: Your message of "Thu, 08 Feb 2001 09:32:57 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Feb 2001 01:56:32 -0800 From: Kireeti Kompella Sender: owner-mpls@UU.NET Precedence: bulk > I agree Bora....if you allow PHP, then where (in a functional architecture > sense) is the LSP trail termination point? This has implications for: We've had (much of) this discussion before. The LSP termination point is the end of the LSP ... simple :-) The simple way out of this apparent paradox is to distinguish the control plane from the forwarding plane. In the control plane, the LSP termination point is clear. For example, for RSVP, the LSP end point is the LSR that doesn't send Path messages. The fact that PHP is/isn't being used is completely irrelevant in determining the LSP termination point; PHP is purely in the forwarding plane. Let's take your points one-by-one: > - defect detection Two ways: a) failure of control plane, b) notification from "lower layers". Example of (a): loss of Path/Resv message. Example of (b): Loss of light from SONET/SDH layer. Either way, PHP is irrelevant. > - server->client layer adapatation If you mean (for example) IP->MPLS and MPLS->IP, this is forwarding plane related. PHP means this gets done one hop earlier. I don't see an issue here, though. > - performance monitoring Forwarding plane, so PHP or not has an effect. This is the one argument against PHP that I buy. And perhaps the OAM argument, although I would have to see the OAM spec first. > - protection switching Control plane. PHP is irrelevant. Bora wrote: > I would have to add to this that when you have an MPLS diffserv > network that uses a combination of E and L_LSPs and PHP is > enabled, implementation of PHP in hardware becomes quite > complex due to amount of tables, exception cases and remapping. I don't get it. What gets harder? If popping is a valid operation, how does it matter to the forwarding plane *where* the popping is done, at the egress or one hop earlier? Kireeti. From owner-mpls@UU.NET Tue Feb 13 07:37:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16148 for ; Tue, 13 Feb 2001 07:37:17 -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 QQkces11824; Tue, 13 Feb 2001 12:31:21 GMT Received: by mail-control.mail.uu.net id QQkces18352 for mpls-outgoing; Tue, 13 Feb 2001 12:30: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 QQkces18347 for ; Tue, 13 Feb 2001 12:30: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 QQkcer19552 for ; Tue, 13 Feb 2001 12:29:40 GMT From: neil.2.harrison@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 QQkcer19565 for ; Tue, 13 Feb 2001 12:29:39 GMT Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Tue, 13 Feb 2001 12:28:51 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <1RBRBW50>; Tue, 13 Feb 2001 12:29:21 -0000 Message-ID: To: kireeti@juniper.net Cc: mpls@UU.NET Subject: RE: PHP negotiation Date: Tue, 13 Feb 2001 12:29:09 -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 Kireeti.....You have missed the points.....let me expand for you below (sorry its a bit long). > We've had (much of) this discussion before. > The LSP termination point > is the end of the LSP ... simple :-) NH=> There are certain actions that a *trail termination point* has to assume responsiblity for when terminating the characteristic information that defines a trail entity. If its not so clear with 'pure' MPLS user-plane (shim header) then it ought to be very clear with GMPLS user-plane (eg SDH_VC4 = trail trace, BIP8, etc)....however, let's revisit the ones I noted below to make the points clear: > > Let's take your points one-by-one: > > > - defect detection > Two ways: a) failure of control plane, b) notification from > "lower layers". > Example of (a): loss of Path/Resv message. Example of (b): > Loss of light > from SONET/SDH layer. Either way, PHP is irrelevant. NH=> In case (a) one may not always have congruently routed user and control-planes. Further, each of these functions has its own distinct failure modes which although not relevant to the other directly, can be relevant indirectly, eg user-plane failures could trigger control-plane prot-sw action on S-PVCs say. But note that control-plane failures should *never* take down permanent/semi-permanent user-plane trails.....which seems the case with GMPLS/RSVP due to soft-state holding. In case (b) 1st let me correct a small arch error. The 'light' is not part of the SDH layer characteristic information, but a lower layer optical network trail (eg part of a WDM system say). If the fibre is cut (ie light dies) then this is detected at the optical trail termination point. At the optical (server) -> SDH regen/mux/VC_X (client) trail termination points there is a *recursive* server->client adaptation of the failure into their respective Forward Defect Indication (FDI) signals....and in traditional WAN technologies, such as SDH, this FDI signal is called AIS (Alarm Inhibition/Indication Signal). It key role is to inform client layer layer networks that there is a lower layer failure and so *not* to create an alarm storm in those client layer networks (since their trail termination points could be geographically/organisationally far removed from the original failure point). However, there could be other failures of an SDH VC_4 (say) trail, such as a break in the SDH fabric per se, BIP errors or trace trace mismatch. These are only relevant to the particular SDH trail type considered (ie don't result in loss of light, since this is a lower layer), and need correct defect handling (ie detection and consequent actions) at the relevant trail termination point. So, one is inherently taking advantage of the fact that the SONET/SDH *user-plane* has already been specified correctly wrt trail termination points and defect handling. Now let's consider the user-plane of 'pure' MPLS. This can have defects that are neither relevant to IP nor any server layers....they arise due to the new functionality the shim header introduces (indeed, LSPs create layer networks....its just an arch fact and should not be regarded as a problem). Such potential (new) defects include: - loss of MPLS layer connectivity (ie within the MPLS fabric, and not from a server layer below it, eg SDH)....at some LSP level N - swapped LSPs....at some LSP level N - >=2 mismerged LSPs....at some level N - self-mismerged LSP (aka looping).....at some level N These need defining, in terms of entry/exit criteria and consequent actions (both for my Ops people so they can diagnose the defects, and to protect my customer's traffic, eg leaking of VPN traffic say). The defect detection and consequent actions *must* be applied at the trail termination point....so its essential I know where this is....and which leads into the next item: > > > - server->client layer adapatation > > If you mean (for example) IP->MPLS and MPLS->IP, this is > forwarding plane > related. PHP means this gets done one hop earlier. I don't > see an issue > here, though. NH=> In order to detect all of the above defects we need some form of network-unique Trail Termination Source Identifier (TTSI) to be sent from the LSP source to the LSP sink on some deterministic basis. In the OAM work we call this a CV (Connectivity Verification) packet flow. Now suppose we get one of the above defects occurring at some LSP at level N in a nested LSP hierarchy. This would (depending on the defect type) have varying impact on all the client layer LSPs served by the initially affected LSP. Let us take the very simplest case of a 'break' in connectivity. In this case all LSPs at/above the break (ie those that span the break) will defect 'loss of CV' (dLOCV). The trail termination points of all these LSPs will want to raise an alarm to signify the failure.....but to do this would be disasterous from an operational perspective, since it could cause an alarm storm in geographically/organisationally disjoint locations. (Note - in this discussion I am focussing on explicitly routed LSPs which are largely permanent/semi-permanent, and which one may use for VPNs, an LSP carrier transit service (sort of VPN) or TE say, and not for LSPs just used to support BE IP.....of course, this all applies to GMPLS too, but that is largely OK since the user-plane has been specified earlier). It is therefore vital to apply an FDI at the lowest LSP affected by the break so that all client LSPs see this FDI signal (recursively mapped at each server->client adapatation function) and supress their own alarm generation. Further we are propsoing to add a Defect Location and Defect Type fields to the FDI so that upstream domains can identify the domain of the source of the orginal defect. Note: (i) In the case of the mismerging defects, where an unexpected TTSI is observed at a trail termination point, (dTTSI) then a further important consequent action will be the squelching of affected customer traffic to avoid any security/censorship/misbilling issues arising for carriers. (ii) All above are pre-requisites for carriers to develop robust/measurable availability (first/foremost) and QoS (only relevant to available-state) SLAs for some MPLS-based services. > > > - performance monitoring > > Forwarding plane, so PHP or not has an effect. This is the > one argument > against PHP that I buy. And perhaps the OAM argument, > although I would > have to see the OAM spec first. NH=> Perf monitoring....one has to do this at the appropriate point *and*, if we are talking about QoS, this is only relevant when the LSP is in the up-state (so that needs defining 1st). Kireeti...I'll send you a separate direct mail on the OAM issue.....but I guess the discussion above gave enough pointers as to why an unabiguous location of the trail termination function is important. > > > - protection switching > > Control plane. PHP is irrelevant. NH=> Its not irrelevant. The control-plane may not always be congruous with the user-plane, and in any case each 'plane' has its own specific failures mechanisms. The only other issue here (and the one I was trying to make in the initial mail) is that when we are discussing prot-sw we have to be very clear about the 2 points between which the working and prot-entity exist. And since user-plane defects can be used as triggers to invoke control-plane restorations (eg S-PVCs...something I see as very important in GMPLS, and certanly before SVCs (re OIF UNI stuff), but as not yet properly considered), then knowing where the trail termination point is (ie so that we get the defect detection coupling) is important. > Neil From owner-mpls@UU.NET Tue Feb 13 08:39:52 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17812 for ; Tue, 13 Feb 2001 08:39: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 QQkcew04291; Tue, 13 Feb 2001 13:34:48 GMT Received: by mail-control.mail.uu.net id QQkcew06268 for mpls-outgoing; Tue, 13 Feb 2001 13:34: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 QQkcew06261 for ; Tue, 13 Feb 2001 13:34: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 QQkcew28556 for ; Tue, 13 Feb 2001 13:32:38 GMT Received: from zrtps06u.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) id QQkcew01457 for ; Tue, 13 Feb 2001 13:32:38 GMT Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f1DDVo300410 for ; Tue, 13 Feb 2001 08:31:50 -0500 (EST) Received: from zcard00n.ca.nortel.com by zcars04e.nortelnetworks.com; Tue, 13 Feb 2001 08:32:07 -0500 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 16FHT7J1; Tue, 13 Feb 2001 08:32:07 -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 1WVVGFBB; Tue, 13 Feb 2001 08:32:06 -0500 Message-ID: <3A893755.C276855B@americasm01.nt.com> Date: Tue, 13 Feb 2001 08:32:05 -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: Kireeti Kompella CC: akyol@pluris.com, dkatz@juniper.net, mpls@UU.NET, swallow@cisco.com, tli@procket.com Subject: Re: Handling multiple IP addresses on PPP interfaces with RSVP-TE References: <200102130420.UAA15849@kummer.juniper.net> Content-Type: multipart/alternative; boundary="------------2A59BB50A276A59759DB7078" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk --------------2A59BB50A276A59759DB7078 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > > I am not from OSPF land :) and I don't have the latest version of the > > OSPF TE Extensions draft handy but I recall a statement in the draft > > indicating that each sub-TLV of the Link TLV may occur only once. > > As you say, lifting this restriction is the easy way out, and makes > OSPF compatible with ISIS. Forthcoming. > > > In addition, the OSPF TE Extensions draft states that only a single Link > > TLV may occur in an Opaque LSA of Type 10 implying multiple Opaque LSAs > > for multiple Link TLVs. This again has a potential for a negative impact > > to OSPF operation in particular flooding. The question therefore is > > whether this restriction can also be lifted, i.e. Opaque LSA may carry > > more than one Link TLV. > > This is actually a Good Thing. Why would this affect flooding negatively? Please correct me if I am wrong but there surely must be some extra overhead (bandwidth, memory and CPU) if N LSAs with a single TLV are advertized versus 1 LSA with N TLVs. > > It would appear useful to decouple the flooding of independent TE links. > By removing the restriction of a single Link TLV per Opaque LSA does not prevent one from advertizing a single Link TLV per Opaque LSA if fine granularity is required. > > Kireeti. -- Darek Skalecki Nortel (613) 765-2252 --------------2A59BB50A276A59759DB7078 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti Kompella wrote:
> I am not from OSPF land :) and I don't have the latest version of the
> OSPF TE Extensions draft handy but I recall a statement in the draft
> indicating that each sub-TLV of the Link TLV may occur only once.

As you say, lifting this restriction is the easy way out, and makes
OSPF compatible with ISIS.  Forthcoming.

> In addition, the OSPF TE Extensions draft states that only a single Link
> TLV may occur in an Opaque LSA of Type 10 implying multiple Opaque LSAs
> for multiple Link TLVs. This again has a potential for a negative impact
> to OSPF operation in particular flooding. The question therefore is
> whether this restriction can also be lifted, i.e. Opaque LSA may carry
> more than one Link TLV.

This is actually a Good Thing.  Why would this affect flooding negatively?

Please correct me if I am wrong but there surely must be some extra overhead (bandwidth, memory and CPU) if N LSAs with a single TLV are advertized versus 1 LSA with N TLVs.
 
It would appear useful to decouple the flooding of independent TE links.
 
By removing the restriction of a single Link TLV per Opaque LSA does not prevent one  from advertizing a single Link TLV per Opaque LSA if fine granularity is required.
 
Kireeti.
-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------2A59BB50A276A59759DB7078-- From owner-mpls@UU.NET Tue Feb 13 09:31:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19824 for ; Tue, 13 Feb 2001 09:31: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 QQkcez12864; Tue, 13 Feb 2001 14:28:24 GMT Received: by mail-control.mail.uu.net id QQkcez23401 for mpls-outgoing; Tue, 13 Feb 2001 14:28: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 QQkcez23394 for ; Tue, 13 Feb 2001 14:28:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcez13897 for ; Tue, 13 Feb 2001 14:26:58 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 QQkcez10755 for ; Tue, 13 Feb 2001 14:26: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 GAA24264; Tue, 13 Feb 2001 06:27:10 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA12549; Tue, 13 Feb 2001 09:26:55 -0500 (EST) Message-Id: <200102131426.JAA12549@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: neil.2.harrison@bt.com cc: kireeti@juniper.net, mpls@UU.NET Subject: Re: PHP negotiation In-reply-to: Your message of Tue, 13 Feb 2001 12:29:09 +0000. 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, 13 Feb 2001 09:26:55 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Neil> I guess the discussion above gave enough pointers as to why an Neil> unambiguous location of the trail termination function is important Well, I can say that it didn't give me a clue. Repeated unsupported claims that it is "vital" to follow ITU architectures just aren't very persuasive. Are you expecting to achieve WG consensus on an OAM proposal? If the proposal is an attempt to warp an IP-based architecture into some kind of connection-oriented ITU-like scheme, my guess is that there is very little chance of achieving consensus. Actually, I wonder if the OAM stuff falls under the charter of the CCAMP group rather than the MPLS group. From owner-mpls@UU.NET Tue Feb 13 09:33:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19892 for ; Tue, 13 Feb 2001 09:33: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 QQkcez15243; Tue, 13 Feb 2001 14:29:58 GMT Received: by mail-control.mail.uu.net id QQkcez23486 for mpls-outgoing; Tue, 13 Feb 2001 14:29:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcez23473 for ; Tue, 13 Feb 2001 14:29:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcez28241 for ; Tue, 13 Feb 2001 14:29:14 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 QQkcez21483 for ; Tue, 13 Feb 2001 14: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 GAA05252 for ; Tue, 13 Feb 2001 06:29:30 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA12570 for mpls@uu.net; Tue, 13 Feb 2001 09: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 QQkcer16236 for ; Tue, 13 Feb 2001 12:16: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 QQkcer22907; Tue, 13 Feb 2001 12:15:45 GMT Received: from rip.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQkcer00042; Tue, 13 Feb 2001 12:15:44 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14SeMp-000Ex4-00; Tue, 13 Feb 2001 04:15:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Vijay Gill Cc: , , , , , agenda@ietf.org Subject: Re: CCAMP charter and agenda items request for the Minneapolis IETF References: Message-Id: Date: Tue, 13 Feb 2001 04:15:35 -0800 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit approved by relevant [sic] ad > The CCAMP charter and mailing list information are at: > > http://www.ietf.org/html.charters/ccamp-charter.html > > We've requested a 2.5 hour slot at the Minn. IETF. > > Once we get the allocation, the information will be sent to the ccamp > mailing list. Subscription information is in the charter at the URL above. > > Please send requests for agenda items to us. Priority will be given to new > individual submissions, and works in progress that are being moved under > CCAMP. > > thanks > > kireeti and vijay > > > > From owner-mpls@UU.NET Tue Feb 13 10:35:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22069 for ; Tue, 13 Feb 2001 10:35: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 QQkcfe22281; Tue, 13 Feb 2001 15:32:32 GMT Received: by mail-control.mail.uu.net id QQkcfe13359 for mpls-outgoing; Tue, 13 Feb 2001 15:32: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 QQkcfe13351 for ; Tue, 13 Feb 2001 15:32:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcfe01202 for ; Tue, 13 Feb 2001 15:31:05 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcfe27202 for ; Tue, 13 Feb 2001 15:31:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA08820 for mpls@uu.net; Tue, 13 Feb 2001 10:31:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcfe13130 for ; Tue, 13 Feb 2001 15:30:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcfe22099 for ; Tue, 13 Feb 2001 15:30:24 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkcfe25335 for ; Tue, 13 Feb 2001 15:30:23 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id HAA07821; Tue, 13 Feb 2001 07:30:22 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14985.21260.782000.180586@gargle.gargle.HOWL> Date: Tue, 13 Feb 2001 07:30:20 -0800 To: Kireeti Kompella Cc: neil.2.harrison@bt.com, mpls@UU.NET Subject: Re: PHP negotiation In-Reply-To: <200102130959.BAA29897@red.juniper.net> References: <200102130959.BAA29897@red.juniper.net> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Kireeti" == Kireeti Kompella writes: Kireeti> Bora wrote: >> I would have to add to this that when you have an MPLS >> diffserv network that uses a combination of E and L_LSPs >> and PHP is enabled, implementation of PHP in hardware >> becomes quite complex due to amount of tables, exception >> cases and remapping. Kireeti> I don't get it. What gets harder? If popping is a Kireeti> valid operation, how does it matter to the Kireeti> forwarding plane *where* the popping is done, at Kireeti> the egress or one hop earlier? The problem that you face is: 1. PHP node may not have all of the relevant information that it needs to so it infers what to do in some cases. 2. Think of the case of an IP packet when it emerges after a PHP prior to the ultimate tunnel egress and it comes in as an IP packet instead of MPLS into the ultimate egress. How is the ultimate egress node supposed to treat this packet? If it gets treated as an IP packet then you may be misapplying an ingress policy at the ultimate hop. 3. Doing PHP at the presence of hierarchical LSPs and MPLS-DS is hard (but not impossible) because it requires you to keep too much state in hardware and too many possible mapping behaviors. Makes the packet processor more complex. Again, I am not saying that PHP is impossible to handle but that it makes life harder and unclear at times. "Unclear" usually means interoperability problems and that is what worries me. Bora From owner-mpls@UU.NET Tue Feb 13 10:40:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22234 for ; Tue, 13 Feb 2001 10:40: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 QQkcfe00422; Tue, 13 Feb 2001 15:37:40 GMT Received: by mail-control.mail.uu.net id QQkcfe13813 for mpls-outgoing; Tue, 13 Feb 2001 15:37: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 QQkcfe13787 for ; Tue, 13 Feb 2001 15:36: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 QQkcfe16578 for ; Tue, 13 Feb 2001 15:36:00 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 QQkcfe27705 for ; Tue, 13 Feb 2001 15:36:00 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14511 for ; Tue, 13 Feb 2001 10:35:58 -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 KAA28185 for ; Tue, 13 Feb 2001 10:35:59 -0500 (EST) Message-ID: <3A895472.3F588B88@marconi.com> Date: Tue, 13 Feb 2001 10:36:18 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Shared Risk Link Group (SRLG) 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: > > Only if you have full knowledge of the physical infrastructure (ie > duct layer network). A client layer link connection (ie 1 element of > connectivity of a client layer trail between 2 adjacent nodes in the > client layer) is created by a server layer trail (ie end-end path in > the server layer, composed of several concatenated server layer link > connections).....this is how one constructs client layer topology and > is the fundamental aspect of network design/TE. The disjoint degree > of connectivity of the duct network is inherited by all (client) layer > networks above this.....noting that this is a recursive relationship > between server/client layers, and so the actual diversity of a layer N > (client) network is a function of (server) layer N+1, layer N+2, layer > N+3, etc to the duct. If you lease server layer capacity (at any > layer, including the duct) you may not have this knowledge. This is actually a serious problem in the real world. You may buy a fiber from two different companies for redundant backup, only to find that they're both going through the same conduit in the street, so both will get cut at once if a backhoe operator digs into that conduit. There's nothing that any protocol can do about this. -- David From owner-mpls@UU.NET Tue Feb 13 11:03:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22815 for ; Tue, 13 Feb 2001 11:03: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 QQkcff04276; Tue, 13 Feb 2001 15:58:59 GMT Received: by mail-control.mail.uu.net id QQkcff16071 for mpls-outgoing; Tue, 13 Feb 2001 15:58: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 QQkcff16064 for ; Tue, 13 Feb 2001 15:58:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcff18980 for ; Tue, 13 Feb 2001 15:58:19 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 QQkcff02135 for ; Tue, 13 Feb 2001 15:58:19 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 KAA16919 for ; Tue, 13 Feb 2001 10:58:17 -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 KAA04389 for ; Tue, 13 Feb 2001 10:58:18 -0500 (EST) Message-ID: <3A8959AD.F10D6B90@marconi.com> Date: Tue, 13 Feb 2001 10:58:37 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP negotiation References: <200102130959.BAA29897@red.juniper.net> <14985.21260.782000.180586@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > > 1. PHP node may not have all of the relevant information that it > needs to so it infers what to do in some cases. Maybe. The penultimate node isn't supposed to look at the next label down (or underlying IP header). It's supposed to make its forwarding decision based on the top label alone. If, however, the packet in the LSP is not IP, the penultimate node may not have sufficient information to fill in the correct layer-3 protocol ID in the layer-2 header. > 2. Think of the case of an IP packet when it emerges after a PHP prior > to the ultimate tunnel egress and it comes in as an IP packet > instead of MPLS into the ultimate egress. How is the ultimate > egress node supposed to treat this packet? If it gets treated as an > IP packet then you may be misapplying an ingress policy at the > ultimate hop. Since it is the ultimate egress router that requests PHP from the penultimate router, you would assume that it wouldn't do this. If there are ingress policies on the interface facing the MPLS cloud, then the router should be requesting PHP in the first place. I don't see a problem, since the decision to do PHP, and the responsibility to deal with the consequences are both in the same router. > 3. Doing PHP at the presence of hierarchical LSPs and MPLS-DS is > hard (but not impossible) because it requires you to keep too > much state in hardware and too many possible mapping > behaviors. Makes the packet processor more complex. Not really. Labels are supposed to be non-hierarchical. As long as uniqueness and scoping rules of RFC 3031 section 3.14 are obeyed, the egress router will not have a problem. It will get a packet with a label, and will forward according to that label. The fact that the presence of that label is due to PHP on the previous router shouldn't affect its forwarding decision at all. It's still a simple label->NHLFE mapping, just for a different label. Of course, if the scoping rules are violated (meaning the label space of the router that originally did the push is in conflict with the previous hop router's label space), then the meaning of the label received is ambiguous. You can't know if it comes from the previous-hop router's label space or from the label space of the router that pushed the second-level label. If the same label exists in both label spaces, they must be handled identically in order for anything to work. But this rule applies whether or not PHP is used. > Again, I am not saying that PHP is impossible to handle but that > it makes life harder and unclear at times. "Unclear" usually > means interoperability problems and that is what worries me. It seems to me that only your first problem is a real problem. And even then, only if the LSP's traffic is non-IP. -- David From owner-mpls@UU.NET Tue Feb 13 11:14:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23051 for ; Tue, 13 Feb 2001 11:14: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 QQkcfg00757; Tue, 13 Feb 2001 16:10:55 GMT Received: by mail-control.mail.uu.net id QQkcfg01440 for mpls-outgoing; Tue, 13 Feb 2001 16:10:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcfg01432 for ; Tue, 13 Feb 2001 16:10:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcfg24451 for ; Tue, 13 Feb 2001 16:09:27 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkcfg19306 for ; Tue, 13 Feb 2001 16:09:26 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18107 for ; Tue, 13 Feb 2001 11:09:24 -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 LAA07419 for ; Tue, 13 Feb 2001 11:09:26 -0500 (EST) Message-ID: <3A895C49.A2DED7EF@marconi.com> Date: Tue, 13 Feb 2001 11:09:45 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP negotiation References: <200102130959.BAA29897@red.juniper.net> <14985.21260.782000.180586@gargle.gargle.HOWL> <3A8959AD.F10D6B90@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David Charlap wrote: > > Since it is the ultimate egress router that requests PHP from the > penultimate router, you would assume that it wouldn't do this. If > there are ingress policies on the interface facing the MPLS cloud, > then the router should be requesting PHP in the first place. I mean, of course, "... should _not_ be requesting PHP ..." -- David From owner-mpls@UU.NET Tue Feb 13 11:56:11 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23984 for ; Tue, 13 Feb 2001 11:56: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 QQkcfj07746; Tue, 13 Feb 2001 16:52:49 GMT Received: by mail-control.mail.uu.net id QQkcfj05643 for mpls-outgoing; Tue, 13 Feb 2001 16:52: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 QQkcfj05634 for ; Tue, 13 Feb 2001 16:52: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 QQkcfj29769 for ; Tue, 13 Feb 2001 16:52:04 GMT Received: from chucky.luxcore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: unused197.gw.deltacom.net [216.248.170.197] (may be forged)) id QQkcfj05826 for ; Tue, 13 Feb 2001 16:52:03 GMT Received: by chucky.luxcore.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Feb 2001 11:04:47 -0500 Message-ID: <459095B074F4D411BBB500B0D079EA2012CDE3@chucky.luxcore.com> From: Mukul Katiyar To: "'mpls@UU.NET'" Subject: draft-prs-optical-routing-01.txt Date: Tue, 13 Feb 2001 11:04:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can some one share with me an acrobat or postscript version of this draft. thanks mukul From owner-mpls@UU.NET Tue Feb 13 12:18:30 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24850 for ; Tue, 13 Feb 2001 12:18: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 QQkcfl22476; Tue, 13 Feb 2001 17:15:33 GMT Received: by mail-control.mail.uu.net id QQkcfl21915 for mpls-outgoing; Tue, 13 Feb 2001 17:15: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 QQkcfk21774 for ; Tue, 13 Feb 2001 17:14: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 QQkcfk03848 for ; Tue, 13 Feb 2001 17:13:35 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 QQkcfk27071 for ; Tue, 13 Feb 2001 17:13:34 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Tue, 13 Feb 2001 16:45:49 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <11T2X3YK>; Tue, 13 Feb 2001 16:46:12 -0000 Message-ID: To: erosen@cisco.com Cc: kireeti@juniper.net, mpls@UU.NET Subject: RE: PHP negotiation Date: Tue, 13 Feb 2001 16:46:04 -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 Eric asked:> > Actually, I wonder if the OAM stuff falls under the > charter of the CCAMP > group rather than the MPLS group. NH=> Not really Eric....OAM is required for both the control-plane (its not called OAM here, but what do you think things like 'hellos', message acknowldegements, etc, are doing?) and the user-plane. All layer networks need OAM to maintain their health. Its just in some technologies, like SDH/Sonet and IP, OAM has already been addressed (in IP its ICMP).....I am assuming here that you do understand why OAM is important to carriers? In MPLS (user-plane) it hasn't been addressed as yet. So one can't simply equate CCAMPS and OAM. > From owner-mpls@UU.NET Tue Feb 13 12:44:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25484 for ; Tue, 13 Feb 2001 12:44: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 QQkcfm28990; Tue, 13 Feb 2001 17:40:58 GMT Received: by mail-control.mail.uu.net id QQkcfm23811 for mpls-outgoing; Tue, 13 Feb 2001 17:40:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcfm23805 for ; Tue, 13 Feb 2001 17:40:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcfm23701 for ; Tue, 13 Feb 2001 17:39:15 GMT Received: from femail11.sdc1.sfba.home.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail11.sdc1.sfba.home.com [24.0.95.107]) id QQkcfm26152 for ; Tue, 13 Feb 2001 17:39:15 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010213173914.BKWD4091.femail11.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Tue, 13 Feb 2001 09:39:14 -0800 Message-ID: <09c501c09648$3274c8e0$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "David Charlap" , References: <200102130959.BAA29897@red.juniper.net> <14985.21260.782000.180586@gargle.gargle.HOWL> <3A8959AD.F10D6B90@marconi.com> Subject: Re: PHP negotiation Date: Tue, 13 Feb 2001 21:37:18 -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 ----- Original Message ----- From: "David Charlap" To: Sent: Tuesday, February 13, 2001 7:58 AM Subject: Re: PHP negotiation > Bora Akyol wrote: > > > > 1. PHP node may not have all of the relevant information that it > > needs to so it infers what to do in some cases. > > Maybe. > > The penultimate node isn't supposed to look at the next label down (or > underlying IP header). It's supposed to make its forwarding decision > based on the top label alone. > > If, however, the packet in the LSP is not IP, the penultimate node may > not have sufficient information to fill in the correct layer-3 protocol > ID in the layer-2 header. If the the packet in the LSP is not IP, I would like to know if PHP is applicable as per the RFC/drafts for L2 transport over MPLS such as FR, ATM, PPP, Cisco HDLC, VLAN/EtherNet Frame Assuming, PHP is applicable for IP as well as non-IP payloads then your concerns regarding protocol ID in the layer 2 header is for the particular case of PHop ---- Egress Node link being ethernet. What if the link is PPP or Cisco HDLC or FR or ATM? There is no or may be different encapsulation information that the PHOP need to prefix to the payload before transmitting on the link between PH node and Egress node. > > > 2. Think of the case of an IP packet when it emerges after a PHP prior > > to the ultimate tunnel egress and it comes in as an IP packet > > instead of MPLS into the ultimate egress. How is the ultimate > > egress node supposed to treat this packet? If it gets treated as an > > IP packet then you may be misapplying an ingress policy at the > > ultimate hop. > > Since it is the ultimate egress router that requests PHP from the > penultimate router, you would assume that it wouldn't do this. If there > are ingress policies on the interface facing the MPLS cloud, then the > router should be requesting PHP in the first place. > > I don't see a problem, since the decision to do PHP, and the > responsibility to deal with the consequences are both in the same > router. > > > 3. Doing PHP at the presence of hierarchical LSPs and MPLS-DS is > > hard (but not impossible) because it requires you to keep too > > much state in hardware and too many possible mapping > > behaviors. Makes the packet processor more complex. > > Not really. Labels are supposed to be non-hierarchical. As long as > uniqueness and scoping rules of RFC 3031 section 3.14 are obeyed, the > egress router will not have a problem. It will get a packet with a > label, and will forward according to that label. The fact that the > presence of that label is due to PHP on the previous router shouldn't > affect its forwarding decision at all. It's still a simple label->NHLFE > mapping, just for a different label. > > Of course, if the scoping rules are violated (meaning the label space of > the router that originally did the push is in conflict with the previous > hop router's label space), then the meaning of the label received is > ambiguous. > > You can't know if it comes from the previous-hop router's label space or > from the label space of the router that pushed the second-level label. > If the same label exists in both label spaces, they must be handled > identically in order for anything to work. But this rule applies > whether or not PHP is used. > > > Again, I am not saying that PHP is impossible to handle but that > > it makes life harder and unclear at times. "Unclear" usually > > means interoperability problems and that is what worries me. > > It seems to me that only your first problem is a real problem. And even > then, only if the LSP's traffic is non-IP. > > -- David > From owner-mpls@UU.NET Tue Feb 13 13:06:11 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25934 for ; Tue, 13 Feb 2001 13:06: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 QQkcfo23741; Tue, 13 Feb 2001 18:02:29 GMT Received: by mail-control.mail.uu.net id QQkcfo01798 for mpls-outgoing; Tue, 13 Feb 2001 18:02:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcfo01653 for ; Tue, 13 Feb 2001 18:02:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcfo04100 for ; Tue, 13 Feb 2001 18:02: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 QQkcfo00641 for ; Tue, 13 Feb 2001 18:02:00 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f1DI0Hb01597; Tue, 13 Feb 2001 13:00:17 -0500 (EST) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id <1Q7CMQLV>; Tue, 13 Feb 2001 12:55:37 -0500 Message-ID: <0CD7D73C734BD411AEE100B0D0220404DFDD44@mail1.tellium.com> From: Bala Rajagopalan To: "'Mukul Katiyar'" , "'mpls@UU.NET'" Subject: RE: draft-prs-optical-routing-01.txt Date: Tue, 13 Feb 2001 12:55:36 -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, You can obtain the ps version at http://www.ietf.org/internet-drafts/draft-prs-optical-routing-01.ps Regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Mukul Katiyar [mailto:mkatiyar@luxcore.com] > Sent: Tuesday, February 13, 2001 11:05 AM > To: 'mpls@UU.NET' > Subject: draft-prs-optical-routing-01.txt > > > Hi, > Can some one share with me an acrobat or postscript > version of this > draft. > > thanks > mukul > From owner-mpls@UU.NET Tue Feb 13 13:10:51 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26094 for ; Tue, 13 Feb 2001 13:10: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 QQkcfo01450; Tue, 13 Feb 2001 18:07:30 GMT Received: by mail-control.mail.uu.net id QQkcfo09825 for mpls-outgoing; Tue, 13 Feb 2001 18:06:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcfo09812 for ; Tue, 13 Feb 2001 18:06:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcfo14227 for ; Tue, 13 Feb 2001 18:06:19 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 QQkcfo29554 for ; Tue, 13 Feb 2001 18:06:19 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 KAA15360; Tue, 13 Feb 2001 10:06:35 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA13355; Tue, 13 Feb 2001 13:06:17 -0500 (EST) Message-Id: <200102131806.NAA13355@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: neil.2.harrison@bt.com cc: kireeti@juniper.net, mpls@UU.NET Subject: Re: PHP negotiation In-reply-to: Your message of Tue, 13 Feb 2001 16:46:04 +0000. 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, 13 Feb 2001 13:06:16 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Neil> in some technologies, like SDH/Sonet and IP, OAM has already been Neil> addressed (in IP its ICMP) I believe that ICMP Echo Request/Response already works in MPLS networks, even with PHP. From owner-mpls@UU.NET Tue Feb 13 13:17:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26302 for ; Tue, 13 Feb 2001 13:17: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 QQkcfo18498; Tue, 13 Feb 2001 18:12:40 GMT Received: by mail-control.mail.uu.net id QQkcfo10680 for mpls-outgoing; Tue, 13 Feb 2001 18: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 QQkcfo10675 for ; Tue, 13 Feb 2001 18:12:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcfo21442 for ; Tue, 13 Feb 2001 18:11: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 QQkcfo17282 for ; Tue, 13 Feb 2001 18:11:47 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 KAA29227; Tue, 13 Feb 2001 10:12:00 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA13369; Tue, 13 Feb 2001 13:11:45 -0500 (EST) Message-Id: <200102131811.NAA13369@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Manohar Ellanti" cc: "David Charlap" , mpls@UU.NET Subject: Re: PHP negotiation In-reply-to: Your message of Tue, 13 Feb 2001 21:37:18 -0800. <09c501c09648$3274c8e0$1cd01318@frmt1.sfba.home.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: Tue, 13 Feb 2001 13:11:44 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Manohar> If the the packet in the LSP is not IP, I would like to know if PHP Manohar> is applicable as per the RFC/drafts for L2 transport over MPLS such Manohar> as FR, ATM, PPP, Cisco HDLC, VLAN/EtherNet Frame The encapsulation for L2 transport over MPLS uses two labels. The bottom label must be seen by the egress node, but the top label is subject to php. No problem, because then when the egress node looks at the packet, it sees the bottom label, which is just what it needs to see. From owner-mpls@UU.NET Tue Feb 13 13:38:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26899 for ; Tue, 13 Feb 2001 13:38: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 QQkcfq12379; Tue, 13 Feb 2001 18:35:17 GMT Received: by mail-control.mail.uu.net id QQkcfq13218 for mpls-outgoing; Tue, 13 Feb 2001 18:34:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcfq13209 for ; Tue, 13 Feb 2001 18:34:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcfq03207 for ; Tue, 13 Feb 2001 18:34: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 QQkcfq11123 for ; Tue, 13 Feb 2001 18:34: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 f1DIYS414627 for ; Tue, 13 Feb 2001 12:34:28 -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 f1DIYRC06801 for ; Tue, 13 Feb 2001 12:34:27 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id MAA27314 for ; Tue, 13 Feb 2001 12:34:27 -0600 (CST) X-OpenMail-Hops: 1 Date: Tue, 13 Feb 2001 12:34:26 -0600 Message-Id: Subject: MPLS, CCAMP sessions in coming IETF MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-1b6ac859-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1b6ac859-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Tue, 13 Feb 2001 12:34:25 -0600" Content-Transfer-Encoding: 8bit Hi All, Any idea when the MPLS WG session will be held in the coming IETF? what about CCAMP WG session? I don't see any of the them in the proposed agenda http://www.ietf.org/meetings/agenda_50.txt Thanks. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations & Evaluation Group Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --openmail-part-1b6ac859-00000001 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf" ;Creation-Date="Tue, 13 Feb 2001 12:34:25 -0600" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --openmail-part-1b6ac859-00000001-- From owner-mpls@UU.NET Tue Feb 13 14:05:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27825 for ; Tue, 13 Feb 2001 14:05: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 QQkcfs28423; Tue, 13 Feb 2001 19:02:01 GMT Received: by mail-control.mail.uu.net id QQkcfs21995 for mpls-outgoing; Tue, 13 Feb 2001 19:01:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcfs21715 for ; Tue, 13 Feb 2001 19:01:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcfs19685 for ; Tue, 13 Feb 2001 19:01:08 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 QQkcfs18403 for ; Tue, 13 Feb 2001 19:01:07 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA27437 for ; Tue, 13 Feb 2001 11:01:07 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA48228 for ; Tue, 13 Feb 2001 11:01:07 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102131901.LAA48228@garnet.juniper.net> To: mpls@UU.NET Subject: PID in LDP MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48225.982090867.1@garnet.juniper.net> Date: Tue, 13 Feb 2001 11:01:07 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Folks, Right now we have a situation where RSVP, CR-LDP) have a mechanism (PID) to identify an LSP payload, while LDP doesn't have such a mechanism. Would there be any objections to add a new TLV to LDP that would carry the PID information ? Yakov. From owner-mpls@UU.NET Tue Feb 13 14:16:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28171 for ; Tue, 13 Feb 2001 14:16: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 QQkcfs12610; Tue, 13 Feb 2001 19:13:50 GMT Received: by mail-control.mail.uu.net id QQkcfs00839 for mpls-outgoing; Tue, 13 Feb 2001 19:13: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 QQkcfs00831 for ; Tue, 13 Feb 2001 19:13:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcfs24998 for ; Tue, 13 Feb 2001 19:11:56 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 QQkcfs03652 for ; Tue, 13 Feb 2001 19:11: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 LAA18817 for ; Tue, 13 Feb 2001 11:12:12 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA13672 for mpls@uu.net; Tue, 13 Feb 2001 14:11:54 -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 QQkcfn25282 for ; Tue, 13 Feb 2001 17:52:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcfn19830 for ; Tue, 13 Feb 2001 17:52:02 GMT Received: from motgate.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate.mot.com [129.188.136.100]) id QQkcfn00666 for ; Tue, 13 Feb 2001 17:52:01 GMT Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA22143 for ; Tue, 13 Feb 2001 10:52:01 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA24867 for ; Tue, 13 Feb 2001 10:52:01 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 13 Feb 2001 11:52:00 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D973@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'mpls'" Cc: "'arup@ccrl.nj.nec.com'" , "'griffoul@ccrle.nec.de'" , "'furquan@ccrl.nj.nec.com'" Subject: Status of the "IP Multicast Support in MPLS Networks" Draft Date: Tue, 13 Feb 2001 11:51:45 -0600 X-MS-TNEF-Correlator: <01FAF65DEA16D4119B95009027E78F3149D973@il02exm26.comm.mot.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C095E5.A15CD940" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C095E5.A15CD940 Content-Type: text/plain; charset="iso-8859-1" All, I have read this draft "IP Multicast Support in MPLS Networks" that describes a way of implicitly binding labels using a data-driven approach for multicast. I only found the 00 version of the draft that expired in 99. I was wondering if there were reasons why this draft was not well received or if there are any plans to revive this one at a later time. I would greatly appreciate any input on this. Thanks, Vidya ------_=_NextPart_000_01C095E5.A15CD940 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgERAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcCAA0ACwAzAC0AAgBUAQEggAMADgAAANEHAgAN AAsAMwAtAAIAVAEBCYABACEAAAA3ODZEMzMwOENBMDFENTExOUJEMjAwOTAyN0U3OEYzMQD4BgEE gAEAPAAAAFN0YXR1cyBvZiB0aGUgIklQIE11bHRpY2FzdCBTdXBwb3J0IGluIE1QTFMgTmV0d29y a3MiIERyYWZ0AKsUAQ2ABAACAAAAAgACAAEDkAYAqAcAADEAAAACAXEAAQAAABYAAAABwJXloThG ESp6AcgR1b3QABCkxWP+AAADAN4/r28AAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAA HgABgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsAAoAIIAYAAAAAAMAAAAAA AABGAAAAAAaFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAASACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAsABYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAG gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAARhQAA AAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAJgAggBgAAAAAAwAAAAAAAAEYA AAAANoUAAAEAAAABAAAAAAAAAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAA AAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwAMgAsgBgAAAAAAwAAA AAAAAEYAAAAAAIgAAAAAAAALAA2ACyAGAAAAAADAAAAAAAAARgAAAAAFiAAAAAAAAAIBCRABAAAA 0AEAAMwBAAAxAgAATFpGdfQ6bAADAAoAcmNwZzEyNRYyAPgLYG4OEDAzM08B9wKkA+MCAGNoCsBz sGV0MCAHEwKAfQqBknYIkHdrC4BkNAxgHmMAUAsDC7URYGxsLBMKogqASSAQ8HZlIEEJcGFkIHRo BAAgCGRyYQGAICJJUJEF0HVsdA3gYXMFQNBTdXBwCREgC4AF0ExQTAXwB8B0dwWwa3RzIhUhYQVA AQAE8mIBB5FhIHdheSBvGmYXMG0LUA3gaXRszRmQYhJxC4BnIAtgGRC6bAQgdQCQGuEZUGQYgLRh LRWAaRSwA6BhFuCzA2AA0GggAhAFwG0WNrwuIBRwAiAaYQIQdRKAuxUhFMAwEVAUsBEQaQIgDxmi HxIVhBhjZXhwafMJcRcyOTkeIhlwBCAX8P8SgAZxGuEGkB8CCXAZYCNi7RThcwIgIlFoGZAVOSIy PG5vJUEbQAMgCXBjZb8ccRUQBbEjFwrAJ2FuGZDzC1EGMXRvFNESIBSxFTPfAiAnYQVAGVALYHQE kBUg9wdxIfMIYGwVEAnBGIAaYT8cwgWQBzAqACezC4Bwdb8FQB/RFTIeIBQUFBRUEPAGbhggFAVW aWR5YQsUFBHhADAAHgBwAAEAAAA8AAAAU3RhdHVzIG9mIHRoZSAiSVAgTXVsdGljYXN0IFN1cHBv cnQgaW4gTVBMUyBOZXR3b3JrcyIgRHJhZnQACwACAAEAAAADAP0/5AQAAEAAOQBA2Vyh5ZXAAQMA 8T8JBAAAHgAxQAEAAAAHAAAAQ1ZOMDY1AAADABpAAAAAAB4AMEABAAAABwAAAENWTjA2NQAAAwAZ QAAAAAADACYAAAAAAAMANgAAAAAAAwCAEP////8CAUcAAQAAADAAAABjPVVTO2E9IDtwPW1vdDts PUlMMDJFWE0yNi0wMTAyMTMxNzUxNDVaLTEwNjU3MAACAfk/AQAAAEcAAAAAAAAA3KdAyMBCEBq0 uQgAKy/hggEAAAAAAAAAL089TU9UL09VPUxNUFNJTDAyL0NOPVJFQ0lQSUVOVFMvQ049Q1ZOMDY1 AAAeAPg/AQAAABcAAABOYXJheWFuYW4gVmlkeWEtQ1ZOMDY1AAAeADhAAQAAAAcAAABDVk4wNjUA AAIB+z8BAAAARwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1NT1QvT1U9TE1QU0lM MDIvQ049UkVDSVBJRU5UUy9DTj1DVk4wNjUAAB4A+j8BAAAAFwAAAE5hcmF5YW5hbiBWaWR5YS1D Vk4wNjUAAB4AOUABAAAABwAAAENWTjA2NQAAQAAHMDrZVaHllcABQAAIMBgTjKHllcABHgA9AAEA AAABAAAAAAAAAB4AHQ4BAAAAPAAAAFN0YXR1cyBvZiB0aGUgIklQIE11bHRpY2FzdCBTdXBwb3J0 IGluIE1QTFMgTmV0d29ya3MiIERyYWZ0AB4ANRABAAAAQAAAADwwMUZBRjY1REVBMTZENDExOUI5 NTAwOTAyN0U3OEYzMTQ5RDk3M0BpbDAyZXhtMjYuY29tbS5tb3QuY29tPgALACkAAAAAAAsAIwAA AAAAAwAGECoYjYUDAAcQUwEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABBTEwsSUhBVkVS RUFEVEhJU0RSQUZUIklQTVVMVElDQVNUU1VQUE9SVElOTVBMU05FVFdPUktTIlRIQVRERVNDUklC RVNBV0FZT0ZJTVBMSUNJVExZQklORElOR0xBQkVMU1VTAAAAAAIBfwABAAAAQAAAADwwMUZBRjY1 REVBMTZENDExOUI5NTAwOTAyN0U3OEYzMTQ5RDk3M0BpbDAyZXhtMjYuY29tbS5tb3QuY29tPgCa ig== ------_=_NextPart_000_01C095E5.A15CD940-- From owner-mpls@UU.NET Tue Feb 13 14:23:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28332 for ; Tue, 13 Feb 2001 14:23: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 QQkcft23738; Tue, 13 Feb 2001 19:20:49 GMT Received: by mail-control.mail.uu.net id QQkcft01829 for mpls-outgoing; Tue, 13 Feb 2001 19:20:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcft01816 for ; Tue, 13 Feb 2001 19:20:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcft03676 for ; Tue, 13 Feb 2001 19:20:13 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkcft22746 for ; Tue, 13 Feb 2001 19:20:13 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05436 for ; Tue, 13 Feb 2001 14:20:10 -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 OAA00243 for ; Tue, 13 Feb 2001 14:20:12 -0500 (EST) Message-ID: <3A898900.C1EF8EF0@marconi.com> Date: Tue, 13 Feb 2001 14:20:32 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP negotiation References: <200102131811.NAA13369@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen wrote: >> >> If the the packet in the LSP is not IP, I would like to know if PHP >> is applicable as per the RFC/drafts for L2 transport over MPLS such >> as FR, ATM, PPP, Cisco HDLC, VLAN/EtherNet Frame > > The encapsulation for L2 transport over MPLS uses two labels. The > bottom label must be seen by the egress node, but the top label is > subject to php. No problem, because then when the egress node looks > at the packet, it sees the bottom label, which is just what it needs > to see. Note that this is different from transporting a non-IP L3 packet. While the two-label mechanism can work, it is may also possible to use a single label. When RSVP-TE is used, an ingress router provides the ethertype of the L3 protocol in the label-request object. So every router knows what's underneath the label. If the penultimate router's outgoing interface can support sending the L3 protocol without a label, and the egress router can receive said unlabeled packet, then PHP can work with only one label on the stack. The first condition is something the penultimate router should know on its own. The second condition is something the egress router will know, and should consider before requesting PHP. I think all the popular interface types support non-IP L3 protocols: - Ethernet and those protocols that emulate ethernet have a protocol field. 802.3 has the protocol in the LLC/SNAP field - PPP has a protocol field, although it's not the same as ethertypes - ATM uses SNAP for RFC-2684 (formerly 1483) VCs. - Frame Relay uses SNAP for RFC-2427-formatted VCs I'm unfamiliar with HDLC, but I'd be surprised if it didn't also have a protocol-ID field in the header somewhere. -- David From owner-mpls@UU.NET Tue Feb 13 15:07:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29397 for ; Tue, 13 Feb 2001 15:07: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 QQkcfw28811; Tue, 13 Feb 2001 20:04:40 GMT Received: by mail-control.mail.uu.net id QQkcfw14624 for mpls-outgoing; Tue, 13 Feb 2001 20:04: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 QQkcfw14349 for ; Tue, 13 Feb 2001 20:03: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 QQkcfw27573 for ; Tue, 13 Feb 2001 20:02:38 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 QQkcfw15978 for ; Tue, 13 Feb 2001 20:02:37 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA02457; Tue, 13 Feb 2001 12:02:33 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id MAA58521; Tue, 13 Feb 2001 12:02:33 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102132002.MAA58521@garnet.juniper.net> To: David Charlap cc: mpls@UU.NET Subject: Re: PID in LDP In-Reply-To: Your message of "Tue, 13 Feb 2001 14:46:51 EST." <3A898F2B.9412FE89@marconi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58516.982094553.1@garnet.juniper.net> Date: Tue, 13 Feb 2001 12:02:33 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk David, > Yakov Rekhter wrote: > > > > Right now we have a situation where RSVP, CR-LDP) have a mechanism > > (PID) to identify an LSP payload, while LDP doesn't have such a > > mechanism. > > Does CR-LDP have such a field? I was looking for one and didn't find it > in the draft. You are correct. > > Would there be any objections to add a new TLV to LDP that would > > carry the PID information ? > > It would definitely be useful in CR-LDP. Agreed. > It would be less useful in LDP, since it could not reasonably be used in > any unsolicited label distribution mode. Look at draft-martini-l2circuit-trans-mpls. It specifies unsolicited downstream mode. And the Virtual Circuit FEC TLV defined in that Internet Draft carries in its VC Type field the information which is not that different from what would be carried in the PID. Yakov. From owner-mpls@UU.NET Tue Feb 13 15:21:58 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29588 for ; Tue, 13 Feb 2001 15:21: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 QQkcfx14666; Tue, 13 Feb 2001 20:19:11 GMT Received: by mail-control.mail.uu.net id QQkcfx22262 for mpls-outgoing; Tue, 13 Feb 2001 20:18:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcfx22252 for ; Tue, 13 Feb 2001 20:18:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcfx17923 for ; Tue, 13 Feb 2001 20:16:58 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 QQkcfx13744 for ; Tue, 13 Feb 2001 20:16:58 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 PAA10756 for ; Tue, 13 Feb 2001 15:16:55 -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 PAA15814 for ; Tue, 13 Feb 2001 15:16:58 -0500 (EST) Message-ID: <3A89964E.67B454D8@marconi.com> Date: Tue, 13 Feb 2001 15:17:18 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PID in LDP References: <200102132002.MAA58521@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > >> It would be less useful in LDP, since it could not reasonably be used >> in any unsolicited label distribution mode. > > Look at draft-martini-l2circuit-trans-mpls. It specifies unsolicited > downstream mode. And the Virtual Circuit FEC TLV defined in that > Internet Draft carries in its VC Type field the information which is > not that different from what would be carried in the PID. I understand. It would certainly be possible to send an L3PID TLV with label mapping messages in addition to label request messages. My only concern is that unsolicited label allocation of multiple L3 protocols would quickly lead to an unmanageable number of labels. Instead of sending out mappings for every FEC, you're now sending them out for every legal combination of FEC and L3 protocol. This could easily overrun an LSR's capabilities. Especially if the edge routers know about a large number of protocols. Consider also the kinds of non-IP traffic that is likely to exist. Most will probably be streaming audio/video/whatever protocols, which will likely require some level of QoS - meaning they'll be signalled with RSVP-TE or CR-LDP. The rest will probably be legacy LAN traffic (like NetWare or AppleTalk), which will probably not be a large percentage of the network's traffic - resulting in a lot of wasted LSPs if LDP establishes a full mesh for these protocols. This is why I said it could not "reasonably" be used. It could, of course, be used, but I don't think it would be a good idea. -- David From owner-mpls@UU.NET Tue Feb 13 15:59:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00181 for ; Tue, 13 Feb 2001 15:59: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 QQkcfz05281; Tue, 13 Feb 2001 20:55:25 GMT Received: by mail-control.mail.uu.net id QQkcfz25587 for mpls-outgoing; Tue, 13 Feb 2001 20:54: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 QQkcfz25554 for ; Tue, 13 Feb 2001 20:54:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcfz12474 for ; Tue, 13 Feb 2001 20:53:56 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcfz29161 for ; Tue, 13 Feb 2001 20:53:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA12089 for mpls@uu.net; Tue, 13 Feb 2001 15:53:55 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcfz25399 for ; Tue, 13 Feb 2001 20:52:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcfz10359 for ; Tue, 13 Feb 2001 20:51:51 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 QQkcfz00235 for ; Tue, 13 Feb 2001 20:51:48 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id OAA28933; Tue, 13 Feb 2001 14:51:40 -0600 Date: Tue, 13 Feb 2001 14:51:39 -0600 From: "James R. Leu" To: Yakov Rekhter Cc: mpls@UU.NET Subject: Re: PID in LDP Message-ID: <20010213145139.D28601@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <200102131901.LAA48228@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102131901.LAA48228@garnet.juniper.net>; from yakov@juniper.net on Tue, Feb 13, 2001 at 11:01:07AM -0800 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Feb 13, 2001 at 11:01:07AM -0800, Yakov Rekhter wrote: > Folks, > > Right now we have a situation where RSVP, CR-LDP) have a mechanism (PID) > to identify an LSP payload, while LDP doesn't have such a mechanism. > > Would there be any objections to add a new TLV to LDP that would > carry the PID information ? Hello Yakov, Excuse me if I'm mis-understanding the problem, but doesn't the combination of FEC element type and address family field of the FEC TLV do this already? I could see the addition of new FEC element types and, if need be, the usage of different address families. > Yakov. Jim -- James R. Leu From owner-mpls@UU.NET Tue Feb 13 16:22:40 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00540 for ; Tue, 13 Feb 2001 16:22: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 QQkcgb09658; Tue, 13 Feb 2001 21:19:05 GMT Received: by mail-control.mail.uu.net id QQkcgb11458 for mpls-outgoing; Tue, 13 Feb 2001 21: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 QQkcgb11451 for ; Tue, 13 Feb 2001 21:18:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcgb12886 for ; Tue, 13 Feb 2001 21:18:31 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 QQkcgb20242 for ; Tue, 13 Feb 2001 21:18:31 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA07328; Tue, 13 Feb 2001 13:18:30 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id NAA72681; Tue, 13 Feb 2001 13:18:30 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102132118.NAA72681@garnet.juniper.net> To: jleu@mindspring.com cc: mpls@UU.NET Subject: Re: PID in LDP In-Reply-To: Your message of "Tue, 13 Feb 2001 14:51:39 CST." <20010213145139.D28601@doit.wisc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72677.982099110.1@garnet.juniper.net> Date: Tue, 13 Feb 2001 13:18:30 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk > On Tue, Feb 13, 2001 at 11:01:07AM -0800, Yakov Rekhter wrote: > > Folks, > > > > Right now we have a situation where RSVP, CR-LDP) have a mechanism (PID) > > to identify an LSP payload, while LDP doesn't have such a mechanism. > > > > Would there be any objections to add a new TLV to LDP that would > > carry the PID information ? > > Hello Yakov, > > Excuse me if I'm mis-understanding the problem, but doesn't the combination > of FEC element type and address family field of the FEC TLV do this already? No it doesn't. > I could see the addition of new FEC element types and, if need be, the usage > of different address families. That doesn't solve the problem of identifying the payload of an LSP. Yakov. From owner-mpls@UU.NET Tue Feb 13 17:22:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01635 for ; Tue, 13 Feb 2001 17:22: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 QQkcfv13279; Tue, 13 Feb 2001 19:48:55 GMT Received: by mail-control.mail.uu.net id QQkcfv05076 for mpls-outgoing; Tue, 13 Feb 2001 19:48: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 QQkcfv05071 for ; Tue, 13 Feb 2001 19:48:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcfv16795 for ; Tue, 13 Feb 2001 19:47:48 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 QQkcfv05466 for ; Tue, 13 Feb 2001 19:47:47 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA01489; Tue, 13 Feb 2001 11:47:46 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA56056; Tue, 13 Feb 2001 11:47:46 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102131947.LAA56056@garnet.juniper.net> To: Yakov Rekhter cc: mpls@UU.NET Subject: Re: PID in LDP In-Reply-To: Your message of "Tue, 13 Feb 2001 11:01:07 PST." <200102131901.LAA48228@garnet.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56053.982093666.1@garnet.juniper.net> Date: Tue, 13 Feb 2001 11:47:46 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk > Folks, > > Right now we have a situation where RSVP, CR-LDP have a mechanism (PID) > to identify an LSP payload, while LDP doesn't have such a mechanism. I don't think I was correct wrt CR-LDP... Yakov. > Would there be any objections to add a new TLV to LDP that would > carry the PID information ? > > Yakov. From owner-mpls@UU.NET Tue Feb 13 17:38:32 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01886 for ; Tue, 13 Feb 2001 17:38: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 QQkcfv22409; Tue, 13 Feb 2001 19:47:28 GMT Received: by mail-control.mail.uu.net id QQkcfv04904 for mpls-outgoing; Tue, 13 Feb 2001 19:46: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 QQkcfv04899 for ; Tue, 13 Feb 2001 19:46: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 QQkcfv08794 for ; Tue, 13 Feb 2001 19:46:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkcfv03563 for ; Tue, 13 Feb 2001 19:46:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07894 for ; Tue, 13 Feb 2001 14:46:29 -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 OAA07797 for ; Tue, 13 Feb 2001 14:46:31 -0500 (EST) Message-ID: <3A898F2B.9412FE89@marconi.com> Date: Tue, 13 Feb 2001 14:46:51 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PID in LDP References: <200102131901.LAA48228@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > > Right now we have a situation where RSVP, CR-LDP) have a mechanism > (PID) to identify an LSP payload, while LDP doesn't have such a > mechanism. Does CR-LDP have such a field? I was looking for one and didn't find it in the draft. > Would there be any objections to add a new TLV to LDP that would > carry the PID information ? It would definitely be useful in CR-LDP. It would be less useful in LDP, since it could not reasonably be used in any unsolicited label distribution mode. -- David From owner-mpls@UU.NET Tue Feb 13 22:01:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05779 for ; Tue, 13 Feb 2001 22:01: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 QQkcgx18004; Wed, 14 Feb 2001 02:57:39 GMT Received: by mail-control.mail.uu.net id QQkcgx15773 for mpls-outgoing; Wed, 14 Feb 2001 02:57:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcgx15768 for ; Wed, 14 Feb 2001 02:57:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcgx02836 for ; Wed, 14 Feb 2001 02:56:47 GMT Received: from WATERTOWN.litchfieldcomm.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 121.125.252.64.snet.net [64.252.125.121]) id QQkcgx16756 for ; Wed, 14 Feb 2001 02:56:45 GMT Subject: Draft IETF MPLS TE MIB 05: Tunnel Table indexes Date: Tue, 13 Feb 2001 21:57:44 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC031257@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: Draft IETF MPLS TE MIB 05: Tunnel Table indexes Thread-Index: AcCWMeecxI8dB1gCS6Cs7RiCKu3OHQ== content-class: urn:content-classes:message From: "Dave Danenberg" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 To: "mpls@uu.net" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA05779 Hopefully this is a simple question. The Tunnel Table has 4 indexes, 2 of which are the LSR IDs. My question is: what should the egress LSR ID be within the node that terminates the tunnel (0? the local LSR ID?). Conversely, what should the ingress LSR ID be within the node that originates a tunnel? From owner-mpls@UU.NET Tue Feb 13 22:31:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06493 for ; Tue, 13 Feb 2001 22:31: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 QQkcgz28346; Wed, 14 Feb 2001 03:27:59 GMT Received: by mail-control.mail.uu.net id QQkcgz01273 for mpls-outgoing; Wed, 14 Feb 2001 03:27:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcgz01268 for ; Wed, 14 Feb 2001 03:27:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcgz05668 for ; Wed, 14 Feb 2001 03:27:24 GMT Received: from mason2.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkcgz26909 for ; Wed, 14 Feb 2001 03:27:24 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id WAA30552; Tue, 13 Feb 2001 22:27:18 -0500 (EST) Date: Tue, 13 Feb 2001 22:27:17 -0500 (EST) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Dave Danenberg cc: "mpls@uu.net" Subject: Re: Draft IETF MPLS TE MIB 05: Tunnel Table indexes In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC031257@WATERTOWN.litchfieldcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Please read inline comments On Tue, 13 Feb 2001, Dave Danenberg wrote: > Hopefully this is a simple question. The Tunnel Table has 4 indexes, 2 > of which are the LSR IDs. My question is: what should the egress LSR ID > be within the node that terminates the tunnel (0? the local LSR ID?). > Conversely, what should the ingress LSR ID be within the node that > originates a tunnel? If I am correct it should be the Local LSR ID (whether it is ingress or Egress) -Rajiv > From owner-mpls@UU.NET Wed Feb 14 05:28:51 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25602 for ; Wed, 14 Feb 2001 05:28: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 QQkcib17177; Wed, 14 Feb 2001 10:25:14 GMT Received: by mail-control.mail.uu.net id QQkcib02222 for mpls-outgoing; Wed, 14 Feb 2001 10:24:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcib02213 for ; Wed, 14 Feb 2001 10:24:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcib00883 for ; Wed, 14 Feb 2001 10:24:26 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcib25015 for ; Wed, 14 Feb 2001 10:24:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA21508 for mpls@uu.net; Wed, 14 Feb 2001 05:24: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 QQkcib02184 for ; Wed, 14 Feb 2001 10:23:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcib29031 for ; Wed, 14 Feb 2001 10:23:34 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkcib18641 for ; Wed, 14 Feb 2001 10:23:33 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA04455 for ; Wed, 14 Feb 2001 05:23:28 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA04425 for ; Wed, 14 Feb 2001 05:23:27 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA28026; Wed, 14 Feb 2001 11:23:25 +0100 (MET) Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" , "Ben Mack-Crane (E-mail)" , "Greg Bernstein (E-mail)" , "Bala Rajagopalan (E-mail)" , "Debanjan Saha (E-mail)" , "Michael Raftelis (E-mail)" , "Shash Chatterjee (E-mail)" , "Jeff Connell (E-mail)" , "Eric Mannie (E-mail)" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA28005; Wed, 14 Feb 2001 11:23:21 +0100 (MET) Message-ID: <3A8A5C98.19B6FF3F@lucent.com> Date: Wed, 14 Feb 2001 11:23:20 +0100 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vishal Sharma Original-CC: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" , "Ben Mack-Crane (E-mail)" , "Greg Bernstein (E-mail)" , "Bala Rajagopalan (E-mail)" , "Debanjan Saha (E-mail)" , "Michael Raftelis (E-mail)" , "Shash Chatterjee (E-mail)" , "Jeff Connell (E-mail)" , "Eric Mannie (E-mail)" Subject: Re: FW: [IP-Optical] GMPLS enhancements References: Content-Type: multipart/mixed; boundary="------------FF19E49E4044A2D3C7D5BCAE" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------FF19E49E4044A2D3C7D5BCAE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vishal, Attached is a brief description of the features (increase/decrease of VC-n-Xv group size and protection) that are introduced by the LCAS extension of virtual concatenation. Regards, Maarten --------------FF19E49E4044A2D3C7D5BCAE Content-Type: application/msword; name="lcas.doc" Content-Disposition: inline; filename="lcas.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAFgAAAAAA AAAAEAAAGAAAAAEAAAD+////AAAAABUAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcQAJCAAACBK/AAAAAAAAEAAAAAAABAAA Sg4AAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAAAAAJBBYAKhgAABZBAQAWQQEARAoAAAAA AAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAAO4AAAAAAAAA7gAAAO4AAAAAAAAA7gAAAAAAAADuAAAA AAAAAO4AAAAAAAAA7gAAABQAAAAAAAAAAAAAAAIBAAAAAAAAAgEAAAAAAAACAQAAAAAAAAIB AAA4AAAAOgEAAAwAAABGAQAADAAAAAIBAAAAAAAAkQcAAPIAAABeAQAAFgAAAHQBAAAAAAAA dAEAAAAAAAB0AQAAAAAAAHQBAAAAAAAAdAEAAAAAAAB0AQAAAAAAAHQBAAAAAAAAVgcAAAIA AABYBwAAAAAAAFgHAAAAAAAAWAcAAAAAAABYBwAAAAAAAFgHAAAAAAAAWAcAACQAAACDCAAA 9AEAAHcKAACWAQAAfAcAABUAAAAAAAAAAAAAAAAAAAAAAAAA7gAAAAAAAAB0AQAAAAAAAAAA AAAAAAAAAAAAAAAAAAB0AQAAAAAAAHQBAAAAAAAAdAEAAAAAAAB0AQAAAAAAAHwHAAAAAAAA 2AIAAAAAAADuAAAAAAAAAO4AAAAAAAAAdAEAAAAAAAAAAAAAAAAAAHQBAAAAAAAAXgEAAAAA AADYAgAAAAAAANgCAAAAAAAA2AIAAAAAAAB0AQAAEgEAAO4AAAAAAAAAdAEAAAAAAADuAAAA AAAAAHQBAAAAAAAAVgcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAAAAAAACAQAAAAAAAO4A AAAAAAAA7gAAAAAAAADuAAAAAAAAAO4AAAAAAAAAdAEAAAAAAABWBwAAAAAAANgCAAB+BAAA 2AIAAAAAAAAAAAAAAAAAAFYHAAAAAAAA7gAAAAAAAADuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVgcAAAAAAAB0AQAA AAAAAFIBAAAMAAAA0PcpWm+WwAECAQAAAAAAAAIBAAAAAAAAhgIAAFIAAABWBwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARmlndXJlIDEgZGVwaWN0cyBhIGZyYWdtZW50IG9m IGFuIFNESCBlcXVpcG1lbnQgd2l0aCBhIEdiRSAodHJpYnV0YXJ5KSBwb3J0IHVuaXQgKDR4 IDFHYkUgaW50ZXJmYWNlcyksIGEgSGlnaGVyIE9yZGVyIEZhYnJpYyB1bml0IGFuZCA0IFNU TS1OIHBvcnQgdW5pdHMuIEVhY2ggb2YgdGhlIGZvdXIgR2JFIHNpZ25hbHMgaXMgdGVybWlu YXRlZCwgdGhlIGV0aGVybmV0IHBhY2tldHMgYXJlIGV4dHJhY3RlZCBhbmQgbWFwcGVkIHZp YSBHRlAgaW50byB0aGUgcGF5bG9hZCBvZiBhIFZDLTQtWHYgc2lnbmFsLiBCZXR3ZWVuIDEg YW5kIDcgVkMtNCBzaWduYWxzIGFyZSB1c2VkIGZvciB0aGUgdHJhbnNwb3J0IG9mIHRoZSBl dGhlcm5ldCBwYWNrZXRzIGluIGVhY2ggR2JFIHNpZ25hbC4gQW4gYXJiaXRyYXJ5IHNldCBv ZiB0aGUgVkMtNCBUZXJtaW5hdGlvbiBQb2ludHMgKGUuZy4gZm9yIEdiRSBpbnRlcmZhY2Ug QSwgVkM0IFRQcyBUMSwgVDMsIIUsIFRhKSBvbiB0aGUgR2JFIHBvcnQgdW5pdCBhcmUgdXNl ZCwgY29ubmVjdGVkIHZpYSB0aGUgVmlydHVhbCBDb25jYXRlbmF0aW9uIFNlbGVjdG9yIHdp dGggdGhlIG1hcHBpbmcvZGVtYXBwaW5nIGNpcmN1aXQuDU5vdGUgLSBUaGUgVmlydENvbmNT ZWxlY3RvciBpcyBub3QgbmVlZGVkIHdoZW4gMjQgVkMtNCBUUHMgYXJlIHByZXNlbnQgb24g dGhlIEdiRSBwb3J0IHVuaXQuIEEgZml4ZWQgcmVsYXRpb24gYmV0d2VlbiBWQzQgVFBzIChU aSkgYW5kIEFpL0JpL0NpL0RpIGludGVyZmFjZXMgb24gdGhlIG1hcHBpbmcvZGVtYXBwaW5n IGNpcmN1aXRzIGNhbiB0aGVuIGJlIHVzZWQ7IGUuZy4gQTEoIFQxLCBBMiAoIFQyLCAuLiwg QjEgKCBUOCwgQjIgKCBUOSwghQ0NVGhlc2UgVkMtNCBzaWduYWxzIGFyZSBjb25uZWN0ZWQg dG8gdHdvIFNUTS1OIGludGVyZmFjZSBwb3J0cyAoU1RNLTY0IHBvcnQgSUkgYW5kIFNUTS0y NTYgcG9ydCBJVikgdmlhIHRoZSBITyBGYWJyaWMuIFZDNCBUMSBpcyBjb25uZWN0ZWQgdG8g QVU0IHRpbWVzbG90IDAyMjIxLCBWQzQgVDMgaXMgY29ubmVjdGVkIHRvIEFVNCB0aW1lc2xv dCAwMjIzMSwgLi4sIGFuZCBWQzQgVGEgaXMgY29ubmVjdGVkIHRvIEFVNCB0aW1lc2xvdCAy MjMyMS4NDUR1cmluZyBjb25uZWN0aW9uIHNldHVwLCB0aGUgZGlmZmVyZW50aWFsIGRlbGF5 IGJldHdlZW4gdGhlIFZDLTQgc2lnbmFscyBpbiBvbmUgVkMtNC1YdiBncm91cCBtdXN0IGJl IGNvbnRyb2xsZWQgYW5kIHRoZSBpbmRpdmlkdWFsIGNvbm5lY3Rpb25zIG11c3QgYmUgc2Vs ZWN0ZWQgc3VjaCB0aGF0IHRoaXMgZGlmZiBkZWxheSBuZXZlciBleGNlZWRzIHRoZSBtYXhp bXVtIHZhbHVlIHRoYXQgY2FuIGJlIGNvbXBlbnNhdGVkIGJ5IHRoZSBkZW1hcHBpbmcgY2ly Y3VpdC4NQ28tcm91dGluZyBmb3IgdGhlIHRvdGFsIGdyb3VwIGlzIG5vdCBhcHBsaWNhYmxl IGluIHRoaXMgYXBwbGljYXRpb24sIGJ1dCBjby1yb3V0aW5nIG9mIGEgc3Vic2V0IG9mIHRo ZSBncm91cCBtaWdodCBzdGlsbCBiZSBhcHBsaWNhYmxlIHRvIGhlbHAgY29udHJvbCB0aGUg ZGlmZmVyZW50aWFsIGRlbGF5Lg0NVW5kZXIgY29udHJvbCBvZiB0aGUgTENBUyBwcm9jZXNz LCB0aGUgZ3JvdXAgc2l6ZSBtYXkgaW5jcmVhc2Ugb3IgZGVjcmVhc2UuIEZvciB0aGUgY2Fz ZSB0aGUgZ3JvdXAgaXMgdG8gYmUgaW5jcmVhc2VkLCBMQ0FTIHByb2Nlc3MgcmVxdWVzdHMg dGhlIHNldHVwIG9mIGFuIGFkZGl0aW9uYWwgVkMtNCBwYXRoLiBPbmNlIHNldHVwIGlzIGNv bXBsZXRlZCwgdGhlIGluYmFuZCBMQ0FTIHByb3RvY29sIGlzIGFjdGl2YXRlZCB0byB0YWtl IHRoZSBhZGRpdGlvbmFsIFZDNCBwYXlsb2FkIGJhbmR3aWR0aCBpbnRvIHNlcnZpY2UuIEZv ciB0aGUgY2FzZSB0aGUgZ3JvdXAgaXMgZGVjcmVhc2VkLCB0aGUgaW5iYW5kIExDQVMgcHJv dG9jb2wgd2lsbCB0YWtlIG9uZSBvZiB0aGUgVkMtNCBwYXlsb2FkIGJhbmR3aWR0aHMgb3V0 IG9mIHNlcnZpY2UuIE9uY2UgdGhpcyBiYW5kd2lkdGggaXMgbm90IGxvbmdlciB1c2VkLCB0 aGUgTENBUyBwcm9jZXNzIHJlbGVhc2VzIHRoYXQgVkMtNCBwYXRoIGFuZCB0aGUgVkMtNCBj b25uZWN0aW9uIGlzIHRoZW4gdG9ybiBkb3duIGJ5IHRoZSBjb250cm9sIHBsYW5lLg0NSWYg b25lIG9yIG1vcmUgb2YgdGhlIFZDLTQgc2lnbmFscyBpbiB0aGUgVkMtNC1YdiBncm91cCBl bmNvdW50ZXIgYSBzaWduYWwgZmFpbCBjb25kaXRpb24sIHRoZSBMQ0FTIHByb3RvY29sIHdp bGwgbWFyayB0aG9zZSBWQy00IHBheWxvYWQgYmFuZHdpZHRocyBhcyBiZWluZyBmYWlsZWQs IGFuZCBjb250aW51ZXMgdG8gdXNlIG9ubHkgdGhlIG5vbi1mYWlsZWQgVkMtNCBzaWduYWxz LiBJbiB0aGUgbWVhbiB0aW1lLCB0aGUgTENBUyBwcm9jZXNzIG1heSByZXF1ZXN0IHRoZSBj b250cm9sIHBsYW5lIHRvIHJlc3RvcmUgdGhlIGZhaWxlZCBWQy00IGNvbm5lY3Rpb25zLiBP bmNlIGRvbmUsIHRoZSBMQ0FTIHByb3RvY29sIHdpbGwgYmUgYWN0aXZhdGVkIHRvIHRha2Ug dGhlIGFkZGl0aW9uYWwgYmFuZHdpZHRocyBhZ2FpbiBpbiBzZXJ2aWNlLg0TIEVNQkVEIERl c2lnbmVyLkRyYXdpbmcuOCAgFAEVDUZpZ3VyZSAxIC0gR2JFIG92ZXIgVkMtNC1YdiB3aXRo IExDQVMNDQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAANQcAADYH AAA+BwAAPwcAAEsHAABMBwAAVAcAAFUHAAD+DQAA/w0AABoOAAAbDgAAHQ4AAEoOAAAA+gD6 APoA+gD1AOv1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMDalvnND4KCAFVCAFWCAFtSAAECQNqAAAA AFUIAQoJagMA4PBtSAAEDgAEAABcBgAAXAcAAF0HAABcCAAAXQgAAGoJAAAaCgAAGwoAAFQM AABVDAAA/g0AAB4OAABEDgAARQ4AAEYOAABHDgAASA4AAEkOAABKDgAA/QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChAADcYPAjkQciADAADUEqclAAEC AAoPAA3GDwI5EHIgAwAA1BKnJQABAgMAAAMkAQADAAAPhNACAAEAAAATAAQAAFwGAABcBwAA XQcAAFwIAABdCAAAagkAABoKAAAbCgAAVAwAAFUMAAD+DQAAHg4AAEQOAABFDgAARg4AAEcO AABIDgAASQ4AAEoOAAAAAAAAAAAAAAAAAAAA/v77/v4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAUCEAANAQIBARMoACZQCQAfsIIuILDGQSGwbgQisG4EI5CKBSSQbgQlsAAAF7CoAhiw NwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJscAABEAGQAAAAAAAAA AgAAAAAAAAAAAAAAAADiLcoqFgMVAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwAE8DwAAACyBArwCAAAAAEEAAAACgAAQwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/AQAA CAAAABDwBAAAAAAAAIAyAAfwCxwAAAMEbxeIrTBBtfozpArhj3I0d/8A5xsAAAEAAABEAAAA AAAEAWAhG/DfGwAAbxeIrTBBtfozpArhj3I0dyhBAAAAAAAAAAAAAAEAAAABAAAAGNBxAJAj agCtGwAAAP54nLWbe1RU57mH9+zZM3sAoyaCMCiGBJRb00RBUEybGkEEa2sEuUnSKjfB1iTK TXL+6DkBVNL0soI3XJqa4AWzmtNUUMR41unxTprVpIIi2p604o2k6+SCiEhXzjPvzDBbEWPT 1WQ94f343t+z98zevMDKxqR4KYq5LlhRxijPKY5/gmCKdYzyuLIgKTM5Pjh3Vf7Skvy84GVr ghcU5a56vnDV0oKKbwQnr8z9ZvCCworCVfnBZVO/+cQTiqKRNJtsioWPPqrD5ahGqSbF5Kp6 bD/3clRWk2Nbh0GKL3/i6HWkHzMpio2PA6qFjPMf5+dNcnah5seU59Qd6nPqr9Rn1ddhu5oD S9RtahZkUmcIr6vp9KSrJnOGqoLZnAlZqmZeZlkD57RcSxec1/LAR/+zxUefZR2lPwnfsj4A o/VvW8fCg9QPCU9ax9EzTo+HC5ZxepflIf2c5UEotpzRii2l5iJLCaw2L7esMhfCc+rfVcf5 ul/pT770vCJVWSSvKEwZVHaog8qv1FvK67BdHYCbyjb1BvRRXxdeV3vp6VVM5uuKCmZzH9xQ NPM2dQ10ajXqBUuNOsu6Vn0SvmVdB+vVb1tfgZ9Svyo8af0ZPT9T4+GCZSe5nWqpuUEtgdXm N+ENdZV5UPm76jivoWtkuBZmJU3OPFxppqOZs2ri7Jo4y33wW876N/Cf1G8Lr6u/pufXnPnb nHmvUg7ntOtKF5zX+qBZ/bOlmbPaz9nt5ywPQAtn3QqHqN8VnrQepucwZ36YMz+snre8q3bB OcshGFTOaINKqfmWUmJuVr5Um4fO/vY7SXPdYcrQP87PW+Tzk82qUmM6DGEmR3qCtt10iTrM NJHVLTVg0Jn5hVuqzF5VtPRHfKzQvR9P3/C38h/AB4X/V+5YK4q3y26VrwDV5Ig5TWe+HMmU q3vvMpoca49JV0bxcZp3tCmHK6EoScsSlWDFH6v7SLf35ZqWSN/CeVn0TFImGF7nNlONKUq9 MzdOcm+bNpocnYkly/NXrcwvmaj4cBR/ZbT8d9Swoz0kqT/jdLxvLyzNXZFfsrrE0evHv/6k /RTnO/qGulqNUuuHGULFEKf+Xs4gPC8/4sdLX3ihaGVhcFnR0uCkuQtdxx6tPMp/A8DLdS6+ VAEcIVgJ5PXd6X1EvIXq58qDVEUrS54PzqyYOv2J4AXLikoeX/2ElzgcZzhRztTpdBzDm885 7O537B3uqXcYcu51P+t+w/op0w71KZNnXcO6xrB+n/X7hvU4ZsM41bPOZp3N+s5X8IC8gonK MybHZ6Zyyf1HuOZ+0vldJdbk5Xyt+asKlubmK+7XOFquouNV3v1u+TelWO6W8NkRiaPxP+C6 ZuXmAC/FPPyazZRUqPlXZse7nF60qqR06Y+C5zy/MpdvGiuXlhQ9vzI4bWFwav6P8nNLnl+F 0ct1Ds53d5Li7zqfUa533ofPOz86ruUoEs7r7Cep0a7zydW+Y2o3vzPCq/jM/IHieBXpc2IS J8ox7uzzlr5HtD8pjkGQttDOcTxXtczcr7QbrvIyrV/p1Nx3r8kcpa4a9lXjvEbfV/9Ddr47 Z3aqP0ee6Pp6G1A9A8eZsA0d7yBX/eDQVffMoQnaYfDMoZeoDw+7N9zT4HPz/U2Dz8x3nwYT tG2mCdrI0yBK+zrTYJr21dPAZolSHx/2utzTYJn5XzMN1pn/2WmQZN6hJpk9X72vsn7VsG5n 3W5YT9B2qBM0z3oZ62WGdSPrRsP6U9afaiNPg8vm+50Gvzd/3Wnwpdwt4U/fPg3eUDdyzXTL SF8DAZY7vwbuvOe/Z9mhfs8y/J7fph8Gzz0/SP1tfaR7frXuuudT733Pr9Jd93zq7ff8Nn2b aZs+8j3/a/3r3PNN+lff87W2KPUd60j3/EXrv+ae99L/2Xv+pHWHetLquUfH6DvUMbpnnc46 3bDexnqbYd3NutuwjrLtUKNsnvWLrF+0jXzPL9fv955foH/de/4ncreEJzju+UlD33HeUAO8 otT1tpHu+XrbV93zH/DaPuC1uX+mNn438Br6PYdfpPjZerxy1JKuHoH/sWSovxMy1f+2ZMES 6hx4lr1n6XlOPQbHqU8IOepJek7Se4LMCbLH4Rguh9Ptb6c+DX9k70MhU/2AzAdkP8TxIa4/ wmncHXCG+qyQo3bS00nvWTJnyZ6BDlztBn839UX4K3t/ETLVj8h8RPYvOP6C669wEfcluEx9 RchRr9Jzld4rZK6QvQyXcHUb/L3UX8Dn7H0mZKqfkvmU7Gc4PsP1OXyB+zr0Ud8QctR+evrp vUHmBtk+uI6r1+DXrOmqGVRrhmoSMlXFmgVLqHPgWfaepec51QJWal3IUW302OjVyehkrWDB 5XC6/b7U4+Ah9h4UMtWxZMaSfRDHg7gegnG4/WA8tb+QowbQE0CvPxl/suPBD5evwR9KHQKP sveIkKkGkwkm+wiOR3A9CiG4J8MU6jAhRw2nJ5zeMDJhZKfAZFyhBn8MdTRMY2+qkKk+QeYJ slNxTMU1DaJxT4dY6jghR51Bzwx648jEkY2F6bhiDP4E6jnwNHuzhUz1O2S+Q3Y2jtm4noY5 uBNhLnWSkKPOo2cevUlkksjOhURcCQZ/GnUqLGLvGSFTXUhmIdlncDyDaxGk4l4M6dQZQo6a SU8mvRlkMsimw2JcaQZ/HnUuLGNvqZCp/pDMD8kuxbEU1zLIxZ0PBdSFQo66nJ7l9BaSKSRb APm48gz+EurVsIq9F4VM9QUyL5B9EceLuFbBatylUEZdLuSoFfRU0FtOppxsGZTicjjdvyW7 vzO7f9725WeZGtNIP283mFw/b5vu/fP2b03Df95+31Rmft/UbvgtaZn2vsn983audo0jZw/7 Hu0+8hr1/o68Vh1+5B1qmfyM5lk7fibzHFnxaje/OGziu4/8C9v9HXm7bfiRW2xl5hab58gt tmVai61TG+m7gb/ZXxsPfuYAzVewa+PMgTCROggmsTeJnoe1ALBTBwpB2gR6JtAbSCaQrB0C cDmcbn8Y9RSYzF6oYNdCyISQDcURimsyTMEdDhHUkUKQFkVPFL2RZCLJRkA4rjCDP446Fqaz FyPYtWgy0WRjcMTgmg6xuGfATOp4IUibRc8seuPJxJOdCTNwxRn8SdRzIZG9BMGuzSEzh2wC jgRciTAX9zxIpk4RgrT59MynN4VMCtlkmIcryeDPoE6HxeylCXYtlUwq2TQcabgWQzruTMii zhaCtCX0LKE3m0w22SzIxJVh8BdSF0A+e3mCXcslk0s2D0cernwowL0ciqiLhSBtBT0r6C0m U0y2CJbjKjT4y6nLoJS9EsGurSazmmwJjhJcpVCGuwLWUFcKQdpL9LxEbyWZSrJroAJXucG/ lroGqtmrEuzay2ReJluFowpXNdTgXgfrqWuFIO0Vel6ht5ZMLdn1sA7XWoN/E/VG2MBenWDX XiPzGtk6HHW4NsBG3JthC3W9EKRtpWcrvfVk6slugc24Nhn8u6l3wU72GgS79iaZN8k24GjA tRN24d4DjdR7hSDtLXreoncvmb1kG2EPrt0G/wHq/dDMXpNg1/aR2Ue2CUcTrmbYj7sFDlK3 CkHaIXoO0dtKppXsQWjBdcDgP0F9HI6xd1Swa0fIHCF7FMdRXMfgOO6TcIq6TQjS3qPnPXrb yLSRPQUncZ0w+M9Sn4EO9toFu3aazGmy7TjacXXAGdydcI66SwjSztNznt4uMl1kz0EnrrMG /xXqy3CJvW7Brl0kc5FsN45uXJfgMu6rcI26RwjSPqbnY3p7yPSQvQZXcV0x+G9Q98F19noF u/YFmS/I9uLoxXUd+nD3w03qASFIu0XPLXoHyAyQvQn9uG4Y/Lrmr1nBogVommDXzFogTKQO gknsTaLnYc0GXtTeQpDmQ48Pvd5kvMl6gQ2Xwzk0/6nHgx97vgLzn8w4sr44fHH5wXjcAWCn DhSY//RMoArks4Hs2iFA85d/h+Y/9RSYzE6owPynO4RsKI5QXJNhCu5wiKCOFJj/9ETRG0km kmwEhOMKM/jjqGNhOnsxAvOfTDTZGBwxuKZDLO4ZMJM6XmD+0zOL3ngy8WRnwgxccQZ/EvVc SGQvQWD+k5lDNgFHAq5EmIt7HiRTpwjMf3rm05tCJoVsMszDlWTwZ1Cnw2L20gTmP5lUsmk4 0nAthnTcmZBFnS0w/+lZQm82mWyyWZCJK8PgL6QugHz28gTmP5lcsnk48nDlQwHu5VBEXSww /+lZQW8xmWKyRbAcV6HBX05dBqXslQjMfzKryZbgKMFVCmW4K2ANdaXA/KfnJXoryVSSXQMV uMoN/rXUNVDNXpXA/CfzMtkqHFW4qqEG9zpYT10rMP/peYXeWjK1ZNfDOlxrDf5N1BthA3t1 AvOfzGtk63DU4doAG3Fvhi3U9QLzn56t9NaTqSe7BTbj2mTw76beBTvZaxCY/2TeJNuAowHX TtiFew80Uu8VmP/0vEXvXjJ7yTbCHly7Df4D1Puhmb0mgflPZh/ZJhxNuJphP+4WOEjdKjD/ 6TlEbyuZVrIHoQXXAYP/BPVxOMbeUYH5T+YI2aM4juI6Bsdxn4RT1G0C85+e9+htI9NG9hSc xHXC4D9LfQY62GsXmP9kTpNtx9GOqwPO4O6Ec9RdAvOfnvP0dpHpInsOOnGdNfivUF+GS+x1 C8x/MhfJduPoxnUJLuO+CteoewTmPz0f09tDpofsNbiK64rBf4O6D66z1ysw/8l8QbYXRy+u 69CHux9uUg8IzH96btE7QGaA7E3ox3XD4NctzH+wWJj9AvPfwvy3MP8tzH8L8x+sFuY/eFF7 C8x/enzo9SbjTdYLbLgczqH5Tz0e/NjzFZj/ZMaR9cXhi8sPxuMOADt1oMD8p2cCvYFkAsna IQCXv8EfRj0FJrMXKjD/yYSQDcURimsyTMEdDhHUkQLzn54oeiPJRJKNgHBcYQZ/HHUsTGcv RmD+k4kmG4MjBtd0iMU9A2ZSxwvMf3pm0RtPJp7sTJiBK87gT6KeC4nsJQjMfzJzyCbgSMCV CHNxz4Nk6hSB+U/PfHpTyKSQTYZ5uJIM/gzqdFjMXprA/CeTSjYNRxquxZCOOxOyqLMF5j89 S+jNJpNNNgsycWUY/IXUBZDPXp7A/CeTSzYPRx6ufCgBAAAAAgAAAAMAAAAEAAAABQAAAAYA AAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAD+////DgAAAA8AAAAQAAAAEQAAABIAAAATAAAA FAAAADQAAAD9////FwAAADsAAAD+////PAAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEA AAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA LwAAADAAAAAxAAAAMgAAADMAAAD+////NQAAADYAAAA3AAAAOAAAADkAAAA6AAAA/v////7/ //89AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAP7///////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAWAAUB//////////8JAAAABgkCAAAAAADAAAAAAAAARgAAAADAw8a4 aZbAAdAsNlpvlsABGQAAAEASAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAAmxwAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQgAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAqGAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEBCwAAAP////8EAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAwcShab5bAAdAsNlpvlsABAAAAAAAAAAAAAAAAXwAxADAANAAzADYANQA0ADQAOQAxAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAQH//////////wYA AADG34m54VnSEYaLAMBPsXnyAAAAADBxKFpvlsABMHEoWm+WwAEAAAAAAAAAAAAAAAABAE8A bABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAUAAAAAAAAAAMATwBiAGoASQBuAGYAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBBQAAAAcAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAQAAAAAAAAARABlAHMAaQBnAG4AZQByAEQA bwBjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAAAzIAAAAA AAD+/////v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAP7///8NAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAD+////FwAAABgAAAAZAAAAGgAAABsA AAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA AAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAA RAAAAEUAAABGAAAA/v///0gAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////wEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQA AgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAJAIAABIAAAABAAAA mAAAAAIAAACgAAAAAwAAAEQBAAAEAAAAUAEAAAUAAABoAQAABgAAAHQBAAAHAAAAgAEAAAgA AACUAQAACQAAAKwBAAASAAAAuAEAAAoAAADUAQAACwAAAOABAAAMAAAA7AEAAA0AAAD4AQAA DgAAAAQCAAAPAAAADAIAABAAAAAUAgAAEwAAABwCAAACAAAA5AQAAB4AAACZAAAARmlndXJl IDEgZGVwaWN0cyBhIGZyYWdtZW50IG9mIGFuIFNESCBlcXVpcG1lbnQgd2l0aCBhIEdiRSAo dHJpYnV0YXJ5KSBwb3J0IHVuaXQgKDR4IDFHYkUgaW50ZXJmYWNlcyksIGEgSGlnaGVyIE9y ZGVyIEZhYnJpYyB1bml0IGFuZCA0IFNUTS1OIHBvcnQgdW5pdHMAACgAHgAAAAEAAAAAaWd1 REVTSUdORVJET0MAAAgAAnic1X0JXBVV+/8zAyIoKu6oiFcF9xQVFcXluqSWppZaVlq4pma+ VFboazVzLyrgAiouiRaWppYmlZml2c2wbLey4vW1olKjMqPyLbXF33nOmfVyhrkX6D/8xw+e We48zzPL93ue85znnGkr1FgGM0YtWQqnxtUSl9wNAvkXEuoDsnjChBqwsUMIlPwsgrqo22Fk /coVsFyEmuFUyDfSnggBt30JdH/G83Q35L7mgxqfHQUY8TlAxE0ivBRFlYRAKODvj4jsTxTh igRna80KwaMzyD+26Gs9w8gZtfHkGmFsT5jvJMBxQQAso1oLkHNKANdIVo57RYCEOSK4G4q0 lHqQUyNDrEzcMU4xsRjKMVG6Amfr2JhYNxRNrKnsqpkzk9mIJdqY8AtQG7FEG1O+B2ojlmij WkK9Gla29unLbP3Pt5qtPTm3E2BWVPm2kicfUj/MeEddY5i1WNI7OpNZiyVaC5eZtVhSKxvU tLCyTolEfjIQAMudU8le9nKdbWhz/xqFk7XQ1Fx2FpbH0wEaR1jpwV/hX4d8gAMZmh5ybUKT WngSbiXcx8QUPA9Q/DRA09r4Q0WcRxF33REi7ug9ANvJ1UZmAxwiZwjRQGXWEEUqCXflCMze Y3XIrRt8z5yp84i2ZtAcDEtow/VhkNvrgbQUovHgpuR9RM77sQDvxpGLentmYcxsUt6Wl5x7 jNzZpQD7lgHEbie3bDd5uGR7UBbAqscBbtwF0AKgDbmOWmC/uLRyc3dWJk1n5YlcVqa+wcrI i6zc2VGg5bBbWVm8gpWLDwsQw9HQ0qXcU7ZcuXLlYfzDBzVpI+4RRHeJB2KdsrkVT4Xt02NG u5wyunWFjAb5tvMnT54nTCVAhvJQXCYRIWzvA73QppS05E0HiwFakccU+z5A3LsBXKdx0auH rNslbV2gNohE02jDL0L8zkU7aoWtF99VjsWGrW+1WDu6admHtBxB/qaRv6vBTbc9JW6DdLNM 0bCuSG8QpUsXigzSP6K/IRwPI8nfzX7SybEGjIOmn0tSTwpb3zC0TSSUw27INlhufFGz5mxb G3aLI8+PsRvSEJZYecXXBZ2OUncY9LQhVNByFakNXgZI3EOMaccu3fbdaA8djDdrY9tlGh3V KVDoKJnRUfFXMwu7ELorvi8vedtPAD+uBih8BuDgewA5HwOcJNtXPwvwJqnGJx8H6OgUSjpx NHR2cekI7+7sV3GPIKY29EIXp2y+iqciADpCo7s6ZXS3ChkNsidYOiqow+gouZJ0NOG4th4M HS3rmU9KdDhiw5bV0/WrdHQ1+VtA/khdDcQnAOIbwHxlfYFCIt6GqUFQ1LI2F0hZk2lMjDJo ZBSVSv5HZwkf3p2aJoB7/bThe01rWxNlLWu7MaEeHvN1X1jnTK/cz0oHHbuzw96tC1710R9Q SjnWg1FW+AfEcfoCjA5T9yjFUOoAIjPlfM0cwh71QWeoNYwJpfHoMOUOBVh3kLAKeb92kzOE nuzKbV+XROhlvFcXYnWGOpqxKXkjqchDlzCGmvT+zMLIw6SclpecHitAy5sAthEPuPUpQpdE TTuy3b8Y4LH/AIwnjm9vp4DTh6MhycVlKHSWRuKDJE8yv40X+jplcz+eigAYCo1Odsro/hUy GuRPg2WojKOMoZaEVo6h5iZo60ExVGw+KRsC5Ys4neVUhsJKHh0M5AlSL8NdwPgjVfmbA4yx 7lCu9H5l31RlGx2u4eRvnMovbfKDYbMmyJ31mXXCNoN1jM1U7chg/1I0TiJ/aeQPXwIkgARl /3XAXL85yu+xDrrXzyois08G3WNivdgLAxqA7qghy6llnY39GMthWfKXdhVnB9o4aoPwnof6 pigRhimsPexuZNAz6aBBT/gNTA+WRj2DbfQMaYx6Uu5ierBEPUObgIXjmTaH6cHSqGeYjZ6r m6IeeJDpwRL1DI826DE5nrTZ/gVzcI16RtjoGdkM9eSvYHqwRD3XNLe6HqRB1IOlUc+1NnpG tUA96OahHixRz+gYgx53tlvXc2wv04OlUc91NnrGtOTpGRtrum8GPUlvMj1YGvWMs9FzPbZb Q6WDTA+WqOcGF+jVrnrfZrxF9HhmAQyKAIjOI9UdwYIwHiCgancCTFT0Ar7M0QKrdt0Ep8/s 3ZR8jLgALxN52xJZnKKkOYtTdMgkIF9E3jtSTxU9BxBDfl+LbNckTJxPGgt/zwW40ana4CaO hkkuyzgFYhSr3XFjvaQt6JDNt/BUBFDtotG3OmX05EoYPcUpo2+rkNEgFwXjK8x3J2/aS3AQ m0Owj431bRDcYvAV7ndr60H4CqGL6qFXhOHn2NBFIfu0o5uW/ZeWeCv9AyzeseO49X0ocOr7 kFIBQygYio0NKR2QbtBwCvzre7W9RHhKa9HM5GoNNV2L8dqY1unhp5T9sSHTI3Q/atOyz6mV 6AMNBvR/zNIxeDuJ7jF5C0L07a3BojbCthGydoYQAhfjBGPbKKWNYhCMG87IOapxCA2OT20L OkkvV9pGY7Ft9FIPAT6JEGC+IEJkMwEEvPWBkPR0Vjns7uiFhB5Db/yzNyPpAkJcm6dtSs53 AZz/hLSZCIMXfDOr0F1bgIIHNieXTiH3czippjoTtz5GhBNuAYaR7QVdBbjUSISnBwj4XJyB 4SyOhjtcXJIu2CPAxkQ8IIilc7zY/nbG5jk8FQFQR1ow1HFDQfKmaZvJT/IBPiGvbaMLAVyn cdGBmpmq6+FTh//CHPmMGHScEBadwzI6TdCOqtRBanZ6LxDQCO77gIF6nnJlQ4E5+Aj+6cox lQTmG7bnGH6H56Gmccr6eOX385RyOugNh3tUaM8pVaFddxjdY4J27z/nxoEFtLEBkDRMoI5z 9L0maN8ZD4awR8odzD92rxdgHoZb/f0vKm4zUZ93HXmrbwd4bh6B9l3sSdi+HPPpBeGrTpdD ERla2GPbIXM/UU7ezMLcMQLkdMtLjtwrQCJhsy7zBRAfALi4RoA4sv16qgDnyWM5mU2DR87A 5G6OhnuICuHDkLUKu6vQpv2hDzFoSxFe0sRzyOYFPBUBuDJo9H1OGX1/hYwG+ZZgwx6HtlVJ P1Hm9FJtPZiwR0bvNFB7cjLCj2lHjXyEnJOo8kKEFETYIqPNPmU/kd5FDyWpbgxjJbNkdCaY HUbGyYg49EB7sGAcbGagE4ElMo/aFEyzaQouRIcm1Nj1jpS0qGN5epDRsOywSdfzbxs9izup epDq1C7+BztTPd3ZDy8OYnem2KjvAxZARkfJL4D8UBflJtPAsZqfgX8PY0eIyqS37KXipH6F RNyyEwBLXid1A3n/D31ETpck9ths32tJBsljfNRSfIbmJ9U7wPyk1HbMT4ruMquwiDzBaF9e ckYLAdqfJo3Z7wA21CI0/zd5lcj25R8AmoQL0P0PIsvrFMildCi7SEuIEkF3lVU+jf4NaC4J 8qnv8XSQljpm9jKejgDIKTRYZ+lAPeYstUutnLPUN0dbD8pZisVmMG1nhWXUnKEdVclpNDBy Ggzo1LjpvvTHfSqNNOLQSLwkZXQFi3yftLNKyO+sElLCWyJSK89KmTYgl7K6UWMvK4G/y6zt Ii1PMKj7tsStqauzkzxbTNzB0pi4I62wU7XyInkjpVXdrSTP7s8kliwS/FN1pOzf8NycHqCx hE89l+blLCG+FublvDtHYHk50mqAwFhiDUhrjU9xZK2MKkvNkXIdg9s6jgppPVEi5A5Xt62y c6QNjpm9kacjwPwc6RHHzN5UIbOdy9DJ3FWxLvHMqHmgel6Zg/T6RiW3ymXoZA4s0KV3W2GQ zjyvcjJ0BJYtZKLNWiOlPOxutuQxZBksjSk60mY7HtvyK3LRo4mgeyxffWeQ/HWKQJNyPsgV WFKO9Bi7XHsuygdpq/EWSZBZZXk50uOOoeMJjgppm4s+9ui72LZVao603TGzn+TpCDA5R9rh mNk7K2S2c+k5mYUV5KJ6yEUsPSezu7F7mXFR1afnZHZHBmLpOZltCg0aGT8FkZ4DjDiMfJUJ krQL+7wN+TkZvzR/+84537LTKbtk1GF8dWyX4N+8kp4qRWZ6ujfoXtIZxnksGWdCrECTcd7L F1gyDvosgTHTHpCeMd6cmD6ZVZaPI+11DCsFHBXSs66AUnKk5xwz+3mejgCTcqR9jpn9QoXM di4tJ9PQSxcUM8Vh9Jml5WQ215ugKjM5m5aT2RWdbJaWk9nLmAddtpuuitJy4tkeE9v1iZH2 Y0Kc6p39epb9iOV9NGbshqUxT0J60c47O/AjcuBLSQbJPxr581gXJhlLk+SX7SQf/AElH+oL Fh4lBvFobscwP8mv2Ek+/B1KfrWfQbLJo6Rt7S+Yr2qS7LOT/Nq3KPlIspXNGBhEyViaJL9u J7nwDEo+2t8g+ZMfDJIzsphkLE2S37CT/OY3KPnYAIPkD84ZJF/cyiRjaZL8lp3kt79Cye8M BN1zV+8GzZoZMligWTNF9wksa0ai3BFI/fgeSO8rumjiTFSvTFPiTE5sxRNnpA8cY+zjUHaR PiRKhLjD6rZV7oz0kWNmf8zTEWAiinTCMbM/qYzZnzpm9mcVMtvBDJrT+t6gqvV4dJdZZDez vT6ApsoyaMLio5GVaAZNWHyD/0cZNERTAqhhl/imxg4vPYNmCHAzaNqzZABTxd4rSirCfiH/ XqLFn7DTWTW8izVjdhaVbcb85wTS9En8tULTKdNYdci6hEbsFWiXUMePBaVLiN7/QGj6FEif G2/GuQ6ZVdcl9IVjCPySo0IqdnGbMWW6hL5yzOyveTqqcZdQVuY4bT2YLqGsvtidwYgjK6Fs e8CmS2gQi+iYQNbhnPQN/pzn1dVIek3xRF8TynYJnbbzks58iPA7O0SXLglXdOl1MtJF2gOE pakH6Fs7ySW0B+i7oVaSR85kEo89IZbpAfqe9gD9gA0rhRSK1XNpD9DM+0XaA7R7jaj0AJ0D CIwUfgTpvPGhLU7KqroeoJ8cQ1cplF2kn12Wec+mHqBfHDP7V56OQHuALjhm9v8qZLaDY7T/ 0GNfQeXedC4BLfcmzthHUxU9QBktI3XpdY1DLm17gPom0j1GlsxKWiz9hmFgSx5DlsHS1AP0 ux2PXaQ9QJcwBKNwkfSQUfKRTJH2AO19RVR6gC6zy7Xnoj9A+tN4iwoGbqi6HqC/HEPH3xwV 0hWiRNDfCKseIBmcMlsWgLME2AMki46Z7Y/cwMx2cID2ZTu/is9FGwZgfIL1AG3oWLY3uup7 gDYMwH5m1gO0ob3PoDHoHqAObAiGka82DCyQQ5FADT1Aw8jKC0P+ZqezPJnejK92fiT6N53k GtgDJIchRapeEjBmYj1AiSNE2gO05y2R9QDJNdmF2r4dcjjIEcabc6HVhirrAZJrOYaV2hwV cqSLPnB1aiurHiC5jmNm1+XpCLAHSK7nmNlRwFmqcQ9Q1iVdT1DMFI2BEdYDtCFa75GvHj1A G5ocArUHaENT4zQT/1gPUDRjZxPbtbog178GdO+sppHlkgYydsPSGOWXG9h4Z3JD7AGSG11r kJxulLxzIpOMpUlyYzvJTbAHSG46Ciw8yui7mGQsTZKj7SQ3wx4guflog+SH/H1V2puS7ie5 hZ3kGOwBklteZ2XzxTwmGUuT5Fg7ya2wB0jGMTGqZHd/GsJQ66nnmWQsTZJb20lugz1Actux umTfIqPkoreZZCxNkuPsJMdjD5DcDt0N0e9u0B6gNnNF2gN04FGR9QDJmL8fUP3YAeSOii7a AzQjZkOV9QDJnRxj7M4cFXIXl2UUwdgDJF/lmNldeToC7EqRuzlmdgJwlkDN7u6Y2T0qZLZz PUCrllewwRGaD2ogd0OLVO1o1fUAbQjFOoD1AG1obpwC75/sAdrQsBjUsMuGkEkGrXoPEEZe OT1AjcqGXTbEzJB7Xg9le4B+/J2dzqrhj1gzBgdT+zdjErEHSO6FVKLQdMIgpRlDe4DaF4m0 ByjiT5H1AMmY8xYQTfcBWbMUl9I+WVXWAyQ7NkuTzJumSU52BdQDJPd3zOwBPB3VuAdoleTT 1oPqAUrGXFWlB2hA0IOC+uTTPabYZp9SeSAOiuZ5dTWiv1c80e/FMj1A8iA7L8mNPUDy4Am6 dPOQo2/PCoCzNk9sJ8IjxxTp5ETRMMWwwHQNsdM1FOebCT3+B5vreFw/NsexPOxGg/IZb+mX RqcewhQrnKrHb6S2fPV/0fDhOOGLyDv3XBYblr1/uzIsW0a2Dog3RoKMbRVtZHbxwKwqG5kt X+sYAEdxVMijXVze8B+cLV/nmNljeDoCHJ4tj3XM7HHAWarxAO1Va4q19WD8pKzkaFD9iaze XbSjVTNAO6veClAHaGfVTDFIL3eAdkPW4WUi0YHF8vXo7nCZBsN9OEIbS+MIbfkGO1IbX4Q8 NOHm8iQjd2FpHJMtT7STfOOnKPmmWwySh39hkIwTi6GtWMf7s+Mkyo433wo6O5rO7f8hY8ew cyo73sIegD073goynfxJZccJdZdXHTs6NjWUzJsbSr7dFRg7pjhm9lSejkDZcZpjZk+vkNkO suN2t7YeDDsuF32gsuPyZP50OhVnx+XxUaCy4/Joo6tZLju2ZPmMRnZcXneCPANhzWUaGjSM 01PeNQ6bacdhsyg73jGlPMlqYrqJHWfbSZ5D2XHubbpk35mQwbpkDBiirQcuiWXY8U7KjvNu B8PgKeO5p06IlB2f/ElU2DHQOX3k+SCbZvXZ3LQK2dGxaX1k3rw+Mp3YR9+2ZEfHZvaRKzO1 j+zY3D7y/2+T+6x6MV9bD4ode/tAY8cwfT6AKmLH9imgsWND46DRctmxRSTdY2LHppvlB1AY l2lGfi1SdsTSxI520/vICyk7LppanmTkLixN7Gg3oY+8mLLjg9N0yeZm/U2hAoy4RYBPXhYh Ygp9K6ya9Q/Z6XoYX/VQdzOBot73vkhLWcJfqc6nm83zAxmvk8s6PwCgbQnhQNK0S/8dQ3oy e4LaKy5Y0asHZC/unbzuXno0td1yLaS36TUW0vu6EQvplS6fWQjEvy1tlZdcMFCALNKGzY8U YB65K7mtBVhFtnvWI9ukDsmNJRanOwb4JRwV8lIXl15LJ7KxckivKTEyyMscMzuDp8P2IYL0 Z7Ahvdc2AQ3pNfq6ciG9tyo2z8+KCL0VuiJ6tHZ007IztETIdleYRI5JKSeZe3m7VDkTg/lc YMydyIAxcpYKjCx2AfbAWA4yTdBMSuhJ/yBihSUwUp5gwEjpw4BxeQYDxqmFDBi1ZjJglNyn AGOlY2/YKo4KOdvFBQZOma4CI/88qcBzHDN7NU9HdQaGz62tBwWMNhtBA0ZDvbPFCIweahV7 XssQCS8bnlkRAfIa7N3iAuOhtxkwJv9XBcZadgH2wMgFmc6PlNO1J/1bPMAaGDnRsygwcnYz YHQ6yYAR+RMDRuxJBow/v1eAsd6xN2wDR4W80cV3yL/WgVHgI8BwbPIkufzJk6ohMD61m7DE f1GAET8JNGD01+tJIzD6qMDwFajA6Fq2h3XFgMVyHuaG+QNj8VECjBeiBehJgLGW3PRcCozN 7ALsgbEF5EeNhu+MtQZGwaxZhSUEBAWX85I3DhHg2g7kQUQJ0GWAAIvjBZhItjs3JKb0FWBF G/KcH3PsDcvnqJC3urjAKEgQAP1WNhSGAONxx8zmzZtUrYFxXE+JCAoYgpoMQYARZxxYy4CB Q9FUV8qrj/iIZYkKJmDE7pS3Ybq3/6zMtMZoQh4t1hgX3IJSY2xnF2APjCdB3mE0PL9XliUw wj2sxghvspnWGI8PFWiNkT5JoDXGo2Qba4zFEwRWY+x07A3bxVEhP+XiAiN8tKDVGPAnAcbT jpm9m6ejOgPjtJ5kGwwwVvbPBxUYKw2ZeEZgaK7Un6ACIzKa7jH1dPXKl/dg8hDXlRq2nQGj zX4VGM+wC7AHxl6QqeMW+c091OhTNVdaAmPcrwwY45YxYHy/jwHj3bcYME7vY8A4clQBxrOO vWHPcVTIz7u4wMB5kTVg7CTAcGyGJbn8GZaqITAu241C9F8UYAyMBA0YfYxzGOnA0FypnRow 2s6je4zAWFnzlLx/LlgAo9dgkQLj0A2iAowX2QXYA+MAyC/h3kh3OkSmpMO8Vjow+irA2NZY aWNk38HaGG23UGC8NU6kwLhrlkiB8QnZRmBMniYyYLzs2Bt2kKNCPuTitzFuFjVgHE9LB/kV x8w+DJzlHwFGXwaMxtsqB4yfU7T1oIDRTO/9W1ljpHZUBQZmcaquVHracRUYPWgLwQyMVvPk V3EMmz8waBR66SQRGhJg1JkrwgIKDB+7AHtgvAbyEdyr9oalhVoDA3bcURiNA46TtyQf6ydA 39kiHAgX4PMHRdjdUoB2ZDu5tgB7FoqwuTl5zq879oYVclTIR13cgWRwtwip9RkwXLEEGG84 ZvabPB3VGBhZ71SwxuhpAEbzaO2oERiqK5Ue61KBcVUK3WMCRmiafAwrEm6NUfgeqzFGfanW GG+xC7AHxtsgv6PZ1XpGSGjrVZbASIiZTWuMhAJWY8z5nNUYdX5lNcaMz1mN8cN5pcZ417E3 7D2OCvl9F7fGSDir1xgFIwgwHJv6TOZNfVatgXEkRVsPBhirWkwGFRir+uiTDxiBobpS6SO0 qFQtNjuVERirWofKH2JSBPeTSO9PBFjSVYCimQBnB2D+xEfsAuyB8THIJ3DvvFX/gjBSJrp0 YPylACNGaWOM3DGzcDZRMzI5LzlaFuBq0ugJHyvA1AcB/pwuwI1ke8/1AqQsBKg7lTznTxx7 wz7lqJA/c3GBMfJuAN9NDBipuwgwihwz+z88Hf8IMP5S2hgxlQPGAbe2HhQwIopAA0YDfTYd FRiYKqC5Uru0cf2t2OxyJmC4EuWTOGqHC4wmmxkwXLtVYPhPZ2YJjFMga9OZlTT+QEwCa2Bs /JEBY6PMgLFuLwPGs68zYDy6lwFj56sKMBybzkzmTWcmF7u4wMAhRCowSp8lwPjKMbO/5umo zsB4xu7zW/6LAowOOaABo3vZGgOBoblSz2qf5ItlgDABA5LkbzA1jguMG88yYKT8pgLjNLsA e2CcAfmsanDU+nQ4Hb/cEhjH+8yiwDj+DgPGe5cYML6rI1BgfHGJAaMkQmDA+NaxN6yEo0L+ zsUFBv0wuQIM36MEGN87ZvYPPB3VGRjb87X1oNoYVxmiUiHG6Tt1YPRUgfGoNrqrWdlPPi2P Py2fw84ULjAunREpMEJ+ExVg/MguwB4Y50H+yWj4qaRsS2Bk9JlNgZHxzhYKjCWXRAqMrXVC KDBkso3AWB4RwoBR6tgb9jNHhfyLiwsMHHCqAiPKRYDxq2Nmc1/RagyM5ZE+bT0YYGT3kEAF RvYA43QoOjDmq8BwRanA6Mx6TYzAyE46Jf8PE48FX99Jx4Y0eS7n50GbHsFFcOd9ceHJPrcd 99HRzn3PEaAcqM0yyI+5QiC6VDDle//2BWZD/o4DqLXRMKwh7/r6KzfU6dOE+EgvkGogXoTd JxBkF9nNsM/3vgQynfBN/UCzKzRby/fuPITlex8n4jHfGz/QPDmUfaD5xAwB/hsvwIW2Ajzd XwTfSAFOku30dgKs6CVC3tXknfnDsbf1Tyi7yH+5+L3oft9olv92zOwrPB0B5Huj2R5wymyP AJzFPt/bUzfYfO8hnWm+t9DkeKXyvZeLdp3//Hzv7M5YUbIZD7J7ls2KwRj2WOUqcMqjqcDm V0DgYofmdLWbR/n4c2B54NldcTIjnLClZ1i2S88A3bTsLP0NJiHg6OoJSolPtItihZqBjt8s TSxnv1pOt/kNyu4dwO96G+R19LtqYnMIi1iZ2DLU5RExKdrym9fIilhOqidqmeSeEJvsbk8o jqEIxal/3A1F+llsqYcInhr3WalKupapwtKkKsxOVU0c9xDqm8JUYUlVhT9gparoZqYKS5Oq CDtVtfCVCMWMUVSFJVVVe6GVKvqx8FL20XCTqkg7VXUWoSr6HXGiCkuqqu6/rVRFL2SqsDSp qmenKgonEQnNX8FUYUlV1X/QSlWHfKYKS5Mqu5m3PA0fQlUFzzNVWFJVjR62UnWsB1NxcQfA xq6isX72NJZAqVnGDWeCpIOkqX89EdhEBr3SzlMEXo/zG34wCmBKUxF+WUU0tCNU4GmKxwKo tD3R4GkGhmVBjO4Zz9/JPON+I5hnXLJ/ZuGxaBFKrs1LTrtThBtvB5jdV4ScJwEmjxFhLtm+ kizCyscJakcRi5s7Vo204KjwxBAlnK+v49QKriH4DEiTsXs6eFo6ZnYsT0cAo52ig/WMd85n nvGIfpXzjFtULMMnuxFGtpXar3HZ1LfB5G+ichUYWkeGRZrSJwh009+ld9eak01i6B5TPRCz wNMKfRlLFOLEG4hCnBTPiEKXFwwoTJvCUHg8jbzTrbHeVlG4mQmUxmAf2KZxpJp2i/BhJoH1 WERhG3a37FHYFjxxxruU0y1HQ+G0PQyF7yTrKPQNZShMXS/CtYSNUmaI0Dif1NsLRehNtv+e JcJdWwB63U8sjnfsdW7HUeFpT5QIAq3acTGiEGcQpH1gO4gP2sExszsCZwkAhVHBonDPNIbC 5Hcqh8KofG09GBTm1HWDOq1vTtfN2lEVhTh7ouoF9lauxjRScIfWLzaIzfFhRB95hz2dcDQX F33oZ2DdhyWiUKtuO9tVt12WktVQfF2wVsQS8em5all5qhDgWKZMNajqaqeqW4aqCqGPJc5E 6UnI5KhyZ7sZp6AK5JQDi82c0v1B8pp7euAwJj/6AN9kcu786wHuvkMEnBlx5/1IH/gV34Do IxE8vYyPt7ifTh9xzzD6QKbn0UfkTEYf4x9j9IEjnpA+Cjcr9NHbMRz24ajwJBElwuLe6rYl fTg2KZmHNynZP0Ifz8Qx+kD/rDL0MV7fGxR9wAHQ6OMq3VaVPnAeuwDpox9riproo1+xJ3k5 WAANsYwAwzI1w4Dp/naYHpCGMBy4giN58VEFwigRIYxfZDFCeBCFsHsllPUAXnudnHtqGIC8 SoSX1hHrtiCEB7NbbQ/hIeAZarzF7lo6hFduZRBeMJ4P4fsmMQh/9zSDcNokBuGJuxQID3MM C1dzVHiGu7jBszIQHuGY2SOBswQA4ZhgIbx1JYPw+AWVg/DwYm09KAi3whoObzCBcEzZCLUa C0JPwBizwavy/yiJAc5NTtE9JjjXcnuuwSGsXNAhjBFsNPqw1wDna+3gPIrCeXS2QXLTr5hB LC7yqRIX+dSvWX+dneQxK1Dy2BwryWlnlTDIWT/J4+wkX5+Fkm9YbSWZzmJVymazMkkebyd5 QgZKnrjGSvKBGgKVjKVJ8o12km9aipInrbWSjOlrKBlLk+Sb7STfko6Sb821kjy7P5OMpUny ZDvJUzwo+bZ1VpLDP2D3F2eq8I/D3C7huSnrQaP6/EbKuTTkUq+EhVx6dBaUkMtUPBYI1U8D j2nOp6J6OVUXcpnhGGfO5KjwzHJZUr0p5HKHY2bP5umoziGX7j5tPRiqX10jBdSQy+pB+tTI lQi5dGXVpInm6xV55uCAbEvAYWOPfjPaL+Qyl/pWd9JB9MrcrgrgWHTl5DkWXanfTlCiK/PY jbEH3F3gmW+8IaPrVWF05V+OvbmpUHbx3O0KzLe6xzGz7+XpqM7Rlfb63qAA1wAjkqx5tDqk bL6YGl1R+7fwaiyaR22L6R4z0EZ7FjwCFkDLj2A1Gpam6Mp9dnXm/YsQhg9sKk8yQhdLUzDF boYnz0LqqS3K40imTTokB5RIZ6rzi538m5LDYgxR+ZEDi5088yOLncyOF5TYCfbzBEQOD4Hn YePDcyWsrrrYieQYymSOCo+HKBFc2jcbLcnB65jZ6cBZqnHsZMVan7YeFDnE4XgehRxaGsmB 5ampsZMAyCGx7OjO1Qkuz5ItYAE0hC4CDEtT7GSpHYSXUQhnPMqRTJtxCGGUSCcq94udZFII Zz0GZet3GjuJ+YrFTi51F5TYyXJ2q+0hvAI8K423eGSn1VUXO1nlGBayOSo8OUSJUFNL9LCE 8GrHzF7D01GNYycr51Rs+o7V/TACwmInq9vow/NUCPvHToxQLid20pHeYzOcO430rM0HC9Ah jBFsWJpiJ7l2cF5H4bx+qy5ZGvsLk8ziEPeyljeds9vY8t5gJ3kjjZ088riV5AMeJQ7h8ZO8 yU5yHo2dbH7CSvKkNUocYo2f5C12kh+lsZPHtllJvriVScbSJDnfTvJWGjt5fLuV5I3PMslY miQ/YSd5G42dbH/SSvLOIiYZS5PkJ+0k76Cxk507rCSPvJNJTCsuGzvZRWMnT2E4UaH6cWOU c2nsZGy6QGMn97ypxk6exmOBUP1u8OwBw1LYd3XVxU6ecYwz93JUeApcgcVOHJsuxMObLqQ6 x05W3qDrCYbq19TAbDIWO1ljip0wqh8MVRE7Wd230PM8Tk1kCThsyiHg/GMn+6hv9cJToAHO rQCOxU4arBRo7OSZw2rsZD+7MfaAexE8B4w3ZFvbNRrgej7LANcxke9btZjNfKthm5lv1XU2 863efkTxrV5y7M19maPCc5AoEfSna+lbHXLM7Fd4OgIAXGSwgHu2JwNcYsfKAa51irYeFODq Y34YDnomgAs1TlvAAKfGTuziJhPoHiPI1rTd5jmM1Q0XZMXbWW2GpSlu8qpdfemjcZPXdpcn GWGLpSlucsRO8uvUSyvcw5FMm3NIDCgRicE/bnKUEsMbOK2VHzGwuMlBQgwYNzn5iho3oRNj BEIMx8DzlvHBrWijE8P/FGLY3oNPDJ8rxODJY8TwmUIMv21UiOFtxxD2DpRdPO8SJcI27bMo lsTwnmNmv8/T8Y8Qw/8YMfTYXiliyB7m09aDIoY2CGWFGJImaEf94yY2xNCi7Gc/1rRZ4fkA /TAuyBC2CC4sTTGT43bw/ZDC96MCjmTafEP4okSEr3/M5GMK3xPPQtl6ncZMOskCjZnMe1uN mXzCbrM9fD8Fz2fG2+vqpsP3tu0Mvh+N4sN3+GQGX/zCN8IXtxG+GdsV+Do2S4OHN0uD56QL x4lo25bw/a9jZp/i6fgnHOnttzH4jvqocvC9rWJj6Nf2xUG/zJFeKxgnl+DHTAKIl3Bmll/T zeX5HNsmXMAhhBFoWJriJV/YQflLCuXi5w2Sc/5kktkQEtKmpUNISGlqbX9lJ/lrGi/5Zp+V 5GPtmGQsTZJP20k+Q+MlZ1+wkjy7N5OMpUnyt3aSS2i85Lv9VpLDhzPJWJokf28n+QcaLzn3 opVk9KNoVGOin+Qf7SSfp/GSnw5YSUaKp3GpxX6SS+0k/0zjJb+8ZCUZpeEfJhD7x0t+pfGS C9gmUeMl2cq5NF5yeweRxks8d4pKvIR24QRC87+B53cwLO5aa6ouXnLRMb68xFHhuexCL22K um0ZL3FsKLGHN5S4OsdLssenaOtB0XxvDKkrNN/ROLi1wvESIZ/uMdF8LbfnL5yY0xJw2IRD wPnHS/6mftWVQ6D7VQrgWLxkckeRxku6zRVZvMSr3BjbZ+UVwGu6O7n912qAW72LAe6uoXy/ amEK86vOPsH8qtkpzK9K3sr8Km+IU2+uNxTKLt4aroByTbxhjpldk6cjAMA1ChZwu1YzwA29 q3KA61CsrQcFuP5uUoYDBdzAfdpR/3gJaY8DjhSxScfvUTZusrZ/rjccw09csJVew2o1LI1x E6/d6GNvLYybeGsfLk8ywhdLY9zEazfY2FsHvTVv3Vc5kmmTDgkCJSJB+MVNvPWQILxRPihD ECxuktBJpHGTpXNEFjfx1sdjgRBEA/A2ND7AItAJYvxTjCC+G8wniOSpjCDiFILoP5URxJp8 hSAaOYa0xhwV3iYuGlAtjWfblgTR1DGzo4Gz/BME8dR4RhCDv6scQbTW9QRFEOGYWKkQxFXz tKP+cZMACWJA2YmT10KRt9lrYAE2hC+CDEtj/MTb3A7GLSiMY45wJNPmHMIYJSKM/eIn3pYU xrGvQ9l6nsZPHmsp0vhJU4IdGj/xtmK32x7GLvC2Nt7mzc10GB/awmDc5FY+jLdNYDB+eS+D 8dMTGIzb7lFg3MYxPLTlqPDGuehr5D+dcxkYOzbQ2MsbaBwIjF3BwnjLIQbjW5tUDsaNKzZu fm0/zCmtDRTGDfK1o1bxE384lxNH6TKM7jFButlmb/tCsAAeQhkBh6UxjuLtYAfpjhTSnY5S yUkLs39Py/69dBD9QcbzvpZHWsccWe3zQQ3VkI0dQqDkZyq+J9QgDy7E2/kN5Z5ABqlN3QS2 rv4hgPMoe7tgF4Y6PC/1RZ8qF+q8TLB54gCpPkmLZOu3CPer2GOxh3tX8HbDvae2Z9Kj21rm Uri7SXNl1N5NycfI85T6kv2JAMdfnlnY4WkRjo/JS57dLARazAU48JYIeaTWnvy3CJ3I9uR3 SVP+MYCOfxCLExzDTXeOCm8PF721h7awbW1mRXJ38OurCHfXvkzw9nTM7ESejgDmtqJm93LM 7N7AWQI1u49jZicBZwmAXIuDIdf57uRNe0cRXssB6CsBJG4L4EKNi4Fcax/X1oOZkiu3Jupk fUu5MfYJfWwwpJsey9zn4k7DFWqyTNPUwwdqfCS3Y65BUyn9zTXA4iA43xQOq8JJv/CDkFOB TYM1k6vV3EY3XqOiVVT3E61hxuv7mVqJfWKouaOfdAyys18aK4fcltu8NJrPnavzJ3Lam/tE uDlOgMPfINXSUfGBUG0yePvj3v5FmfRhHOpmTbUdxs8qLN5PTP82L9kVHwL3EuGpn4jwa7IA jWqFwANk+6fPRPiqjwBnw0LAO8AxFA3kqPAOcnEjKB1akp3nGdXmbCXgdztm9mCejgA4i5o9 xDGzhwJnCdRsx4bLe3nD5QOh2tNOUa0oaetBUW0iDrtUqLZToXa0/NxpNz2WuTUnGKqtcQ40 qh0YadAUJNWatNpSbdwCxSKitZExTcFMtSa6VTRgsJvtMdFtt0Pe4Zhw4+/Z0m+fNlsuwLeE br0+AfZRuh0BEBjdjgQvWgGT32KebXgva7rFL9kVHBbpl+xKu4RA3uMCuD8XocUpAU7XD4FM sv3ll4R+PxNgd11Ct9c6hqRRHBXe0S5uQxa/ZHf8f0pDNpsQwHWOmT2GpyMA3qJmj3XM7HGV Mft6x8y+oUJmO0i3D0vaejB0u7bOabwwoGGDuro/b5124ab7M7MLgqDatZEYWlB6/SLzDVqC pFqTVjuqzaqXpF1bVg09rMKjWhPdZuuzD5WdiT63V7h3/NtgQbc7rhIp3daeJSp0Syk+ELqd CN4bjRcUF6PT7dE9jG5X9md0m7LhDkq3KZ23ULqNv1qkdPucLFK6bUq2kW7/jZ+FQ7q9yTEk TeKo8N5MlAglIUX12LZKt9jpotJtTrwXvLc4ZvatPB2BuIlo9mTHzJ4CnCVQs29zzOzbK2Q2 yCXB0u2eo4xu+6+sHN3ebzcy0MK7bYEBCDa4N7eLftQ+Suumx73xQXm4IIHm4YYbfc3gaNes 1dbDjU0AzcNtos+f7k+7SHYd/TRgAq5E95goNybOm4Lp19yAQsG7Av34x8vE1aQf//Ci/RDA xz+808Brmm8nrfc66++oxd7BvqP23Gb2HbVigX1H7QL7Kk4S2caPfwwpZV/F8To2346XN9+O V5lvR7kP+nfUSvSv4kRFLgGvY/PteMufb6f6ffwjS3lVcQmmq2ZdTf07ausMwR+VBBCoUxVg LInUPv7R8QTdYwTGut5p3jmIMNFH43Cz+32mjAMqfVUptf2xrj+ufBD1m2/n0DCYXRw2GCJ2 kd/U+4U86g8AhkSLmoWCdy67UHsA3Qle2mN87o+lFPFJA3QA/bCfAcjdiQGoKHJWYepfAhTl 5yW7xonw+usAUbEihJCrC+0pwjtke79LhL+/A2iaQFqsdzn2Js6Hsov3Xy5uRA6nj8PkWwSQ FEIAlMruowNm383TYQ8gOTxYAO3/gQGok7tyAKJT2rMlKAAl4mQgzLFfF5egHVUBhHt6GP7U jxIuCZFUMDVge0xgGpDkvec9CAhM8oDLV8Z+/qvvhTFhMPJLBNPeswBn3hYgCmfo+1nQrBW8 97KLtgfTAvBiuiOMnpcOuQk9YXRNazCV9JxVOEkQoeTNvOTwCSJ8/D3AxdYiNGwswLneInxI ttPjRAitL8AZAi7v/Y6B6QGOCm+ai58gSJi5oJMSb2mfDt6F7D46YPYino7qDKa2dn1b/osC puTRoIEp4qJ2lAcmnHZa+8Jne62V3MpH95jAVHO099849CwAMB2fS4gr/V13QkwIpPavT8D0 xkTy5r4jQPuZIvQxgWkxu2h7MD0IXvz4BnT5cgk9uq3teksw4UfVMy4J9KPqSaNF+GEK8VKb i9A5Q4SYbiKcIduHY0SIThehVRcCpocdA5PEUeGVXVww4UfVi9so3fKpS8HrYffRAbO9PB3V GUz99LhlMGBaXx/PY2BaH6pPWaWCyQgkY820NFXrUOWMTF7fdtv/AdClpMd4nONiYGBoYWBk qAFiDiBbEojlgdgcyGcD0ouAWA6I7YB4NZTtDsRLkcTToWxRIPaDmqHGwsDwm5mB4TIQRwD5 FUAsDMQKSGwYjazfC6hPHoi/E6EvDGrXPKD6YiD2ZiHNLmqxQ1kZGLSAmImVsP0wGhZO3UB/ JgCxBR7/wtQqQcPlPIlhisyGhZk80IzPTAwMp5hwm5WLpC8CygY6gcEKShsACRYgvk2Ee5D1 hwAJDSD+T4Q+J6ieFUCiBoiDiYhjZLuoxU4Exq0pEPOQEMcwtxMT1jE47B0Na9qGdTUDIo3D wlqHBcK4TmJYY4u3wWYWsn/Fgea8BobTITxhNapmaKnxgsbzAyCxBYi7icjDmUhpghK2PwOk bjEGupMdiO/hcSdMrTZQ3X+gumt41OKyD5YviDEDW34yB+rjBuJHROqjFhtmPzHhRK4fsdk3 EsJJHajuN1DdJQrCiVQzSHHnYAknfaA6ZiC+RUE4kWoGTJ81UA8/ED8jUh+szZoJbA/YArEI Ce2CXKBaRyCWoLGeQqBaVyCWIUEPMeW5N1DNd6D8OTqoAQBxffe0REVTSUdORVJET0MARDAA AIMDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMC9HIqoiwXmPz0r6C0mU0y2CJbjKjT4y6nL oJS9EoH5T2Y12RIcJbhKoQx3BayhrhSY//S8RG8lmUqya6ACV7nBv5a6BqrZqxKY/2ReJluF owpXNdTgXgfrqWsF5j89r9BbS6aW7HpYh2utwb+JeiNsYK9OYP6TeY1sHY46XBtgI+7NsIW6 XmD+07OV3noy9WS3wGZcmwz+3dS7YCd7DQLzn8ybZBtwNODaCbtw74FG6r0C85+et+jdS2Yv 2UbYg2u3wX+Aej80s9ckMP/J7CPbhKMJVzPsx90CB6lbBeY/PYfobSXTSvYgtOA6YPCfoD4O x9g7KjD/yRwhexTHUVzH4Djuk3CKuk1g/tPzHr1tZNrInoKTuE4Y/Gepz0AHe+0C85/MabLt ONpxdcAZ3J1wjrpLYP7Tc57eLjJdZM9BJ66zBv8V6stwib1ugflP5iLZbhzduC7BZdxX4Rp1 j8D8p+djenvI9JC9BldxXTH4b1D3wXX2egXmP5kvyPbi6MV1Hfpw98NN6gGB+U/PLXoHyAyQ vQn9uG4Y/LqV+Q8WK7NfYP5bmf9W5r+V+W9l/oPVyvwHL2pvgflPjw+93mS8yXqBDZfDOTT/ qceDH3u+AvOfzDiyvjh8cfnBeNwBYKcOFJj/9EygN5BMIFk7BODyN/jDqKfAZPZCBeY/mRCy oThCcU2GKbjDIYI6UmD+0xNFbySZSLIREI4rzOCPo46F6ezFCMx/MtFkY3DE4JoOsbhnwEzq eIH5T88seuPJxJOdCTNwxRn8SdRzIZG9BIH5T2YO2QQcCbgSYS7ueZBMnSIw/+mZT28KmRSy yTAPV5LBn0GdDovZSxOY/2RSyabhSMO1GNJxZ0IWdbbA/KdnCb3ZZLLJZkEmrgyDv5C6APLZ yxOY/2RyyebhyMOVDwW4l0MRdbHA/KdnBb3FZIrJFsFyXIUGfzl1GZSyVyIw/8msJluCowRX KZThroA11JUC85+el+itJFNJdg1U4Co3+NdS10A1e1UC85/My2SrcFThqoYa3OtgPXWtwPyn 5xV6a8nUkl0P63CtNfg3UW+EDezVCcx/Mq+RrcNRh2sDbMS9GbZQ1wvMf3q20ltPpp7sFtiM a5PBv5t6F+xkr0Fg/pN5k2wDjgZcO2EX7j3QSL1XYP7T8xa9e8nsJdsIe3DtNvgPUO+HZvaa BOY/mX1km3A04WqG/bhb4CB1q8D8p+cQva1kWskehBZcBwz+E9TH4Rh7RwXmP5kjZI/iOIrr GBzHfRJOUbcJzH963qO3jUwb2VNwEtcJg/8s9RnoYK9dYP6TOU22HUc7rg44g7sTzlF3Ccx/ es7T20Wmi+w56MR11uC/Qn0ZLrHXLTD/yVwk242jG9cluIz7Klyj7hGY//R8TG8PmR6y1+Aq risG/w3qPrjOXq/A/CfzBdleHL24rkMf7n64ST0gMP/puUXvAJkBsjehH9cNg1/Xmf9g0Zn9 AvNfZ/7rzH+d+a8z/8GqM//Bi9pbYP7T40OvNxlvsl5gw+VwDs1/6vHgx56vwPwnM46sLw5f XH4wHncA2KkDBeY/PRPoDSQTSNYOAbj8Df4w6ikwmb1QgflPJoRsKI5QXJNhCu5wiKCOFJj/ 9ETRG0kmkmwEhOMKM/jjqGNhOnsxAvOfTDTZGBwxuKZDLO4ZMJM6XmD+0zOL3ngy8WRnwgxc cQZ/EvVcSGQvQWD+k5lDNgFHAq5EmIt7HiRTpwjMf3rm05tCJoVsMszDlWTwZ1Cnw2L20gTm P5lUsmk40nAthnTcmZBFnS0w/+lZQm82mWyyWZCJK8PgL6QugHz28gTmP5lcsnk48nDlQwHu 5VBEXSww/+lZQW8xmWKyRbAcV6HBX05dBqXslQjMfzKryZbgKMFVCmW4K2ANdaXA/KfnJXor yVSSXQMVuMoN/rXUNVDNXpXA/CfzMtkqHFW4qqEG9zpYT10rMP/peYXeWjK1ZNfDOlxrDf5N 1BthA3t1AvOfzGtk63DU4doAG3Fvhi3U9QLzn56t9NaTqSe7BTbj2mTw76beBTvZaxCY/2Te JNuAowHXTtiFew80Uu8VmP/0vEXvXjJ7yTbCHly7Df4D1Puhmb0mgflPZh/ZJhxNuJphP+4W OEjdKjD/6TlEbyuZVrIHoQXXAYP/BPVxOMbeUYH5T+YI2aM4juI6Bsdxn4RT1G0C85+e9+ht I9NG9hScxHXC4D9LfQY62GsXmP9kTpNtx9GOqwPO4O6Ec9RdAvOfnvP0dpHpInsOOnGdNfiv UF+GS+x1C8x/MhfJduPoxnUJLuO+CteoewTmPz0f09tDpofsNbiK64rBf4O6D66z1ysw/8l8 QbYXRy+u69CHux9uUg8IzH96btE7QGaA7E3ox3XD4NdtzH+w2Jj9AvPfxvy3Mf9tzH8b8x+s NuY/eFF7C8x/enzo9SbjTdYLbLgczqH5Tz0e/NjzFZj/ZMaR9cXhi8sPxuMOADt1oMD8p2cC vYFkAsnaIQCXv8EfRj0FJrMXKjD/yYSQDcURimsyTMEdDhHUkQLzn54oeiPJRJKNgHBcYQZ/ HHUsTGcvRmD+k4kmG4MjBtd0iMU9A2ZSxwvMf3pm0RtPJp7sTJiBy+G886l898P07mfp39C9 w43P0jvWnmfpvYc9i39nfqrNu92Yd6w9eR/X/+P/L/WQPEc8e+rEoecAhveo8uzD7Gn36smT pxRmx92r5xmzo+fpex5rk7Pnnsca0KTnnsf60OroSZg66R49Abr0TLtXT6U8A5EQN3LPa2az 89mQqfZ79HQ6e6bdq6fF+aRH9L16jjifyVjp6bnziZc/Wcq8OrWQEZ4vjLJUa47nC+d9P3ju 0mWrinKVSUqwMkqxu57P9KLvzmSiJJdYks0RVOGpaalTvxGcPuexGOd/H4vJdRVTY91VbExu hOJ48tYuz8E7nsWcIM8kOp5l9JEnuEe7nkj1k13HZx4YekbVb1iX43MPGP6e4YLlHSXe6l5/ xPojw3qs6YJlrMmzfor1U4b1StYrDetu1t2sne9gvfXv1MP/ZsD5DqZaLzn+9kyZvTj4x6UV RSsL5Tx9lBA5R+dzrU7PWP3vpnfv4nE+b/sHa6/0LUidGhuctrAkhHfI+fyq8Xmb+aYt1vlY POsx+nxTtO48Qg1HiNZHOkKi3idHWOQ6wiS5Fu6/UPAYqzE2uoyDGBvvYhwvxkP6B3InpqYt 4GIHL5yX5bjCIVyZANdTuJNuO/dbmB+2ude16gVLrep51w+yPmhYX2V91bD2N1+w+Js96yTW SYb1YdaHzZ6r1kE9/O8b3FftsHrbVcsa+ap1mN+9i8d91X6vOq9abMzIVy3EvMUaYvZctRDz GD3E7LlqHdQjHSFR/4PqvGrOI9z9qoWYqzF6rloH9XCj+6o1qu6rhvMrrlqI+RZmz1Vbpl2w LNM87/ovWf/SsP4d698Z1p+y/tSwfthywfKwxbPewHqDxXPV3qZO0Ua6ahu1+71qb1vevYtn rOuq/UazylVzvKXOa3b7FRvUtlgHNc8VG9TG6IOa54q9bYnWR7In6vvEvkjsk1wTz3i1Bvkd YlDzXK23LY13sfm5rtar8podV0suluFq3XmtBvn5blDzXKtF1guWRVbPe/3vrP/dsH6H9TuG 9UesPzKsx+gXLGN0z7qadbXuuVbbqeOHPf3vvlY11vu9Vtv1d+/iGee6Vuvl+AtSp02PHbpa /vLqjVfsE+sW6ydWzxX7xDpG/8TquWLb9Wh9pGMk6j+V3CLXMdxfY87rZjxGNU7PdduuN97F GeC6bgVWH9d1c1idf6nk+Tob/pX2ifUW9odt7mcmnUe5ZvuZ420cNoGd99osm8lkHZrARv/d r8oK24B8t0p2/z1BlvPvJRzfVR2VL9m7Pye61Rbn/Iu65Aj524PRI5zR47ZzqvuMYmO++ox+ YPuj+o+ekfNvFX5u85a/rwhPTo4YLT81DD+nMa5zOqxZ3F9Dhqsw0hm9pf2jZzTGdUYX5Dic ketdGnXXd+oh11ltlK8k1x1yx90x0rlttX7dd6vN6ny30uXdmjh0XsN/qnzRIj9VLrXLX6a4 fzOpMleZh/9mMah77zH+ZuFYe36zGGX4zeTu+R/o3knGvGPtyT/gemfTrXNUxzv7xLRp06a6 vjY979KoO7r/19Lq7o6+n+4xuqOb5tvcQ38z/uWXQ19/zvfsU5Pi+qi6PppdH71G+Ktsd7/N 9dHiel/GylEU5V1JmFT10dQ1q0vyf6yU/00vOKIrtSbHe+H46K6dPvdxra6Puuujt+ujj+vj KNfHB+TvSBXl/wGskByEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQBUAGEA YgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA4AAgABAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAWAAAADQwAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAKAAAA/////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAABUAgAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAGwCAAAAAAAA AQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABHAAAAagAAAAAAAAAeAAAAEAAAAE1hYXJ0ZW4gVmlzc2VycwAeAAAAAQAAAABh YXIeAAAAAQAAAABhYXIeAAAACwAAAE5vcm1hbC5kb3QAcx4AAAAQAAAATWFhcnRlbiBWaXNz ZXJzAB4AAAACAAAAOABhch4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAGZAAAAAAPRKqQgA AABAAAAAANLabW6WwAFAAAAAAN6PxGWWwAFAAAAAAHZuRG+WwAEDAAAAAQAAAAMAAAB8AQAA AwAAAHcIAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAA BdXN1ZwuGxCTlwgAKyz5rtQBAACQAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYA AACUAAAAEQAAAJwAAAAXAAAApAAAAAsAAACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAA DQAAAMwAAAAMAAAAcQEAAAIAAADkBAAAHgAAABQAAABMdWNlbnQgVGVjaG5vbG9naWVzAAMA AAASAAAAAwAAAAQAAAADAAAAZQoAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAAQAAAJkAAABGaWd1cmUgMSBkZXBpY3RzIGEgZnJhZ21lbnQgb2YgYW4g U0RIIGVxdWlwbWVudCB3aXRoIGEgR2JFICh0cmlidXRhcnkpIHBvcnQgdW5pdCAoNHggMUdi RSBpbnRlcmZhY2VzKSwgYSBIaWdoZXIgT3JkZXIgRmFicmljIHVuaXQgYW5kIDQgU1RNLU4g cG9ydCB1bml0cwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAmAAAAAMAAAAAAAAA IAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAA TgAAAHsAMQA3ADIARgA2AEQARQBEAC0AMAAyADUAOQAtADEAMQBEADUALQBBADYAMQAzAC0A MAAwADAAMAAzADkANQBBADgAOAAxADMAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIA EQAKAAEAWwAPAAIAAAAAAAAAJAAAQPH/AgAkAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAEAG1I CQgAAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEA cgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAALAAfQAEA8gAsAAAABgBIAGUA YQBkAGUAcgAAAA0ADwANxggAAjkQciABAgAAACwAIEABAAIBLAAAAAYARgBvAG8AdABlAHIA AAANABAADcYIAAI5EHIgAQIAAAAAAAAASgoAAAwAABgAAA0A/////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAIAAAAEAAAABAAAAAQAAAAHAAAAAAQAAEoOAAAJAAAA AAQAAEoOAAAKAAAAAAQAAEoOAAALAAAA/gkAABoKAAAcCgAASgoAABM6lP+VjAAAAADKAAAA 0gAAAGEBAABpAQAA1QEAANgBAADkAQAA5gEAAEkCAABSAgAAZwIAAHcCAACTAgAAlgIAANYC AADZAgAA2wIAAN0CAADmAgAA6AIAAOkCAADrAgAA7AIAAO4CAAAJAwAAEgMAADUEAAA3BAAA bwQAAHQEAAANBQAAEQUAAFcFAABgBQAArAYAALEGAADTBgAA2AYAAOsGAADxBgAAcQcAAHcH AABECgAASAoAAEsKAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAAgAAAAAA xAAAAMUAAADfAQAA4gEAAEIDAABGAwAAJwQAACsEAAAcCAAAUggAAEQKAABICgAASwoAAAcA GgAHABoABwAaAAcAGgAHABoABwAHAAIA//8UAAAADwBNAGEAYQByAHQAZQBuACAAVgBpAHMA cwBlAHIAcwApAEMAOgBcAG0AYQBhAHIAdABlAG4AXABUAE8AUABJAEMAUwBcAHMAZABoAFwA cwBkAGgALQBjAG8AbgBjAGEAdABcAGwAYwBhAHMALgBkAG8AYwAPAE0AYQBhAHIAdABlAG4A IABWAGkAcwBzAGUAcgBzACUAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUA cgB5ACAAcwBhAHYAZQAgAG8AZgAgAGwAYwBhAHMALgBhAHMAZAAPAE0AYQBhAHIAdABlAG4A IABWAGkAcwBzAGUAcgBzACkAQwA6AFwAbQBhAGEAcgB0AGUAbgBcAFQATwBQAEkAQwBTAFwA cwBkAGgAXABzAGQAaAAtAGMAbwBuAGMAYQB0AFwAbABjAGEAcwAuAGQAbwBjAA8ATQBhAGEA cgB0AGUAbgAgAFYAaQBzAHMAZQByAHMAJQBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUA YwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAbABjAGEAcwAuAGEAcwBkAA8ATQBhAGEA cgB0AGUAbgAgAFYAaQBzAHMAZQByAHMAKQBDADoAXABtAGEAYQByAHQAZQBuAFwAVABPAFAA SQBDAFMAXABzAGQAaABcAHMAZABoAC0AYwBvAG4AYwBhAHQAXABsAGMAYQBzAC4AZABvAGMA DwBNAGEAYQByAHQAZQBuACAAVgBpAHMAcwBlAHIAcwApAEMAOgBcAG0AYQBhAHIAdABlAG4A XABUAE8AUABJAEMAUwBcAHMAZABoAFwAcwBkAGgALQBjAG8AbgBjAGEAdABcAGwAYwBhAHMA LgBkAG8AYwAPAE0AYQBhAHIAdABlAG4AIABWAGkAcwBzAGUAcgBzACkAQwA6AFwAbQBhAGEA cgB0AGUAbgBcAFQATwBQAEkAQwBTAFwAcwBkAGgAXABzAGQAaAAtAGMAbwBuAGMAYQB0AFwA bABjAGEAcwAuAGQAbwBjAA8ATQBhAGEAcgB0AGUAbgAgAFYAaQBzAHMAZQByAHMAKQBDADoA XABtAGEAYQByAHQAZQBuAFwAVABPAFAASQBDAFMAXABzAGQAaABcAHMAZABoAC0AYwBvAG4A YwBhAHQAXABsAGMAYQBzAC4AZABvAGMADwBNAGEAYQByAHQAZQBuACAAVgBpAHMAcwBlAHIA cwApAEMAOgBcAG0AYQBhAHIAdABlAG4AXABUAE8AUABJAEMAUwBcAHMAZABoAFwAcwBkAGgA LQBjAG8AbgBjAGEAdABcAGwAYwBhAHMALgBkAG8AYwAPAE0AYQBhAHIAdABlAG4AIABWAGkA cwBzAGUAcgBzACkAQwA6AFwAbQBhAGEAcgB0AGUAbgBcAFQATwBQAEkAQwBTAFwAcwBkAGgA XABzAGQAaAAtAGMAbwBuAGMAYQB0AFwAbABjAGEAcwAuAGQAbwBjAP9AAYABAJgDAACYAwAA IHb9AE4BTgGYAwAAAAAAAJgDAAAAAAAAAhAAAAAAAAAASgoAAMAAAAgAQAAABAAAAEcWkAEA AAICBgMFBAUCAwSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAg AFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABT AHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABB AHIAaQBhAGwAAAA7BpABAgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBp AG4AZwBkAGkAbgBnAHMAAAAiAAQAcQiJGAAA0AIAAGgBAAAAAIlyUmbRclJmy3JSZggAPgAA AHwBAAB3CAAAAQAEAAAABAADEBIAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAJAMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACAADIwAAAA AAAAAAAAAAAAAABlCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAACYAEYAaQBnAHUAcgBl ACAAMQAgAGQAZQBwAGkAYwB0AHMAIABhACAAZgByAGEAZwBtAGUAbgB0ACAAbwBmACAAYQBu ACAAUwBEAEgAIABlAHEAdQBpAHAAbQBlAG4AdAAgAHcAaQB0AGgAIABhACAARwBiAEUAIAAo AHQAcgBpAGIAdQB0AGEAcgB5ACkAIABwAG8AcgB0ACAAdQBuAGkAdAAgACgANAB4ACAAMQBH AGIARQAgAGkAbgB0AGUAcgBmAGEAYwBlAHMAKQAsACAAYQAgAEgAaQBnAGgAZQByACAATwBy AGQAZQByACAARgBhAGIAcgBpAGMAIAB1AG4AaQB0ACAAYQBuAGQAIAA0ACAAUwBUAE0ALQBO ACAAcABvAHIAdAAgAHUAbgBpAHQAcwAAAAAAAAAPAE0AYQBhAHIAdABlAG4AIABWAGkAcwBz AGUAcgBzAA8ATQBhAGEAcgB0AGUAbgAgAFYAaQBzAHMAZQByAHMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3Vt ZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------FF19E49E4044A2D3C7D5BCAE Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------FF19E49E4044A2D3C7D5BCAE-- From owner-mpls@UU.NET Wed Feb 14 07:02:13 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26468 for ; Wed, 14 Feb 2001 07:02: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 QQkcih05592; Wed, 14 Feb 2001 11:58:20 GMT Received: by mail-control.mail.uu.net id QQkcih21784 for mpls-outgoing; Wed, 14 Feb 2001 11:58: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 QQkcih21777 for ; Wed, 14 Feb 2001 11:57: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 QQkcih28398 for ; Wed, 14 Feb 2001 11:57:36 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcih21970 for ; Wed, 14 Feb 2001 11:57:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA25412 for mpls@uu.net; Wed, 14 Feb 2001 06:57:35 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcih21763 for ; Wed, 14 Feb 2001 11:57:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcih13005 for ; Wed, 14 Feb 2001 11:56:00 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 QQkcih22572 for ; Wed, 14 Feb 2001 11:56:00 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 DAA18137; Wed, 14 Feb 2001 03:56:13 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id GAA09379; Wed, 14 Feb 2001 06:55:58 -0500 (EST) Message-Id: <200102141155.GAA09379@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: Yakov Rekhter cc: mpls@UU.NET Subject: Re: PID in LDP In-reply-to: Your message of "Tue, 13 Feb 2001 11:01:07 PST." <200102131901.LAA48228@garnet.juniper.net> Date: Wed, 14 Feb 2001 06:55:58 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Yakov, > Right now we have a situation where RSVP, CR-LDP) have a mechanism (PID) > to identify an LSP payload, while LDP doesn't have such a mechanism. > > Would there be any objections to add a new TLV to LDP that would > carry the PID information ? Would you give an example of how this TLV would be used? To evaluate the suggestion that a PID TLV be added it would be helpful to see how the information carried by the FEC TLV is insufficient. (Please note I am asking this question in the context of LDP not CR-LDP.) Thanks, Bob From owner-mpls@UU.NET Wed Feb 14 07:39:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26768 for ; Wed, 14 Feb 2001 07:39: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 QQkcik22293; Wed, 14 Feb 2001 12:36:13 GMT Received: by mail-control.mail.uu.net id QQkcik07811 for mpls-outgoing; Wed, 14 Feb 2001 12:35: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 QQkcik07806 for ; Wed, 14 Feb 2001 12:35: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 QQkcik19801 for ; Wed, 14 Feb 2001 12:35:29 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcik20357 for ; Wed, 14 Feb 2001 12:35:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA27987 for mpls@uu.net; Wed, 14 Feb 2001 07:35:27 -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 QQkcik07784 for ; Wed, 14 Feb 2001 12:34: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 QQkcik16611 for ; Wed, 14 Feb 2001 12:34:31 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkcik17408 for ; Wed, 14 Feb 2001 12:34:14 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 HAA10439 for ; Wed, 14 Feb 2001 07:34:12 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA10374 for ; Wed, 14 Feb 2001 07:34:10 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA19752; Wed, 14 Feb 2001 13:34:08 +0100 (MET) Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" , "Ben Mack-Crane (E-mail)" , "Greg Bernstein (E-mail)" , "Bala Rajagopalan (E-mail)" , "Debanjan Saha (E-mail)" , "Michael Raftelis (E-mail)" , "Shash Chatterjee (E-mail)" , "Jeff Connell (E-mail)" , "Eric Mannie (E-mail)" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA19716; Wed, 14 Feb 2001 13:34:04 +0100 (MET) Message-ID: <3A8A7B3B.D5451D7E@lucent.com> Date: Wed, 14 Feb 2001 13:34:03 +0100 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vishal Sharma Original-CC: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" , "Ben Mack-Crane (E-mail)" , "Greg Bernstein (E-mail)" , "Bala Rajagopalan (E-mail)" , "Debanjan Saha (E-mail)" , "Michael Raftelis (E-mail)" , "Shash Chatterjee (E-mail)" , "Jeff Connell (E-mail)" , "Eric Mannie (E-mail)" Subject: Re: FW: [IP-Optical] GMPLS enhancements References: Content-Type: multipart/mixed; boundary="------------3485E32978AC83038A130ECC" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------3485E32978AC83038A130ECC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vishal, Attached a short document further illustrating the need for two separate SDH labels: one for HOVC/STS signals and the second one for LOVC/VT signals. Regards, Maarten --------------3485E32978AC83038A130ECC Content-Type: application/msword; name="gmls-sdhlabels.doc" Content-Disposition: inline; filename="gmls-sdhlabels.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAFgAAAAAA AAAAEAAAGAAAAAEAAAD+////AAAAABUAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcQAJCAAACBK/AAAAAAAAEAAAAAAABAAA gwsAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAAAAAJBBYAKhgAABZBAQAWQQEAMwcAAAAA AABPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAABYBAAAAAAAAFgEAABYBAAAAAAAAFgEAAAAAAAAWAQAA AAAAABYBAAAAAAAAFgEAABQAAAAAAAAAAAAAACoBAAAAAAAAKgEAAAAAAAAqAQAAAAAAACoB AAA4AAAAYgEAAAwAAABuAQAAFAAAACoBAAAAAAAA3QMAALYAAACOAQAAFgAAAKQBAAAWAAAA ugEAAAAAAAC6AQAAAAAAALoBAAAAAAAAugEAAAAAAAC6AQAAAAAAALoBAAAAAAAAogMAAAIA AACkAwAAAAAAAKQDAAAAAAAApAMAAAAAAACkAwAAAAAAAKQDAAAAAAAApAMAACQAAACTBAAA 9AEAAIcGAABCAQAAyAMAABUAAAAAAAAAAAAAAAAAAAAAAAAAFgEAAAAAAAC6AQAAAAAAAAAA AAAAAAAAAAAAAAAAAAC6AQAAAAAAALoBAAAAAAAAugEAAAAAAAC6AQAAAAAAAMgDAAAAAAAA RgIAAAAAAAAWAQAAAAAAABYBAAAAAAAAugEAAAAAAAAAAAAAAAAAALoBAAAAAAAAjgEAAAAA AABGAgAAAAAAAEYCAAAAAAAARgIAAAAAAAC6AQAAUgAAABYBAAAAAAAAugEAAAAAAAAWAQAA AAAAALoBAAAAAAAAogMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgEAAAAAAAAqAQAAAAAAABYB AAAAAAAAFgEAAAAAAAAWAQAAAAAAABYBAAAAAAAAugEAAAAAAACiAwAAAAAAAEYCAABcAQAA RgIAAAAAAAAAAAAAAAAAAKIDAAAAAAAAFgEAAAAAAAAWAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAogMAAAAAAAC6AQAA AAAAAIIBAAAMAAAA0DfaPoGWwAEqAQAAAAAAACoBAAAAAAAADAIAADoAAACiAwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARmlndXJlIDEgZGVwaWN0cyBhIGZyYWdtZW50IG9m IGEgaHlicmlkIFNESC9BVE0gZXF1aXBtZW50IHRvIGlsbHVzdHJhdGUgdGhhdCBTREggaGFz IG11bHRpcGxlIGxldmVscyBvZiBsYWJlbHMuIFRoZSBlcXVpcG1lbnQgaW5jbHVkZXMgYSBT REggSE8gRmFicmljLCBhIFNESCBMTyBGYWJyaWMgYW5kIGFuIEFUTSBWUCBGYWJyaWMuDQ1U aGUgU0RIIEhPVkMvU1RTIGNvbm5lY3Rpb24gcG9pbnRzIGFuZCBsaW5rIGNvbm5lY3Rpb25z IGNhbiBiZSBpZGVudGlmaWVkIGJ5IHRoZSBTVE0tTiBwaHlzaWNhbCBwb3J0IG51bWJlciBl eHRlbmRlZCB3aXRoIHRoZSBBVShHKSBudW1iZXIgKEVEQ0JBIGZvcm1hdCkuDQ1UaGUgU0RI IExPVkMvVlQgY29ubmVjdGlvbiBwb2ludHMgYW5kIGxpbmsgY29ubmVjdGlvbiBjYW4gYmUg aWRlbnRpZmllZCBieSB0aGUgSE9WQy9TVFMgKGUuZy4gVkM0KSBUZXJtaW5hdGlvbiBQb2lu dCAoVFApIG51bWJlciBleHRlbmRlZCB3aXRoIHRoZSBUVShHKSBudW1iZXIgKEtMTSBmb3Jt YXQpLg0NVGhlIEFUTSBWUCBjb25uZWN0aW9uIHBvaW50cyBhbmQgbGluayBjb25uZWN0aW9u IGNhbiBiZSBpZGVudGlmaWVkIGJ5IHRoZSBIT1ZDL1NUUyAoZS5nLiBWQzQpIFRQIG51bWJl ciBleHRlbmRlZCB3aXRoIHRoZSBWUEkgbnVtYmVyLg0NEyBFTUJFRCBEZXNpZ25lci5EcmF3 aW5nLjggIBQBFQ1GaWd1cmUgMSAtIGZyYWdtZW50IG9mIGh5YnJpZCBTREgvQVRNIGVxdWlw bWVudA0NV2l0aCB0aGUgZXN0YWJsaXNoZWQgY29ubmVjdGlvbnMgaW4gdGhlIGZhYnJpY3Ms IFZDMTIgVFAgVDEyMSBpcyBjb25uZWN0ZWQgdmlhIFRVMTIgMjI0IGluIFZDNCBUNDEgdmlh IEFVNCAwMDIyMSBpbiBTVE0tMTYgcG9ydCBJLiBXaXRoIHRoaXMgY29ubmVjdGl2aXR5LCB0 aGUgVkMxMiBUUCBUMTIxIGNvdWxkIGJlIGFkZHJlc3NlZCBhcyBwb3J0PUksIEVEQkNBPTAw MjIxLCBLTE09MjI0Lg0NTG9va2luZyBhdCBWQzEyIFRQIFQxMjIsIHRoZSBhZGRyZXNzIGlz IGxlc3Mgb2J2aW91c2x5IGRlcml2ZWQgYW5kIGlzIG5vdCB1bmlxdWUgZHVlIHRvIHRoZSAx KzEgVkM0IFNOQyBwcm90ZWN0aW9uIHRoYXQgaXMgYXBwbGllZC4gVDEyMiBoYXMgdHdvIGFk ZHJlc3NlczogcG9ydD1JLCBFRENCQT0wMDMyMSwgS0xNPTIyNiBhbmQgcG9ydD1JSUksIEVE Q0JBPTAwMDQxLCBLTE09MjI2Lg1UaGlzIGlzIHNpbWlsYXIgdG8gdGhlIGFkZHJlc3Mgb2Yg YSBWUCBjb25uZWN0aW9uIHBvaW50IGNvbm5lY3RlZCB0byBWQzQgVFAgVDRhKzE7IGUuZy4g VlBJPTM0NSBjYW4gYmUgcmVhY2hlZCB2aWEgcG9ydD1JSSwgRURDQkE9MDIzMjEgYXMgd2Vs bCBhcyB2aWEgcG9ydD1WLCBFRENCQT0yMjIyMS4NDUFUTSBWUCBjb25uZWN0aW9ucyBvdmVy IFNESCBIT1ZDL1NUUyBjb25uZWN0aW9ucyBhcmUgYWRkcmVzc2VkIHZpYSB0d28gbGFiZWxz OiBTREggKEhPKSBsYWJlbCBhbmQgQVRNIFZQIGxhYmVsLiBBcyBjYW4gYmUgc2VlbiBmcm9t IEZpZ3VyZSAxLCBTREggTE9WQy9WVCBjb25uZWN0aW9ucyBhcmUgYXQgdGhlIHNhbWUgbGV2 ZWwgYXMgQVRNIFZQIGNvbm5lY3Rpb25zLiBJdCBpcyBsb2dpY2FsIHRvIHVzZSB0aGVyZWZv cmUgYSBzaW1pbGFyIGxhYmVsIHN0cnVjdHVyZS4NDVNESCBzaG91bGQgdGhlcmVmb3JlIGhh dmUgdHdvIHNlcGFyYXRlIGxhYmVsczsgb25lIHRvIGFkZHJlc3MgSE9WQy9TVFMgY29ubmVj dGlvbiBwb2ludHMgYW5kIGxpbmsgY29ubmVjdGlvbnMgKEVEQ0JBIGZvcm1hdCksIGFuZCBh bm90aGVyIG9uZSB0byBhZGRyZXNzIExPVkMvVlQgY29ubmVjdGlvbiBwb2ludHMgYW5kIGxp bmsgY29ubmVjdGlvbnMgKEtMTSBmb3JtYXQpLg0NDVNESC9TT05FVCBsYWJlbHMJEyBQQUdF IBQxFQkyMDAxLTAyLTE0DQ1MdWNlbnQgVGVjaG5vbG9naWVzCQlNYWFydGVuIFZpc3NlcnMN DQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAJEGAACSBgAArQYAAK4GAACwBgAARAsAAEULAABLCwAA TAsAAE0LAABOCwAAgwsAAAD6APD6AOnm6eHpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACDBKEQBtSAAEAAQwShEAAA0D agAAAAAwShEAVQgBEwNqePU0PgoIAVUIAVYIAW1IAAQJA2oAAAAAVQgBAAwABAAAvgQAAL8E AABaBQAAWwUAAAkGAAAKBgAAkAYAAJEGAACxBgAA4QYAAOIGAADCBwAAwwcAAKAIAABMCQAA TQkAAFoKAABbCgAAMQsAADILAAAzCwAAWgsAAFsLAACACwAAgQsAAIILAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADvAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAChAADcYPAjkQciADAADUEqclAAECAAoPAA3GDwI5EHIgAwAA1BKn JQABAgMAAAMkAQABAAAAGgAEAAC+BAAAvwQAAFoFAABbBQAACQYAAAoGAACQBgAAkQYAALEG AADhBgAA4gYAAMIHAADDBwAAoAgAAEwJAABNCQAAWgoAAFsKAAAxCwAAMgsAADMLAAA2CwAA PAsAAEMLAABECwAARQsAAEYLAABKCwAASwsAAEwLAABNCwAATgsAAE8LAABZCwAAWgsAAFsL AACACwAAgQsAAIILAACDCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v7+/v7+/v7+/v7+/v7+ +/7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAhAADQECAQEoggsAAIMLAAD9AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAAEoACZQCQAfsIIuILDGQSGwbgQisG4EI5CKBSSQbgQlsAAAF7CoAhiw NwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYdAABEAGQAAAAAAAAA AgAAAAAAAAAAAAAAAACkM1soxgLGAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwAE8DwAAACyBArwCAAAAAEEAAAACgAAQwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/AQAA CAAAABDwBAAAAAAAAIAyAAfw9hwAAAME1V0s+QTYhjTGX2EGkFssz/8A0hwAAAEAAABEAAAA AAACAWAhG/DKHAAA1V0s+QTYhjTGX2EGkFssz/w/AAAAAAAAAAAAAAEAAAABAAAAWBiAALAY ZACYHAAAAP54nJ2bCXwURfbHu7uqpjshCVGOgCBEQQMLKkk4FHVREZVT5EhIgAhiCEEBCYT7 GCCJrhoIeOyqy/XfFeUI3rpcKiB44YEXoBxR0RVBAUVERf1/q2Y6MyZEccPnS79X9d6val7N dPdUOrYVY1nil6aWVd/qYemfs+H8QG3rIqvntQO6dkweVpA7dHzuzck3TU7umT+sYExewdDh k1ondx097MLknnmT8gpykyekXtimjWVJMoXtWYpjLUdraSvOsS07bI3wNsVqK2DrbhdOYmza pGN19gW2ZXkcf3QUOaGfULttXcGxuWhiefYC27Pn265dBvPsACh7ri3AwbYNZQw6H1zn79ZK 535rFcSLv1sJUFv8Ax6wEsVD8E/shYYEsYiYRVYcrHZcO9bx7BjwHD2mP9tfXwxWzsqxrjGz OsfKURUiR+0Tg9Ve2CMGwUC1W2TBAOxMw16RQUyGypSZagBkyQHwRWCQ+iKwVh0IrIP16ks4 GNigvoKvsQ8b1qkjxBwJrIFsGEBbJv2ZKkf1k3p8f4bB4K+VMxRWmplhkjVFxYkpKl5MVQlQ W0yD6SpRzIQg9ixDgphNzGz1qzNL/QI/O0GYqU4602Ea9lTDL84UYqYoS2jdyBhHaDtK/zfw LfHfkneM/GPofIue5htnNjGz1afYn8DH9H1MTAWxFeR8TK7mE7Q+hf2O1o2M8R7++/R/ADuI 30HeTvJ3orMDPc0H6L8PL2NvhS30bSHmJWJfImcLuZqtaL0Mrzhat7UZoy5j/Ad/Df1rYR3x 68hbT/56dNahp1mL/hpYib0CltO3nJhHiX+U/BVQ7mit5kY30ZqgFjoT1SJY7ExSS4hbgu5i Z4bhn/hljDcP5pJX6kyA8fjj1QJH555vdM6wxqrZzlhV5BTAOFVMXzF6cyCIPZ74AtoL6B9L 3FjnNuwxMFqNgwmOzr/QaNWzblF5zi1qhHOryndGwWg1ktiR5OQTl4/GCMjFz6J9AGQSk0ls hjMS8rHzaR9B/wg10NF65xrt2lau6u7kqh7OcNUTehHfi3F6QFfsv5J3OVxG3qXOzXAT/k2q k6PzWhiNM60bVRvnRpXqDFXpxKSjkwptnDx1EccLaTuXnGT6mxLX1MnBHmw4xxlE3yDV3NEa bY1eAytL1XWyVD0nW9WHJGcgDFINiG9AbhKxSc4Q+oYQM5TYIaoO7S4EiFHEKnKkMwAysTNp z6A/Q8U4WrubGacZZ4QFdo6abw9WZTDPHgQD1Vw7CwZgZxrK7AxiMtC5Wyx37hIrnDvhb2Il xIs7RQLUFnfB3SJRzIV52GWGBDGfmPkiDh5nTnHMrRZz1MQy3xjwHD2PynNXcFPlmUFWnlEv dRbYlzrz7Y5OGcyzL4GLnbl2e2iH3dZQZqcTk+7EOG2dWOcZZzXEi2edBKgtnoP/OIliLazD Xm9IEBuI2eDEQbmzwVnprIdLHdfRY1aer36NnK+UuQo1F82t6W6FmO7uE9PcvbBHTIUp7m4x CSZiTzDsFYXEFLp95SzOq0HOsTMNA9QMzr0zxFrsdbCevvVqltig5kARdrFhnSohpkSsgcFq ipstp7pZcpphgJzuZkKG1HOJzDZyVQpYV5vZJlsnnApxwtknvnf2wh5xHL5zdotv4Rvso4a9 4ggxR5x+8hHW/mHeCw/ba9Uyex2sV4/Ao/YGtQJWYq8yrFPlxJTba2CQOu5kye8NA+QJJxMy pB67coWjrpmudZmZXWOrg10hOtj7RHt7L+wR7aCtvVukQSp2G8NecRExF9n95Rd8Sr6wuCJZ XJEsrkhw0OKKBF9jHzZwRSLmiMUVyRqoOtiZsoOdIfVYodn89gruha/sVuVPqD3G3Ac0kqud 5gHPmWA1xvvJaXAyFFPmi1hXFuQPvZVjXTf23Iz7vpp4I7ydd3ii9i0rNqwWa+40HFunhZQ+ +LUmpVFu7MZoJe1HlGpZ9TimxbZyvnG4R7J6XJ98zdCbCvKHWUlWshVnNeSYZCVw/1Svcmw/ 8zyTOdCZ49TFapHR+YLU1NbJ+pBmDuktE5hdEysehQZWLdQa4SUYxTj8xmEvwdTsPOFY6VQ1 nepWrY5d5TVNCsQ+F/2atB95TXHValI1v58be2F0vvYj+fHMTr+yGNmNOwui26aaOjQIr+FA VRKbIXOq1SNUyeXyRakreV1lJZv8YSW7mMxdski01JXs269vqJBtQ/9f0HZY2Eht71vt2w5r KXV9G0LSb6r729omMZ7u9VciVP961aJ0W3zlShyystUh3vO+38jOVo3siN8dv3uUPwV/SpS/ HH95lN+Uq1BTZ40KVbBB4GLs92uo4HaVbOsKXtk/eVThpPzReWaetaxmZo4xZq4hnbnodAxU 1znT6PQMXGTOvj37prZP7teb/Ebh956umT+zEjspUGJ3DET8UvwnAqERpHux80SNI2wOpJoR +oRHaGLWQq/GWYwVURRuiZ3ihhSnoJjiVlesbxQvcWvRZll9+/VksZN7X5elV7gZK9PA6DY2 Y0SUJ6O80PX9LVR5ixOp+jH8Y1F+M5GtmomI3we/T5Q/G392lH8C/4SIrFqi5Pzs1LRqJ5zf rFpWzauWKDsGquv4q+aK0Kq1b1vzquWIpECOiKxajijFj6xaonyixhE2B2JFaNVCI5x61XKE cHNEZNUSZYpbXdFftf2Ov2po/sGq5YjJKEdWbaHMVgtlpOrb8LdF+SfxT0b5rVS2aqUifrbS /yL+23hvq8iqHcAuljWt2nZ5uqt2QHUMVNdJDK/aQRkwq6ZLGlqz365YB5UU6KAiK9ZBleJH VuwAdk3qmwNfG/U+Rr1J+IwXvVodlHA7qMhqHcCu6TVf4r5iXrNeLbNYUatVda06qMnoRtaq lG+lpYFIrdfjr4/yD+EfivIbuZw33YjfDb9blP8i/otuZK12YU8I1LRWGwOnu1a73I6B6jp1 wmv1klmFnn3T2rWvXK3QNTp6xVLcpECKG1mxFLcUP7Jiu7BrGmNz4GWT1yc8hv8ZC61b9BjC TXEj67YLu7pmg/C6LQ3UCq+bVmXlrOjPWfVPWoo7Gb2Frr+7Eholz9uoP6zVzsCh99oa9zI7 UHkGjtY/9aoccNuZq1XX0eNzC4YPHZabFWdmoq+q2qpLbtXM0P1FQ6/A3F+06NqS2Fpw6hmV u3WFP6P2bf94RnvcePFnZxRvMuO9LkKaGXVtmWDuGqrPqXZ4Tiek8j9DUatQ04w+l392RrXD M2qgVGhG4SrFnbJSZ4Zntd28O8PvkCrvjprm9kHgf62WckPVyjDVamwlRN3XF4kiUf3OM8mN XR1956n9yJ1nQtSd66nzl3uxraLztR/Jrx2uWinXC121Nm3acO+aVPnP/y7ifz4etMqdB604 4fuv4r8a5Z/APxHlp9jlTood8TPxM6P8N/DfwA99zm4Rn2HPrqHuzcVbelfW6ld5NmvIZzfO Opd61+UVRc5mH6NTegqd0KdjifjS0p+OjM762qA//1WvDen2SL5VlFbO8hjfJI/xjdL/tlD1 rv9XJ3TXn9Y2dNdfeZ3l2322E3m1d+LfGeWvwV8T5X+B/0WUnyTKnSQR8UvxS0WkWsuwO9dw d9VczHNOt1rLROkpdPxqrXR+v1rHnJFUJ1KtbFXBXWDN1RqrQtUaWqVaG2W5s1FGXu0R/CNR flPuJJuqiN8Lv1eUPwN/RpR/DP+YilQrLhAnltdwhW8ujsvTrVZcoPQUOn61zlC/X61sNZLq lFbuTIR+QiqJlbv6bSy9Q1HfelXMEK/Ay2Km2GoIii1iFszBLoJi+oqJKRGvwevY2wxF4g1i 3iB2GznbyH0dXkNLa/r6u7B3wg76PjAExfvkvE/uB2h8gNYO2In2h/AR9m5DkdhDzB5id5Oz m9yP4EO0dkXpH8D+Av5L3+eGoPiMnM/I/RyNz9H6L3yB9pdwEPuQoUh8RcxXxB4i5xC5B+FL tA5E6f+AfQK+p++4ISi+I+c7co+jcRyt7+EE2j/CT9gnDUXiZ2J+JvYkOSfJ/Ql+ROuHKP0Y OUN44MqZImAICiVnwRzsIiimr5iYEhELtbDjDEUinph4YuPIiSO3FsSipTV9/YbYDSCJvvqG oKhHTj1y66NRH60kaID2WdAIu7GhSJxNzNnENianMbmN4Cy0Gkbpt8RuASn0nW8IivPIOY/c 89E4H60UaIH2X6AVdmtDkbiAmAuIbU1Oa3JbwV/Qahmlfwn2xdCBvvaGoGhHTjty26PRHq0O cDHaHeFS7MsMReJyYi4n9jJyLiP3UuiI1iVR+l2xr4Nr6bvGEBRdyOlC7jVoXIPWtXAd2t2g O3YPQ5HoSUxPYnuQ04Pc7tANra5R+lnYAyCTvgxDUPQnpz+5GWhkoJUJA9DOhoHYgwxFYjAx g4kdRM4gcgdCNlpZUfr52CMgj77hhqDIJSeX3OFoDEcrD0agPRJuwb7VUCRGETOK2FvJuZXc W2AkWvlR+pOxJ8FE+iYYgqKQnEJyJ6AxAa2JMAntKTAVe5qhSEwnZjqx08iZRu5UmIKW1vT3 JqvuRZbEes76anfbjcy5r7NT19P3OVf265mc0dvfywrdUel7ncbmTOjvadWtPCNOdiv4flv9 elE7fL0odlXoetHK31XTd2d+dgXf2isCkbN+bb5z13Yj/l/x/xrlj8YfHeUvxF8Y5dfxyp06 XuSq0Rr7lRq+XzUX9Vx91eDVVn6/asRVo5m5C/ztVaO1V3oKHf+q0cb9/avGZHckNYpcY9+L qRDvxdR8jT0YE7rGjm7122tsx5hyp2NM5NXm4+dH+Q/gPxDlv4L/SpT/Pf73Uf6o2HJnVGyk WiXYzWJqqtaYmNOtVkls6Sl0/GrdFfP71XovZiTVKRU1XVWv8maIK+EKb6boZAiKv3qzYA52 ERTTV0xMiegMV2N3MXDGIeYaYruQ04Xcq6EzWlrT1++DfQP0pu96Q1D0IqcXudejcT1aveEG tPtCP+z+Bs44xGQQ25+c/uT2g75o9YnSvwl7KAyh70ZDUOSQk0PujWjciNYQGIr2MLgZO9fA GYeY4cTmkpNL7s0wDK2bovQLsMfCbfSNMQTFaHJGkzsGjTFo3QZj0R4H47ELDZxxiJlAbCE5 heSOh3FoFUTpz8aeBUH6ZhqCYgY5M8idicZMtIIwC+0BAAAAAgAAAAMAAAAEAAAABQAAAAYA AAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAD+////DgAAAA8AAAAQAAAAEQAAABIAAAATAAAA FAAAADoAAAD9////FwAAAEEAAAD+////QgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEA AAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAD+////OwAAADwA AAA9AAAAPgAAAD8AAABAAAAA/v////7///9DAAAARAAAAEUAAABGAAAARwAAAP7///////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAWAAUB//////////8JAAAABgkCAAAAAADAAAAAAAAARgAAAABg8mHG epbAAYAa6D6BlsABGQAAAMANAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAAhh0AAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQgAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAqGAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEBCwAAAP////8EAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACQKtc+gZbAAYAa6D6BlsABAAAAAAAAAAAAAAAAXwAxADAANAAzADYANQA4ADEAMAA0AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAQH//////////wYA AADG34m54VnSEYaLAMBPsXnyAAAAAJAq1z6BlsABMLHYPoGWwAEAAAAAAAAAAAAAAAABAE8A bABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAUAAAAAAAAAAMATwBiAGoASQBuAGYAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBBQAAAAcAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAQAAAAAAAAARABlAHMAaQBnAG4AZQByAEQA bwBjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAAjj4AAAAA AAD+/////v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA/v///wwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAAP7///8WAAAAFwAAABgAAAAZAAAAGgAAABsA AAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA/v///zYA AAD+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////wEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQA AgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA5AEAABEAAAABAAAA kAAAAAIAAACYAAAAAwAAABABAAAEAAAAHAEAAAUAAAA0AQAABgAAAEABAAAHAAAATAEAAAgA AABgAQAACQAAAHgBAAASAAAAhAEAAAoAAACgAQAADAAAAKwBAAANAAAAuAEAAA4AAADEAQAA DwAAAMwBAAAQAAAA1AEAABMAAADcAQAAAgAAAOQEAAAeAAAAbwAAAEZpZ3VyZSAxIGRlcGlj dHMgYSBmcmFnbWVudCBvZiBhIGh5YnJpZCBTREgvQVRNIGVxdWlwbWVudCB0byBpbGx1c3Ry YXRlIHRoYXQgU0RIIGhhcyBtdWx0aXBsZSBsZXZlbHMgb2YgbGFiZWxzAAAeAAAAAQAAAABp Z3UeAAAAEAAAAE1hYXJ0ZW4gVmlzc2VycwAeAAAAAQAAAABhYXIeAAAAAQAAAABhYXIeAAAA REVTSUdORVJET0MAAAgAAniczV0JXBXV9z8zIA9FE00NFfWpoLikiBuGy3O3tMLU3A1cMTEp Nak033vz3MqF+luZS+L2S9OSdjPTV1FZWWJZ4o4LuFaUZrbyv+feWR8zzHuAn2H6vK5zhznn zJ37PfecM/ee25SrtAgi+i9YCMGjq/ALHgWO/BcU7AVyuEO4ShCzPAgKP+dBOqTzEPLvoiIw PDhbKCVyznm5Mofn3lg8dSyJ+JheTzvihUpT2gHMEAAGDwdoF4R/BkEQDPiPT3j243n45BMo qDI5CK9OJP+xQ/lX+xByRxhKWCkYz4Md6SGQcZbwImUmYR4xLAQSHazMeIgQrxpkJNC+TznY 14+DwQN5+DjfSKAir7OgmolAtwUrAqVdsEHeFg6wLDzAgSM1FPKa8LS09yI0q1cqSaD5rwF0 +Y7TtBCnEcjpLCoINxGoBr6xSvg3QTHXbLQhsMSGQbmwoaCmzfBNteLom3J9zpXwplCO203k qBWqbRh8U5IAEfczgbCkb6p2ZSOBGu1mXefohZK6TpHzk4I6JgLdUUURKOck6zpYokD7Q5lA WFKBIsKMBJrfnHWddk+W1HWcRUUFdU0EqldVEci+JpR2HSyx68QOtNGugyXtOvWrGQnU41mg AiX/DSUKBAWRJgI1uE0RKDGS9WUsUaDCN0KoQFhSgRpWN+zLg5hAv06WBWqv88oAJjcqWSCi mILs4YpMeYtCqExYokxpaUwmLKlMjWtQmbrUeStjQeuJ+T0m0+NGD/jo0r0zPlnvpZTr/eSF auHNAfK2Ayy28bQjANN8hCPXpCYSwbPEfgDhjTkIrx0E9gEcNL0d/1B85K/OUnLed48TclsP A7z+PkDfURxk/0hujwJKsxLPU0oeUpXBsSfbT95kpZ6PTU1OJdyioRnW7WghQGxc7wcLu1wN g5Ud56QnEVWwaHXCOxEA7ywFOEDoZZ2bnD0mmIOsOWsTDk/k4NLDHFxvysG6PzjwEun+Iuee Zhy8VMjBmr4ckCdsQp6jCpgfdrlc246V8RNYeXglK9M+Z2XVm6zc2oKjZZ/RrMxbysq5e4m6 0eHQwi62KTuKiorm4y/rdQ5WdaDjBl84VYCWVsncSo+F6dtjQre2Sug7SyU0uHb/fOzYz0RJ cLBYfCl2DYkgVjunI8qUlJ6welEXgEarAJa+AxB1wI/nVB+yTWF7zOuVazkqA084DVL+AoJ8 7kU5qoRdbZdLShwiGoZdjWstXz20yENLom/gfvEpCGQhmfzGk99j5DeV/CaAg/6dMLVQxVXL i1f9W+Qai3fVYlxjV6q4LqB/g938QfLrTX74JtqJv9aiJL7X4gyutSe/Fj4SEvrtFtOaCVfj JcZhV7sUtkF5OK+dViz+nqiejElAlROWsTM46UkK2poo+9ja5F/BeJfjRXZ34kdkVKsDsooD x3omlWOFA6qNnA7wwjAOikib3yDqh4tjzSb3N86gv7WHDliXunwGNSaDY5iKy3qANMfe1QmZ 5Fn21ge4Tp5swKuTslPacDAgYU1ChIuDWUSq0Ps5iHMB/DOBgyXk/PXBHLSdB3BbMgcdrUJe Jx0One26Km7Ao2SQGM5UXNo2D8RbJXMXPRambw9cEIi2eCArYfVe0svtmcRk2Uvgc92P51Qf Km3xQ55cq68tfA8Rt/aJwDQJwa19l3xV0hZDyQ97ZDsRc55taRLmGu+gNRrMxQTfdQdQq+JN NCoaX+ux+mU8OEfSk9+vOZXylZcKdKCQYNHRiGEw80liMHzGqa2KhJ9JZ+gaAQq6YlZQ/o6Q owRd+8iLW/cMB4924eGdbeRldGONYarNu0MPrJMMiFlRigHRqhczIHLqcLoGxPFoZkBs78pT A+JYNDMglnbkqQHhsKqn9tTh0MvulwHR2yqZ++ix8NOA6GuV0P1KJTS4bwvUgOjVihoQXJ2c shkQVxxybUAGxG1rQTYgmjrlq5JKGAC3xIC4Dem2IL/2YVer7lBxVQyIIcAUEpZGxkOHEuql coLJ3yDtTn78XScVPR2jpGEKrdEoyKhZ/euCj1Fivw+oAsQy6bxilAwwMUrurgfoDJO7HLfz 9G5nHA/31Pel7x3L6GOppj/QhP6gSKSPdyF9LJH+vQ186SdNZ/SxVNO/z4T+/Q2RPt6F9LFE +omNfOnDPEYfSzX9wSb0H0AawXgX0scS6Q9p7Es/cymjj6Wa/lAT+sOaIH28C+ljifQfbOpL P+ttRh9LNf3hJvRHoF8cjHchfSyR/shoX/roeSNd54cAmUG8eiAdhQ4zVS/4R3g7/pF3MA+j iccrj67Q3ov/dxYgueEPAUy6ysGTGwHW/k1G1zF4zY/RdSyMA9XhaaLYro9sZbbrXf2Z7Xrx vUnZ+yN4uHjPmoT0aaTRCM8UMppn/A9gzH08PEzOixJ4WEZk6DSQh4esUvpJOhyS7bqj60Un sMAKGV297TyoE62ReYIeCz883YhAbdetjzDbtf9dZbNd/8iUawOxXY9UIgOkOFAd4XLlq4cW LaclWkbDxKcgygVmk186sEGKSA5TJJu2nVdS2TUZADUqu4lnIg4+xSA3ojpDU1ZLDeQmtQAV 5NLHsj/KSedhcktQQa6DF//vmHSYkGtC2E6tTbC9jiA4ijz9FNZCpi8thT6MfOxpnCtDbvzr DHJfJyiQ8/ZmkEt7kYwThGfSRB5qk8Yf+gQPncj5f5N5mE5k6Pg4gaBV3XeaDodUuyHkIqYz yGW9KuBbtkbmR/RY+AG58EAh9/p4BrmEr8sGuTl5cm0gkMttjPYQfhBpGJbbyStflSB3LyjW WSfxadBiS5Sso1ezJKhxEbRGDbXcxntmYGxRAzV8xziqYYmQk0bPNJPR81GUNBjvwuEOS8Ti Y3fq0UcIY5nSSaE/04T+rDYSfcQ2los9PMxuq6b/qagqkK408KpUxeNHSCeeg/rARys4e31G 7rxB+D1B3M0sYo9nkUGQQ+Xlj1Z4Ap5Uv7pZdRStEPUG0wqosvW0QtVJTCsMWc+0QpVJTCtk r2Va4SmrEDZXh8M8u19a4WmrZJ6vx+JWaIU3ophWQPOqDFphpitLrg1IK4ShiShqBYiUr0pa gfQ7f7WCPZHWaLRCnVlOJ96qgZUvsCXYOl0muHW6vyOdxCnEUYrAAKoeplUAdXoQoc4FGHX2 gShsfZZIMXEEwJIJPPTcRqR5jLSWcyFrUtO37FwEzsXqphzaSEHpsg0MpbOG6KN09giG0kvb GUrTRzCUDtvGUOpcYlWXdz6jw8L5rN0voDqXWib2Mj0efkA1MlCobljGoDpkVtmgmu+UawOC au39WAKFalBxqEohFhzI1aEQfCqEJgZpRhaHbSP6zVkL20ZDncsxOkJB5jtOynBdYQbXDArX 5zqC/AEdFp9jArDow2XmXWOp9q6dz5tR/r8CpLyykxFl+ItRxlJD+QUzyi+eR8ovdTaijLMo aMSBlBrKq8wov3wWKa+ON6LsqMsoY6mhvMaM8to8pLyuixHlvBhGGUsN5VfMKK8/hZQz7zKi XHg/o4ylhvIGM8obTyDlTQlGlHGyAlLET0o+kRHn5mN475auIKv2zAXsXhYGeelvFgbZ3Z1j YRDn//CiP6r9VXBuBdWREp1bbpEQ5zbLdORrOiyc2+1UtRwWP/kaBUOcOywT+3U9HhU4HDLz RqZcG4hqP1opCaRwyNGGim1RhnBID9aNNWo9OsX5Bn5vMwQcOmkIOJ+4iHMntaWyuoMMOKcI OBYEGU+eA4MgL3fhWBDE+SZrGHPAvQXOt9UNElHvaLnFQZzvWNZz39Vh4XzPTl+4NM3U0JZ6 3zKxd4HOUYGDITN/T5NrAwKcHeeXMLfnKBcuX/UNhkififBpDNyeuw7TGjXQjtaLcH6An6t1 gRbTgI1oWKqjIs7dZmPmh4cRhnscJVFG6GKpjoc4PzKjvJdaavt66lH+VFQOSBGVg08kxOml yuHjXlBMObBYSCeOo7GQwniOxUKcn+BFf5TDp+DMVr+8Pp2Olls4xPmZZSj7XIeF8wu7f47W fsvE/lKPR0WOifyq8AlIOdTIBFk5xA2Sr/rGRPxQDjWY9Brl0KmP8yv8HK0LNIQuAgxLTWzk azMIH6AQ/qYPpRwuU6bQRUoIXd8YybcUugf7QjHoshjJ5ussRuLqy4kxkhzWxObQPQTO79RN u6vj0fKLkXxvGQYO67Bw/mD3D7o/Wib2ET0eFTlG8mGhXBsQdDsiKFiM5GjNPfJVoxiJGsIl xEiaM2k0MO64y5mLc2g0YEPYIsiw1MRKjprB9xiF7/H+oFIM15ggLO6wUIw7LPTxtE+YUT5J YyWnBhhRxmmxNO7wog/l02aU82is5MzdRpTpQg+MO2zxoXzWjPI5Gis5f48RZee7jDKWGsr5 ZpQLaKzkwkAjynQ2j/jTUL5oRvkSjZVcHmREOfYqo4qlhvIVM8pXaazkp3uNKOc8LVK8XjxW 8jONlfxyH8gqPmchu5fFSo68xNFYyV/HpFgJ7ev+qPhfwfkbqI7cZkfLL1ZyzTJdqae1nL/b /Zo44rxhmdh/6PGoyLGSsES5NhAVf0wVKzl2y2IlR5vlOm/iVElDwFHX7XrxWMmf1Kb6Cx9O BJxXBByLlazOZLGSTt9JsZK/WcOYA+4fcP6rbpCIesdkwLV/kwGuRQd9m6p+CrOp+qxlNlWb FGZTffWyaFP9Z1nP1Vt160ImfthULs4qsV26HdUPwFUNFHBvtmeA69CibIADr1wbEOBorASX tBDAlRArCTxOcqxehCtoMBiALOUDNpphqY6TuIJNxktXJYyTuEIeKIkywhZLdZzEZTOjHIpW mqvyED3Kn4qKgVK8XixO4qqCisEVhs3joxhYnKT3BhYnGX9IjJO4cN2sP4rBVQ1ct6lfXJ9O imL4XVQMW+L0FcNJUTG41zDFcERUDDdWMcXgqm4ZwsKh+OGqYfdPMdS0TOzb9XjcEsXwO1MM cVvKphhuV/gEpBhonERUDCXESQKPkRzr1MdVCwdxXZAhbBFcWKpjJK7aZvCtQ+F7x4OgctsI ZQpbSul6sRiJK4LCtu5wKAZbFiN5ayVHYyTXT4oxElc91rzmsK1PHGx1s+7qqMB23BYG2+8G 6sO23xgG24itDLZ4jrBdvEWEbQPL+n9DHRauRnb/YGu3TOzGejxuhQG9ZRyD7cDvygbb5kpt QLClMRLRgPYjRlK6+MixjrtcTUaAD9AQsggwLNXxEVdTM+hGUehGjwRFKXz5LxOErdQg4zld qUFKtXftamZGuTnGR1wxo4woJ97FKGOpodzCjHJLjI+4Wo02olx4N6OMpYZyazPKd2J8xNVm jBHljJGMMpYaymarpV2xGB9xtRtrRDl2KqOMpYZynBnl9hgfcXUYZ0TZkcEoY6mh3NGMcieM j7g6P2REGXNnIMXwVbxvfMQVj/ERV5ckUOIjX7B7WXzkQgJP4yNV5vMsPuLCyTB+qfcEcHUF 1ZHb7Fi5xUdc3SzTk911WLh62P2Kj7gclondU49HRY6PtMuTawNR78dV8ZHjtyw+cqxZrqtX MpQAOHTZEHA+8RFXb2pP9RkPij0lAo7FR84TFwjjI+/P41l8xNWXNYw54PqBq7+6QSLqHZcB 99w2BrjpvfXtqSeSmD1VsInZUylJzJ5K2CDaUwMs67l367Bw3WP3z54aaJnYg0Dn8ANwtQIF 3LbnGOB6Ty8b4Po75NqAAEfjI5gFjACuhPgIzlrHqbAm0+h14iTH60W47sVXoQs2dFxwVMNS EycxW8Trup/GSRInlkQZ4YulJk5itnzX9QC11oZM0qP8qaggkCIqCN84yVCqIIZNhmIKgsVJ dnXjaZzkNqIgWJwE/Tm/FMRwcI1Qv8A+nRQFMeQ1piAu9dRXEAnJTEFEiQqiazJTEM9nigpi pGVIG6XDwjXa7p+CGGOZ2GP1eNwKBfHaEKYgel4qm4IYmSHXBqQgaJxEVBAlxEn8VBA68ZLj nfq4xuHCU12w0dkfgxmMNfGSh8xgnERhnJwCihuHlCl8kRLC1zdeMp7CdwKaEz7wZfGS5u14 Gi9Zv4QX4yUTWTObw3cSuCarm3dXRwW+e9Yx+NYZrQ/fzUMZfHfvZPDdPpTBt+nrInynWIaD FB0Wrql2/+Br2Vpfl95iX3/gaw8Uvuv2MPiOrlM2+CaWbq7ocRovwTyZBL5+xEt8YRxY3OR4 x12u1IfBB3AINgQalpq4yXQzCD9CITxjGqXYbvaKd+Ke4H/r4Zg66bfgf9710i8Mjn1eqCQJ oMqP2x4qYWZKV1qq2Baw+Hby143IY3UNgtgCAppH0YOQ06it8LLyIIF5L4LUE8t42LEGYNse hPlj7HWYw3wmuGZh7YktS+jV3GYM5g7ingzcuTphP2kYZxeAzR2Is757UnbMdtI4961JSKkb BPVJ0+36koc1ZJQe8x8PLcn5mAM8rFwP0OJvIvFsy/DyuA4L1xy7LsxzSOsMOMtgbn9nCbjS LRP7CT0efiR8omI/aZnYT5VF7LmWiT2vVGKDKy8QpfqII2H1TuIYNiT2TBcnQIfNfjyo+lAp 1WSzWRz6mapO1MA1/uzb0YnGVeWrJS9mdNBrS96x62anClZLpnAKwgA2i4ecaCgrWsJpBf0b 9K4x7oEqB/0VVFNoZSQDyw41SZdrsOaZ1M8ocu2aCFJyvhPhaq4ZVEpMS4KcW/hQJ/fb2RCj GRSa5bqeRiF5r53WUPdsDukVB4kVdaYzB5/vQhVLV637o2Kd4HJhbdfcJfQl7Gp6wlDFxgyZ nJ33HhH5wpoEe3QQzCTE037g4VoCB7WqBAGK8csRJkZBSBC43JahR9Bh4fLYdVUsTtGEn5mK zdhAQL/AMrEX6vHwQ1dRsRdZJvZi0Dn8FduyZe4uvWXu/qjY81apWNOELwYq1q5SsbxDvlry XGj2d0s2ZASiYntgVxBVbJWVKk4BqlgNV1MVy10VJSJcm8xScdWqWI2aFTkQGnWYN6BWsyea 7nI9OwOKW7RzfyDqdsMrRM8RdRt2mIM9VN0uBfBP3S4DF23zMV8yi/ZAN2N1m3htcnbWXh4S F61NKGwdBGs2cuA4yUP9ExycrxEES8j56dNE/R7hYMdtRN2usAxJGVD8cD1n11W3mHQ553fR cV1BFMDzlon9f3o8/NBbVOyVlon9QlnEftEysV8qldjWqds0p8InIHXbBO9DP5qooxpK7lfj aRUOWr9kRVYgqraRkiL+BNxUcQlQ1Wq4mqrabjHKs7VU/lpP1WrU7Qo51NGSyapRt90OuFah FtZVt2178lTd/t8TvKhuXwbwT92uBtca9QPl1jwpq9vPXmfqdllXpm6TXppC1W1Sq3VU3Ub3 5am6fcvFU3V7BzlHdfvUPJ6p27WWIWmdDgvXK3b6knzXlCcl87K6zYgWwLXeMrEz9Xj4Yyai 2BssE3tjWcTeZJnYuorPD3V7MVB1+/pnTN12XVY26/Zls48q+ur2ZDd0k9ki3ZPt1TbnKloa R2Ud9LoQHYiFe7IbBumZ2j0Zl6ni9jIEona1XM3U7slutUCycE+2UyfWXg1qtYvfP1v4cCA0 ahbfWeNkzVzXlkfxZi9Np59y15GP2KXCfWIp12fe80VR0c6T3tjIIAg/GN4TKv+3hZicOzl4 6F1igv7AyZJyLt/8Oka7LLheBRedTNL69AJ6NfyOk/InnCvvsU84jpbsEw68OiV78Z+ETMK6 hPhBPFwZSx65Hg+tFvMQ2ZaHfHK+N5KHCA8PjVrz4LIsv45LL7+Oi+bXUd6xpJrhUZ7u5kRj u2kLwbWDtaMFYpecX8d4q4zQQD/hvHcF6Ceclo6yfcLZWbo1Yyd7oIJi9svJTsq+TZKyiFX9 MFoobZmxME2OynUtnvP05B3hrjcQ6dJX1xEfetmVa8R+2U80Dq69xzIH97eTPtnsNPtkk0Un pL4504hySi9GGUsN5bfMKL9NJ6S+M8uIcugDjDKWGsrvmlF+j05IfX+2EeWtyYwylhrKu8wo f0AnpO5+3Igy7juDlLHUUP7QjPIeOiH1ozlGlEesYpSx1FDea0Z5H52Q6k03onyzJaMYk8k2 XlN/P/+YTkj9BD+7SHbxNHZvZhO8d2gfgB8qc7B5IUDVujgh9VO86I9dnA2uz0B1RPRQlO8h cULqrH76E1I/ECek3ilOSN0nTkitLk1I/dwy5fuFDgvXfjsFf/s32bnhhNQvLRP7Kz0et2RC 6iGmfPuVLSfDrB4Kn4CUb1PEgWg7VVY7j0z5opUW4ITUBBp50yrjHhGurzF3siHg9rdmgMNN xNSAO0AnrHyDHwwlwKWyexN74b3TiAl5NI6DZ+YRsPZCwH3LGsYccAfBlaNukM1NT5XfurxD lvXc76D44frejt+ufpfODSesHLZM7B/0eFTgdXmzmil8AgHcqZq4qowF/k8Fe+SrEuCk/XBM 1uU1HUpr1CA71XSz60dM560LMtxbD0czLBFs8nh5xGy8zKUTUY/OU1FefpYJpKRzRdj+pd37 z3XMjPLxK0j5xNOggDvsHKNMd/s78y/b7W9RbY7t9uc6yV6CuStzClynsVba8C896lS5bfjn yrMMJWd0WLjO2nWD+r57/rnOWSb2eT0eFXjXv1l1Spew/VQTJ0gTC04FKbET9WiKwI6TRk1l 17/ubEKZBtBR6a58nDUgwa7fKXYbBXT8F8wAxlJjABeYwe4CdWFQ9+tTzv2RUcZSQ/mSGeXL 1IW54jKinF7AKGOpoXzVjPJP1IX52W1EOeIGo4ylhvIvZpQLqQvzq2BEeVcljlLGUkP5NzPK 16gLc91jRBnVMHVCW/tQ/t2M8g3qwvyxwIhyyj7WCrgpoa8Lc5O6MH/itAZpF+me7F7mwmTn MhemVn1OdGH+wov+WFR/g+sfUB3XG58qPxfmX8u01386LFxFdsMpwGoXBjusNWK7OdA5KrIL E1e6GfynGhPeogtzinPIV8vgwnRjIXONMm583c0vghIAhzBGwPm4MO4gdGHcwRjvlawcEXDM hTl+hrkwf9XgmAvjrsQaxvRduUPAbVM3SJKt/FwYd6hlPbeyDgt3FTt94e3EcyMXxh1mmdhV QeeoyC5M/zy5NhDAna6ET8pcmNM9iscM/HRh2gygNRqQ2ZLc1XAWji7I0MGgo9lfWhfGfZvJ eOmuji6MO/wZFeU/f2eUlbyCA8QMgCoXxl3DjHJNdGHctz8LCrgfv8EoUxfm0gGOujArzosu jLsWewmm1q+7NrhxH3TZhdnc9HS5uTDuOyxDSYQOC3ddwoQbI0+iMXJh3PUsE7u+Ho+K7MKM dsq1AYG7xiqQXJjTQcp2G74uTHJxF0YnJnG66WZ3JMYDRdg5e19nt7EY/vPMAMZSbQC7G5jB riG6MO5Gy4wo39zAKGOpoWw3o9wYXRh3k+VGlFe9yShjqaFsliTFHYUujDt6hRHl+I8ZZSw1 lM2SpLibowvjjskwopybwyhjqaFsliTF3RJdGHer54woX/yDUcZSQ9ksSYr7TnRh3G2eN6K8 +BlGcVdRMRfG3RZdGHcsThUUlW5iL3Yvc2HOb+KoC9OhQHRh3FQD+GNRxYG7PaiOpU1Ol5sL 4+5gmfbqqMPC3cnunwvT2TKx40HnqMguzJQ8uTYgpdsEn5S5MKfjh8pXy+DC1Gcf0jXKuMlS dxd8YkPAoVWFgPN1Ye6iLkwCjs9SzEAEHHNh/t7BURem3knJhenKGsYccN3ArclZY297uvxc mB6W9VyHDgt3T7sh4DQuTC/LxO6tx6MiuzBJDrk2EMDldcHt+pgLk8c55asBujA6uXdOt7W7 +7wIBiBDBwNHMyw1Lkxfs/GyH3Vh+r+kUHYsifiY/kHaES9U+qU7B/ObczD2aQ56tqStHQTk RsLgE/HH3mKBe4AZr7uxEYIzx9toQnv7Bla676HT6bxd9veq81bGghM9JtPjRo8RpOK7IzR3 EUC9n8SsbHnbyXD8ZBA1D9S6ZODP+CCD6CQ5cfA+8BttIu+7x8m9V7bzsG4f6V2Vg+Dwt4Sh G2cJ+qVL7gM3ZoWGHS0EiI3r/WBwFUWXzF6zOsHTHOC3ZKZLss5NznaEcZA1Z21C4VgOoudz kNeKgzvOcHDYwUEzcj6LeFSOExxs70aePtEyUA7WYeF+wK4bDsl6nQWhUJcUTiW6ZIhlYg8F ncMPXRITqC5ZM5vpkuTfyqRLZtcv3UefvJY41JJnQF0CS+Wrki5BXEiTXfFJULckiv/GPSpI h4TxwKal4oA+QdIzUwslPRNWPBXB6SrB7mE4kV4KaKwWAchyoKfzdBDHUhPQeNAM+8NpQGPE WlAyhPwhUqYBjefm8jSgcXUTLwY0RrJmNA9ojAI3ZluUAxoru+bJ8BwpTi+d1Eo/oLFhLAto hCxhAY2Xx7KABn5doQENyzLluPUy5bjHESacMmnYMKDxkGViJ+nxuCXTS0cyeLaaVDZ4tlEk Dgie3aNAml6al5ApXy0e0CAigjK9VBXYiCs+zOd1XelOxjUf0jD/dBG7jU3V7MezqZqk1LjF 483gN4EGNia+YkR56zBGGUsN5UlmlCfTwMaU9UaUB0xilLHUUE4xozyVBjYezjSifHEWo4yl hvI0M8qpNLAxfYMRZcy2gpSx1FB+xIzyDBrYSNtoRHnVdkYZSw3lR80oP0YDGzM3GVGO784o przNFwtszKKBjdn49Umyjeaxe1lgY+VwngY2zr/Mi4ENmrfEH9toDrjTQXVMDFOU70ExsJFu ENh4XwxstDUKbDxhmRZ7UoeF+ym7f4ENyzKJuEubSSTwwMZBMbCRXjblW8poch4ogY28u5SE u2o/S7KF/P02O5fWaJRx2ET301ugBMChr4WA8w1szKeBDboDtRTYEAHHAhvbk3ga2PgqgxcD Gy7WMOaAc4Nbk/EixpZXfoENj2U9d4EOC/dCu3+BDcvSYbhLlw7DusDG7MGlmwyR1w3lEwMb keoEwwEFNlozcGlAZotxL3kVDECGjgaOZlhqAhvPmI2Xz9LAxtKtCmXv9yEqVybUEURhi6XG lVlmRnk5dWVWbAMF3DVtKlfmUP8g6srMeShIdGUy2Eswd2WeAzd+uZBdmcIWZ8rv2+z/WYaS lVD8cL9AmHA/Ds6pw84NXRnLshi4S85iUPG+zc5+unTJDs90/wekb7Nn2imTan1dmUeKuzA9 2No8NaDPtCh0r8K1kfKUiEoMHBTQjmosdIelxgB+2Qx2q6kLs2a7EeW8SEYZSw3ltWaU11EX 5pUdRpSdrRllLDWU15tRzqQuzIbXjShjTkWkjKWG8kYzypuoC7P5DSPK3oGMMpYaylvMKP+P ujCv7jSinPMYo4ylhvJWM8rbqAvzWpYR5bRKjCKGd31dmO3UhdmBK7tEpZtyk93LXJgDDYOo CxOZHCS6MHSdqz8W1Rvg3gmqY2nHM+XnwmRZpr3e1GHhfsvunwvztmViv6PHoyK7MLMccm1A Srce8mQuzJkOq+SrZXBhWh+mNRpl3HGp+923oATAoVWFgPN1Yd6jLsz7b4MMuCQRcMyFOdc8 iLow/Igg0YXZxRrGHHAfgHu3ukEGtD5Tfi7Mh5b13D1Q/HB/RJhwF52JYszW0IXZa5nY+/R4 VGQXRjUfNiDANcGdk5gLc6amOotSQC5M3FVaowFZ6wFuL+otXZChg4GjGZYaF+Zjs/HyE+rC fPquQjlzXc2P6R/Qb7NHPuDpt9m+f/Jm32azzXh9loK8Pn9P9RRFwewp2Gq8n9lGTViqN2py f2FGeT+1275834hy5r+MMpYayl+ZUf6a2m0HdhlRRhuTbi5FSg3lb8wof0vttoMfGFFGG5Nu ch7pQznHjPIhard9t9uIMtqYdJPz1j6UvzejfJjabT98aEQ5YwijjKWG8o9mlI9Quy13jxFl zAqOFJNGB/luteU+Su22Y5hwRrLb/mP3sq22OhexrbZG9QpiW225j+NFf4aRE+A+CapjYvSZ cttqy33KMn18WoeFO89O1Zj05c/Qbjtjmdhn9XhU4K22ZjdRVukHMIxUqUvBQe22KnXjkuSr 6s/yAc6pC2Pbg2iGlOiJ7nN7oQTA4a4/CDifrbbc56ndlo+jumS3iYBjW211IC2KW23Zegax rbbcBaxhzAF3AdwX1Q2SG3Wm3Lbacl+yrOde1mHhvkKY+JHZwH3VMrF/0uNRgbfaSh1TujxO Z7sS3uJOOmdbK8s8JMAFuNVWZCqt0YAtKtf9sxcMwLbfzkY1LNVbbbnNlgC7C6n99uvHJVFG +GKp3mrLbbYE2H0NN/hwX/9Ej/KnooJAiqggfLbacv9OFcQNTCDkoyDYVluhXBDdamscsVfp VlvuP/CiPwriJrj/VL/AAW3PlttWW+6/LEPa3zos3P/YdWfiFFMQlq0vduutL67AW23BooWx 8r8DUhB2zHEgKoh2mfJVSUEEuNVWJNueW60gzrYd4C7KBgOwIXwRZFiqt9oSwATGAocwFvjP KOVwmTKFL1JC+PpstSXQZb9CMHYEH/iyrbbmXGdbbf0yKIhttSX4u+xXCAFBs+y3Vruz5bbV lmDZsl9Bb9mvIC77lQ4j+AqWLfsVSrvs16KttuCZzFKO77FekLbaOtt+gHz10KKNtCzDVluN o2iNBsrtagnVMHmcBnAIXfqJmZTqrbYEsyXAQnUK4XCc9i8t1P3pAhOEZrSeHxxEM1qf6xrE MloLNVizmcOxJgi3q5trc9RZTUbrjIalz2gt1LKsX9fWYSHUIUy4WvCceG6U0VqwbH2xoLe+ 2N/U0EJdy8SuVxax61smdmSpxC7FBgLlk9EaVkzIlP8dSEbrs1GovlhG67MNvPJVc+XnoNcD y2h9to3yzelsN/UibDqt9BZltD7bIBWk6QVnK6sXMtAJqTSjtUE263DWIhoFHrVZaPAlKHNv pOVKE48SdTuRjJoNiE8e05KYQ8Ru54SGAL5zb/aILaNVt41AsEtcwj0zILXyOdn6qfshs36q N2TWz9aZ0+jcm622DXTuzcdtQujcm5xBIXTuzTvkHOfepJPz+GTSnxtbhqQmOiyEpnZd62dr txB57k14xGIQoiwTO1qPh+lLLMXcmw/rMuunYfUyWT8rxpXOeTlXOQIkcJyLUhSQpAAGkh+G B+8VwbE4IryEuTfnKqcKzTDHrC84Hs4l4HA35aEaAcf2LjysouBozh7CHBwxILTA2rmVF2Nv KcruroDjkjgxraYIjosLp2c7W3Jwsd6mhNh5HBzqGwr2gRycmxAKtZI4+I6cv3svB3+PDgXH WPKuW1rWy1rpsBBaEyZc1F7pXHYNEkMhdwgDR4aNgONOy8Ruo8fjVoBj7yURHDXLFPqbEeaU awMCR5sskMFhU2LPEjikORJ3S+CwySNH91m0RgOO7tlC269B8ZtHieAYd4yAYy55xBXfcjCj N0C9U6QNhVj2EObgaAdCnFr4rJYKOJaK8xneEuczZMyZlp1Xi4eMsA0JGVN4iGwRAs6OPHw7 OgRm3cNDLXJui+fBNioEnu9P/Ob2lvWyDjoshI6ECff3aMmnlsCR0ZMMdN2ZoW7vQsDRyTKx O+vx8AMcAS9Ae3MpA0fcW2UDR1C4XBsQOMKwg7IFaOe6qddAMHD0Jb8+5NcL2LyGnhJIusj7 G4SwuzQgaZklxONGVr4gwRkH1X4gomYRu6ZZN4CEZARJF/Yw5iC5C4QEiQv2iq6cApLv32Yg yW+jmFcxS5l5lUuw+FTzENi/g4OkB0Ngz8ccTCfnaTs52DskBP7Gd97Vst7WTYeF0J0w4fZN 8gUJmlfOd9kIkpZIQGJZHgnBocfjVoDk7e8ZSNrklw0kdUu3buHibdi1GUgucinyVfUIIk36 UceDFyfKU5yh+ISfc1xXoec3IMeDtSkTMskLyJnOQc9XiWOQz7FmCQacKitPy+HBWQQFQi+z 8FJvTDtfCf8oKHa/jX7rxxK3kkmMtEHhAUJU6HPQSJRH5/BwiIiS/AtfoihFBYJZpgihX44s SmJ4ZSoKliiKfU2oKEr/Q4oo4NjppeUdvxLVUTiMtArx3LHEHA5yiM0sbYRwN663EO7BBPTy pnHrGeWfLhDKH48kyu55cvEJgP9tQLMWjWZ/1lsIg0CgWSDk9RbVzstKafRuppSSmuqvt9iU zNZbBC1g6y2eS2brLb5zsvUWwn2Woft+HRZCImFCXnxP8dxovYUw2DKxH9Dj4cd6i+BAldLu 0UwpNU0qW5aYZ0sX8T4fij4fhk0ahp2vqqQ2lpQSKiJszzjQXTbenU1cUSuk89UKhSHfgwK9 uZ95aekoEnf4cTRiO/w4u4MCvaFm0BuGs9WEBw9Tyo0fHIZHfg+Fcl4bkeI80onGguZD1XCc +SWMwA0YRNg6FzCpMofjvVPbArxA7k2fC7BjLMLWN+ODYWR8FAij1c2aW4/BNj0J4IlNqxPe Ie0bTfrxgSj2oep8DfahasxjPCSPIq3TjoeFRAcNeJCHWeS8egdiaL8K0GwIKS3L+CDoZXwQ aMYH5dxo5pdgWcYHIUmPhx8hZip2smVijy+V2OB6MhBtk5SesHoTGZcarQIYHA0QdQACO1Ta Zr3CJ5AQ83lbtkgHtU2ofFXtJ8haRpyU5htO1kiiUG6DgV325e58lJKXRwonY2AX9QmGkjF6 hNPhyPuGNPFXwpS4esW3MTxfL1eY8CNQTTRcVxOlI8F5zMxQa6KJ9JP5pCOgGBALmSZKnIP3 /kecmCUzAHbhUPg0aqLJ7IHNNdEUEBSjkhxD7YoBEfUGMyBwoqLeJ/Oqk9gn8yHr2SfzKpPY J/PsteIn86mWYeNhHRbCNLt/n8xTLRN7uh4PPyAdHqgB8UYUMyBwenFZDIiVpfNqzofhjFL2 1eh8oyT5qq9XIxkR+DQGs11CWFRNAzT7UOGRXDAwJtB+x6EeSwo4yZiYYWZMpOF0OOHRo2rK PzCBqIfg/JBBF0uNh/CYGeWZ1EOYdQwUgKcdYZSphzB4H/MQnj8leQg4K9cvD+FxEHCvQNlD mFulHD2EdMuQ8oQOC+FJuy7Ai3kIT1km9lw9HhXZQ9iq8AkE4PmAy4mYh5BfQ/Ey9DwEnU1/ glmNBtRV5grzcGmFBL1B37A/oqBe9T7zELDUeAhPm0FvPvUQnCco5XYaD2HiURWHtJWMMl2T 7OMpuKinQBdzSJ5CLyYd8xT+XMk8hdCzkqcgsGY2H59Jb9VkFomE/PLzFBZahoNFOiyExXb/ PIUllon9jB4Pfz2FZy0TeynoHBXZU1CtRA3EU8inm3YyTyG/c/G4ROk9hfz2mSB5CvkxSjqQ cvAU+OJz/PIhUlh2CqhGGl6iRkIDhuYy8PEYllOPYQUuxZIMClEjMY9h+XrmMQw4InkMvile DDXScyA8r26sDp3zy89jsCzFi6CX4kWgKV6Uc0OPwbIUL0LJKV4qoMfwZulSvOTTmVTMY8jv 5JCvlsJjaLKW1mgA17mDsCoPDIwLtOdxyMdS4zGYpXwRVlOPYc0ZFWVpfx3qMeByVoQuXYqr 9hjMUr4I66jH8AouWpRMjs43GGXqMXBfctRjeDWPEz0GTHDpl8eQCcIGrJU8htzo/HLL4SRs tAwpm3RYCJvt/nkMWywT+396PCpwDqdZqs3aAwJ4R2WqTL59kHxV7THgDiQ63gJXPG1IfnSu 8Oo5kGEnZ5ungMadZNBbwFLjLZhlABK2UW/htfNQ3Fu4dkPFIfwVRjn2KlfMW6CZgIQd+aAk M5V2aaHewsvkXvQWtl7hRG/B30xAwhsgaDIB7QnVegurGpXBW7AsE5CglwlI8DMTkGBZJiCh dJmARLHftUzs90oltoXeQm6eXBuIt1BQfQBI3kKBZrs+xVtoXypvoaA76jLmLRS0VU8YL7O3 0JAlK9boutA9wvu4Bt7XWyimkdB4QY3k6y3sot7CBxdAmXcrbWNDvQXcxga9BdzGhnkLu9mD m2ukD0HQpBXa3LSg3FIlCR9ZhpG9UPwQ9tn98xa8lon9sR6PCpwqadbPDrk2EGOioCmGHFmq pIIuiqy+3kJ7KNFTaFDcUyhouln4BD856BoWaMfjcI+lxlP41MywyKaewmeXFMrQoJBRpp5C 0hQGWyw1nsLnZpS/oJ7CfkwSIXkKo0XK1FPoOY15ChfckqfwJXsJ5p7CVyDgdGTZU0iPKig/ T+GAZSj5RoeF8K3dP0/hoGVi54DOUZE9hTOFcm1A4I7oAJKnUNBRWWXs6ynozDyKLr5fTEFU unDoCiiwO3iV3UYBnT6BeQpYajyF78xg9z31FA5fheKewh2/qjgkOhjltOXFPYUfqKfwIyZK EaGbeYBJxzyFow7mKVxcJnkKR1gTm4/LuSAcVTdtnw4F5ecpHLMMA8d1WAgn7P55CictE/uU Hg9/PYXTlomdVyqxwfW0VZ7C7165NiBPARaDrHFsJ+SrksbBVQq40LWU3oINqYvegt2hol5m byGcyarRdx36CGfoRR9voZhWQgMGtZKvt3CWegvnfgHFoBC1EvMWEu5n3sKo+ZK3cJ49uLlW ygehQNNaLS6Un7dwwTKcXITih3DJ7p+3cNkysa/o8ajA3sKMuaWbjdSkOkKMeQtNKuXKVwP0 Fu5gE+nUYLvQAoSraHPoGhdoy+OQj6XGW/jJzLj4mXoLv/wKxRfK0mVOfxALLa0yQNU5AK9G IAQLWVOZQ/BXEH7D2rnXUm3dbzzSA6IVCP67mUGwwX0MgiNem5YdSpTfiO4bEna9CDDs/hDY SiR9bF0IrCUquz85j50CMOblEJjyOGmsa5b1Zb1eJfxu14XgiFkhkESn4hEI/pJqE25YJvYf ejz8gGBUoBDc/C+D4H0NygbBR71ybSAQvFAXDWW05RuGXWivzm2s/nLPnsLPJA+21F9kaDYs vtL8QjQIN7Gn6640dxKH2EkA9AIZQN+nAPqTPag5gP4CQZNvLTbMGEAXq6dmF/Yn5aYNCZmr AfLfCYEMokb4IBt4cCIwOY+ZRur/C4GHniQ99h/LeuK/OiyE/wgTvSSTR0MAHWMKoIMEQEVW ie3R5VGRATQlT64NCEA1UT4RQA3USSbLAKCDMoCqMKk0AAqL9XDXQHFNn1DnMZnejYMMAqBH nuPgCwSQh2cPatr2niDw0GA8fuzHlcVLIxUA2TIZgCqPYADa/2Fqdu5AUt6/MWHxK2R8HW2D 9FSA3LdtkOoC+IGc24kt+uNOGwwntqinkmU9MUSHhcdmpy+wknguAWj/AhvE0im+HJ80ONXm sSz5nEcv+dwt2a0408YANKJy2QA0rnQTTC5EYtdmuxVfaKxeC7KDloqPFyCIBidJIKrNYlUa EEUu9VTBh9U14/qu4qgZN+osx8w4Txh7WHMQVQVPNcpf5HQCLhqOQpm1p1MzLnPbRmrGrdtt o2bc7tBQasa9QM7RjHstOJSacZ7bLOuN1XVYeMLtumZc5mmbbMY5GxMQ1bBM7Jp6PCryKDRM 4RPQuo4gvI+NQucbKGkhJBCxT6oBAqixU94fhmX0UAPoIpzw3I4GiC6Awr8CeC+dg4Pk5fy0 iCMAqsUe1BxAtcFDN3Y7EDGJw1+sXQFQ3dUMQGPHMwAlPpCaHf82B4kFGxIuVuJh6tUQyP2e g8/vs8GBixwkkfPHf+Sg0SAbvJ5P+oNlWQA9elkAPXXtugDCBfoZJ/ACx6eNJgCqZ5nY9fV4 3AoArRazaY0fWzYADcySawNK9xBLPHcRQBejMuWrEoCwLVuBYsr57vmCI9R9Yl2iBKDR8veP RnmUigZA9lhP5A0wAFCtvjwF0PebeRFADdiDmgOoIXgaYe3Slqk27DFp1YwBFP/NdAqg+ORN FECDp4RSAL3xZSgF0ERyjgBq+kUoA5Ddsp7YWIeFpwlhwqW0iXCxcwlA8S+FygAC0gyeppaJ HaXHoyIDqFeSXBsQgKJwgbAIoKrKcqsyAaglyAl5aY0WQNXSPNEYp+G9NJCecteRj9ilQnFn qkK5fmn/o0W/eG96s9wc1Nxj7wmV/3QC3FjPwagMgBafc/KTcJ5mrEFMP+B6moMH45fgbDYT kv5Ote3ooADtynsMaI6WDGihZ6ZlX7zEQejsDQmruvJw7aUQWFyFh/afhMDcRjzkkfPQajzc vjcEpkby4GlhWY9tqcPC08quG3AI3R4CjttZ0DyRNIGntWVi36nHw4+v8AEnJnrvCgNaS0fZ gNZFqQ0IaDSdnZiYKFz5ki8BLVb8sTm78td4W+rfiXJiIjYzTgOmDjs8bbCZ/QBTTPr2oh6/ /+x9fgEHe643JmB6sC4HIZkcvB/DQRcNmNqyhzYHUyx4aC9IfT7Vlmrjjhe2uGQIpgHzUrNz fuJgQI2NCU4HAVEHG6TdxsPMcTaY2JSHaHIONXgYMcoGyXYCpjjLemV7HRaeDoQJl7aI5uMF 1ZSW/jaIuUMEUyEBU0fLxO6kx6Mig6lN6RLqXKIbGDMwXdJsYKyACUFUDEyFMph0kqlealHo 6Yxxaz/AlLn/WNEvE//1zlzMwVudcWTa1h2gDgFTFTIc3q0BUzx7aHMwdQHPXVROECN5HY3B lPnKtOxdv3KQGbchIaUPD88OC4ERNXn4en4IDGrOQwY5v1mLh0+fCoGRUQRMCZb1yq5Q/PDg /vKcci4HIVJCILw+A1NsbwKm7paJ3UOPR0UGU7TCJyAw1dsFMpg0G9NqR6Y48AFT79gSNqK9 1HGpx/EX+AWmEY9NhbyYKw4cmb5dHk3A1P8yT0emrX/yPiNTT/bQ5mDqBZ7e6oet2sEYTPH3 PEJHpvhTm+jI1JSrTEemCa0q05GpDTnHkSm5eWU2MvWxrFf21WHh6WfXBVN8rcryyJQ0frrN 098ysQeAzlGBwZQ2upQjU2NU3CKYaipT+SUwxfn8JDBNHy+HvduzuzRg6lDVczd+JfUDTDkP jC0qeu+E9xhxW+K/a9QTqp35EaAPsT57FZARqghBdA97WHMQDQQPXVqGvlLem8/A1doKiJaJ M5b/qcdAdLNTavaqZhzc/GpDwoAnOFjwewjE98e1szZoPYaDdHL+0d0c3FPVBg1Hkj5xr2W9 8T4dFp777bogukmG48L7qfLhvZ5nwJNomdiD9XjckhnLyxiI6v1TNhBNUfgEAqLTdmX+4OlK a+WrviCSNsV4xiPP4KvJpiNpwFP7qucBtBf9AI83dCx4Hzjn2HIJIO8q8ZGqfXGYgxEEPP+d 46AlBc8Q9pDmEb2h4Bmmfrg9kZcNwbM/fnr2zToc7D+wMWHrVA6G/WGDVZ05GFwzFJYO4qAf OW93FwcRt4VCCgGR50HLeuFwHRaeEXZd8OznQwHnRtKI3tvPgoemfLRE7FF6PPyI6FkGniSv XBvQCFR7FUjgudREPbOBgYdN9UeTzkHPn31bjta1ZtM/1OC5HLnHMxrnsujuvrJ8CQcpbwLc S8YazNDLecawhzAHx1jwjMParp8/S6/G2i8bhrt31ZienXONlFs2Jjj7cXBouw3SanHQhoBh Innnp8g5gmddWCi0JSOQx7LcmJ4kHRaeZLsuOHYdt0FMAwaOnD8JOMZbJvYEPR4VONydNqt0 sxYuRztACndf5tSr5ksOd0sfYXXC3fDsnzklfC+6bI/1TMSdOf0YfZybh/5bdHKP9+AfADHr 7GT0ORLLwVAy+sQTHdqMjj6TWEOYm26TwTMFa8fELYC1HdpDajXj0ScnI5Xu4JITtZHu4DL2 fhvdwWXkwza6g8sj5Bx3cHFMtkGdsaS/pFjWU6fqsPA8bNcFWM4om7yDS2LwAvBMs0zsVD0e Fdl0G1a6xWaXo7aCNPpcrpouX5UAht+N1KPPgmAlvJ1HazTgqZbqmV4EfoEn7YvPALrkOH6e z8Hh6VE9oXKje3iokcmBcyQPfTRBhEfYw5qDaAZ4qKLZE81i7+mhlw2DCFkfTM+GAg6y7t2U kBXPw5q0UMgM4eH46lBYWZ+H/5HzhMo8HH0xFNZG8OB51LLe+JgOC89MO22eP5PYuQSiLCGU bYONk1PrLgXPLMvEnq3HoyIHEQaVboHF2Ya4DokFEc42UWZG6AURGKActH5pXWUpdvFNjS+H pnseRw5ShrOH1TO47yBN1ut5gDY9Ab7ZgCCZwx7GdJMQTzp4aHrRi7Vm0qvBcQpIinYykCzv pGyHtDUH6HZII5pysKJ5CAz4FaDBuBDoSt7VS+T8MjH13hgdArODyDt/0rLe9pQOC89cu+5I g9shAUY7ce5c4gI6Gd0isZ/W4+HHTi8Br0LaWcRA0ml52UDS2yHXBgKSKzyOLmwV0pUaxWcu +GY4U69CWpAoz5GrxFYKaYASF+yZz3HFfR46xWdcEw7iCFB23sfBRxQoTvZA5kBxgcetfpCr 3BXDLZHQJPMeAGqSpTXiYFMfGyT9BLB4pg2GEkZvkPPffiE9MM0G88ib8AiW9Ti9RQOeBXZD kywCp0/haFKfAMWynKoevZyqFXlLpLQuSsaCgIDSFF8QG02uaLJ8aoGCPo4GJPXl0aRRa1qj BskV7qpnMc/5F1WL/KBo/a8/e5/ew8GB+Eji1/xCENn7ImbyAqhN/Zol7GHNTbJnwEMjBtdI d0L0J6lAJIh+TRUxiYYzcVr2CBuxAM9nJoSO4iCoegjcbM5BtZYhcLUrBw3J+Vzi9xRGh8DJ LqRPLLWsNy7TYeFZbtcFkbNeCGTF4gWOd9R71OZZgVctETsDdI6K7NfEOuXagEBUPwYkv+ZK jDpFldYk6yB+z3m0nkNOosGeTAuepP8HqWyHHXic42JgYNjmwMiwDog5gGxJIJYH4kwgnw1I TwBiOSDWQWO3Q9nKeNTgYk9GYsdB7WxiYWAIB2J9II4A8iuAWBiIFZDYMDoeql8UxGdmYHjB xMBwgAm3Pk8gBhrLcA1IrAbiZhLtoITtBvWfNtCdDEB8A487YWqVgep+ANVdwKMWl32GUL8S Y0YAVB9IvRaUNgfq4wbiR3j0eSDpi6AS2wpKGwPtZgfie3jsh6kFhel/oLpreNQSso9UM4xI CKcAHHbTO5zUgep+A9VdoiCcSDUDFk7EuHOwhJM+UB0zEN+iIJxINQMWTtZAPfxA/IzIcApj gJQVmawMDLZALMJKuEyD0alAtY5ALEGCnlwy9BQC1boCsQwJeryBYfAdGAbnyIiDwZ6XpIF6 3wP1HRv126D3WzUDok71goo5A80QB+J3RJqhPJqWh4zfsqjk1pFUB5FTJxCTbohRQ0zeIkZN JwOiH4PMRg4feaA5n4FmnCIyPGHx4AMkFID4OzPh8KFGm5ZUdzqR4U6YHkrcSWrZQYk76VnG wewMABIqQPybhu60B6oH9X1f4VFPjBpi6jRq2UWMGmLaf/RUY01EGiBGDTF+J8YcYtxMTFoi pmwkxj0AD0hFmkRFU0lHTkVSRE9DAKY8AACQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADlQhF1sKBIlxJQQW0xOMblFMAet2VH6C7DnQxl98wxB MZecueTOQ2MeWmUwH+174F7s+wxF4n5i7if2PnLuI/deuAetBVH6/4e9FJbQt9gQFIvIWUTu YjQWo7UElqL9L/g39sOGIrGMmGXEPkzOw+T+G/6F1v9F6T+J/QQ8Tt9jhqBYTc5qch9D4zG0 Hocn0H4KnsZ+xlAkniXmWWKfIecZcp+Gp9B6Mkp/E/ZGeJG+FwxB8Tw5z5P7AhovoPUibER7 M7yEvcXAHScxW4ndQs4Wcl+CzWhtitJ/B3s7vE3fW4ageJOcN8l9C4230HobtqP9LryH/b6B O05iPiD2fXLeJ/c9eBetd6L0P8H+GCro22cIir3k7CV3Hxr70KqAj9H+FPZjf2bgjpOYz4n9 jJzPyN0Pn6L1SZT+N9hH4Qh9hw1B8TU5X5N7GI3DaB2Bo2h/C8ewvzNwx0nMcWK/I+c7co/B t2hpzapXVf98tdvLVru9yB5frZhsVSsm4nfE7xjl5+PnR/kP4D8Q5deOzVa1YyN7hCnYL3k1 7REmxpzuHmFKbMdAdR1/j7BOzOnsERbGJAUKYyJ7hIUxpfiRPcKU2CdqHGNzoF7M6ewRFsYI tzAmskeYEpviVtf09wgPe1X2CPN/f4+wMGYy6v4eYfUdpeSYqB2l3qe3o3RezP+2IxjvZZsr fYuMlq30XlB8ld8Tr3eq7gfd7sb2iN4P0n5kP+iMKr8JrZ5/uMp+1OHf7EedGZ7Xa875lp5X 9x49qZ2ugK9fNW5iQJh7gq5W6G6galzoLnCiutj8BrvL1Vd1vtKsR+jfqaN/FukmmjuEfr2t 0B2Cfg+GogKV9wP+s1Mn5Bp1Qq5VP8h1sF79CD/JDepn+AX7V8M6Zam1sAp7JaygbwUxy4ld Ts4KcjUr0VoF5UrrRsZYiL+I/sWwhPgl5C0lfyk6S9DTLEZ/EZRhz4O59M0lppTYUnLmkquZ h1YZzFdaNzLGLPzZ9M+BIuKLyCsmvxidIvQ0c9CfDeOxx0EBfQXEjCV2LDkF5GrGoTUeCpXW vdiMcRZj5OIPpz8PRhA/grx88vPRGYGeJg/94ZCFPQAy6dNkkJNBfiYMUN/LLBiIPQgG06fR dq7yn+k6SPxhOCL7Qz91VPaFG2i7Xu2XXdXHUCG7qX2wV3aHXtjXQ2/ab1A6339m6h1i3yXu ffgAe4fhOrVTXgtdaOsMV6nX5eXqZdgiO8FVaivtW+XVtF2ttIavt4aYDfC8vAwuVS/IjnAx be3VenhStlGPwWqZqsphlUyDdtjtoQPtFyut4estIXYpcf+Ch+VFapm8EC7Abg2taG+pHpDN 1T/g77KZup/jfXCPPB9aYrdSWsN/Xu92+u6Cu4m9W56rSuU5kIzdFJrQd7a6E4IySU2HabKB mgpTZENojH02NKG9qdJa/jxHEzuGuLEwTtZX42U9qItdB86kPVHlyVpqOOTKWHUzx2EwVMZD IvaZSmv4ev3py4JsYrOlpwZKl2MAFO1SDYBe8hfZHbrJX2VXuE5a6jrauxLTDbSG/565jLjL iekEV2BfIX+WVxp+oO172U5+I9vKozIdUrEvksfghGwDqcTo/OZW6NnEZvSnGI7KFvIIHMI+ KM+HRvIz2cDwuUyC+vK/cBD7EG2HpM79i9GpY8USV4uYeEjATpD7ZW35KVTQtlc6cpe05U5p wa9il/zF8KH8WXwE+7D30V4htY7/HOFRYr4z7JTHxQ54F/sdeQwOiG3yM8Mbcr94E97Bfld+ DjrPn9dOYnYR8yF8hL3b8LrcI16Drdhbad8i3xYvyrfEC/IN2Ia9TWyUr4tNsIW2l6XW8Wv2 PP2bDC/IzfCSeB7WYq+hbY18TjwlnzI8LZ8Uz8Aa7LXyadC5vs7DxCwj5hF4FHs5rBRPQLlc AcvFKrlIPCIXimXyIXhAPAqrsFdLneu/v+4mZh6UETMfFoiHYSn2EtqWyGLxoJwFQfEQLJQz xSKOi2EJ7UvlbNAavt44YsdDIfETOE6EyeIfcB/2PfJWMZfvwqUyH/LEPDlclMF87AVwD+33 Sa3hf06ziR8MOcTfCEPE3fA37DvgdtpLZF8xS14PvcRsmCN7iiIoxi6B2+m7Q/YGreXP80ri r4LO5FzNsQtcK2bCNOwpsqMolJeI8bIDtBMTZFsxESZhT4YptE+TWsP/XLUgvhW0Jv4CuFCM g9uwx8Bo2kfJc8QIeTY0FvkwUjYSt8Ao2sZIne/PrTYxdaCeGA7DZF1xEwylbaj0xCDpioFS gcQWhsHSETkwhLabYJjUGv77+LgzSP4APzoD5U9w0smGTOwM6E97P3nc6SO/hW+cvvIo6CcO jxBz1BkAWbRnS60Tuj9QlfcHO7k33+mtVbu8dbBefQgfeRvUHtiLvc+wTlUQU+Gtwl4JK+hb QcxyYpeTs4JczUq0VkG50rqRMRbiL6J/MSwhfgl5S8lfis4S9DSL0V8EZdjzYC59c4kpJbaU nLnkauahVQbzldaNjDELfzb9c6CI+CLyiskvRqcIPc0c9GfDeOxxUEBfATFjiR1LTgG5mnFo jYdCpXX9Zyp3ern4w+nPgxHEjyAvn/x8dEagp8lDfzhkYQ+ATPo0GcRl8F2oPzn9yc1AI0Pt IGYH35F2egNhEG2DYZDSYzUx48Zb27y+6g2vn3ob3vH6QC+13eupXvauUVu9LmozbPSuhe5q k9dD6Xj/vfiM11mthXXeVXClWu9dAZ2w/wqX03eZetxrpx6D1V5bVQ4rvfZqhdcBOqpV9GsN /9nxxV6aWuKlq3/Bv7H/7XE999rABditaW+tHvTOUw94zdX9cB/2vQau414KtMBuCX+hr5XS ev654g7vXHU3lHrnqLmGZDXPa8qxCTSmvZGa49VVs2GWV0cFYSb2DEM9Nd2rDw2xz1Jay//8 FHhnqALvTFUIE71ENcmrDXHYtdQEGOUJlQ8jPKnyDEoN9wLgYnsQQ1+s0jr+9WmgZ6lBnq1u hCHYQw0n5RDvJ/hRZnjfyv7eN7IP9PaOwQl5g/eD1Hn+vK72jsgucI13VF4L12F3hW7eYfha dve+gkPYB+FL+g7ITt4n8lK4xNsP/8U+ILVOstFMsC709smLvAqZBm29vfCRTPc+hF2ypfeO bOFtl+dBM+9d2Cmbg87x1yDJe0s2gIbe2/IsaITdGM723oQ3ZBNvG7yO/Rq8St8r8kxvo4w3 bJJx3mbYKhNo11r++9D2npeO94JUhudlwNsgXcMa7DW0/UeedJ+QP7mPyxNw3H0SnpLfuU/D M/J79zmpNfzr55fuankYjrjl8Cj2I/Izd4ncD5+6i+Un8DF2Bexzl8LD2MvgEalz/fP+u+5C +Z67SO6AXe4/5YfuQ/AA9j/g73InvOmWwTz5OrzqzpevGO6Vr7n3S53va21wS+Umw91ys3sX 3IF9O5TI/7gz5XPwrDtDPgNPYz8FT7pBKMYukTrf11rmTpOPuNPlCljlToUpstydDJOwJ8IE uRKWumPkEne0XAgPubfBOOxCqfP991mZe6u8F+53R0Iedq68y82Rd8Lf3MHyDrgduwSK3Rth iCxyh8JN2MPgZvpullrHn99kd6Cc4g6S02A69gyY6WZDf+z+cqrbl/4+cqKhryykrdAdICe4 WfhZUufXtGck7QU2i+1U/Q1A6EmTtXairVv6paalhn4DEPmNyQkrBzaEd3Ua21PtDdbcavsL sUZng/WlpX9J3SW18Sl2L0I7KF9Z8yy9g9Li5tyWo4bedlv+6Lz8hPDvec4Njx29j3QPI3ay q48Y2j+5wX7MxGV0Tk1L7tc7vL9fdYdf2o149Z3syqfunAV2B6fmaoSebqAaaVWr0crJgUg1 VmNvtGuqxtnOH1djk/3nqrHa6WRXH9Gvxif2H1ejg9OIVx+pRrZaYGer6tWIC1djeOgJjHS/ GpEnKnIgUovt2PurPeng1+IKZWqR/nu14DvPn6rFdtXJrj5iYrgW/rMV6TU+W6GfOo/UoZNc YHeSNdehmwzVIbVKHdJlDkTq8Cz2q+LUO3AbrPpG5eq+6Wmh/ciaavGa+HO1eFZ2squP6tfi uPj9WnSSjXjtnaq9rxqa/LOtO8z8u6QmV246+n8VoP9vYMUbq94pXo+vsM7+XxUahRVeFPGh ykUkLP9Z3dOfx7vSzCP9f30l4+QwRyuktkpN1r9T7Nurc+/QesRZfmVDO46Na1TYE/hzCv7z iP7zd4NViR16/i49rfrzd9Wj+woTnXY60Tl8ikPaaacVvd3T0Wlpvx8devcLcad59i0trX1a KK7q84xW+MffP348EDsuev9Y+5H94zrVnmesmn+uG7s0Ol/7kfy6lfP6mznHpae2saPnX3Xl GjrLZGTl0v/UyoVGkuJBoUdqW2Wk6nU9FAjX9RRPWEZ2sBPD56aU8DOKqWn9Ks/6+vN96h3v tfZoEdrxTj/Fjnf1VXvQCq1a235Jlecc83dyUX9zGPqroyO2FT464aMIH2X46IaPieFjIHxU Nfxlm68XE17rRDO6/l2D/t92nHP7Th43PneUNfHrwPDXXetOW6+vPvp2SMefT1z4GB8+1gkf 64aPseFjrfDxjPDxzPAxIXysbWpiWf8P0G6RaQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQBUAGEAYgBsAGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A AgABAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAAAA yQcAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAKAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAAAUAgAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0A YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAEQCAAAAAAAAAQBDAG8A bQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA1AAAAagAAAAAAAAALAAAATm9ybWFsLmRvdABzHgAAABAAAABNYWFydGVuIFZpc3NlcnMA HgAAAAIAAAAyAGFyHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAAZkAAAAAAIJ20BgAAAEAA AAAAlKdvdJbAAUAAAAAAdhEmgZbAAQMAAAABAAAAAwAAAAoBAAADAAAA7wUAAAMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAA AAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmu rAEAAGgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACMAAAABgAAAJQAAAARAAAAnAAAABcA AACkAAAACwAAAKwAAAAQAAAAtAAAABMAAAC8AAAAFgAAAMQAAAANAAAAzAAAAAwAAABHAQAA AgAAAOQEAAAeAAAAFAAAAEx1Y2VudCBUZWNobm9sb2dpZXMAAwAAAAwAAAADAAAAAwAAAAMA AABJBwAAAwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA bwAAAEZpZ3VyZSAxIGRlcGljdHMgYSBmcmFnbWVudCBvZiBhIGh5YnJpZCBTREgvQVRNIGVx dWlwbWVudCB0byBpbGx1c3RyYXRlIHRoYXQgU0RIIGhhcyBtdWx0aXBsZSBsZXZlbHMgb2Yg bGFiZWxzAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAJgAAAADAAAAAAAAACAA AAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4A AAB7AEMARABGADIANQBFADkANwAtADAAMgA2ADcALQAxADEARAA1AC0AQQA2ADEAMwAtADAA MAAwADAAMwA5ADUAQQA4ADgAMQAzAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgASAAoAAQBbAA8AAgAAAAAA AAAkAABA8f8CACQAAAAGAE4AbwByAG0AYQBsAAAAAgAAAAQAbUgJCAAAAAAAAAAAAAAAAAAA AAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAA RgBvAG4AdAAAAAAAAAAAAAAAAAAsAB9AAQDyACwAAAAGAEgAZQBhAGQAZQByAAAADQAPAA3G CAACORByIAECAAAALAAgQAEAAgEsAAAABgBGAG8AbwB0AGUAcgAAAA0AEAANxggAAjkQciAB AgAAACYAKUCiABEBJgAAAAsAUABhAGcAZQAgAE4AdQBtAGIAZQByAAAAAAAAAAAAgwcAAAYA ABgAAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACgAAABOAAAA TgAAAE4AAABRAAAAAAQAAIMLAAAIAAAAAAQAAIILAACDCwAACQAAAAsAAAAABAAAgwsAAAoA AACRAgAArQIAAK8CAACDBwAAEzqU/5WMEQAAABgAAAAaAAAAUQAAABMh9P+VgAAAAACkAwAA qgMAAF8EAABlBAAAgAQAAIgEAAATBQAAGgUAADcFAAA9BQAAMwcAAIEHAACEBwAABwAcAAcA HAAHABwABwAcAAcAHAAHAAcAAgAAAAAAPQEAAEABAADuAQAA8QEAAA4CAACOAgAAMwcAAIEH AACEBwAABwAaAAcAGgAHABoABwAHAAIA//8GAAAADwBNAGEAYQByAHQAZQBuACAAVgBpAHMA cwBlAHIAcwAqAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMA YQB2AGUAIABvAGYAIABEAG8AYwB1AG0AZQBuAHQAMQAuAGEAcwBkAA8ATQBhAGEAcgB0AGUA bgAgAFYAaQBzAHMAZQByAHMAJABDADoAXABtAGEAYQByAHQAZQBuAFwAVABPAFAASQBDAFMA XABnAG0AbABzAC0AcwBkAGgAbABhAGIAZQBsAHMALgBkAG8AYwAPAE0AYQBhAHIAdABlAG4A IABWAGkAcwBzAGUAcgBzACoAQwA6AFwAbQBhAGEAcgB0AGUAbgBcAFQATwBQAEkAQwBTAFwA ZwBtAHAAbABzAFwAZwBtAGwAcwAtAHMAZABoAGwAYQBiAGUAbABzAC4AZABvAGMA/0ABgAEA MgcAADIHAABAwP0AAQABADIHAAAAAAAAMAcAAAAAAAACEAAAAAAAAACDBwAAYAAACABAAAAD AAAARxaQAQAAAgIGAwUEBQIDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAaQBtAGUAcwAg AE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAA AACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIcCAAAAAAAAAAAAAAAAAACf AAAAAAAAAEEAcgBpAGEAbAAAACIABABxCIkYAADQAgAAaAEAAAAA9nJSZllzUmYAAAAAAgAw AAAACgEAAO8FAAABAAMAAAAEAAMQDAAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAkAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAMjAA AAAAAAAAAAAAAAAAAEkHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAG4ARgBpAGcAdQBy AGUAIAAxACAAZABlAHAAaQBjAHQAcwAgAGEAIABmAHIAYQBnAG0AZQBuAHQAIABvAGYAIABh ACAAaAB5AGIAcgBpAGQAIABTAEQASAAvAEEAVABNACAAZQBxAHUAaQBwAG0AZQBuAHQAIAB0 AG8AIABpAGwAbAB1AHMAdAByAGEAdABlACAAdABoAGEAdAAgAFMARABIACAAaABhAHMAIABt AHUAbAB0AGkAcABsAGUAIABsAGUAdgBlAGwAcwAgAG8AZgAgAGwAYQBiAGUAbABzAAAAAAAA AA8ATQBhAGEAcgB0AGUAbgAgAFYAaQBzAHMAZQByAHMADwBNAGEAYQByAHQAZQBuACAAVgBp AHMAcwBlAHIAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAA AAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdv cmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA= --------------3485E32978AC83038A130ECC Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------3485E32978AC83038A130ECC-- From owner-mpls@UU.NET Wed Feb 14 07:52:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26849 for ; Wed, 14 Feb 2001 07:52: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 QQkcil23273; Wed, 14 Feb 2001 12:47:49 GMT Received: by mail-control.mail.uu.net id QQkcil08715 for mpls-outgoing; Wed, 14 Feb 2001 12:47: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 QQkcil08710 for ; Wed, 14 Feb 2001 12:47:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcil09618 for ; Wed, 14 Feb 2001 12:46:46 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcil05692 for ; Wed, 14 Feb 2001 12:46:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA29051 for mpls@uu.net; Wed, 14 Feb 2001 07:46:44 -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 QQkcil08654 for ; Wed, 14 Feb 2001 12:46:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcil22839 for ; Wed, 14 Feb 2001 12:45:55 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 QQkcil04469 for ; Wed, 14 Feb 2001 12:45:55 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 HAA15825; Wed, 14 Feb 2001 07:45:25 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAL00077; Wed, 14 Feb 2001 07:45:51 -0500 (EST) Message-Id: <4.3.2.7.2.20010214074407.020e6428@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 07:47:28 -0500 To: "Dave Danenberg" , "mpls@uu.net" From: "Thomas D. Nadeau" Subject: Re: Draft IETF MPLS TE MIB 05: Tunnel Table indexes In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC031257@WATERTOWN.litchfiel dcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dave, >Hopefully this is a simple question. The Tunnel Table has 4 indexes, 2 >of which are the LSR IDs. My question is: what should the egress LSR ID >be within the node that terminates the tunnel (0? the local LSR ID?). >Conversely, what should the ingress LSR ID be within the node that >originates a tunnel? The egress tun id should be the end of the tunnel (i.e.: terminating LSR ID), and the ingress LSR ID should be the beginning of the tunnel. The descriptions are very clear about where you should get these values depending on which signaling protocol you are using. --Tom From owner-mpls@UU.NET Wed Feb 14 09:19:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29426 for ; Wed, 14 Feb 2001 09:19: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 QQkcir14089; Wed, 14 Feb 2001 14:16:16 GMT Received: by mail-control.mail.uu.net id QQkcir12366 for mpls-outgoing; Wed, 14 Feb 2001 14:15: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 QQkcir12355 for ; Wed, 14 Feb 2001 14:15: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 QQkciq21897 for ; Wed, 14 Feb 2001 14:14:38 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkciq19150 for ; Wed, 14 Feb 2001 14:14:38 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id 5C1F494006; Wed, 14 Feb 2001 09:14:33 -0500 (EST) Message-ID: <3A8A92C9.F0CA07FD@sandburst.com> Date: Wed, 14 Feb 2001 09:14:33 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Bob Thomas Cc: Yakov Rekhter , mpls@UU.NET Subject: Re: PID in LDP References: <200102141155.GAA09379@rhthomas-sun2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov, I have to agree with Bob. In the normal case for LDP, each hop of an LSP is established for the explicit purpose of carrying packets associated with a specific FEC. If some enterprising individual chooses to use the LSP in some other way, there is a strong implication of either a pair of cooperating implementations, or a need to use CR-LDP. In either case, there is no need to define any new TLVs in LDP for this purpose. -- Eric Gray Bob Thomas wrote: > Yakov, > > > Right now we have a situation where RSVP, CR-LDP) have a mechanism (PID) > > to identify an LSP payload, while LDP doesn't have such a mechanism. > > > > Would there be any objections to add a new TLV to LDP that would > > carry the PID information ? > > Would you give an example of how this TLV would be used? > To evaluate the suggestion that a PID TLV be added it would be > helpful to see how the information carried by the FEC TLV is > insufficient. (Please note I am asking this question in the > context of LDP not CR-LDP.) > > Thanks, > Bob From owner-mpls@UU.NET Wed Feb 14 09:32:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29829 for ; Wed, 14 Feb 2001 09:32: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 QQkcir20595; Wed, 14 Feb 2001 14:28:24 GMT Received: by mail-control.mail.uu.net id QQkcir13316 for mpls-outgoing; Wed, 14 Feb 2001 14:27:50 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 QQkcir13289 for ; Wed, 14 Feb 2001 14:27:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcir08665 for ; Wed, 14 Feb 2001 14:27:17 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcir02258 for ; Wed, 14 Feb 2001 14:27:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA06764 for mpls@uu.net; Wed, 14 Feb 2001 09:27:15 -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 QQkcir13259 for ; Wed, 14 Feb 2001 14:26:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcir04898 for ; Wed, 14 Feb 2001 14:26:04 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 QQkcir00277 for ; Wed, 14 Feb 2001 14:26:03 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 JAA21002; Wed, 14 Feb 2001 09:25:22 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAL01262; Wed, 14 Feb 2001 09:25:50 -0500 (EST) Message-Id: <4.3.2.7.2.20010214091808.0211ace8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 09:27:26 -0500 To: "Choudhury, Sanjaya" , mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: Draft IETF MPLS TE MIB 05 usage question: Tunnel Table Cc: cheenu Srinivasan , Arun Viswanathan In-Reply-To: <4FBEA8857476D311A03300204840E1CF446C07@whq-msgusr-02.pit.c omms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Comments inline. >Hi Tom! This is a follow-up question based on your reply. >In your reply, you pointed-out "the XCindex notes the >"group" of LSPs used for the tunnel". It may denote a group of associated LSPs. It depends on how you want to implement tunnels and LSPs. See below for more information. >If this was the main reason for having the mplsXCIndex in >the mplsXCTable, then I might have mis-interpreted the MIB >definitions related to the mplsXCTable. I will appreciate, >if you can clarify the following. > >Given the following context: >--------------------------- >(1) mplsLspId is not a part of the index into the mplsXCTable >and is optional for implementation [LSR-MIB mplsXCTable >definition and conformance statements] > >(1) "It supports point-to-point, point-to-multipoint and >multipoint-to-point connections" [mplsXCTable description, >in LSR-MIB] > >(2) "mplsTunnelTable does not define the in and out segments > forming the tunnel. Instead, these are defined by creating > rows in the in-segment and out-segment tables, defining > relationships in the cross-connect table and referring to > these rows in the mplsTunnelTable using a cross-connect > index, mplsTunnelXCIndex. These segment and cross-connect > related objects are defined in LSRMIB." [MPLS-TE-MIB Section > 6.1] > >(3)"Uniquely identifies an instance of a tunnel. It is > useful to identify multiple instances of tunnels > for the purposes of backup and parallel tunnels." [Description > of mplsTunnelInstance in MPLS-TE-MIB] > >I interpreted the following statement: >------------------------------------- >"-cross-connect index mplsXCIndex that uniquely identifies > a group of cross-connect entries" [Description in the > mplsXCEntry] > >as: >--- >(a) cross-connect index mplsXCINdex uniquely identifies a group of > cross-connects entries, that belong to the __same LSP___. > [NOT a group of independent LSPs, as you pointed out in your > reply.] The LSR MIB exists at all points along an LSP and identifies the local in-out label swapping for any particular hop of the LSP. Remember that a tunnel exists only if at least one LSP which has been signaled to carry the traffic for that tunnel. To that end, if the XC pointer in the tunnel entry does not point to anything, then no LSP exists. What may be confusing is that each tunnel instance has one LSP per instance and that it *may* be convenient to associate a "group" of LSPs in the LSR MIB together using this primary index, but that is not mandatory. This is not necessarily mandatory, since you can have distinct XCindexes for each underlying LSP as well. >(b) The main (and only) reason for having the mplsXCIndex, is to > represent a LSP (inside the switch)with different cast types: > point-to-point point-to-multipoint and multipoint-to-point. The main point for the XCindex is to represent the cross-connection between some set of incoming labels to some set of outgoing labels. >(c) mplsTunnelXCPointer is used to associated a particular LSP > with the mpls tunnel defined in the mplsTunnelTable. Yes. >(d) Parallel tunnels are abstracted in mplsTunnelTable using the > mplsTunnelIndex and mplsTunnelInstance. Yes, but as I mentioned above, each instance needs its own LSP. --Tom From owner-mpls@UU.NET Wed Feb 14 09:54:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00637 for ; Wed, 14 Feb 2001 09:54: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 QQkcit16642; Wed, 14 Feb 2001 14:50:04 GMT Received: by mail-control.mail.uu.net id QQkcit15062 for mpls-outgoing; Wed, 14 Feb 2001 14:49: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 QQkcit15052 for ; Wed, 14 Feb 2001 14:49: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 QQkcit16364 for ; Wed, 14 Feb 2001 14:49:31 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcit15131 for ; Wed, 14 Feb 2001 14:49:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA08994 for mpls@uu.net; Wed, 14 Feb 2001 09:49: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 QQkcit15025 for ; Wed, 14 Feb 2001 14:48: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 QQkcit14004 for ; Wed, 14 Feb 2001 14:48:45 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 QQkcit09012 for ; Wed, 14 Feb 2001 14:48:45 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 GAA11826; Wed, 14 Feb 2001 06:48:34 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BFBPN>; Wed, 14 Feb 2001 06:51:33 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A6C@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" , Bob Thomas Cc: Yakov Rekhter , mpls@UU.NET Subject: RE: PID in LDP Date: Wed, 14 Feb 2001 06:51:31 -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 Eric, What about CR-LDP? Don't you think there is a need to introduce L3PID in CR-LDP if non-IP packets are being transported? Yours, -Shahram > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Wednesday, February 14, 2001 9:15 AM > To: Bob Thomas > Cc: Yakov Rekhter; mpls@UU.NET > Subject: Re: PID in LDP > > > Yakov, > > I have to agree with Bob. In the normal case for LDP, > each hop of an LSP is established for the explicit purpose > of carrying packets associated with a specific FEC. If > some enterprising individual chooses to use the LSP in > some other way, there is a strong implication of either a > pair of cooperating implementations, or a need to use > CR-LDP. In either case, there is no need to define any > new TLVs in LDP for this purpose. > > -- > Eric Gray > > Bob Thomas wrote: > > > Yakov, > > > > > Right now we have a situation where RSVP, CR-LDP) have a > mechanism (PID) > > > to identify an LSP payload, while LDP doesn't have such a > mechanism. > > > > > > Would there be any objections to add a new TLV to LDP that would > > > carry the PID information ? > > > > Would you give an example of how this TLV would be used? > > To evaluate the suggestion that a PID TLV be added it would be > > helpful to see how the information carried by the FEC TLV is > > insufficient. (Please note I am asking this question in the > > context of LDP not CR-LDP.) > > > > Thanks, > > Bob > From owner-mpls@UU.NET Wed Feb 14 10:27:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02229 for ; Wed, 14 Feb 2001 10:27: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 QQkciv16123; Wed, 14 Feb 2001 15:24:56 GMT Received: by mail-control.mail.uu.net id QQkciv00650 for mpls-outgoing; Wed, 14 Feb 2001 15:24: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 QQkciv00629 for ; Wed, 14 Feb 2001 15:24: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 QQkciv29229 for ; Wed, 14 Feb 2001 15:24:02 GMT Received: from mx4.tellabs.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx4.tellabs.com [204.68.180.54]) id QQkciv13736 for ; Wed, 14 Feb 2001 15:24:01 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAD46234; Wed, 14 Feb 2001 08:39:58 -0600 (CST) Received: from tellabs.com (dhcp-192-168-62-101.hq.tellabs.com [192.168.62.101]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA16794; Wed, 14 Feb 2001 08:38:52 -0600 (CST) Message-ID: <3A8A979B.FBA2084B@tellabs.com> Date: Wed, 14 Feb 2001 08:35:08 -0600 From: Ben Mack-Crane X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: neil.2.harrison@bt.com, kireeti@juniper.net, mpls@UU.NET Subject: Re: PHP negotiation References: <200102131426.JAA12549@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, I don't know if one could describe the OAM proposal we're working on as a "connection-oriented ITU-like scheme," but I have often found functional modeling of layered networks (defined by ITU) useful in understanding how networks work (or fail to work) in various configurations. I have even found it useful in understanding connectionless networks. It seems to me that during its evolution MPLS has developed two personas. It has a connectionless persona, exemplified by features like independent unsolicited label distribution and PHP. It also has developed a connection- oriented persona with features like LSP tunnels and VPN applications. For cases in which an LSP must have well-defined endpoints and there is a need to be able to effectively detect MPLS layer defects (e.g. mis-merging) some additional OAM features are needed. These OAM features apply to the MPLS (shim header) packet layer, not to sub-ip layers (for which similar OAM features are already defined). Regards, Ben Mack-Crane Eric Rosen wrote: > > Neil> I guess the discussion above gave enough pointers as to why an > Neil> unambiguous location of the trail termination function is important > > Well, I can say that it didn't give me a clue. Repeated unsupported claims > that it is "vital" to follow ITU architectures just aren't very persuasive. > > Are you expecting to achieve WG consensus on an OAM proposal? If the > proposal is an attempt to warp an IP-based architecture into some kind of > connection-oriented ITU-like scheme, my guess is that there is very little > chance of achieving consensus. > > Actually, I wonder if the OAM stuff falls under the charter of the CCAMP > group rather than the MPLS group. From owner-mpls@UU.NET Wed Feb 14 10:40:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02959 for ; Wed, 14 Feb 2001 10:40: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 QQkciw19650; Wed, 14 Feb 2001 15:37:35 GMT Received: by mail-control.mail.uu.net id QQkciw01837 for mpls-outgoing; Wed, 14 Feb 2001 15:37: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 QQkciw01830 for ; Wed, 14 Feb 2001 15:37: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 QQkciw08209 for ; Wed, 14 Feb 2001 15:36:34 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 QQkciw18165 for ; Wed, 14 Feb 2001 15:36:34 GMT Received: from oleane (dyn-1-1-221.Vin.dialup.oleane.fr [195.25.4.221]) by smtp4.cluster.oleane.net with SMTP id f1EFaWC20332 for ; Wed, 14 Feb 2001 16:36:32 +0100 (CET) Message-ID: <00a501c0969b$f76a25c0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: Beyond SONET/SDH Date: Wed, 14 Feb 2001 16:36:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C096A4.58DAA160" 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_00A2_01C096A4.58DAA160 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gigabit Ethernet MAN & WAN, Digital Wrapper, Resilient Packet Ring, = GMPLS : "Beyond SONET/SDH" international conference, Paris, April 10-13: http://www.upperside.fr/babeyondsdh.htm ------=_NextPart_000_00A2_01C096A4.58DAA160 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Gigabit Ethernet MAN & WAN, = Digital Wrapper,=20 Resilient Packet Ring, GMPLS : "Beyond SONET/SDH" international = conference,=20 Paris, April 10-13:
http://www.upperside.fr/= babeyondsdh.htm
 
------=_NextPart_000_00A2_01C096A4.58DAA160-- From owner-mpls@UU.NET Wed Feb 14 14:58:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15143 for ; Wed, 14 Feb 2001 14:58: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 QQkcjn17369; Wed, 14 Feb 2001 19:55:36 GMT Received: by mail-control.mail.uu.net id QQkcjn20782 for mpls-outgoing; Wed, 14 Feb 2001 19:55: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 QQkcjn20705 for ; Wed, 14 Feb 2001 19:54: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 QQkcjn05553 for ; Wed, 14 Feb 2001 19:53:14 GMT Received: from alemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQkcjn19563 for ; Wed, 14 Feb 2001 19:53:14 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA24948 for ; Wed, 14 Feb 2001 14:53:13 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA24936 for ; Wed, 14 Feb 2001 14:53:13 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA28277; Wed, 14 Feb 2001 14:53:12 -0500 (EST) Message-ID: <3A8AE227.A0E38BF4@lucent.com> Date: Wed, 14 Feb 2001 14:53:11 -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: mpls@UU.NET Subject: LSPID in ERO/ER TLV References: <200102141155.GAA09379@rhthomas-sun2.cisco.com> <3A8A92C9.F0CA07FD@sandburst.com> Content-Type: multipart/mixed; boundary="------------88E4B8FE792A724348FE4684" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------88E4B8FE792A724348FE4684 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, In the scenario as below: -------A------B-----C-------D------E------F-----G---- A,..,G are MPLS capable routers. C and E are FAs. There is a high granularity LSP between C and E, with LSP/Tunnel ID xxx. When A wants to set up another low granularity LSP from A to G, A decides to use xxx. Assuming these routers are within the same area, what should be in the ERO / TLV 1) A (strict), B (strict), C(strict), E(strict), F (strict), G(strict) or 2)A (strict), B (strict), C (strict), xxx(?), E(strict), F(strict), G(strict) Thanks, Yangguang --------------88E4B8FE792A724348FE4684 Content-Type: text/x-vcard; charset=us-ascii; name="xuyg.vcf" Content-Description: Card for Yangguang Xu Content-Disposition: attachment; filename="xuyg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Xu;Yangguang tel;fax:(978) 960 6329 tel;work:(978) 960 6105 x-mozilla-html:FALSE org:Lucent Technologies, Inc.;Advanced Optical Networking Architecture adr:;;1600 Osgood St.;N. Andover;MA;01845; version:2.1 email;internet:xuyg@lucent.com title:MTS fn:Yangguang Xu end:vcard --------------88E4B8FE792A724348FE4684-- From owner-mpls@UU.NET Wed Feb 14 16:32:23 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17285 for ; Wed, 14 Feb 2001 16:32: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 QQkcjt10647; Wed, 14 Feb 2001 21:29:36 GMT Received: by mail-control.mail.uu.net id QQkcjt26352 for mpls-outgoing; Wed, 14 Feb 2001 21:29: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 QQkcjt26347 for ; Wed, 14 Feb 2001 21:28: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 QQkcjt04666 for ; Wed, 14 Feb 2001 21:28:51 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcjt02391 for ; Wed, 14 Feb 2001 21:28:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA12045 for mpls@uu.net; Wed, 14 Feb 2001 16:28:50 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcjt26324 for ; Wed, 14 Feb 2001 21:28:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcjt06965 for ; Wed, 14 Feb 2001 21:28:14 GMT Received: from fncomr01.fnc.fujitsu.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fncomr.fnc.fujitsu.com [167.254.105.21]) id QQkcjt08670 for ; Wed, 14 Feb 2001 21:28:14 GMT Received: from timor.tddny.fujitsu.com (timor.tddny.fujitsu.com [167.254.240.106]) by fncomr01.fnc.fujitsu.com (Mirapoint) with ESMTP id ABL21852; Wed, 14 Feb 2001 15:28:11 -0600 (GMT+6) Received: from fnc.fujitsu.com ([167.254.242.159]) by timor.tddny.fujitsu.com (Netscape Messaging Server 3.6) with ESMTP id AAA33C5; Wed, 14 Feb 2001 16:28:09 -0500 Message-ID: <3A8AF866.DD73768@fnc.fujitsu.com> Date: Wed, 14 Feb 2001 16:28:06 -0500 From: "Indra Widjaja" Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Mack-Crane CC: erosen@cisco.com, neil.2.harrison@bt.com, kireeti@juniper.net, mpls@UU.NET Subject: Re: PHP negotiation References: <200102131426.JAA12549@erosen-sun.cisco.com> <3A8A979B.FBA2084B@tellabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ben and Neil: If I may get back to the technical discussion on why PHP impacts OAM ... I still don't quite understand how PHP would specifically break the behavior of your OAM proposal. Behavior 1: OAM with PHP Penultimate node pops the top label and sends an OAM packet to the ultimate node. Upon receiving the packet, the ultimate node sees an OAM alert label and forwards the packet to the local OAM engine for further processing. Behavior 2: OAM without PHP Penultimate node forwards an OAM packet without popping the top label. Upon receiving the packet, the ultimate node pops the top label. Since the next label indicates an OAM alert label, the packet is forwarded to the local OAM engine for further processing. So it looks like the OAM engine will see no difference in the two behaviors. On the other hand, it would be different if the recently popped label is saved. Appreciate your clarification. indra Ben Mack-Crane wrote: > Eric, > > I don't know if one could describe the OAM proposal we're working on as > a "connection-oriented ITU-like scheme," but I have often found functional > modeling of layered networks (defined by ITU) useful in understanding how > networks work (or fail to work) in various configurations. I have even > found it useful in understanding connectionless networks. > > It seems to me that during its evolution MPLS has developed two personas. > It has a connectionless persona, exemplified by features like independent > unsolicited label distribution and PHP. It also has developed a connection- > oriented persona with features like LSP tunnels and VPN applications. > > For cases in which an LSP must have well-defined endpoints and there is > a need to be able to effectively detect MPLS layer defects (e.g. mis-merging) > some additional OAM features are needed. These OAM features apply to the > MPLS (shim header) packet layer, not to sub-ip layers (for which similar > OAM features are already defined). > > Regards, > Ben Mack-Crane > > Eric Rosen wrote: > > > > Neil> I guess the discussion above gave enough pointers as to why an > > Neil> unambiguous location of the trail termination function is important > > > > Well, I can say that it didn't give me a clue. Repeated unsupported claims > > that it is "vital" to follow ITU architectures just aren't very persuasive. > > > > Are you expecting to achieve WG consensus on an OAM proposal? If the > > proposal is an attempt to warp an IP-based architecture into some kind of > > connection-oriented ITU-like scheme, my guess is that there is very little > > chance of achieving consensus. > > > > Actually, I wonder if the OAM stuff falls under the charter of the CCAMP > > group rather than the MPLS group. From owner-mpls@UU.NET Wed Feb 14 23:34:33 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25042 for ; Wed, 14 Feb 2001 23:34: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 QQkckw07577; Thu, 15 Feb 2001 04:31:29 GMT Received: by mail-control.mail.uu.net id QQkckw09592 for mpls-outgoing; Thu, 15 Feb 2001 04:31:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkckw09569 for ; Thu, 15 Feb 2001 04:31:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkckw21100 for ; Thu, 15 Feb 2001 04:31:03 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 QQkckw04636 for ; Thu, 15 Feb 2001 04:31:02 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 UAA13000 for ; Wed, 14 Feb 2001 20:31:15 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id XAA14557 for mpls@uu.net; Wed, 14 Feb 2001 23:31: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 QQkcie06438 for ; Wed, 14 Feb 2001 11:00: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 QQkcie25322 for ; Wed, 14 Feb 2001 11:00:14 GMT Received: from hclhprnd.hclt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hclhprnd.hclt.com [204.160.251.1]) id QQkcid10259 for ; Wed, 14 Feb 2001 10:59:40 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id QAA29592; Wed, 14 Feb 2001 16:55:18 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1ZFXSTNK; Wed, 14 Feb 2001 16:28:57 +0530 Message-ID: <000701c09675$53375890$6ee8a8c0@hclt.com> From: "Mallikarjun MLR" To: Cc: Subject: A Question in LDP mib - mplsLdpSessionXCMapTable Date: Wed, 14 Feb 2001 16:30:07 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, The LDP mib draft says: The mplsLdpSessionXCMapTable provides a way to map LDP LSPs in the LSR MIB's mplsXCTable to the LDP session which created them in this MIB's mplsLdpSessionTable. DESCRIPTION "A table of Session's Labels which are Mapped to the LSR MIB 's XConnect table. Each row represents a single cross connect." Since a cross-connect involves two LDP sessions, which session can be considered to have created an LSP. Does the mplsLdpSessionXCMapTable include In labels as well as Out labels belonging to the session? Does this mean a true cross-connect entry in mplsXCTable is mapped to two LDP sessions - one LDP session mapping to the incoming label and one mapping to the outgoing label? Thanks in Advance, Mallikarjun From owner-mpls@UU.NET Wed Feb 14 23:37:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25065 for ; Wed, 14 Feb 2001 23:37: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 QQkckw11518; Thu, 15 Feb 2001 04:32:58 GMT Received: by mail-control.mail.uu.net id QQkckw09793 for mpls-outgoing; Thu, 15 Feb 2001 04:32:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkckw09787 for ; Thu, 15 Feb 2001 04:32:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkckw21199 for ; Thu, 15 Feb 2001 04:31:05 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 QQkckw06519 for ; Thu, 15 Feb 2001 04:31:04 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 UAA29146 for ; Wed, 14 Feb 2001 20:31:21 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id XAA14561 for mpls@uu.net; Wed, 14 Feb 2001 23:31: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 QQkcjc07649 for ; Wed, 14 Feb 2001 17:05:25 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 QQkcjc17455 for ; Wed, 14 Feb 2001 17:05:11 GMT Received: from ftpbox.mot.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ftpbox.mot.com [129.188.136.101]) id QQkcjc01650 for ; Wed, 14 Feb 2001 17:05:11 GMT Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA21508 for ; Wed, 14 Feb 2001 09:30:27 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA16382 for ; Wed, 14 Feb 2001 09:30:26 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Wed, 14 Feb 2001 10:30:26 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D974@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'mpls'" Subject: MPLS on the end hosts Date: Wed, 14 Feb 2001 10:30:02 -0600 X-MS-TNEF-Correlator: <01FAF65DEA16D4119B95009027E78F3149D974@il02exm26.comm.mot.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C096A3.61401840" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C096A3.61401840 Content-Type: text/plain; charset="iso-8859-1" All, I remember having done some reading on extending MPLS all the way to the host a while ago. Has there been any interest in the working group in this area at all? If there has been a discussion in this area already, I would appreciate it if I can get pointers to that. Thanks, Vidya ------_=_NextPart_000_01C096A3.61401840 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhsQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcCAA4ACgAeAAIAAwAVAQEggAMADgAAANEHAgAO AAoAHgACAAMAFQEBCYABACEAAABBRENBMTJDRDkyMDJENTExOUJEMjAwOTAyN0U3OEYzMQAcBwEE gAEAFwAAAE1QTFMgb24gdGhlIGVuZCBob3N0cyAAYgcBDYAEAAIAAAACAAIAAQOQBgDwBgAAMQAA AAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgABgAggBgAAAAAAwAAAAAAAAEYAAAAA VIUAAAEAAAAEAAAAOC41AAsAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwADgAggBgAA AAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAASACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsA BYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABG AAAAABiFAAAAAAAAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ACoAI IAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAA AAA4hQAAAQAAAAEAAAAAAAAACwAMgAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAA2ACyAG AAAAAADAAAAAAAAARgAAAAAFiAAAAAAAAAIBCRABAAAAXwEAAFsBAACrAQAATFpGdZnRp0MDAAoA cmNwZzEyNRYyAPgLYG4OEDAzM08B9wKkA+MCAGNoCsBzsGV0MCAHEwKAfQqBknYIkHdrC4BkNAxg HmMAUAsDC7URYGxsLPMKogqASSAJcAeABtAEkE4gEPASIA8gIGQCIGWcIHMDcBXACXBhZBVSYQIg IGV4dAnwFmNNnFBMBfAHQAMgdGgVwCh3YXkYAG8YA2hvanMFQGEYQGgDEBXAYcBnby4gSGEEIBgR 3QlwIBTgCfAXwG4YcAuA/xcACXAZIQuAGAQFsBJhFXD7CcAIYHAb1AQAF8AWMRfAwxkxE+A/IElm GlUQ8E8EIBrEFYAEAGN1BBBpyxaxHTxsFjJ5LB5wHEFIdWxkF8BwcAlwY78HMBcAG0AbwR6QFHBj A5HiZxEwIHBvG1MaQRiiLx4AGgAUFBQUVBDwbmvScxQFVmkhkGEUFBHhAgAnoAAeAHAAAQAAABcA AABNUExTIG9uIHRoZSBlbmQgaG9zdHMgAAACAXEAAQAAABYAAAABwJajYTjJSHfPAo8R1b3RABCk xWP+AAALAAIAAQAAAAMA3j+vbwAAQAA5AEAYQGGjlsABAwDxPwkEAAAeADFAAQAAAAcAAABDVk4w NjUAAAMAGkAAAAAAHgAwQAEAAAAHAAAAQ1ZOMDY1AAADABlAAAAAAAMA/T/kBAAAAwAmAAAAAAAD ADYAAAAAAAMAgBD/////AgFHAAEAAAAwAAAAYz1VUzthPSA7cD1tb3Q7bD1JTDAyRVhNMjYtMDEw MjE0MTYzMDAyWi0xMTc0NzQAAgH5PwEAAABHAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAA AC9PPU1PVC9PVT1MTVBTSUwwMi9DTj1SRUNJUElFTlRTL0NOPUNWTjA2NQAAHgD4PwEAAAAXAAAA TmFyYXlhbmFuIFZpZHlhLUNWTjA2NQAAHgA4QAEAAAAHAAAAQ1ZOMDY1AAACAfs/AQAAAEcAAAAA AAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TU9UL09VPUxNUFNJTDAyL0NOPVJFQ0lQSUVO VFMvQ049Q1ZOMDY1AAAeAPo/AQAAABcAAABOYXJheWFuYW4gVmlkeWEtQ1ZOMDY1AAAeADlAAQAA AAcAAABDVk4wNjUAAEAABzAAGSYWo5bAAUAACDAAG2Rho5bAAR4APQABAAAAAQAAAAAAAAAeAB0O AQAAABcAAABNUExTIG9uIHRoZSBlbmQgaG9zdHMgAAAeADUQAQAAAEAAAAA8MDFGQUY2NURFQTE2 RDQxMTlCOTUwMDkwMjdFNzhGMzE0OUQ5NzRAaWwwMmV4bTI2LmNvbW0ubW90LmNvbT4ACwApAAAA AAALACMAAAAAAAMABhAMoK8vAwAHEOQAAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAQUxM LElSRU1FTUJFUkhBVklOR0RPTkVTT01FUkVBRElOR09ORVhURU5ESU5HTVBMU0FMTFRIRVdBWVRP VEhFSE9TVEFXSElMRUFHT0hBU1RIRVJFQkVFTkFOWUlOVEVSRVNUSQAAAAACAX8AAQAAAEAAAAA8 MDFGQUY2NURFQTE2RDQxMTlCOTUwMDkwMjdFNzhGMzE0OUQ5NzRAaWwwMmV4bTI2LmNvbW0ubW90 LmNvbT4AW00= ------_=_NextPart_000_01C096A3.61401840-- From owner-mpls@UU.NET Wed Feb 14 23:40:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25119 for ; Wed, 14 Feb 2001 23:40: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 QQkckw05761; Thu, 15 Feb 2001 04:31:41 GMT Received: by mail-control.mail.uu.net id QQkckw09610 for mpls-outgoing; Thu, 15 Feb 2001 04:31:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkckw09572 for ; Thu, 15 Feb 2001 04:31:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkckw21033 for ; Thu, 15 Feb 2001 04:31:01 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 QQkckw04578 for ; Thu, 15 Feb 2001 04:31:00 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 UAA12982 for ; Wed, 14 Feb 2001 20:31:13 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id XAA14553 for mpls@uu.net; Wed, 14 Feb 2001 23:30:58 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkchi06394 for ; Wed, 14 Feb 2001 05:37:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkchi09255 for ; Wed, 14 Feb 2001 05:37:06 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkchi05327 for ; Wed, 14 Feb 2001 05:37:05 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2650.21) id <17LBN07Y>; Tue, 13 Feb 2001 21:36:53 -0800 Message-ID: From: Vishal Sharma To: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" , "'mvissers@lucent.com'" Cc: "Ben Mack-Crane (E-mail)" , "Greg Bernstein (E-mail)" , "Bala Rajagopalan (E-mail)" , "Debanjan Saha (E-mail)" , "Michael Raftelis (E-mail)" , "Shash Chatterjee (E-mail)" , "Jeff Connell (E-mail)" , "Eric Mannie (E-mail)" Subject: FW: [IP-Optical] GMPLS enhancements Date: Tue, 13 Feb 2001 21:36:52 -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 omitted to forward my initial response to all relevant WGs, so please bear with the duplicates. I sent a duplicate on purpose, so subsequent discussion can proceed on all relevant lists (at least CCAMP and IPO). Thanks, -Vishal -----Original Message----- From: Vishal Sharma [mailto:vishal@JasmineNetworks.com] Sent: Tuesday, February 13, 2001 9:26 PM To: 'Maarten Vissers'; ip-optical@lists.bell-labs.com Cc: Ben Mack-Crane (E-mail); Greg Bernstein (E-mail); Bala Rajagopalan (E-mail); Debanjan Saha (E-mail); Michael Raftelis (E-mail); Shash Chatterjee (E-mail); Jeff Connell (E-mail); Eric Mannie (E-mail) Subject: RE: [IP-Optical] GMPLS enhancements Maarten, Thanks very much for your detailed comments and observations. Some of the discrepancies you mentioned were noted at the San Diego IETF (comments from Jurgen), and we fixed some things thereafter. However, your comments on some of the new encodings for SDH in line with the newer specifications are well-taken, and we will need some time to review what you have sent and respond to it. I have therefore forwarded your email to my co-authors (some of whom may not be on the ip-optical list), and we will try to get back to you with a response in the next week or so. (Several people are traveling this week, so we may not have a chance to discuss this before early next week.) Regards, -Vishal -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Tuesday, February 13, 2001 7:45 AM To: ip-optical@lists.bell-labs.com Subject: [IP-Optical] GMPLS enhancements Reading through draft-mack-crane-gmpls-signaling-enhancements-00.txt and draft-ietf-mpls-generalized-signaling-01.txt, I came across a number of items that do not align with SDH specifications and terminology. While it is the intention to have GMPLS as the control plane of amongst others SDH networks, it better matches the SDH specifications and terminology in my opinion. draft-ietf-mpls-generalized-signaling-01.txt ============================================ - In the G-PID table a number of entries are not supported by SDH (G.707, 10/00): 8 Bit synchronous mapping of E3 SDH 9 Byte synchronous mapping of E3 SDH 12 Byte synchronous mapping of DS2/T2 SDH Items 19,20 and 21 are already defined under items 13,14 and 15. 19 Same as 12 but in a VC-12 SDH 20 Same as 13 but in a VC-12 SDH 21 Same as 14 but in a VC-12 SDH draft-mack-crane-gmpls-signaling-enhancements-00.txt ==================================================== - In the G-PID table for SDH, the following items are not supported by SDH (G.707, 10/00): 5 Byte synchronous mapping of E3 8 Byte synchronous mapping of DS2 draft-mack-crane-gmpls-signaling-enhancements-00.txt ==================================================== - In the LSP Encoding table for ETSI-PDH, the E3 and E4 signals are defined as a single entity, suggesting a single frame format to be present. For E3 and E4 however, multiple frame formats are defined; the traditional PDH ones define in G.751 and the newer ones that can carry ATM and SDH signals (defined in G.832 and ETS 300 337). The former frame formats are identified as P31e and P4e signals, whereas the latter ones are identified as P31s and P4s signals; refer to EN 300 417-5-1 and EN 300 417-4-1. For the case the frame format is unimportant, the signals are identified as P31x, P4x (x refers to transparent transport of the bit stream). To be complete, the ETSI-PDH LSP encoding should be extended as follows: Permitted values and their meaning for LSP Encoding Type ETSI-PDH: Value Type ----- ---- 1 E1 P12x 2 E1 P12s 3 E2 P22x 4 E2 P22e 5 E3 P31x 6 E3 P31e 7 E2 P31s 8 E4 P4x 9 E4 P4e 10 E4 P4s For mapping of these ETSI-PDH signals into SDH, these distinctions might also be important; e.g. a E4 signal might be processed as a transparent bit stream in the SDH equipment, or it might be terminated and its E3 tributary signals demultiplexed, or it might be terminated and its ATM payload being extracted. Refer to EN 300 417-4-1 for the set of alternatives as reflected in the set of adaptation functions. When the technology encoding type is SDH, GPID can take the following values: Value Client Type ----- ----------- 0 Unknown 1 Asynchronous mapping of E4 P4x x Asynchronous mapping of E4 P4e x Asynchronous mapping of E4 P4s 2 Asynchronous mapping of DS3 3 Asynchronous mapping of E3 P3x x Asynchronous mapping of E3 P3e x Asynchronous mapping of E3 P3s 5 Byte synchronous mapping of E3 6 Asynchronous mapping of DS2 7 Bit synchronous mapping of DS2 8 Byte synchronous mapping of DS2 9 Asynchronous mapping of E1 P12x x Asynchronous mapping of E1 P12s 10 Byte synchronous mapping of E1 P12s 11 Byte synchronous mapping of 31 * DS0 12 Asynchronous mapping of DS1 13 Bit synchronous mapping of DS1 14 Byte synchronous mapping of DS1 15 ATM mapping draft-ietf-mpls-generalized-signaling-01.txt and draft-mack-crane-gmpls-signaling-enhancements-00.txt ==================================================== The Requested Grouping Type (RGT) defines virtual concatenation as a co-routed group. This is not supporting a major new feature in this virtual concatenation application: Link Capacity Adjustment Scheme (LCAS). LCAS is recently defined in T1X1.5 and ITU-T SG15, and is based on the fact that the signals in the virtual concatenated group are transported via multiple server layer signals (diverse routing). Refer to ftp://ftp.t1.org/T1X1/X1.0/1x100060.doc ftp://ftp.t1.org/T1X1/X1.0/1x100060.pdf The control plane for SDH/SONET should not introduce a restriction on the SDH/SONET networking functionality. As such, co-routing should not longer be associated with virtual concatenation. draft-ietf-mpls-generalized-signaling-01.txt ============================================ In section "3.2.1.1. SDH and SONET Labels", "S" is defined as: "S is the index of a particular STM-1/STS-1 signal. S=1->N indicates a specific STM-1/STS-1 inside an STM-N/STS-N multiplex. For example, S=1 indicates the first STM-1/STS-1, and S=N indicates the last STM-1/STS-1 of this multiplex. S=0 is invalid.". This specification is not aligned with SDH terminology. A STM-1 isn't a timeslot of an STM-N!!!! AU is the name of a (higher order) timeslot of a STM-N, and AUG is the name for a group of AUs. The text should therefore read as follows: "S is the index of a particular AUG-1/STS-1 signal. S=1->N indicates a specific AUG-1/STS-1 inside an STM-N/STS-N multiplex. For example, S=1 indicates the first AUG-1/STS-1, and S=N indicates the last AUG-1/STS-1 of this multiplex. S=0 is invalid." And consequently, definition of "U" must be enhanced as follows: "U is only significant for SDH and must be ignored for SONET. It indicates a specific VC inside a given AUG-1. U=1 indicates a single VC-4, while U=2->4 indicates a specific VC-3 inside the given AUG-1." Note that the latest version of G.707 (10/00) has defined a naming structure for the AU's, similar to that for the TU's. AUs are now named according the EDCBA structure (TUs are named according the KLM structure). It is thus possible to replace the S,U number by the standardised number E,D,C,B,A. The specification could be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | E | D | C | B | A | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH, this is an extension of the numbering scheme defined in G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For SONET the K field is not significant and must be set to zero. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non- significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. 1. E indicates possible branches of a STM-256/OC786. It is not meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12, STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case. E=1 indicates that the STM-256/OC768 is not further sub-divided and contains an AU-4-256c/STS768c. E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768. 2. D indicates possible branches of either an AUG-64 or a STM-64/OC192. It is not meaningful for the cases of STM-16/OC48, STM-4/OC12, STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case. D=1 indicates that the AUG-64 or STM-64/OC192 is not further sub-divided and contains an AU-4-64c/STS192c. D=2->5 indicates a specific AUG-16 inside the given AUG-64 or STM-64/OC192. 3. C indicates possible branches of either an AUG-16 or a STM-16/OC48. It is not meaningful for the cases of STM-4/OC12, STM-1/OC3, STM-0/OC1 multiplexing and must be 0 in that case. C=1 indicates that the AUG-16 or STM-16/OC48 is not further sub-divided and contains an AU-4-16c/STS48c. C=2->5 indicates a specific AUG-4 inside the given AUG-16 or STM-16/OC48. 4. B indicates possible branches of either an AUG-4 or a STM-4/OC12. It is not meaningful for the cases of STM-1/OC3, STM-0/OC1 multiplexing and must be 0 in that case. B=1 indicates that the AUG-4 or STM-4/OC12 is not further sub-divided and contains an AU-4-4c/STS12c. B=2->5 indicates a specific AUG-1 inside the given AUG-4 or STM-4/OC12. 5. A indicates possible branches of either an AUG-1 or a STM-1/OC3. It is not meaningful for the case of STM-0/OC1 multiplexing and must be 0 in that case. A=1 indicates that the AUG-1 or STM-1/OC3 is not further sub-divided and contains an AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given AUG-1 or STM-1/OC3. 6. K is only significant for SDH and must be ignored for SONET. It indicates a specific branch of a VC-4. K=1 indicates that the VC-4 is not further sub-divided and contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-4. K is not significant when the STM-1 is divided into VC-3s (easy to read and test). 7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further sub-divided and contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. 8. M indicates a specific branch of a TUG-2/VT Group. It is not significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. M=1 indicates that the TUG-2/VT Group is not further sub-divided and contains a VC-2/VT-6. M=2->3 indicates a specific VT-3 inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the corresponding TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried within a TU-11. M=11->13 indicates a specific VC-11 inside the corresponding TUG-2 carried within a TU-12. Note that M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). Some examples: EDCBAKLM - 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0) in a STM-16/OC48 - 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768 - 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0) in a STM-256/OC768 - 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192 - 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal. The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3) structure in a STM-16 could then consist of the following set of labels: EDCBAKLM - 00210000 AU-4-4c (1,0,0) - 00321000 AU-4 (2,1,0) - 00331000 AU-4 (2,2,0) - 00341000 AU-4 (2,3,0) - 00351000 AU-4 (2,4,0) - 00410000 AU-4-4c (3,0,0) - 00521000 AU-4 (4,1,0) - 00532000 AU-3 (4,2,1) - 00533000 AU-3 (4,2,2) - 00534000 AU-3 (4,2,3) - 00541000 AU-4 (4,3,0) - 00551000 AU-4 (4,4,0) For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering scheme has the bandwidth implied. There is no need to code this bandwidth seperately anylonger. Question related to the definition of "M": ------------------------------------------ "M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to transport a VC-11 via a TU-12, I believe that the M range should be extended with values 11 to 13 as follows: The M encoding is summarized in the following table: M SDH SONET ---------------------------------------------------------- 0 unstructured VC-4/VC-3 unstructured STS-1 SPE 1 VC-2 VT-6 2 - 1st VT-3 3 - 2nd VT-3 4 1st VC-12 1st VT-2 5 2nd VC-12 2nd VT-2 6 3rd VC-12 3rd VT-2 7 1st VC-11 in TU-11 1st VT-1.5 8 2nd VC-11 in TU-11 2nd VT-1.5 9 3rd VC-11 in TU-11 3rd VT-1.5 10 4th VC-11 in TU-11 4th VT-1.5 11 1st VC-11 in TU-12 - 12 2nd VC-11 in TU-12 - 13 3rd VC-11 in TU-12 - At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive monitors) as a VC-12. At the path endpoints however, the VC-11 is treated as a VC-11. Coding the lower order VC (LOVC)/VT signals: -------------------------------------------- SDH ADM and cross connect equipment may have separate Higher Order and Lower Order fabrics. This decouples the TU identification from the AU timeslot and associated physical port. I.e. EDCBAKLM label should be split into separate EDCBA and KLM labels. Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M" VC4 termination points connected to the LO Fabric. The TU timeslots are defined with reference to a VC4 termination point. The VC4 signal geenrated by a VC4 termination point can be transported over any of the STM-N signals; there is no predefined relationship, neither is there a permanent relationship (i.e. it is possible to re-route the VC-4 without tearing it down, or tearing down the LOVC connection over it). As such, the TU timeslots should be numbered with respect to its VC4 termination point, not with respect to the AU4 timeslot in an STM-N; The AU4/STM-N part of the label may change over time, whereas the TU link connection and TU connection point stay the same. Resulting label should be "". STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO FABRIC signal PORT timeslots | | Term. timeslots | | Points per VC4 TP | | STM-N --- PHY --- "N" AU -------| | timeslots | STM-N --- PHY --- "N" AU ----------| timeslots Figure 1 - SDH ADM with separate HO and LO Fabrics The HO Fabric contains the relation between AU number and VC4 TP number, as well as between between two AU numbers (case of STM-N - AU - STM-N connection). <-- phys. <--- EDCBA <--- VC4 <--- KLM port AU TP TU number number number number STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO FABRIC signal PORT timeslots | | Term. timeslots | | Points per VC4 TP Figure 2 - numbering Regards, Maarten _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Feb 14 23:50:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25391 for ; Wed, 14 Feb 2001 23:50: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 QQkckx19709; Thu, 15 Feb 2001 04:47:27 GMT Received: by mail-control.mail.uu.net id QQkckx11405 for mpls-outgoing; Thu, 15 Feb 2001 04:46:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkckx11391 for ; Thu, 15 Feb 2001 04:46:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkckx26996 for ; Thu, 15 Feb 2001 04:46:21 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkckx28832 for ; Thu, 15 Feb 2001 04:46:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA03638 for mpls@uu.net; Wed, 14 Feb 2001 23:46: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 QQkckx11214 for ; Thu, 15 Feb 2001 04:45:52 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 QQkckx12455 for ; Thu, 15 Feb 2001 04:45:17 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkckx23602 for ; Thu, 15 Feb 2001 04:45:15 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA21299; Wed, 14 Feb 2001 20:45:14 -0800 (PST) Received: from volsung.pluris.com.pluris.com (localhost [127.0.0.1]) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id UAA11837; Wed, 14 Feb 2001 20:45:37 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14987.24305.302275.114266@volsung.pluris.com> Date: Wed, 14 Feb 2001 20:45:37 -0800 To: Narayanan Vidya-CVN065 Cc: "'mpls'" Subject: Re: MPLS on the end hosts In-Reply-To: <01FAF65DEA16D4119B95009027E78F3149D974@il02exm26.comm.mot.com> References: <01FAF65DEA16D4119B95009027E78F3149D974@il02exm26.comm.mot.com> X-Mailer: VM 6.90 under Emacs 20.3.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit That would be as popular as ATM to the desktop I am sure. MPLS does not provide a global address space and there is no socket layer for it either. Bora >>>>> "Narayanan" == Narayanan Vidya-CVN065 writes: Narayanan> All, I remember having done some reading on Narayanan> extending MPLS all the way to the host a while Narayanan> ago. Has there been any interest in the working Narayanan> group in this area at all? If there has been a Narayanan> discussion in this area already, I would Narayanan> appreciate it if I can get pointers to that. Narayanan> Thanks, Vidya From owner-mpls@UU.NET Thu Feb 15 01:19:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28680 for ; Thu, 15 Feb 2001 01:19: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 QQkclc24259; Thu, 15 Feb 2001 06:12:36 GMT Received: by mail-control.mail.uu.net id QQkclc16197 for mpls-outgoing; Thu, 15 Feb 2001 06:12: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 QQkclc16183 for ; Thu, 15 Feb 2001 06:12: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 QQkclc09430 for ; Thu, 15 Feb 2001 06:11:31 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkclc10972 for ; Thu, 15 Feb 2001 06:11:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA08379 for mpls@uu.net; Thu, 15 Feb 2001 01:11:29 -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 QQkclc16006 for ; Thu, 15 Feb 2001 06:11:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkclc09638 for ; Thu, 15 Feb 2001 06:10:12 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 QQkclc08022 for ; Thu, 15 Feb 2001 06:10:11 GMT Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id WAA25596; Wed, 14 Feb 2001 22:10:23 -0800 (PST) Received: from jlawrenc-pc.cisco.com ([64.104.86.66]) by bulkrate.cisco.com (Mirapoint) with ESMTP id AEP05579; Wed, 14 Feb 2001 22:10:06 -0800 (PST) Message-Id: <4.3.2.7.2.20010215164620.00b14860@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Feb 2001 17:09:52 +1100 To: Narayanan Vidya-CVN065 From: Jeremy Lawrence Subject: Re: MPLS on the end hosts Cc: "'mpls'" In-Reply-To: <01FAF65DEA16D4119B95009027E78F3149D974@il02exm26.comm.mot. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 10:30 02/14/2001 -0600, Narayanan Vidya-CVN065 wrote: >All, >I remember having done some reading on extending MPLS all the way to the host a while ago. Has there been any interest in the working group in this area at all? Not for a few years. :) There was a thought that high-performance servers would benefit from connecting directly into an MPLS network without an intervening eLSR. Leaving aside the wisdom or practicality (or otherwise) of such a capability, it could be achieved by putting a full eLSR stack on the host. The working group has already defined the eLSR stack, so that sort of host support has effectively been defined. If 'MPLS to the host' means something else, then it is not obvious that there is any real benefit from it (as Bora points out). Jeremy Lawrence From owner-mpls@UU.NET Thu Feb 15 05:03:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12158 for ; Thu, 15 Feb 2001 05:03: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 QQkclr00938; Thu, 15 Feb 2001 09:59:30 GMT Received: by mail-control.mail.uu.net id QQkclr17349 for mpls-outgoing; Thu, 15 Feb 2001 09:58: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 QQkclr17341 for ; Thu, 15 Feb 2001 09:58: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 QQkclr08643 for ; Thu, 15 Feb 2001 09:57:17 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 QQkclr27320 for ; Thu, 15 Feb 2001 09:57:17 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Thu, 15 Feb 2001 09:57:03 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id <1PC3Z7QS>; Thu, 15 Feb 2001 09:57:26 -0000 Message-ID: To: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: PHP negotiation Date: Thu, 15 Feb 2001 09:57:32 -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 Indra, From a quick analysis I think you are right (Ben and Shahram may wish to confirm this). However, this is a fortuitous consequence rather than a planned one, ie a lack of protocol ID in the normal labelled header forces one to create a special bottom-of-stack OAM alert label, and so increase the label stack by + 1, thereby fortuitously negating the effect of PHP. However, PHP must not be allowed on the OAM alert labelled header. Neil > -----Original Message----- > From: Indra Widjaja [mailto:Indra.Widjaja@fnc.fujitsu.com] > Sent: 14 February 2001 21:28 > To: Ben Mack-Crane > Cc: erosen@cisco.com; neil.2.harrison@bt.com; kireeti@juniper.net; > mpls@UU.NET > Subject: Re: PHP negotiation > > > Hi Ben and Neil: > > If I may get back to the technical discussion on why PHP > impacts OAM ... > > I still don't quite understand how PHP would specifically > break the behavior > of your OAM proposal. > > Behavior 1: OAM with PHP > Penultimate node pops the top label and sends an OAM packet > to the ultimate node. > Upon receiving the packet, the ultimate node sees an OAM > alert label and > forwards the packet to the local OAM engine for further processing. > > Behavior 2: OAM without PHP > Penultimate node forwards an OAM packet without popping the top label. > Upon receiving the packet, the ultimate node pops the top label. > Since the next label indicates an OAM alert label, the packet > is forwarded > to the local OAM engine for further processing. > > So it looks like the OAM engine will see no difference in the > two behaviors. > On the other hand, it would be different if the recently > popped label is saved. > Appreciate your clarification. > > indra > > > Ben Mack-Crane wrote: > > > Eric, > > > > I don't know if one could describe the OAM proposal we're > working on as > > a "connection-oriented ITU-like scheme," but I have often > found functional > > modeling of layered networks (defined by ITU) useful in > understanding how > > networks work (or fail to work) in various configurations. > I have even > > found it useful in understanding connectionless networks. > > > > It seems to me that during its evolution MPLS has developed > two personas. > > It has a connectionless persona, exemplified by features > like independent > > unsolicited label distribution and PHP. It also has > developed a connection- > > oriented persona with features like LSP tunnels and VPN > applications. > > > > For cases in which an LSP must have well-defined endpoints > and there is > > a need to be able to effectively detect MPLS layer defects > (e.g. mis-merging) > > some additional OAM features are needed. These OAM > features apply to the > > MPLS (shim header) packet layer, not to sub-ip layers (for > which similar > > OAM features are already defined). > > > > Regards, > > Ben Mack-Crane > > > > Eric Rosen wrote: > > > > > > Neil> I guess the discussion above gave enough > pointers as to why an > > > Neil> unambiguous location of the trail termination > function is important > > > > > > Well, I can say that it didn't give me a clue. Repeated > unsupported claims > > > that it is "vital" to follow ITU architectures just > aren't very persuasive. > > > > > > Are you expecting to achieve WG consensus on an OAM > proposal? If the > > > proposal is an attempt to warp an IP-based architecture > into some kind of > > > connection-oriented ITU-like scheme, my guess is that > there is very little > > > chance of achieving consensus. > > > > > > Actually, I wonder if the OAM stuff falls under the > charter of the CCAMP > > > group rather than the MPLS group. > From owner-mpls@UU.NET Thu Feb 15 05:43:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12320 for ; Thu, 15 Feb 2001 05:43: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 QQkclu09159; Thu, 15 Feb 2001 10:41:18 GMT Received: by mail-control.mail.uu.net id QQkclu04828 for mpls-outgoing; Thu, 15 Feb 2001 10:41:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkclu04823 for ; Thu, 15 Feb 2001 10:41:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkclu07534 for ; Thu, 15 Feb 2001 10:40:06 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkclu24068 for ; Thu, 15 Feb 2001 10:40:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA18157 for mpls@uu.net; Thu, 15 Feb 2001 05:40: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 QQkclu04748 for ; Thu, 15 Feb 2001 10:39: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 QQkclu17516 for ; Thu, 15 Feb 2001 10:39:14 GMT Received: from coltrane.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQkclu18163 for ; Thu, 15 Feb 2001 10:39:13 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Feb 2001 10:39:06 -0000 Message-ID: <37701240971DD31193970000F6CCB9F70125D586@duke.datcon.co.uk> From: Edward Harrison To: "'mpls@uu.net'" Subject: Question on correct response to invalid LDP initialize messages Date: Thu, 15 Feb 2001 10:39:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a question regarding the correct response to an LDP initialize message which is missing the Common Session Parms TLV. RFC 3036 states that upon receipt of an unacceptable initialization message, an Error Notification should be sent to the peer. Section 2.5.3 states that the notification should contain a status TLV indicating which parameters are in error. Section 3.9 defines specific status codes to cover the label advertisement mode, max PDU length and label ranges being invalid. I was wondering what status code should be used if the entire Common Session Parms TLV is missing. The obvious choice would seem to be the Missing Message Parameters status code, however this is listed in section 9 as being a non-fatal error (i.e. E bit is set to 0), but obviously an invalid initialize message will be fatal. Another option would be to use the Bad Message Length status code (as without the Common Session Parms TLV the Initialization message is effectively of an invalid size). This is listed as a fatal error. What is the correct status code here? Does anyone know what status code existing implementations of LDP use in this scenario? Thanks very much, Ed ---------------- Ed Harrison Network Convergence Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8366 5084 Email: eph@dataconnection.com Web:http://www.dataconnection.com From owner-mpls@UU.NET Thu Feb 15 08:49:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17062 for ; Thu, 15 Feb 2001 08:49: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 QQkcmh07483; Thu, 15 Feb 2001 13:46:47 GMT Received: by mail-control.mail.uu.net id QQkcmh01136 for mpls-outgoing; Thu, 15 Feb 2001 13:46: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 QQkcmh01127 for ; Thu, 15 Feb 2001 13:46:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcmh09118 for ; Thu, 15 Feb 2001 13:45:58 GMT Received: from atila.ar.logical.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [200.51.165.8]) id QQkcmh13670 for ; Thu, 15 Feb 2001 13:45:53 GMT Received: from hermes.ar.logical.com ([10.1.0.240]) by atila.ar.logical.com (8.9.3/8.9.3) with ESMTP id KAA06615 for ; Thu, 15 Feb 2001 10:45:16 -0300 Received: by hermes.ar.logical.com with Internet Mail Service (5.5.2650.21) id <1N0G75K5>; Thu, 15 Feb 2001 10:42:24 -0300 Message-ID: <96CD4BAC2E4A6A408056FE8E6C6AF2E7048C92@hermes.ar.logical.com> From: LOPEZ Miguel Angel To: "'mpls@uu.net'" Subject: Aggregate label Date: Thu, 15 Feb 2001 10:42:24 -0300 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, Please, could somebody explain what means an aggregate label and how it works? TIA From owner-mpls@UU.NET Thu Feb 15 09:58:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19704 for ; Thu, 15 Feb 2001 09:58: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 QQkcml20515; Thu, 15 Feb 2001 14:55:57 GMT Received: by mail-control.mail.uu.net id QQkcml21619 for mpls-outgoing; Thu, 15 Feb 2001 14:55:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcml21587 for ; Thu, 15 Feb 2001 14:55:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcml06199 for ; Thu, 15 Feb 2001 14:54:32 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcml03920 for ; Thu, 15 Feb 2001 14:54:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA01185 for mpls@uu.net; Thu, 15 Feb 2001 09:54:30 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcml21510 for ; Thu, 15 Feb 2001 14:54:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcml29663 for ; Thu, 15 Feb 2001 14:51:56 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 QQkcml12768 for ; Thu, 15 Feb 2001 14:51:55 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 GAA23023; Thu, 15 Feb 2001 06:51:22 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BFXC4>; Thu, 15 Feb 2001 06:47:57 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A7E@BBY1EXM01> From: Shahram Davari To: "'neil.2.harrison@bt.com'" , Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com Cc: mpls@UU.NET Subject: RE: PHP negotiation Date: Thu, 15 Feb 2001 06:50:56 -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 Indra, I should also add that, after a PHP, the egress can not uniquely identify the LSP that the OAM packet belongs to. And that is why we have proposed to duplicate the user-label below the OAM label. If there was no PHP, there was no need to duplicate the user-label label. Yours, -Shahram > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, February 15, 2001 4:58 AM > To: Indra.Widjaja@fnc.fujitsu.com; Ben.Mack-Crane@tellabs.com; Shahram > Davari > Cc: mpls@UU.NET > Subject: RE: PHP negotiation > > > Hi Indra, > > From a quick analysis I think you are right (Ben and Shahram > may wish to > confirm this). However, this is a fortuitous consequence > rather than a > planned one, ie a lack of protocol ID in the normal labelled > header forces > one to create a special bottom-of-stack OAM alert label, and > so increase the > label stack by + 1, thereby fortuitously negating the effect of PHP. > However, PHP must not be allowed on the OAM alert labelled header. > > Neil > > -----Original Message----- > > From: Indra Widjaja [mailto:Indra.Widjaja@fnc.fujitsu.com] > > Sent: 14 February 2001 21:28 > > To: Ben Mack-Crane > > Cc: erosen@cisco.com; neil.2.harrison@bt.com; kireeti@juniper.net; > > mpls@UU.NET > > Subject: Re: PHP negotiation > > > > > > Hi Ben and Neil: > > > > If I may get back to the technical discussion on why PHP > > impacts OAM ... > > > > I still don't quite understand how PHP would specifically > > break the behavior > > of your OAM proposal. > > > > Behavior 1: OAM with PHP > > Penultimate node pops the top label and sends an OAM packet > > to the ultimate node. > > Upon receiving the packet, the ultimate node sees an OAM > > alert label and > > forwards the packet to the local OAM engine for further processing. > > > > Behavior 2: OAM without PHP > > Penultimate node forwards an OAM packet without popping the > top label. > > Upon receiving the packet, the ultimate node pops the top label. > > Since the next label indicates an OAM alert label, the packet > > is forwarded > > to the local OAM engine for further processing. > > > > So it looks like the OAM engine will see no difference in the > > two behaviors. > > On the other hand, it would be different if the recently > > popped label is saved. > > Appreciate your clarification. > > > > indra > > > > > > Ben Mack-Crane wrote: > > > > > Eric, > > > > > > I don't know if one could describe the OAM proposal we're > > working on as > > > a "connection-oriented ITU-like scheme," but I have often > > found functional > > > modeling of layered networks (defined by ITU) useful in > > understanding how > > > networks work (or fail to work) in various configurations. > > I have even > > > found it useful in understanding connectionless networks. > > > > > > It seems to me that during its evolution MPLS has developed > > two personas. > > > It has a connectionless persona, exemplified by features > > like independent > > > unsolicited label distribution and PHP. It also has > > developed a connection- > > > oriented persona with features like LSP tunnels and VPN > > applications. > > > > > > For cases in which an LSP must have well-defined endpoints > > and there is > > > a need to be able to effectively detect MPLS layer defects > > (e.g. mis-merging) > > > some additional OAM features are needed. These OAM > > features apply to the > > > MPLS (shim header) packet layer, not to sub-ip layers (for > > which similar > > > OAM features are already defined). > > > > > > Regards, > > > Ben Mack-Crane > > > > > > Eric Rosen wrote: > > > > > > > > Neil> I guess the discussion above gave enough > > pointers as to why an > > > > Neil> unambiguous location of the trail termination > > function is important > > > > > > > > Well, I can say that it didn't give me a clue. Repeated > > unsupported claims > > > > that it is "vital" to follow ITU architectures just > > aren't very persuasive. > > > > > > > > Are you expecting to achieve WG consensus on an OAM > > proposal? If the > > > > proposal is an attempt to warp an IP-based architecture > > into some kind of > > > > connection-oriented ITU-like scheme, my guess is that > > there is very little > > > > chance of achieving consensus. > > > > > > > > Actually, I wonder if the OAM stuff falls under the > > charter of the CCAMP > > > > group rather than the MPLS group. > > > From owner-mpls@UU.NET Thu Feb 15 10:04:37 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19898 for ; Thu, 15 Feb 2001 10:04: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 QQkcmm01565; Thu, 15 Feb 2001 15:00:53 GMT Received: by mail-control.mail.uu.net id QQkcmm23440 for mpls-outgoing; Thu, 15 Feb 2001 15:00:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcmm23274 for ; Thu, 15 Feb 2001 15:00:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcml18290 for ; Thu, 15 Feb 2001 14:58:59 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 QQkcml24311 for ; Thu, 15 Feb 2001 14:58: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 GAA26869; Thu, 15 Feb 2001 06:59:13 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA15143; Thu, 15 Feb 2001 09:58:55 -0500 (EST) Message-Id: <200102151458.JAA15143@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: PID in LDP In-reply-to: Your message of Tue, 13 Feb 2001 15:17:18 -0500. <3A89964E.67B454D8@marconi.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 Feb 2001 09:58:54 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> My only concern is that unsolicited label allocation of multiple L3 David> protocols would quickly lead to an unmanageable number of labels. David> Instead of sending out mappings for every FEC, you're now sending them David> out for every legal combination of FEC and L3 protocol. This could David> easily overrun an LSR's capabilities. Especially if the edge routers David> know about a large number of protocols. I agree 100%. Right now the same "top label" could be used for carrying regular IP traffic, for carrying L3VPN traffic, and for carrying emulated circuit traffic. The distinction is made, as necessary, after the top label is popped. It's hard to see what is gained by a scheme that doubles or triples the number of labels used (and the signalling to distribute them), while providing no additional functionality. The "VC type" FEC TLV in draft-martini-... isn't really a PID; I would say it carries information about the kind of PE-CE circuit that is being transported, rather than about the payload of the packets. The real use of that is to indicate whether some kind of interworking function (protocol translation) is needed in order to make the circuit operational. I don't think this could be replaced by a PID. For example, the "VC type" might be used to indicate that one side of a circuit is PPPoE, and the other is "plain" PPP. I don't think this could be eliminated in favor of a PID value associated with the top label. From owner-mpls@UU.NET Thu Feb 15 10:07:20 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20036 for ; Thu, 15 Feb 2001 10:07: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 QQkcmm18030; Thu, 15 Feb 2001 15:04:09 GMT Received: by mail-control.mail.uu.net id QQkcmm00314 for mpls-outgoing; Thu, 15 Feb 2001 15:03:45 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 QQkcmm00257 for ; Thu, 15 Feb 2001 15:03:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcmm29214 for ; Thu, 15 Feb 2001 15:03:24 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 QQkcmm06057 for ; Thu, 15 Feb 2001 15:03: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 HAA00186; Thu, 15 Feb 2001 07:03:39 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA15161; Thu, 15 Feb 2001 10:03:21 -0500 (EST) Message-Id: <200102151503.KAA15161@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'neil.2.harrison@bt.com'" , Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, mpls@UU.NET Subject: Re: PHP negotiation In-reply-to: Your message of Thu, 15 Feb 2001 06:50:56 -0800. <9DC5E2ABE65BD54CA9088DA3194461D6037A6A7E@BBY1EXM01> 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: Thu, 15 Feb 2001 10:03:21 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk So PHP doesn't make OAM impossible after all! I guess I'm not surprised. Shahram> after a PHP, the egress can not uniquely identify the LSP that the Shahram> OAM packet belongs to. You haven't forgotten that LSPs are multipoint-to-point, have you? Do you have a way to tell where the OAM came from? From owner-mpls@UU.NET Thu Feb 15 10:32:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20746 for ; Thu, 15 Feb 2001 10:32:34 -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 QQkcmn02678; Thu, 15 Feb 2001 15:29:36 GMT Received: by mail-control.mail.uu.net id QQkcmn09198 for mpls-outgoing; Thu, 15 Feb 2001 15:29: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 QQkcmn09193 for ; Thu, 15 Feb 2001 15:28: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 QQkcmn02862 for ; Thu, 15 Feb 2001 15:27:35 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkcmn08927 for ; Thu, 15 Feb 2001 15:27:35 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13601 for ; Thu, 15 Feb 2001 10:27: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 KAA24838 for ; Thu, 15 Feb 2001 10:27:35 -0500 (EST) Message-ID: <3A8BF581.E3EB1085@marconi.com> Date: Thu, 15 Feb 2001 10:28:01 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PID in LDP References: <200102151458.JAA15143@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen wrote: >> >> My only concern is that unsolicited label allocation of multiple L3 >> protocols would quickly lead to an unmanageable number of labels. >> Instead of sending out mappings for every FEC, you're now sending >> them out for every legal combination of FEC and L3 protocol. This >> could easily overrun an LSR's capabilities. Especially if the edge >> routers know about a large number of protocols. > > I agree 100%. > > Right now the same "top label" could be used for carrying regular IP > traffic, for carrying L3VPN traffic, and for carrying emulated > circuit traffic. The distinction is made, as necessary, after the top > label is popped. It's hard to see what is gained by a scheme that > doubles or triples the number of labels used (and the signalling to > distribute them), while providing no additional functionality. Please don't quote my words out of context. Especially if you're using them to advocate a position opposite to mine. My comment about label explosion has nothing to do with whether L3PID is encoded into a second-level label or via a new TLV. My concern is with automatic generation of LSPs for protocols other than IP. There is no problem with label explosion if LSPs for non-IP protocols must be explicitly requested by ingress nodes. I happen to prefer the situation where the L3PID is signalled during LSP creation. It allows the transit routers to know what's inside the LSP. The router can therefore pop the last label and forward the traffic unlabeled, or insert it into a different LSP - an impossibility if there is a label underneath that is encoding a protocol instead of a destination. In section 3.22 of RFC 3031 (MPLS Architecture), a router that doesn't yet have an NHLFE can choose to pop the label stack if it can forward the content correctly. Obviously, knowledge of the L3PID is a requirement if it is going to be able to do this - otherwise it wouldn't know where to look for the L3 destination address. -- David From owner-mpls@UU.NET Thu Feb 15 10:46:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21142 for ; Thu, 15 Feb 2001 10: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 QQkcmo20586; Thu, 15 Feb 2001 15:43:37 GMT Received: by mail-control.mail.uu.net id QQkcmo10730 for mpls-outgoing; Thu, 15 Feb 2001 15:42:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcmo10707 for ; Thu, 15 Feb 2001 15:42:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcmo21884 for ; Thu, 15 Feb 2001 15:41:52 GMT Received: from mx4.tellabs.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx4.tellabs.com [204.68.180.54]) id QQkcmo13889 for ; Thu, 15 Feb 2001 15:41:52 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAD61408; Thu, 15 Feb 2001 09:34:34 -0600 (CST) Received: from tellabs.com (cis1host5.bb.tellabs.com [172.16.51.5]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA18521; Thu, 15 Feb 2001 09:33:25 -0600 (CST) Message-ID: <3A8BF5E2.633BD625@tellabs.com> Date: Thu, 15 Feb 2001 09:29:39 -0600 From: Ben Mack-Crane X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'neil.2.harrison@bt.com'" , Indra.Widjaja@fnc.fujitsu.com, mpls@UU.NET Subject: Re: PHP negotiation References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A7E@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Indra, I think the real issue here is that one needs to know the user-label for the LSP over which the OAM packet is received in order to be able to detect connectivity defects (e.g. mis-merging) and to do performance monitoring. If the user label is popped before reaching the LSP termination point, the OAM processor at the termination point has no way of knowing on which LSP a connectivity verification packet was received. If the trace ID is wrong, it is impossible to determine which LSP has the mismerging defect. Similarly, for performance monitoring the egress must count packets received on a particular LSP to compare that number with the count in an OAM performance packet. If the user-label is PHP'ed, the egress router cannot count packets for that LSP. Regards, Ben Shahram Davari wrote: > > Hi Indra, > > I should also add that, after a PHP, the egress can not uniquely identify the LSP that the OAM packet belongs to. And that is why we have proposed to duplicate the user-label below the OAM label. If there was no PHP, there was no need to duplicate the user-label label. > > Yours, > -Shahram > > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Thursday, February 15, 2001 4:58 AM > > To: Indra.Widjaja@fnc.fujitsu.com; Ben.Mack-Crane@tellabs.com; Shahram > > Davari > > Cc: mpls@UU.NET > > Subject: RE: PHP negotiation > > > > > > Hi Indra, > > > > From a quick analysis I think you are right (Ben and Shahram > > may wish to > > confirm this). However, this is a fortuitous consequence > > rather than a > > planned one, ie a lack of protocol ID in the normal labelled > > header forces > > one to create a special bottom-of-stack OAM alert label, and > > so increase the > > label stack by + 1, thereby fortuitously negating the effect of PHP. > > However, PHP must not be allowed on the OAM alert labelled header. > > > > Neil > > > -----Original Message----- > > > From: Indra Widjaja [mailto:Indra.Widjaja@fnc.fujitsu.com] > > > Sent: 14 February 2001 21:28 > > > To: Ben Mack-Crane > > > Cc: erosen@cisco.com; neil.2.harrison@bt.com; kireeti@juniper.net; > > > mpls@UU.NET > > > Subject: Re: PHP negotiation > > > > > > > > > Hi Ben and Neil: > > > > > > If I may get back to the technical discussion on why PHP > > > impacts OAM ... > > > > > > I still don't quite understand how PHP would specifically > > > break the behavior > > > of your OAM proposal. > > > > > > Behavior 1: OAM with PHP > > > Penultimate node pops the top label and sends an OAM packet > > > to the ultimate node. > > > Upon receiving the packet, the ultimate node sees an OAM > > > alert label and > > > forwards the packet to the local OAM engine for further processing. > > > > > > Behavior 2: OAM without PHP > > > Penultimate node forwards an OAM packet without popping the > > top label. > > > Upon receiving the packet, the ultimate node pops the top label. > > > Since the next label indicates an OAM alert label, the packet > > > is forwarded > > > to the local OAM engine for further processing. > > > > > > So it looks like the OAM engine will see no difference in the > > > two behaviors. > > > On the other hand, it would be different if the recently > > > popped label is saved. > > > Appreciate your clarification. > > > > > > indra > > > > > > > > > Ben Mack-Crane wrote: > > > > > > > Eric, > > > > > > > > I don't know if one could describe the OAM proposal we're > > > working on as > > > > a "connection-oriented ITU-like scheme," but I have often > > > found functional > > > > modeling of layered networks (defined by ITU) useful in > > > understanding how > > > > networks work (or fail to work) in various configurations. > > > I have even > > > > found it useful in understanding connectionless networks. > > > > > > > > It seems to me that during its evolution MPLS has developed > > > two personas. > > > > It has a connectionless persona, exemplified by features > > > like independent > > > > unsolicited label distribution and PHP. It also has > > > developed a connection- > > > > oriented persona with features like LSP tunnels and VPN > > > applications. > > > > > > > > For cases in which an LSP must have well-defined endpoints > > > and there is > > > > a need to be able to effectively detect MPLS layer defects > > > (e.g. mis-merging) > > > > some additional OAM features are needed. These OAM > > > features apply to the > > > > MPLS (shim header) packet layer, not to sub-ip layers (for > > > which similar > > > > OAM features are already defined). > > > > > > > > Regards, > > > > Ben Mack-Crane > > > > > > > > Eric Rosen wrote: > > > > > > > > > > Neil> I guess the discussion above gave enough > > > pointers as to why an > > > > > Neil> unambiguous location of the trail termination > > > function is important > > > > > > > > > > Well, I can say that it didn't give me a clue. Repeated > > > unsupported claims > > > > > that it is "vital" to follow ITU architectures just > > > aren't very persuasive. > > > > > > > > > > Are you expecting to achieve WG consensus on an OAM > > > proposal? If the > > > > > proposal is an attempt to warp an IP-based architecture > > > into some kind of > > > > > connection-oriented ITU-like scheme, my guess is that > > > there is very little > > > > > chance of achieving consensus. > > > > > > > > > > Actually, I wonder if the OAM stuff falls under the > > > charter of the CCAMP > > > > > group rather than the MPLS group. > > > > > From owner-mpls@UU.NET Thu Feb 15 11:01:39 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21576 for ; Thu, 15 Feb 2001 11:01: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 QQkcmp07206; Thu, 15 Feb 2001 15:58:37 GMT Received: by mail-control.mail.uu.net id QQkcmp12600 for mpls-outgoing; Thu, 15 Feb 2001 15:58:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcmp12591 for ; Thu, 15 Feb 2001 15:57:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcmp21083 for ; Thu, 15 Feb 2001 15:57:17 GMT Received: from femail2.sdc1.sfba.home.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail2.sdc1.sfba.home.com [24.0.95.82]) id QQkcmp27818 for ; Thu, 15 Feb 2001 15:57:14 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010215155651.HRZL6538.femail2.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Thu, 15 Feb 2001 07:56:51 -0800 Message-ID: <0f5c01c097cc$46cf7ee0$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "Ben Mack-Crane" , "Shahram Davari" Cc: , , References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A7E@BBY1EXM01> <3A8BF5E2.633BD625@tellabs.com> Subject: Re: PHP negotiation Date: Thu, 15 Feb 2001 19:55:17 -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 ----- Original Message ----- From: "Ben Mack-Crane" . > > If the user label is popped before reaching the LSP termination point, the > OAM processor at the termination point has no way of knowing on which LSP > a connectivity verification packet was received. If the trace ID is wrong, > it is impossible to determine which LSP has the mismerging defect. > > Similarly, for performance monitoring the egress must count packets received > on a particular LSP to compare that number with the count in an OAM performance > packet. If the user-label is PHP'ed, the egress router cannot count packets for > that LSP. > > PHP is signaled by the ultimate/egress node to the penultimate node. If OAM requires that per LSP work is to be done at the egress node and so one needs the top label to demultiplex at the egress node, why should one think of enabling PHP? Isn't this egress initiated PHP negotiation. If the egress itself doesn't want penultimate node to pop the top level, then why in the first place initiate the PHP negotiation? May be I missed some discussion. But it looks very trivial to me that not using PHP feature is a simple way of out this. -Manohar From owner-mpls@UU.NET Thu Feb 15 11:25:02 2001 Received: from cmr2.ash.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 LAA22288 for ; Thu, 15 Feb 2001 11:25: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 QQkcmr04324; Thu, 15 Feb 2001 16:22:22 GMT Received: by mail-control.mail.uu.net id QQkcmr28832 for mpls-outgoing; Thu, 15 Feb 2001 16:21:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcmr28815 for ; Thu, 15 Feb 2001 16:21:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcmr23792 for ; Thu, 15 Feb 2001 16:21:34 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 QQkcmr02078 for ; Thu, 15 Feb 2001 16:21:33 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAD61511; Thu, 15 Feb 2001 09:39:44 -0600 (CST) Received: from tellabs.com (cis1host5.bb.tellabs.com [172.16.51.5]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA22117; Thu, 15 Feb 2001 09:38:35 -0600 (CST) Message-ID: <3A8BF718.F687F23C@tellabs.com> Date: Thu, 15 Feb 2001 09:34:48 -0600 From: Ben Mack-Crane X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Shahram Davari , "'neil.2.harrison@bt.com'" , Indra.Widjaja@fnc.fujitsu.com, mpls@UU.NET Subject: Re: PHP negotiation References: <200102151503.KAA15161@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, There are some issues with PHP (see my reply to Indra). We haven't forgotten that LSPs may be multipoint-to-point, but this case presents some interesting challenges (as you know). We have not addressed the multipoint-to-point case yet, in favor of trying to complete a simple and useable OAM for the point-to-point case. Regards, Ben Eric Rosen wrote: > > So PHP doesn't make OAM impossible after all! I guess I'm not surprised. > > Shahram> after a PHP, the egress can not uniquely identify the LSP that the > Shahram> OAM packet belongs to. > > You haven't forgotten that LSPs are multipoint-to-point, have you? Do you > have a way to tell where the OAM came from? From owner-mpls@UU.NET Thu Feb 15 11:30:02 2001 Received: from cmr2.ash.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 LAA22389 for ; Thu, 15 Feb 2001 11:30: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 QQkcmr18248; Thu, 15 Feb 2001 16:27:21 GMT Received: by mail-control.mail.uu.net id QQkcmr29683 for mpls-outgoing; Thu, 15 Feb 2001 16:26:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcmr29657 for ; Thu, 15 Feb 2001 16:26:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcmr06571 for ; Thu, 15 Feb 2001 16:26:21 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 QQkcmr15432 for ; Thu, 15 Feb 2001 16:26:21 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 IAA05958; Thu, 15 Feb 2001 08:26:36 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA15497; Thu, 15 Feb 2001 11:26:18 -0500 (EST) Message-Id: <200102151626.LAA15497@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: PID in LDP In-reply-to: Your message of Thu, 15 Feb 2001 10:28:01 -0500. <3A8BF581.E3EB1085@marconi.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 Feb 2001 11:26:18 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> Please don't quote my words out of context. Especially if you're David> using them to advocate a position opposite to mine. My apologies, I guess I didn't fully understand you, there was no intention to misrepresent. David> There is no problem with label explosion if LSPs for non-IP protocols David> must be explicitly requested by ingress nodes. Well, the PID would have to distinguish VPN IP packets from non-VPN IP packets as well, if you hope to rely on the PID to determine whether intermediate nodes can extract and properly process the payload. It seems to me that label explosion occurs whether the LSPs are set up in an unsolicited manner or whether they are set up explicitly. You must be assuming that the number of labels needed to represent VPN or layer 2 tunnels is just a small fraction of the total number of labels per node. Why would you assume that? From owner-mpls@UU.NET Thu Feb 15 11:35:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22550 for ; Thu, 15 Feb 2001 11:35:36 -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 QQkcms04241; Thu, 15 Feb 2001 16:33:01 GMT Received: by mail-control.mail.uu.net id QQkcms00960 for mpls-outgoing; Thu, 15 Feb 2001 16:32: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 QQkcms00951 for ; Thu, 15 Feb 2001 16:32: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 QQkcms08316 for ; Thu, 15 Feb 2001 16:31:24 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 QQkcms23970 for ; Thu, 15 Feb 2001 16:31:23 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Thu, 15 Feb 2001 16:27:35 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <11T27F5C>; Thu, 15 Feb 2001 16:27:41 -0000 Message-ID: To: ellanti@home.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com Cc: neil.2.harrison@bt.com, Indra.Widjaja@fnc.fujitsu.com, mpls@UU.NET Subject: RE: PHP negotiation Date: Thu, 15 Feb 2001 16:27:29 -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 Manohar Ellanti [mailto:ellanti@home.com] wrote on 16 February 2001 03:55 > > PHP is signaled by the ultimate/egress node to the > penultimate node. If OAM > requires that per LSP work is to be done at the egress node > and so one needs > the top label to demultiplex at the egress node, why should > one think of > enabling PHP? Isn't this egress initiated PHP negotiation. > If the egress > itself doesn't want penultimate node to pop the top level, > then why in the > first place initiate the PHP negotiation? May be I missed > some discussion. > But it looks very trivial to me that not using PHP feature is > a simple way > of out this. > NH=> Yes it is......this is the obvious solution. Alternatively, and as Shahram pointed out, if we capture the orginal source 4 octet labelled header in the OAM payload (or the CV or P pkt) then we can still make the association. From owner-mpls@UU.NET Thu Feb 15 11:37:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22625 for ; Thu, 15 Feb 2001 11:37: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 QQkcms28777; Thu, 15 Feb 2001 16:34:58 GMT Received: by mail-control.mail.uu.net id QQkcms01332 for mpls-outgoing; Thu, 15 Feb 2001 16:34: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 QQkcms01276 for ; Thu, 15 Feb 2001 16:34:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcms17246 for ; Thu, 15 Feb 2001 16:34:03 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 QQkcms24511 for ; Thu, 15 Feb 2001 16:34:02 GMT Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Thu, 15 Feb 2001 16:27:00 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <1RBRHFTK>; Thu, 15 Feb 2001 16:27:43 -0000 Message-ID: To: erosen@cisco.com, Shahram_Davari@pmc-sierra.com Cc: neil.2.harrison@bt.com, Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, mpls@UU.NET Subject: RE: PHP negotiation Date: Thu, 15 Feb 2001 16:27:30 -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 Eric Rosen [mailto:erosen@cisco.com] wrote on 15 February 2001 15:03 > > So PHP doesn't make OAM impossible after all! I guess I'm > not surprised. > Shahram> after a PHP, the egress can not uniquely identify > the LSP that the > Shahram> OAM packet belongs to. > > You haven't forgotten that LSPs are multipoint-to-point, > have you? NH=> The scope of the work is targetted at important LSPs that are pt-pt, usually set-up via ER signalling. So the work is not targeted at plain LDP LSPs....however, if you/Cisco have some possible OAM solutions here Eric I would be very happy to review them for you. >Do you have a way to tell where the OAM came from? NH=> In our case yes...its the Trail Termination Source Identifier, which is composed of a source LSR address + a tunnel ID. What do you/Cisco do here (for both pt-pt case and the mpt-pt case)? From owner-mpls@UU.NET Thu Feb 15 11:46:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22911 for ; Thu, 15 Feb 2001 11:46: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 QQkcms11725; Thu, 15 Feb 2001 16:44:05 GMT Received: by mail-control.mail.uu.net id QQkcms02331 for mpls-outgoing; Thu, 15 Feb 2001 16:43:33 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 QQkcms02313 for ; Thu, 15 Feb 2001 16:43: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 QQkcms29283 for ; Thu, 15 Feb 2001 16:41:35 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkcms08382 for ; Thu, 15 Feb 2001 16:41:34 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f1FGfPV22814; Thu, 15 Feb 2001 11:41:25 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; THU, 15 Feb 2001 11:39:40 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Feb 2001 11:39:39 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E56993D00@newman.tenornet.com> From: "Shah, Himanshu" To: nbvpn@bbo.com Cc: kireeti@juniper.net, mpls@UU.NET Subject: L2VPN (kompella) issue Date: Thu, 15 Feb 2001 11:39:34 -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 It seems that when processing cross-connects dynamically, as described by Kompella draft, there is a greater need of MPLS OAM (or some type of NNI) type of functionality. You need this to prevent data loss due to asynchronous nature of cross-connect programing occuring at local and remote PE. For example, if local PE (as a DCE) programs the cross-connect and reports DLCI active to CE (as DTE), CE would start propagating data through that DLCI. However, remote PE may not have programed the cross-connects yet. I do understand that this might not be a problem during initial setup (inverse ARP discovering IP addr or some other client server not being able to discover each other). However, this might become issue for restarts (e.g. due to BGP session loss), if not for IP, may be for other protocols (its layer 2 circuit after all). It especially does become an issue if CE devices are frame relay switches. If other people think this to be an issue, we should address that in the draft Any comments?? Himanshu Shah Tenor networks Acton, MA PS. Sorry for distribution to both the lists, but nbvpn list is very sluggish for some reasons. Himanshu Shah Tenor Networks Acton, MA From owner-mpls@UU.NET Thu Feb 15 11:52:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23040 for ; Thu, 15 Feb 2001 11:52: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 QQkcmt20418; Thu, 15 Feb 2001 16:49:42 GMT Received: by mail-control.mail.uu.net id QQkcmt03112 for mpls-outgoing; Thu, 15 Feb 2001 16:49: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 QQkcmt03103 for ; Thu, 15 Feb 2001 16:49:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcmt23742 for ; Thu, 15 Feb 2001 16:48:50 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcmt17946 for ; Thu, 15 Feb 2001 16:48:49 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA15194 for mpls@uu.net; Thu, 15 Feb 2001 11:48: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 QQkcmt03041 for ; Thu, 15 Feb 2001 16:48: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 QQkcmt03716 for ; Thu, 15 Feb 2001 16:47:36 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 QQkcmt24413 for ; Thu, 15 Feb 2001 16:47:30 GMT Received: from timor.tddny.fujitsu.com (timor.tddny.fujitsu.com [167.254.240.106]) by fncomr02.fnc.fujitsu.com (Mirapoint) with ESMTP id ABV02924; Thu, 15 Feb 2001 10:47:14 -0600 (GMT+6) Received: from fnc.fujitsu.com ([167.254.242.159]) by timor.tddny.fujitsu.com (Netscape Messaging Server 3.6) with ESMTP id AAA4F5D; Thu, 15 Feb 2001 11:47:11 -0500 Message-ID: <3A8C0808.89FC527E@fnc.fujitsu.com> Date: Thu, 15 Feb 2001 11:47:04 -0500 From: "Indra Widjaja" Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Manohar Ellanti CC: Ben Mack-Crane , Shahram Davari , neil.2.harrison@bt.com, mpls@UU.NET Subject: Re: PHP negotiation References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A7E@BBY1EXM01> <3A8BF5E2.633BD625@tellabs.com> <0f5c01c097cc$46cf7ee0$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 Manohar Ellanti wrote: > ----- Original Message ----- > From: "Ben Mack-Crane" > . > > > > If the user label is popped before reaching the LSP termination point, the > > OAM processor at the termination point has no way of knowing on which LSP > > a connectivity verification packet was received. If the trace ID is > wrong, > > it is impossible to determine which LSP has the mismerging defect. > > > > Similarly, for performance monitoring the egress must count packets > received > > on a particular LSP to compare that number with the count in an OAM > performance > > packet. If the user-label is PHP'ed, the egress router cannot count > packets for > > that LSP. > > > > > PHP is signaled by the ultimate/egress node to the penultimate node. If OAM > requires that per LSP work is to be done at the egress node and so one needs > the top label to demultiplex at the egress node, why should one think of > enabling PHP? Isn't this egress initiated PHP negotiation. If the egress > itself doesn't want penultimate node to pop the top level, then why in the > first place initiate the PHP negotiation? May be I missed some discussion. > But it looks very trivial to me that not using PHP feature is a simple way > of out this. Manohar: The issue is not when you have the option to use or not use PHP. But, when you have to use PHP, would it make OAM impossible to implement. indra From owner-mpls@UU.NET Thu Feb 15 11:52:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23069 for ; Thu, 15 Feb 2001 11:52: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 QQkcmt19907; Thu, 15 Feb 2001 16:49:45 GMT Received: by mail-control.mail.uu.net id QQkcmt03129 for mpls-outgoing; Thu, 15 Feb 2001 16:49: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 QQkcmt03117 for ; Thu, 15 Feb 2001 16:49:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcmt09421 for ; Thu, 15 Feb 2001 16:49:15 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcmt27817 for ; Thu, 15 Feb 2001 16:49:14 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA13861 for mpls@uu.net; Thu, 15 Feb 2001 11:38: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 QQkcms01701 for ; Thu, 15 Feb 2001 16:37: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 QQkcms15413 for ; Thu, 15 Feb 2001 16:37:32 GMT Received: from slim.equipecom.com. by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: slim.equipecom.com [209.6.39.131]) id QQkcms16877 for ; Thu, 15 Feb 2001 16:37:29 GMT Received: from eccexch01.equipecom.com (eccexch01.equipecom.com [172.17.1.11]) by slim.equipecom.com. (8.11.0/8.11.0) with ESMTP id f1FGbOD11168 for ; Thu, 15 Feb 2001 11:37:24 -0500 (EST) Received: by eccexch01.equipecom.com with Internet Mail Service (5.5.2650.21) id <1Z7WXZNM>; Thu, 15 Feb 2001 11:37:19 -0500 Message-ID: From: Michael Oh To: "'mpls@UU.NET'" Subject: unsubscribe Date: Thu, 15 Feb 2001 11:37:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk unsubscribe From owner-mpls@UU.NET Thu Feb 15 11:54:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23147 for ; Thu, 15 Feb 2001 11:54: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 QQkcmt27706; Thu, 15 Feb 2001 16:52:13 GMT Received: by mail-control.mail.uu.net id QQkcmt03348 for mpls-outgoing; Thu, 15 Feb 2001 16:51:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcmt03327 for ; Thu, 15 Feb 2001 16:51:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcmt19957 for ; Thu, 15 Feb 2001 16:50:02 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 QQkcmt20469 for ; Thu, 15 Feb 2001 16:50:01 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26673 for ; Thu, 15 Feb 2001 11:49:59 -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 LAA23697 for ; Thu, 15 Feb 2001 11:50:01 -0500 (EST) Message-ID: <3A8C08D3.FBCFD900@marconi.com> Date: Thu, 15 Feb 2001 11:50:27 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PID in LDP References: <200102151626.LAA15497@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen wrote: > > It seems to me that label explosion occurs whether the LSPs are set up > in an unsolicited manner or whether they are set up explicitly. You > must be assuming that the number of labels needed to represent VPN or > layer 2 tunnels is just a small fraction of the total number of labels > per node. Who said anything about VPN? You know as well as I do that a private address is meningless outside of its own network. If a transient condition would cause such a packet to hit a router without an NHLFE, there's no way the packet is going to be forwarded, no matter how it's encoded. I explicitly said that a PID field is needed for non-IP traffic. This is not an IP packet with a private address being tunneled across a public network. There are two uses for non-IP traffic I can think of: 1: Streaming data (like voice). It makes sense for media server or media gateway to strip off as much overhead as possible (like IP headers) and just send the PCM (or MPEG, or H.323, or whatever) stream directly in the LSP. A transit router won't be able to forward these packets without the labels, since there's no address information in the data stream, but it will be able to identify the traffic as something that is not routable. Of course, this is really not applicable for LDP, but CR-LDP, since some level of QoS will be desired for these applications. I doubt customers would be happy if this traffic was treated like all other traffic to the destination. Yes, DiffServ and the EXP bits can be used, but not everyone is going to support DS, and DS may not provide the required granularity. (Imagine 20 different streams, each with a different QoS requirement?) In this situation, you're not changing the potential for label explosion, because a customer in this scenario is going to have to be using CR-LDP and L-LSPs anyway. Tacking on an extra TLV so that the content can be identified is not a big deal. 2: Legacy LAN traffic. If someone wants to connect two legagy Netware (or Appletalk, etc.) servers across the internet, it would be nicer to pass the packets in an LSP instead of tunneling them through IP. A transit router may know how to route these. (Probably not in an ISP core, but possibly in an enterprise network.) I can't imagine this being a large amount of traffic, however. -- David From owner-mpls@UU.NET Thu Feb 15 12:37:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24817 for ; Thu, 15 Feb 2001 12:37: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 QQkcmw28727; Thu, 15 Feb 2001 17:34:24 GMT Received: by mail-control.mail.uu.net id QQkcmw22789 for mpls-outgoing; Thu, 15 Feb 2001 17:33:51 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 QQkcmw22767 for ; Thu, 15 Feb 2001 17:33: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 QQkcmw18379 for ; Thu, 15 Feb 2001 17:33:15 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcmw04140 for ; Thu, 15 Feb 2001 17:33:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA19825 for mpls@uu.net; Thu, 15 Feb 2001 12:33:14 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcms01800 for ; Thu, 15 Feb 2001 16:38:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcms08735 for ; Thu, 15 Feb 2001 16:38:23 GMT Received: from fncomr02.fnc.fujitsu.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fncomr.fnc.fujitsu.com [167.254.105.20]) id QQkcms03952 for ; Thu, 15 Feb 2001 16:38:22 GMT Received: from timor.tddny.fujitsu.com (timor.tddny.fujitsu.com [167.254.240.106]) by fncomr02.fnc.fujitsu.com (Mirapoint) with ESMTP id ABV02594; Thu, 15 Feb 2001 10:38:07 -0600 (GMT+6) Received: from fnc.fujitsu.com ([167.254.242.159]) by timor.tddny.fujitsu.com (Netscape Messaging Server 3.6) with ESMTP id AAA4A2F; Thu, 15 Feb 2001 11:38:05 -0500 Message-ID: <3A8C05E6.CDC18AAA@fnc.fujitsu.com> Date: Thu, 15 Feb 2001 11:37:58 -0500 From: "Indra Widjaja" Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Mack-Crane CC: Shahram Davari , "'neil.2.harrison@bt.com'" , mpls@UU.NET Subject: Re: PHP negotiation References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A7E@BBY1EXM01> <3A8BF5E2.633BD625@tellabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ben Mack-Crane wrote: > Hello Indra, > > I think the real issue here is that one needs to know the user-label for the > LSP over which the OAM packet is received in order to be able to detect > connectivity defects (e.g. mis-merging) and to do performance monitoring. > > If the user label is popped before reaching the LSP termination point, the > OAM processor at the termination point has no way of knowing on which LSP > a connectivity verification packet was received. If the trace ID is wrong, > it is impossible to determine which LSP has the mismerging defect. > > Similarly, for performance monitoring the egress must count packets received > on a particular LSP to compare that number with the count in an OAM performance > packet. If the user-label is PHP'ed, the egress router cannot count packets for > that LSP. Ben: If you meant that the egress router needs to count *user* packets for that LSP, then I agree that PHP must be avoided. indra From owner-mpls@UU.NET Thu Feb 15 12:41:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25013 for ; Thu, 15 Feb 2001 12:41: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 QQkcmw12135; Thu, 15 Feb 2001 17:38:24 GMT Received: by mail-control.mail.uu.net id QQkcmw23336 for mpls-outgoing; Thu, 15 Feb 2001 17:38:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcmw23311 for ; Thu, 15 Feb 2001 17:37:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcmw17936 for ; Thu, 15 Feb 2001 17:37:24 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkcmw02448 for ; Thu, 15 Feb 2001 17:37:24 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id C53F294006; Thu, 15 Feb 2001 12:37:18 -0500 (EST) Message-ID: <3A8C13CE.231F1895@sandburst.com> Date: Thu, 15 Feb 2001 12:37:18 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: PID in LDP References: <200102151626.LAA15497@erosen-sun.cisco.com> <3A8C08D3.FBCFD900@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, First: I fail to see why you have demonstrated a real need to tell intermediate LSRs what kind of traffic they are forwarding on a specific LSP. It seems to me that you need only to indicate if the packets are something that the intermediate LSR might know how to forward or not. Since you stipulate that you would only need to be able to make this distinction when using CR-LDP, then this is only needed for CR-LDP. CR-LDP defines a FEC which carries the meaning you seek. So, what else do you need? Second: Have you looked at proposals for transporting compressed headers over MPLS? With such an approach, it is difficult to see what the real advantage is in omitting the IP header when transporting data via an LSP. -- Eric GRAY (please note the last name :-) You wrote: > Eric Rosen wrote: > > > > It seems to me that label explosion occurs whether the LSPs are set up > > in an unsolicited manner or whether they are set up explicitly. You > > must be assuming that the number of labels needed to represent VPN or > > layer 2 tunnels is just a small fraction of the total number of labels > > per node. > > Who said anything about VPN? You know as well as I do that a private > address is meningless outside of its own network. If a transient > condition would cause such a packet to hit a router without an NHLFE, > there's no way the packet is going to be forwarded, no matter how it's > encoded. > > I explicitly said that a PID field is needed for non-IP traffic. This > is not an IP packet with a private address being tunneled across a > public network. > > There are two uses for non-IP traffic I can think of: > > 1: Streaming data (like voice). > > It makes sense for media server or media gateway to strip off as > much overhead as possible (like IP headers) and just send the PCM > (or MPEG, or H.323, or whatever) stream directly in the LSP. > > A transit router won't be able to forward these packets without the > labels, since there's no address information in the data stream, but > it will be able to identify the traffic as something that is not > routable. > > Of course, this is really not applicable for LDP, but CR-LDP, since > some level of QoS will be desired for these applications. I doubt > customers would be happy if this traffic was treated like all other > traffic to the destination. > > Yes, DiffServ and the EXP bits can be used, but not everyone is > going to support DS, and DS may not provide the required > granularity. (Imagine 20 different streams, each with a different > QoS requirement?) > > In this situation, you're not changing the potential for label > explosion, because a customer in this scenario is going to have to > be using CR-LDP and L-LSPs anyway. Tacking on an extra TLV so that > the content can be identified is not a big deal. > > 2: Legacy LAN traffic. > > If someone wants to connect two legagy Netware (or Appletalk, etc.) > servers across the internet, it would be nicer to pass the packets > in an LSP instead of tunneling them through IP. A transit router > may know how to route these. (Probably not in an ISP core, but > possibly in an enterprise network.) > > I can't imagine this being a large amount of traffic, however. > > -- David From owner-mpls@UU.NET Thu Feb 15 12:45:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25131 for ; Thu, 15 Feb 2001 12:45: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 QQkcmw19191; Thu, 15 Feb 2001 17:42:55 GMT Received: by mail-control.mail.uu.net id QQkcmw24051 for mpls-outgoing; Thu, 15 Feb 2001 17:42: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 QQkcmw24024 for ; Thu, 15 Feb 2001 17:42: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 QQkcmw00609 for ; Thu, 15 Feb 2001 17:42:09 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 QQkcmw15253 for ; Thu, 15 Feb 2001 17:42:08 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA21184; Thu, 15 Feb 2001 09:42:08 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id JAA77527; Thu, 15 Feb 2001 09:42:08 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102151742.JAA77527@garnet.juniper.net> To: Eric Gray cc: mpls@UU.NET Subject: Re: PID in LDP In-Reply-To: Your message of "Thu, 15 Feb 2001 12:37:18 EST." <3A8C13CE.231F1895@sandburst.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77524.982258928.1@garnet.juniper.net> Date: Thu, 15 Feb 2001 09:42:08 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Eric, > David, > > First: > > I fail to see why you have demonstrated a real need to > tell intermediate LSRs what kind of traffic they are forwarding > on a specific LSP. > > It seems to me that you need only to indicate if the packets > are something that the intermediate LSR might know how to > forward or not. Since you stipulate that you would only need > to be able to make this distinction when using CR-LDP, then > this is only needed for CR-LDP. Please recall the discussion ~1 month ago on the subject of handling TTL=0 in the "shim" header by the intermediate LSRs. Yakov. From owner-mpls@UU.NET Thu Feb 15 12:54:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25528 for ; Thu, 15 Feb 2001 12:54: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 QQkcmx02979; Thu, 15 Feb 2001 17:51:45 GMT Received: by mail-control.mail.uu.net id QQkcmx25482 for mpls-outgoing; Thu, 15 Feb 2001 17:51: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 QQkcmx25458 for ; Thu, 15 Feb 2001 17:51:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcmx28765 for ; Thu, 15 Feb 2001 17:50:47 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkcmx01471 for ; Thu, 15 Feb 2001 17:50:47 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Thu, 15 Feb 2001 17:51:04 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id <1PC36T10>; Thu, 15 Feb 2001 17:50:13 -0000 Message-ID: To: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com Cc: Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: PHP negotiation Date: Thu, 15 Feb 2001 17:50:05 -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 > If you meant that the egress router needs to count *user* > packets for that LSP, > then I agree that PHP must be avoided. > > indra > Indra....look at the details on P flows I sent you. Further, Shahram has extended the basic ideas in a good survey of variations on the basic P flow theme.....we need to choose one though yet. Note - when I originally proposed the P flow it was as a simple 1st line diagnostic tool for Ops people and not a full-blown QoS metric analysis tool; and as currently envisaged, it simply counts the (cummulative) lost pkts/octets over some period T. So it would be used in ad hoc mode as an adjunct to the basic (defect detection/handling) CV flow as/when needed, but not full time......its costs to measure/collect metrics, so you should only do it when needed. In any network one needs at least 4 types of perf measures: - simple OAM to aid Ops people and to protect customers traffic, eg security issues.....key in-service metric is availability, QoS are metrics are dependent on getting availability stuff right 1st; - ad hoc sampling of detailed QoS metrics, eg using probes, to get a feel for the population behaviour/trends and to detect otherwise latent faults; - nodal/link utilisation trends, eg for TE and inputs to planning/design cycle; - UPC discard/re-classification activity Our work clearly only addresses the 1st of these items. As regards packet/octet loss metrics however, these could also be counted by doing so at both ingress and egress (ie no need for P flow....a P flow just allows this to be done at one end, the sink). There are some inaccuracy issues with 'pkts in flight' and the synchronisation of the 2 ends (ie so they relate to the same T period). However, as T->large these inaccuracies will decrease as a %. As regards the PHP issue wrt P flows.....we are still OK for the reason Shahram pointed out a few mails back, since we intend to put the orginal 4 octet labelled header (ie outgoing from the LSP source LSR) in both CV and P OAM pkt payloads. So, fortuitously rather than by design (due to need for 2 label stacking forced by having no protocol ID field), we can actually identify which LSP the P flow should be associated with even with PHP (of top label only). neil From owner-mpls@UU.NET Thu Feb 15 12:57:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25611 for ; Thu, 15 Feb 2001 12:57: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 QQkcmx08100; Thu, 15 Feb 2001 17:54:54 GMT Received: by mail-control.mail.uu.net id QQkcmx26046 for mpls-outgoing; Thu, 15 Feb 2001 17:54:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcmx26035 for ; Thu, 15 Feb 2001 17:54:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcmx20932 for ; Thu, 15 Feb 2001 17:54:21 GMT Received: from mx4.tellabs.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx4.tellabs.com [204.68.180.54]) id QQkcmx08960 for ; Thu, 15 Feb 2001 17:54:20 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAD63984; Thu, 15 Feb 2001 11:37:27 -0600 (CST) Received: from tellabs.com (cis1host13.bb.tellabs.com [172.16.51.13]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA02324; Thu, 15 Feb 2001 11:36:17 -0600 (CST) Message-ID: <3A8C12AF.CA5150F@tellabs.com> Date: Thu, 15 Feb 2001 11:32:31 -0600 From: Ben Mack-Crane X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Manohar Ellanti CC: Shahram Davari , neil.2.harrison@bt.com, Indra.Widjaja@fnc.fujitsu.com, mpls@UU.NET Subject: Re: PHP negotiation References: <0f5c01c097cc$46cf7ee0$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 Manohar, You're right, of course. I was trying to follow the thread of the discussion and failed to notice that it had circled around, in a sense. If the egress LSR supports OAM (i.e., the ability to pop a label header, recognise the OAM header, and do OAM processing) then it would not need (or want) to request PHP -- so the question is moot from that perspective. Regards, Ben Manohar Ellanti wrote: > > ----- Original Message ----- > From: "Ben Mack-Crane" > . > > > > If the user label is popped before reaching the LSP termination point, the > > OAM processor at the termination point has no way of knowing on which LSP > > a connectivity verification packet was received. If the trace ID is > wrong, > > it is impossible to determine which LSP has the mismerging defect. > > > > Similarly, for performance monitoring the egress must count packets > received > > on a particular LSP to compare that number with the count in an OAM > performance > > packet. If the user-label is PHP'ed, the egress router cannot count > packets for > > that LSP. > > > > > PHP is signaled by the ultimate/egress node to the penultimate node. If OAM > requires that per LSP work is to be done at the egress node and so one needs > the top label to demultiplex at the egress node, why should one think of > enabling PHP? Isn't this egress initiated PHP negotiation. If the egress > itself doesn't want penultimate node to pop the top level, then why in the > first place initiate the PHP negotiation? May be I missed some discussion. > But it looks very trivial to me that not using PHP feature is a simple way > of out this. > > -Manohar From owner-mpls@UU.NET Thu Feb 15 13:07:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25849 for ; Thu, 15 Feb 2001 13:07: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 QQkcmy22820; Thu, 15 Feb 2001 18:03:42 GMT Received: by mail-control.mail.uu.net id QQkcmy03023 for mpls-outgoing; Thu, 15 Feb 2001 18:03:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcmy02953 for ; Thu, 15 Feb 2001 18:03:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcmy18492 for ; Thu, 15 Feb 2001 18:02: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 QQkcmy18046 for ; Thu, 15 Feb 2001 18:02:02 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05576 for ; Thu, 15 Feb 2001 13:02:00 -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 NAA13333 for ; Thu, 15 Feb 2001 13:02:03 -0500 (EST) Message-ID: <3A8C19B5.7074BFE3@marconi.com> Date: Thu, 15 Feb 2001 13:02:29 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PID in LDP References: <200102151626.LAA15497@erosen-sun.cisco.com> <3A8C08D3.FBCFD900@marconi.com> <3A8C13CE.231F1895@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > I fail to see why you have demonstrated a real need to tell > intermediate LSRs what kind of traffic they are forwarding on a > specific LSP. > > It seems to me that you need only to indicate if the packets are > something that the intermediate LSR might know how to forward or not. > Since you stipulate that you would only need to be able to make this > distinction when using CR-LDP, then this is only needed for CR-LDP. I stipulate that streaming media applications only make sense over CR-LDP. But there is a second category of non-IP traffic, namely legacy LAN traffic. While an ISP core network won't be seeing this (except as part of a VPN connection), an enterprise network might. In such a situation, merely knowing whether or not the packet can be routed isn't enough. The router also has to know what the packet is, so it can locate appropriate addressing information. I realize that most MPLS work is focussing on ISP core networks, but you shouldn't assume that those are the only networks that will ever want to use it. An optional TLV to carry L3PID information isn't a big deal. > CR-LDP defines a FEC which carries the meaning you seek. Where? I just re-read it again and didn't find this. > Second: > > Have you looked at proposals for transporting compressed headers > over MPLS? With such an approach, it is difficult to see what the > real advantage is in omitting the IP header when transporting data via > an LSP. The means of encapsulating streaming data in an LSP I mentioned is just an example. I did not mean to suggest it as the way things should be done. -- David > David Charlap wrote: >> Eric Rosen wrote: >>> >>> It seems to me that label explosion occurs whether the LSPs are set >>> up in an unsolicited manner or whether they are set up explicitly. >>> You must be assuming that the number of labels needed to represent >>> VPN or layer 2 tunnels is just a small fraction of the total number >>> of labels per node. >> >> Who said anything about VPN? You know as well as I do that a private >> address is meningless outside of its own network. If a transient >> condition would cause such a packet to hit a router without an NHLFE, >> there's no way the packet is going to be forwarded, no matter how >> it's encoded. >> >> I explicitly said that a PID field is needed for non-IP traffic. >> This is not an IP packet with a private address being tunneled across >> a public network. >> >> There are two uses for non-IP traffic I can think of: >> >> 1: Streaming data (like voice). >> >> It makes sense for media server or media gateway to strip off as >> much overhead as possible (like IP headers) and just send the PCM >> (or MPEG, or H.323, or whatever) stream directly in the LSP. >> >> A transit router won't be able to forward these packets without >> the labels, since there's no address information in the data >> stream, but it will be able to identify the traffic as something >> that is not routable. >> >> Of course, this is really not applicable for LDP, but CR-LDP, >> since some level of QoS will be desired for these applications. I >> doubt customers would be happy if this traffic was treated like >> all other traffic to the destination. >> >> Yes, DiffServ and the EXP bits can be used, but not everyone is >> going to support DS, and DS may not provide the required >> granularity. (Imagine 20 different streams, each with a different >> QoS requirement?) >> >> In this situation, you're not changing the potential for label >> explosion, because a customer in this scenario is going to have to >> be using CR-LDP and L-LSPs anyway. Tacking on an extra TLV so >> that the content can be identified is not a big deal. >> >> 2: Legacy LAN traffic. >> >> If someone wants to connect two legagy Netware (or Appletalk, >> etc.) servers across the internet, it would be nicer to pass the >> packets in an LSP instead of tunneling them through IP. A transit >> router may know how to route these. (Probably not in an ISP core, >> but possibly in an enterprise network.) >> >> I can't imagine this being a large amount of traffic, however. From owner-mpls@UU.NET Thu Feb 15 13:12:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26049 for ; Thu, 15 Feb 2001 13:12: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 QQkcmy06477; Thu, 15 Feb 2001 18:09:49 GMT Received: by mail-control.mail.uu.net id QQkcmy11520 for mpls-outgoing; Thu, 15 Feb 2001 18:09:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcmy11406 for ; Thu, 15 Feb 2001 18:09:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcmy04161; Thu, 15 Feb 2001 18:08:21 GMT Received: from exchange-west.photuris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.3.135.228]) id QQkcmy27371; Thu, 15 Feb 2001 18:08:20 GMT Received: by EXCHANGE-WEST with Internet Mail Service (5.5.2650.21) id <1V0Y17ZV>; Thu, 15 Feb 2001 09:56:58 -0800 Message-ID: <2350AC684549D41193CA00D0B773E84F0850B6@EXCHANGE-WEST> From: Xipeng Xiao To: mpls@UU.NET, ip-optical@lists.bell-labs.com, "'te-wg@uu.net'" Subject: CSI 2001: Call for papers Date: Thu, 15 Feb 2001 09:56:57 -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 You are cordially invited to submit a paper to an invited session of: "The 5th World Multi-Conference on Systemics, Cybernetics and Informatics" (http://www.iiis.org/sci/). July 22-25, 2001, Orlando, Florida USA, Sheraton World Resort The theme of this invited session is: "New Technologies and Important issues in the Internet", which include but not limited to the following topics: * MPLS and MPLambdaS * Traffic Engineering * QoS * VPN * Circuit Emulation or Circuit Cross-Connect * Optical Networking * MAN * Content distribution network and Video/audio streaming IMPORTANT DATES - Mar. 7, 2001. Submission of extended abstract (500-1500 words) or full paper (2000-2500 words), in English, text or word or pdf format. - Mar. 21, 2001. Deadline for papers acceptance. - April 13, 2001. Deadline for camera-ready papers: hard copies and electronic versions. CONFERENCE FEES The conference fees will be $330 on April 13, 2001 or before, and $380 after April 13, 2001. This fee will include: - A CD-ROM version of the proceedings - One volume of the hard copy version of the Conference Proceedings. (Other volumes will be available with a 30% of discount for participants) - Coffee breaks - Welcome Reception Please send your abstract/paper or questions to the organizer of the invited session, Dr. Xi-Peng Xiao, Director of Technical Marketing, Photuris Inc. xxiao@photuris.com From owner-mpls@UU.NET Thu Feb 15 13:45:10 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27160 for ; Thu, 15 Feb 2001 13:45: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 QQkcna23060; Thu, 15 Feb 2001 18:42:26 GMT Received: by mail-control.mail.uu.net id QQkcna16368 for mpls-outgoing; Thu, 15 Feb 2001 18:41: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 QQkcna16353 for ; Thu, 15 Feb 2001 18:41:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcna26454 for ; Thu, 15 Feb 2001 18:41:22 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcna21646 for ; Thu, 15 Feb 2001 18:41:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA28197 for mpls@uu.net; Thu, 15 Feb 2001 13:41: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 QQkcna16223 for ; Thu, 15 Feb 2001 18:40:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcna18674 for ; Thu, 15 Feb 2001 18:38:55 GMT Received: from miles.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.dataconnection.com [192.91.191.8]) id QQkcna18360 for ; Thu, 15 Feb 2001 18:38:54 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <1Z4MYQX0>; Thu, 15 Feb 2001 18:38:46 -0000 Message-ID: <37701240971DD31193970000F6CCB9F70125D597@duke.datcon.co.uk> From: Edward Harrison To: "'mohanvak@future.futsoft.com'" , "'jcucchiara@brixnet.com'" Cc: "'mpls@uu.net'" Subject: RE: Question on Generic Label Range Table in LDP MIB Date: Thu, 15 Feb 2001 18:38:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I'd forgotten that the generic label range table was only added in one of the more recent versions of the MIB. I guess this means that this problem in the MIB has only been around since then. Joan, have you any comments on this? Is there any chance of adding an additional index field to the mplsLdpEntityConfGenericTable to cover scenarios where two interfaces advertise the same label range for the same LDP entity? Regards, Ed -------------- Ed Harrison Network Convergence Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8366 5084 Email: eph@dataconnection.com Web:http://www.dataconnection.com -----Original Message----- From: Mohan Varma K [mailto:mohanvak@future.futsoft.com] Sent: 07 February 2001 08:57 To: Edward Harrison Cc: 'mpls@uu.net' Subject: RE: Question on Generic Label Range Table in LDP MIB Hi, Yes, creation of row will be a problem if we go with the assumption of the earlier ldp-mibs. As per ldp-mib 7 they have defined a generic label range on a per Interface level. If we ensure a slight different label range in configuration( for eg 16-10000 (mplsLdpEntityConfGenericIfIndexOrZero 1), 17-10000 (mplsLdpEntityConfGenericIfIndexOrZero 2) we have almost same labels available on each interface,which we don't have earlier. However if we want to create a row wth the similar label range we can have additional index to this table. with regards Mohan Varma Hi Joan, I have a question regarding the use of the mplsLdpEntityConfGenericIfIndexOrZero object within the LDP MIB (draft-ietf-mpls-ldp-mib-07.txt). My understanding is that it is possible to have multiple interfaces using the generic label space and that, typically, each of these interfaces would advertise the same label ranges. Furthermore, I thought that it was possible to have a single (non-targeted) LDP Entity for the generic label range - this entity being associated with all the interfaces using the generic label range. If this is correct then I believe one ends up with a single row in the Generic Label Range Table which corresponds to more than one interface - for each interface the LDP ID, Entity Index and Label Range will all be the same as each interface uses the same LDP entity and shares the same label range. In this scenario what should the value of mplsLdpEntityConfGenericIfIndexOrZero be (as there are multiple possible interface indices that are appropriate)? Should it be zero, meaning the index is unknown, or should it correspond to one of the interfaces for the Entity? Thanks very much for your help, Ed ---------------- Ed Harrison Network Convergence Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 Email: eph@dataconnection.com Web:http://www.dataconnection.com From owner-mpls@UU.NET Thu Feb 15 13:49:37 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27301 for ; Thu, 15 Feb 2001 13:49: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 QQkcnb29393; Thu, 15 Feb 2001 18:46:54 GMT Received: by mail-control.mail.uu.net id QQkcnb17096 for mpls-outgoing; Thu, 15 Feb 2001 18:46: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 QQkcnb17089 for ; Thu, 15 Feb 2001 18:46:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcnb26820 for ; Thu, 15 Feb 2001 18:46:33 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 QQkcnb20247 for ; Thu, 15 Feb 2001 18:46:32 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 KAA17095; Thu, 15 Feb 2001 10:46:48 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA16011; Thu, 15 Feb 2001 13:46:29 -0500 (EST) Message-Id: <200102151846.NAA16011@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Ben Mack-Crane cc: Manohar Ellanti , Shahram Davari , neil.2.harrison@bt.com, Indra.Widjaja@fnc.fujitsu.com, mpls@UU.NET Subject: Re: PHP negotiation In-reply-to: Your message of Thu, 15 Feb 2001 11:32:31 -0600. <3A8C12AF.CA5150F@tellabs.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: Thu, 15 Feb 2001 13:46:29 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I really hate to keep this thread going, but ... Ben> If the egress LSR supports OAM (i.e., the ability to pop a label header, Ben> recognise the OAM header, and do OAM processing) then it would not need Ben> (or want) to request PHP -- so the question is moot from that perspective. Well, not exactly. You don't request PHP just because you feel like doing it, you do it so that you can provide at high speed functionality that you wouldn't otherwise be able to provide at high speed. (However many labels you can look at at high speed, there's always a piece of functionality that requires one more.) So if you had an OAM scheme that depended on the absence of php, you'd have to choose which is more important to you: supporting the OAM scheme, or providing the additional functionality. From owner-mpls@UU.NET Thu Feb 15 14:37:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28578 for ; Thu, 15 Feb 2001 14: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 QQkcne14406; Thu, 15 Feb 2001 19:34:48 GMT Received: by mail-control.mail.uu.net id QQkcne05776 for mpls-outgoing; Thu, 15 Feb 2001 19:34:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcne05758 for ; Thu, 15 Feb 2001 19:34:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcne02580 for ; Thu, 15 Feb 2001 19:33:55 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcne07252 for ; Thu, 15 Feb 2001 19:33:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA03287 for mpls@uu.net; Thu, 15 Feb 2001 14:33:54 -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 QQkcne05705 for ; Thu, 15 Feb 2001 19:33:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcne25120 for ; Thu, 15 Feb 2001 19:32: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 QQkcne05791 for ; Thu, 15 Feb 2001 19:32:45 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 OAA02212; Thu, 15 Feb 2001 14:32:13 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-223.cisco.com [161.44.134.223]) by bucket.cisco.com (Mirapoint) with ESMTP id AAP04957; Thu, 15 Feb 2001 14:32:44 -0500 (EST) Message-Id: <4.3.2.7.2.20010215143337.01c0f060@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Feb 2001 14:34:20 -0500 To: Edward Harrison , "'mohanvak@future.futsoft.com'" , "'jcucchiara@brixnet.com'" From: "Thomas D. Nadeau" Subject: RE: Question on Generic Label Range Table in LDP MIB Cc: "'mpls@uu.net'" In-Reply-To: <37701240971DD31193970000F6CCB9F70125D597@duke.datcon.co.uk > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 06:38 PM 2/15/2001 +0000, Edward Harrison wrote: >Hi, > >I'd forgotten that the generic label range table was only added in one of >the more recent versions of the MIB. I guess this means that this problem in >the MIB has only been around since then. > >Joan, have you any comments on this? Is there any chance of adding an >additional index field to the mplsLdpEntityConfGenericTable to cover >scenarios where two interfaces advertise the same label range for the same >LDP entity? I would vote for leaving the MIB as it is an forcing the user to create a second entry in the table. Additional indexes are expensive to implement, and in this case, I don't think that effort would buy you much. --Tom >Regards, > >Ed > >-------------- >Ed Harrison >Network Convergence Group >Data Connection Ltd >Tel: +44 20 8366 1177 Fax: +44 20 8366 5084 >Email: eph@dataconnection.com Web:http://www.dataconnection.com > > >-----Original Message----- >From: Mohan Varma K [mailto:mohanvak@future.futsoft.com] >Sent: 07 February 2001 08:57 >To: Edward Harrison >Cc: 'mpls@uu.net' >Subject: RE: Question on Generic Label Range Table in LDP MIB > > > >Hi, > Yes, creation of row will be a problem if we go with the > assumption of the earlier ldp-mibs. > > As per ldp-mib 7 they have defined a generic label range > on a per Interface level. > If we ensure a slight different label range in configuration( > for eg 16-10000 (mplsLdpEntityConfGenericIfIndexOrZero 1), > 17-10000 (mplsLdpEntityConfGenericIfIndexOrZero 2) > we have almost same labels available on each interface,which > we don't have earlier. > > However if we want to create a row wth the similar label range > we can have additional index to this table. > >with regards >Mohan Varma > > > > >Hi Joan, > >I have a question regarding the use of the >mplsLdpEntityConfGenericIfIndexOrZero object within the LDP MIB >(draft-ietf-mpls-ldp-mib-07.txt). > >My understanding is that it is possible to have multiple interfaces using >the generic label space and that, typically, each of these interfaces would >advertise the same label ranges. > >Furthermore, I thought that it was possible to have a single (non-targeted) >LDP Entity for the generic label range - this entity being associated with >all the interfaces using the generic label range. > >If this is correct then I believe one ends up with a single row in the >Generic Label Range Table which corresponds to more than one interface - for >each interface the LDP ID, Entity Index and Label Range will all be the same >as each interface uses the same LDP entity and shares the same label range. > >In this scenario what should the value of >mplsLdpEntityConfGenericIfIndexOrZero be (as there are multiple possible >interface indices that are appropriate)? Should it be zero, meaning the >index is unknown, or should it correspond to one of the interfaces for the >Entity? > >Thanks very much for your help, > >Ed > >---------------- > >Ed Harrison >Network Convergence Group >Data Connection Ltd >Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 >Email: eph@dataconnection.com Web:http://www.dataconnection.com From owner-mpls@UU.NET Thu Feb 15 14:58:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28843 for ; Thu, 15 Feb 2001 14:58: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 QQkcnf04277; Thu, 15 Feb 2001 19:52:57 GMT Received: by mail-control.mail.uu.net id QQkcnf07885 for mpls-outgoing; Thu, 15 Feb 2001 19:52: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 QQkcnf07856 for ; Thu, 15 Feb 2001 19:51: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 QQkcnf22711 for ; Thu, 15 Feb 2001 19:50:41 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 QQkcnf02961 for ; Thu, 15 Feb 2001 19:50: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 LAA18877 for ; Thu, 15 Feb 2001 11:50:51 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA16196 for mpls@uu.net; Thu, 15 Feb 2001 14:50:32 -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 QQkcnd04434 for ; Thu, 15 Feb 2001 19:20: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 QQkcnd12373 for ; Thu, 15 Feb 2001 19:19:37 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQkcnd06323 for ; Thu, 15 Feb 2001 19:18:56 GMT Received: by sanmiguel.telindus.es with Internet Mail Service (5.5.2448.0) id ; Thu, 15 Feb 2001 20:12:20 +0100 Message-ID: From: Javier Antich To: mpls@UU.NET Subject: LDP Interoperability test. Date: Thu, 15 Feb 2001 20:12:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09783.37C82F30" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C09783.37C82F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, For who may be interested, attached is a pdf file with the results of a little LDP interoperability test that I have done using Cisco and = Juniper equipment. <>=20 Javier. Visite nuestro web: http://www.kerndatanet.com/ http://www.telindus.es ________________________________________________________________________= _ Javier Antich Romaguera. KERN DATANET = -TELINDUS ESPA=D1A Dpto Pre-Venta. Torre = Metropolitana Plaza = Ciudad de Viena, 6 -2=BA=20 28040 = MADRID. (ESPA=D1A). e-mail: javier.antich@telindus.es TF: (+34) 91 4560008 ------_=_NextPart_000_01C09783.37C82F30 Content-Type: application/octet-stream; name="LDP Interoperability Test Cisco-Juniper.pdf" Content-Disposition: attachment; filename="LDP Interoperability Test Cisco-Juniper.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjQ0NSAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gNDQ4IA0vSCBb IDkzMCA0NDcgXSANL0wgMTY3Mjg0IA0vRSA0MDMwNCANL04gMjcgDS9UIDE1ODI2NSANPj4gDWVu ZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTQ0NSAxOCANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwNzI5IDAwMDAwIG4NCjAw MDAwMDA3ODYgMDAwMDAgbg0KMDAwMDAwMTM3NyAwMDAwMCBuDQowMDAwMDAxNjE0IDAwMDAwIG4N CjAwMDAwMDI3MDkgMDAwMDAgbg0KMDAwMDAwMjk4MSAwMDAwMCBuDQowMDAwMDAzMDIwIDAwMDAw IG4NCjAwMDAwMDMwNDEgMDAwMDAgbg0KMDAwMDAwNDEzOSAwMDAwMCBuDQowMDAwMDA0NDIxIDAw MDAwIG4NCjAwMDAwMDQ1NDMgMDAwMDAgbg0KMDAwMDAwNDU2NSAwMDAwMCBuDQowMDAwMDA1MDk5 IDAwMDAwIG4NCjAwMDAwMDUxNDEgMDAwMDAgbg0KMDAwMDAwNTE2NSAwMDAwMCBuDQowMDAwMDAw OTMwIDAwMDAwIG4NCjAwMDAwMDEzNTUgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSA0NjMNL0lu Zm8gNDM4IDAgUiANL0VuY3J5cHQgNDQ3IDAgUiANL1Jvb3QgNDQ2IDAgUiANL1ByZXYgMTU4MjU0 IA0vSURbPGU5Yjc3MzY3Y2M2MzgyZDM2ODlkOTkwN2ExY2U4MzM1PjxlOWI3NzM2N2NjNjM4MmQz Njg5ZDk5MDdhMWNlODMzNT5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICANNDQ2IDAgb2JqDTw8 IA0vUGFnZXMgNDQ0IDAgUiANL1R5cGUgL0NhdGFsb2cgDT4+IA1lbmRvYmoNNDQ3IDAgb2JqDTw8 IA0vRmlsdGVyIC9TdGFuZGFyZCANL1YgMSANL1IgMiANL08gKCOG7pr35O2yy+g5BEUwxLW0f5vW pFdEI1Srn2osLJU2KQ0vVSAo+sMkUNMqZMrvYJ8mRulcXCG0hrcxuAwn8lxyYVFGwqSk9ikNL1Ag NjU0NzYgDT4+IA1lbmRvYmoNNDYxIDAgb2JqDTw8IC9TIDUyOCAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDQ2MiAwIFIgPj4gDXN0cmVhbQ0KXxH7nixf1nubo9hPwkQJI8J4Wa0jO/SmZlDn j199cYNQeFamRdPY0LD7NADKLCn4OqUU9yDglHTyHFkzsbzEs5kz0JT2LfSj4zjBHHp6IybLTWKv 7UqpR5J+jaNldYYt5tzYpHCeDGZOktLgyaJzbaWHOASR5NqhH+9YCKOC3F73Hx4tMjOqAloYzKXu yobHH/51phYOCXXX0l0TlcjI25wHW7/jO8TP6Pfbc5LObJEObKc7P+A4lQRIeMsagWIDIjHWo0uB m4xHgdqEAkkhDEh8zuw5RPsEqIrcCDpGuKDqMgtfZHl/w4RuShtgi4HIk8KAv+sdYNla/aO+LrBE IZ7oPVz9eQ/DxzlC8A65siKVr8DB4oQOEbUWbSxLUMDcQq/T3wEZ0O8aLci3px6xQUlPxlgfy810 hvm4BNFB1x+p9kk3KyFhKts3YHXlEOTNWFsNZW5kc3RyZWFtDWVuZG9iag00NjIgMCBvYmoNMzM4 IA1lbmRvYmoNNDQ4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0MzkgMCBSIA0vUmVz b3VyY2VzIDw8IC9Gb250IDw8IC9GMCA0NDkgMCBSIC9GMSA0NTMgMCBSID4+IC9YT2JqZWN0IDw8 IC9pbTEgNDYwIDAgUiA+PiAvUHJvY1NldCA0NTggMCBSID4+IA0vQ29udGVudHMgNDUxIDAgUiAN L01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90 YXRlIDAgDT4+IA1lbmRvYmoNNDQ5IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1Ry dWVUeXBlIA0vTmFtZSAvRjAgDS9CYXNlRm9udCAvQXJpYWwgDS9GaXJzdENoYXIgMzIgDS9MYXN0 Q2hhciAyNTUgDS9XaWR0aHMgWyAyNzUgMzI3IDM2MiA1NTEgNTUxIDg5NiA2NzIgMTg5IDMyNyAz MjcgMzk2IDU4NiAyNzUgMzI3IDI3NSAyNzUgNTUxIA01NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA1 NTEgNTUxIDU1MSAyNzUgMjc1IDU4NiA1ODYgNTg2IDU1MSAxMDE3IA02NzIgNjcyIDcyNCA3MjQg NjcyIDYwMyA3NzUgNzI0IDI1OCA1MDAgNjcyIDU1MSA4MTAgNzI0IDc3NSA2NzIgDTc3NSA3MjQg NjcyIDYyMCA3MjQgNjcyIDEwMDAgNjM3IDY1NSA2MDMgMjc1IDI3NSAyNzUgNDEzIDU1MSAzMjcg DTU1MSA1NTEgNTAwIDU1MSA1NTEgMjc1IDU1MSA1NTEgMjI0IDIyNCA1MTcgMjI0IDg0NCA1NTEg NTUxIDU1MSANNTUxIDMyNyA1MDAgMjc1IDU1MSA1MDAgNzA2IDQ4MiA0NjUgNDgyIDMyNyAyNDEg MzI3IDU4NiA3NTggNTg2IA03NTggNTg2IDU4NiA1ODYgNTg2IDU4NiA1ODYgNTg2IDU4NiA1ODYg NTg2IDU4NiA3NTggNTg2IDc1OCA3NTggDTU4NiA1ODYgNTg2IDU4NiA1ODYgNTg2IDU4NiA1ODYg NTg2IDU4NiA1ODYgNTg2IDc1OCA1ODYgNTg2IDI3NSANMzI3IDU1MSA1NTEgNTUxIDU1MSAyNDEg NTUxIDMyNyA3NDEgMzYyIDU1MSA1ODYgMzI3IDc0MSA1NTEgMzk2IA01NTEgMzI3IDMyNyAzMjcg NTY4IDUzNCAyNzUgMzI3IDMyNyAzNjIgNTUxIDgyNyA4MjcgODI3IDYwMyA2NzIgDTY3MiA2NzIg NjcyIDY3MiA2NzIgMTAwMCA3MjQgNjcyIDY3MiA2NzIgNjcyIDI1OCAyNTggMjU4IDI1OCA3MjQg DTcyNCA3NzUgNzc1IDc3NSA3NzUgNzc1IDU4NiA3NzUgNzI0IDcyNCA3MjQgNzI0IDY1NSA2NzIg NjAzIDU1MSANNTUxIDU1MSA1NTEgNTUxIDU1MSA4OTYgNTAwIDU1MSA1NTEgNTUxIDU1MSAyNTgg MjU4IDI1OCAyNTggNTUxIA01NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA1NTEgNjAzIDU1MSA1NTEg NTUxIDU1MSA0NjUgNTUxIDQ2NSBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0ZvbnRE ZXNjcmlwdG9yIDQ1MCAwIFIgDT4+IA1lbmRvYmoNNDUwIDAgb2JqDTw8IA0vVHlwZSAvRm9udERl c2NyaXB0b3IgDS9Gb250TmFtZSAvQXJpYWwgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTI1MCAt MjEyIDEyMjAgMTA1NSBdIA0vTWlzc2luZ1dpZHRoIDI3NiANL1N0ZW1WIDgwIA0vU3RlbUggODAg DS9JdGFsaWNBbmdsZSAwIA0vQ2FwSGVpZ2h0IDkwNSANL1hIZWlnaHQgNDUzIA0vQXNjZW50IDkw NSANL0Rlc2NlbnQgLTIxMiANL0xlYWRpbmcgMTUwIA0vTWF4V2lkdGggMTAxNyANL0F2Z1dpZHRo IDQ0MSANPj4gDWVuZG9iag00NTEgMCBvYmoNWyANNDU1IDAgUiA0NTcgMCBSIA1dDWVuZG9iag00 NTIgMCBvYmoNNDIgDWVuZG9iag00NTMgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAv VHJ1ZVR5cGUgDS9OYW1lIC9GMSANL0Jhc2VGb250IC9BcmlhbCxCb2xkIA0vRmlyc3RDaGFyIDMy IA0vTGFzdENoYXIgMjU1IA0vV2lkdGhzIFsgMjgwIDMyMCA0NzAgNTYwIDU2MCA4ODAgNzIwIDI0 MCAzMzAgMzMwIDM5MCA1ODAgMjgwIDMzMCAyODAgMjgwIDU2MCANNTYwIDU2MCA1NjAgNTYwIDU2 MCA1NjAgNTYwIDU2MCA1NjAgMzQwIDM0MCA1ODAgNTgwIDU4MCA2MTAgOTgwIA02OTAgNzIwIDcy MCA3MjAgNjcwIDYxMCA3ODAgNzIwIDI4MCA1NjAgNzIwIDYxMCA4MzAgNzIwIDc4MCA2NzAgDTc4 MCA3MjAgNjcwIDYxMCA3MjAgNjcwIDk1MCA2NzAgNjYwIDYxMCAzMzAgMjgwIDMzMCA1ODAgNTYw IDMzMCANNTYwIDYxMCA1NjAgNjEwIDU2MCAzMzAgNjEwIDYxMCAyODAgMjcwIDU2MCAyODAgODkw IDYxMCA2MTAgNjEwIA02MTAgMzkwIDU2MCAzMzAgNjEwIDU0MCA4MDAgNTYwIDUzMCA1MDAgMzkw IDI4MCAzOTAgNTgwIDc1MCA1ODAgDTc1MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgw IDU4MCA1ODAgNTgwIDc1MCA1ODAgNzUwIDc1MCANNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgw IDU4MCA1ODAgNTgwIDU4MCA1ODAgNzUwIDU4MCA1ODAgMjgwIA0zNDAgNTYwIDU2MCA1NjAgNTYw IDI4MCA1NjAgMzMwIDc0MCAzNzAgNTYwIDU4MCAzMzAgNzQwIDU1MCA0MDAgDTU1MCAzMzAgMzMw IDMzMCA1ODAgNTYwIDI4MCAzMjAgMzMwIDM3MCA1NjAgODMwIDgzMCA4MzAgNjEwIDY5MCANNjkw IDY5MCA2OTAgNjkwIDY5MCAxMDAwIDcyMCA2NzAgNjcwIDY3MCA2NzAgMjgwIDI4MCAyODAgMjgw IDcyMCANNzIwIDc4MCA3ODAgNzgwIDc4MCA3ODAgNTgwIDc4MCA3MjAgNzIwIDcyMCA3MjAgNjYw IDY3MCA2MTAgNTYwIA01NjAgNTYwIDU2MCA1NjAgNTYwIDg5MCA1NjAgNTYwIDU2MCA1NjAgNTYw IDI4MCAyODAgMjgwIDI4MCA2MTAgDTYxMCA2MTAgNjEwIDYxMCA2MTAgNjEwIDU1MCA2MTAgNjEw IDYxMCA2MTAgNjEwIDUzMCA2MTAgNTMwIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0v Rm9udERlc2NyaXB0b3IgNDU0IDAgUiANPj4gDWVuZG9iag00NTQgMCBvYmoNPDwgDS9UeXBlIC9G b250RGVzY3JpcHRvciANL0ZvbnROYW1lIC9BcmlhbCxCb2xkIA0vRmxhZ3MgMTY0MTYgDS9Gb250 QkJveCBbIC0yNTAgLTIxMiAxMjAwIDEwNTUgXSANL01pc3NpbmdXaWR0aCAzMzAgDS9TdGVtViAx NTMgDS9TdGVtSCAxNTMgDS9JdGFsaWNBbmdsZSAwIA0vQ2FwSGVpZ2h0IDkwNSANL1hIZWlnaHQg NDUzIA0vQXNjZW50IDkwNSANL0Rlc2NlbnQgLTIxMiANL0xlYWRpbmcgMTUwIA0vTWF4V2lkdGgg MTAwMCANL0F2Z1dpZHRoIDQ3OSANPj4gDWVuZG9iag00NTUgMCBvYmoNPDwgL0xlbmd0aCA0NTIg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NClFM5ht5Bb3LdL5RyxWJ6tkbbZ+k EKTNWBIPJhYL9ovxt4SzTkdSx+JZWw1lbmRzdHJlYW0NZW5kb2JqDTQ1NiAwIG9iag00NTQgDWVu ZG9iag00NTcgMCBvYmoNPDwgL0xlbmd0aCA0NTYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCgmuk9Dvw3LsMOMlaYLf0siIthiM6d8Xmw0auKBvWeA06igwG9UUMm4Xo3ECiR57 YGjK6SLPYVREq0ipQGh3rUUnRgA0lUnikopbC4iRRzTtYBeAQwiMDdUVi4d3HVrHlvsuDitpcWmC C1sRHyEbAc56avLqQsOBKJna2Qt2ORqtwaHu13MSmNhPOngGEhQ+SwGEDrAMJazqFRUdtY2BrBJs teaVMMvf5EJd5U2EDd2PiMPVZoWU6EaOD3cMArzBpBxwFLKez3YLuK8ieaGknPBxbYV7QjMYVW5O QG1szsjVryblhbapy9m/EfzOdyAMshMM/MK1y8Ugps8AmXYgnQAppqtgJI/zIZos+GIMWuponoJH AWB7VVGDR9bC0E7cV9/9P7joZCGw1mtpwdKF2Giuq4NrCYtqvfFxZnGFclhuTJlH7O4abLm/eYY7 OZqIWzUlfXFQ3+pimUvPliPZUoOfrSpkhKJYX20NjpKHNoU6NTwHhCpKfPtW8uVMmoekBJ5ZJ7UY drGnk1k4lEJvckUrfIkRqNH34gDwnL4IF3kYk/cLX48kjpOMNVJCnXG1Quj/I2eeZuLYcTPbAwSx NRbQLoD3tmQNZW5kc3RyZWFtDWVuZG9iag00NTggMCBvYmoNWyANL1BERiAvVGV4dCAvSW1hZ2VD IA1dDWVuZG9iag00NTkgMCBvYmoNMzQ3MTkgDWVuZG9iag00NjAgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTEgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0 aCAzODQgDS9IZWlnaHQgMzg0IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rldmlj ZVJHQiAvTGVuZ3RoIDQ1OSAwIFIgPj4gDXN0cmVhbQ0KMlK8rO47BawfmBgXeHPEwK19DR0nBcWY Bpww/eYFKZ+Z3IZw6qZXdmF23nd0zTh47+NDFPUmsFTq63mHnA0KiS0D2et+ZgYpwGYav9ydUNib RkNaKLffd1HxaYb+hVAV4PPwmcMzB/Sozq7473HeP57oUJSDRQz7ctIyczCU5g+CzrFbI2NoMB3m gDvxUm8Zw8IqsFgUwybFC6yyOUfMWx81VP/iWQcnTwm2E6HJ1pccjvfdz18Etp/zRarmxzCUUhMi MJRTuJxDa7O3F9vDwvNGqNKsb/LDd863PYcrqtucCJtqBETejyFNe1N3QZI05cgHhz79Ppty3rGU EALjZRT31WVVS/8rZwfa/plL6GxTFuQFcSZJSlL8Qf/XYBaJD8x3v4XNrqnagq87voKyj4VLTzpu RRoQDcQztPXQip3rZ//z7yjPzvs+Yr8f5NgCVSb5IKGrCftz7r3HQ3j0GN/3BiJh5ydNeOjhohOA wudKzGpJqEaesSRDEhBtH0eyzSbZq5G2rkHbnsrH9cxVlUnTl1wmce1lO2E2eoeYF/llQiA1yQTt 8F7BoXALV5ZXAHbFU4XDaeDDHaIMaijiL3SSuAG3Iubqlkr+tccA5vBRbozD/eiFJ6g1u1QdHx/O 1WR0UA+Xk8ubUu56FZsRmZpYDpzHC6EnDUtrcEgnSNwF8PIIgyIvvJT+6cdhCwNiIrmSBHRm7O2w a+CuuKPDqmMnBDpIDJRoy/sCjmhoJFPYOLnc1HHHqf5o/53K8nMVMYaIOdrKpFO70VfRO4hV3JUH HJ5CQDdZ/CwqrwQq1xrTgZ6qruBHDVQZL5EtVkSGwxNRMWYbS2Xddti4gHJCO4cC1ZTIE6w3tZFh 6BQHxbzQqd4FW+Rbfm2+bm6f8G7C7j/J1VADq12MXSxk2urnEf53yaEHChfPpOUSXVkwymsj60lm KW3m0mDi9EiYKlx6nIgYRyK3iR4UKH/ew4QkUzvQPnQKpv+NsBN0q+R+/J5bcX7iUcyHT2w9txXf uwBgup39VAhuuFCrSmfNC1ug976BiPRWuawzNd6YcCLGefHO0zMg8nE7r0iJdrHJhyLepqpPhSwq 3I3MBZgvWjBPkd9hKZ2kGQBf8Tsb9ucJqRCfFpAQEPbVC87jqVtJWXNP8EwgFuDtmZPvSTnAVMNR n8V0ykbroD6pVcHwjqZgZ9UBiJuAp+cmN4fcuJdAmrLbssXpMLfVpSDZtNJNNfKeVhsmcq/uAFDf En1o10QJjetygpA/b1sMNWlDpV8BuMvbzTfTYZiGp6qp6djZBRgEtkBwoN6ufZyVFzBTZIxpk0TJ SNETDzon0YgZEvbyhVr94QIe+y2kETJRjg3x6Jv92yeit8teu5gNgjJ0Eyy7OcLniovfmHhDLRUE rDQyICEbqruh9CEhDh3WfQ1FemyB4eMvHSDJZ+CUa6I1c/4KW5l4gLU74NhqVniC/SqhfIgCdQIN KtTA5CP3wcE9Hjm8DXSi8m1nFNmP8BlUv0oPYPuDFuzHUktJNxwLDeBMe1v+7cl44Se5e3veSPAu YckVL7iBLU/p7WbYn+VOneJnO1Y/lbMQmqP/ye2D6uM4tzyK23oq/IgFJex4fHeCDaKZaOyrU36X ziGe4OSBqG1RZiieL/iW7VXBTmhee7lb4D8zUr06Be+IzASESbPCRC3Iq47KB1Tn7vd/qX+dRNKJ GjajkVV8psBSZpOWsGlpGO1sTCzqruIuFbBWgErealjUaVU6JpU9BqFZaEPxF4sGaXgwcpTSYExy Z7nqcm0eaUgrc1YwSe5JzBEJm6tLf8RTIqQLpMyuHOzME+YuyxNCPK13JIYnvOaByOc5M1P2bca9 sbvod7gmJZoe4N69tfal+x2BEYQLoa6x/e1NG0/aejqrLSkEh5SL1fdwPbFp83tT8jcYL8awiWWI 4dRSDzDPP0OzAxRyvD2iiipy3kaisSG6wW4u4KX1piM7oYi0chUCUdjGXBxKy4QqviXnK5QPI9MG HeALJQ1X0usyGMu3AvfvZRx/ndZ8yS7x/l/eKa96c5FQGKevl4XddK7X9v/K/9k6ppTbAChKmL+E vbX4uswh+oBaY+GzIO5D2co+UPaMChX3nO/MVHZQ939Vi64v5FlbcC1xkzeaYCmTZKZey3a2LOON aGbmiVdEDLAekP176BHSpI6aMK+MxRg7AQjT4Lz84ZBz8a4n8Jlwsx3OGNhnKfyFvCmSiWBDqJUU ZtYs1P7o/ugv+x5vqmCe3oW5GaA5icSss7oZrriZIN2/9+Wlp2GQ9+Gn9uZGf42orhLsUrIC6qRB QRFAo9QOI91qKP8SP9CcnxuVIMEzA8Wia/wSlYcmSN6bZ9xRi3TukfR43GUP6o1pB3YoKY7588+K w2ySS434lpyeJdccQWkOCH9OgV17EdQYE9wb2UmxQt9iri1KJn6U93UpAxhHZdgBjYZEViL1C5Xc rkgYhXf21L0KVBOm26HKFWUajfaywhmEYT1/nj6eoSf21ar2/85nQxW+qfpVuYyWfVvUcxT79CXa cIOjAaEgjBofCFtaaBp5chIL/vIqTYMzs85GG6P7XbKji1579nJP0+fX95E0cy+O36IehJ3Oqn4t S4sAlrBUPwEK7u3TYuhyb2UdsgHx+TS23lyPrORqK8iA9/FhiXCuKj8q1mcNV+RY4nM/4zfJRIao KI9PPrYWrhdBv7HNOOcluEm3w14L2Mo38M50SpGoRne5L2F+d/JKy8wdQXLFF/LVyUaxyAcfxG0m E0Zs+YdgWQhI45Erx6byQnWptiF45jCMgUQ0BdIbUV1DhWMIUuJmaquTtqsqPbaBb7a4tRl1ncwx Bqt0ahzrw/nTo8x7TfJKZD0KxliOrI9smN9HL3IFQpIWXRSMuqKqcOhuBK+t/pFbk4cFquHaYKdK WVYhS308+vYx/Fx+5yNBd8quo8f+tkWDBlwsAXyj5RxojuIEnn+7dO3BHxo4O+2Wf5pRwXw5wTK9 RbX1JmL/ad5EVNCeskoUqBhPZJirFAMfPK0MwSfFmFW0nPylnhGyGu9OPJjvslcHSYHaM9Pp/CZT UQ6pBF2vTpJbJmjbhzW1wX4zLUsynYV6P0WvwUU/P3eglXy5tH5drwcyguvIBIs3kd1cFj0s7wa+ r0iZb0F4s3NdzDf76C6R6YUXZ9ePDvQgxvDXEgGmoi1SgqjIdt2LImTgv+d2mitQCApeh2pIWim6 PXtOVsT8PXlNwj5eux/4StY3ueXLz7+PrODUsBDpQWWBeGo6/Co5SAFPNq59iy8llLlA3TKEkD4y YGqwfWBpnDYtw8c98XtqpTuAYzAS7EBaYSiKEw2RxT3Pi18P2pziWi+Dbqueod3v7BwwnG7vX1KO yr1/Dneu7IsOvr6sJdD9YmMdeV5fviMHijIBqevKdI58cRW6XG9FflOxMDSQGOv0ggyvsDe0Oij8 1+eOR1cZAKRob+fUTY50LGI9ZLvR5Kx8Y1cDVlpk7r3/4l0ko1CbnvKt/6XFHCeH4J+zthmDencF ZebdUvDAxAmy8w/SsJkx54oKKF2f2cE35o9X64qVcPucE3jK6B9iLMy4lnpOH5QXSmMnhwRFdQRc /VblM3Oljs2urkGrkVHceeOSnPcAwIAhJKQv+U52e1/nOJAlU+/yIe1eJkHPoTrftqFMJpS3p2iI ng2yxVoMPK/IaheT0PNaOD1OQjBOMgK3TnfYHQDHbTOlMFOtG7nvWZed6bR32H9rTaWxx4+oy/yS 3H0GIbckWHgTEGTthAOellLS7lEORTBWAPt/GjK5XJZktqGRCF+gEmqs+dgZbl6KYbH6odblD07G 2x8iwt/jzz7fQJjJlJDyDIjZTwguIWCQT7ipa42DrJPewAJk6oiNteyCyuadVWFESK7qHoBNl6Ep 5Pd4gBjIPuoXLLj9XRjkmiX2kvf9ZY45k7spl57D5Q/y9LbPpXeYZFhxp4ovW5SQJSp3O/pKl/o3 Dk1BSgdMYhIGhF1cy0imM9bUFfE+gQ8jypnymzjPG7s9C8VhLAyv89EUdCnMPM505+EzQjSYkK0s Rbh6PiLzyQJPtjQrBkL/X9TrZeZm67RRiNKukkpPOXdlczO3vb1APhxZxhFG4FYMOR5KqXQbqlFH TncmhHT0Ylr6pdsQEBwzL1VIDDG9gL6qcEylSPuD99QGAItU1ah4AG0aG2CeOCRi6VV8cgzQDXxQ hC5b5RBgTPl3zxXylCBL1c9Mk/z4Ekgh6SgKpkQV7GbD/JlduWMq5nWwsvNzF2f9MK39KIxJxnXm INvXrmGSip1meEJPWXfIk46vi7b7+IQ6asfCuOHJWR3/2fYTAQPpk8T3zQ3XvliscLv952sFtzsM uVO2/RHtjUwBvJcqEo3+5Olq91qpf6YqdHzpZbUyX57XsJXCwMOjVGel9ecAMGbp08BMrRl5+Ikp FOo7tB30oLfqyp1lEOBQo89Iw46/mnz0gtioHYyjRtjGqL30veU/pGYDH4XxgDG353xCiSnWGAaG VS2E/YpoI+IFYzQNWPCHRWL/VqH9J6+hdA+yqxE6egUtqTTcvsskGQXOlhwhM1LP8veTV1FUwZhx wbSyWbblH5K7a7+KQZr05nd1oGzfrF9JFC/siU5nuwgbJD+B+SuVUOZrS/y7xr4GlJhf/KAL4DtD RqFGtgeraOevTvBSeM3v5R0PrUNkV+aTdABEBghwKGssPEhmmumaIwdr2DobaQYIE90JvqzFN3lg hMJ19s28sFIXTDkz7v9KFinRGKeM3pjS+aPXgHoTkokspMS+/mK4vGOtS4o2bjA+qMZUwVIEE/+i P0z2jq7WKwZ2N9Jmr5hDyDANkSEuyKRBlCj+IRLFmwGsyi3Q//oF3+JLzRxQyWsT71+McZhC1roL MW2kfMsbGib9zdtTLfVbyh2SHQvcVK8kzpOMgxDNN1NRHeJ01ZjRevFNnIr3hxasFMFUm4lP1idG lT1AOEjYrHtAxycrvLWt7KivTqkWuMFsHh/8vwx4j9kFw53NSOlATwV5MS7+H9QG0LTvb3wWpMrU lPYJFT9UJnk4kCeNoAE2RRApWM+Tun/TNjN+rvLCADgSzxHmrQ5PjkUw5X1vrJD0cpPDsK979aon pfe05I2WBzTVtsSSyXfBA8adFAE60dCtYfHtl+3GjIggXCPx5JFZS5eybEjXBsQ6lWnxDBkyunV4 PpETBPJtmUDuhqQe3JNeOoQbDwF/WL5z5hye7kTTXi9XplBfBrICAiqsttdgDaHeZHH56lFCePLD w4q/zA7TZXW2OM3CdFzWQm3kYYIEUPbaCW7v3+8UVgJ6EIGdnRt8jLBcoLdlfgMjjmtW7F54HvVX Jnrz96SqUrfTwA/Ri2LzuhJz2AULCqrgdmGAS9Nj5uaX4qqgmXt0nE34naSTZx2AxmctIXG05l3R nnzGTskPRk5xf2huxJ4zWYjyPZYaybQ5zZERkxzsyKTrAjR2NWqckFEt7/tBPnr/v84eZXeCbQEW oCYs120QsKefkhFK7LCaB+LkWXepmZCrK9EqXUW/6UuFK6ofJiYjtYUcOZZmP5J7ryY6OxxyjTZ6 +3Pr72PuXONda196BCrDz/t3PPC4kDDdghM8A33461R7Pg+kr4NSbiG3fL+DQwdahm2vo0QpcReV MhxTvMsNUC5BC+6Z+DoTgDFywNAvTvknPAPLjPHQ6FyygUF+mDPav5PLx3G5k+fnNnIgzoXFtq4H aGVGvs3rO7FO2J36GHGgkrycvG8vSCZdbzc8JTpxbNgPAh+NFnwPX5wbTsNjz6eIUADLW/fvFOUS gW1qbn4DmxBKqPRc3ML/Gf8GL7aPBXDlhtllXMXBq0KN4aPRMrWBwrZ4m2X4iZbIM7bSIIoVewd8 CyV8mo3c+BhEwpdcLMyMyL6SwVZITccxJgpM9C1x6YOPK32l/UXEnMgH5i7f154pGxNjZBWen5zX Sju0wc8QbV9r2BoTGgohkKx+JN28UtjKEgnpIfq3S8yodIVn9XWS1jDoiFRIz3ThFtjvJK8kyLnD GpX86Y8AuT73Z+RaEnGWPsWxAgOjbxIez4n1fmh7aVy0L+UU5JSBsOGe8UjEEDCFHknPqdOvMJQr q8fn1yFMrNd0MP3blmlnEaKcngPeX30Y8UC/Fupn0UBxnk/cXUnG3ho7BENkGgFDlCO7lc7a3DLa AsoAB/2aZNG9NkkMpARMTSR4TyHpccuRw6k5yRzsCHCE+ficENuXLYimOR+eEmMBIe5WzlqsGPgA dErJu4BFWPcShPNob+Bo65p/B3rf2atBtEm9E4a9/6UiPfomhnMA/PBAE1s1Gh8ibFZDg3HInQB8 lUbyYnq7G3q416h/mLRBZa6f+NeK8BaVeYaVrVLNpsUeUiVxMZRmbJ44roprKoRaDXsKYsLs8DED /SLh2UkSk/UFvuYbgbi+DO2B8AaWafGAb31h8wMiYdZmPZBJFsKZRswxrkVEyvjaKz/49oXuNqOZ XGqP8oHiQwkYUHZpTY9p1Zk2+ZjtOIZhzH14kM3GaSq7qo9AB2r9OvbkrHzLnejSUP10SA9tjAlz BsbkaOjJ2QFKQTK/cQFhg6myXZjdy8fo3Q3qyjR7DOkFd+FzXCBk1hC9VXClFyMqnijSsi2r321U Kfiay536IcxPsUUaEXz5yi0r3irW2XDTf21LUkE3cwV6PbzwU9yFt6BA9zJkrcL6Q6ubHGwd9btM 3oiEaOQZuOor8oOHcKiOm5O7kdO5afPiThp1l8owhW4OyCurGwWj6ouMz74Id6s01bq0r9Z3gA+s byjxYXWkmaEj/QOvr5lvLrxhbFzDpsCEs2xRjRL/avae1Q/hjij4D2JmeOUXHc7bf/EpIqAugoU3 CHA7z3nYfd8e65uIJ/eBr4hBVeCoTOfwCUF4rnvGKe4UiDX9vluAf8+iw4A69U3a8MGBDriAcbjg Pv/FBUz6+1sAh5+QetQ21KG8kp+F0gQV9/hFKLoXpI/S911CbKXEP3fBThVacYbyCl3ea85G4hmo /lt8Jup+PHQ6sbhCea/flGO/42EcN69AImHX042LxoXuCwxPf7go9ktcwE52pHnw2+RmSQExHvlI xBSHQtxSs946Dbyc5zmjyz9C5X6AdgyIdqjrEasGqBXY3rB1RK2fFAX0jD6AOZxw1ZUZ3PcZQHx7 lBABPkhyIuoCuMygIo2Op24656BVxMm2J23ilQ0bMSKzjC/Vzi3Iz2Bh0Ju0mwv50RcpS2477d1Y vVIrXTz2RkiyqnwH42nLo+Tr8i5+pVAGFug/dJZjOO7H0fEpt04ln+Nd6JgVPAcZ/GVuTZY75S9l 28sTIeJy4SUfoU/NrHT/PBvhK2s64znCumpgJ/sicgL4NHjvwhWGUpBWt0tUso78UY1gkrOtIMeI MbP0yCUhz+7f8+SFiVmwQ64iXz8OROXZR/7Jn4QSZb1sBU0oAnYXtQzCvrJ+5TYS2VIS7qRhGKO4 CoIwoDQp5i8cdDfYeiFDLQYjO9a+/qnANcLFxwUeQI7snNS0emYGgjOKsUfMv25RoGvKgMjEQUMF 5M53Hfzp+TWLf43I4T4JxxVkxbTmh/I0DqFr7Y+DJSSmkOt1E6Dy4W6mOls0OVdv9kBqQVdlTubc qjW7w+wfdU84ybjLIHj3QUOyGRNBAE35uLEIJHLna6q8Y12M57sW3tFU+amRwKTgyUC2E7uOdTlS 3nhlIHdYeuLsyo2dZe0MFjZmX7+eyVNCE/5cHQkgK/Vgkd53B+iVGAIqE6MAaJIvIV/RsHexGvxH gZjfcLZWAS1Z44PfD2nEvbTEs2QDD4MNbNI4bejZ7rsspqH0Of8HhfgXh53R6n6KKNhpCvijv/Ms Huk8CTUk1zz0c/S5z4/x/EM8Ayj9MaooyebtSCSJeKPmv4pH3SZFZQ38deTVzgiKZmX7Ex40z5Gw cN76LjSvAiTherqIhFYMBxIuxnObFYTsIznnpIfnvnsaCLW3S4P/sxNoSfI7Rt5S+DL7XPC3x4iN /mZr8HytCUHp8XuPIKcTSHbwjqyEofg++S4692DSdJ3yahNSPkDX44V6LGm9ekoVhb3o/ecICKjo mnmV7GhmJUjMC8WCHC9nYV5coNjRV8ovjYtO576RJjueOZrGXODUHIYklhFExBJy5YKO9p2ZHwrl eIxtbleRrTDKcx1Z++pngHKNYGjbXuRLW+2H27OtrTBdGXhdXTRJ2yoVDUkM++FT2oAfEZltj9CN 6en0JMOF4epLQK8KWqGfR5KoGmE/RI6yfsitjso7HoL4cD/tmon/7yI6Igo7iwPZxFF4Ijp2/LHq pgFRuMreldQ1AtUs1SFMhV8wsZb+0CG5bCLVlTg0ZZ+Rhmd5FlmpdtVMyP+2bEBNvE1EvjV3H0vT BHDFb2IK+lD20YC89rzQjBaYT5ZYxI2FmzdJlxc/Fi3SblZoHVZVnOB2Xa4W379LemwsxCMiKid1 rQhCSzJA/quXKVg9LpGQWTjqIeqPSKhLJDkwcMgaBVCBGi5TXL2wgSyHgqnoYuGF/52JE8D1Iz1g I/f+tAMdtuPOuv0ciTCRCA58keQMO4xhEMGZiiDdBX+rSKG/NCw8nwnbSWjXlCqNO8Ma8F+9sOf/ XmU5sGyqoaOj0OplQlWb0su2Z6AgNtMIsF1zITWpCwUiPCcjz/HnxR1DF3NNZdmfwYOde79YRgVa //DoTYYodcAOnCUE3UzgXzmBy/aNzhmN+32D12BhT2sNr8/KcdCEwbzqZMn2phw1nDRmWrLKjLa6 hvO1hXMceQLzTLXxRnIF7TWCsYMuYBVwaYrj4takPVSJPEsBYjMNYEThxBn9PF/lwe7/EJubKAH1 W2ymzSGxao9wLwTOJsU6svlG5IPd3FCp+p3qcw853i7Pdy0npCIEE9GT239HfsiIfLZpMtnhVa1Q AE+ewPI4IonNiUqHozRbDhVubgbFm2ihSSsndDyfTfzix/Sa3HKE5GtX6+HVENtF9R9MJ8OFt3VX 3nplGdLzFlAUNtRowgD+v+qvrbAPcM6bQOxf3HVWfksnxa7LgRWjx4wi5b446BkOKTrtD+P8pAIu HrFjfSYEh7gFmlTkZ8aKc+YuBAzszFXXfqlavDolCXhmyKyjb8lAm/Fzevmh9Tq+ca1ol+pyjSVj YgQu3BJtYv7WVvQ0JiT5DUd5cJ5NLVQ/ZOSEYoXkIcNPDBNhBFvVEernd6TWAKmE2i/XacYONW7E Ds1nDDOYaovi2cl8GFNXzOLa/DkbViFrILky816CzuTKdqlTTFF8u7TUizauuiE8xIYBW0HJBXUJ yW82yy9ZYfP711ZNwGXFC9j4K/kjcqr4VIjY+G2mhRsdc6eldhzDJyHXHdjEQ7dJjKQIQULQIhbA POWnXPaS8cbrhV4XXxZruMSc0E1TkJvuBWkl+gYNoACa/CKBDZK2kfhjKfcmcuQVwW9x5hf9/yOq djbmyeeU6azQIbuVHSLxbJrWoxKeHQJ+XE78eZyn2kzDIiUtdvde/7WUfJDMudNw+kd14zWRhjZy gTC4jhlNAHIJzOrn62fWYBFUO1a1X31di24JQMxQoRgRH3gkO8mBjaE+C846YvLjIWFY5Q3cz0ik Ww7j0YgJoOy6C9iiedzZ9IMU49g597EoprEMNA04mNhA9Z1OMfs6UX6jhR5WxwWltFihVUNDnwtL Gi6veTZOtAdt3Szy8rBbPTPh9D7xdFKnaZh6AaPOgGo+z5+R3FENmgb65/Zdck4CnIrubiNE6Lzs yiqeag87cYz5FooSxLU9zX8UlR2MCJQMe+rtfw6Idnaq0WsOwfG7PMFHtDBj48RwQqGeveu7bTdy vM1870N9gJ0c17fiHC2m5lU7MBy/LLNzQ3T3qagInR51qrsw3O1n3xj7tr0UvLSZPyeetmbFmMfj a2JD5KDDDw+1umJr93VUtyY8V/ketmPw+MD2UmSStr9thRQfuHxm6EStvGJaBhhAO4b6P5Bb2j+3 /hTKzzxoNbUSKp7BiJT9bvjn0zZ9DwmUb9RsfjeWunf1i7NQtJ3NSoexnXjA4sVZsP2d+Hi1XLIR RPXd1HauHH+++tpzy8Pp37dqOAWsB8m3p71mAlbxiJmgvktemJxNXRUI8WawLoAZTupI+Wzk6evR Psd6P2sDg31OhN+ltGJQgMtfKfJDayb0JB0lrE+MFmisWoI6iV6dQpcXVXbMHHsxa4vFGWkRs/4c 4DpYNeHiajswQGhXEUECqhBcf1gfpIcaWsb+naZBTn4SZF30fToQdCfy+GElHNK6hjmt5W6olcB0 asWUFHk3wrBtwOPYa1yJm1JqCn+z3dQjLESAFyzSc304/Es+9mNIZKuKVvXvuw6HXBMB4ymTe1JL kMWrh4pjv4KumntBomKumuBp0rdsIAbqEGduUByK5EbyxR8QYEgIU9zt1+jtLcsMYc7/KuRKR07f lYmSkX0+UE5RcPO77o1e0bJqJTv/GhmalRa8LkFfKUen+9aMjTiSBFpOf985Je3nzIs+1qbysf05 NMouAjiLd39skGBdCTQ1Tw4qo+2D8wNExQLRgqup6eqW+bTSV2+mv+WNr8zc+goAIcjn8ip3d3LX QuR7+zC2pXOddbRXquD5yzGaibEbsKgZy8SsdavvOBVH4lPiydatIXKkSYyMIibIPZ/WoE4zyEqd zvyQFAGUDCykON26QhJasBo10/nXvzP1KkrdOD/DnUAjA3+MNEbx+zRUQkP8J9sfBgSLrlySuslV 7AyCC085D/IARagJ2e3TsQYBA8pA0zxoiLBVfwu4SVV/E4X5Dyl0ktlONoKhndt7sUvY3CqxdApz jE+tutO3R5kyc7hgSD5hCh+nZ5CJeDrZEOWGGiFhjG7dS/phr6Hys2SpTMn7mwFyJwmaC5Uc4StG 03NPmrSG7qSoslL7bUeE4KuGAx4wYgT+dR3h+nwokHG4Dl8YR/DIMYSQSjDBE972anxOr9LUkCum mfZ5b+GKboZXfgkLIdXHh8ShmFbrKpanyRX/oggkK4OkhSgmexGLUJy0RHaTKYEJPLy3/geDcYLa vP6vqspwHY1biPAefRlejp2+TiszyEBA3ZNZx091uR0+83tK7gYXazuB/gChtdtfbTr3negQYiOC oClv0JCKht+jrKT3auwStDwT5jCYq3Z9eegyRqMYqgGwgYNgRE58ucbb23Gb+ZO9XbXCcjrGZQf+ 1vTiYJh7omjBaZ422pc2elrcD9wFy46MdzZXa2LwAygXktpuZzFMxNFTWN2rofnSZ9arqN1s/47z y0326jSd64vKZN3Xp9BtTEColItF5HjIWFgmQANvguVJnGdkoie8Fnx4V7rIfHsBgB9dZpUbfHvR 0j1C0eZp2uTN+9uRSx/JD8kGzHh1hOJv0pyilCOwa2q/Yr/ZHYNoj4i64HseOW8uKuJDrmWE6WyK KXgocrWk0LoTOJEBINAasfb+feSFRMKfdbWe772DTNyTTcVLO1EcrNdO+DgcZwCckuccktZMiXWw OM+uwjXAJV4iCZ4LlPUEm/36UweTvOHPlHILQD0+oY4arkKsxxXZ6qeIViLR2IMqzMew1LFLJkRP N7Xq+HB15TJxgZmm+jiIMJqt42QidAZbMmUva6iB978koxqdf52+cEj7/s9hQtQA7++SmKjlPNy1 7oRxZiIHftMW5KYxBIG1APHNCESnFhH0OzgK3apyaiftGaTIpR1z029X57uRdl5FgYh9e3vGd1EF VsyVk3FZuNwBJlx6ZzmJeok8uonbDn/gy8j6CM+mu+YuhTJR53Y8A+/zWLIp6sAJqrcKR58TIUq5 dGm74ImiDonRgECan3TFs2hjDvdrhf6B+LPJNzQn/ucKo50nFeV1VTFUCIBtwN0EkUQBXpPP+uhG DCDWxvsLChnU68Qn3IyFNzMBQVTO0/bgTCCLcYSrm3AVh/cpNO6hj6/yRLLLk6P88lgQmwyXmlm8 mpvmFgbGfvf+E6ezIroBbIVNwPuThJnHQtuSPbWJX8H274Lpy1/x0R7hb6iWpwMtYFp+ZfpSCQu9 OwNqUZmq3N2VeFxpKtMhjlDcvBc5r8AgX97UQI4dWk+RWRVPw1jh9d8vdKn6h2k8AqkKJRU+7r0/ Js679Mp66JO3GQUynLfPshL+GRszT16UXPg1ZZ6sHCM2Tr1qGP/pLrm0rZeSAIJX1vle9Wxsio6I WDhivA8PxVU7nGuPhJ+3tiwGt8nApjJR08+/8KG0H7s0BM0O2O6Uilz6gYcIE2HWVNZKc6d8QF5L 0d5gPlFg6+cL2eAQzys0bvssmHNdqQUT1UucUy8ETKuMUSoyR1r3WcPLoIiZEgp8HJRgb/lXCMwg yGR9RLSGVbx04kbOOABq1A5XGHuVYNUMMRjV2a2izk0yxlZuQrbA68oUR6m2PfuEe1CM8wwkMSQL RXl0QZ9CEEhrz30Mmug3FrNnLDex7vKeXiIDrDY0nJWWNuHEQbfTiMX4WLtUvUqXtH4sj5Xgt9db KZC00tXH2pHGQ0GvkMicMiYK8GKgZ85mhMLTEuEotwmuNYrKbEea2ilnjRj+bFdduCkB/g4bMLt6 2AAK+IryGB8QbuSnXjIkynlHLjEPTH/icjlxEiR7otiSvLsKp0J9peayS2muPJ56BHBczAIPWmzi KoBNwdneuIhWy1KQKrY1YDFD7DbYvS6dEm9xO+fvQYLgOMtgavz9H2NqleqQsXHICc0m6Oon56Im kkqZfvCisMT6q9sw5qanFqx7g29r+NEV9CxABRD7q4qA2epkUIiBhEGG93qApqA7foQu8KJpZNwl lCW4fJ1947FaoZmft2/hGL4ALbnY+PEqmM3Wtqd7PSB35NYFvyLnr5V2Y7YjCqYgsPxlvjKE+YkQ e+nuH8BVYgRhJXdbegctERp7lnOXzfuKHQTLp2kVb/XD4ZVEmZ8ZNdISEDd5n/I+l/SSk8mCPyLT NHFRKebkiYnYFKnSxZHY+6e+srNeZe6Mwq34oUkXB0zRnaPiaq36wJNXfekzzt1y31TWgZV9t0F0 DOik7bySEkEocHFQlaWt/gA8Y+JWRv+Xfq9Yu44LiZl+IR9e4n4vszK/15dVPjNj9I9kyyd98/b0 jASjBglxtT5pv6DcQWXOPvDRYjp/aNTc8lKGq8HHpedWxRmjnMHqGYy3IjASnG8Vyw4gLX1MCj/X fBuSO62QujZbXTGcnwo2N5iMYDRkQpnpsvcTBlRQ/2MT+B5A3IKHx2rqrXObDfjm5MRnxcOu6GNJ d3nMfBXA5l6rpgAbqGUFf6YTl6SKRnhvBOFDwdrH/bjre+fG4IaN42CGoXidv2w3AWouKOdGoXzX fX9F+mIzgSJdibTkIyQt9QqjFW36R/BIPVgThJamy5g7kcfpnzsf9SG1GyUTX5mv3sokpT4mw2dG qpRwLMEn8QmmS3v2wp87wdqQYOJiTgX7GmdeXfT6GdbWqtnF/CdmzBNWj14toVAmEniL4qdhrY+G gPqTzTbtNWbhPHgkCeRwg+kzAKznClWnfr/K4hnMcCOFXWWq7FqZGbQKUZV4nOBrRcWgo21bkzoF mOgPUBAoPe44JmV325gw/UspLvSeBT/hwu6MEwk1mzhS6hysCk+mC+iokC3wyywOYsbtH+VNrelE FPol2Zxp2FLNETpKd+HRp4X8XFNLV4eV5DD7os+6UNJkzj3SPIkp+5mfW0QP9cZQ7i6fVBRU7liH bIXreiOfAxhHAxx1Gbj92hJYHEf36mJvy5gVJrCIVw6ex75WZS7VAK6pbRlHkbRs38hb/gjKZrkX 1Fc2w45x6X/QceCZMV5AqYME4AKnuM5ruLyxCcyvyq3b8tBQMFgVqFdFDDo0awGe1m8i1JUxg+MI LtVulXjum0aL0qYpdLnKGBLiHJt0npaaAcCjNpMZb5S+spgfr01bBdebF7LbhEi4g0XzS/wGsQXT upIojlWpC6Muk98ESpPmrdkwOrewl6jmDDWplNSOZ4WynpfPtExvhHW6UHI6XzglVYg8Q4e3EYw3 5yYXMM37/7xEtY8+lGNN32HK0ZCzlJZ9jA/rdyxQjpJdfxYANjNrMZz0T8ZzWN25XOOgrzQQ72ih pZ/qHq2yoWluVSq+6hwD0Y3PjwYgcvApwuKSv5YH+oPp3czW3/GmE0Qq+AgWRWjRpDqDN1M8fwE2 A+uUG7lHK4Iqc4tWK2ffVdAcWlQs0NiIHwSQHn4sMMpHXJzFXAwF1SNV3sPkMqocilDJIJ22iEx5 S/rzCjvo5E4ELK4MNE+VkJe8uP6/pSEJT7uVULNm+8N1Db4hy7LAxlU77UwL6lGOj5r2PYvAzrx5 rT6u4MkqcYBEEdy+BvNdlw8VDwjyMYArdsRsvxlwQiJWX1GDmNLvZvxBo2MyTJ2SNpKp/2RilgM3 7XMj31obYJ6FiBtruv8YHgo5B9q+uu4hXuUszI6QdP7Sfx5fEhGqhndFpRu9hL9llr9JZIIBpcmz stEuKpladjKxrZcgmlL8e+uZU8wPWNT/b1ifpCfULRlwvysTEM4zoZGAombiJ4YjHDN2tpZ1muBr 49gCiiJXh2+myptw+LowWd72+DOHnbi5XQ9tgJyG85bQ8i/n2i4wzrNUKn1Lvu70CUN2xVccy13x o8ofozzjpxA/TIaW7zd1eBPKiSi4/gsV/n5xxoSUeJ0JdffNiIM6LRu1ZFnfKFPEqQry2BVpqEUc wtqDe6EPMUDGvlM7EU1qfN4vyP5H11VdNofMDNVRzPYbPpCO2a+XIbysefLk/CK0Ds5y1ZqDumRq pc/Ob3IBzJc4V52eIXmiInF3BPOxUtvSovDMuR+uMMRpNIiXYN5DUtZK0jiFrxm9d8w1CPT0Ej6U iLbTG2CwM9oe1XZ9sNGnuzrLq+qQmGTjonTSTwGrha/arPHpHtGbJnFfifJyjzVL6W87EUhPKGxS fHeFDY8JTBzQcfe8kQ0br0tMI2+448qJ+vmoZcRSgGlBzqE0EhsQWynC9bjdowxxC/W29sCwzInU C+fZFZFpRJg0jLOPl6Kz8MdvoqEf1LNpQjreLkd4w5RB1+bAZvDlkS26UDrMAp1Pos6hqZIAvp70 5+Zucv3jyfOmywSvVsYhZGraRiMPiyj6gCMmqvIoATIUuh4rnkmlb1UnGuITVtHeK7voZ+NdXYMi otyAmum9FylkRKu7AYAlQ02yxCiRNDyJZgMNMTVvAfY1SF73kUpkfUPq0N+UTjG0fQKHYLoWbHPo LjXrEUMH1u4F3MkRmy4ENTyuMGrV8TRIU44ZHJEOp8Tj2lgoveZGtckPWI5VgarjSdzs40u0eozv wEmhOfn9P2Daji/BNkX42TNHTqmAfrKLjIwcrofrZFTKYsmULLOMHapnKLexekjNs7B8rIMcxMLt gMefrRyYzp3PSW2f26JTVICwxmdS2IWl1DWdWAJ3oRqHLALDuuSaBdR9Vhn9ELFDtQDGqLa0JwtS bFDsH2NIplA/vsIJR56x4wUKBjOQD2lbFE21pHkW83LdJrwph3GRNQUZIV5r66dSdHlH5WXk6/oM sgoU+phHwHmW59vpiuXA/d3+BsTjul20LRw5NBvlKQmeSLmTtXSHTt1I/swq5aO/dIUZ0HCeqN8d VX3RuMTxbgKPsZEePmuj81jH+8PIaW3Dt/VBYPEred78MHLjJzk7cDn8rRuFsuONPGvuA/EUJom0 Y2+pYWZNuB9yBAxq89C/TQRNKNtqMBP8kOVqRuu8no5z3shi6WZs6DW6E47CukX9bVl1b+bDycXc z73ssJQJl/Eum2Orya2AfSiJKWoZOhvwn9eM5Z1XayYNunHms7uFCIzUdubPRvQvZCdX9X6SUjmr SGA1RmoDY5GGDJLXPd/Cd6iPkfpMnCwtDuJ/eOZvpB5xOIpL8DLzDB5xHkOUBH3u6xL5VUbKP3Py /9zRkHMryRp+Jah5Oo8JxX7x6xJ0V5SqO/6J7+xDWpHo1FoPxieG1uEhMlgRW9T27Og7jJx7DddM L/yYzAgy48YYuVWl6W/v+nFqUKr1AxWrmSC+ArFzsHZijRcGFQQx+F2ma9Xb2fwOY2foBaceB0NV Guiix4Liht6Q0ZeKv2eiOvLN5JriwuiBv8DnLjTrIo+qHNPJwxRvwfOhfBgFk/IGXVTfGhasDzrE G8XNATNA0A4Tw6+KxL4t0jEsT/Ww6eANT+s8hFclJ0AlsjT0yLTa1xG9CCurpVRm4RWula1T44Yh haaV/6FSMS5kFOcURFjCgm73+KlDZs2Hvpt3oSF3hNfcalZXSCDz6y6XjOcuV2cFWIwqAqeQ7COw Ik9oriSQeVcnB4t4xkZDUneHsaygjtlx9w4zJuGL51zTKJm0IHstI/cndZwTTz9Z3jtMOfxDGH7z ECxoCQ9HHKpsbfmCyu6PyFocQTFymdMuOcaNpVNUdtP6OBilpaWwDGjk1VmYXojTiUrG8o2JrKtx dQRrGJ7vHJ5MmUCpDtNRc607uiA0pxhDUmZBxmlymGF9Q0NK7c+yvWGc+a0VKpbOCkwq4F1z87th s9Vc8BeE6j8Yytw7O/Z+RLpqHtN760/n7XWAzyL3jeNEwhBqnTyaE64GDqxgF6uwSF2uWCYmuX4T nDdTq071PRv7VLV3UR6S8/NSm9HBTE8hgL+QL3wS2k43pa0Q3Nt/OYNV6nDmG2cX5jpdNU9MUVPG BOfHJKdw2m4eFOaDXoCvUdICGxkr+U3wbzV+6IgogVJHTRgKL65Or6Mb+MW/5m999ahmRhSVhIgI hCnFb4uL0WW0IDWL6eWr2/houzBldrAn4uJExYLgI/e3zdtqOGWtfo3Z5wH5r52wb4dmpx0XwdjM 8i4bpXAdtc9OyKfFPutNDEDlLUTGHek9fu/3mTXVuOzQX11UeK5GTFhO9y1bBEzhxZCHmfDr0hst lZIrvU1hC1ehUHYg+WaDpukfrO/ZBhwM6quQLZRtwmh6ba178wmwr3ATZwJXWtRtYgaA2D8nDW+A jL0eLbTC0Kb8l1EHkmB+rUsHj3sx1jP0E/EOVYGqqbeDqzLR351B6kNjsNKL5LTtxAAnUtpgfJPK k0Rrovw/qwlxrzoce2YEA39FMXwJ1A/GeLt89zoD2WPZhoCVx5sYso8xxJTxOc6N0cgzaQoQkKt5 oTXTkUHOIKnRqYc65YABqQnBcvqlosJqEhfUWmAkHiNTUhQqLE6ntaN9PG4YPIeFRpbcEW7B4kDt 63sxO9FtA7fZ31sqWppGllGfdGjXIi7gcbTb2vEV6A4sYDgxTDbLMFZ/ZOd23+9S9iPaIbXgPD9j HF0ajiRkd0svztT/d/EUKQRpDx9Vm2RiOp5/zHJkHb4lExRQBF4FLN2qTB1aZ8wM3wHk6Dly4JHD Uc9Q2yAB1nvA5p+IXHf1pNbJX02dUO4fELL0k/gOXD/zBcB/vHU9ZX34ybwzh0A2LNte1qQO3EFR xxKdEy/xx/s8zlMjb8PQlIFJHzylIjf4l/i6BitlifTxWw6ulsqM+uTzkxu49TwBwF9mHd4RWJLO QSfpF1gLHnHHSwTeaf3rNbB/h9vpJJ6sEJIm9WYP1iDQ84Xc8k9Zs0h5aZWiTVBu1tlVURM91KqW 0edgMEkYU3ckupmjAyEobXTpNMEiDRfw3iDw0qOPPvrqtlRyQILO/IheJB56GtQ7k8l3wXF1gZu1 wDrImBUAM7FDd7AhEW9s+uVDvuUHxBEhUD79MNi39XfwQtx5xzOdUz5EtAjSoj4ZCJWrWNQ6rNPG IcVONH+UAc6nmUFBRaXIwEq3S51fu77tV6Nz2lccEi4e4sxKe4KuyDcaXIeDnvfSE3Xw6U5KIQi0 RxqzbIYBH5razEbJabbEzLpjFHC3anLUKYOpDkJtVlh6hc8/zncKyVDkuAjVse3M19xb+1bFdMJ1 kHIb/ot5Cn82F9AIz8rc3e3KarbRgKy29o8k9l/wJ7zFWvDaP2yFOHgysS0I1oEsGojyCRrEPx0j 0WUMDoxt5DfjXlN8Ft1ZrUqk1JQz35t4tmHnmNAHtXB3MMtIbLj9g2V6tw9YR+Fq/4FobZlTFyWh C/5B+djab8JnoMBy7OQCS7GBozcsrbtCaYuJ77unN3XhsdX4C1SPZ9igiKe1/Sbw4eL7mSfF548m HDaHEfYkDXMSxZ+rhP6Al+6EaN6WMAXjVRCoXC5Ioqturb5FdX1fXqwzI+utSlc+fuY37eWIGZ8S l0KlMikWrNecy45PqYWBHHOcA5U1b2CzwQbRL1VSVkBrUrOI6AFfrVZOPz3UB7GuuMLZFEJXiU/s gHs/3SKTTV/gLjXNk1VQV6iAD5irvGbBDlAd6woODH8YFnrX7WOzjwQnWtBXh6izxYwrGtzmyzSo gpKbGVUTuD5rp3qly9+Mkyq1iAEnbm5uej4hHbETdNzv7mPS9YwmR79CThVfXQGQdhsx0i9cteV4 z8uxBDzimtN7vIO/OQ1sOE4HaIRlyC3UnykzalosmL73Qe/SytZ6OxfWxsCa9cYBoXWUyEhDQern oTD8EWCnWfxQgklZGWdLEcB7ZVep+c4HLlaPk9iKS+VIvu97k/LmiQubFrnGYgdzlFLXepghXzya MIGOlAcsDuV7HjpUc9Fc2yvaqfJbDxaZnw2AwftnWyvKAiDTfiHzQCzO13T0vd3IGkCwLMpBKxWP yzMFGlr33LghKiozBwaq3P5tUYAmfP5kjd42FCpWnHEHSeDQJ7OVC0iMzEIn40QFtiW97RArFzZu pdSKjfkWxdY6oVYadKMfP730/u2iKEQCZARaIB9q0FSstbtQsD6iGjVCn/I0WARuCHMSfeforvia 3VJqMdA4OjiN5uDpsKKTCueEvo/JWQclZp5g3NrEoJXmKbuOBeTT+Eg0sF6PRX1jD9QJj3xwZNLR du2pZu4Ya6SatGLBmC3olwu3Y+OHDcZpTVfWx/bL2q9/in/MIr71DXLlPmR0UnLzBKmbP9QBEZVh B7AHFKVZ0R07/L9oWgQGJRAw4be31gzqWnXcRgjsWZGoZ5KDHqdg/EP//4N8Oan+qqGOjurpdalG aMqxTVV+Pld4AqZlJq/SPE+GiAZ7qWhDCuPfluJwKJv27y/zJx9hN29cxPODTQD27qOK7ACcpTk2 YGb0O4zq0blm9FlYUWhITfyFW6RvQwT7hdkiGrsS6zMahjHg+sMNs/yjAuPsvgKIlksi13l/wN0g b6c9AmtpVUSaQEQSCX/SOGUxi3zEujNZlrvrucLo+TqF0/nXStr8YkTTxCt6qwIPFKDG42G1hDFR eMItovxQCyF1y/M1byfOatEWg9xSlCNWMis50b6ytsDMgHGTOU0RmmMfm5hJ0IXe6r5E9r14B6Mq TT/6BWWA2wmwAeB4wKMNdzNMQSWmqQYoSG3y50Ul2AM7RHpX6FXD9TkNHmhi5rsvDXX8irS6SvPZ FiVtj05VonGUQuZnGHCHyA9qb5eg8Kr4+JwY7ilSLGN5FIkE1lEajLXcMtDC8rU/dTSk46DlSNV7 VSqAojVLFnwLK6s64XlSiwM62NMxpkJJVfKmnqz7I1dQ4rD+CrMZ+OxqMSkEkRW2OzZx9YTjc8dd w/CDUAWjDERzqqne/Rk/gos1rBGRro6dooyPV+2IV08PFiRT10QmuOMe2UDvMWp4NLEQCs0MerVs +DQyqi3briAN9Uqo2g/7NpkV9DZMT5PZvaFcV5qZDDaqsiTOdXX0hADi7nabPMrB0+ZdAcarolxs tl1v9VET/wWLCkas9igr9WZhLvUEgUfVcr05ZLMmcAhunKVSU5ovxLoyTbbCVS9wtCpSAX1vSkKC OfOuVwaP3TEPHOmZJluOqYYK17RgaT1e+57tc/CaG78f9oz9Y6X3WrwOvxycYL4s779GA4h8l8Wb CnpOHh7ZbZeKEQPzjrHhauc6q8zwrXHdAlGKqx1H9jzQcMk5hUYdIZ0hgW7T41yIIn5d2zR+aT5B Eh+3BJMYXpcCqzOlgli8uRb5h3cLheJRDXa8q5bd3A3o4+EvXg2uxgbR/R+W6u307IAMzllml5hB 6zcUJNGTA09psXiIYg/14iHzXTEWnW79Rs0eSCSQ9IcpaYdcOL9nxrrpTcm/CJchqWERu4HLlwpz djWolLgk/rLW5cA7dSt8yJ1KCMRdU0WMdEA7146fwDGtpwkYYok31tgkdA03IbiIjowW95Hw9J7V dqO70ceYjjzPK3gBIKpkUCxcVf9KrlGJ/nLBN2WJE1pfwZMRyxstjOtFRpEh+HzaQPqBoqjwQ4VJ swkSM2UqPM8yqpS+fQIuLMRL0g5D0lBLnoR/c82fSZaPvy7lGUcem73jswRJdyWU59q45myBn8Ry Hb/iOE2o6sPp/esVCqcii6zPoWRNQq+q4lfvHmTFMiYtVxT3Ks8pEAGOmdaQO0yna1xiFkPuNKOt rF1Q0/jBjjsmTBaULan5kYNnPCrGdh910JZON/zhlf6JTPKhboS9zQ6SfXWMPuqGLfKkWHMPw5jG aIW1vNhgJTpzoCu6HGaYENpjTTW1jxP9TSLlEP96zSuinEHOihl9hfdOBsPny4mWQ3mobNux6wzf K+bvWoo5oL7FQYbEUOaCqewgj5LFzANK1bfb6pP8tGRqG5MJFaXg/yVKysHL6ohc/aW5lGreLnHo DLCVLDmP/HfCFiDpvHH5JcSm5QOFzNKXoWcFSGKOWdporlK2IMvexCWTp16ZBfkMvQDeJ5W/bJir AkQRDgT0V3n5ksDQDY4L0ODgFzJXVG15wAa+SA2yjNIpIjsjkLuWBI92Cmdk1ETyrG3kUC0WzfJJ oxayqt61tfWhCkCm2IFyD4ly6vCTDCG2dhVNdkuTPBhr1TxRrxo+o+b+leT4m+mBAG90zAl4PtbX waWsX1Y3XHtU0HxtFRN2ApVwoGegfGYpQoplHW9Bbr5OqQWGztbOyHX0MoBY6gtJhfwlozQVvjJL HIubQVGbVAAmQuIkLhCgWnwUO7ZL4Nk4u84+swxl4MtP3kRfwWxiwdgv1cky3eRTyUP3XqcPUUxY JrKvL58pAgP7pZv6O/Wm7aLRreoZkRSkkgSchyxXJ0USEJFkrU6Of1PIir9I4ySp4MzXrp5xFpTD HlBk0/DAudqOxMoXkrw1Peg6z+RTLh9YGXdxk89DjDK3L5lyHJfhdd3QOc7T2JUqFQO+GYIzQpCz z29GaKf+bB4/UZLLyNajxFXSoul8y5DH0rDhTkYl33vzd/mGYWfJfSvQrf9Jphx7ZY033IoUKWNV hWK/QwbxBd9uCTGuvtyfTFqufZtvmCdkePoWoKCRm72xKF4PrCEkDbDJauEgz5Vc5S6tUtxUy6Nm ifdoCmwc0t1DWSLzsy/YpDAKCNFCStFpaj+AQJFiQXtnTvW/F2cAways5d9FfcZl6dl0DeA1CZk/ Jn8LMuTP2fyLlSSTWpVM7C2I+PEknpAIWAw/e4xtx5m6vtMZMcyhs8HkWdnFDxx/qRZSyeKKkeAq 65EZWtOWe4RVEE3VMe3O2YAErGHhid4zJ6GPUgDn7maeAOIxotBtqggz5XZHXHZZdmQ/yH7hOPum i6Bs2xl2uMynlPRZ4bzNc+lsCTO+dox1TdTjhOHG7cjcEqs79+PpJ/Gz3i60LeU0gKg0mAd5/Vjx e2QWygGoDfU0mmLy9oleFlR8eObJK1O0jwmWMxEMYO9xMaqujZO+giQxhUkF/sVyxrLBojrguJZj YKe8qWMOKHjS1uV29DCFMnkgDZ5EnvIdVbyty/FB+zcG1T5OzSLyvyN4s/UfwMGZ7qJVEjWMUGhA FdHk2jQLBRsqgZNPDcEvo02yaNN1G5+Kn3ctEJ5c1Q/Jh2KyrOTrYTJlCcX6DTSF56cQSf3wXAem YbBO8YDXOlbtEReGmXJQfsklBparNKn3OTWWCRRxhJPIphX9F6MZAERG/649k5AhsVxsx7Ynn3Dd EUJNEKBh86oi+iFu1N0PVpQr0ym66NGVZD1tWP+PmNj4cf7tJJj3qfFUBIWqxpriqADJWenUabjp 4RGVMQVeTSAbeKs1dtqmLVKzv4Xsddbs2/NM7YbMQd8Lq1ZK0CvL8cwNAy96JqmmKqgNGobiKyvL tFbeoj+0yo0lxzn2iL87bRO2Uf66kUxm+DcbYWDGdLPEJMsYJZ8n1SofyCEZ5pP74sEmOj5HoONC uHlJTS059rncWtxsjBGsdXhk+yGERmpCYFMs4oA4MdHNcEyZ4EsghPR0fLPAELSsvLFCiAQjTKZ5 1hkiPPLRMNI0rg1HKNmXhSWi/lKPFxISS4B68q+ak0hHqKMKHPS7cqOyLz1Kb0BWQMPFa4Ukf43q L2Gu0rILbbl5cN3xyWl8/R/3se8AoSV40lZR3esVJGxqazWCt8N34qTKESLPs+j8h9/nudhNoWiN fuOuoH2MpASpDG2t+gKo9i2jVhjl06nf4GXLpy1+yonoNUYScOiQcEvN0qJF3rRa0xJpy62lvF+L CS4MpIs+dDXVqIhTK0OOruSqWghjXxtZIq3SYpM65ZlhkjgKDJn3vim0MmHAJZBmjgDRSM11v9CP Ho8j7dNaDS9c+1Cd7IUr0MGqZ8CxSMGOrfyHyZHZyftREr+Qyh+6gsqw1JaZApdvu/mSh0RIBiNb AfdrhexBMYs+tkS/QxzcPzoza90zKWgkpiJq8yxP+1qRByWYkUVBcCWfb91wbYQk3eKzMSntn6fB c6B6z0yR99pHWtL5pz5A5lpEGWXwfkH/UcciZfYgqflGuo1qj+eBpPToqF1J9jpxcwhxmU26hQFk kzmiLjqv6R+JTw9JU+25ZuU6gVT8oI4ZnRrBZ9BvGwJWNTmRa5Q1U71OQSwfFubm5Q59l5gsFQRU p4aWYB6abxvW1wpdCRlzO/GysM1e8qupwC6IGsLqAAnxlK1+/41YBwlTjxuSnuXFMuw0DXQ7IxhW Gi0fkEH+F929I0mgCNCJ9qv35bstcOolFSziFfZCL1UuXP0nP7p1IweHdCH0iPAem48RkIsofuts GOinUFcPUuKCG+tpc8AP6+OeJzPhcEG/Ko42Ru9yzVye8zvfEtIFGgX05lj+pDPVtyxAn0PPtPq1 3ZdVVYnbBo+majK1Rl+NMmiwU0LWkIRlKcvTpdO8PLhwNfBuA4hH/NorEZ6yep6mptBSbx61KpIC oGfwP0ZAhotvs5JsSEdmXGkp3fG5M/3nX1xRJdSyTN4pfcImcguAg2MJYXXhR/wZLwIp7pFHAfQ/ ZhP2OyPCG2zyYs6lI7GafHwl7B2Ecg2N/C6NgonuXBvY4YHKQPWn+exfLwQ8IVWHresToY3aMLpB 2LV0XbhpkxSSepIwc7v6Ow9mRrbzQmuuPkV7MnbqsAOWu8n9fwjAd/0s2BbF0J07efluVoO38vCS rIaOsA0tHPY0tG1z7K/wW4areKszIWIwqHGsFbWS3PhbaU33W/S7ozRCCujQCrdTAkBHeA9MyhV+ RIhrcgyWHjHlMxglNu3hsS6L7cishHfo0mTsp36CSa6sVW17f2QHGxGoWWL+pjwQ7HLBaZekpL5D 4mso8lXsOiuKye2ILwkdetjkTsvTe60ucjFnVe8ZaJ7FQV3SVXVanpjfTlnJVuKMcouDqXvs0dCX EDnul6BecmYgitF9Fz+SerY6uOlEkCQjIAmSn1bKjRaO3rxrixAK9XYBbUegMyupWf1oC4mYvT2g 8yxPTyPMi9C2OUooO2JP6gdIH2pOBGJZsgUyvxqfdpeugBDaeXuxrb8KQ0DVXE+iSoJIBa1YFCBM /MA9NVaAdhkHoYQu4X5/kpfYIYVJj49pJzLwO/kJZvNdfqHfiSbMZ7ZtOqCAw7ljqrikJP60jsHG EluXLPczhsIBGAKBvZRZHr7zgvp0AXS0sj63NZwuiIivAMbdyMC0+9a8BO6O2M7RYTPpywZRYa81 xpyzYmwhd2vLyjD6isMZDd+XLdL1G9qWEFbF8iIa8dt4I4l8/5YrQbIx3MoJmgDCYS/01s7ovuSw qNPcUUgpLppq8Wl3QiVtUmGoHINkdTBCXM4N1S23T5cjgGXQS+aLlacrE4WJzUTYEYenx1d4OdrC 2KF+wA/FlCkbsWPd4w2CxLxjc+EV5zy79L0tGpvS3ZK0CcWDlBtmY1zq0lPN83t6pExWyZskprd1 JoPbm5rtFyRVomqs5JHTNN0+FONZO/IiW3qR3e4+qnCiWsntvfEJBlFhWClXCGyP2opkls6CkhHw RVF3ZCiOL2bGcP0yJCCio7QyxZviNSFqf/VqVOvyDQpbIIDFijnQCp0OMmtHn1BiPbYiex3ByVqE iNYHyVAvOPhVzGdq7ruOAs0WGAdgI0IxfpTCYBxvUKud5GyYzJPTbmf6+JNzx+LTJWuiXtOJfEK5 CeRcCKHqhP3GiN/v+lEuVE31XYOXCPpPTs6W6jSvWqrKAzSZ10/LzWGrRK5b4ekWazasGCp8SrvS 9JsJC+I9Y2bobYjYKIwt9RX9hCFjYGgD+IjzUYysbCM9CNnZvhM2szZfzI+s61tfD078yEr6kAir Eqe8ek6AzUKYzrC698PDbO+rPOWRaKO0rBo0G8RaZkwk8zje7R8FBFTMtnbCcy2VYuDu4sHvCHm8 2dhM15OUxT5knS5t1rGGxwCp1O+MAi3ucnMEHXjXezwDPwWyfdLkP6Qc16s+N/FvhSTeSVStCZAa VZ5isidR0ldD1rscYmEeU6kLi5X4HUsAoIUE91ljdewats7aIA27AnHvMN0toUbX3z2nfnBRL1z8 pzIZcoOpOTkt98cib5uGNkhNoTRYwhBNs+CEtpt2hB0WLVDvxyk54cD1gxELjX9jH7PCZQUbYqVc sLZFzVUFF+EiE0eaG5KYFo9rWlDqygqVtM0FGE+0h6BwlVMrWU03KHW7Y3cGYNoWdxIZerjAQR1g 3xHKEY06nxMHIo/yz5PZnrLSYtKvwBFNikhGdmC4PZVVEi2ScR/srqGtg+gWGUEGlYvkGyhE/a0N gg3HCpPsKD57l27iVG4KW+DX/FdbguFB3pEH1a81hugUwvZjU/7A6FcN/Am8XnKbw1dq23XQs0vZ U1RR4aWExsl/H00hoe4z5SxkXVPm28bcY4LM5C+8kDvSq7tG7ZIU6IYmi6Ub3q9zYVxQMmto680e foSbtX52MdsajJhoHt7kgPlbr3tuaSBToJP+9isPizLqKwv6RbbUp4E26iDaTKWWBGSGJ+MYUhTI 5TmfZR7RWWYH+0L0MrcveL5eE6NFIdKzmh+3NwWdNVA6qoeS8DE00KQxGqscdmY+o1ACN1Kw76mO N++nzatryVdParUOKuIVZJ3gNnmdhOyE+uT275W0Ap7vBtByirut9jSu29Wqw2jpcpfIW5CK4jo6 I0mswBol4h1xDCpoUIR+7dUV3x33wp61u+U9n1+wulNwgG7G372Mh6QTCyr2anJH2rLmwAbZSAYz HXfPg2/oE7sHkvzkNWWVTVbLSaNyKd88Lr/OiRZBy15MhL/KQxWYtAJlI2mQpywCtk97vXu/UcNt 5Kp3138HiHRdubMjGJsVHW9YwRDiI0qtJU5RdJHbd1+yjlsdpCe8/qxtb9MpVZ+GboumjKM2RpEj cgtcELBRcM0uLkDJvDM7MlDxiTny9XKDW0BuHksEj8IzjZZoADyjs8342l9hRMh+yx/qGYJZO2ss h1ELHGGZ+umjvhKFhWD1GLEL7WsPw6YjzLhNf//fV6pPIvbDKp0XsnELYBRZWQr5OUxKBjVLiF92 WF7zNBix0TGaX/ZmJL1Nmoiv1i/DY1pjLZxTg5GKbvVABHNGo2hzmg7DkAilkUggxZECPbhaVWb6 WcGayYUgzR56IYtIon5d8rCGELkU/DYo8Xt5aIjg4GJC1lHVHKZ0yFmReCWNjscXSiA1AMvloIq+ 2k8z5ILswDy8nhroWaAavThkTXgAXq4z4Aa3whKu1KzqM+JaQvstgvqb1+F8z1RLWTUbueF9bqE5 rMfuGNvJdbLnxoc0cPXh2bH/tsNZO3R0IsDG54PGFcHz36YKoEUzuIy4SmQaHBua4qmyje84ZbfC GLUwp4gXVawwV5B9enFIqHMGgk6FX/FTD8v0w+AVDcXxsXb0YUMA8x/byj0AiViHO3gkax4It0Sv wwkU8W3XbzXevWRgMqUCsXftqUkiCRBf6zueQKpw9nwIoT78G93A8GL/GitzoX/P7htecA7UUKcU 13CRusgHLVlBMrfypj/4Mnfy9CRSF1egTA0+HGfGY1J///I7YP79VX5NGg0sGogB3SbVho8kEacv Vy4AmYfvlODFHpReQ8n1wF/3DlOabnSoz/MLC9xCnOCCH1aWEkc6+aRM5JMH7QBKkin9MzCV1Thw XEIQZ23hoI9fu+LFTmwHj3P8n3xhbJ7prsGrn+w70ooCV/EhYmP98rKIn18cf7lZLA55IHaethEA pMlaOLckNUjd6s9VYpHcqBBIceIPx5/Odp7MxYrM2Bl/B4hD0GyLTXJcqsd0Gzs2/o9Qes7xAeid g8Zkie54gnCyoFQCk4N8M0B9bas1Q4bEoPZUZrKFpTIMTvg8Y7G5tWi5EyF1NcIz8GSDjf66gR9E j21qM/2tx1kAfNfrGWugD9VfwWJ/peSp+StSeAWgdppc17jjSYlZrDrUf1+3bket/43xAqyMX7wv 3aXvGo6tIYBeRScexBxM//qt0SCwJYBuUaQewwCHmKpIqY5ItaLA8CnEeIgN5FvTnDjc39pMzrQi A65pbxkmKUO5sxI3R5/FVMb3sKQ+1df3WNfidY0dBVBPak/y6z8RRTwP3HJ3TezzX7qProgADVrM I5AYk5+vwk8Px6GYV2hnZhSqd+SB/1L+PWTOEnUEK5ztM+NAwQc7kifw9RHSHeR3f/ClKAPjbPFN 4fwPzmy0lTKIXq9b7GLvQIAik/mCjqjrvZnOLnUlkMOu6Za6p0/1ThoKqWtPWj9D/UY9XMAYkHYJ p4l6YA4TiFbpKuTgDCgxlgNRSCsaT4minCApJs8oYW2Se+pv+STz8AhhS9y9Z7SEltCsOwbGEZ2n 699kzFR2RzqaSHn0N/hNPnd0YNFjGAkwSlu9zVlZzrVXYr0vkC1pNvJIEkF0RqdaTNl7OImPT/Mn 2meu0Gx4QPqX0BcW32Zp2NvNo1N18Dfqe3KPI+VdoHeB2EvDMag867084PtkwEhv04bnT3BvGUDR skYHNa+IGY+7ph9KV86Ht1IBP8YT+Q7Y6ZJxgiAhkqmEeh2hmthP1rZjKWPUz1NJDUmH5Ckj4ad4 Bqv8p5OhmMP8EDh886ZoVa0PD566nPLURrlj3RQK4DHAs15tANFLO03XXmMKlAJvaWk0HCal0MCG Y/jS2rlTVbprEikQI442lwc+BFntInNijNAqkzcZ48GUtEZzp9F3nucsJXV6dhH8EhvVQU8DMR2D N6ngq8tWXVhhQARLSwSJNnzurLVenAu9IYZlEfoR8Q5AY75aRGJSMOTBTBKCU+q/bhA7zxVylJKp KnAR+AnXV2XIg3juOdvygV19B6A4xP4zj2MAvz6iBfflh5ikNJS9wq80OGHH43brErMNgd6mQx40 rDwLTn1GisuLt1ctHk9jIc1adOed6l/NidmyBfQuD3B5UY8TUR/1X9njkPcKBxduJ7fW+aC8HEf5 cLh9MAB2x4gFun11NorGfut4URZJoErekiFIMPfH0L2j0BeqCFx9V1VN8rHOHXEbGH578xiObDTX iZ3NI43ZR1aY/YM9vZHZRl3COgRkWRtdk0I6EllXH+LndCltqbCNPSQhla/asJgxmcrEbOUI299R qYTQejiEE+98DWbXRaS4HDvn/S2cMQpgt8sZ7Yz3OfRPX4mwKeTTHN8lAGaMqruMhUzylrNvz0a+ JB+5HL/WU9qiSXMK+Oa8AVY/p00dMCWA0YxuRchpid4F9o67jXpllUh21WdfU1czxyWGQxZMJpYi lhx/8g2ST8g1VnZ+/BcGVyR8ixFEOUDVUP3Su92AJUNs7yLt/t/tY7Tvu2M3kHZXSrQIWMGgmH2E EZFl6pZIPbRYtXxfdK6Eka97/aa/VKdfXclYnemEjMxgoj0bYBYc6N7NpSEJLBFuF2Vre0Lic4d/ cXDXXp3MNRBGOQTXDkJHYDVc0pq1xLYGMObBn6k39lRR6schClcsVwsEJIz3ZNeuAQLjSCm9hqxJ UQIdiwHKw6V4u/21hGMPC4qpcyqGC8bCZyvX/5aYcDw2x5ed9lbWDl0tK3ZK3ncnMMCc7Q0L5NJc fTjMKFlb76nK/q7t18pXwwmBWigOYmOfpB8xWv627G6dPt7NoWR4abtJS5JweB4rqv+E3zyHDRLo FmPrPb0MHanaVfW91c58gn7a72UkQ/WCFJ0dGFfLsQMKrno9WmW0dNeLHXAsRFBLy9sZuVT/XdwB 7U1UdYbNTJjrsC3SS/PrP5Cw57lLdFHF44ewC6xKsyUdcbOtHZ9fqmtaCV0SMmXUmSkJtbf030ac aXtnx/z7LhaSDpHfU0TDMViZBrqnP4yBrqCOoIs/thQYFsiFCb9spn9F5YOecgPn7Z81E6Ijsnvb xGU6nwpCdLM2TuwHQwnF0cmnW//OoEBkN5e8nqbXXmAq/SkBVVJDyOpDH6Sj9ZAkb473jTMfNbXx A6XTv3RkN5Uu5oQ1ESUrxALz7GrTr36XjnUEuZ2+JaGKbbyiOMD47FTRBiL2Wx21bLMYv9fsh9EQ I+q2XbYdLbl+IN8CD6GUkrHZTMW0rdVtwG+Arig0aKF8hw4TYcDSDC+3p2aD5zWDgKMeZXLtew4z YrKoqztH6SR1ZzAzza7R6XDPhOCXlIGC/sa4540bnBpLKhb2qZtbDCtRK98nuUwesljgN0sOAXzS jy9oQn72PjdCSLgBJQaLUWWccuu8ydWnLXWhu+jd3ilhr/WuJdRz4jYMmmykI5IJvQC2ndnECJTZ lOxGG9a5Y9d1rv2UF0Ojaat1OVC7nS1CwHpRGJhObslVwDHgSZPJub7eOveAa0VHE8YEzT8eWtrL 45gHu40vqb1m5vl55MTE2XrvWxjNW7MENtw7sqyc3maHcDX+6uexjIUfEkbabldT/WRKEyLVtFOo eLu3nPEeafzTAF6Im/juvaL8kq6xmJnRySP1bjQgHBgqm11PI1asyv8qfR10cX74WU9Z5QRbMk9o +7Mn3z+OrlIFMbuQlnk10BVECaz18EBCmwQnqLYbPxJEhpDjUqxOY+lYARrGfdPiurmTAQBigOEc jVZiDki8aIvDY5DVpUg0l6HrZsiyCD48neKQyC5Gb/TM4jcTTXcYpjvgWQRy5VxpJ4KyHTrs+E0L 7QNfE0ib8VB+qLccfuZMWltbieaLK8+71cG0rkYToC1FGoi6zJhJjDZxOE3cEHC9fj8NQP7T/80p rlUVdcAuSA41B1vzfxCEqDhOEc4ERwC6vqJ4GkLuWnYJxy3hrHz14ENWvcl40SdLO4CjCuu6+4F0 32B+j7tbFk6kHvGLjEYbVi5tTB3VtQIZhM5LcAPG+9fuG0xuoVfBCSCPG8Qv3QzlIS5O3A8AykEY PYdO9IqRUb/17lntZfyvUHYI/gqPReTMTtmD6iaq/1Ov4VP44no1GzofoZtoW1y0a4+CMxhQyGAX 1Uuhzn3xib2byyUdLhOhimIr7nBiVa8x8YifO0y/09g6LlgWZapqUbIwz/yXCujePt7jYvNnI/wM QWmHgXH6a+/OpT+aROOZjPmY6l7/+Ci0zEvBY1x+BvU9IBGjNEOJCjiAYFDPewURSkS2TMXVvSw9 crXAZvYp7xrhJJ/GxDLv/MeJM36dDoZvREuODsd2UY0sBoshX+dgViGAqzgTHnzmdqYrI18psiPJ dKeXaziJGQi+gHUALB9NYjGtnx+03ooiHH0HwjSNtrBST0Sz3gdEIseQiq2PSVF3ObBCGFrdensM Y7n/EIkJ0PoQ90Nz30AqvKF8EvfqQOd2eLeoF7Yq6a1XPiGGpz1gVK1D2GG98xDkkb6t2TvLfG6d kcGk+cFiYZ+q+z4E0iqjVRgwONi0UTIoUR8dXwXE+lYYM9RN7ZYTN731EzO+aPBu3kOBgn9bOnFu p682d8UnALLE5d6ESn+aZ1btnn7zGg5VCOo6moAJgQew5mSS1d/7LTHI0LlMDEqfuubEVhw/DjYD hztLMIDzCZFJTPKYkC8BYnCCc/7u9geeuNU4B50GqZlGIUYFQ16sLDVlqbJFZHS3ssrmnOGp+5NC MWVqbrGhXdfQ7e6/MXutJ8wKW4eEsdYLdSkPdsFAx2pRuYMhKQO0kBPreVQ1lrAXzOuWqgp8QSBU NOcSUy0gQiC97YZGWpmQIN5yz//Qrv0fUV3dnaRi3LYLmF3hhKZnVCQhUa9Dr7G+yd4xRQGX8Sxw ZyTBpl5vDOl+/llwnEA4d64ohF1mSRKeNbH+sFoYzcJajGFI17nXnkaJhnXeggdNVNK6oSh8VqdC MSSGKGrCZXUZ8rgc75mCO56TBzjohjHeagpza8xcV5jPcJpnDrsjm1WNMSmnCo2SAmb/+MXvOSxR zAB8fJ/ErBsR/A/AaSjmgDzqCN1hEVJWU5log9pJ8sXRkzIzqI4aP7LHcHnYkuQiPCgU1nIUv4m3 KwXE2NHEt3kOYSMPDY58WnqXAmHwsc19wYQaleoBPlvOoEGzNcbObq2D2RpoWzRIMjv+29tKaWrE s4xk6Lcfo156kNr8wa/BJeelSRv4Yit6u985yCR3mTSBGDXz6ivjCgBEm6wkv+o0I+FViGe4lkD9 VR2mpnGhEVD66sfYger1jzZLKwFzRTqZk/ELWhrM+2C7w9vy2f1YmvSc2OGvq4sDHcut7niLbjpk h1eaIx9DIrSHwwCLiIUq7Z/nwW5ndupP5dq2oVmdoMZIjYX/CNkomYoSa0VmNswOBr2mn1hfsrMa rSW0WyQMUFpOD58GuC/48y40m5B4RGDgy4MfdH708CYIsoF6u2IryLcl07TxrD4l0kp2f0P7o7uN K7o3rpqSuyaIoQbpz8KqVJ3WiNSkBfYY5QIr1P11/yN4i1X8mSCqdgT1BIZJM6sv1u7wLRndenDj o/FfAI5Ke+sIDHhfw+b92CpVH7gFqElUe8+lp+zcirWixk+JRdIUVNkYgAVVKWSFskxvP9Hr1sh9 FJisOWQWKiTOtiezOwjTVGTOEJgYSu28r0xTU3hP/Uyo6l97p7ylgEhvTfPs8Up/+ltaMp8wPSPq jKbh3I7y22epQC5D5YRsZGZRFAyAJMA5s3g41XxFeaUhTeYb/ojfFQ7tL3wsLZUdiXHM7TSKOmIT WE+0uHqamYQh14cZnMSyWcYBumT0U4E/rj5xIBVlA1fClznFzmycvfnxjWlDXWyZWq/Rehqsre2w y899hDLdr6GheNaJt8vXoBOgbsxiqkRGqhbMODDmu7Y3+hoIEzhYz0nfr2M3akCLhzFgEvLN4N3G vzQgdUSP1csATErroN9XbCn/UqZs1P/OFWdbSiattutSZ/7wbUYKUSwdzvKf2IGLUe0fDunyodNR fl6P4Fk6U22NJjs3F25sxSimGEBJkLVj1AssXur0mVd3UNSQgSsy9cFOStKWPD6+DRR8hRHUPjts gW8IrUNyM4cvxdqbp8gn/viLVA0fIgXksUxK8SwbdmxcD/4HoLm+yEmxvXD3o9Ih1Wx6wxgqjs8W n/yHISPxHnev5lJCL4WpUlTRNTOXk347esSRpIRL4dZ6HqAZSkGsEVfQEdDH6Hls7rm+Yj/BKK0H xIkR+iahy89Ybh7FGXdZCEVhhFWLpORmKSkBHaRn+XyXX6VbRoMzkO/7IW8KabiuMIMLFA/CC/Ap mX5wfiAN/cCZxX1nOe+L1FDQLS0CyIxzrS9dS8vnjepSxKFq07jmSwiHLEzSUL5QNs4YTiq+P07c J5RxH53lwbnRbAch7XGQ2/cSKU3dFgAkcfdqsGJJ2YIfC8WuXvoazji09L9LGOZX6Uf6fL4KxSop U2HAciFIf/k29rF/7O9z3aEsVj2xuKnLgl1XGeGvtJA1y8qlW+ZP0LxcUszFjzwdUdKAcUKNX15I iSLbxxq6iyhWlj6ulaQEDAmEJI++u8120AK5UV6jnQiRbdJPBg9Jv6BapzK1B3uhMSsgCQWYdtOp rXQ0IiNJ9dGcgOAKg1NT3jzQzd5ZeowZWGNm9u2lNG+MLsXVC8hZpMvZg0Zsn9jZCY9T1DiFOs7R Oh/EtYSJET9JRbmyJiIdunqx6NUFTqeB/CRu7r0jbdaPq4r1TfBf7aIuO2HaeTFfZWEQPb9cEexI XCnCYnegcnlT5jgEGizrdun20dnn+cUhAVddLLXwI1j+tjYOYqYvKm5q75QI9c6hStHrtSpFBAH4 b+RXOM3Lza4DfOoMVpUECIdzGKNAIwnJP8vA9UNPGHrfLZNwawoiRrUAnwl5lyStFp5u5J6o492B 4jc/TmsqMLv5EKMOiDDQc+vMyR/0Y91OPeiPALv1IURAxoZACl3V/Y0fdjJtUQRDAkMCBvuFw138 8tp6IJpNWr3ASVHU8D2h9x0Cad3B5OJso3FhD5MHD21dYtNNlRIxMHDTY0xJBKHY+ghb0r8UL/f/ bqjC6Lu2oiAwl4eR5cBlsWdC9tsWFk7gY556yXAYdK/Ii/LB/B6gWlvzPsYDC3BcwpwaPWDGB1B5 LaysrmyZT8Y5QvV2jB9gzyk0wxVnQJeh5OqvYjfgfG+xbUpgc3jh2+m3HVde5C5ozmYEfkOPaAh/ YSMhigK2X8fF1Vye2HtboxBTKVJVqBtnTUn/tGAu8xnY2jRHK8zrpvnQiX3ScYikTOM7J9KUo3QO hHecbvINbsn5la637AxVdOMcuAczZaLuxytwFPXfD7ciRSO7GRUqWJ4fPvlw02rEDpEfE9PEWvAf UUAGevahhOhcyBOE1uqY/Gix8ZduK0+KwXDinjC+s+mwY6DopHaEdrUMyCgRCHQHsCY+pICehgmp IgBS//wmcq28E4ROy9uy+MNN7ng+1FwvMALwGid/RxnjsVAsXV3Z43pjfVqN/wPeZTjc+KKqCtOX drj4PczvCWxT73QZYO4zHZGpcjRDC9AbpDC6MJEg3YSeSmeG345WzcCFv4cCX4EI1BwZ137ZoyuF JHc0bzkdWiRooW+xDgypJCv6APu2T4bbHjpvbaGl9kdcR4cRKb7VEkoJZ+lLQHktummWYwWtlzZh HR+6pUr9FJLe0fXBK5xfdtD+TVbKmawHAtNkI8D2mdU737k1M3vMyIQEvXGuu8sfuTzJiMXyzVWM GDY/eUmxwQ18ssHlhshRv/Jm+bMba+IUonlUJ1VL9jURThhb8ssdwasczb/dHkZiA/y0/t+XOXBd /L5fDX1+Tw0Z1Q3VQsd/e7o8UNQBb7VfJ7lDt0q/lVkXko6h7EJpoijG57kiAHDu2qH+yFnYWGFP S7aqVRLjpImzt/6izotSC5vHPg9e52tZ90VsL1LpDoiJ9fgC/yRKJyTY7BNPgYuWvTArB3WtFm4Z +ojhQbMsjuQgPIbVRs2nD8/E4VU/6pDn6oxTI/ZBcO/J2f9uthjWoy//m9sQKaFxVRWaYBKXXe9N rqruT3ykfRIbAYFO29T8BVPb8Bxn62cjsCwBXjRAcH7RIKrjMOq70X8D67ZGGZ2DovyFL4NmT7kL ZZQEMssDYbjad9y+RZUaOLDzYYY19KgSyHI+d7EfAl8N5MYErn0jKoy4uQPRUXmFFrEmDxEo5yoP bGWjNaI/6HeTQETcMSrYStQpivaaSZpIwwmibFAdMe17oBeDhcc/jBxI4dL8dLCrMUd/PoAX6t+a 5x46bc4QgeT56YBW61Prew5j6//1aKzlSC4TmoquUuNU5B0xdTIIXeg0XE495yvlsr6/2RB241tG s0kJK/oX2YXo+2pZPN3+q6evUPOffY4F6yvZ1qOKsujmiW/VxsWjyE9AOPU6yzS3XD3MzrN3i7Ve z9ydxxQLZODAVet3QJqks8JZdpKq1HHyNYe7MILjV1mZZFxSVS6sUlMV90n/6kiWN0g6owm0MelO XNvzlsvM3WEEZ5LjpN+/DIpVjtMD5r09yj3v0bPZIzjTtwn5Qfh0d6YIpBW2PRZCO7zaLI+OTaoe PJDlCv1FrAm+KiMXbzMkUAOq96RF85Jt5X8x74I3W3AH3u4Yn6egl9Wb9yN7BAG68SL/iWlskKGj s3bICFUU0oIeWseRcyWfNv+UXw6AuWqhssDJcihr0hGo6rXd7FhlnOaYTkmelOURWsl3uS/xLd0r zuwLAsIj0rRmbP5nhPNbjAlVrxsn30F7V0HOKX1mgRjS9uFbQgBs3HLJSQKsshc3Ukgf4ch7kYI8 H8CqlFq2vMTBRCVhjoYHrw0HWmYTTUsaCLMrPRwaBhFWW9u2Qh91xgLgYAGwW4GJWodreUpXIMRA 39YmimF9Q2qrKqP1xoCedCldCel3kCpesaFRq00RCNhRfudJ0TX0IyB6Lv3yLacxmT3pmF9z13/k b3GhYNaasJbyUtnZT/buQZm3U959XptZNfEVRAV085D2tgkM9c3gAVSvMsezsKrBnHqOkiEzvkqm MeIKu+FXU6kOiORXatYuoc0Y2qYHia0g2aHGJBSzJDjO8rv3+nwN9ioXANp7CjfABq05Yt9f4yZ2 h1jAZ9sECL+NwQ6EyPXyxdY3nwxKAPy9I/D+ZoHx/OQ1BJKrm4bqpOgedWELrB6prmySJqN1Wxy7 0vVn0wGuF4rD4Ff4e5jpQmy5ZNM4SS7ILnnvE/s2O+oWPEOVpmwWAFNzPVKRRHJKCILnDjlQezOl BFs7FVWFNXTwZuyomt4KPKytYR0fLZGAVkcLIBUfHtADwKQbZHfQKpw/IhBcqYhyA4OeOUYcZ7jc hsRgmpufj+FHwXBEZcao1Y91m7SqcQsli5AWcBTODNkC9gqQq+f1F/Hqbm9PGbPDxOvt+y3lUYOg opqXuqwgGCwbkfforLJ6iJeLZnt3n9bnzE4HKutfeY7pXblRHnvhPQ90VCMYGFS0oQCvMZICMpsV 5vWDtjm67LvkuJ47/QoDpFi9sbpQKvw0KuHGabAZIem7b9cDRNuEjdjQMaXBJp8TR8qzAUmHRAFW xihZLwSTQtcTuJirXyqPar10kQ4jU+hdsrWsIvSErdl8Ywavzm/d8k5qo6DgIV1yNBds0I19KYD9 rEFl2j/nqXW6DICB1p2mCCxZOlkcKUzwuVGQYwmWBWHaETsWUXCGFSLoZQwx+UJWtBX+1erOnDYj e7jFChsaZHpD6KhgYLiiF4YhhmF9HZZ3X5YfnAp4jSNgjoND/tq1c1rwZY6W7023XLmLb2j8WxgU VkrDAXwQUh2yZNE5x9rh0M5RQeKIxp+vMmdMkkmSq82T+V36edghLjQO8TNChlzCK0FKKGR/HF7B js+6mTX7RdOOv5jfW1UifEGs7q/b1kYtynjgzY84mIgWvpwkNHuYpIyJiOB9V1711q4jJ03iRBYs +5bzkC+F1d4QH+lTCvglIBUSaeDSkxhgOX/tNlXXyvYgfMfoCAqVCTbwC2+tc/+EMtoblJm5JE5P 3wsuThHbKmHisfx3GRkbzgEe0Dh9DXLoZCpdol5b6WDCXk1VbTVh3VEgWL1YAZhnnCTkMnuo+rK4 OkwWepfKkwku56vMKBmrWB+3kbPhzNAZealhmmaMsKA08WFshjK3BR7NPy9ZTZP8oqNTzVb4I1S9 nwMsn1PSXLdkSlCe/1wWr2v8tIMT39mhxdSNAMP6myhsSBXHWeA36n45tYIkYV5PkN/ONCLN8X7B dms2IwDWUWIV/bl/AJcGvdt/fd9u+Wg5YmIAmeHgdyGa936XhPhxtzuvV7/sjFuTz3qhmrMGDtDx cSCnY4i4jmuOpcZFMWAtK5HON8KGGqbByiaYpssOJLaIH9PyNrmTkO7p1GkA3QwBlGQkkq0+/TEf pZnEJFlbix2n3rbtbmzdXXLjE+zxcc9F61PlzBWshP8Mcr+QHsaCpzPpmfNO849S7S70tKMqJA6q YcKvEEeI4NkAsc1Zi+ZypFM91clXCM40XDWMURHc4QuYpPelW8nxc9+I8JBjT9qL99tBnHV27YT6 BqHMYB0MWv533YiT9Dbgy0mHcSo+00DuPV/MMvNOFIb9LqqeoVZFKrhc0VMQsaykdCwJSCjfgrNp m6d0hY59dW16KshNZbrvgaBHB3aI2PgN007J8/6KQjleA/vLqm14uJhQ0Wjmt9ZMNI2W8EvFytV/ H74bHm68OyqiSlOJJMRcOdKfooAHqnkkAfOdEh6z7ZU2HFj2c6Tuy7+7iDW/yThdSuIB9r4Fkera 0wVLngpyTlwhG5/54bigf2BQ/mQrf7vHNBUGxQSn89p9iXYne5yAXq2ObJKxDKeJquHHNGlqP9cF v2fmLLgDZ2fkfRl6CoDbDbhTiSYPZcwJ9mqMqaurIGgXVSdfsw4iUxePaOUaKVAawh1BhASNSumz CD6Q8O01bHx6ZFHCvB5Z7FUBrkjREGWEJ4TpIsr07yx0WxF6DNdkq8/eVEyc2Z2EAPgj2GHBCVUg nRVh1LRqloZx2HiLtwQOjGuBTucQSXfyGwPvQJMk+X4SipWcNxex8gkNF0Q7RwJ6onZh5KmQIYV8 B8NmKnhDgOE0H24Z7gtWfurcR+5gwzIro114U85aW5r5renuSFQsLj58Ke5fOgvr7O31vdm8UcIL hdkreRBA32FmHM0+bZfuW7mWqdgO4Aw9lMwr+X5opP/RfKfaEnnKk5UTSghS5jZJYzgXKMId+68s t2vL2P5wf2vDJtEeQM8C05KNRwiH+cvko8dihs4SeUNZf4zgL9MvnQaduwg6ut4vNhfBY/WqK88u nKvZ1ih5MD2Cq70Y5/+AiuyYYTej0pMs9jEM6z4Jl1FUXz/7EodGZI+Ypbg3haWvJIhYVplUvcha 0B4cwXWdtvYFbqg5Pi6bQizkY/OV9OQ6T9Nvvf//6hTTtPL0ZgghEPeaS8DcvjMYoRfzL6otkdvO fFy7X7+P1603VfB57Bx2V/UbR6Sj3TfCvGVdn1FER18FYsZh03V6VORFiOWRwebdL2tSs2alV2pf +6IPk5VYNXKfwjmzsOuLf6FLjdz9CR/bvVGEfJbg/o75xiELU+2OVuvc1YbGSAjSIw4hNXZv1gZE eQNpZohAeSm1G7ms653Z5AEFwZPLgr31D5Dzsv+uhPzN2sfAEJPEUWsmgbZ7iagU+kRzwvmjPMZg KN+hMaZQn5YV1YBIU7e4vekT4ilB4d5bGTHDSg65vpkn/icfbiK8jyjQz8U8huxrSVE0Rh9ePsKX HDTQ2dhKozoyZTrw1EHVHW7Kx5ZLZ+/cr65tjQz5wQisUJHZHN8dYWpYedtdppXnc5+JeKM9J8o0 ZPex5wUlDtlcLotbnaafSnX4uaNiqZ7R5PRqtS0fVTCY+H4LCmXmchoVZXiLPRAQcaKJeIKJb4+q Q3YIET8hQ/IROm3ire5bcIqfdBnNqC2Ef0HD4wO6udxfTgSVZCB2ns3lLi0W91L7dUtqtagcsS66 gaAX4XnBpElGgvoi7+1bEOHR88B3KeJGiU6UTmioRKp6n/lW2tO2KiKXl/6X+XioZG6DwmFefO0+ ORWBjobn2K61r/VnUXvh6WpbyWsyMN4A/K/zZcp+X2C28IssXhGgD8jGr5YTpTU/nPbFBG/KVHLx SJCe7q02URq9/tYfWUy/ElkhqGUgkup0JxXCP9Tpo74ZfZPNVkBwtWCLlQsi0I4DiRfHtDeoZdKm b7/Io/ZOy6KwxRKJDHiDydO5/96IFFtgJoqhSsFq/MaTskj3STfoaOI7+79HgdvPtqZCM4nJof1N hb6j3cIuVbUIKgsexh1urlgcO5pq4lVDL8lbch4F691fnLyc1idCwGEYIV36rFvagWKLlj9bgZKI LpSciQLyws4GucGJKTFz755wiqBN228F2zFK0hFGtuXH3lIq5EJhvWvORU8Act8JswXU6qFhgHSy j6J9LfP8DkfCda2atqvVpccmIX5mVYviTkYX/J0BZy7fENRkai0yLR3to4/decoP6xeo7qIHyhp+ FwGkBdpoqMe5poc2I6D40focq8mo1680ROA5kLzoRdGl2Bnz4bZGyTVTFVtsS/1/dGQAKlOThcya V0nQYKOR+FC/tvpjoyzAokSAk17AbAbgu4wy1cu+1I/tTcXZUIv5UrkUH261EOKi7LUufH9I4S7B 6IPstzqrMur2gpMCL0JHArf32UprrtcHTMyRyCrJtDexSogA+gLbhgXn3aA3+8V+1hKEEVSV7rEY U62JshnZWX86KYowB5U8kuRRKI7JxLK2p9OPWYe0rUq/iOmWhZBVxRdFKru/8KbR+wxgtk+DPF5U NmXOdKr8gTz5J9QRBXKxywEFtSHqcMWEJdQF4fhU9qPpmVb5SYTBv8M9ornbvi8kzSgw7J8NB3GT xg56YHlSUkwdL+Mms04AgVChWYmg0Wo4zvxkK3VobtfOChwTOaLmmn6WZBFKEhqbSSkH87b47lTX XKghdpadqXj92QUCbDd2zHkoRqII1e9Oom9IVbSL3LvsrKzbVpJBWwWsMoFMlW/yyorM3D9A64Wm hO6Dx13IzmroQPIum300dQQSJmUXyA5uwooJ6U1GSBmze5ZpFPO4PRgAC/OGaZYaPETywf8pMQ1l HTHeqozGt12r/V8f+s72zaP2hm6O9B3uK5L6OuhZ+LfUe+sy9PhAwo8M65qaoKda4lB7E1/2sciy /3fCHD3QjbfPVoT1TWHMbL961i4EIUYX76N27mUa3Z+auuuei6Z4mMaoza3wWvbBjpLWr+kTo6xY tpfIoWAq5JXVygZjFzPq9RKXqP7DbtFGqp8L7s4NIepR1qafSa89JFXBsiSpsz2VtCn4XjtYjnux 3TqAU8tc477Yr4qwXQ6XMay//Q7VqMpnN1FIqrDsnUnAOov17z67EFDsMVCHvmMJ9wScHB+Kx64S EkdMU7sU12IOZItPwp1bGDSRp6P9Or6niGd+CZkSILFAlNbUMUdDp5TaPHX5brodzd+fnF3rjUNF oE2/f9/txKej7Ziog7urOPCG7VszmBUQQTlNrG0Gw/GY1KhTYLK95+MKvlgd8BJHEOd8SKFX7hkF 0Kvso0T4k/pwFVDxfOxqtKeXja6Tq1+euztGH4e4s+X2Z/okyEd7Ie6MtfJGGJYZdwnkboCFBUYv O37e/NkClBjtTJUrcDMfXf59h7DGUDg2+EtknAurzZgjr17pjvJ4xvkuRIoEokzbW5dIs1QCacIX z5zEs5h2QlAU1tjaQw55/cwzeqrKTOrC1OMu1Jub8axfb97lkP6qJassRayWQOJ8tt0Zp51IPv8s /fvMrVqGJJlCyNwdY5rnBMJujq3y1D6kwXmrQ/Rjn/PV//cPnJsK6Yh8QNPYz0daf2M2muWygRBk pRKwYk94G1hZzpydO7l1rGpE6xZO4lGlAmwEPlRQLIDt3CUoHOiYt8ERyBroyFaeJqKflyZfjGDN g3cf18PQMIh9CQPG5myLJupZgncZCMNVbcDEZt91pKz4kivKyNyaQfto7SI/eR7RNO17bbmINinU ZQ/NmkXeOjHCpYgTTlrAxGCafq0CuzeHGysGbrvRNCAXQ34efvsrK2ICryvi2oliRATvXwvxHyEI OYu7uhw+aAx9Xe88EEewb+LOr/VYq4jAEf3fYLFHq5Bi/JEdYIUYP5C1MwsgVZEXztRWhtsI/MqJ oha9v6DVgmDOOS8FuMfZuocNcBhxrEP2/TSxdrmb7YU6zh8bmW0eUkU4OhEY2u1PbWFbWGzA4GiN hsjWkYNjWPShearGnnPZghOGOZV8NHBGaUU8SDHmvztZV2gwldDzqXZtJJD4CGK+UVNcwnDNFw// idHxtwFjZ3GaFzLYtoEbay4tn4jt0NUlB4vrjKhgzhXjjqhh+YzWqJzEQVwdsLaGbQSRzVlf7vy6 3D9Ez5gaesqPPNZ+ceLJUyIl7ymbePsmWyV1eoqjxdwwaE42jkh7zm9wjVrpf6YwVdZyKujNugq+ YCLoqS+v80hBrvY1AH56kwG/G25VHTuAgb5hn4e0bFOecPpbj4a2OuuFwpvlHNG0UlzSFBKo4P0A bEpoBFXyu3Fc6glpOI8I8JOXyzaT1wpdlHOxmfrR50kHG+cBi99t59uocJBzxMeW5liK9OfJCLsP aAqFeWttLTef9jOM9OAPb3Pd86IFvmxTVn1o3Esyk9Gs+9DP/sGyZEnnXnNipz64aZO/e5DvUVVp bNAzdBx7enMOM7aXxyh+ALI3C22HXgNEJ9Im6y23TtinvG8biAi+5SbHhxEXiB0MkD+IFdQtYbm9 PQvU49yqNt2r6ESLMVvEyi7q0zo3KVINyQM6JyOElZyijopXhFMUSgGzdUmI5KAM2dDHRaYOv2Mr d9mRp/Du7BfgknNMK87HICbIuPKgZZdQbauln7O3MUBGKUPg8y5hlz4KaY38EU/ecCdEMZP0f7UL oIncZK4wQr7+RLKThYJkmUIoEBhyioSjZmzIMwyoO9mUNZRzkHKItIUgn9B281+2eBKc7MSlcIQP aTWk2fOTfEimQ4M+nAG5st45AvV3O22UCkG44+YIiGB/w0iI2Nwzfc4ow+TKhqxA2A+bbMeC3aDc yqNzejZJVJeo25leQZMZ6/rD4B+RIYsLQJdqlwy2d2AdKY5gxhuV7p3C6k8FLwcqUbAdtPXKjpCo jfqTCR5ekRk0USN45aDA/rQ3swqm16V11mGXWbocCbnwrPwELA0b1sYQY2QQK4j6QIHfAx393noO 1cWVKheaTLLKkGhswXQ4OBnTVEU5DBH8tW2Gabl7Ab/hLRd0Uvwc96cIKR4xH0NvUsplU3wQAS9Q s/HLUROqWVAAekoERHAgvQ4QXpSzYw5VOmMAILGyeXnzYw197M2pg8vjWT5FOfZ/MpySqWVz0GBi aMrOb+ozY/kmCIr1H7nRWDO2ldxnNj8p3ChdF4CagiG5G3v+3yaKjUVtb9cUQTVgRDyIx92IcjUB 1wfAjDf9aDwbI4P8xGpmNZRUqtgrKmM51SEmTMldWkBsIc45M6aNZEwAaVJBHfTD/nIccI19gWYV ye0EvX/Rk5u/uKDyb5a4o8BY2ynhxROweohwYIN+rwu1iWaXpJfUkTQ12xPJI8l9pbamWc76IVMo f2jclovqzqLxSRWPgEN1tCuX3LQexPj4PBTIsCRzPjkgFnLdcbNv79plHMRVo/B73lTDMl642zx+ 2Ki7R7bfquIuWke9QNthbjlZh/CMgzW2D1eJ9G8wLhzjxISIWER/Mibo9mN/56CpKh//0NakIIeX ZkGrdZLIqZUYyBmdamg6hJ24y/V4/zwTXlYiPDh0Kcw0L9qtgHy684skiQsaNRa8gV+tiaaXz+sx oJ0ZhFGDxrkrUOH6FO0NDm6PG/+Q+Y+DD689fya98K+sxZSiPDje/56RsMFNP6CnQC0EhYPCqMWQ 6LxHZoXXSnrps/Fkf/guvq1JBZWBiAyBJx5Wd5QCrjGXj0uM1vzxHC5woQkmrr/WsCqs+V/ojBcI oouFISX+T1SMmiyQYrm1GE2VvYUuLDmsL93XtCPGw8i2HGeR2UHaeAhr1sRHoZx4NCgteW633jSi zSFN9Eq0ERmeaAkfTOCNWvK6gfxgV4GL/DNlQnJr2CA+PdtNVljxp0O1imrv2rp1LgFWMGIpMcUG nyP/vqfXl4NJppz7kMQJfQT/Yhem/67o4nHH9Vj2q2BFKsHelj2piYJ+USzorSrr7hBznVFcRQym BsrRjfsabFU4u6zVjLGnXOAouhYgJNFvZZTP/VbmSnz4hFgiPeH4MIJsIq/xlkz9S4FGHi++QgTF AOWzuN4uCcfQ+Iw+VzyNTs5DYL2Oqt8RjJDEkAsD1jC+V9pg16fMmS5R4jR/Rjx80SuyQ+47bthR ZVZCgwUKNX68RwUS4QAqsFnqBe3uDUaa4YYY9IPesCe1iOHIOhhOT8IldU0dIZWmkXvQJIVw6SBn 8ZGgadfChzVE/vudCFWKphhdzRgza934NX9T1yfLTMZXcHmNV6cUd20iJqQ8OUAkMtC2A4/jcbm2 JfXDqo3WNO6LCnIcgdda/asuzP/62grJ5MME0hxrF2OYIUoy1pmGZ1WC+ESQwezqSbTWsav3/rGR VnKmWCw5RqMmTxPMUWat3Tpv5QS8a6qLL4v9yZhJYf+Ikd3bO31Ske7HI13x8EyH+ovjNm6/QsJI +ZjB+QseDHzxzcDoGGFS00tu1KGFh/oqhpggEn+8FfxABn9uZ5OfxbXirYAllBABTAVHxfAvj++f FoD/SJ76slpET46cDjZTk1MhvI25i9mi7bYwPxPY+E9p0V6J0w1Q0y3EaadcdID/qvxFP3+ZK5ZS dqqVeaOAkYOaRZLYnZmX7dqbksBYHKEzGa2+MGNynnIdRmY99oSb77ooae/G8PE7Sv705JMUOnvG Uga92tJ5GdwAkIxkVfjg8dRMGEL9Bfj/U6aVzzqKmynEStlxARnNatZeGQEsLmkct3jf8ySCBWwd 7HgSiPv8XB1MX3xDLUOfcN9VPo88XKfZ/IJGMlRKu760sQqe3nj82x+UER3SIrJ75zRVJveUmL96 uIz6vUOv2vH2MdRVhHm9D6gkHvfJ8MSW3vCaTbbRe2dQmGOrRUEKrwHhpmpEPqFpB/5dsecnF1zd k4KnXLwV9KmwwVVsXAYr/gAL38vnhO2Qhk44Id4mIv2E8AubrpRT8r3RwqW1DV95cfUmElzWaKXe CjB5xU+5oKnIr4GKOJ/VPu7OC2KVGoDmdUJQZUTXhhs50/bTUN4J7tQSm8HM57VYHMrnvd4G1LdG ZL8Fqm1VRIcOzDgHqaL0sPLnRBEO9MNLmLcTM4V00nrB/vylxcc720vuAWeRZZ7bghrTx9XiufHY D3A3wzQyFBsLMG0ukvLtO4tAlT2AcYa3PMm+mq0+1Im+UAA2sqpO84QrPpFGBd7xxWxgv0Ea0hVb 9HRz+gfDZwjw3/1OdJjwNCnh5lzZq9tiS4jhLeg3Fy3VXV3rWC+jCDtktcF239qMo7Sje/8kYM43 /bm7fP3E3tM2Wfrw4Zq/sYsNBzRXHyAb+ik0Nuuh6W7uXfW0IMHxzIwPZpyIOx/ik3LUooCWLrXn Nv1u/gBqnH/07+BTQ7CjytUaTB3XZV6LtDWz5rwqjlXfbv5a8nYh0QYiPenpJ4ONofGT5TlDhHOG F+q1dD2zC31YmeCR9fffBp3jvBgvh/zDWQMWl8jx7EUTfY1oLX8AjB5YOkERmeKq/usRN9RpgLmd LOnM2GZUbh6HEZNU3VqCZ21oV1MiswmcGf5kaOuFt0aPQjpLLiETJO4Q5YXk2Qg+EGv93Qb+xGGY Gzl5mAy88Fc993Ozxhn+VVawBQyVfDhUDMibnbghTisfhhiFw4XFD13DRXfalilfCs1o8aRu1LNN v6cu4CgN+1qbGINGj3xl8sKXXL3IqYKcpG/SQqqCvcxnZ4xqViuAElW6Q32RATmthGOXjapDL+oH BdkcMf7rMvhzxJeQO2nonOk4eyQtUts9l7aK7B5AkC/J5vuaxOAECXLtR1JCWmwm8L49mFjUhxVg VFylQoM70efRH5wRWR8A/oGcClbUPw1BYodk4NZt622ZxVmwd5w7yRCG4lVachfifm2TrGnCjXR6 eCwhtM3pnkXjO6YOuU15gKMcxaYC7J46oLTFA9RbAwQaszilOE+2HC9yyIu81lLiQCf++a74b7/W rqMZTMNcuYsrdoMEbz1Fgnp6bsIaSqT2iX9N93Sn19hIn1HLw+Ydx9bvGaB9btYBopaaW3fNzdQN 1wy/5SPS+0q9k4vb5xOvpm1IvSjPc8J9yegYKHbfuLpsNXnl8yesuXq+K61PUIXQMOqiCMUuO0il a+8gT+ZB+5KD2b8L93a5Cb7V13fCBcdj64fJnPIrnLh6E9F16P1HZaZVt+qocQsxqlXQUcbV33lS Nu1u8jjFPxRl67PiFAiR855PZWjzPB/J+uSL739LksijbjZg70Bv3QBBTHILhm0Yl/mrd1qD4rTi FX/9O4YaUo4PTAz8ZoVTx8uYp5GYZ5g+L5fG00M3V2eYTSxtHwn74+G20kqY8mJ09PVrbP0vsKTJ 8U4msYZlbQMU+Ztxk9QbiYy9a2Ke0j/SEsddy6xSznfjfFmdoh9WPPuTAQvzj4taJhirkigPiFVu egf2DuxQzZXHnVj10GIrKlyirrTqmQcJ2WYAQRTmY1fyjB+AtzBD7oi84ABQRzpbG4wy4l7UCjru INSYN1aYcf2/Yl7qpo4N6ctkeVSeZLoj611wPOl+nvfRfLSDpHjpUNgOI3dxyA+Nj4BXG8tHNW6+ /SpAPTwX777VWUJXPKiskHYUJzoOdQNNPnnVRLWgq0VgtXvenLexEmZegGjJTnvcfTsKYo+TePez jphskbmaUenc3Mb7VzCpNZVGgnypyGxNVdXJx0wkv+54zqpmW1/J2CvGyV3KKyKUrVsftlvPwSLK 9EZ4C1GiZIBuhZ+Ckx9FxVaJZ54gnKVzqwwATvyeavJ/rIDr1a9XDqcmH1EhFLL2CNtLH0oBmHmY bE0vKN/v6E22Md2xqmvGxRXQRuBwcwJk0jJ994S30vOrj1tAxMLhsaQa+PgOrhd/mGBpGdOPKFnv Y6MRB2cwsbBXFdEj1FvLqTTUtNiIMnzEEhsdxCT5pqumsgM0wmXeXBtWIG2JmrnhfXHxrFTmRm8E SDIi9HtJdP8XczH9J2aDSUWbg3TGDgM8FIWwm/TlIs/x3RJOuOGX/XORJr5QDKqNbcIiMllECmy1 t3CkHd9m+Cj57RWyM1hHfRPzLQDxFBA/giLMpyf7sZnCuwE3L2AtOHJQKhVwIpjZ+/RtuA/YnEc8 eCYPEQG+GwiDvleuS9uLfSkygt+VPI0V2PounN3HMYFQRelTiG88mUaVGNFms8poWvKRaCouNM60 g5Gh0jHWHmO0pMuvarZO5jGpOvlF0/RK2TkFlALFzUVik1E50lx7oX/bmTq8CyGpNvDk9TlAchM8 B5tnZQt8twIXURFIYJu6kJDXOk1F16brCxOP2/DetBVobnYkvTFq+jA8yDQca0VqaU+pvdvRvSUj j3r17FtFjzOplRW6arX/wt+EGtoLT+ISv8YAKmxDT7+Wdq+B1bi0hVjNaCkyPGxyFAP36zcOeQsg 9sZdA4fVdxUk5hVQ2PTpOdFNazXndYXqn3Yviarx7buFVEigjgkvA92ZxVCNXt5Pp1hBBf+w1GTs rlgq+5oBWEZmurQ1slizbc8JYfUg5c0o/7gj4/hWHuwy7L/eJmLJ2BBwTakJ+LosnEUPO8qZedkt 7Wz12W9iKTMxMR4JXIc3xpXfsvhZXxs0rDGvEC51erF9LZ/jD9tF4UxhPf/vvdiS8k2gp0394Zry FNGB4HSSxQ4lF2ZMJWh6g+UVlh2IKjGkmD2/V1HSeksjdTGYY9b40Ql9miiVp10hgpkwbkha2yjb bcY+cCaP7osHKPBHPaqPaLmx0sT9cGtDYJh9O2EG4mORqiFvr+rNrKhGSD46PKzH324SInvO1VWF rduPsTEMSp+ponoX227xbucPAFokze/a8e9tM7o37GcTeu39+1QuShb3AobhagWtnruPn+BjMDDV Qa1ohJLjdtnQaEcfXMlADEb7L71RFPSKOt9uS45vfpxFUJdR1wjL48ETPp/HvotGpH8RHA8i1Z7X HCcOBBsmEgbbdWxrYMD+M2uJdbebRImkNJYrfP5yT3rWbe1y7gGtU7w5dcbJ4v6/oc/30b0qjqeu rD8Wj/jKVPpXB9Y1HwxwA1VfnjUXS68eiy+4v3kImpMlwVSifk+l9xEGyMoOTwzflKQjYWg/p/UG s37jDqjfdQOLbEvDld6aKKh25utEGB/Bl0zhFkhoMHotnP8Jwsqc2SfONNngh19g6RGSJLy8ZKMx xQ/At/Qh3qc4ijclSsDynniy1SO2S8cS3B/mMQfMaIgEsPMGgYeu8Bzp9O1QHN33DfycNkp0CkuT y6znj/nau6BNyQv1/idY69hKuaM3yxWdj9GW7hFOK3VjbOH1RSbmAIfGGgwfKVn7Wz0CH0RuYH06 JsQkBzRc5aJodUA84b+Aw5pjAU5QV71fNxmUJr4uqyVH42g6alN8URoMfUonyvrExCTnFS5tYum0 urHVbhChDhof3yKPfAjs4bUKP3g33N4kypNp+XDl+HAQ2SGfol2Q+R1IJj+gW13bh60MPkrebNcr GTpv4rcJbGnEauYKstafCAT3bLbsu2Ml093WhzoytT6Zye8n3D1uDWVuZHN0cmVhbQ1lbmRvYmoN MSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDM5IDAgUiANL1Jlc291cmNlcyA8PCAv Rm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yIDQyNiAw IFIgPj4gL1Byb2NTZXQgNDU4IDAgUiA+PiANL0NvbnRlbnRzIDIgMCBSIA0vTWVkaWFCb3ggWyAw IDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVu ZG9iag0yIDAgb2JqDVsgDTQgMCBSIDQzNCAwIFIgNDM2IDAgUiA2IDAgUiANXQ1lbmRvYmoNMyAw IG9iag0zNTEgDWVuZG9iag00IDAgb2JqDTw8IC9MZW5ndGggMyAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0Kn1/xtaGxOvILN0e7oa3T58x5w5W2jpSJjHv06gNkQS7qIxWbEd8B eiAfYn8xbLe1YxYJS+C364WrHJTxc+3lil5C8uy66sF8HmIaQR5zqukKCK9byFGlu1ysUIu487oZ V+uJFvSDLDsRs6ZLUswbyK3s8mcg8Fenn0KBdB20bX5SUAJYrZ6IluAbZqkotMCx7hb3Slpodq1q a58mvNvW4u33OXUGojBD9528ZRVI7zNL3wQQl9Op2uO0KP7vhDasW0LqyWyjckr1VWMv39ABuDgT FmoRUAbG8LI5PXSDLJArikyNu/iyXII+QjSmWtaW1hkXUHkI/fkklB//ebVzerQdOOe4ooYFd+8s 8NWvMFAmev3nA/ImBgUUHzR9D8yfLzgBOXKRmKonMLA0dlO3eyRfsQ2DbFkJDuRZOSgEHuSg0lKD UMiYodCh36TBDvL+AOfsUTGHn7eUX3jbDjwDDWVuZHN0cmVhbQ1lbmRvYmoNNSAwIG9iag05NzIg DWVuZG9iag02IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNSAwIFIgPj4g DXN0cmVhbQ0K33N38eVdgQW0fit4WIQ7tk9/04X8Wdq6E/o7QnmriJC4yQsVyDOu0/wH2mBb9ldR FmWYwIDnomKPAlY/iGGVK3Zyh687VuwBur9+UwbgiN4qOb18FAfiB5DSWSi2iCl40mcilwkenANq SlwYJ+mAqo36QjxRJEP58TmjCC3t03nj3K3ty/AkSw42f0JB+vPvb9YGg0JUYz/YOoZoQFjUCNua fe4Xu5BOlXaDIR0yNw2cZAeIZP5W2eFbnIH5Iaf1wbP4W9L7Ba/UI/rGdEWZHwJj5yRT9aB8P1lc 1V+dzFI6wUoyFLx+xeZQtv+4bKY8rAHP/Kqc3khJeRUxd6bhsmPqfaT4tCJViQCnWnV4dY3xClEr eItC7Pvc3GSglaEMBDLTqxzuiHIoHxNzBb1Px71vEoRM1nMYsxv+xfid04AfdX9n/V/1DhtnN0ay 95gNRwH7jtRw8QxStpEs6VwaozmCUdU4k0bihhRs02h5qsw3pdwOxiNkFqOHqOMtY+/YsMbGjiNC ctyYJ+IwkStzugFYFl151/Aj0Dxhjb1R86I/wII6AdsX4FLUtOTVYG9r0ZqGCRMvyYkjQh4zTNNK VDOXzj2efKp9V1Oz9/SnIiI3+rKl+3+YWpPGpfBCD/ObR6vbBp/7Hl/6slFvF0xO/8olxPLgYzWS BVjWVwuhSNEwj/qlKrLGoY6yWJc0G2MDRsz8YSr+J92wBfKjKSfvFspDX562u0kTIXq3Y8+LFOBH TUdBMAYdJepZF48qTxV5eyLcLic29/DKktQqL5ekyCopeRrc+NMXYsKgTWoypLvIjl6g6+Mnc5eY N/pF7qqZt0h4TD2L0FCSq7C0Zp69I0ZrGXAwzRvvdm8ygGfPJjFehGSCrKr7DOcsjiaTEIXmymWv iDIupXe3qnVWZcsy6CcxrqSyK9llyKXvXxTExLH4bu/nVSKGMDprgz8hV4tb1KWpD9XR6HUu/UOa IkA6LFEJF44CF5u8Zs4No6Hb3IzuN0QYyRclCVW35XEY0x1LZhw+AWVVS8bPfryPXWQhrywpFamO UTnkHPWD8IXw89ClG9Jp+smoO4ElG5Y1JbTC2Z6mKuK/kW9JqWM35byt8b69Kzyf2ugmxs505NoF v23uxOtbe/XRi8G78E1j326wxVHd7POuYH+VbRRxCeCtgRZxj+kCQTVsiLdSnTOHZdf8X9hCWrqY 8jtLw6ARJtSsoy/Xne5rpjTNtP+Ba4nk23uEC0M6RvzVvDNvsWg33T8sMrQgIle/4cq3vzpfPTkZ ZRam2h4yuX6EtyZqDWVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q YXJlbnQgNDM5IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUz IDAgUiA+PiAvWE9iamVjdCA8PCAvaW0zIDQyNiAwIFIgPj4gL1Byb2NTZXQgNDU4IDAgUiA+PiAN L0NvbnRlbnRzIDggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAg MCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04IDAgb2JqDVsgDTEwIDAgUiA0MzQg MCBSIDQzNiAwIFIgMTIgMCBSIA1dDWVuZG9iag05IDAgb2JqDTM1MSANZW5kb2JqDTEwIDAgb2Jq DTw8IC9MZW5ndGggOSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSJkieFOX +LnMyeA8k9KrCmfrqFXE73Z9dZN146k+xyYwGUfg8qWTCnYKG92oHTUROAlnFV7QLGFLx/uX90iz N+bQlgT23/y+otEIbM/w+Nis3CknMsidsK7ekIIEy9oLZjQOIgqElW2Ro3wsQ+tjW8/CzG0G8IR9 WYSTwC1k3UeJOpns5hRLpsPCPSwZbp9IeSFsBjLGSLuxnlCn+tfypseN5DIybfSO0/tm5LW3jCAv P5yXENTFOah6LLI4by8qDbZMLSf8ld5TlG+pz/Udk05/RZadA4a4cXGjmWexgy61NCbtBYn+ea2L daMnPKhGFjz8dst/ESmYnq8+Svrbtwq8y/Q1gwNkq2XXiGLvA2x2qMOBbmo6U/Uwg0ENTkb7k/L1 qrvskJUGMWNfodBpbEjpvJr7MnGXyC0Qf+zjFbN8/7xHWeDO35Ap054ElAhKZLuuS4ULDLYvdZYH DJ63DWVuZHN0cmVhbQ1lbmRvYmoNMTEgMCBvYmoNNTczIA1lbmRvYmoNMTIgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMSAwIFIgPj4gDXN0cmVhbQ0KDR/3JG8rwDL7cH8r 5YEC7UjZcKRdg9k86oN9PHunjLIHc8FnsvkcE3UbNdiOjVx2iYAt0VVPHTLrrfWgmvLWsihKFjrn rZeIzkxQIt/gXi/XDaIaA54HKlz9xOceDLkkJVsjt8m/hyNo2WrMpqcVuD9GcXeD0k8xzk0MsW32 d0Gr3A73MWh5M1PZpFURDwJvJm9rhPL6KWOjBdV3LQNN7yVUMbS0KIsdE9knr4Qi558Z+RFAwvF6 FMe2sPyYQ0MZRjMmGv93lImkbsvQFgCpwWrhqOYy3CHEQUSmFWNejdjeT8jkGmEe5fhFSf3v6HJE 0UoaksvdiLR52TwQOSpmOd+oDMRYfS/cJX+Bm2k7EZf7l9HovYQfKckFoF0qqNgJzQbdR0i7NrSa fhTbgM2WeMcbxZtFrQEoSBUFzjizdruO74mPoeaVvuteIGnTqHNJ6osLrdQU/TjzcmbHSI4fsocq BI974mL0IpeyHVCAMDp3/XknezuYaAKYlLPq0otFNuoaUCs57bOWiL1CaF2BEWFDT/c5/fxakT51 vPitXr4KGT6NkEW2bthItlN3WPQZ+cGGBu+c+ywCPz6vtnQtWxPLKRraQDClj1g+bykv52EmB657 lg7GwGWfLMuPb85W7y6PXkEM3tDNien2EdOHcSS1lDiJ1b75U3JqwdBNrhjFmalWaQBTMa55veNp BqIm91mHbMeVparjfXX4ziPpmOaTRZnTFBQBapco1qAJ7GD0fTsTXikRnPmt4VoODWVuZHN0cmVh bQ1lbmRvYmoNMTMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQzOSAwIFIgDS9SZXNv dXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDQ0OSAwIFIgL0YxIDQ1MyAwIFIgPj4gL1hPYmplY3QgPDwg L2ltNCA0MjYgMCBSID4+IC9Qcm9jU2V0IDQ1OCAwIFIgPj4gDS9Db250ZW50cyAxNCAwIFIgDS9N ZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0 ZSAwIA0+PiANZW5kb2JqDTE0IDAgb2JqDVsgDTE2IDAgUiA0MzQgMCBSIDQzNiAwIFIgMTggMCBS IA1dDWVuZG9iag0xNSAwIG9iag0zNTEgDWVuZG9iag0xNiAwIG9iag08PCAvTGVuZ3RoIDE1IDAg UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqvQ1PxLIRVZTWextWI3xezvzyMr9EN 0bZSq09e/i8O7Vi6/CPsY0VnofIX/p4WQ6w4sRrdzu6w5a6/5jjhJatxa4ITNVuzmDSNTlfdljeZ BMGlJW0LadCYDfoE0DOB9UdjXXkrAhgwKTfxCPfRGrdOI5M9eN5Y1Sjj+OfQBUHsnsxdMKppJGQE TzAHXwoWUrD2NKJFNptprkRAUsVDAVcisBDTMz1gtwPW7rCiPUbtDKwZUBYcGraHjrxgooVbtcSW PM7Husfk7qBRlnFjYpfAj35LmRc/qeNPTT9K/Y3vw0vZM16SY7KrxwG3OrGt7a8lbhyMbgAw5994 fcuCgHQa9NW1bw8S92IKjhAdyk+zpFZqRd+BAbNmZ4edn9Hg+WZ7sfpp8Tgxo6gbC5Yxg5MaJ6Ib YY6Ux1ztBLPxp+BipqHr0C5wrMF/fXKJX5wEJOYkFAXDEcFucpWjkxWep/UNZW5kc3RyZWFtDWVu ZG9iag0xNyAwIG9iag0xMTU1IA1lbmRvYmoNMTggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAxNyAwIFIgPj4gDXN0cmVhbQ0KaOub/WuZ31Lsq5Ql9UVVjj9VQbWIGf0Uc8z2 xgBbIlmnQXbVgZjeIlvbWhfH1rjyffPcNWS/u44u5avtOy9HhikBNCDA/JExjuUzmhmWX6sovkRW YAL/7z4D2fekUCuH14+QReIbreNkMfE+1xW1yG5ZGucCreaSjngpgd2sql4GxeZcxAA8o2Fo8UHW kzGUxe/IdfrPWVReDzMmkc5dZqbn+Trv3F0MNhq8QDOiMaVWNp9KzJJqI3laGxT7nSCwKUO5Ljd5 Z7CwZ2K6AE6MKNkzY+hOiOfIQ30mL45KsAw8SeREBVf/AMsrprizRrWdFjA9TcX7kQ/WF3QNNptt YISH9i2jjWCEgcWafXPe8HHQQUvQoDVNbraOmte0633/1ax6axwB0KRXqkqM3uuTzcKebYbKHfZO qUKTZBJX7qajgWQ+pEq5upf7cHqureRDS9tDJc1tV8N6J27Q+ukqCVr8js8X5YdI4gyUxqGeOwVc /InxTAnVpxv8IFwtF6m1M3JLZaJ+vyVpW4iCORIooSTZOv0N14JtSkVE37/uRK8QzUdE5/rl7Ruh C0w+JxP2CQf2u2Tle0M5C/tegQdgSXa7sopYQmzqJ2hKKQ0wrDxOm0m83XxokKzVWiXmCAqwEHJ+ DSbgeDiu77x0SpXivIFHjBXa0/dnnsrYpCJhtqeVjGYX+y5E5F022+29VdQ98Jm9fOa/cKNYRHeU a0qxOo0MauXQscuoTqiaYpyhjYH30X8NYqsA+1VS4YKn2K3kn+J4D4JaCQreyczkDYMF8ide3uR8 MJy2salnDGl3fgdEySAN2Jz5nf3nglLr4AihIAH5g++0qeacZ1zW5ZcYxNrBHHCAZRoY8k63LamU 84uBbl3AWs5Ed7DuvwHiEn6QiZjIvbmD5ewmHXDpbAYGAAJG4W8LEupJuQk/Sh4omq/VVAO2Jzrn A3AF7v+lnmlLBibrGmopvbtzof/635tLWVEUeT55iCuIMyBCc8E+e2/ZmM1uLLxAbfi4L5sUE+Ar 4ofHUVj9AapLokej06zgDLrdZYNKRm4zVJJLYQ6Uv6iPIrCEQNGqrgEGNwGu27stvhf34sQZNi89 XC0foig9jvdFRRL/R2DlniN5cOzhIKvc3u7KLmdtYDsoQK5V0JqXv4gxf/1FRpKR0/7Gc4FEImP5 AoLG3aEr7GBzdZv1iY6tIDvjIgh8UZFv7aFhaQbU9x9GUZA8L+S2yJwh9K9KCfGIWqhzMfOvSDHC 3HFRmazYq2F7tCOSmwIsB2WYed4foIrs3aLuDFPjVPoFM6UjPIS1Dw5hvK43n+ApHt5Od5tyoh4n qN4aBMGNjHVIfbGQCgqa08VJ+BA63OH0OBA7tSHAxmlRVrEvD7Yi+nrwzvJhnpifo1JAvL6loPcQ OKq8o4S0em9M4WG4I42bjbTFqTctMVSSh4hm2uZIoIuoHHeL6zVfXGeIv/USvcAh9YsjEMTvmLgD KGGEJvHlxdJz4vfIy0VbvVZagi14/sv6lmN/g9JcDYcuFa2E3maKFPGTaGe9DWVuZHN0cmVhbQ1l bmRvYmoNMTkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQzOSAwIFIgDS9SZXNvdXJj ZXMgPDwgL0ZvbnQgPDwgL0YwIDQ0OSAwIFIgL0YxIDQ1MyAwIFIgL0YyIDQyOCAwIFIgPj4gL1hP YmplY3QgPDwgL2ltNSA0MjYgMCBSID4+IA0vUHJvY1NldCA0NTggMCBSID4+IA0vQ29udGVudHMg MjAgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQy IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yMCAwIG9iag1bIA0yMiAwIFIgNDM0IDAgUiA0MzYg MCBSIDI0IDAgUiANXQ1lbmRvYmoNMjEgMCBvYmoNMzUwIA1lbmRvYmoNMjIgMCBvYmoNPDwgL0xl bmd0aCAyMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KvMQ6UyNZxiWEtlHv H3JUvUrronzrLK199WMnJHZmgOftURBB+dTIThMG+G0shpm015K75LKUF1zUr8gUj3FiQlLMdU2V SVXrPozQvddwYvOAg8pF+m1Fk7oDs42MGrXuYlZWUhrMvuE0EF/V1R3WpxybyGLmIxr/V6kdPCGw g/jMuBOODF+Tj/sU3CkhmDvqG7PblK48MCp8wJOgTb58kKMd/LZd+AQT3zIqpnvPTkaNP0INP/h/ CUSrx40ZBtyT1xVmu/h/cZdafMe8HGXklsR4hR6UG3KBXQfQsYk7Y5QCYkGB1QpP3czkw3trv+F7 G96I0fmfBcurE7AW/TLdJ8fgD8bX8wsA7FseR+HNyh+5UaM+ccJldgP2YLZ4iDiltMJM+++IHLOb PtQ/yUpz7UT61UhqySXnKYOmqFoD68HegNGxKuTdQsTJnfMi4KLdT11ffp4KociSnwLB6x4NZW5k c3RyZWFtDWVuZG9iag0yMyAwIG9iag01MDAgDWVuZG9iag0yNCAwIG9iag08PCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvTGVuZ3RoIDIzIDAgUiA+PiANc3RyZWFtDQr7ZuR6DNY3pw7nkzxgpqFgYWVN vJgJqvEC4cL1xJni8hDKKbiFR/Dl/+qmEFGPx3o1wQpfLBprIpH2RWe3zU4JkOhK6n4s6SKWV9fr Lwkua0KlxMrw1JrRF66bt3n337dTaguHcdCkydUO/u2elctuCDGm8oHsFfkB/dQdUDEDXEZZvOcP nGQUoj09m4nl1L+vQ+rixldIFVouUTMOkmV5dYxKWPFKSS/gyRExqSVqZ3HdmI9OvTsxQtkjzJsh tXX3+rtQWrLHsRVm2Fy8Smg6nH9L7VEGzUk+K5GH9MjTQglSJ0zYR6HXfTfArAo3eAQZ53cuzyav gBm4L8QHT0AZEzdG1fUXCmoIo5m9onc5oFZxm2in88fQZuu+2MKzthmxsC5BdlMNElkGXfjtJImD OyWgRwMcnn3dvm2f0fmoDbJNEDQRVvPBN0MgMpr4hR8m8yQkPCRgbalTP95/JhLkLReWtWi0ofd9 plaDPC/uh/nG+fyNoCzkmywS0rLe17VNyJyYEORNH4Cs85Gz4ed8R8tbkLYrpjgMWfQOuCkcfgxv jntoIRZhHEb3Y6n6xHF58KoSsk7F5MWShiFg9fn8eKct4ga05XOkEMWnYb/s4jPfo74PTAMiLdhh +iKgXjTr06Ju8+C4q0jQ9BJYPlKlCRXMwA1lbmRzdHJlYW0NZW5kb2JqDTI1IDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCA0MzkgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA0 NDkgMCBSIC9GMSA0NTMgMCBSIC9GMiA0MjggMCBSID4+IC9YT2JqZWN0IDI2IDAgUiAvUHJvY1Nl dCA0NTggMCBSID4+IA0vQ29udGVudHMgMjcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd IA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yNiAwIG9i ag08PCANL2ltNiA0MjYgMCBSIA0vaW03IDE2NyAwIFIgDS9pbTggMTY5IDAgUiANL2ltOSAxNzEg MCBSIA0vaW0xMCAxNzMgMCBSIA0vaW0xMSAxNzUgMCBSIA0vaW0xMiAxNzcgMCBSIA0vaW0xMyAx NzkgMCBSIA0vaW0xNCAxODEgMCBSIA0vaW0xNSAxODMgMCBSIA0vaW0xNiAxODUgMCBSIA0vaW0x NyAxODcgMCBSIA0vaW0xOCAxODkgMCBSIA0vaW0xOSAxOTEgMCBSIA0vaW0yMCAxOTMgMCBSIA0v aW0yMSAxOTUgMCBSIA0vaW0yMiAxOTcgMCBSIA0vaW0yMyAxOTkgMCBSIA0vaW0yNCAyMDEgMCBS IA0vaW0yNSAyMDMgMCBSIA0vaW0yNiAyMDUgMCBSIA0vaW0yNyAyMDcgMCBSIA0vaW0yOCAyMDkg MCBSIA0vaW0yOSAyMTEgMCBSIA0vaW0zMCAyMTMgMCBSIA0vaW0zMSAyMTUgMCBSIA0vaW0zMiAy MTcgMCBSIA0vaW0zMyAyMTkgMCBSIA0vaW0zNCAyMjEgMCBSIA0vaW0zNSAyMjMgMCBSIA0vaW0z NiAyMjUgMCBSIA0vaW0zNyAyMjcgMCBSIA0vaW0zOCAyMjkgMCBSIA0vaW0zOSAyMzEgMCBSIA0v aW00MCAyMzMgMCBSIA0vaW00MSAyMzUgMCBSIA0vaW00MiAyMzcgMCBSIA0vaW00MyAyMzkgMCBS IA0vaW00NCAyNDEgMCBSIA0vaW00NSAyNDMgMCBSIA0vaW00NiAyNDUgMCBSIA0vaW00NyAyNDcg MCBSIA0vaW00OCAyNDkgMCBSIA0vaW00OSAyNTEgMCBSIA0vaW01MCAyNTMgMCBSIA0vaW01MSAy NTUgMCBSIA0vaW01MiAyNTcgMCBSIA0vaW01MyAyNTkgMCBSIA0vaW01NCAyNjEgMCBSIA0vaW01 NSAyNjMgMCBSIA0vaW01NiAyNjUgMCBSIA0vaW01NyAyNjcgMCBSIA0vaW01OCAyNjkgMCBSIA0v aW01OSAyNzEgMCBSIA0vaW02MCAyNzMgMCBSIA0vaW02MSAyNzUgMCBSIA0vaW02MiAyNzcgMCBS IA0vaW02MyAyNzkgMCBSIA0vaW02NCAyODEgMCBSIA0vaW02NSAyODMgMCBSIA0vaW02NiAyODUg MCBSIA0vaW02NyAyODcgMCBSIA0vaW02OCAyODkgMCBSIA0vaW02OSAyOTEgMCBSIA0vaW03MCAy OTMgMCBSIA0vaW03MSAyOTUgMCBSIA0vaW03MiAyOTcgMCBSIA0vaW03MyAyOTkgMCBSIA0+PiAN ZW5kb2JqDTI3IDAgb2JqDVsgDTI5IDAgUiA0MzQgMCBSIDQzNiAwIFIgMzEgMCBSIDMzIDAgUiAz NSAwIFIgMzcgMCBSIDM5IDAgUiA0MSAwIFIgDTQzIDAgUiA0NSAwIFIgNDcgMCBSIDQ5IDAgUiA1 MSAwIFIgNTMgMCBSIDU1IDAgUiA1NyAwIFIgNTkgMCBSIDYxIDAgUiANNjMgMCBSIDY1IDAgUiA2 NyAwIFIgNjkgMCBSIDcxIDAgUiA3MyAwIFIgNzUgMCBSIDc3IDAgUiA3OSAwIFIgODEgMCBSIA04 MyAwIFIgODUgMCBSIDg3IDAgUiA4OSAwIFIgOTEgMCBSIDkzIDAgUiA5NSAwIFIgOTcgMCBSIDk5 IDAgUiAxMDEgMCBSIA0xMDMgMCBSIDEwNSAwIFIgMTA3IDAgUiAxMDkgMCBSIDExMSAwIFIgMTEz IDAgUiAxMTUgMCBSIDExNyAwIFIgDTExOSAwIFIgMTIxIDAgUiAxMjMgMCBSIDEyNSAwIFIgMTI3 IDAgUiAxMjkgMCBSIDEzMSAwIFIgMTMzIDAgUiANMTM1IDAgUiAxMzcgMCBSIDEzOSAwIFIgMTQx IDAgUiAxNDMgMCBSIDE0NSAwIFIgMTQ3IDAgUiAxNDkgMCBSIA0xNTEgMCBSIDE1MyAwIFIgMTU1 IDAgUiAxNTcgMCBSIDE1OSAwIFIgMTYxIDAgUiAxNjMgMCBSIDE2NSAwIFIgDQ1dDWVuZG9iag0y OCAwIG9iag0zNTEgDWVuZG9iag0yOSAwIG9iag08PCAvTGVuZ3RoIDI4IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQqTV8M3bwbtgLaiie1DKkNcOzGYOLiI9vTSNvnLtxn0Wghv QS0gan2NtclPrXBgCYf4WaOMiZ+4evEfTX+4MwQJsRd5VHj186QD7y4qrZ7C3MuLQsB3PURrFLJj sEh+SHllQLggQqkVV89MehG7XfSEte5H3ogXW1K16RSy/k3C3tJ7yIY+gAJYxcZBvgdGgHYpuU+2 M7H7z62CIuPVyMFCEifv0Wpsxq3MXqTMwISW0zxHKZ+NJVwJQVfurhbbx+WtX17HYWePiJZT8wzK g3XQgS/J26KTm36DhxMsDf4KJxBr7zNHHkUC1bIYEh+pLotsAVd6vkIwvpXArTfm1/2BYKhqjOuL mFocZ7eFKZM9Tm/ijYHIMNeGuX1TpK2ARZutqaE2BhhM6oZBy0MqwO1mK1rQokCuCID3fihEicK7 pzUGwK6YuR+9R5GhXRleB9WyJDBDZTKKggX/DoKufBkNZW5kc3RyZWFtDWVuZG9iag0zMCAwIG9i ag03MDIgDWVuZG9iag0zMSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMw IDAgUiA+PiANc3RyZWFtDQpkXw+wBpch8SLit7FPDyAOtA6WTyMy9rgnUhOhPpKfA/PwIixf9Wf3 t1ZFUxc0nn6sSgFRgrShEk2rX23miFZKZhhJoj50P7AkDZM82fnvBGxWUWTCHLnFO7fH21XVm6zX RhLw00UxR4aUmxFWbwa56/9h9Ba6iGrjLs+GzdSxk8O3co+jMJvLpMied02DxTWuptpp1Y8OnIWK 4w/4NQNpK3ymn9Jbh1+/VNVJC1HMghEBxNtO/4rSj7HZXY+ykcqZ+kTSnpM7U/lELzrK1YU9iPc0 PZ89LMHArAzNG31J8sJjMALS+UNXWB1T+sHVBKNZv2uufHAYecftgmfMNQyxtQLH1aulJgY2JixU AZBKlx3uZrOtRHGIYUsIBKkvHSKj05g0A3xOZPXPPFSTWonItI6Bdcp7UM2pV8kcU+Zhzv3B1QvO fshSHBfmCaiKZweKT3+2D8qs8XEFPJHk4I0p8/dL6XgBkwTAyiGxbOD7Enta3qG1FL3TzNLiwlch jAHo5yQ1e1YeNbPhZFtqAymRvZbmcITRKhaW47fU2/A+OSG/fzEG5156DXv7KBdoo4eUS+iFbv1i QqZfQdicDP6urL0La2HzpDz7HM1dIwk4Xh13uxoTiVCuENJmnFjhVYS7z/UuDyJe1b8uExP3PitI e3ZHvbs8HnNBsRzkMddNdfgRzoB1BscTDoFwulO8Nxn4a/ggyuGlE1qUjLY2CZrl1z+8MNZu9CI8 buAwQkZRJie47YS0tDenr/iWeRrNlpPlaaZOir8H1seuSsXbyNySJq7VJ6Lyd4FessQ1hh1d66Ky pBvW6RwerXiYZ8Sf+waCq419F9whxDRaTfyBou3Tcl41bqJZJSWjNnrmBPzmskQASrum6XdLwEyu nweOgHZ7so5nyzle6xMtMZOE7IAJGIlsRZiSj6J7SklIGisNZW5kc3RyZWFtDWVuZG9iag0zMiAw IG9iag01MSANZW5kb2JqDTMzIDAgb2JqDTw8IC9MZW5ndGggMzIgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCr7i9JLt+RNT6rsyiMhRnIJQUMcGt+uXoOWC8l32Iud0y+bxfDbO VI83re0SeGCMY53r/A1lbmRzdHJlYW0NZW5kb2JqDTM0IDAgb2JqDTUyIA1lbmRvYmoNMzUgMCBv YmoNPDwgL0xlbmd0aCAzNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KU3+t lStLLor/BQvesPZxhMmJIHg4E3SydCnQjDnphBy7snkVKAhQgyWfBSvgWsRHYF+KzQ1lbmRzdHJl YW0NZW5kb2JqDTM2IDAgb2JqDTU0IA1lbmRvYmoNMzcgMCBvYmoNPDwgL0xlbmd0aCAzNiAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K0tlpovPDRr5x23gJFXaNDW82Upz4Mix/ S/xHqYOKwWI/o8HatwbIs2qaSasrqNNkSW1UQ6/YDWVuZHN0cmVhbQ1lbmRvYmoNMzggMCBvYmoN NTIgDWVuZG9iag0zOSAwIG9iag08PCAvTGVuZ3RoIDM4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQoYy3qOK2v9AXkKhMYOsFQr5aqAMZdFLqgODmTkQPywAtUAAlrFZGwX1nC1 fGPJahheLU1bDWVuZHN0cmVhbQ1lbmRvYmoNNDAgMCBvYmoNNTMgDWVuZG9iag00MSAwIG9iag08 PCAvTGVuZ3RoIDQwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQreya3wuJu/ TOwi/GBGyw6wv8p0DMasf0UM1b0cLuGs9NufUkrLcoJenyFpUyY77I2CSX32iw1lbmRzdHJlYW0N ZW5kb2JqDTQyIDAgb2JqDTU1IA1lbmRvYmoNNDMgMCBvYmoNPDwgL0xlbmd0aCA0MiAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KNeRkyr/4v42WC2qNVSIQ0nq5RZ7QNvXvvTdu EaMXKjZPGcabI0BhbyGYzV1XXZTLtfLZPzUlOg1lbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqDTUx IA1lbmRvYmoNNDUgMCBvYmoNPDwgL0xlbmd0aCA0NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KcY4MP8XWecw75QdxlJYPHsiBiojQFJZcMiULGqC/lwWYLf42ZsczBwcuMIGE +0Q1mPtuDWVuZHN0cmVhbQ1lbmRvYmoNNDYgMCBvYmoNNTMgDWVuZG9iag00NyAwIG9iag08PCAv TGVuZ3RoIDQ2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrGYJhm6GZDARW7 kQBsR5MWegdMer6cqquisTDWjbsubdtOuD6ESVIG9lZxgKBzQK1VHihgNg1lbmRzdHJlYW0NZW5k b2JqDTQ4IDAgb2JqDTUyIA1lbmRvYmoNNDkgMCBvYmoNPDwgL0xlbmd0aCA0OCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K7mHdiQ7N/R3D9fM4TjU9eDnkyJinbGNKVIJ6vaoD VYq+fCghzjrNkfsgQBAnjM8pvkNA8Q1lbmRzdHJlYW0NZW5kb2JqDTUwIDAgb2JqDTUyIA1lbmRv YmoNNTEgMCBvYmoNPDwgL0xlbmd0aCA1MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0K+bDnvd1cJLRjhfaKrcpDMWp7y3ANBhF1g6IyOUzTURe58AT18sMCULSfqVuk3IToH0l5 jw1lbmRzdHJlYW0NZW5kb2JqDTUyIDAgb2JqDTU1IA1lbmRvYmoNNTMgMCBvYmoNPDwgL0xlbmd0 aCA1MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KUmLcYmYWOMu6ZCmgK4kK v9RmT1CU7+L49x43DXDk+Xp5b1pib8P0+G7Md2tV3JnJwZnoTwN1EA1lbmRzdHJlYW0NZW5kb2Jq DTU0IDAgb2JqDTU0IA1lbmRvYmoNNTUgMCBvYmoNPDwgL0xlbmd0aCA1NCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0Ku+yiSci8asskdWO4dX5yAggZ5BW702zet8xQSIxsCfIJ 8bCYbkHWFG/ajCf+Auyauznq4VGODWVuZHN0cmVhbQ1lbmRvYmoNNTYgMCBvYmoNNTEgDWVuZG9i ag01NyAwIG9iag08PCAvTGVuZ3RoIDU2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQo3zIIILTTfZUZ07fHuuyDc9WpzJ8x1ADm1q+1MPl0Ie8Puj4iw6phQjEaxVpPgsbDIcV0N ZW5kc3RyZWFtDWVuZG9iag01OCAwIG9iag01NCANZW5kb2JqDTU5IDAgb2JqDTw8IC9MZW5ndGgg NTggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NClR5nV0Or++2OWHKAYaB7ICi LY9xsrqh8No6Nqa14eq3YDvwGxK59v4xmtToKXnT3FBs/Ul0hw1lbmRzdHJlYW0NZW5kb2JqDTYw IDAgb2JqDTU1IA1lbmRvYmoNNjEgMCBvYmoNPDwgL0xlbmd0aCA2MCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KVa/qONK1Bndu5fZzf0msdKN6LjFKNZFLggBNviba5CzHiNKJ r2sKEunO66LHxebaLQotH7sKaA1lbmRzdHJlYW0NZW5kb2JqDTYyIDAgb2JqDTU0IA1lbmRvYmoN NjMgMCBvYmoNPDwgL0xlbmd0aCA2MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KNteQhTrYmXH9uaZlpkji938a/KSR0PTMmHCJcNl+ZH/rpWNaoDbjIzI37fLL/uehDtiwR+Au DWVuZHN0cmVhbQ1lbmRvYmoNNjQgMCBvYmoNNTQgDWVuZG9iag02NSAwIG9iag08PCAvTGVuZ3Ro IDY0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQr1m6uectUzl0BSrOnwsvIh J0PyaWoZZXljZqSYP+zmR1ye5VBPawU0MdkBuOxJJykdKOce2qwNZW5kc3RyZWFtDWVuZG9iag02 NiAwIG9iag01MiANZW5kb2JqDTY3IDAgb2JqDTw8IC9MZW5ndGggNjYgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCujCRJGbXW/Mc5Fzu3kCzEitX0WXrmrZZ045rK/3hy2Mdcbo 6BD/3Po/OhmWtfLgOcbFJTwNZW5kc3RyZWFtDWVuZG9iag02OCAwIG9iag01NSANZW5kb2JqDTY5 IDAgb2JqDTw8IC9MZW5ndGggNjggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CgeXl2BQ5UHC0z8P9tKGErsNE6bQtnfy5z3QR1c+OAJ4xrmysuCU0CovEhKDbhWXXBpmqmKIh5UN ZW5kc3RyZWFtDWVuZG9iag03MCAwIG9iag01NSANZW5kb2JqDTcxIDAgb2JqDTw8IC9MZW5ndGgg NzAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmz5faoe/rrvaY2UVpSVSGfq KRaESFA2RKkvHXqkzmZ5rKh26bJUW+WQzm16r0TV4FI5qILd83kNZW5kc3RyZWFtDWVuZG9iag03 MiAwIG9iag01NCANZW5kb2JqDTczIDAgb2JqDTw8IC9MZW5ndGggNzIgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCvoXcx81E514J4z/hpVZupAjx0uV8/YsYxhpeeYmKnntjbjj dAecChcPpRTPVttYQflJ5HOvfw1lbmRzdHJlYW0NZW5kb2JqDTc0IDAgb2JqDTU1IA1lbmRvYmoN NzUgMCBvYmoNPDwgL0xlbmd0aCA3NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0Kg8Dc2I8dXW/hXD3LbY7oqJmq3YkrooQvf7FfCyqDE/pauf8/BsDoji6pXpVV6+tEj0ka6oxz Fw1lbmRzdHJlYW0NZW5kb2JqDTc2IDAgb2JqDTU0IA1lbmRvYmoNNzcgMCBvYmoNPDwgL0xlbmd0 aCA3NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KAuaL07NfHuOK6JPcg0xX FkDOrpN2qmOZP5lYqBCHbAAJNFrf0F7QIJ60JPXJ+zI+NA52P10nDWVuZHN0cmVhbQ1lbmRvYmoN NzggMCBvYmoNNTMgDWVuZG9iag03OSAwIG9iag08PCAvTGVuZ3RoIDc4IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQr77ow9+F+XDl8nQSUvbTDHGXgU9aIqOjVBY+gl2WH0Wj6K wR5iSuNNPB/4EGAouXdc0D+WkQ1lbmRzdHJlYW0NZW5kb2JqDTgwIDAgb2JqDTUzIA1lbmRvYmoN ODEgMCBvYmoNPDwgL0xlbmd0aCA4MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0Klma3xv/KaaKC6NBdGO9LZB2Y9jTGspZXq8eBig/X1RNWIan+5ChmzoQgMwpCxSSqr/yOSB0N ZW5kc3RyZWFtDWVuZG9iag04MiAwIG9iag01MyANZW5kb2JqDTgzIDAgb2JqDTw8IC9MZW5ndGgg ODIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvxqjw5GLeg7GD+cAt1zjP6H ZdrfImJnFrmtYzSHsrXYCflmFECN5pXAP81g/bez8H4O2qJsDWVuZHN0cmVhbQ1lbmRvYmoNODQg MCBvYmoNNTQgDWVuZG9iag04NSAwIG9iag08PCAvTGVuZ3RoIDg0IDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpWPwq/Kr/ijk8Xm74DF17Xjskoam/6pctS3ZeT3cTIr8arT6sY +4m49WxrBd69WQEuQdSbF/gNZW5kc3RyZWFtDWVuZG9iag04NiAwIG9iag01MyANZW5kb2JqDTg3 IDAgb2JqDTw8IC9MZW5ndGggODYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CiL9mbL2LYBH2Z5eQGwxshNa6C/Oc3l4XO9yQxzeEaUYd39B/QEcpMX1qoQRnQUsF7ohREiBDWVu ZHN0cmVhbQ1lbmRvYmoNODggMCBvYmoNNTAgDWVuZG9iag04OSAwIG9iag08PCAvTGVuZ3RoIDg4 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqtSixPF7XTReFJAqlksLxUmCGc 1MrGisN+Q3PQmn9/mNCmEnpQA1985VxienHnkYAboQ1lbmRzdHJlYW0NZW5kb2JqDTkwIDAgb2Jq DTUwIA1lbmRvYmoNOTEgMCBvYmoNPDwgL0xlbmd0aCA5MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0Kj33hHRHf91z1YPz/noylvcuhNzbXP7WT9xy8Na6fm/k/JSEIJBzN2/LN DLurtqE/QB4NZW5kc3RyZWFtDWVuZG9iag05MiAwIG9iag01MiANZW5kb2JqDTkzIDAgb2JqDTw8 IC9MZW5ndGggOTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCpfueeQ9xMlo nPoMgplGme9dLocPZAyqXa2t8sw8GdMPnGja/G7+co7YCdPTG+xWsKlg6fMNZW5kc3RyZWFtDWVu ZG9iag05NCAwIG9iag01MyANZW5kb2JqDTk1IDAgb2JqDTw8IC9MZW5ndGggOTQgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCgwkvkkW4uMmELvV5aynwHt2Q99GNbW5kMhNz/2b OwpJ/PlepzB6TWkDUqXK/1D1jLiOCpohDWVuZHN0cmVhbQ1lbmRvYmoNOTYgMCBvYmoNNTAgDWVu ZG9iag05NyAwIG9iag08PCAvTGVuZ3RoIDk2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQoBs+P6faSNARwnoCDFYkMLT/aZiU3Os2nlBCuSXw8TjGt0sVTBPP3IoXXHuwgnd89o mQ1lbmRzdHJlYW0NZW5kb2JqDTk4IDAgb2JqDTUxIA1lbmRvYmoNOTkgMCBvYmoNPDwgL0xlbmd0 aCA5OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KTtVMxYPC+YqS3BClk7MJ UIX3JjL9bgLgK1H/IbiCmNxk48LoGg8kkWlGddRNUBal6bnhDWVuZHN0cmVhbQ1lbmRvYmoNMTAw IDAgb2JqDTUzIA1lbmRvYmoNMTAxIDAgb2JqDTw8IC9MZW5ndGggMTAwIDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQrOym2gHivf+xxVKNfUV91S3sDvDzAMtelNmzv4Z13ejJX9 LkQ0m4YtUF+mxh222kFIVgKSCw1lbmRzdHJlYW0NZW5kb2JqDTEwMiAwIG9iag01MyANZW5kb2Jq DTEwMyAwIG9iag08PCAvTGVuZ3RoIDEwMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KWusp1qAo9OBFS+SpJTwyAmdM2n9YNDbzzdsvjXBdJaNnPvk1xhzgYs/2XrU6ZmxwERzm QZ4NZW5kc3RyZWFtDWVuZG9iag0xMDQgMCBvYmoNNTUgDWVuZG9iag0xMDUgMCBvYmoNPDwgL0xl bmd0aCAxMDQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCqEXomEgi/xJw9xv Pli3n61ABERneDN+en5LBHpOwDgkihMO2fOGbSg39D9WMFwtixjFdGrNOM8NZW5kc3RyZWFtDWVu ZG9iag0xMDYgMCBvYmoNNTAgDWVuZG9iag0xMDcgMCBvYmoNPDwgL0xlbmd0aCAxMDYgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCt578tmNTH3hZJdAO8IJHPBbk6ukuyatmTBs QTlmnkkcX4Jh5iyVjEhurTB5lJPkJ5gwDWVuZHN0cmVhbQ1lbmRvYmoNMTA4IDAgb2JqDTU0IA1l bmRvYmoNMTA5IDAgb2JqDTw8IC9MZW5ndGggMTA4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQqnOKte8l3AkGDqdEl+QQcw+Kg799q5lxb56w3u4EeD/ibCunhbblEO4kRguFpW IsF4pmBY+JMNZW5kc3RyZWFtDWVuZG9iag0xMTAgMCBvYmoNNTUgDWVuZG9iag0xMTEgMCBvYmoN PDwgL0xlbmd0aCAxMTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCtK2e8yi wrIH9kfVRfbF2Z3nbvwHQKhAzJ/LHZgnzi47gIyb8Vw8zoxj+UeEThNn//sSzzrawZgNZW5kc3Ry ZWFtDWVuZG9iag0xMTIgMCBvYmoNNTUgDWVuZG9iag0xMTMgMCBvYmoNPDwgL0xlbmd0aCAxMTIg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NChYz1fPKXqFeJ4Fvk6TvcpaxVyNJ FDYOKwfLBdnE6mhs+ffc7hL6AfXxJPL7wmRkCWP+40YWFb8NZW5kc3RyZWFtDWVuZG9iag0xMTQg MCBvYmoNNTMgDWVuZG9iag0xMTUgMCBvYmoNPDwgL0xlbmd0aCAxMTQgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NClegf/SLA32Cfk1RnNgOm24i8nPIsI4wRExdWtdmtI77jBXg FQLxIbpiCxEBM4siya3WstXtDWVuZHN0cmVhbQ1lbmRvYmoNMTE2IDAgb2JqDTU0IA1lbmRvYmoN MTE3IDAgb2JqDTw8IC9MZW5ndGggMTE2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQoP3OcmVpY85Ewa6uWxYkf4HKP4yJfmCQvzlTbuP9QYhJrxjaU3A/ldpVah9EI0TClK2KX9 I+YNZW5kc3RyZWFtDWVuZG9iag0xMTggMCBvYmoNNTEgDWVuZG9iag0xMTkgMCBvYmoNPDwgL0xl bmd0aCAxMTggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NChAGNWA1GqYjPdQ3 CB9MST8HH7vM97aZCUBWsZLzQDgohVsFmX92gidBUUGWlflK9FZiJw1lbmRzdHJlYW0NZW5kb2Jq DTEyMCAwIG9iag01MSANZW5kb2JqDTEyMSAwIG9iag08PCAvTGVuZ3RoIDEyMCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0Ki6CmWJ0cQ0XS2QAannhJ6kjxAz1Y8J2Vzqa5N0vu tkC+Twty8uYjoBSkmuC67Z69aEA0DWVuZHN0cmVhbQ1lbmRvYmoNMTIyIDAgb2JqDTU1IA1lbmRv YmoNMTIzIDAgb2JqDTw8IC9MZW5ndGggMTIyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQqsNjzjyi04vm44/TSc6KKTxBk3ZFvPfhRTkRv0OfMYbYt+uF6dgE7CedH9oxFCFWh9 rDTZAKKJDWVuZHN0cmVhbQ1lbmRvYmoNMTI0IDAgb2JqDTUzIA1lbmRvYmoNMTI1IDAgb2JqDTw8 IC9MZW5ndGggMTI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqDxuzlqpQ+ khSxjCZmf2kBy0wzVbKpCD1JoI1RAEVYu4pmBKgvfYXdZwvx2U11Jy0IZKuyCQ1lbmRzdHJlYW0N ZW5kb2JqDTEyNiAwIG9iag01MiANZW5kb2JqDTEyNyAwIG9iag08PCAvTGVuZ3RoIDEyNiAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KG6olbSxYKsU7iu7QCE4S+XiSfz+g4jgc wURSmM5UAKBKdgVK5qL/ThFIA/q10Ng+rSlbqQ1lbmRzdHJlYW0NZW5kb2JqDTEyOCAwIG9iag01 NCANZW5kb2JqDTEyOSAwIG9iag08PCAvTGVuZ3RoIDEyOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0K1+YWSEqeVSegcMx1DxLmUcmgFGi8c3W2wReH4thZFisrYKsrTBd3qzwg ZQndJ/a8ak2rzk8HDWVuZHN0cmVhbQ1lbmRvYmoNMTMwIDAgb2JqDTU0IA1lbmRvYmoNMTMxIDAg b2JqDTw8IC9MZW5ndGggMTMwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQq/ axxIFnz0CHYq8XffNAR21X/zVcjMm4q3rdCBQn7IsfgPz+K867ZPFYv8SmYxRjvJKVk+BUMNZW5k c3RyZWFtDWVuZG9iag0xMzIgMCBvYmoNNTQgDWVuZG9iag0xMzMgMCBvYmoNPDwgL0xlbmd0aCAx MzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCsCjEG4zcQMH1fyO2Ic8ZSe/ PZPBMhzYvb4xvSvPDYIqRfH2r+u+PBp1dr6pyG4FbJDn0xqEhA1lbmRzdHJlYW0NZW5kb2JqDTEz NCAwIG9iag01NSANZW5kb2JqDTEzNSAwIG9iag08PCAvTGVuZ3RoIDEzNCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KFCma2rY2BIXApDuI9UhFHyPdq1FhqM7uy2FLaNcpeHqe K6mWW2B/zqLisIgf5MJf7KXpIumcnw1lbmRzdHJlYW0NZW5kb2JqDTEzNiAwIG9iag01MiANZW5k b2JqDTEzNyAwIG9iag08PCAvTGVuZ3RoIDEzNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KyRwPOaddi5L3vx7JpjtXoypDfYOknd6nsez644OUmy+TnTNVVt03n4GhbmTR9B3M mcKwKQ1lbmRzdHJlYW0NZW5kb2JqDTEzOCAwIG9iag01MCANZW5kb2JqDTEzOSAwIG9iag08PCAv TGVuZ3RoIDEzOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KCsyzAnPdYuZu T2KGfApkJKoPG/ca7jzrRp/iSzxJPtn4bBSbl47zwA96FpEuJx0Q5ksNZW5kc3RyZWFtDWVuZG9i ag0xNDAgMCBvYmoNNTQgDWVuZG9iag0xNDEgMCBvYmoNPDwgL0xlbmd0aCAxNDAgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvOE5rbjLgkktKP3dFGR+KacdDYP7DZd3YSVGm2L 3ZRIxOuPob7GOBjoi5LU0PvEfr+xnDMr2A1lbmRzdHJlYW0NZW5kb2JqDTE0MiAwIG9iag01MyAN ZW5kb2JqDTE0MyAwIG9iag08PCAvTGVuZ3RoIDE0MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0Ku2RHDYgZriZN6EdzxbUTLUjO7hb2s068NrLAh7DORcMw74rNZ4ELUehrpB/j 7lbVIPr3+lQNZW5kc3RyZWFtDWVuZG9iag0xNDQgMCBvYmoNNTUgDWVuZG9iag0xNDUgMCBvYmoN PDwgL0xlbmd0aCAxNDQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrwXOy08 /YNA7DPEit4i4M5c3yj4voCpPzrNvdsjUk2l3JvodLkjG2IB1lrB6p3YOk0JtrCXGBINZW5kc3Ry ZWFtDWVuZG9iag0xNDYgMCBvYmoNNTUgDWVuZG9iag0xNDcgMCBvYmoNPDwgL0xlbmd0aCAxNDYg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrRLeZji8kBWZDnhIbBJjHywXuap ax6nwI8uyp69Z/sasZ7rp8PSt6r7CpVZ622lCrO0W5brQsANZW5kc3RyZWFtDWVuZG9iag0xNDgg MCBvYmoNNTQgDWVuZG9iag0xNDkgMCBvYmoNPDwgL0xlbmd0aCAxNDggMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCp97XMncyZuF2uoJ4SF7pINChWfeWkzOYhS0Cz8oM8C88JYi MDuUsIAwKsjRkYqS3IhhicBqgw1lbmRzdHJlYW0NZW5kb2JqDTE1MCAwIG9iag01MSANZW5kb2Jq DTE1MSAwIG9iag08PCAvTGVuZ3RoIDE1MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KX7WTe6ZKLxI7yv7bg6c/hFhXgdQIhXHYcGJmYXM9TyQc7/45e/KOUHs00wUEhSRnmJcI DWVuZHN0cmVhbQ1lbmRvYmoNMTUyIDAgb2JqDTU1IA1lbmRvYmoNMTUzIDAgb2JqDTw8IC9MZW5n dGggMTUyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQoa37PcJXZFUg9pC4Z1 jsSbU+7GCFCk/q9s5Irs7W/dAsOSiCOOEsEwwNiSydSYvJgJtNuE+y8cDWVuZHN0cmVhbQ1lbmRv YmoNMTU0IDAgb2JqDTUwIA1lbmRvYmoNMTU1IDAgb2JqDTw8IC9MZW5ndGggMTU0IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpxZL/1d/iNRmtV+o+Uc7h31GSVhrrscDt8Vi7K Cn0/f6lNHroHytLVdt0aFxpoxaiguw1lbmRzdHJlYW0NZW5kb2JqDTE1NiAwIG9iag01NCANZW5k b2JqDTE1NyAwIG9iag08PCAvTGVuZ3RoIDE1NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0K7Fx6ZYAsQ3vTbAf+pxQZPkg9BqPm3zVoYdLPRf6fxFzd2MHgcC2LRp9ISQkADFYF d5aL/oTpDWVuZHN0cmVhbQ1lbmRvYmoNMTU4IDAgb2JqDTUxIA1lbmRvYmoNMTU5IDAgb2JqDTw8 IC9MZW5ndGggMTU4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQq076qxjYjq Ci02hjBp4Brwrr8hS+9N0RdTLK4Yiie3C1KngNQ1GbOGyrScouYPTTKp1sANZW5kc3RyZWFtDWVu ZG9iag0xNjAgMCBvYmoNNTIgDWVuZG9iag0xNjEgMCBvYmoNPDwgL0xlbmd0aCAxNjAgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmiCwSBRsWBhIfE3ugiuKhWG8AGtJcO3LXvU pkXWwnXEhNAVdJLbs9nsP/KScOWRxolfKeENZW5kc3RyZWFtDWVuZG9iag0xNjIgMCBvYmoNNTQg DWVuZG9iag0xNjMgMCBvYmoNPDwgL0xlbmd0aCAxNjIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCnCf45FljgW0ujntzn5d9IH7bUyuEHsrG+FI3ZB4PzxlFM25z6kU/g44Bupg iaA3QKZxZUgzZA1lbmRzdHJlYW0NZW5kb2JqDTE2NCAwIG9iag0zMjE1IA1lbmRvYmoNMTY1IDAg b2JqDTw8IC9MZW5ndGggMTY0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpE NNc7jNC5JSHr1WK5F75N/pN1PEztlxArIgR+8zw4+cOMTqdSgekSG92WWPvG4QZZ3rPY4/1OW8YF F4nmbvwKelZeL1A4VAF2bsZS2u+QVMrgRuB+WSNnVxFuaW9LFoSFAWyBIHDNVhllI9sfs6ksIpRT Cr3Ukf6Tx3HCZXpyYc2AP6aTVs5FyjP31W6f+oo/eZkkE8a7D2NG2HtJYDEwpkvbNjDrsRljCRud zH9VmKhVxQIGZslKNthy/ibL1+3W7LhFTM7qWp7DFpjdyWpD5nU7E1mZd19DO+ydS6VJsDcgYBJs TEVKm1d0WBO+cf4eokgoQs9kR3l2pGRhHqPMxeDP5xuDPAPDU1AEPeK/RxPvy6kJCS6PqlZHA0ht cJSVwhmGye5BOQ8EQlR8Q1Wy+Jl/s8s+OmdNYtFusMZd+Y9X88N6H1y2ilw3WghLavGRh9rnjFBA 9TvftPX2EpW92VPR8JKB5+AuFvw2NTA0ZTM+cESeUXBkNUIhnl8vRF1f1UUH22eNxvRptpxjSspR PQmFfVlvOE3NVpO0NpsWTU6tyJYEDeln1PWK+JVOWHMB7DpEAD119NpnuyVea0XFPti5FbQA4Nr2 wu4Cvl7W87Nf2aNiV2fQqurba0P1csUgU4OTGopLvb/Osg/UWhAhvzDuGJ0k+Rplfbq24B6cgG69 +roKwwraRjYqblkv9889fR5djL2TeZL43FMYG2ZTCKzaAPapMkjEpf7gzOu2uiM2CvnWNGx5efxC +k9ONInHEV/Ua7Q7qgkKtkS58UXbQ4VxpzBy1JhhI0jBlAeg2HTPoEeao3bEWk/tnap1VVAQeMTa YTf5OM6G3mjtN43/zYU6fUGSoFyDEVjl3ojUujGmHHrwmLWlamgGS7b1kRm1l9982OeJbHpHWcz4 LK5W8HnRZbBE1qf8gMhxbQpfLrV092RrsOzCh2U98WdrXlLOfL4BEBbj4/jz5eQABjwOqLFPJDx2 OAmYNcxDqX9a3brAladwGUEYfx88AQr7ttjFyQwNncN/cWVLwSUyczRTzHPdiG3DufDTEEnIT+GD nTY9WKo6RxCqAPB4v1lo8mGbz2wydJHJTeRkNKDdEA4y1R9fJuv0rGIzSRG7nHyayvB8eTe2nLmr KIm0VntQnxaXZs6w9JiY4+65v7IzTZSbtQH7k7YV7rHSzH8o5nolnBS4F8sos+LUMMZGMKKGRynW Xg/xXIRIO8E7kf/LgUovIvgE5nFyJ8RxzxJ8SliZ233r4wmx9FbZ6YSA4gMyPuO3/yFA5ADKFqGR Ooi/7drTkb3JF0iAb+BCwI/89BuXhcB9BgkADeyXobefffYQE3Ox6MPFnlzljH5SlZoG/a9nH5eR cR5mpGssqG9lZ8bqNnUAw7eSJddJMnaJ0R82XxK9gOomRZz9V/pMhYQHtXlDD+xEVp22VTOr/Y71 BdA2FBVdo15bLXmztNmEAxCgCwzz6NQEZHUtsJuynbxmFR2Yv+MmqqF98eixFrGxVWAzRujMNhqA tA0J8BItnRJ7pnkjpNafXFg1DP9wdUeZ6Jovv8KYfAagm8HjFtsl2lK/Dg7IiwCwQGzlAAabfwkw G6KbBsMiMaF7kVTUQYp/bB2S+WU7B7pCL7vbVNI0PlVJ/Ign3IwOWdVtNnrwzv3LFwaYbVALyUeb LBLzl7maf90chIWy39z9/tCRM+D9/zvcg3oIqN5Iyk41pLZpoy2jDKdxN8xbRRbBNB+HHtTkm13h VNhZHrg3C07pTkKdV0Cn8M5BGyw91dr3k89m9VH5w31Fe5Zqq5+sfgH/6vSSRnOxC6VJTKREVPfn Le4iKBNLzc1cct6ZWz6OFsu8Fdv2bvakOwhiOjhr+Mi5DdA0xOedRvt5jAiuwRMXkKZHbcwdciK7 cHgs5TsvXuuKyk/ESO+dBJ7FjUwSsPGES4rC/lY/JT0JfyCxF3gFdD6hs4DZ+SsM+jyWOWgkhWYj +qet4rdr8m7fNJls3RcCCTv9ASxY35yPrmyetfSkz/NDCnY9ZU+b37MSCBtJg05noG1OvOAafzOf +h1d4bSUBSQb0oMs0T5B5Zx5ex+4gAf+W5k/1IKIl0QBzSqusUYUHC7CLyYcS7FJW4KiPQyaQgQH V961BGIwRJ177jY9P6s9JpXRdvpRP9/vcLpQDsWccHPF+NwvFkWc+4ZIaBaB3xSdZKxq5QoU3w0e ZzUxWg72eQFJFS6XUpzqQqksfF5OsDTejRy/Jyu86Rkx5vRI8Y00zSq11UJFYIKMmqLkA3g7KyLy FjEWXctbKxst5lJ+j4w+fI5fKWZATscuDvIFokT3yx3hZb0HmVmzLhhq1qrSYIFyye4ut6Msw3TF GnzzKi5yrmHs8WS4cOjAYrqk4BUWWjPH0hOqG+rtrRj8lpkOh06HyctRfM5bMMVAb/2dM8qu9xoq M9+5/Qwpdx6t5IjMBNntHcF1ldCuRN0zruDiFDtUdkSreneEeyHadeMjz2TtNGg2vo3Q7RFp4joP FSLd1T6GVjPxvwlIT/iRdfcNYmDPsofocPyLwAQIXh1GonIO/TLd5zL3bVlvOiNp6ggQ33iP5Eqt kO7HhirG0IcPk0YYcexDIIIL3eaL2y8qhMWZdyekuflmAYRhQG3OdcH3VueWHp4kPzboS3t1uSi3 yF5DW8DFZXbFiP66rmxse9kgdVCAhIrMum+xq9Nf2SmlE833G7z/BH9c4pMKXDn5vVGJ5/Fk2cus UWFcd50CX07h/fvALVmw6bUmHgB7538epUb5dLoCCmO39ANtGmGGS+8HvVc98QnRV85m0nVkDLw2 Tl4AsC2Xc5jcB8Y3M26NGu9I2UZ2NpK/IEghDkpVpLBYmXnqFvNpkyZnSFk5SyR7L6svL4qWHdWe bFR8dhA1A38OevhYjixQyAnaD7zHmSh0brP/F+Vg7DXRsbqAHHsykYcsEvE8vgYfexLmXA+L96MQ DZxTzdHkLPN9Re2YYUJlF47tbqIksHq3hlNkzYT1itGpsZ+CGOOyUPkMtzIk4EwyB1OfUZ80z+MF UTGXQcitCISaLM+Wcp9Uv94KCMsUfLetnXDPq1cNIhZPB2lcyEa+DrpzWR1ddfpX7BPgZgBidB1L GZJfHIh0dsqNGW+qYuyM5DmwZAR94PgXSP3/D9HdKvp7y7vBE5+erV4cGaDed7naT83B/K3m3WWW M23YpuDMEKN0y7z10kKQ4Y6wzVY/MZRjbPQyDABdPVxT8hO+736IOoruUSght+WFtL5KaKV8ARkR mxj4qaxK0j8yVXUFxPZ/5ex7cPBm1J3aZjXtT/SXc7+9Kt5C04g/Ciztg95bQagwwCfZ2pBGglqX Z6WGEovwGzyczAGRjDDsO/wJA6Ttpy/71WkubCAecpgIww39L92I5ykPOMBhaPnJ+109NE78RcOK yl/aDVYW0SAtOfRfTgxHurNwg0iZPH/acFF50K4JxYYk1RUsvK5IWzuI6NjOncM/hlHrWLPpAegq k9XeBTPrK7I7d8Y0q4f+p0a4kUpuxSC1JIs/BxXFzBZ6i0vGWg/9YK8o1GCcr2pf1MlU0yfRZ+Lr 87gtiiK3QgXoF3Jj3a12nc6Q535GI7IcaUleyUM8PB3QUqDHsIlVvSrwvAWFywzQrs97fRsfOAnz 9u5kV+M/QY9aMxN0n3djwz0yZ9/C3gGHG0t6HNPjRJeJEPUpG9fwpph+ZsPucRWYatuahW8TYm7T Iw4///jOux0HE1j0ce0+7CNpW4g/VLUIB8nLuWprXL1FOowYI2anrMiTSZSOgxFa8y47zaMia/JT v3p15HwM6jB4zMJtHzVO17lhvvwnPdNSAUugPF/AVcCEDJ6B5ouHU08Ydd4Sqy9CnLbAAYuTwTmm /vy2+C10gTD2jqekFoWHyAdIhqLQ0LkeWZqxm8ft00sszqBCXgkXSx7c5henaxsbC4B4PccckSVC C0p6XvXORKbkQbivagQFvRRSpDBkJw5mGsYvBCS8WEhD2+8y4gpEVxAW4nXE9VgO3fAh0pketpxL CVi7YvqcsjP7yVnrNgDJ3aE++EQMH1nBOJvMKTXRVD+muDLgMffknB+PQyaRJpMBCR5z0AspSK0N fww0YX9JauhQdK7OMlLzaPXzGVcvSHhA8Vunjm6/GO8sn5jKDN/rRFHKMw6wavDfgXowaeGNPBHp ut/2kkvGPxC+y9nJRtrBbvYYtBfewyakg0t4xT7n4HSy+/Jj9J4sdQxNale7mptPbuR+6IecJgOJ b8ZLeQMj4LoX7Vg4nHvTNlb8kz/TmA1lbmRzdHJlYW0NZW5kb2JqDTE2NiAwIG9iag0zNTYgDWVu ZG9iag0xNjcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9p bTcgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAyMSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDE2NiAwIFIgPj4gDXN0cmVhbQ0K /Ls1pJLyxX1tzDB44ATE5xqQTZrTuWKhPMUlrXnZJ/zgKyK47uvdUAtt/aswTILuRuLt6LJ5FcVr TR9bN8D/Sm8AH2dxfTzE4VaiTge8+RVOa3W1NH5FsCoegYiJ2lZNvIfroN7RggBKM6juMJIIEouK JsausZz8PNU37Fo1mAUxrfE1zLvibHuQXhkWfHA9bURz909cYklvg2PFzAJCcmkJSFZCyctSbsn0 ziAFnDTq+iY+klwRaZNG45AexXGCxUCkNPwY4g6PiplQjdkvhftfHW7VsMITxQEQWXfFWWLYMK87 U7Lb7lraAy5hc5/VOsmdtdGIvaYAgyIfRrw9NP/VriPlM23CdYeD3nC02RIQPM9YAQvjc2uzJdCs 9CmvF69JqSI7wuGZ0ltN9ZZjFA2Of771eGSE63qfb4wDzavKJWP5DVSd4moihZRR6UYej0t1sDBA 7qzmb8Qb587h62SIMoENZW5kc3RyZWFtDWVuZG9iag0xNjggMCBvYmoNNDQzIA1lbmRvYmoNMTY5 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW04IC9GaWx0 ZXIgL0RDVERlY29kZSAvV2lkdGggNDMgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9D b2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAxNjggMCBSID4+IA1zdHJlYW0NCm8ME0b4F00l s8U7ByMRIV57VFtIlC3SEachHLEF+U2oTTdgiGiiWpzfgu1QBEFX3Z7jhV5b6dM71rnxyAVu6tHD lr18ABEIct/JbQ7Vo3u0PoFG2ZEv9F0/TIH5nR+r0dkAOh8vgJpVTZh1kUo4Ih1kjVw91Gn1RDQe t35L1TtR5t8Cil8t4BC+U1Chx5FoxAfJoHND1clWkJdja3thS2N0HF5t/R4OhTY0GQ+87xUDsUev k0wwQEQKt+eKcufVyAR3zoHhSz3851nesOtbnsCqiCxUQt0IbKieZFY+FSqdpux9PLl+0Ab/k+mf Xg7ILiC2y45yfDsUfMfmsieY1Oa5GHFSL+Vct8DtTuCue1SkhHqTGwp9IKQJICRYPwIMTBcdl3Za JndXCe4zmMI+cn356e5gfx7EQD1Hc5NgdFbaTioTHq3Z2o5c5n4zApFtRPmzMqW/gbsPiwEHJbXj 4JjLBQJrs+hhOANxWYhCqdALyDLtCj1GVyd9NE8q3hVXSNUeKz+PZVnI93XKf9pHB3WedKlhpG7n zRsmWa5bWSMWI35PD+hvr6PNjrCMOe6ThjqlKMNKzaxb6zFHDWVuZHN0cmVhbQ1lbmRvYmoNMTcw IDAgb2JqDTQ1MyANZW5kb2JqDTE3MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltOSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDU4IA0vSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMTcwIDAg UiA+PiANc3RyZWFtDQpOCKhOhKO4mcRGJsc2qEKNmDh7OW8znUJdCsIoj7TsApezKAkdN8K1E03L UbrnyEeg0WXO+LsDojFtkfNNE9J9KZ8sJJQ3h2mBqym7QeXwisURIAcrQudJray/hWaKpvCsvAx/ ZznD99uLozWeVh1kU7JyybgFGNaFnu8H6Ekz1FRCwFkDqsWM6FCYa+GrHtS/R4RqYGQWcfT3klUL RvaHn43Zf3eaoh4kG8RMKa93tuqSqYuwBsVs5ijdOH7yyn3n+Uka5400tT/XDeP6w6TE7l1RE09s liCJnUuj3PuDOecIibtCi1hxCN9bjKm7bUiZ/+b5hxneC5fnOii4b8JOFVHN9G7+KBo2mCl1AuKM kiMnKvn3PePKWM4rAEQ3B5Tq3Zvazi4KAzqftPyDWk+68dZ8bKJHtrgoUV1sMMIFl6b+H+4DBXpF 2C3BaPD4afA7TkzP4r6GXa6FEgdu42/otriXP1N9rLGEGWFjOKhZ5SJIMzVIt6ChaDiKZ+SYhhCD tohSGZljEfHaql1XEhY9jQ9GYMIv6/9dW/PTwR1gScO4qUCW8ZICuY7fClVdIXhMo96xvWSaYq8a OHl9HaRHQMyfavUNZW5kc3RyZWFtDWVuZG9iag0xNzIgMCBvYmoNNDIxIA1lbmRvYmoNMTczIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMCAvRmlsdGVy IC9EQ1REZWNvZGUgL1dpZHRoIDY4IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29s b3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMTcyIDAgUiA+PiANc3RyZWFtDQqTAY4kLIb/jFzs ROEOC2adFs1VdpWAWUYVqoak0w7M1es0rX77ewl4UwXKvVA7Rh5rOlaeNAmOT2davQvRSorHP/cn DAqHVEb4Iu/3vsSQNjEJUt6dS9j4C9o/Hk9SpJlVsxF/kUmczuv45jBUhjtulCJTqFR/RVkZTTyK wd2CEQ9ukpzeIyFACJPhE7qDpNDVNoQiCspu/VtexPRRDWg2/+id8fvhjkqPQKSlQ2VgpistSSxo kVZhNxxhW3xPTekeZv/VETRM7U7tsILsUqfNupxxCsUwxJnqbbOHXP/frlr/ldsfbb3VDPjPHsW5 r9GLzWo4u/gCYAbLjFnklLcPcxCzCmAe0GHsXsFrB7bSzjDAHTkwPR7geG3m43Bwkzj2io+iR5dn gp+m9uH467uh7muJpAXuR+57FrPcfHNpSVHX85rLn+KGQYPgxnmd3Txh0VDJGhGey+zkCkAiMRTz daU+BWM9IDip0W34E9TpHu+2ZAyC2ZBRMGY1pG24P6ce3d7jEmpQTS6Fcq/m5JUY9xGfTHiELSCX YKFSy3Y9R9cMKv9PDWVuZHN0cmVhbQ1lbmRvYmoNMTc0IDAgb2JqDTQ0NCANZW5kb2JqDTE3NSAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMTEgL0ZpbHRl ciAvRENURGVjb2RlIC9XaWR0aCA3NyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0Nv bG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDE3NCAwIFIgPj4gDXN0cmVhbQ0KCUBdv6kFXEMr wdpMqCIqlaeJ2Z5DKKFqCSF7ClMUZaAGo3ubS8jXDos0FoZ2oZT87PGdV3al5Umx3PPDhHug6Ycb sFJQKCgCwuJbcNYwhox5/AviXe3+/tm3k4CrkRwS9NwRlZ8YU5tqI787aeTI2A4SfcuYeMli4Att VCWaq8aDVYHLRfr1s4rprwOBQAdWZ6a6Ipv2bNNgiH2rARCY0X9oRuzY1GD1eg3hDkeivs8GDSr4 gPmpIuAw3W3lCuAYGbGi26vh8k9IdJtvJhzi48LYC1WeOqi8r9H0M1Nr8Ywvh7rW69GVD7w9cfFu Xv/KpUNpNuwmZC3D6wx6RA+UANkDLJPZ7lm2+Rrgb+zCZRlWY3k/Cq6VLpTyMJ1/YZbWi1/+2Aw7 WxVu8uY4TTW5pDirjEWTdI+NprWERvsjrqmKy303viBEAeBKpt/fan21V5cdwzliCAURcgfbuN91 Abwe7cC68uvUTLpaI+wmZdOPW6wpH5s6G/d36Zk6m7zSIrctUufhRj/KmqCcBRk89Erm1r5hDaMR EEECPO5qWpo/nGy5sQWEK6+CBu8k+Y8P6h+Honz9V0KddlGgDWVuZHN0cmVhbQ1lbmRvYmoNMTc2 IDAgb2JqDTQ0MyANZW5kb2JqDTE3NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltMTIgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCA4NSANL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDE3NiAw IFIgPj4gDXN0cmVhbQ0KzSGGiEvqHuNNX41OfWZvmdllTLyRls1HixbWqZFtEv8rdQid2ziHLDPj HcwgjkIlGRurR0IaXnmcDvQkl2E0cM00Z2dcdFTYFQ2XZMYmgW5tmoRy4dKl8LK2Hm2VitLSUsLm UfzXb0fkIrhnsYtBhjYe/fossXMkkGCGUNNaORVoamDS2DstjmcWhQFVINUG0pY7fm4Z6/+qDsUg sv/joVaw3Evch45Euwl6iHK3d6cdk59/ukg9ZVE6qJc6eP2uvAYv36djEJMhr9iHSKH/IDQYE6Ox YQxwAemdCpgd8VdxAZwVFIvz526Se69zcPXKs+SZSutLRbvabudiuXrfaVlQ5esgFGfvimjD5GxW 1+ckUb3EFllEmAgLlQJ+sPku2GvLxBnXIxltphx88q3isFJsHeld4V3fyG9oOC2PXYSQ6ujvphKh F0bSx9yI+NTiLk1IFpPViPpnWTvWp8faUDxVb0g8bUSXYtmgQ2fFASChFwRqeiTo+795W5HEqNg6 n8re2vk71mU0Q1yCQJeXjC0Uyr0OS5H8yi8bNBZQ6X8WLWGQ534ThGUnf966WZePCyGxhZVT/K/S 2AINZW5kc3RyZWFtDWVuZG9iag0xNzggMCBvYmoNNTI1IA1lbmRvYmoNMTc5IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMyAvRmlsdGVyIC9EQ1REZWNv ZGUgL1dpZHRoIDkyIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAv RGV2aWNlUkdCIC9MZW5ndGggMTc4IDAgUiA+PiANc3RyZWFtDQrLZhXQ5/QA2SfLoLZ7SFLbcLHR 9yZ+D9phCTh1NuXS49UtzG2I/NmRXAu92LVxHRdesq+1orOuisQtf9b+5kWus7CYv5y2j6wpI/Jc xSj7JZsK9ed01Gx3xP2Fga6F+JoYkb81RQ1MNG5WRJIGyx3lKDwfm8jNf0XhrdofNgo0BLXdEUDp xjgIAzu8UKvk2Hi+4QXmkFTmjyN6PDhN+4D6jkgMYlLLP142GaKksHJnICDoIKd8hqksNuAI4wUA s30o1RyNrxx6HkzuUgvENqWybYg/kvIPkQuqnxZhg1kynWaU4pC2e6FRKBe4wCZ/JqWX97CoJ7cu oSfmw3u7hkLVVmjoNh+e0f3rXrQbnjQRupMWKpyIEAyXfr6/DCXpu+l4LT32Z1HxqEnoRhlG73bN 3xKOcPyndIWm8In6xejB0uRb08/GEzn0Hdzp49OQPjBdS6Qte+MO9O0b8LOfC6ez3nV38lpwo0bt YbXGtq2o7b4MbmfB6YUczJJPWX1ELiKDtb3AN7iyNHXK+EO3tTxxBYc/hGyfLsccbHBwBU6+7hEz Cgz6Y/A1erfjUKybC1Eq3BvoLe4E8UPIyQ/T4Tl4Jm/++vE6BzWy5tKNL47p22rYE7+J4jOuCBEf EfG2NMc3QtmbOjGGV2hXHJfFPfAr6TCOWD8bq6wbOLk2ScOgjcfuQxW1MrGw9Q5D0F8NZW5kc3Ry ZWFtDWVuZG9iag0xODAgMCBvYmoNNTU3IA1lbmRvYmoNMTgxIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xNCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRo IDk4IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdC IC9MZW5ndGggMTgwIDAgUiA+PiANc3RyZWFtDQqfbt8cBRD35GwWniHlPU+LtHrbYczDGUMZ0D9r PHJfE+8gJsiCZ+cXls2zKkA+VJh6HbphKYXFgXM9hPJMg4/htKF0nn0jOU3QZVFDdOWni+JB/u3n TRbVO4V7G43If8CwO4zctFebTRw2xwOghgkzWlhGU/vdElzHN9UJ0eYFLUmr91NRNoAPdFKXPbPm Q+555oUDhoUDTdcNnXBh6oKLrbO0qliHoQhS3s9srvNVMRuAMDJ/wBx8Rbqu1ZYkDwlOq/6t6Sjf 5X4OsDYTYLZFSSl5+ZoUe2YQYgwhY5T+g9IREfugnMrR7cN6feoUMFYIRBkr2vvTS8uMTTgtFrLO 6OKiOg09fOQmkhDrr8Esi0SJoPPzcYiRkgN0ADrqn8S/aEYXxxQDUCpt9JoGoGeVLEO/O3duchqw ckuUEznHscoeITDMxcf8r62JSv3k657r8Kaz/ml2Pvn50U6L05Hswt7bAhr31TAPreju29SVcNSb NOSWw396kylmIwxq790IhZVYbCB8Ej5umqdmoI1pUEQMGTfeB1N3/87E+tONsSRVk3nKwHX55Xjq veFBVjMx1jCVShvGjMLpcY7TBQm3XStsqYtqTxlwNOC9V4gzNVmqj1DTb9jZv7Yl/nP9BGV3GDPT ixtZI2n4auGqX06ud5AhVW31CjXbXWoBdVKt7nLKql7/E2l/rYHlw2cXV1+DCfLTInyqK76WAfmT j80Cxirs7lgd1TuAlMrZNA1lbmRzdHJlYW0NZW5kb2JqDTE4MiAwIG9iag01MjUgDWVuZG9iag0x ODMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTE1IC9G aWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTA0IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMTgyIDAgUiA+PiANc3RyZWFtDQqoLOLS ycFR6xqYqjtzd9WxQ0meYf4lgj7mwBOzRi6Vwj0QaaAF+dO4wY6Jo9eYmh3FbD254DIxd0uyq9X1 4/8JndBoKWjYXzDss/jBtZCOoP1tln0SoLrJmdDtiGQpiWTpToAGIdHRzAhdFv8UABf2r1Z9Fijp ZmNMVgMm/oOREwqdaL5ri8NxcY/VJsnpUdEDQTyhPF4lPnavIXTUE4E+j9lgVJ7bJ5EHIs2QmoY5 ttuoP+kMGKr/n/ma5FVKbhFuaWLnz4hREiDybChgutjdRWeOdRKLGYWgnlhPgefby6uxfUY2Usve zrkHnnmDVLcaHJL8DeqNV5CfqqVP076pCNX09v5Xj/EzCFtB3pSKF53ErBRsaEdm27QpPMJ4jgxq EZdiVbGZKN1B3agauG56RZ+ZEajAGcVGbV57nLtT7kzdZ9Gc8K7SaHWuL1vFQyRJZk9DWI0iRDWT 656y8HV8j1tSKBBw4rWv+scK50pDCRXLDtRhKJlT4/GpAS8AfD480t984qqjCUuPVHUwQWdt1RlF aD73ZgCa5VitaC+tBtp8XYg6fLjIAmt8ctDu+u0JpufX0KdEYdMmmSAGrVY8tsYCHYQX1qra/A4W dLIQUuopQFfbi/eTHpG1MoGahvfrIz2adMfBnXeAEnGUKGUM3tyBRN0I550Dd+sRhYM4s5oykbLb LtbiMtmHgdcNZW5kc3RyZWFtDWVuZG9iag0xODQgMCBvYmoNNTUwIA1lbmRvYmoNMTg1IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xNiAvRmlsdGVyIC9E Q1REZWNvZGUgL1dpZHRoIDExMCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9y U3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDE4NCAwIFIgPj4gDXN0cmVhbQ0KWkToDqKYhbrCOGsl tnflgga/+6aozwa3tSrEBCzUdLdx2Jh+19hNuFf6+xpcvAW1m8be4lmBDnXN1jaQ5ascBwqX6H/2 sPPMZhYlBYmB2MvAc5beUahb4cOM4JNANdC9gm5MR3GlFhTfK1fnNTROYt1FoKBhZou+pHvVMUhq KkimbMGg0Y4PqKuS4w1SgAKtrcKBxNlmFTPOHuORwKL7XWWAGTIX6y7VL0b46NpeC8ezXw+qfQ+m eXenRsvWRist7v75dTZLQ/ARAk5xhrQRbpGSKMxfXGqVvIGbwD92n8U2+4FWoEGbqKNHHnLtXOk3 jOI1YqXRzGR3WPEJepWWOAaix7QiYj0sE0lOA/BX5iPSi0JRri2liT8brs8pqoC0zU0dhVGoYF/n FscfQ4UYcz1y5UUCLmbS+Hjr7OdLkwGYK9AbocecV+w1Btzo8Ax1pQHuZYW/26K/PqLepR9oX3h+ uSbfxSZxL5w8in2mh32GdhDm3XQq2U8UdNRNhVCl99tiDGf0NjcZ9dRAhWoSBSBy6dLaaFLF4oDf UXMmc2hhhQZVNEJlqGDt3GZwDfxj8dqrC8cGrQ/QV6MXGbNo3bTNRhMAgNqN78ahVpjFkpctYufD M5r8iN+BHhpDsWioJrQAq8598lnzyIlZnuJQ/8YJGs1DV12qIOYPo1Tv2Vho8xEDd9NC1ZRc75Od HbbrXPPSozigzVU8kn43fPMaMUW+k4jNig1lbmRzdHJlYW0NZW5kb2JqDTE4NiAwIG9iag00MzEg DWVuZG9iag0xODcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1l IC9pbTE3IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTkgDS9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAxODYgMCBSID4+IA1zdHJl YW0NCiIrh5KWtC1di6OZU7nQDM/b/eONSEQiOnYY2Vt8IjP72uh1/zy4ufZnuuMrjZTLoQ1aBfK2 k2/rExzEvr5HDqDdcVOWJ6ipo4R3ADZmRBCUGMtiV9BQ52h02QrUl7WdWZjRVBtdj5O9j0sbDKB5 majtaF5nKm2vXt3413KOKleQ1rv1IK3d2XbuQLSIb3K41ehrkzIFDlSXf/Zb5I7wKW0yDeLPCHwR unWY+xNbU8nzSepmP+xVizIwAP3LDQ7dTj13tard+h/pHdLq2heFkTmRhanFkSTnZkpDlGtRq8Kf vys8ak8WvFjYBW4gEdQORaeL5tMBqy4Qaz4u7jv74TsQvsz4hAzBAOyEdB0XYUtoQBxY1UHTMUFT wPA+Ciq90hgey7IxWqzJcPItkT5Oyd8ZiKBWm794XGLyLTB0ifFAcEtOta88V+IbxARSLZiuFm/I +h+nRDHfrQ6RLVS/jRyZkTZVb5s4PX3MHM4HsKQSwaDnp6YY62MFCfs2CeyUtjO4iW37ZgAwvfRX XaF4W5OjyTxHSpFuvSzagzWVLZOOH3oiibNffQsFk8vUptWCDWVuZHN0cmVhbQ1lbmRvYmoNMTg4 IDAgb2JqDTYzNiANZW5kb2JqDTE4OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltMTggL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMjEgDS9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAxODgg MCBSID4+IA1zdHJlYW0NCl4PPa2HnsY6sXBd93KI7Z5wkvvJj6keX8a0NDeSCEs9ll8XfrYCwWpm U3EI7Qf3bWALlXs6Pnk3/85c4NJR8dsjkzKMWXLCTXogcSxN5CP6V4vil5/wlXlhMJAB2LnsjQ0l 4eKrK+XsQm1d3pX7ZfoqMnubHNk4qumohgbBVttTsC6a0AQq15zAdTE8c6u/In+bxqrcxihkODg6 Wap2xNGhHBLDw89ds2nnVTTh3bZI57CjxODRpycRq42/JZ/A1B1OQjPerwJeqTy+ch+yPiBhHG1l YLj37OgGX8OjfbMnGC1xfpwbuj67PYg8flFFNHtHotp8Fyn7xhuTXB5ElhpN2IovdA85yYvAz7LG zei+YrwTBL/JaLIdRXEzTFpSZ1wH2kalfSbFSBtN79+ZEb/l2eyJAEHJEnCyCwh/oikM3dGThvBl duEw4xoXZknR/8sbNFUCnAe6Ybt4m87pAwSunRodLbhbbslxp475JbfLlBBeAWjQpgT+CzeMgGfg ChCCChbqY5fVJasawcUir4+dwZj7ersU37Vh5WKB4kf9zkc3B0x/1teiNA55ReTMaLFLTTVyWgHh pbD0s7EKXGcIkAqudC7dzl0LoKsYfi24AMYhiFcJCTguzMwfC5AA6RXjwBaMH32bzCpoeImGq8Zi m8J/FSMB02Atiw/+I9896GDkLv7lF30GAG6lJ5yyxzTP63mhw1JcEeqci1+hUYlyEgoO73Dfqokk y7nw4aj6s2n+yEFTmt8kPVMG3/3Oo2y61QSwhuChCx9d96e9TawjmPnLLqGo88jhTqxLQ+3+Ci5d +VCOVdiHvKDF5Vdzb9M726nwqXxDTX3k5A1lbmRzdHJlYW0NZW5kb2JqDTE5MCAwIG9iag02NTMg DWVuZG9iag0xOTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1l IC9pbTE5IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTI1IA0vSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMTkwIDAgUiA+PiANc3Ry ZWFtDQq8NBdUU4lKT2VWp4m7B4x44fkpMVHM+JQrsyKF4j2P1Agc2S06oeUVengz90O+vpvd0NTa XQgIkgtcqDgX+rpAoHQvY14rcXGmobiuL6Uzm9add0O1uLlGaPhTCfw8u9VxmajMdNAFs6nIXd6T rtjd2tjQzJm2AaH0OLcGRWvsILE3BdkO0dinKvIs4AtWEd077dquo+PUhgHoEDCC4YWxAjsZWZZR HSzQLtxpe9jtMGrMwqjBsCTK/35kfsztDEH7ID/9ZGwNvlwuuuvi/c7Xx4E+YLpoVY3ZMDViUw3w Nw15+/73tIAsoEGUTSXJP4xGWwu3ir324A2VHJdiJv0yzQHc04tEiRu2cgtCQvXwWnxF0nUndLJq YTod8bPwZ54MWe1otP8r/E7TajPXF+KSEAsBZGiczNUBpZL6KQqw+LGaFuoT8W91Gyr+e+EfVCiZ WVCBk/AMXFtlBNmYcrpNBH+FdhnYTjGkBYbmtaqe4pwzLrApNBwNjWZRd92JjHCKE+8gZaKHl6ka S4d380apMpLcBHyt7Ez70J8E3yZEYrtqsZlwdnbnZfmkT01aHpqjj/uM2onC3WgE9gwUyaWVOHAW c0zoaWiGJe/X1b94BlJt9vL2b9yX2TxsfVaGuBls78KUBgQqOO+/WPOSRTPjFN+zcJXJw97K6oMY w3cvnNqDemEy0fWbVySCn4JMDamvzb3GTa2jwaI5JJXNTjaZvKdfIu8HsoiWSbl/PLKgCbUdfPCq MQoyySSx1vDbWA9idFQfakLqR0pqMZKSXv6dLZj9Rt9DD1OlfgvYGICfA7dtRj0PijAij5bu7n5y Z2y8E99/VM5wB7kqOCf57hihfOUMHRDTv+6jTa+mXw1lbmRzdHJlYW0NZW5kb2JqDTE5MiAwIG9i ag02NTkgDWVuZG9iag0xOTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9OYW1lIC9pbTIwIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTI5IA0vSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMTkyIDAgUiA+ PiANc3RyZWFtDQoA2FUmHghsP+0gKazTGq5XkUENF2HoUPYHyRsNmc4fER2yecMnqjIcV2STG6Df PSjMbA5zQdnhWt0u+SPYJZJFO68SlUmQXWEv/HlI/rRULtWBAePjqRIXnSrukxyJTeB+a3or7yOV Nr5W6kffpGJPrTygVTdFN3H4a/KZ2T5+YJ0XC1wDj+LUeOfEbBc7N8AlfJZ5H1tZqrmN+w7VN998 IeWLMfNv2PCkcb9RibZRdurQPBmH3Rs/ClJNMD5UJEq6thZCt9siAWofIqajBVA5sV5fwXB7kqqA xS4hLofG2pKpR9Xgz345Yzq6sxNZvz+kRxJs4toGRoi/MrINJgqqSjbiblj3RN5znMkTdCDrDHRD 9fq0e747We2H2PKa36PaRRFgHFaWEk1/IhsZGY3KNAK7cgZneHV/fe6J8VDTDHQzTLrdPjBHwivD kpoBnogbAZsiyPPqdcggjg5x2WK/DEgWUrAzXUEB1o59BkDaC6O4Zor5yIP/12wKPFCOUoWyp0AE ZnnC7tl1OskzmBAQNQHkVs/jBlxnVngWILQy1DGkeMcMDKsPrIprQ2nubExc3Qrdg7gHYdVRHpAx LezMgltG56EmhSs/pnZtj/bE8vGiDwEttkUrXtm0m9kjHItKYcuWUDa49zsc7lG66Dq+/a6NoP+j 0NCC3rIg1+CfKQujh8Su81rB1ZFEsn6eEZUSa1ArDEC2Otbkg3iZpKf03ssnKboD2g/zQBSGxccT k84G79kW96xT22OREIdBGFV9Xy4Rd1qe9KHFWoWeZp0bKRPV+f3EgIF7E8ebNL8DQT3SKxP4RyXy 4j33A+bhzmQ+fu/NQwBS3c/27FInDvodg3UR4Jw0zVUSIcEbHSU//TMubQ1lbmRzdHJlYW0NZW5k b2JqDTE5NCAwIG9iag02MTEgDWVuZG9iag0xOTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTIxIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTMyIA0v SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5n dGggMTk0IDAgUiA+PiANc3RyZWFtDQoQ6NiZL1zLaJHggrS0YXTFiYDBXjHX0HEf9vmGdWtEpOLH EofdzXdBbiwmyoEb9oussNggKBWSftbZccTZVIsDlf1CcGkDSOyV7HsN9ce+yGTyfsOzeoTKibTB 3dyT8ndOBviW0mljPH5rDWHO1gxT2uEGrMIpPDY5p/vCCN3tbS/EesrQg0H9f/G6S6YRUMYoCb5i 3EwWGMKrxMk/PaSwpAdnIilcTNdbAHaQMr5Y2GgtyXQx5SreYlIUgpWkoiMa5J2d9qwk3Tgv0va5 Fs092tF5YccGPJq/IHNlDPQVzNs/ScOHUKKvNZ+o5ka9sKnWt67UeT8WtsK7fZEv3TFCfM0fqcoK R5A9A2kp0stq0RWcCfJLH6CUWcAJK6EwaKq9wqAk7xSqO7JEq0p079lDmsFUa2SOcQ91HWLumnQV zIfhRrHGddcFGbonbyXun8BQpf/7YIYm3fjDa8GAwEx2Ruh3PqvDSb+GNGLbKDg0LCIoW1Rry7p7 Z5t08Ce2NLqnp4dJUDwETX1tUVDZaZzqhoXRAm5daUeYzhmK/eotqnu7lWfO2yc+TW9nCu/ErP3s ePsCredmxMu/skCeKBGK+ymYQBh7cbZ5S8kl2EChATrUPdsw1fRU+LITbpTpLQVk0kWD8LjhFh93 ii+HzmyOh3QJZQtcPWXrbhoVdDMVtSfD5fOm/43z4MUt3rVFUiydQCH98vWz3wmmAlQSzvHeQ5Wk nEan9SYgMplShsKn4jzuCUpR000Lp+myLNrQX4PeZ0NUlN5rlQQwXtJN/apySvO/n2Av+uErmKtQ cQD+1+InWA1lbmRzdHJlYW0NZW5kb2JqDTE5NiAwIG9iag02NTMgDWVuZG9iag0xOTcgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTIyIC9GaWx0ZXIgL0RD VERlY29kZSAvV2lkdGggMTM2IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JT cGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMTk2IDAgUiA+PiANc3RyZWFtDQpNnvAp7VJw17kMvveN e2Sq0vu6+ZSuF5rsNSFNHB+BFDYZu6jiEDLcNm+ZMwe+v+rLYehu2boJc4pEVIPA9tnve9F7Ym5x EF2Y9Oju7hGQkxQaBLBehQocefTtqRA6vpfFarpDY0gPNG0lCvsB1YOGmh9ol+AnoK/XBc/65KEE 5i04goeGkF/F1pOVEy/EAtkpRAr8E/rmMD95r5VMaszlkzCsGU5QXEVIUgGWFbMgpW8RaipL/gZ+ aYcsqjvEcS5GqGbmfvRilcfy6IO/CO7ieuwZy59TUhwp8z/2m5s8bcJ50iElaJwrMWBhomzYo/bq XS+MeDwozK645FqDFCGZWoSp7qXuRvCc8Y8W91SYCkuP+tIFZLaWjPEqHiyWVEE7hvtwwZOS0qGN hUk07sn0/5/CFFQob+saDVPioJlzz6X+45nuScgmpErd8KfG/HcyvRg68tLTqLywYujB74djv6iy vdNpzEWglqBHyRbHoUEPY/sO4LrcVI3rsK6ZlknUGFOlyIdsISvoRLNgjyDCQR+0nafDH+I5nK2M RTkDPuKQw4rRJBxGdqc7uVYhub+oEOWNYuT1/PxXU7MueSpUzO2qCGv9HsZXnQ7vsOtBj66t1VVH AioqXwEedAu0+eVnUPkXe1A7NhoW0eILekd9BwiHOB+9tVcxoEsCAaLDQK8RrIKK8xH7wSnNvfW+ cdm0mp7YtdCy+iGeKNblAvgHzva2RMk/eDbv/FlF8tGh9tX+4626uP5xSdk0c8v1h6RCMvAdNaXa FrfQVK83hMvNyhYM9v5F9wtBOuPcX4Qc9c/+xo7xCTQRQgX2XENl1AHErqcns2Q9SS2M15GLfHyS /Zhb6Y+ecp1i6Lb44Q1lbmRzdHJlYW0NZW5kb2JqDTE5OCAwIG9iag02MTkgDWVuZG9iag0xOTkg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTIzIC9GaWx0 ZXIgL0RDVERlY29kZSAvV2lkdGggMTQwIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAv Q29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMTk4IDAgUiA+PiANc3RyZWFtDQoVWByz1bN6 94ElJsLDoeMoeogFzXU/7ezOFBM55sCcMEnrV77pyI+iTBCyQAYDsTqKA/5VYx8lWK91uWLB3sDh xjqFlJfitEj9+OLeGG6zTUOezxo/15HDst6dohlCQJxmTvXGwHNuH74r6TfIJ0S7tB55bzyHNYCo l9an3EQgVN3yPJI3nk1QvKC0tLgBgEcdQQQPCOkyCkixllQBMFXoxTaayaOfuOVWhTwfKji2qpBe BiRf/Oe6QaQ5CAdEJ58omPWPetGCkeFaexdiFitHvJioBAXWhwCu/AQcfXinbA34jvw2N428050z 7mxS6T5Vdr5ZEDd3saCkJVbBEHUlRU2EtVYnEG/S7VC7/Azl1g3yojxgDeCcUGLP0J/+8DEHxOsP mOKLCX6h2E/jj05Jb5aNtmADL0jVZg99f8AKAeAZvS29oWSNla4DoGOoxNIOb8mj4jBFZx4/yen1 Q+j0kkPE2xIhYt+cxtgKBS+4rUUQHfNESvKzOrtZhxx2NKMJlGSYuGuyziO9bAvICNzr8l3LzBkv kvGsHuccuAf/+SJlDSL9VF6wUto/0MWv25eyQvwuvRMy5aQ3Y0nex7La221wHUegeCNS9oTXWqre D1vSHgOCqb0jyXQWzBrpukss20F21xuyqm8/2jSXTeHQgNkbKT4xuX+J9piVGkNb5hi5dNdlQmel qO9g485Bc/NUD/7kXLymcgmMDSs82Tc7zek7lAPbkCWP1awpP/qS7BmQKHnmyK39mlNjgGmd+3W/ Crg5ZCHT0jugMMdmBkcVeb2gCZjjCw6b+Trbw5DJZ7LbIAW6QDerHdXTDWVuZHN0cmVhbQ1lbmRv YmoNMjAwIDAgb2JqDTY4NCANZW5kb2JqDTIwMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL05hbWUgL2ltMjQgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxNDMgDS9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0 aCAyMDAgMCBSID4+IA1zdHJlYW0NCsgVKeIzJDYtKea/AimNZr97Ika9kIwegwFHIo8fC3drNEkr nvfcLsIpLoy5+2qQj9pYMZqkAR2ls354fY84/UGDDJpHNf4NO0iHqbtQhckaHX1MU5spvShKvWYr K3qAnHTsGErIgyqFa1+2/f3jGUKt5mszEE0sT/x1U5APdmHeAzUxGnqEVxgXA1lv1iFQ33WA50nZ tmfbw7Z0SWBf0/kMgZY8lK9gAneoKuj/o2T1+8ScwJLfL5GgkWFL6lbuR7JjpCAdlyoxht3ATIQ7 FZr34OraoJqfqy2iQ/mu4BN98O/UMcFvFU53TfZkCIrC8NTShWhBfpeInk8a991beR0ECgTlIL35 pdQw5gZLqugbWhztXjDlC+v4lm7bWimFMIb1O+MxUrVNy/TTL1RBOI0hlOLzs50FJGNgVXCfPItg GNH7HTLHPCIxjoFj01SMqQj9btkNAuaV+vnbqlYWT5FVIRRmwXmr7QCQxC4yqO+oQDz0tTEBWgx0 kdy5xtLnj00k0XN/BRlfFrJVHbmlV8CRcKY4yEP2g1oFZjVHKNvPUsPGq8baMLvNCwklmk5jglIM 63JxcMJhay6/9IrTGLUgBiAZwFZHOtRRnIFl63Hqh/gickaewZYGAZVUZ/r0nqFHWTATW4vj+PBG ZuOGCXt4lMmJQsahTgO9MhiQyYWIsp2jcpc7X3uoz+HuCeLihFGhcDkJUAm3m1jLhFVvTxAOGggH wDkKXC+7kZNHckpO7hnwM/oLKUYIqRMaK1NzAPynSwZ2IOo2yKM/tUKHofHR4N/OBLSEyFXZFGIL wviDdoByvPQJhLQRmxB0Q//cRi2kFYGjWwKy4z31RDxHgEPi6kB9foQIgHzE1CBCaVNOv9tmPlUg pDbgFZnP4Op/iJ5j8eNKKAJgB/Sxpg1lbmRzdHJlYW0NZW5kb2JqDTIwMiAwIG9iag02MzIgDWVu ZG9iag0yMDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9p bTI1IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTQ2IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMjAyIDAgUiA+PiANc3RyZWFt DQoK+WjHkFNhVlFAWbwZtUIGLD7/JfigB9Q/WxokvQSxIIC+5eiBI7m6v8yPI4qrgPaTqSOcamHb gBxoMIBhkl7uwsCJclfJqtdJ0zJcjE/GFJ7+6wZZ68zxhXQyYtXY6WUxLTJZ5khaCcXThXhjOcxk qI4o+wHenbd9PvN0/dg9i99zfbEIrvYDncuJnGOph32lO/yTb3AGUpzLFCfUJ/WF6iHEmXloc+iG o6zWnVPQuPYYyVndmsnSgglP2QwwTP6InlJxDLC+Pcidj4ZBqhT1TW+4FT9l7hBPsS6qZiGZUXki o5dkPd0FJAHHI6E7cpygTQSg7w1MjI4QWQqBcHKkZNjJqUb7YepoNzhcg9HEZtw4NXAY29Tb5wCJ S9wB9ZaRHqB5AUk6qa1TYg25gRdx+PodiOOTo9NlWeG0yJfS5RrfYdC28xPmd9eyxiqg/UpSH9PG rQ2apMjJIjlaK6dDiv0TZPeBpyTNNZrsXvDfeLl9SSRaxbWMiEY28EDt/s88XgAHD2+c/RZRtatm i9sKSKCidFJ3whJOvKIDHAnfs95kDdrvU8aX6kV7hUU2SCeHPiGOc4Y1RxCBODF3ESaO47PFx/Bq HdLS5yQn3sKrQAuUPFykvcspQoNB6FMhGOflLil1bESjqKD4Je/IBMiITF6e74crRhnSS9hE3yuu DnIdHesVBDAH7antI3OyuK1DGNylvxw6xFlyPNL2Bzc1FFlJhmernuj+x1eUP0zbbXkytXb22lu8 kdb84jbsOre4N90mDzk2Th1+oZliTRTwpllcIm4ISW9ybxfFK/gaV3RFoxBycnJiNrrCySCVAJha LtgsxIxjDg1lbmRzdHJlYW0NZW5kb2JqDTIwNCAwIG9iag02MzUgDWVuZG9iag0yMDUgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTI2IC9GaWx0ZXIgL0RD VERlY29kZSAvV2lkdGggMTQ5IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JT cGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMjA0IDAgUiA+PiANc3RyZWFtDQpF6VaR58HK7jp7A/GX sLmzsGW3eAIOzvTl4SYmrPftd1/IHUKNZaTfT1bE+nT2kGAaSqkKL/Evg0OHOwcA/6CjlrvPT2Ue SHmTz7Jwv55w5SghYCkkIyq6FzrURRZj9+qZzlO2p0SkvtrNj4NqhTA0DzKTDPKPj1wa0YKcUy4W rZ/TA5MyNXwXYFS4PPegQRJ+8eFNc6xwIadhY/p75wNZni3JKQawYcXcocZRXMKtfUG5QxPFdcTr 10h9MgnVlSMZ55SBpymjIqKRJIZ0GFVjezeLfiHII98MKJIt9V6E5+V+EAJhKAFaAnhBQIoevIba +kH2vbrWsxjG+mgr5cBgi24t7AfohKZzxKwEBtNU3F/JDlIgEPA4Uih/B5kDMrpf5G97l1L2MpT4 FVfR/TAChSuEa4vcc63NmDLOx/sS+Bhcrh/YMFKmQbzkd//tWh04WHiK8kaHK9yCVFhTNks7LWIV kplSsfW8vnUi119qSkYoBjkwI3BloIFvxjhpH5AAy7zpeJeQoR29KAkP5LtJsllXs7DOEBxbF3VX 9S9+12Dw5iYhHO2LQ3jBqfOTHdEmFka07lGgkIHJtmbs2EEp4w+VaS072bGoucbE6pk1zofUxlYO 9P9yS3fBkMWOEuW7L9KRypZWCTPmtZotbBvUZ8FfYZdAliVjakP/YwAK/QfsozVzLJuWzDKtARf6 m2MBCffAFaR9BGISMGu40dx6QsErA5/2/6Hu8RyeVkLdAG3FYhGG7eR43DYJwZHY0WFYxdm0Vl7G FADtu3t8GVSPXoIZIwFMrFL7MVgpf6CCzvlrIkk/4mqNzTH3jZmSoD2+zvRl7Y1lNVlhZw1lbmRz dHJlYW0NZW5kb2JqDTIwNiAwIG9iag02NTIgDWVuZG9iag0yMDcgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTI3IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lk dGggMTUyIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNl UkdCIC9MZW5ndGggMjA2IDAgUiA+PiANc3RyZWFtDQqK+uL7M5gdAUcH9i5c0geHhLpbZ5GsDrAE Xrcy5JHiVfxyvYAsr8zTVDvZmLOxHnhcLVXlWa3qI6Pi4q7njUUXI3ILxLgKHoQi9JXyIkZYE7Cb asjPiTRZzTntdRtbMDRFl7mkob9FK0fUowfDhzWymgAdwcq70Y7G9gi7uhrH29cPogJ9/4/j4s5b TVsnu0CqEvFZwxF4phHZC+XkyDP7S/vCDYuwgLTXltGJ8CiiG35pWJaJwmevd5mGeROxIGM0xlOO lllYSvWQwsLYq/y2/y7uxraMelvnieUYOiG26NDkFeTxZbGUsY46SsXdLDM8q9RtFrhq+sNT/yrp 6DwDDr6gA0Vh1wEdi+0XFmTXg2Z0fmAAT8KbAQMbe/D4pTcbIeF4v1LLj+kENoGreR4h0as3qudd DtShLi9V1e9qeN1E6w/O8vh788lV3h60RPu3xuqXh6/vePH+LjRku11VzdliH2tduVvJIEuoxT6z hJ9wMNWvKyosvrI24tnJfOxekB+rt6OultDooUENO6vBwsyXc95aECyAKyvV8UJeS8UqRpm+my0C 9BVz9MLGl8Qdcdc1cVqs+FeFcKFLswK/xmxWWebeqtp0YSgVr4+jXq2XoiQ5oWU6hf/kfrrLM2A+ 8oHciLauCTg+nzY2zBRZrS9q9F3ts9kAsDE8zqSIP8csSET+lnFvGTd8HaeXMSJjwW+GjyRlAutz MTnqDusyQq/ocYunzDbeRQaVT9poTNTT+W3AEismfKvVmHLFm1U7+kOkx+PqyEV/sFYeNwu/by6G XIwvt+DX8+11cmFMTQjR9jKYqpUL18Ff2jmnjfIXL4epp2x5Yu4y9zeB1r0xOUn1YmApQHVCaQ2n DWVuZHN0cmVhbQ1lbmRvYmoNMjA4IDAgb2JqDTc0NCANZW5kb2JqDTIwOSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMjggL0ZpbHRlciAvRENURGVjb2Rl IC9XaWR0aCAxNTUgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9E ZXZpY2VSR0IgL0xlbmd0aCAyMDggMCBSID4+IA1zdHJlYW0NCoiuWJNFtuhA6IxTQ7WNgiqPj8ox PuKaKzi2/ykb7CLMVxLIxxymwpAqOpFy+FfQ29p8N6b9DvH4GmRZ4AZGekVNOId4Zd3E15ZtxNTt S7MamL0aNwm810JDs9T4K9kHUsbcqynaUhOTLJlWRGKf2nQ2WVQWIpbtY0SPJHsjaJXZxYz6s8xz 0C86z/oSnRo6snTuf5xMBdtCdzOV0hDRYM/NDMpuSb4aBWHVmtTyHj0ruS9fGyo1iOARsfruf9Nu ZMtwYFZCzj/ebE9nTP4WfUWAk3kLU+QetVOoOZSVuaROlpWFBrqp9IH44+cs9UiHO5KkzNoGTz0n GL3QhEuCbtmmOVgaimG09XOEgv6VbcmZ4bMysV2Xbm9rbyjkWwEkBKFN3NJDOjqQiLDsVcnfqVRV vz6IUERkJwcJNTJecOHwDHtczvhr+16TBcVxZ4cE6mm43MB6KcSvcLLKWx6oDRwfTeSe8IMiNAIL gG+mmqmXS+YaYK23RsqHVHjKUueXX9rAg1dB7lemTdT0Kp7cokIupRwhdrtG1olPBu4YSlKkKluc u46sPmR1ydT8mhfBF/mtrU02wCOdGXFzuSXmpblyfqIeqM5wCIG4NKSP0RGNNs72z1SU4VU1GjVT scd1oRF+lrtXrIpnrTjYPd6Cku4v16bXITpp8hEIEs3k1rqYutJfhHNJF7I+yS3Mt/T76g4KC6R2 XNU5vXqdiVyKiUVQWeYb6Hl8hqRH1tjw2FejtUrjsMKbcbbabbPrwbXqwSSMCpL6jTbLxXNVtDHy xWx5eqhW1aAHlKavG7Y8qOgRq03um+JOMkMYS12MR9WpDAKDcQhO9PMaeX32xaW0LoqZZLctN94r M3V/Ev7FCb7cHPFEEx/N7WLkIfWHI9XjU/HTGQ5QyHmBGsH3SmPB/E/JyQh6mrj3+Be6FK4nhAwy vIeIYbcE+9/ovCY8rh3p/bh9YhiXbxIjZEm1ofghCUb/4PYjz5n0CQ1lbmRzdHJlYW0NZW5kb2Jq DTIxMCAwIG9iag03MDUgDWVuZG9iag0yMTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9OYW1lIC9pbTI5IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTU3IA0vSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGgg MjEwIDAgUiA+PiANc3RyZWFtDQpibvsbGdMZ6yP6b3R65qrQDOVhMQH3gnHLr3Z9eE4iGHsUkx8q 3owLX0vm8/WcOTCjiDdmFEV39h+iyuHb9nTFV/lojN6z2GjiHYSH+cPAeIM/FncumG+e+WK/FQJC DOFZgDdzJhkt6qvCvwI4EVy/QgXWNwUErWx+LYsx6cZpn6pcvMk1wyfFWA2Fi6w6SzLiZFOWUYMf fj+tbvccepHqHKENH+TTCzdlVNRXye87qJ0F6maTEx6RVzdmoD8vH+dNINKpK39kDeacgxNqwFlz J3ZE+hpgcI4isXBeoenF41oeO9B4uccyKebD2ymOwav/K7MPzuXlQA05TSl0RuIKhrQsPQpmwSrT QfW+qxlQ1HseepIW8GDFTclF+sUhsmFvfSgz4jgFPoWVrnuYinkvkzit5rSRStKUAfhOplIgwEQF AhpegPbHtDQzs/WrbFOp4zp4fnYC204StRzk3ovQFXcAz5g0IjpkG6DpZofVj6YdXBMc5TW6RR3O yu6RGter3Pi5YpoK4zwfR/oxWXnXetgO9pNJJHbXJV4MrwOlUhtpVI2psNCXvwsZPhJPBhRkcaGc f1Q00ido8/mMD3f2uDPu2naKEqaqO+AlTqICvqM1pS0onE78sKxCcRm12OcUgVozKl2/PqxX/HXP OVBkCrekR+JvFKT44lLxpZABoWJjjuUYTiI0ZimBHGvGZIRWGgx7Ll3XtxNB8l0Saqwky2TC/y/z NCnqyOk397eJbU6aSsvza2mPL8imRVD6W73tFZhwsqTAV8LXQzZ/j9J1FcLbF3IKyjJV0FhKvkdy 7lfFavZHf/CrsvuLogM5j0A3MGWD/vZs0JH1tbOCUNSzM+C9cClfyvfzMyVRtteq3WOg79s6A/CU RSza2SG15a1xvkakDUdWRLpIEL8/gSoPw7dDWa88j//7f7fb8t6k4iMNZW5kc3RyZWFtDWVuZG9i ag0yMTIgMCBvYmoNNjQzIA1lbmRvYmoNMjEzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvTmFtZSAvaW0zMCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE1OSANL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3Ro IDIxMiAwIFIgPj4gDXN0cmVhbQ0K8/ivkwtShmKyvNA3PR0SfBsUNXVep2wn6OhkXryz3gS8NtJo 63oB4DiGkfrVHhYK0Qjq5dyu6MO8libMPhUPxr4L64IYmpdiGpqCB8AV/4jSUOT5Y2VWDH9C+vCc EHjCA4jZXYeNNw41ftEdMLTJlioAgrDbqbHehpEvt2W0bcnIONgGs6mSKRpG0YdBrx8lsl0lEq+F DODlfYcuq/9qsWOpt7VNxCmhUCaUSNqwSvbq4QAjAvifOwD76JaF0QXWp8awu6bZXbnzM6kdXG4x NinxyaUC4waSVJ4QPdAjLDCOBHjPNaMWREM75iI5arPzQax9mdCcTm2KL4PY9eNMv8xf2QA17dUQ FKeob+mZJOLgxcbOPf+fAlUwunykqYXVpxRQl2F4S53lwhXrCSKao6lr7q6DjJP3RAFUPSnoNBjz g3gaVHOCcXNa1XdnG0J2wJ8w2bobW4Mx/XSDZ9Lw+DR7rrhWbOJUpUkGwDb5m/ghd2xumB9t5Uc4 frtjF1n1gu/s8I6sBd5vB4KsGg+IdoAg/mATtBHEmnyXuGqT/Udb99bxxSeaLc99vIaF0EWmo/QC lzKOi8goXTRm74Yl1EMD34o75+kw2J3WrPRpwP5LJicCxFdVlnIDAOkPFjjceWYSo/GboOpwlmzj rr3OJ2pYiF6AVpxERJpOHr86XkpNHcd4pHvPDziGc7Zh8L8MWV7Y4bzsqunwW6Xg18wldLvmktXB uh0FCZDKtC+RvPlZr2sCVy9ENCvwWi8bUlwU4lwXhYQDOJ2oqhIYpuUK5YFLlyJD9hscfzQ+a4Fl 4z/o0MBHGIs+mOeCsF5swAhNJaDTnVNIN4fpp1rgylF4TQFTdQ1lbmRzdHJlYW0NZW5kb2JqDTIx NCAwIG9iag02ODUgDWVuZG9iag0yMTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9OYW1lIC9pbTMxIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTYxIA0vSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMjE0 IDAgUiA+PiANc3RyZWFtDQqftn7oocJKFISbvG3L18L+yESid29ltpktscKmhXxkEmLOBZDLxqNF PniVoZEH3e50x738jGLRW84j6mUxe/y63ZSHa/HFaTEZEvdeRoOQOE3VS4Grp38t2imzUfKnm6rl wWV9J62ceypOhxByZTIZVDuFbZf5PQ7AF7OhZSkUPAngkUtH3D7FJAmUSOIPEZUSBeTeb0O8gbgl iHAGKgNzmG8bZcxSoeNSfPoDYetYZQnpIrTErES5uRvUynmovOV6KYTIEVLIKk5jlhYYC7kWk3Ad rPlSCyliXF4HJJbxvuqt0vA8Z+kroXpvgefzOJBSk1/9y/Ro3FAYYw73o574O4yg3G263Ib8b/JD KcRdRKn46AIuHOs16tluK6yp80Z52PoiNBPFlbo1wsrQRHq8ehVh/Ek1PGipYbs1UF2TBP0LV/jG OlIKQpTgnvcxNQBWUz458DsF75gUIF0JqIZZOHMAgZO+lIqa9hxvkJvMjz3WLqPNdxvyF1CodPZO DAgJT1xA2ZE+NfihW08A3pv02DHfzUeB8TyNQzYEIy2sdDNfzYCRW13ntC/NgtcSlxKGHmNzUS4i aA95xU0pbeBkbDWJIRm5zE7rS+ck8m+Bfwmla6QgEhtMO+MWCBU9In+bt1Besraud7fG9eyRiO42 XctBhEXwsxS+0hCo9/3ZI2RNQvnqsHN/YD0oEITEvQxazhlXNVrVyS9iOds1szeCydMPuR8C5sX3 oTqYeJ+2ncKIHDrWPDpQdP4HbnjW1ItxPD0Ox3dcb3+HlLT+iH2H2/iDEsslS/p1z1AJu6WbuwW+ 8wrcvd/0/vyKZxeb6DfKSFW1bxxWPAqHMNG8y7N8ri6qGEFksNed+VdVJdKX4+EgKTCME+LE26C0 eJFQRw49gF7O5cmCcwsdngU9DWVuZHN0cmVhbQ1lbmRvYmoNMjE2IDAgb2JqDTQzOCANZW5kb2Jq DTIxNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMzIg L0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAyOCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDIxNiAwIFIgPj4gDXN0cmVhbQ0KCEdp oqF9RVbJPbUwyPL+IWw8YlUl/CpynHkp2+1YEtgVWsW6qqXrSXsFWMwDcl7R3HSWYdqbSUcwFYrb aDsBlDP4Dp/EHQoOAYKdcyIWvtk8TE3w0zSGJ5zja37rDsdxyZZZFwE2y6RsPm13SA82V2Ruc6R4 EU810Cl+hmoHnG4nCwKG4oAjnuCLPQNhaS8AptUpDxE+Eu7gibD5bX0y6SdDtWBOtY1LrPJzc2D9 Qke/G/E9+VU7opMpuogvKrDc91M+NCdGerYiKPqn/l6OsqkI6QLjjI8vFsSNBsr6SWcJp/XStCMo POhCLJ+xbZx/w4m8n2qQ8FBvJTeiq0+26smzW4QiFr2Sfzao2q0xzPYzG1vILcmBA9ME/GOl8su2 LRhN5g/ToVcEC4+6+1ZOVNPhVzntmR3NT9DsIlajRpZNPvbd6eQ6HOkuH+eoGY0ZVsimOGGIUyEH W9tRlvdatcJICJ00xWHWcj8bYyazuGcgB71mS+w1m8sxgNiny33RHpxWtuXZSKjwoICPosORxl06 XpT52HZftpjoC8M7xvSxfBa7+CBD2lirVGkIyg7yJ6cs0SjgDWVuZHN0cmVhbQ1lbmRvYmoNMjE4 IDAgb2JqDTQ0MCANZW5kb2JqDTIxOSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltMzMgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAyOCANL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDIxOCAw IFIgPj4gDXN0cmVhbQ0K+0Z5KgxHkRkHaREGtRTSAm1OezouGxaO9oqu9EWgelUjgx+F0QIi7L57 D3IAN1RtZbH/daTwE3cZUTVmXHZIkhzSANkr1Qfvoz8JVkuDQKH9hcyUEcZ6+8bY5aO9GT143c0G gW2S2Ln3qEDMLui/m86WBVph9XkQy41PgQvy3HBe9oY+MvennBBwzHZN8x+vwQv7SCg8qpO6vB0J 54BDFJqcC0idPnm4FJJ9hKUhxiNH+ZTej4hEecZ+Dklf96JRZBWVdSebpy3yUk31929vH+FFl3ao aP4LPrneEuzt4+tm/8P2C06Bnyc6Exq1kZ4hZOxRruKVzaqberVY7H5BkMPdec2tOh6UuWko6wu/ eCPLDTdLW3rBX9QPEIh0WvX/Nf5WK9rq9kB0uV2qYJWXLoUNX4CO4jBFdh1fXuZ4RfoNIZGbBfSt 38OD+rGrSwtj6AokFQt7Kx1fiL652fLLzVC5D0uBQgtoWrmdL3b9MI2qdOaauNosh/EDOF6SgvtO 6aOOIzZUMGjrk1tldM1Dinaqd84xjEBzPGzT9UFDA5DDKNZ9g7rqzIs/etYbqn+TADYIhXOZIq4N ZW5kc3RyZWFtDWVuZG9iag0yMjAgMCBvYmoNNjQ1IA1lbmRvYmoNMjIxIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0zNCAvRmlsdGVyIC9EQ1REZWNvZGUg L1dpZHRoIDE3MSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rl dmljZVJHQiAvTGVuZ3RoIDIyMCAwIFIgPj4gDXN0cmVhbQ0KS9E54nJ+yCGjeDIyyKXzOGaGhoX8 bT0B3GOQPypUL1pa5K6DJnQdo8aJk09O4osjx9unWzu+IPB9lZxFFGLe7th5ZleEgKJTiiqmSLEt Bek2B7vdqNcwFvxGrptntpMyVCzY2aV6GPSZfmZnyFU+aBkPRi7vb/w5xnxtrDjInmHNrJ20Lg8G qYTxApkM4oWSM+FVL0kX6PYoHyXwLM5v3gWPBNqfPpqPxH4kM0Z7afJdK7IW9RJlIsQkrM6UVz8X /T5xs0R1myBexQjdxMABVhy2gKNr4Bwc644AOmAPgvM/MCAGu/6Bl7YzwGyPdhcgtnTmrp0d/nVY y3Yr9rJ3nXknfgvbleaN4P4NZQK7vRKccR8B+PL67I5uHUbdZy4z2dsTkhW5ZKnwUgEyy2jorqIf UMk8GZXtSForw0b1AnCt7ERqH2QglUaxvhvv+mL7QZC7vnE64zE2Ep7TB3JufLrRE+4Vefwg1anx H3HZyRr1LMAoCePvHfDb7luw+fI1YIVFFOr+qUZatJPDULdsERxQn3okK44GOJQR6GDncIAqXt1a 4hSaW/J9REnVPK3+vL6zrfLnqBWYI87R8S19TQtbHHXfoJkO/kBnz5zRNj3UCfyWul2z0yKmIXXx /8pE36vF5Rjvi25+VKBnG8EgvJKVBPqEEbNA9YzoQIjpkDbuKIZLogsD+ABCnyvPKbvnc8nZ9tAg NRBYyn2pZ1+lnlRe1q3KP6HiMOKr+UuuooobWuHmVJtAA2PMHJIaj1pgQbs9Gl9F4inrjHyXm7WN 1Uc56Da171nZbHLUGrFeDx5G/m/NEPD8tG7m9LkZc0T590neiEFhQu23rIYPqp65++UcqiWqDWVu ZHN0cmVhbQ1lbmRvYmoNMjIyIDAgb2JqDTY0MCANZW5kb2JqDTIyMyAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMzUgL0ZpbHRlciAvRENURGVjb2RlIC9X aWR0aCAxNzMgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZp Y2VSR0IgL0xlbmd0aCAyMjIgMCBSID4+IA1zdHJlYW0NCmYABz64oDd46m81zBTjtLnr1tJLJXqk JO6fDfPJyOMI5trsEXq4V7saemAoPi27LxeINAfuNNANyoJwn/fBYU3FWuvGss8xfuE00PtJjMPd GJJ/RBvSx682PwKPBFVbVvA+7JItqU0r0TNiGpgVFVDeTSdSFF66mD50LpVOcFbLwEAPofhKgynK 4gNpA2voZLwm0b9jkrILa8VYoqCYku22f1tPO6kUWbiSwz6YHCkqi6WRtOQdFkX5OwCBqC+QzIUb XRFK6tlvpPosi1J+uVHn/sMuCZBm3ACEnvYbUB5Xgrnsh+ndP+oqP8t/nzqbr9RTf0MJ1tPSoFdF mmZkbT5TGq4MfYd9HYQ7RO73VmIeiLUEACPwOIEQjwlFeP7Y6iKT/ENCToZpsh5my6+bOQUjkdMz eFklfJeZ+K0BwgWJu9jGyYeUtoB6nqwH4Jo5+H5qm6v0ruD+nOLaN/gi5tvjL3iCejB0p9mYbJTi YsUiDBAFxhyYgvG+6WCZhhMoeIhPfKmRwnC3p1eEAREwn8nA4mFlHgsv/zcOABksz7O0rxVeB/SL gopdql4slwgm5yDzZNt0QvunRldtq0xprO6NUAZlY95erbB6oNr94qcv7HiJcZAREDuRi1ekzMww 2FGlHWHA/lhFV1dYkzEEFWgLwEez8CYdX1vc1HgSQ6kCFjTxo6NMRkYlLWj6XtLYAk8bHT2sL+6N 4F7xMMfqoDUiiOKbZncaJWadj6q0ZlXrlOIlnFVUoLTAQqbghL4nh0lUcCF2HX0X1HPv09NZZyIh evGr2NoulPmkEfu8Vpv0UjxOzGf/dUY6S7CkMJ8hnX7Zm2qmNP7PeWScanPMAlANZW5kc3RyZWFt DWVuZG9iag0yMjQgMCBvYmoNNDU3IA1lbmRvYmoNMjI1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0zNiAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDI5 IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9M ZW5ndGggMjI0IDAgUiA+PiANc3RyZWFtDQoRstc5EVGgk9VcYoaD9AL0zbYh79a2LeaIth6OkULj KZou/wHUSjHBXFgEjNeHFPg8PcgZpBfNDni/uW4eIR4J1520lRrT+WpPGxGnXa9U2O3iizcPcC2K DXoCvOchTFV6qqdZQM7HZSoEshahH492v284fmyfzs6I1R7N12+1DpKJeCKLGoiYYTySCdKN7++O LiqA35zU1y0VT7xdXoTT6k5qx/eydGZDMfYB3ofLI8Hc2Tt6TqSh5jBLdJ79zDTytqT8Q54mS2Cu 9PnV6M1d6xUX1mxUiqaqqea/lPuq6BnLGXUUBLG3xK8UXwVsDS8VsGMzIjQXbtI0d4C6iltJixdN 1xfwP9m1m+iYGo6fGVk9q2GAP20awyIdg13saW/4IqYlfqpsaNUU1qKAPiSB/eC/WeCFYuSl/cRi GeKONNspcyW7GjVERIxGfyeL6VxOwW8uDNFH8ss+hqnFFXZHAl7M3gdCpJw4FmhaFU3xjQ8t/OBZ LIv3Uqk9L1fISKkSXfEkH/eHRg4NI8GxL6QbKHHoFWWyBMigs65kf7ZSLWF8Bx2d2EPw3sjyYWJ0 YhvLDf7YNS6y3v6kUCmSXl71SiactC7fqlWyDWVuZHN0cmVhbQ1lbmRvYmoNMjI2IDAgb2JqDTQ0 NiANZW5kb2JqDTIyNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05h bWUgL2ltMzcgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzMCANL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDIyNiAwIFIgPj4gDXN0 cmVhbQ0KOPdWU0drspKi6PP4WtqBg8l0GN4o+bOmQOfxIfb5jBhofrHX6Jb6OXzGTRYETUObuGa/ IxpMshodG9FCy8+0YMEFBDL+2LckbEups9x0dBbGQ6pWJDlXci8c9ccm5eXOiXbbMilC4pBRvAVW wBbjE0lyKR+aIv2gL/wazKMudNAXHJ9FzqL0X0cWQ6ScjPNKmJflf3+CUhir/J+tC4EJpL4TNl87 jU3yKt8ZtVfMum7H1ZF0DOfN/LQ4Dz5Yp4VSOZYPUN53tLUUBmByhaR3RWslPjvnluPqKbE/SzJy H4yUpl0Dy1aMm1p/7sMaW2bnv6LuIXFll8mQ9ye8FZvds10McrcKAq/1AWPkkBcJIryXNnWyzXcs ND+QqlAsVNKIwDZOq4L3XzwqMb6CSneaIO95lSPjpqvwrfg33cWAzdbrSiwcip36bfOgDHk8mcZ6 IYnXs+mHGxxQbnpAE3i8gfOTrxcrzePMQUcpHPjHumW1NY7h4TjegbjFkSOfMr6rSt5Zkqt4Ws8Z HjW0G0n9/MagsrmvqqNRUVC/MdqpLnddx3dbwEs38IxG/WlUmbMZBnmrGZD8Pgw2EKxaijwNZW5k c3RyZWFtDWVuZG9iag0yMjggMCBvYmoNNDQ1IA1lbmRvYmoNMjI5IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0zOCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dp ZHRoIDMwIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNl UkdCIC9MZW5ndGggMjI4IDAgUiA+PiANc3RyZWFtDQohBTZTwRe/YsFgWuVLJYFKUBYBxt/9urDK SGjumVhJzgKLPEL4uIcAuT1fD7HOVSJoxCThc8UpPxqOR4STJTfPM9RoDAnxfcRCTk3agDDr31JZ w78mUzhns7TH3g42/vlsunZEVIJtEH4yfllbhrF5UKDWMyXuwPOXzpKybquv8jG94bEYJwdt3vzh BVuRkiznhxVc1v33PUEQfD/N83y+tIN3fgKuqQfaNF6YwdI4BoZAdAlfylMoHILjsaTz9YoISa39 p422B3YjSUocH6eXMzQQHEbxElvElm+YWUkWJPCfNlyin+h/lxPp7Ac+FrqFO2nR9aHfY9qTHgEq epOzRvezoFM2auH1aTzDa27OIpjt3ca3zcbynj4g6Ej/DNoexLAH1XXbSOSEv4pgNgcRJ89CBkOT CFpaTDkkCl6DFF2E6dydtwImge+NK8ghxLtvKLOZ7KeknvooeLFobLPA+xxTcYBuvCYXfTrolgON iw63xNRnIKy/HhAZBXL6ESXcIIO0hM2QNeuZfEo/dIaouG5faRCQLqetbs6pI2eHkuU0DCFMMGI/ E6vvDUPZb1GhrDpGA4dINdbO5MwrDWVuZHN0cmVhbQ1lbmRvYmoNMjMwIDAgb2JqDTUxMCANZW5k b2JqDTIzMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2lt MzkgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzMSANL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9u ZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDIzMCAwIFIgPj4gDXN0cmVhbQ0K E41uLLW2XIpM/+Bf/E5ACHGekxEcKELzed0j1XMakGxi5lyV46CHpjMgariAAu1cINVaKbDv/GLm JxiyO7e0A92hikwcHycE463sQ+GAwtrcJLlDpQOtGCL6UiFibWukVrNgjtO423APZ6n5bam8o2Ti s+kYRJYCeOTXiJKVmcxZvPUZf0rhwnwjzwCvMfKIsKuGq+x2fK3NQax1W6s5XyrSVyPG82vNg+qT UKQnEGdcKuN5o4/bg/ACH2zqu+wBjc5iYnuEjUJubDphmW8xjVnnNrWAfPZ+ew1vprY/9WirIEn4 a91k2ouL/HpYdEdBlJ5QR7YLJztHl0zqwB83SGfjSxAj9CoNZx9M6gZ+0rP/i7zUnHrWyVDocpYq CU1/gOOvBZn0uVTnp3qmH8zgHvH6Voo/dWicr5SlDpOnPd39B0T/15dWkZY1RD8FpvrH6+F7Gqkl Ttf+sdO1ADbiEcGyxQl4V/jnGx/UhRfG4XjWqsru9lfaQDQLLvMuzBZoCslASmQ1hT7TT9P+v5/3 11HNaqTUp1Bprwd9pYNMV1TnhCQRI33dWyNT2AgmyblFBmTJrpQKnYizjDZOvWkE3r6hfHr6KHtZ lWsbdk09I8YlvksfAeYaxNSZ3Cvr0qtyXJUsPHZD6VBs8LaWd0jemSX18zYNeVN3RVZ7t6yDDWVu ZHN0cmVhbQ1lbmRvYmoNMjMyIDAgb2JqDTM3NiANZW5kb2JqDTIzMyAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNDAgL0ZpbHRlciAvRENURGVjb2RlIC9X aWR0aCAzMSANL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rldmlj ZVJHQiAvTGVuZ3RoIDIzMiAwIFIgPj4gDXN0cmVhbQ0K+ViqfACeIQYYn5iT3O2ewMuUMaX0VCSs OXJkx7LG27vAusjdiTh2o7SmvyrEvOnTfn6PtQzfdRmf1Kw26tEsphhXHMRyoKvlMymv2KEptitJ BHA7YuHWwQR8ptn8MVj8k+rI8V0DtaBElkCVhMw5RgVRp7z6O2zv6YWpImKPZehJkCVEcUBRhm7L MBfzPNh5GtRWnwGxqiwmgAtGnCsV3qBbFZxulkCN3L3ObsPzDmP1LB33T6zT5k12WHQjyBxR9YWE GjksoaZ2AesQhGiVviHzRPsHfVRXkI0+aEqkna3yumZMQYzm9ES4G7QauRLOKBg1Qae0+pUdRLl1 ozU0APIETtxj2XPo9OtafuyL+1Gq/Sa2ENfKXTSbW5jvDNOUIBiQPwv2e/Oz/WsKEJu8F5C89zxd 6xEn9OcGYup5o4VkZk8/e1ZW4WH94nu9u4iJOXKMKjGDQkajSWzOu6WgaFZSIck9E2BHJtLUj50M Dj9QPkMcPnTU2A1lbmRzdHJlYW0NZW5kb2JqDTIzNCAwIG9iag0zNzQgDWVuZG9iag0yMzUgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTQxIC9GaWx0ZXIg L0RDVERlY29kZSAvV2lkdGggMzEgDS9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xv clNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyMzQgMCBSID4+IA1zdHJlYW0NCphvjrqd0f39sl5N xlRfb4OyBUX84ZWm2T9G/lIxphZRaJoI2vd/5S6yd7BRG/yIxQ0fdjegkI9Svvj3pVDeG2zfJ5+Q UQmoaI9KeUQt7o/+RLPGAg9mkEFchNlbRnjMwyeQ+3sV5c/ejgP3H1SmmFLjP2m4UgVxXZWOMsAE hkcfSTdOQeP7+fVTgPdDuzCtd9Zq6oMouEna23JS2ByU42dba85lDxU0X5bFCfhK0pjdUoBbgk3g o5UHxg/6PLQ3ukg5Wsxo7gTLi+MaoIThQWOj/usaHFl6jCyyyKQrY/ZRIxkz9ax92MKYtK9o5hY2 BZjtK28BM7b1b5twGPmAWZhRbfMhwfIWGZAl04gqPi0k/6ebsiVL6vDjyx345B5xL/EHd/yQCcDi nedDX0hY0wt8HIeKRoN6CVv5z87Cf6EYkDyYUg1N4h+Rf5rdNBrBs/WjNJffi10d/vvn41E4bkgp UQksy69putr23r96z0AX7SjWHwOxDWVuZHN0cmVhbQ1lbmRvYmoNMjM2IDAgb2JqDTM4OCANZW5k b2JqDTIzNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2lt NDIgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzMCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDIzNiAwIFIgPj4gDXN0cmVhbQ0K +rrBwrIcyxDobjeNm5ptCgOKWkn+5VAPv5Y/j37jORiVDQrAmkFx+yBlVkhNe6b2Dn5ie1oaXXpL HuVs4R1boC81uqTXJR1OrEq3NC0leaOJDMFkOdJMVPRf/riNK1iGmycKMTiPVGJljgbHw0YSbcDk Vo/Atj565s92VT5ehPbZKmcDcieZg36B9gWtMMC2W7vVr4cS6L6GpginFv1rs+SQfvTUL6GkreqO cnODO4l2KT1j7S+Wtfjj5KPrsNajAv52IH7rE57zbTZrk+t03E4fgfcTQh7xeLNetZUUSr57liwl T9XdsrTDVS0E2BLawhXCRwE+0IvrvqNd6F+/ZsBH5bxbyJL+l7iwwWRlNSOOD5z+quS3sZ71+nKa wE7NiQQu2/t6RT6nFSdC02V6YG53Et20YaHmTrCep01KwIj9x3h30YBcgNHA7SIpDI7c6rVl9vs6 h9Y5Ts0h7As+HgghsaYGhIt7ybF68x5m1dF8RpnVnNAuFAuE9eUjC8tXemzTrw1lbmRzdHJlYW0N ZW5kb2JqDTIzOCAwIG9iag00MjQgDWVuZG9iag0yMzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTQzIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMzAg DS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xl bmd0aCAyMzggMCBSID4+IA1zdHJlYW0NCiMzp3JHx4s/JMFCNnRfE1gn9zwkKQOKftbpclgVub4z KJR4i4PtH3OdMHWL2fKo1Hedo/T1GRKjysz1nf2ttOLr1oJ9qFcnhzQ6zAb1iOcV+owzA5vIxvcH JnRY4a3bXe7xnBpEZkHz3BB9IGxs8tjzuhyU8dWLfj/YUKcWZ1iXeG0F7P3Cn3O19ADAnrhuKoED c9OCNEhNHHiJkY4iui6uxy+SOHCChvghjuLwX9fOgNfL4VReGYMOSekSR16bv+yD/Sv8FEhHVE2j nVXEZAHTjBypys/pRvVaNP3VNbrgneTvcQLCNhCksl8pj0o84dUycSigGIusuTpkTc3Xh4NeVTFy hBcpCkwSoVNFNk5zs2oUrFvY/JOy/EmcgI4N5pubePCHNOhVq524+U+3iUuct+pWNDaVjHsw015+ wjg0Pj5SZwaLr41mxDFG/+uLD7nhhEBRGrqBdmgd0HQOugP2gz+/dD4ZQZ1y5XNsX/iw8Lca6rBT j1ylfE8e2EMIc8E8gZsdjwfqnLONg2MIZq/9imFSQbQq3PmAWU/Pmd7Y2G0qSSjJ8LgNZW5kc3Ry ZWFtDWVuZG9iag0yNDAgMCBvYmoNNjMwIA1lbmRvYmoNMjQxIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW00NCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRo IDE3NyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJH QiAvTGVuZ3RoIDI0MCAwIFIgPj4gDXN0cmVhbQ0K/0wKqdSpA6F6WRtznYuDSUG0upI1IaZvksmP 9gTnzI9+qkpUW1bMw/uMjbotCVhVKutLLnMLBPC7yBgmrHupqyhVXvw80Y4w+86abFBG2lO92K/4 S/EEvMnYHu0ve7wtOxrp9GhZGo/J0X99Eqj+4ypzUiY2kuLZih+cqt7Roee1wn/0DztE5AV02iEx KMIYTw8TwujYHzFJnfla6UhNqh8d5h1PHSZlvSziSoSsCARZ3RXpCtnxZITSoN7P6CsaxtJr9/8a FxjoLclpCV22gG9hvQfLnCLQ2fZt1OFzYHbJNQvvUspleKbaIY2xuwkkqLDmTzkahgc0K2qnpi00 +u9vBhvJdDhxBMz2Tz51ytliXBk5hz1+/UFXVCR/qkDXAx6M4Sq1WuYRgmtqjXrivcisPqY7eBFL CKoKWMvOF+9w3Wt40zM7D1CfDCvWNT5EDsUIFoPrlG9z3VRY0Waqnza7Mf746CzmGGgFUfe8v2fz SEx2FXhK80e/wcPrv/LzOtK6kfE5PjV3LkOIkE/R/vNcaGN4odLo3odS+gqyGNqkVBiBqtPrN3NB 5Mk8XDvf2rXegGW6h/X2BD2Dalr4yFNgrwL49y4zXn/afb988/U8EMUuVzXp+EqXOUiLJufGR8mz vIYFdumxVRoIq6/fy1NusBSqlJVlw0ZBGlT5qRDgGUeqc/5kRnQHitmdKRUDVgNLTkOG+RJ9q/pp wXvnvF/MU/TgqCoEUDPeb8ik3u9lMwc+maGbOssgUe8LiG/VcerYR7lNvSAruYdJypzf6IbeqLPp eZzbz4Sxevh2if2XNwTVUDynHyuawMfI6HZtHdQ6x5V0DWVuZHN0cmVhbQ1lbmRvYmoNMjQyIDAg b2JqDTQ0NiANZW5kb2JqDTI0MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL05hbWUgL2ltNDUgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAyOSANL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDI0MiAwIFIg Pj4gDXN0cmVhbQ0KIrtX4mATag8WOT/Xmujm71hgJ1KmrvzgQCaArgIhM4YsdZdtq3+JBteIHrl1 h8MJsiVjLQKOEyu/e4SXmjigNzZPFiDiDDUdjHLSVuH9Jetv+/22RTubo5vmVgaSq/HlX1jPgD6d Cd//GKemgl3RgCZdLkZtCAT/C6fVAXSLTg1lyJntzPxZ6LXEVrDfWm0wu9BsotKIkz0BaFzdUIYW Pwc0AyIVhJlvjvoTe6Lfnbk//YFDn2V+MY/uVP7utxcgXYz8AieD+c9WMBZ2YyByyT2ti7utpxUW GyRKv3DmQsiKwsaO0dfrhwFXkfseRwp95ct8rl8Hx0OMkzhYN0BAdppWiBgGPYbE+LN+7QdFMje7 en0Aj2dV3aFZJspdmb721lVW3D13ZAd3IPIC2Mc4UjFXzYcbt7EbjGFsj0H80gmUaBcOzo9cNOWB hlYm1wkO3rPgTgc8TkKzCLpJw7jycbuj7UHVrGomEYlbtbVaAj36sgYZeVCriY32PLPqEUKpfFPN dTgcRYBEvsxdSVitgNp/1oBen0fpJrZGsEH32EViuDEs/AV/q/vzKMYcWte3hYlff/nhZC8dgVHQ UccNZW5kc3RyZWFtDWVuZG9iag0yNDQgMCBvYmoNNjc3IA1lbmRvYmoNMjQ1IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW00NiAvRmlsdGVyIC9EQ1REZWNv ZGUgL1dpZHRoIDE3MyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2Ug L0RldmljZVJHQiAvTGVuZ3RoIDI0NCAwIFIgPj4gDXN0cmVhbQ0KcihO1yKYDN5vxhVNi+r9MR5l uLmNqDdCc7ND+MDiID920TktGOWw1pMwAllka9/v+X/El/0CBgk0yeovnI2fyODNW9qhJDHpnbkB tSVF8Sd89rZ2gmlEOS0yU/j1sVSUG1tgab6e4EF8ZcPXfAGsCDVJdEUFA8OHy2WtR6QZ4LTtF8y7 G+amDG6365K8y6iFwJ1DnYIV/S0ciORrfIPbId62jejltNvU/vhyDT7//zYSImhhkOucDVINwx/K MGsRAbOsbFAnOKLfYKE/XlhnEUcCDpoCEVXY7HRSiZHHpbMGsJw2Eng3ZDRXyNRXBcdsHEYItFaA pAj+pMi1pXVsvFVxr9ronmgL+4vBw5EwbbYkRKWWQc87RSnnmjQ+FujY/+ZjrkrbpdpIXvKqy4uc ycEMdguqJJJhTVbqwI+KKv7UboaUsnY+y/XTr7rQwA8nd6RKPAXeyvn1c+os/BV3BzsAp2Fb0AoM UzPOG/YSWNgxQ8fNsnMYmOkRXvb+DPCiRqe1ni0kKdbMZd/iOoCpF/oFjM/mVVQbAWf/VZfCncbe /KoPBG7KBvqSg0WBev/S5BbZfZBixjKfpSiUXYS4og55Tyg6QS4Jixa4cDx3eqdzegHsM1xFXOAa eNC8KVycYaS4e6/4emLfv8wT0L6ViEbdUg3hz41yeW9iqZLcsO/xsqg9UHsdnNTzT4ZE9l0JF/67 LMcKynlMf/scc8MH0taSnBd74bIDPtDNtHPFxN5InG4uB2AGE2qBAaMnPz4IC6GPtQcWeHbfUfrt CSng9urM1e9yDB6keaBiGXAW46pztjE95vUBToTMYPx4Yi8x2CUKnDiZEoJoYbSxIqY/L4hR5d+D M8oHqbHzcIPDjsgf0vopfz1PlR5+0clVFd2KsKRHoDwNZW5kc3RyZWFtDWVuZG9iag0yNDYgMCBv YmoNNzAwIA1lbmRvYmoNMjQ3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvTmFtZSAvaW00NyAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE3MSANL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDI0NiAwIFIg Pj4gDXN0cmVhbQ0KBwVTA2foP2QgMLan42mBY1cj93qdrGRbrTJfyY/V0X9EEaTaS8vGqyXQy4x3 CUOs5QFt0inBbbTvrUj8LtITvysX7dhQqrhKpjrJOYZJnf5YTuIVRkIYxH8jH1DY7ctyBloNob6A 2nN0o3liivR9st+qw6J9xtyb0yoZXYp9EtE56GWaC4LlVYGOZzfdac001BY+GlIKxpG5ng7ci8Iw HNnTP7pUBojrjAxPWz3dS2tmsvgdED05g5iCG+kwcXdlPraTGOKm+G8U1FWKmsYvtumI8bqNIKTM 0F61tMkVjdTg1yAp19HZuqWqWVw1PcCVFXJA4PCOp27UN6ZUpEYD43s9qUFMwfDfKW2YxLM4HwUY xVumMqogruQPfcyD3C/2wGHqYPz8FQKFXO3PWmQK10VPLhiHcfmRbLzEwXglTdC09EkP7aXAzU8k 4qXbeL80USBDUYIhhKbInhj6rVxyqhGiagjAY7oPDd98unxAOnlpUG3HBg3VaindIPpfRL6lfZ1O sI7/WO3IQ7ZDczishdec3i/UY3nwMK+VuQ9tokEEQZiT3irgwFgNI8lUem4F3cCdkB0v1JSQXARW g6HPnDKzlAIhDfe28NHbgFgpk8Cm+r1VNT/9VCyOzB+Iy4fjaClu27Ax0mIxZ0YFFF3oq/RZ+fvl 2niozJnnl3ohRkkjc/27pl3coVs2o6kZL9ZCO/Rtaq6kHz1bozX/0F11Ot1LnaEmbrs+qlqzGSbY r5Yt23jYuxtIWoZ13CSRlJVHqPvdZt1iozvx1MXiPYULcKcWd+ecUSTbHvx/WYmDrq8h6rDTgRzY k0zJdckH9QGjDYWeHaJ1Wpkg1G5YjGVnFLVY6Vt6rGjW6Ff3q00uNDdYrrEa7JlUbRBrbFBBZubf 4f3TXGEHFBEe9Lgaq5rRl0cV5nsnv4VZq0ycUQ1lbmRzdHJlYW0NZW5kb2JqDTI0OCAwIG9iag02 NTYgDWVuZG9iag0yNDkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9O YW1lIC9pbTQ4IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTY5IA0vSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMjQ4IDAgUiA+PiAN c3RyZWFtDQq2kgGg2uodlFVan01OdtvQ9udyTEDHEyEJ5J6WBAUxrFFtX8aJdSRG/liNbXogbMEo Tgetxpvm2woFf0cWpQWfz/7IWbdn53q5MFm/yAM+93N/4it45dQ5suRUWySAirPvSTK7sNOapfqF GOF5hSdXK5Jw1mRVuP/SrBm3rJ9vvgzdp6m05ncGwbkuvGlKljQs9nLwbO0ViD8Tg295GA3kUMlC EF04KeRmpFAbrB4JVbzf/AOf2U/fCk47t5jXOEoaQuAewAfnwo+dEAwuz5crKtwh7q6pApEXldY7 9z/+WCdHqpghAnwzsRaqVafyv4t1GF3LxyL7SGEU2tO9cW1sSTmuFHhd7J4HTg5oWs1T5nKH5c5T PGiIDvS04J4nnBaTRcI9/UUI54gDWeTAJjNebcJMCGi/HC4dQcGHWc6MIDGc4CHNK/pIvRQ0j5KH VOMSoZzgFCpUz826k4r10pxg53lS1BMrioF8wSGe+MFIO1fqX+J31FUnwq0qXx5wTIgnanr+c/Xk VKe0lflMooAgRvAxBvrr8Kr5wvlJ/BWl6a4rPQySEicmCNjAOl/moxC8Hc9IuPdJ6gDE/LL/pNfl RdCQHUI6G1JgnxsTVaT8gks7qpJ2WBiRVQ4EtlntF34d9aYfEeD4S9lUN2fh4qRNsQ00mggzYu03 clS+rfWM5gsg2YraVmo3sxHozd/I9qbj324iLcn0aci9+KBLz9LbLxgipsYuJLmqOdGDE5AQNQRt huynmAFEewkS25f7OUk0qtRrXbgcNI1XrTsHG2QoK+QWCEUNuptoS32vssoG01fnj6mbvJfLqOWU puS4wu5xPfqcOiyDMr/8SHUDF0Fd1PsyCYt/+cFULlZ+a2V6og1lbmRzdHJlYW0NZW5kb2JqDTI1 MCAwIG9iag00MzkgDWVuZG9iag0yNTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9OYW1lIC9pbTQ5IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMjggDS9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNTAg MCBSID4+IA1zdHJlYW0NCmGH1zh7JS+WxMYsnFhvyHiT1iL0t3bMqv8CFGv56nEzsRQMIGdB/aI5 jYNnb7X8rgyL8svHe95pFDEB/4fnlTLUwO/8WI7oqahcLQ+ggx6Keu9QK8uFo1NwWIga1MM4fpg6 UfUlQNiNh8gh0ATxfbuJ6ay/KSP3gKp1JB5GUwSTXnCPo8KPGSVaF6lA7ySNF33Eu3DxYl/pG6xx WebBOVS3hsVDRhx2SZJw0EwBRcTcMxmLAt4YaFwCEVPCRJ8jML12JZFp0m1djR22HBs/8GGYkn8w 2MfnYfAr/Nl8nLk273C68muOtivripN+WZgt5Kz8jfuGkaqEZk2OZTx3VPHTv4dertpzeTchsjTX FqtSCPrf2RTfg+gjUYcLrWehPJvO4uQzqB/uJ5GHUXKzdsOGUtOgbv2iqIJCiDLuyzMjSlUrZ1N6 KCN87nc4Dcb/7G5tf2w2TcEcV5cVQc3aGt5r9ss07mXotHH7WxitZXHcTMw2tVJbpWQByx6cyVNZ 6bu8CdAycRLstufxt0MfwY4xbN+WBsBpIA4D6nA6jqR57OJN8AjUBHh8tLw5XEilMN/zmQ5+BOQN ZW5kc3RyZWFtDWVuZG9iag0yNTIgMCBvYmoNNjM4IA1lbmRvYmoNMjUzIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW01MCAvRmlsdGVyIC9EQ1REZWNvZGUg L1dpZHRoIDE2MyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rl dmljZVJHQiAvTGVuZ3RoIDI1MiAwIFIgPj4gDXN0cmVhbQ0KDDqSYASZaFs0ooWVRow6zO4QJuxC hcmD1ER2T3aNq9zMe3bTGw6U+79Bfl/8zZNtedmt/s0znU4V9UPy2GC1ssji6MReOL4PKa6Is3WS 3MDNKlW80zxoI/oiUDz89o/l+sWvLUKd0mqbjhqz77FoaZqWyDGb+QQjwi8f7HQJD5GzxHbWgMmN qFNGd3TFo3WY0fTDd93fnE3QKeR6Tt0xJe6hRIFoUOcAyhcC+59gKX6ZGJdshp7oCc17XfxLSfNq PJQwCYjBIq+1gl0ZJvtlEfRdlPvcg120934+DakkvHpFnbnH65w5w4o4KhYObBZvvH6I4ItIWIQH S6QBpOYVdb2FW3UwmlbnUj8Emnvkng09pE9NlPjcKIrx1SQWTWgo/Sw8a4rjCCVwew6hdoR94vHJ 0psoMNQWdBitHDmqPrAiLUxWiaVtDijPNVd772d2/igBeB+ApuSgc3DQYqn9EgMzuFIwat/NAVPD l4Jrw5/T5H6f6tvJvZZFyB43nKRtl8edvVPj6bl1YCpjQq/j0zhCKJAj9ZWoGNF6NPEEOoawFItA 6xsumWiO8EYcKxdCBYmZo06zhlnGTTbQN2/JVC/UQSmj4wcoxk4BPR+jMYFUCgGx+496gE+tJ9Jb D2PGeQN227stTrEtxFeO6fFVGi280gab8MNstDhALRwg+D1H2Lypiogf267eqNtOGZuQLXsSUQyA AfoV4DGBZdVYL6dWQVGqfMX/evNlNRsWtghwU+pDcJtDe/yPyeIcbjw2NNMkuJ9fJrSLwiUjWG17 7u3NdjsFvbvsXxVbJbhVvCxIVNf9lSflkuQvYXz8sm4n4leDOUwQRYU4V8jnPewNZW5kc3RyZWFt DWVuZG9iag0yNTQgMCBvYmoNNDU5IA1lbmRvYmoNMjU1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW01MSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDI3 IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9M ZW5ndGggMjU0IDAgUiA+PiANc3RyZWFtDQpjK6xmI0dMjjU9zURGq9iE8LOyi/DlFFzOktSPEJ27 L2GKQRhvho+cPG8RtIY3K5UETavJ+/71vgC4kBsXgnwc29W6dCbzFsn5J5HY3Gog3e8ShZWb7Bnb SW8gSOuW+g6FSLMZQ7JFdP6PVJAwSDE+0c4FpG6mCvms/nsN05i+gfCVZyor6ITPfL3t0iIxArUz YWX1Ks9pnJVpaHh19jJypE1VXvAYxZUSnFyLSoSWvhOaKoTGHWtrNcRR/OIzD1c7S8FumGSI1UAT kUIP+ukxRfU9PXgTqhN7U6mHLo0S8LH0iDV0dm4XeocJGwQm/h1FptewAODyXLY3nAKPOruo48K1 i6yXoKwhMsW5sjAH64Y7WJ6293fdo0d4y27gpNxoRmSyO5pzpYShnkzPGfDqIpo2wXqODAxkzwmt 4uOcnGbZr5XB+MQRsa8E2mD6d8i2ozPGDsUkKEuY2Mlhfab+qAVV1fYMZYLbkZ39gahbqA1Pn0gh TxgYiFo1e4lKTcSqZxrenKitGQQoAO61dBBMVen6ous/y/nEhpUCMROoUXuCDJ/tDW+fLNWE8Hg6 xevDpZXK7P4VIkj26DMuUFy20AVM4ENLc5zInnMNZW5kc3RyZWFtDWVuZG9iag0yNTYgMCBvYmoN NDI0IA1lbmRvYmoNMjU3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv TmFtZSAvaW01MiAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDI2IA0vSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMjU2IDAgUiA+PiAN c3RyZWFtDQrSCrIbaLpDEJxVcs+XpRNRzd5VK7aUDoVZK/KtLucef1TpY7Kt3cBnl5/L6ogQyrGn 1G1XRVqSzoiGESpPkuAvo9vPPC0GAa7KmAEQQbHhlEhZRSMtHWuDQpT+Fo6jH+afonJceXTw5EL6 oGOfZ9DyxE3zakOqJ0InZCMGe8eEWZVEMG6260IN5JOSYF4CCIMiZTE/UAdnnMPl/NMiBOqIxvl1 NBy6DqlqKlq+8csiK1Uv32jKupIeu/TtKRdiD50tU1UcyN+bNRCLYGurARn7m/9U7HBQdv1ClBBU sRMKkiluRgsoMB0OzUKHvyZvoT9M7mP4WBpOJi0ChKGzvgNOdQVrLGuYocizApWsRFykJP5ERNSg +NmHkdTYKpRv++m6OU9riySLKmNnCOW/ctb35q+mTk2jm3H0WBc4ynp8HRIkQniy556IIFN5iMEC ArlbOyAVDRUtjRa+8ppyafz+Medat+2tA7/OyV9mDQNpuzMFsgMSU1oowgXC3GTxPf4MRJAo9YzR W4W1kcK08fOUHdcTTPuH9y6MRHK+6SNKj4llRq8M0Zo3DWVuZHN0cmVhbQ1lbmRvYmoNMjU4IDAg b2JqDTU3MyANZW5kb2JqDTI1OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL05hbWUgL2ltNTMgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxNTAgDS9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNTggMCBS ID4+IA1zdHJlYW0NCsLEqJeAah5RTVHzFN4Gg56URq7qxuAaKp3b/Q/xof+pchQZhxHUGFFhcBTQ nMTXfODFOEBfWSRpCnOZdd89XIdMy3mbHuI72OlrI1MYNfde8F760E14h0Eo2RgGt+476HJrElyP wKsLSdjMpm1Ws8ZC/2tBHcW4aB+ryRLdcYEtTKw8BwAd79grdEyzirjbSmIajUsmuMmCCCFIFGwj v0CNcJtYnpR8uILC8smnYjk05NmJgpyUzmQNdgMqczygkDIAGzV8BKlWe+aKSMTNpsGb77qBqwdJ 4wvrv6LJ4UR1j986qG05+xzYYKLn9LXX8g/iGlyWxEiQwL33Au1E/gwxxiDEFGZYw3wOMDnp6Gv/ eaJFW+aEmO65PD6/oDXCr33x3m604hcgtTRq/GfN6Amrw+8FxmDw4cgboDPUMJM8Q8KFDGTZpAA4 1+OpnVhoR/eD/AUlla1VS4g3OlSlFQi3/wp2GX1ImC1cUqpSDoZ5RX/THbS7EmB5Vy/OffSwAYd4 P7J020ypQEzr4VYZPaft0zB34/YltFKzQ7WbESbSvKVNs3NI+pGzWtIlr7mPIEHPCgEcrgjuxbeF uNEwBc7GAQCzBWYHfOcwkRueYXctPwx9pJM+FqWlnwzwJDUYmcvLk2JfCOmEAmXjNfr4klZP0xBh UtU+dveg0WpQIPM+HhN/SQ9jhSHWEhLvGeMBRClFVGV3mUUx4mpAKu7pxGEs1yJAbzLoreETUCSl EG+xTG/SNGHbfDC18zj9SQ1lbmRzdHJlYW0NZW5kb2JqDTI2MCAwIG9iag02MDAgDWVuZG9iag0y NjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTU0IC9G aWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTQ3IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMjYwIDAgUiA+PiANc3RyZWFtDQpLLkYO bFquPEdnlfAJLgPNRIOsKETct6mo2DNH+E/4KVeAiteXQWmc8hibjmG9z27vkS2/Jmnty32YrKS9 HGfO0InWraxgltt0HgkxdDzP26W/hLPifY82YY1Qy5oUzj8sS3q6uh7ZCEsJmfnL75XJij6V0muA yzV3fRYYzP4cRV065eUqoMzQhzUn4A1vNnvbeTP+jRWJJxrwN3LpvwG22mHWMphQ3pFIIWS8ENOt w+OiE0+abT+4pSXpwB3ocQv/g+JqRHmmW1La9uYoRmWFMavm4bIy6ochLRXDFW06izovjWgeC/QY hxIDKPU8Mbxd7uzQ8s9jBO8oQYy2hySOYQoaeBI3fZy+B5l3woKdyAL+BIAR5XVa11Dyo0nhacqC MStDtsiLB2/4RUULOI/dsG6GZcyIdoml7wpPmM/u0yJoybtDQz8giHp+dG/XeRqLrxHc3wYS3RjQ KUUbTtOSoy4XOyg5lZqtJCLBU0myx4b4N/ke9QyDu6VglsRK3v4zi7TjMlZghohnoEI5suoP7xg0 bXQJdNKWjUHRaJsgeXcPd1LtzZrOsHa8tIZBgRT5OjfjMj7fPXnXbosEmWUDat0cqYcd8XekQbyB Ds/L3EadhsCVN232dF69+ugwmMpGsAbcx/thIkNzhh6CRaYSywHcB1sen1eBKAWlC1v7K27ogsuk tOvaWzXtELVYVl+p6IV0X1laGKbAqfkvCq0BYXaay95r0GyvBjCAgAysufqCOzFpbaDQoq+tA7Fj /sknZpisja1fn2qAmK0p5T3FI/c8AiTQBasNZW5kc3RyZWFtDWVuZG9iag0yNjIgMCBvYmoNNjEy IA1lbmRvYmoNMjYzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFt ZSAvaW01NSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE0NCANL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDI2MiAwIFIgPj4gDXN0 cmVhbQ0Kz6Ma/2kwHsu5WADO6Btd94hrYOB9Q5bjm5dj3vmElDdhb9a/vAcwlDzUcmnDlX8oGUFR IarleWlgp0yRYc5qyYB7ool1LEEjFzn4HubSmAyka/8zzQdALaGMxHYv23GM2aVFhCnyeG2ALyFM vC+LdipthPyvHD8ZtpmejtpYVynOSgSRxS604mRY2ZqwDykorUgnwN7vG4hcNZdbmgZ5pQ3WdOka wE4NWftJJUyPKoT8/uMDq7t8dzFvwbFc00evv6Ab65xFDKh50FIoF9c7Cl0S0bqxU5/1aubEtUv0 aooGASgcuCo2LZVChtUjsQ21MdM/WEMsRHEiReYcY2sbN0GGwqEbUpDrlggxCb0uRAaHqWxbfLkf N6R5mpzSoZVTthvspil4nNxrisuPzBKKgPiE3dU+NpBYq0XLf8LPQUQSh3ZjENxDqjGslNKHmiAK rGGv70Q8RODqnjDwRymAn20KlowEyoSoM7MW4NTeBwaYAdahPVLzHO7jaaYLWlXKHSBXdgtIqSf+ NEHxoXdsQxPOqeA1AwCbLRM3Qkj9qkh2gMOdRZffA4s6p6z0kORv/pty97vpCJNuNB3Mux12Sm3I GrUoRU4KKDafr1KGw+TqrSPHTnrUUfxLTYJiDT+qpjV2LuXWcyPuw439NkEN+sdhxyhBhg9SoAu3 +HIc/u7yNBoB7hiNOH7ixCiQuLNV/mBXCF+uIfUuFbOqHV83HGQq+9AEv/m1lTQRO1d6r0DRlS3A fmO97JgyXq1duylWJkBrv4Rkj086ZzN/5qqacjaDtfL3yPt2qqrUzqw/nmjPdmDzDWVuZHN0cmVh bQ1lbmRvYmoNMjY0IDAgb2JqDTYxMSANZW5kb2JqDTI2NSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNTYgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAx NDEgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0Ig L0xlbmd0aCAyNjQgMCBSID4+IA1zdHJlYW0NCke8U+BM8pVLn1u+2XyoFDUGTC5OjqXDiNspawxh ZccCq2Xgg9Ltr3/j+pP2+Glo4wKiUofGqTwcIJzm/X6A310IOEt/NtGVDVwhmiIabqwLrqNySJja W/ggeaLQ52vP3wzRu07wQQGJFLZvrWxyIJnsJrxb5vTdycOSp+I+nHSveY6DDHpX3RHtoHnCWRXg t5okjL1EGxS8vrrE2PVNAWL+dwTrMUEvzTsjuUEk+XsdYhLYO3SOsC5HDFXMAUpSW2cn+QHtTBK2 9sWpXdEOUd8xhUkIXYMg4CdtB1LxNrvDr+UM3ZBWVzjvwXhZvRrH0DG7u3kGPISl9cjbJi8+Auqx 2ZOBR6r1W3yZRBw3Pl/u5e1zX5c41SVc4Q4iVO76uBmb/FYzYWxGix//L8UgOc+a5Tl9/nndiPsX DX8RAYhEsLNxSuzimxUSuvoIXpp8GsVYb+0L2NkfQqM31Eq/7UGG3Va9Es1V6NEv+h0vux3qj9By grC7QLaq3errOcwJnmqxp2F/xH6tVkYtMwTHcgouSyetZOqcP3w60weAhZXBJIAUaJIiZ+eQi7Jm wYCGeO93viYssdgsuFo6ZdDn/cRJwziubyA/15R5BVFdTPE1pdrKnkp5uiv/uI3AEaSWe3KzCeQU 4k2BWFwe+dYAruBDB/6O74HJS2f5dbz8nxeOlxKUtQcHJyTEW6bUYUuXrubq2iU0XGVLFUODDfT1 T/tR6G7rmjPCVCrIE36BbEEm1ozDnEuedYOmnSEre+KX0z6FnqCFs7Vs49D20khxWErw1Phaas0o 0JQH6O5gbCptPdnlDWVuZHN0cmVhbQ1lbmRvYmoNMjY2IDAgb2JqDTU4NyANZW5kb2JqDTI2NyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNTcgL0ZpbHRl ciAvRENURGVjb2RlIC9XaWR0aCAxMzggDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9D b2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNjYgMCBSID4+IA1zdHJlYW0NCp+GkUWIY22a 8YjUNmm1pC7avRugtPSjHKOKsDYeqYSMpZtIi9iqBHDygBuBrP38sM6V8D99UM/O8PFw5OIvQX/g hx0YwV4JP2sJLLWnZD9CllGKKosuHJX/Azn1z7pT6jPjbQDAuU0tIwATe7OGA4fHYTqNu45VZThr c7o+8uRkPDzBd1tFOez3xelx8qmWO5+jeMN3Ia8fORO0rcrIcmDKMbum7/TObVxdolVb/de/IpIc 6GWEoj4LlsG/YYNZSA6NHfLJSy1V6dk5PmDV/KJY0OwJWVbOE++mi8zn0I0BfU3dquiBbqd2mSds PT4Fmw3K/x9CGzjyVF2xOVVzrFibmINU7t5lA+YldhqY2HGoZaN3vPauRCGW5tV/ceP4VTxEOkR+ n3XH5bHa0K3hVB18yJf0wm58dc67bDeduzzq0gZMaAGzASIEDSIoVjPeFa1DUXovuoe1BQXD1N7j X8dGORfQ+43RtP9lFlZjDJX+w8t5ICPz8Zn6V7zBOAuIga+Hjwh/41s15NlnErf5fihDQdBbMVT9 WjNL9bEwgIQ+48jPPq112yBVP8fKEC/Xf7ZI7BkRT3caGvcCFZydN7sLj3xQBej4P5sYx6j0JLet c5SYI6fScwd9JQbKxKI3vvEzjPR8xyMHcqtcWws3DI2LX9NGHTm7eaSVg4Rczsw18o1hW5h8j4PR FtXArnz8+YvBBjDtO2uhEp2/NxapqFg4EwOMAYTaJEtTF7IH2peT4E+ah1RN9X5XxSw+ASFitjLk dzQpDg8ZGVWiDWVuZHN0cmVhbQ1lbmRvYmoNMjY4IDAgb2JqDTYxNyANZW5kb2JqDTI2OSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNTggL0ZpbHRlciAv RENURGVjb2RlIC9XaWR0aCAxMzQgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xv clNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNjggMCBSID4+IA1zdHJlYW0NCnd2DzTrjFdJKNYv htH/pcA9Hpu831pJxfTjm2q6mEQOueCFs9xATJZMeuQmC3cgJJaawwulNtjsCufX5ZghCQtOfe83 on8ZYdj9cpFoN7m7qP2axXfHWm2gn8hD52o0JBLujVKJfX+YUEnYXtMQKrcBUjvHfRYSFZQlWlh2 8OR/RwsFAmjw7ULUq4ELbtve/MKibcmU0MbOBbqoRl5Ntqn2LLATCdfYQaYfdRN7gNXE6ajq1q5c UbJWS+azFNSdLXoyEu2IsmxmGhJ+wATsCyf5zm65GrPyxQ6jSv2m4c/heAfQpDsUcIH8lOI/6n1F ICC6MWJdkdz1IvLz6QbNMIHknFX5053wzUsyWWEXVo8ckyQXooNsJbVDKwXZ2j5XkTNF1cBsox7t UXADStTKopiMACfLp4+1gFgZihlZgtcTNarDcr3WJKyqHeK3WMeQSiSvH7VJ/Wu9oOYLHCIhPQO6 0JgYJFInJC8fXtczEUp4+NSBaK+ol817ID24Xizv9YhQnLMyiK+rZ6LuXN0NUH171kSOPrOfMsti D4YXlMRpr1vWYdmLp7Lk49C6Av13/Rd/Gy67CtvSg0xa5nRk/47sAKaZbqyv+q9iJ/T+6eQpq48g HYz0PDPli6PQrI0JXb8kfbWA2fiYLAcMU2IrtF2NgVh529b3LqyFrhyoh2D4kKToxiuyl5urbYxD +NcGFBnSGWTnimb+PfWv3sLkxhtK4RkkkoA6G3pDe6vsvkcBS5AXeUZEe4kILuTbS9aEyz0EMRPB c+C7chdWPggNLsx2rhr72dKAQN/BN50nNjKOy2wWWg+wqGD2DWVuZHN0cmVhbQ1lbmRvYmoNMjcw IDAgb2JqDTU5MyANZW5kb2JqDTI3MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltNTkgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMzAgDS9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNzAg MCBSID4+IA1zdHJlYW0NCrFOjGm6MaYlSxx1vzyxBbqU9Q1XxMZNAVPrJAn9pirL7Qei4Iv1GAAD jFGOsYGcNBiXRSWYF1zejg3EfvuDIm5SKTYyZXrBy/9wDo3YkinbLs9JB39zYO2Qh14IqgFbUXCz JXP0kf0rx7YDb77ossQA2quO22JNyzIEhOKXkMyuI/0CoG9+xReNYOTBk0lPNsS8+8Cy+erdMLzW ldoT53qj7TAgO/VT7ZBHK7mCczOg8y2Xzd9E8zNGRtuIG191v33IHTbyacwsn1RreU9j07W7Y9Zu k5ijP7jMLlqBioPBee+vjUhwyNF6RoTBTHgVBII5Gft2UBYWFRyOCP5sYLjENYiBedUAPj/u7wX1 LA4DqSMYk34ygu4ePxCcC7o2dZpwQGV2geSrmSYMpJSJZDNLuJEuQVH0eHO/+tTgXmnGwP7iAIL+ eCpziUDGdJMNdixJIamu1BiJVU1ybRIPJmopwca0C9PaRdFKwpQflvLZRmS7lEuFKWAVkn1Qe5Fb SWPOqUIUhgJv6NTAQZLMVfKLjCkHQ13FoqfZ4g+bVnLxc9N2Cbwtmog0o/WUkPUHTYhgsf6I8BxZ efamJn7VsNoU7U3euX3S9vpKNOSUC6/IQL/YsC+C/iVF0+7p4aPZWzlYJm++KdvrSoKGElkRrftD unJM0obDmfDm5enbsShiGnkGWYpKB1akfu16i82eS6wZ/S1VTvJiALElixc7Yc3CyCS2uFO1MQ8S to15ooOpr/9Kyq30Y97tCauMXwcJIiMH3QOFSF123ffmN5vXZVtCDWVuZHN0cmVhbQ1lbmRvYmoN MjcyIDAgb2JqDTU4NSANZW5kb2JqDTI3MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL05hbWUgL2ltNjAgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMjYgDS9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAy NzIgMCBSID4+IA1zdHJlYW0NChFMF1q8MDjR+Sns2Nmtz1IT0/88zWqUl7ULNwbnQy/2Rz8pWElH TUDxNPsE2FS8dDRhP4NVp4bHx5ICLIi617XrkMP7/iANNfFd8bHrTmM8uFijGLRoaGY/1b5orkzd 6BagvpyH5BrkwN1Azl/mlQU3UavvRRSm/C63wTcwSV19I3i/B1YZrSRDAgke3roQXMI1Ju24VsTN 5bmNtLW+pAQdZFwEnuGlAT3pDJrMSYyE2rjaqMEP9AEm8uM/jLeTupLDGxIhlX2JJRtGJSVmC1Xa shDTFYRHvThPDwm5iMNvdlev8VtIGYiCvo8oItftf4GTJFx7T24McK9rieNPxBnbU94KcptRcice ZweZCXd5AAC3PFFjB/j7wY92hH2f2aeA6mVcN+unaY3B4QhDWZDksinD5mny/ak2hTyOaakwHjap jLA0sqE31ZL7JqPHFhoyAaHtmrmQB8BXXWdqwstAwbGuhYlfUrNAdyEVv0uOhalv4Je2falqShde iGzr0kNF8bxt9ZSUYCtKpgkV5V8W6TuQ4OpCMZdDFDKJZTk7T/aKF7HYU2MN9ndyhV0dKCx4BuSM uzfWd18a43XFWFBon4005LysBYze/BJYSHuxibTSfM4XXmCYQpzFtaYb+15yG24AeEYqDp+lmngs Wxl4DTVRv3Lm4xaREy+dLORhZcgreEIxsq4e9inAIIQ+A+SGRJgIWM3vHa5Vin/yr7BZBpV0YVLL Vk7IPOACIic6HaUfnJtsZwEbzYIq0DO1vLryyYmOjAZnCw1lbmRzdHJlYW0NZW5kb2JqDTI3NCAw IG9iag02MTAgDWVuZG9iag0yNzUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9OYW1lIC9pbTYxIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTIyIA0vSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggMjc0IDAg UiA+PiANc3RyZWFtDQqCHzFkCrQDU8J7RgDvyt7uh4BscFY1edi/J6wfq+LW2nMRHftcWNjKJNIM j4OJvlMuL+nXBIQ4fFef5wn7+ol5kl8dRyUYE6ypdrkJAONiaZs+syXn74F6CnK3y5AFO4HSeEOv VVuxmQB1Fwb1dyCUPG3R5q7Me46kan9z5ZNr1uGfUuiI2jZLWNCkq1nFYOSfYb6tKp0wybHqJrSl GFaS3KNQkRJCcY8eYN24Pz+nTb4i2JVw/KZXDtE9F4snRk7ULnDZD2KXK7pEOIyIH8AX94oC2jR5 b/E2ZqjG9DiZO/pSCFTWz5VvDfLCEvKqL9hDd58aIrUHQ0bVzTCCQNSwob6RSBAat3f5ZFP+8aVt stZKs5AxwzTTV8sF7jty7UXYaoKo3BZqj9U1S8qvqEaH/y/gbQiMbo1+REsDL1cULEGbrf9bZfYv KMKdOJKDV670IVV7UMVMWujM3Fkq3n6yEsemrYMSFEnbt0Rl9C2zwO18RYAOGQ0PX3flabrCbwll 76PrRCJnN+8qfM37bLb+Do7FS7MtB3+D8DRNAcmodkWRj2Fkw49DB6+02wUx0xDzy8h3Rl4vICW8 BUVgKL7wCQXftMYWBIR4Ae4XM+VAPOnAP07it5WZypFgKv7C83HGFZ0E+k6yoYcXkwLjo9Ro0k/N 4LpFGpNBX5jrZwM3ckEnHz+teQygJPpDM33pIR6e6cSEMqbaAYSn39U6OEokONTuMSwgjwkSxusy tQf7JQTu7tA9bY317BzO1QFMkkfbtQbCz2h7H4RVtwVq/wvXmsdQJcBnLBuYcPlc7lWuQEadDWVu ZHN0cmVhbQ1lbmRvYmoNMjc2IDAgb2JqDTU3NiANZW5kb2JqDTI3NyAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNjIgL0ZpbHRlciAvRENURGVjb2RlIC9X aWR0aCAxMTggDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZp Y2VSR0IgL0xlbmd0aCAyNzYgMCBSID4+IA1zdHJlYW0NCiJb6/KoFwuYLlrIq5YFWI3Yf0+7+i9U 2x1g6XTEq4F08KzWTDdb2YIItV0TdVo7UsOA1a4h7ZI8P6F8/Uh5fzOkaAEpfhJ0t/ZxlrNFstrf dJBr3d7zAFLbFbkkYEtckpwcnq/8EXZc70+nLoYeKV9sfw2fl6feVmzYnF/N48A7gY8LUL+kfUr+ DM06TtfTI9YKCk7xDgbhCvzwIUr23h+rucvtMmW7UmP6QNuxvt3xMZAW+0RW7v5C2j23JNNgAnnP XuH7HnDdm6b9BDrB4D0Moor2OR3byexPcDf9mbvDpBhpHH6f3vtL+g3655QSv5d1f/nOFOzgsM0K 4HKJPnLoKTotSK6I5whRj8/3SEyq9NmAUjKYLWbUIksaDBrru0Y0Y75U4abiOZA+6WRLQh6jTo1a QTIQupe/PY+safdqwArtspkFmBqDTnmdnuxpMAeM1fjf+Mf8BOZN0VHox3t2WBj0HSlaZ9vOc+kE J3XRdL9WWGRqH1zgWRUBwKXsYbNvdmBtt7nvO1MxPXKiapqGTeT3FtpOA7GmofEnGDse0qtMZIPD WzqalYJWbVoca9GHpXE9dWsXtoLH6INOPJG0EFAWFcuDbnaHAEUszI6wy3zdROEMcTOFUb/N3DoD UFh1HndH10dUH2lU4iOsUqtJm/2Eq/pLnKh9XOpNPtQtO4lDMDL0oQkr2y8J3Kz2N15Mp6NeUflQ mBGFROXdxYfAbVHLaNugCfbqLLn3+cRjysaq6W3SvkIzdyeYl2g3nA1lbmRzdHJlYW0NZW5kb2Jq DTI3OCAwIG9iag01NTUgDWVuZG9iag0yNzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9OYW1lIC9pbTYzIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTE2IA0vSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGgg Mjc4IDAgUiA+PiANc3RyZWFtDQq51uK9tBR1Fme7ZWOuuW3mi71MY+f2im5ckibJlzHmaS/IFRUw HJHPiqwp+F0cF8JF8CUdEK7N5lV/ybLHduv6ZuERVA5jy4uofP7fwvOfCLRRJgkfclUYJrwKBum0 Fwr4KCC1/BRXP657IEykl0W4MZm0k2s+nUxbzfDlBjrWvx7PhcwzQivN8H1M5fhM+Y99e5mIqDRf p5rtbv1fFAyAJTnwkIzRPlVLN490vx50hEP+WKsiSQUZCG/OfV4OPZaA3uuqOq+jZ3YnwugFhdFr 36r7NjQEasviW0z+6a1PRWKshXKkL81yqfw5REM2yNcQ8LccItyohehJ9zrKLNwvzjAT5HZNg9MP q51Jh6vT7CY1CU+oIDamJzeVp5EVQth63SkD3h7kpRMo+6FzgohyiOnipWWByOhy2xGWkNYcvAbR 0DduJ9bFSafHZEkDY/Appirby74VEouNm0odczPvGan4Il7FJdyVgxuz/Xk8POAJ5AkSoKHsvs67 7KDRUGhNsjF8RQ9iNNg0bm7zir79KDqyClxzh1HzTru67it2RuDwt7mMolmekNztp58H5vAsZoz2 PHlkjlrxfPUwPxVYslScpwpvTtTU3oRZ6AJGQaQ6SNSEmmAartdV6Vy8Dg26kfdy7bwVqkvNH9il HuoSW5wqjNMoRGM27ORPldLzn9jJl3MmD9FJ5GthB2IKkHIgN6YW1V8MwLoFt9xdi+y7dbISRA/o NmLpbVsNZW5kc3RyZWFtDWVuZG9iag0yODAgMCBvYmoNNTg5IA1lbmRvYmoNMjgxIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW02NCAvRmlsdGVyIC9EQ1RE ZWNvZGUgL1dpZHRoIDExMiANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3Bh Y2UgL0RldmljZVJHQiAvTGVuZ3RoIDI4MCAwIFIgPj4gDXN0cmVhbQ0KzBJbxkEyC6cQogko6w3e yUeiIw0H2yQuvpZf58NAnwwRXHsQvfVkjTM1brcX3NgdeDNYo7AMl9A5epX9CFFZib11VC3LSv9J 96msV4n13rLtf2Ft3a5bVVDoArG32HVQYIqrPdc/CvJBf8kwvOL5oG7nh6xzVcwkjXQW6F65CctC m9G67bwweM1B/S6G5h8AHGG9IjN6QEATzSQaePm9mUPZ3lof0EwtbuF+8FxuqWF+9HUjOpFYpqR4 k5hazPzGBvLUx1Gj67z9QrHYnZuOSj4N6/pqJsRYf8oG+jmSyBXmFEUQ12EANKSMwqFtRq6JGbLZ mwN56itmVU48I1KvmorVZgRrBm1XSGdC+zyh6RaykIqenpu/wkCtVkzHt8u/7pHa2Jjsuin1H5ua usvyz663GC/ILwzhPrnkUHTX6wGeLtFy0IcLGDLpo4IY9bVRG+XvMPhMcHndPKDan3sbiz72WsEo hFsjfwK+DX/7bUH8Xz24FaRHJF5SMBm0Ta8Ah53KR8FpgZ0Uvx4j2UuHM0XYURqpZhMZi5fwYt0L gXhS8o71Wxj04+EMPX2TZs9FaMC1+hJPo3lqzYaCl6iykiLD4TZMlygy/ilEpN26XtKvoInKcFDY sW/OHiP0EIQS+bpB5epcXdoskwIlgX4lNnOrjgUEplNV4vJa1ywB3/8NFYOf8BVU/hZmbZT5OUTg mXiXXpIbN+VG4MjgMZtiVom/0mb8oX+JGL9PeOR6cO+adzynNM3UGTaNXFD/MwB076gG2M13FgL2 ewZ62A1lbmRzdHJlYW0NZW5kb2JqDTI4MiAwIG9iag01NjIgDWVuZG9iag0yODMgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTY1IC9GaWx0ZXIgL0RDVERl Y29kZSAvV2lkdGggMTA2IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFj ZSAvRGV2aWNlUkdCIC9MZW5ndGggMjgyIDAgUiA+PiANc3RyZWFtDQrocWiiCXwplA/NAKTYg2Jw s97xhvBBsBK/LRzCZv5GjtiGzUo4WcLsftda9M0nu0pk4BnWkZ2UoMAkqMmZupHRFl4zsTrfF0wh ikIPsSxP/2ROWl/qDFzZYtDkJ7qia3mjNq79Zga5TfbexLqKV9YWezDll6TjQvxjDJEpDTmbDK2K 89u2od6s56bN2ghkdAaUWTsvbe37ZlX5VNEb/lttBieK2TW68OME28PmryflgfCqB6BGoIZwUsvn 7k+Vbtx+BMamMVskK9BZ76tcOXNJj/nwaVOJRCKkRQU7n76yy8aLVYpzG6ScXmXJsHMD8ocBjZ3Z Duufxi7eXU2u+XnLWKRoJnM+5WbJptg9hzOxkEX4f9hgM6Z5Ifp8tL+TJ3HR5dC3UPr7Fndnpq1I 7Na4JmsDr06T0D3QhPZIbW2LDqhKkdPEEyZNzmJHmZ2UDG1k7vvG/T9thSPlKcy14Aj6zjczQqrM AO4hzPMIv+Qq6ZNgaPO62NWgCxr1vDfA6ATdaFhAPHGmfenHFk0iHtutcSaKqhAZQ7LG7mVa6X3r ir+Hm7Dx6dEGBIXBnMWbhdxglet74ozOeELm6nb7u92eIsUHqqAWeKVYQed6XofsjCYgqcR3k4BK NQYMHOFO5KryHmmxyg9C5V60u5BZGrc4CScuPWnL271yDWXmhqAh1WcLJNHdZksyy18r/PjOvnkG uH2NOQF8RMY2ZIxuGvksdHlM0QiPsC3Byzx7PBWLZU1/DWVuZHN0cmVhbQ1lbmRvYmoNMjg0IDAg b2JqDTU3NSANZW5kb2JqDTI4NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL05hbWUgL2ltNjYgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMDIgDS9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyODQgMCBS ID4+IA1zdHJlYW0NClfPAwL1ceeJBO47Y5zNxf5HkyJ4h3RHMYVuIab7afs3rdwqBYN/7+osX6T0 3K2A1whIfx+2sy2tZq+SMZ9gr2jQv2xJeduBmhMu4vq7kgA4pGmzvPAYAlMGf0HYU3zqEchCV+Lb PUwVOOM0beYxzZq0ddoLkyVOxxFufcpncdd6muDgh7si3W+nSKU9WUkrtbUjKuHEbCNir+iPztab oNpS76blHtnSeSDkYl+rEXibvNvebPhzAFpvAYlG0WqRjggnpNd8SBpt8md0Jv0xhzjY0+zd3N5z e86VHnzM4rN9Y0McrbP8skbjub9/Elz6ZHuGXji66hOpm7vBqhWxsCad0hTgLuad4x2TGurnW0VZ cgYKHJMaDKc+Z20RBoGWj/rY2ClyE+zWUcqGDPNz2PPMDQ3k9ioR5Y0DcGSkPBCbDAiXjCbWUGid biMN0rR2bJ+ucli+qDYnlIJJxL43J4p3Wpz+XnLuJze7FMGCDykps/hEO2fEg6eg3t9npqvzAnGc N0b42fWhuSPNDFLNXYIozv13oKl2y+2Hm1ICwKH0jY2eYKvvHVyXMM6Diye5zAt3O4sTFKul2kY0 hkYmmGynwnqGQunQ1wJwcsk85AsE9fwxWIuFuXx7gyhmvX8CxU2enjVdkMLaX8RIBoqtsX4oBgVC 4ePx20PM1O+d2M0BFz8fvz18MmfRI5HJxC5YENJTAOoHGE4bdj1w3Teq4dMWaCTs/hbG3h82lXWp 95/ek0LnQyh5pn2Uu2O6hXkIDWVuZHN0cmVhbQ1lbmRvYmoNMjg2IDAgb2JqDTQ4OSANZW5kb2Jq DTI4NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNjcg L0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCA5NSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDI4NiAwIFIgPj4gDXN0cmVhbQ0KlM4b uEuzZcwsvBe2gd1//FGut3I5cakExnPogsP3cQa05haOJwspVjUvZuYIqxqolyTKKB740txVcRUN KLYraERQlwZVW6YKN3GytbkXb/W8a/8g9OxNJg3BiD0MUjIlqw7/BhgEKf+dW32HP0glsZAAlRwp a0/l6CU0FkAc3OriL0LqP1G3voR0Gg7jMpdWkmHNwNsmVDi1IXBVpzTBaG783ZlSye8yBdObQVjR 06jWQxdpnxgeWrkEWZR8RlPSwCUVU8V0+rhlMeJVjjDuSvC2FzZkW9VEs5t/wJI1mIdoUdgXOtSs C5lpOCLr3bwejsfetX67SF9ib7770+fGJHGSEjC1yXPX20o4QRnXTkUUwyKGepVcm/0PQ7+xF2jL g44zNlyyGhfvv4PeYGgpmLpoTLoMgVGVGR+KSMZUOVRUYPf2XyU5R5oWWTmDI3VbUQlGP4CsGHvI BqGo2mxwI8AiAUYYMA6FLxJoPlXMsPItO6F5u41UuWu//BmtFppqET9NzvbCRYZs8vyB+5qTNlMg 6rTKcvKw++cfx+RY8Allp/YGIQhgEXsXolmgmcmmYQHeoII0wkzW/TVeOPhEkBk0Zs76QQktZ6gI thLHgBzUt2euafuD5N7+TKve6XUqjk4dcVf3YuVDDWVuZHN0cmVhbQ1lbmRvYmoNMjg4IDAgb2Jq DTQ2NiANZW5kb2JqDTI4OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L05hbWUgL2ltNjggL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCA4OCANL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDI4OCAwIFIgPj4g DXN0cmVhbQ0KOZyNuSXX8TgJFpIICx4iEnR0Gt4gYwQRXtoylBlwWIb6qncUdZLljexPybQIQ49S PBb8/LLh3aEbbhqi+QB+MU3+5SBbabaFy8VqhV2d8rbPbsMDsQfMQwyFgJf0TzY8+mtnABZ4KIgJ E1vGlblOiUKfTZzgyc1mj5aHtkGN9iRl+ytN5Wrnmp1WGbHzSw5KmJbAOSKKea2o2s99C6J6j0wH nDmCCoVqKlSkAjCutQmyFCQPlbnLdEk3Z6XFpZWeyt2BhArnoFVUAnHLVn3RLJ1EBcQt7Xk1k+GR 4GVQG5tdvXkwXIK4fpZmmLucHUTpinDwhE+ZiIBJ1QZ0jltMQhqsn/QvD6CXD9HOwIiz69Dt9BGz sRcgLOPgb3P+KGRsieVKR54lAPe2DnK5JAullfnHe69uE9lwdS7wRt3yAKnz9fjpAOlQgnoa+kxq hNCAWTMszZzZrsewp681AwRF23qmUZFl93tl41Z8lKoJqyAc51NJ5R/6zNRpvAb9aZBmqEOj6iwJ LZGWk8xYlbOG/XPVCek4zm3F2BjQbvtautRBIvrf/LZHSyRhWUBVwjVtZi72kZZfg1ppzHJ5EWtm fb4/HMtpsE1IFEnlZTnk2zINCg1lbmRzdHJlYW0NZW5kb2JqDTI5MCAwIG9iag00NTAgDWVuZG9i ag0yOTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTY5 IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggODEgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCAyOTAgMCBSID4+IA1zdHJlYW0NCqzT 2v4sWtXgpSXPa2nhCM4ribkLMTxQBG24Opii7C9p/exSzCYNHWvKGjyDRvkidBo/CFYt5TfDOMpL wSFqkkM/SnSz/Fw88qulmcPSdM4FG/ZvhMvYgsK7fWV1lAknqmBqE5TBGmI3iUX270w1nGPTv9Bc yXlsmDYSfhOA6/vPQu47HKs0ReHubXxBlRXaVp4XS6IOLOd02aT/DsG7fgzTWUrl42pgfgR+AMn4 w+7FhPz4l0VAxNaYukT8Ifj08YPEf6I34iO1vo6imJ2yBD5/kqcIBWGhnEcmXVG/rLOSvPG5r1iO xVz/mRmnA2v0tFZIHLHALeMHB97sFdBfo14iohPwL8udXtZIvCET6jvfDtvg9SjmyLN8k3NZ46Vt fhB2R6OJ25KoQrx0TeX9gmrXYOrF7fUEclujhvI8baFssuoGi2aXYsvNwgifFaC6eFFJsquGhRaI ZKiu/KPXgsUOTr89chxkMcIoVCVQW3ZwRYsg8eHfzBKYkbMZss79NIpItA9XUJSdwtsbWWRGhh5M mkswfomuwll3aZKwjPOoipJn5y0N3Ct3vDWIL29Uo5HVC2Uhe6s2aDlEjD2uybnVKA1lbmRzdHJl YW0NZW5kb2JqDTI5MiAwIG9iag00MTAgDWVuZG9iag0yOTMgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTcwIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGgg NzIgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0Ig L0xlbmd0aCAyOTIgMCBSID4+IA1zdHJlYW0NCp5z58pV501lgKXpOxBvkexfQCJzF6cf60w7hK/v ScMLkScmuDP6IFV9Ms8wYgo7XcOmZGRmLwJzuf/+upBWmyiFpfmhAE6jR55vu+k9rpZ0c46bhRy5 8EXbTExbWoDEUmB08yp1nCxDiQQkqL8YTqO/GqgCHu0TKqVrVp7AFlx/2XNNaGTFqXXSoRjUupkv pNGQCcqONwDPCK/fjimU09fXSgpHhxPcI0rE+YpPBpg0BACko13E6eLsmyiaoXRj4c9tN7Pr1lSH +1KbyAS7dY1UzZ6qFY9vq/HEUVu8P4UCvZOtV79lRIk+GZMM0xvwL1ijXmtAhzeeXm5vyKfY2aPT 85e7D24JJ+j8ga1O7M7+J6ZAtKHSVPBF6nv0H08GSW9nsPUQ760/iaLL5EjW47elB1VYOVJl9tzY ruJkSvf7ukQrRgEq1l1cd55OK5lElUU5pyTyGpX6oyT6SVsGqESVYByBDqmRK1C7az5it6SLdg0E ZXb2/bMDMJGF6EVSvUCToFyYhMvgmeloRCMuPIfMqQGMzgKFNIw0DWVuZHN0cmVhbQ1lbmRvYmoN Mjk0IDAgb2JqDTQzMCANZW5kb2JqDTI5NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL05hbWUgL2ltNzEgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCA2MiANL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDI5 NCAwIFIgPj4gDXN0cmVhbQ0KMw8jsQXfcev+J2Wf/ZBDmgAKA7UwJ7cIcMU8Z8vfs9CcT1qfQFUp O4ylHczdMxugs6TpTGx7Ab0FemaBq4dM7HM/uXRsMKbE+jMCfVRjbAjuR/YNiabr0lZ9rxayHODB HA8vSh/sTqrOUgHd6mO7pRBq3QRU9TLoDSDe04gBetUEGsB09rOW3BKL4vkiskXZKSH6EFUEEq+h nDvHXwv0obU0PKt+q4iX5hhAKFPYmg6o5dK5P1CEjmMNbrKT77/K+BQp4oRDNZT9CK8xf5ix+G4f nUU0yntUWfdyAUG6Lp00EWz/vj77Cxfyv8OfqAtndxrFrnrX0N80xYFKnykfT/JOBGf3p3s4EUJg Y6BxSHAnmgOItXow4WiC43M/chZeZkeEblWexbKTvai1kE18kHPeZMi4kF4d+LN8Ao3qUbMaV8S7 NaOcEwRaCXgxhR/DPMPEfYXjb+Mf7qRTr3FQYP5+IW6aKmRBc7i5cKNsSjEU8u0EABHj06OvDsBH iHvRzAjRbJIHDDJIsMpud5UKEqn06fKTilgeN6+PO0Ys1yihnEBizfMpcvdhXVXkAQ1lbmRzdHJl YW0NZW5kb2JqDTI5NiAwIG9iag00MjcgDWVuZG9iag0yOTcgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTcyIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGgg NTAgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0Ig L0xlbmd0aCAyOTYgMCBSID4+IA1zdHJlYW0NCp3dTjTSE4vq0M8GzjrcaZt7c0BiRFriIu6a1sBI +nk7vslfsh7YF4VIK2xW6g9DoXZ3O1uZXiUgpiODe/F3QHrMbQWtFK11gkqvGBkxU09AUvyzEPzH owfPOdCoVOb5SgB7WolYpdvd0QsMW7BHsl4AOABuRWVipRsxwc4lOKu6wB+N3PDIIYZJCdPt8rgb J97Dl7OQBCEJ2iwLI7jYrhJ0kFlb/yaQiC2ssILcO7yADK3Gu2oaPKWZJ7o3ESikkXBD7c5kW6S6 dzsBzfq/ViXE7SSrILLkbts34+qSA2hQgvLORXztdxQBb+tHHnAp2/k1l19s1GyNheOV4kLKuFUv Sljn3yBIo33WchA+VMXhD79UR8r5gs0Cx0XPhtC/yyBhVify3oUi5hKkAzQyOfRwJ3mj5v2wKYNj qUKENyoNVnY7orZdrbGFa+Y9MSHKsg/ZhA4DM8WS2S1OZbrQ5tmp6AicHZO5GRl+Parl0xgbSiVx LWZIDNOTxl/URRsPboJeDWuaUrgg8t5Fmqv0XDtPl1+ZqhKkvYTsb307YMdvVgVRuwL/ce6sEJUN ZW5kc3RyZWFtDWVuZG9iag0yOTggMCBvYmoNMzc1IA1lbmRvYmoNMjk5IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW03MyAvRmlsdGVyIC9EQ1REZWNvZGUg L1dpZHRoIDM0IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2 aWNlUkdCIC9MZW5ndGggMjk4IDAgUiA+PiANc3RyZWFtDQodGnyVyaA8ueSsBrofi432EWOMaP8b zWcS59fjlOM56YcSwC8zOcmtstZJJXD5mIsdk2+3DvqmlPJk9W7WBscP/5vkj7sAnPL5VEDtTkZL DzPG/+/eQUicIr+fjTTzO2ZPIS0g5Iyl8SOtc0EpZ8MlrV6kqplI8UeI778Kd6e2JyEaqR6ugRas N/oSfvCNCel+hEnwWmVVvqv8O67gU+UJPYfT8ALsCdl5DD+I1mHedhNUD0fLP9Z4ObT/JqmCMqKw tVpSfQkBRScxK+VAdHUo20H5mJIjrGUpxcIax8tr3JuqDGYCl8vGQ3ovOsOdfCHWGmVlOUW4ducg FTjCsZAkFGp1A45WLcanvv/Y448E5AJNRiz68RsgCuwt0HSZ8PJB8UK5OIcm1ePI9L3JAj/FaSSk m8CuuFXL7jM6mIGBQ4bBcySdYEW/I5DuJvDD06DqfikR6oQEWZWmMTTAfYvaQ+MLd0dKfNX/tCTD 5IrldnZXmoHtttoNZW5kc3RyZWFtDWVuZG9iag0zMDAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v UGFyZW50IDQ0MCAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDQ0OSAwIFIgL0YxIDQ1 MyAwIFIgL0YzIDQzMCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltNzQgNDI2IDAgUiA+PiANL1Byb2NT ZXQgNDU4IDAgUiA+PiANL0NvbnRlbnRzIDMwMSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQy IF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTMwMSAw IG9iag1bIA0zMDMgMCBSIDQzNCAwIFIgNDM2IDAgUiAzMDUgMCBSIA1dDWVuZG9iag0zMDIgMCBv YmoNMzUyIA1lbmRvYmoNMzAzIDAgb2JqDTw8IC9MZW5ndGggMzAyIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQrV1hUR1H4rkBi4v5SLZcDDLiZ6t9oLnH+/P3Ae1jnBR+sieqZu 8J+V6RCfn1DtuP9SsS0UlI8YdFmDidBHIdAUFsx53VOzd09mQv/PDxfPxeaBA2MBdSEEUP02Tkr5 MkeYXdBYSxq7uwuR+MWqLwCZzbGyYijqX534qtc7ayMDskuLfJSzIJ+/gSS7MIIkVXgFpfRBgLp9 EASZqW084cvi3WROI0VCC8XeQGxuJAP8WSH4im0/VbW5sobnh5SKx/176seN62PPloam3yU0tCXB FqfzCzm9E+4NrjDNBpc+Mi3/J4YqJg+nLAbpcTucBXwKDg2ZbFWxufcDXwaaRBqJY0OYw6FgUP1V k4O6gba01Ujlj1OSw9gdfy02LcM4XNhQwEbA6XK1hDli+QKaF4gW7vKFjmGAuf3wTZFlHg/LTawf RymywbU0mEIcWL/MJDSGBD0qDBuJaTuBbnlHMs5rDWVuZHN0cmVhbQ1lbmRvYmoNMzA0IDAgb2Jq DTEyOTAgDWVuZG9iag0zMDUgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAz MDQgMCBSID4+IA1zdHJlYW0NCk8W3KzOtGSVdHkDccOCnlkbwKiujPAO4kAD1p9F53qzYnZFVqXT v23I4GQznt1hU2XXLp/SlTLEhEPSMg6dB8ebGvXjg5PuXExPEY6dw8ypVrf0nTxqMhXH13ZfhVXK BPTHvJFVjGnjC4bCbBeLwj7h53ev+mLdETldGttMrxH2YG/wfYFG49Iq0gexYVG3Nn0pvj/RZSCC 0VDwLkScaCdRWZHM//5qpsC+nRvrIW0frWdFclfXvQxXznO6Q6DAUMSfe7MjrTupZcfjijdH8d4P XuRmMqJ8P/UuiSTGwn5ME7nIHnT0B0oblu4O9uytIcxqKM53XyV0bXuScWDfNj/yi8uNnf6iZLKb Adi6Lr02R0sqokA12y/jhQ0CYwFA1pi/Spj90C6NwFdjes+bxZX3m2kGOpm91lnZOQd8MSEVsBkh XAKjhsR83gIYUzfHaYSHBU1SANBSIpfVvueZaCCFunt7vtqN1RJpu/aymjiSfB83jmnCIzz8x5Y6 +lGp6IYLiJadbuMQJUwqqyih5cERc5ovjr958Cs7KfQs3S2JFsfKlgk8vadgPb52du5MMN6MQ/8X ldBQsNHGjSD+lymMWtEjjBGydGuCPqSozV6rNZfZL+ypIlOmgZWBn1fFXGT3OLvUTV8xcEMU2u2V FKuK5BrvIxf/sWmp0tB+2vhEMRQKPkeD9Pfgb4VlZMrvpznMbAl/oY9pOo9JJrHh0RQebe+wKJ8A iontx1zBm3OkNJZC1plPKi7YzE1fm5Y03/iz/JVv80TGkoal3MAEMiN2E2XpX2YEBNQQ+CfaUjqj YOxmkw4kQlmV21Hk7vlvODI4TaTiU2+aBAsPzvCnwew1OgeLtjrY0+xQj58YCrqaBPujmJWapv9B D94DsJerBuuhNOZXRTs2EGzjsM8sqisogcxBozuzJX82BhkUDfnizcUkntEGmYZQvagoJ0GllFMs ZVeNo+ASK0KTJ3SoZ8hmwHqsZ2JZxud8NGZDTygvSY+jZKERGRNk4J+x5j5N/O/rBCLEw7bWtJ0g IZ8rnWgLVGa7/Bk6Dbux9eG3F82BQbyL80VmgLvu/i1gmn2PhXvNLSR/Frq0YaNhE7uDiHuf2/5C WH7VJfeMbiEtkK440t+iye46sWCqfXd24eZsMN3kDCSnWFHRqgbAI1PgeoJunHRD3Qv1IppjaiEX 7zFp+clng7h54Aan6MQf8LYpGLgHeywxTCUpHfrTUSDuLjf3RS4ZEyii07bcx+G3EtoG7TjFbmAz AAkZ3wX5EBoRzgeZyYDVkU+KRniBegOk/322NBZBqaPRrelFEpQk7fmuO8UDjWgQ40sB85rENyMS Fcx+pTt/26loMdSQFsFOpwar6G1//9+n7BZKbkiB4KGFskj3siVheiz7W81f8q0ucOCk0gnnS7tE ISfeq+plGreZntMUHqhXBMMJHy6xwazUgTGK8YFGkrjz7OcRUcMDLwsd+kamT3bWqWDPeU0PtFX8 zzxSsZoKWbajx+z5g1vB92MjTbdZijsNhCA4tB8mnNIy5iGjdCFdT6B03vz9ybEkCxavdV97KYHm DrWxMWinlAMgCMxAZ164AkQ8nf0iZcU7e9XILHEeXYAhY2YVvYwXiVswkdenOkcDZt6eefRc2fo4 s7nvyqiYzp6EvxELxPT2/dDBBJ1MveRGy93GTSiBaPX+7/ZXN/KkANU2QjinJiVwoADvC+/HQQ1l bmRzdHJlYW0NZW5kb2JqDTMwNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDQwIDAg UiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiAvRjMgNDMw IDAgUiA+PiAvWE9iamVjdCA8PCAvaW03NSA0MjYgMCBSID4+IA0vUHJvY1NldCA0NTggMCBSID4+ IA0vQ29udGVudHMgMzA3IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3gg WyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzA3IDAgb2JqDVsgDTMwOSAw IFIgNDM0IDAgUiAzMTEgMCBSIA1dDWVuZG9iag0zMDggMCBvYmoNMzUyIA1lbmRvYmoNMzA5IDAg b2JqDTw8IC9MZW5ndGggMzA4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQox Bkhv3P1QsXakcmPLE1NHL43B3XQbcW+HgY/9Bgq+ToAE6MaIQk832tUApgEkP1+V905E4CT5ledQ 1Z8RaezH0b6qyii5HgNUrPHYes8B9lKev/Q6azTODzkQeoqhmS8O6SQs+DLcAVqHiHmUHeLIdqZ3 cF6Dp39IrbbE9Qz+HiZllQy/n/cGLrcnZwyhJkIKvSfmnJzhNHAnEwt/6A/PL1AuymkBcLqubXSU raL5jCVoQ8dcnuSLeFAcgkkhQ+8M5F5cX6zK288oIlV3FkGSqcFz0ddYvcDtJlN1L517JQQ+CxEE qgiORP/WYrcE/VD7lcT0XPLZjTSztqUrJohrQ3xi2Lr1Oq9MhLaZRQZZzv4aM8RzyNsThOvV0t69 PxDNecGEMz6ECNAIJpSALkkrLmMHcBtq9nYaRDUWBmlv/eImUpf96Pl0mQjrL00iLiimVKCxMmX/ pZG1+rtPuSY0DWVuZHN0cmVhbQ1lbmRvYmoNMzEwIDAgb2JqDTc0MiANZW5kb2JqDTMxMSAwIG9i ag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMxMCAwIFIgPj4gDXN0cmVhbQ0KUpVy /3vsHeRMqgoGzAgGaA90sxiqb5B9WCdNXsMf+h02sSE2RWc47kogKhtgWAdMjBBt/cmN5233CLwF tlVseeuJG28YoeDduqv9PFj6zKkRBlMOTf0qeuzCNAAND65rr4YggstnHrt2Nx+ALk41WpRkF+tj JwMVOnqJMioWTq5TbVDiiaaU8hYnxi0hJbivk1aZbPSumFNniHje/SWG9WgiGVxqTcZQQ6LiZcRo pz2FFkqw7BHtSEAFr+tWmlRH94uskztLLoN9Mi6HeZXJj6yfWjNyOc7Hfmenrzxuevpb7t6GLNLO 04YgzkFZBdjwnSfGxtIawnxDUl4xwjoomzkfRTS51wvwOMHlw1ophGSXbNiEwgCgBSQlI4/QhDxq JVRfDrYhNpE8AREZxcQRWI4Cmw+jiCWd2N1T1IspL3v+ohzByKNb8kyoIdG7U5iY3jx7yEv7f+NP asgjLOQLc016zT238vBCBRfsfLUzjj0ZjspGEP1QRXv9SKceRXNaZHXBHYLep8YfJggA06ZMGmww OujJ4J4FMnKzRQeV8KQS2h5NEeEvC/fmBQzl0jtfuD2Ru3FGM9/mcjOAK/4ygmOf5ewhYoVxzJT8 AVCZhF3zkt+KwuWmpXnh20CMhyJKtrYCaPkV2u1Hv0oWxh9T/ii091cgTVOhqlE7i25qXFgbX6Sd NR00JMEOJJyouBZ9LK5N+IZWLIgpdYYwQLcB/2Gt6/DWbwzg4dYvD7HYZW0BEaqDeEHMznAfHxtR u3+CcY1aJbqNd7PCohsRXt/6Gsl9vKwaUMMsB8JMztSPFi7P3nzQ2H9FQ2UnbeRISsBBz+tp9d+G /dNE35tRqmPtjvmRo8sjYQHua+ejxN8Xk9BaaOjvapf73J2aJBpcrJp+L7PDR5wxEeEz0mko7J2J WLsDxnDErmyZCugjemGwfNWi8wH4y7J/fRqoWPFZJHDphsSLRfMQquONGJDmvyco2817oN126g1l bmRzdHJlYW0NZW5kb2JqDTMxMiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDQwIDAg UiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiAvRjMgNDMw IDAgUiA+PiAvWE9iamVjdCA8PCAvaW03NiA0MjYgMCBSID4+IA0vUHJvY1NldCA0NTggMCBSID4+ IA0vQ29udGVudHMgMzEzIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3gg WyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzEzIDAgb2JqDVsgDTMxNSAw IFIgNDM0IDAgUiAzMTcgMCBSIA1dDWVuZG9iag0zMTQgMCBvYmoNMzUyIA1lbmRvYmoNMzE1IDAg b2JqDTw8IC9MZW5ndGggMzE0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQql cgzkwjQeFH2pVIkzeZgK0Qbdauae5f61OLzV6CVqGrwt3Ppk/H6NcfYJDMDiU1xaEVOoQ+GLRxmg pwHy/pcDrnGykRsRHTFxpA6wGLKfgQFASQ+KAwGio0VqwbeHOWpOFE9X+wiLF8NpPWTnY3P3IK2X BXg1UrfcHTZnPWzIQ15J+4xq/o256aTyZJ74LmOUndH08B38wBqX/6Apdje5Ybs6boFu5hX2kxOY AK9Lrb1kwoNLXwhSBIW5av/QTA1mqHVbdLGHigabgE47bnrt33RIo4TqFEjWPgzxwbz6HWWyVUS5 X86gogQsgLKGgn7Vr3GRvYLgumnfC3kecajYh/ru+a+H13Baw0bP0ARTLivmM3d8rZSEi/MF+a7h uRTpV/SfOjVhRYIEcpnSvWySg2lF5t94z3eIprB9jJac4l33MH/TtdLk1Ktb6cZd8oPyesIDgugX G/VwNdzZzTyYDWVuZHN0cmVhbQ1lbmRvYmoNMzE2IDAgb2JqDTYyMiANZW5kb2JqDTMxNyAwIG9i ag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMxNiAwIFIgPj4gDXN0cmVhbQ0KLGQz 7GG0YKECOitxZ71MvXmTePltfBaA6IFQ+UWmWXWS5vhm9nryBxtG0/4ttPbyYAbWOilGhT4ThGQR vhSWzsDsvrNbVno1M/v5cXg4nW093u1pmGiJmKXkwDjBq065lk5biLIK9NBrgSJNgknNR7aX6p2L TFZGygeaLinehx6j2lvRjF/BJ4Px0ffGhhQKbURS9ZxOhh4U+z51RNT3y3+rBoOBhvepBVpnXIPV WiTvDt/pvZxIcrSkc8LWuR4HWH6zBMIr14ByZS4Xpe6bLZ+hIGAH8C+w/huM7Mp+aNpZhRrSdsZL EFvgE23axl+P2Aku9vZrw7f+axGOVJrmSFHB0VDl/c4gWwBYDj46mJirDFluwStbDSvgZKr0p31M 2ip2+KwdtoSvIbqZ3wALmDYmi5F7QpOe98rC0FFeZS7rbky1xZH3TNYTYTvOmfoYTu06DNJgtOae 8Ii6+9uCc0fkBFJjNsYZ9D+eAiZtee+14YP8U4PH7jJCXODbLNGm4jP9qQ/knx4lNnjP0hGZ9cEx iyqqyaQObjnOQf5ucQE0HN+zOYI4isHe8fxgOGR8+2rT3AAj1UA+rhMYUjOSYNDqrgJHZkghwydP MWdzO070a7HYgpVyoda03PuaJPkAqn3Ez/kddr1EyXn+aAo4Bh/JMq8+PUze1NleFITWOAkdoM7X 3sJ5eqZh8CJkODDB/kIkhaWkP8CvQ9OQ+uVkvkVJpBjAven4VnbcDCHKxMdKCk0w0YeyHUhEZeHI LufOT0xXZCE6yj6B9uvRrYMilZfpvmU9nlau6DT2nMR7HqRrgqFg0VzX7+51swW9PQ1lbmRzdHJl YW0NZW5kb2JqDTMxOCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDQwIDAgUiANL1Jl c291cmNlcyA8PCAvRm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiAvRjMgNDMwIDAgUiA+ PiAvWE9iamVjdCA8PCAvaW03NyA0MjYgMCBSID4+IA0vUHJvY1NldCA0NTggMCBSID4+IA0vQ29u dGVudHMgMzE5IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAg NTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzE5IDAgb2JqDVsgDTMyMSAwIFIgNDM0 IDAgUiAzMjMgMCBSIA1dDWVuZG9iag0zMjAgMCBvYmoNMzQ5IA1lbmRvYmoNMzIxIDAgb2JqDTw8 IC9MZW5ndGggMzIwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqo8yUG3tLp y1Toqbm+YRsi34AYVgGg3R+l04LgAKVmWGnaAYVcxKGqp1jRXhvwDPGhVt+d33scnARtWfE9aiPa lHpV3+HK5LuEwQnUaTGWq1AOZs3W2VrJ8k2cC3iNwFYefm7YNS1q+U0/1su47H0gZSMHAmMEMVGf +MbrJozZebSwRqSNwatHOGpfHyMcqN8QVWMrmVJdf3f7Nih046glGZsZesGsP3GHU1H/F+b6cIY5 5XlDxlbevKrIJP1sdzAio0OXjm9r15Mq6TSmz4Ty91fioMrlveS6BoTs1Fw14d7kJB78hvbYsOrn fhtaaTy0pNCT2A/3r6OrP1MoHPzdHJdmtNjCuxlWM2UDo4ymLAPUBNwwdoWrwKDUfJfr/AXN+bbC v0b5CetvE0MNR7r7ofAmfcRmie3xjfUQLFBPZOgeTpWlKpU135oAPEtlWUd+VULqYJ/HcuMkCnuL DWVuZHN0cmVhbQ1lbmRvYmoNMzIyIDAgb2JqDTExMDMgDWVuZG9iag0zMjMgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMjIgMCBSID4+IA1zdHJlYW0NCmV0EBq8X4D1Xd9x sIYRM9Bp33qJ16d2CR7gBTE1ZS73DvxVKCKnKHDoqTBuu6MbOo7rDrs3VYYdWY/+kxuTuejGzTBz 14Y0E0zaOLqYyUGIhAV1zkLU+7sJhPapNiuIQzHq5q6b9npGnMP8C/ebnHTPDFCFf+aqSNkadgWl 8xejeaVQx4jlN612/v/XKKRXfutzTQCocfGI75plZI4aSPZpqd4Xg+34rE81zQQIYKoOrvHNfFJg Io0rFruWPwx/EvJ5mVIon3z54sevhxziG5zLrF84SekkrG+DwhSYmAVLlEMqTvTSEHuA3ZARG2L2 3Bogw40yUmpJ53CgUSu3CQZRmthw9UjsO6lUDrDiY3NKv7GHbJ4aGWkAnqxzB7CAkQim+HOY/wRF s9I9Cj8UPicV9jpLDLyK19dz50Nk0EFjNBWvjbnWYUDygsnEtf9GV4FFjPWpPPdSLFIG9vZgYA1d OAbmlffa2Ik4GROCQjGHjze70ISjaEEuqBh/m/gF3BmGI2Oy+vfsaMghhv+CyZjZ7cZgb3BV4qxm V/6LmjwcHSwkN4K8LlixkP5W/OEQt0HWZR0SuvHtbNgwkmgQIkvop6a9pB3GdwIuWXN9lL5yIoGC xcXowJcxhFQgPFIfLxPfDp0f8W3GvFJgEjH2df3aulJ3PI2YsFlGOBU6oPAFc4ZNUOEdHaEJsgzV 1f5r6epb9onCynXNiPw79gqdQ8JvoT2igytAPgAEIBWIGUYY2ZrKOxYbB3Vf/DM+t/jLBUEO+06g a8Rd/rYMdOsUUryalAQlJAFP1cnnaNN5DeXQA3KHLLz+oYFl/yN0N8PBhyxqy85uqKoaI6dmMd5X T2IY7XiuaRErBdlam0dEKxjSaxgxlrNAvc2LItTYKefRQQpCF77il4gNCaY8ik3lnevyzea1G34+ 5My8kW54VQ7NA/33TVoXFG83QWWDhNDCL8D8/51ll7ssZwwU+dtw0/GY8DjK1qZE9PMlLaFXXUg6 QjsBNTDtyqKqRXmSukZbnBQ2pu9LWaEJ/jykRk6FqhpQfG6cN2cY2ew0CyRw5uNQ+i6R0eicUGlo qITqAPQEHUlo7tgE6e8t6v1ykQliBrJ6WnSBwyYL5tOCO6UsktKh0XLD2uUd4LdStMmLHwp+55nA KdA4HbvwIyAjjAyfVMr8UTju/DD4GRRI1Esukdn8fGlkRNyHaPuR925WrPbtBtHpyGVPUzmfVpUn W6u0eIh2IGY/7wndUGnGws7B5CEzEzPHf3FykSP3m5ga8/XyclADCgcH7WNQkshB6O4/a3Buax6e 9q1B29GV/MTGiJnv0jMsqo+P8z3wa6x0tmlIRPK4vbJ8rfTGuJjBM+37zip27TkjpJNdxxi4LiuF zHRDwGeu+J8UZXHWCmsy/K+yBCujON21gDtPY42ljFoTLyIjbqRcLm9QTG6ZFp2Qy8UEqEymCQZJ fNO/gNjT+7/jDWVuZHN0cmVhbQ1lbmRvYmoNMzI0IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh cmVudCA0NDAgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA0NDkgMCBSIC9GMSA0NTMg MCBSIC9GMyA0MzAgMCBSIC9GNCA0MzIgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTc4IDQyNiAwIFIg Pj4gDS9Qcm9jU2V0IDQ1OCAwIFIgPj4gDS9Db250ZW50cyAzMjUgMCBSIA0vTWVkaWFCb3ggWyAw IDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVu ZG9iag0zMjUgMCBvYmoNWyANMzI3IDAgUiA0MzQgMCBSIDMyOSAwIFIgDV0NZW5kb2JqDTMyNiAw IG9iag0zNDkgDWVuZG9iag0zMjcgMCBvYmoNPDwgL0xlbmd0aCAzMjYgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCi3o7NEfSim1KMrq0sgvw0GzKTYYbxhGu+xiBOPZQDlyrb98 UqDoBFpIS4dmqaKPgvDayFXTHLt8mluuD7x7BJCXDcG8aAoAeloWpbEvKqLR7iNP/U53m1oRm/FI ukMbSHd4AO2CmkxTSooEav1l/PkZ7dBp+Ke5Jn2AYnsh+KMwxTpoMCQz0O4qiPLpyjgWehfEhjVM hevaoHaWAAozfYDq5DFjL6SEsw0azClvRlJryPMpFEc3WF/JiCZceypnUDWtmGMrWqq3T1I6BeHz RYIiJ8PHJCNYmNG6e9qJPtMC3nai/ZZv/LkNW037z1ekXdHdDWR7KrExOM1Ao8k6YN3t5o7APKGL k/CA9r5S6miDbe3SWhb5pkz+A9FAfBKGoT3WSoRMJqZfjiqmZG1j5DGDNDkTnk2w+luPIobwQa2m hAlA5uanUkFXDBsJCRyC0XaA7sxdrEy/UnG7ueQNZW5kc3RyZWFtDWVuZG9iag0zMjggMCBvYmoN ODAwIA1lbmRvYmoNMzI5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzI4 IDAgUiA+PiANc3RyZWFtDQr1F5ihUzvXgP8Hplfnn/B20jy3IMnljiiQR8sBJegwuEJPZUEiK9pe HZO186zCaLGHmTIN/7PK87F2LuSNTgSAI3mtTi0xvC+JTN2KfxgR3NhTWiLqig1D9P9MZdho+ADj nLgW+sxAZOrYWpzc8k3Zb5HPtDFG20me2/TDjNMnVEqhk6ogwNpzQZAMiKfMBxNtTVtq73F46nUc bLT9ft2t/qkjHUvmGtbLtf3SPgNueIYil7FU1K4QlNP2zwUaId5Qa7Ij7AzoHA5Lzm8uTITNmsE0 fEL3URXCpOHgo/ndwNmmz1K6sZs3HYcC6Hpk092AcmH5kkGV3eazBF7hX0VtYRPktws8EEuTf8lN UJmRLYNPghbQANagNLO35Q5DQrxdpq+4qVQehosPSomjBOz3iXWODSDwqEINHjAKWkzoQkgc3kgB vXpvg4fSIWBOWz2UdpJ8A+FJ2tdXpLJ4VAvMx4mHbs7PrhCVyT+CHi/BVrNK6xyv4a+bmxDa01Cv WtmHhKU0oPZ4mh6da4k5fD+fUoh0cBUG2g8/amLv983MQGjzr+nZIyOUeAwFuKOCZ9tiZivpA4om k5Stju8Sl22x5543cMJbjO7BY5R4kFEgygfZCNCWWSGNDuKfCMqnsEzN4OQfKULws2j3dFxBdqSc mvCryjwjh2oamZmBJ0sobYdX7P9pOybGiy/SSqlMNKjTawZp3DyIjJm5G5Fm3qe6ZYKgkMsSwpQJ ocrCkKPb0Bd4qjh9NblSzjuQAGBblzP1uylzsmpnsfRvVSBLfPLQvuGl9aAThg4k+a93JDUkB8lz x2vzQELEnmvE+PTyuAvPRbYpyq9QOWPYL5NrRVySH5DAwG7rgH+5d/UcDVZ9t+zSs45VfGvfH9HJ kU1/bC+NNbTcmijbyde/V/QaezrP8/iaCkoNQrkEukyGzoFlGbtrFolpvCVBTom0JL789oVhST+3 B3qClymZWBXBLY2CHuaImBameby+6VifxNGWHXpVtniosrNafdLhQKU5GxG1kbs0ITF+RUIGrkK3 zgvLGt/BZ+dAL7X8HxVg51MrUA1lbmRzdHJlYW0NZW5kb2JqDTMzMCAwIG9iag08PCANL1R5cGUg L1BhZ2UgDS9QYXJlbnQgNDQwIDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgNDQ5IDAg UiAvRjEgNDUzIDAgUiAvRjMgNDMwIDAgUiA+PiAvWE9iamVjdCA8PCAvaW03OSA0MjYgMCBSID4+ IA0vUHJvY1NldCA0NTggMCBSID4+IA0vQ29udGVudHMgMzMxIDAgUiANL01lZGlhQm94IFsgMCAw IDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv YmoNMzMxIDAgb2JqDVsgDTMzMyAwIFIgNDM0IDAgUiAzMzUgMCBSIA1dDWVuZG9iag0zMzIgMCBv YmoNMzUwIA1lbmRvYmoNMzMzIDAgb2JqDTw8IC9MZW5ndGggMzMyIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQp5tKSNvX0MfzcC9PR6yqcwJGv71LByq2Su2e77Xsc6TftWwKwL wZaW4ZPeJYkp6hd0JGXn81xH5473X5lRz+hyZ0D1EwrznYa/B5EEYpME1jItvMya6iHuUnUb96Ry 6Q0mVyhQm3+9ryaiw/bcKJRb+nk6dKFh9zvTn9ZLsjQfgxuInsYPZxc9W6d6TzqZrHytrVGbQHaH y5p2YlF82OlaFiT45CFG2WbKqOR/30rWi+PkF2HAImUFmNVTb8pqr8r0j57n5P87jcqZ8y7MqTxq E8pSFusqL+u+jRMwVygMSz5+T26cyTxJQHjOpiF0Qm1MG9tx6kbjvLeTVXa3ABxzJoO0oPWtDPMl h+rJ9JwYPUABWmqQ7WAsN9AicekgI2cOGlTWiT+a8R+OM934QS0KCtLY7gP5prj01rh30/82bG7y vcbGBW5+oV6ZwAUux4l/bDMEdORASbBXt0RSqg1lbmRzdHJlYW0NZW5kb2JqDTMzNCAwIG9iag05 MzcgDWVuZG9iag0zMzUgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMzQg MCBSID4+IA1zdHJlYW0NCiiU5CRdTXpmSIJ3VHX+VxR+8RXWs4afTt3BQv4UMqWI3w694Nvsb1Yg yQgHi75xJmp4z434ekJYjT65bGZBfv8jdNHxhXkt+3P+0mDVy5WGG/JcxYwULky4DmRA3pzAJPbg JZ0vPwmixnY16WJigIOfdUhT1dfSR9Yb7N87Lr2UpZGXhpeGpoRlZbMAN4PBo/iPW8hn2/Wkvtyb NyydsL+jwmiIlcx7ve59t6h/leuqBFAG9HNaJEkHrTmBt7oa84RfNEH74bSfatM89ZZqEWsE+BRU +QLEh5erAG9Su4Xko94fD2ALvyHNmPnBJ/mrh0AKgcCg3PB0pSzwFRJ0zn427rwsifd8MQp0h4YD HN4YcBIcTKyhsQhWEwurpUeJ+6K2DTRtW24nQja4TzfQqdFhEOdFKmQRW3GwCORknSwEOpxyDmz+ 4eolHRfUOSKjewUQaOBJcszloeSS7f6sOp46ULh0I+GtcNCwjxcXf1QQlNdWSHEI5bBkmu16nX1q kX0amVIOFZDciAb7XP8pEfn69W0W21yWeAAm9eFbn3eP1RI2L+zZl3iK43utGhNKnzY8vR0lzj5d 5CalkYZtmBTmdRGYIWgi8AvbxpTnyceXwySnHDZ4+ZBxPUf46bjsl8l8+qNqsEVH8F7FI+kZXxHL aZ0kh3/1wnf74jMIghrr9DPSK+aJBVhg0U3wru9bszpJBMKGnG384ZGFZ7PL5Qlo9Mb9TqCwFt/D /W4uK6UaE/Gf1LsfdC43shtvRdBHdctlhxcEzfGpEbZZ1i6+bk7bTBsFHMu3vB5DuYestvRQ+fU+ cq+R9E4mrnAA670JUZj7HfNgM56Hefp330iISgWREqZFWPdPxlJYTdAnKALyCMCOiCnsgkghDX1F RMw4qLM3qMU1hI8Zlc1A7g8WILcrvF+lRD43BTxtiIWCZFF8B7jvq3LvMN5Ay0gXH4SiWuIwinrU +zTzi3OSP3mBWYLeG8JkXVYq7Tg/zwKeWTrpA/KrzQxJE/7GB1cyJ9bAHwnscdByi9bvJ3wX6Dj6 d9If4lK01sFglNcw4+SRyfDxd5XJiM06XFuUM2uWMcRBaXO+tM1RJw5s9w3yUkknHmLy3ZsJfkWQ aQoMob33+ZNN/y/Q2qQRm9NC7ZCJFIOyECQugcON9GCnlSAtKuTRXXAhnSppvn5BZlSwugCxI1zy 80wMyAO06r/JoCMAm33rslIcFCwsQkAlFPgUHeSciOBA1fRlquWl2aoNZW5kc3RyZWFtDWVuZG9i ag0zMzYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ0MSAwIFIgDS9SZXNvdXJjZXMg PDwgL0ZvbnQgPDwgL0YwIDQ0OSAwIFIgL0YxIDQ1MyAwIFIgL0YzIDQzMCAwIFIgPj4gL1hPYmpl Y3QgPDwgL2ltODAgNDI2IDAgUiA+PiANL1Byb2NTZXQgNDU4IDAgUiA+PiANL0NvbnRlbnRzIDMz NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIg XSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTMzNyAwIG9iag1bIA0zMzkgMCBSIDQzNCAwIFIgMzQx IDAgUiANXQ1lbmRvYmoNMzM4IDAgb2JqDTM0OSANZW5kb2JqDTMzOSAwIG9iag08PCAvTGVuZ3Ro IDMzOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KOXsUIHheL+e+RM2cdeBI FQAnOUItE17PK9pZPRWBs8OtNPVcS/uWc35CwnYN/nqTxnPTuOzSPRy+e/HT0YIlr4qUEsNfECzO f3zvvH8j8zD4M1Rb3PIfhKFzWzPKerC1lNK+ykVyaFiKfhteL6iWdb9svpTD2AexNdRNfQGeylx9 p1HdwENBRmS+NVSbWc5pRFPTYJzsvaRyZRDTPWJpIZw2zm8iTz3PdGKHCkocj1+7XLo9nWQg4MBN t5YaDMn0pDd0wQoRUEBWYhyW/AzAyW1Q8FVJVAMSZUONzKoi6yWolO3bYp+XLqL+altQ6hCHq4sd ApDZ2A9JnF+V7oW1dwJrWaCMBHlMIeMX0lZmnuDMGgxH4cwj7DtYSzCZGKj8byudG8bP0qzNM8+k Ahn3o1q6/5PMeAUXVXUyCE1YEUSMYLH36TDgxzkJhuYY9Mc9cZx142T0ZzXqhI9qGQ1lbmRzdHJl YW0NZW5kb2JqDTM0MCAwIG9iag0xMDEwIA1lbmRvYmoNMzQxIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMzQwIDAgUiA+PiANc3RyZWFtDQoJ9d3hJNbObwx5TomHN1/mHlM1 WeVepcnLMHNQA3WqJ+K0NmLxTc5CGiOYsvz96+X0L1P8CgazyEEHUaI6rauL72YPTRSUiEm7nvMO QgCzzH0vxlzlWh1M2EtFEgs5LWvj7Cshk0N0IfOTl18n962T5j+A0NDGldVF6OP5JSjm2pVmUyaD ByZiNvGMgfbhcqG9AzycVElzYzO1PFX0kRZkCGWRPNZDwkg79u27SjaS+ri0P4giMvDp5T+1KEJG H1eIEdOFjMR0jf5R/JxjSQ5WrlKkRM+WDNdN2yy7RW3QYel6iFexaF6BUrtQJ2QmCjp9FsPwHEeW 6xVUO/zhD8YjmhUCcLjxAzExrBvDNipqVR6AHDzjWOUTdl4dvAhCywaeiSoEd/kA4qIof8CgtFj0 +rNWm7+UDvyb+YN48iz3orRkvPX8znhsR/zNFcSzNVxJBbrFaoUD03/WC5h+XEAbNtKWMYivokM5 UGCU4zmwYAMwJrEURh55tACi0F2aj/MvVMdNwcVI0z4aA1ug54vpl2vX7g/kkVFsaJteY34UYHtT KoFT7g8DZCWBugJUaS6uM5tU82YtSRCibCHh0NMtH0tDpb286JmSdjx0ZaDb1MFyHs+BPueDJ0Yy gFvHqHnE4ckTdg+loQz15U84jIj/uGfoI1yS6Dy4QdqO+ixxnCEeRlFlox7pptG8EofBNilqKzIF ifKZoQNDPGwkz1vxCsnvWGevSE2NCKSxGjfbACJRWffuIrzunPfDkebBj2Gt787rEEmuZx659GDQ NOzEav+YNJeBzuiiI/fQ7dHno2ugy0pvtdURV8elyRx7UHWfLVZ3tojJOxsPT785sxM6UfzMBUku CgaX4pgjlmRRjYO297gBZTbuXCYyY4Z/TVwuc4lmf1Saxrss1jNlgWLV+lGXCZzfgOoLyrevnlk6 aLZ9kKSmhNsUJvfsN16ox0KbNsj4VaXufN68JiFZ3vWngxdU++crxdJ558JHERbArWVR8B9Mxhg6 U/XFbktLca0EX5CC0Ap1UWHV2InS+H8SrkLGkXobYKCleeXlmjY6A3TFGroV/Sl7er0sKJoLeQkF WPEZKQ8BzVeQxPc/Yibwy8P3Gr+v8wXSd3e4NNOYkh64zX0MjPB6OAPbquXWI0TTr4cIAzupYS2Q l145XG5yIM8Rb2SBqfbymDsScva4iT5H/2xMD4DHIbthaEANWjzEfUSBHZ2lUnOVfOOOcViC3UH3 EOqsg8dcKMyNfpAtF0bAPaS27rSlHCRrgE3SykVQpYuzYlYLYl84Kv2t+oC5Jw2IyrOTkPCqGrLX e5B3KZcF1JwGKBtH447w3xZaEuoI/g1lbmRzdHJlYW0NZW5kb2JqDTM0MiAwIG9iag08PCANL1R5 cGUgL1BhZ2UgDS9QYXJlbnQgNDQxIDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgNDQ5 IDAgUiAvRjMgNDMwIDAgUiA+PiAvWE9iamVjdCA8PCAvaW04MSA0MjYgMCBSID4+IA0vUHJvY1Nl dCA0NTggMCBSID4+IA0vQ29udGVudHMgMzQzIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIg XSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzQzIDAg b2JqDVsgDTM0NSAwIFIgNDM0IDAgUiAzNDcgMCBSIA1dDWVuZG9iag0zNDQgMCBvYmoNMzQ5IA1l bmRvYmoNMzQ1IDAgb2JqDTw8IC9MZW5ndGggMzQ0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQov7vBbmorvroxhvqpHkJtJlHcPV7fex0GIKa/YqsANK9ari3SymNkm0tuvMebI 7CxY3mO7Z7cevTbjZ0sa9e0CURm9uj8vSEbiWkt9vQT/dbZO5AOVkQ50X6YmmZC/IEzq6tjBi/Wn 4wlI7oWFt/vka1vr4oSg6qbygHAJSkUYY8k6UgN9cY5ippCta9xcq+yjbcP3/l+ZWz7HNI6B+v8l VaSKahex29IuQeuqW4YDszw7baFYOzH3Wpko6SIFG9K0qC2BDScKeywtVZr/E+hQrhJXTKpPqnfR 0EdOteir7ojHtioumr2vp3kHQ0e9nY/irV2mmJt8hjdhwmmOJXsfceX57jZ8+KG5nB7H84YpB9DG bR+Lc+MFx6xFtJRCfnZJiNvtaX7t/3Q1Lcaav28RbzhBE9R3S7nvM/A8Oikt6PeSaNQ1RWIDdiBw 7PUvY+rXoZjSSxOlursnTpp1DWVuZHN0cmVhbQ1lbmRvYmoNMzQ2IDAgb2JqDTQ1MSANZW5kb2Jq DTM0NyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM0NiAwIFIgPj4gDXN0 cmVhbQ0Kppdv6hWQlsWYLQtl/xinOTPXxp4lI1B45YBNqAAmCQrlIvKZ9SHobv9agWzHlAp5LOrc mj3Zr+n0Z/E1umP83yyygr5Hg0fXA0C9A9FRcNoZSavGL+HpLuj4fmIH6V7DJJkjS0X+QBbi8KCH HrVHQ7rkhaHh+Igv0QNUGiAHRmkql/XPm/f+pPxDHXGNunGlpbWC/z7Gqaopjglo1V4NpqWVVoaf wZZxhUMTzLFANRgzJGqtaqElGlY/VrK+o/jt0z0AkVf+/mOi5JBDT8nTf9JNcvKmA1MliEnBdJfH cDF0EUIQu5tsy3DWW5LUKEzBDNjEf5WNBLGvqVGSE5OvPCdCLmPjHI3g4BykVn5riv0XCCv4KT+x 6PSc6MYI6J1dRTU1zqx3LWvuLamD9M5dNEHO3Nz7DnN3eY8JoCLFoGElIG4J1sR42Y0Ku9H4tbZi eh/qzsS34aO/zF8UmMCNbSg8J3hJqzXzqvRpRv6e7ZxDZWplYZyiS2/tpHGC7HEHnf98w03VswsT n3Mc62ywF92m+/5VWIlA8hdHfJFhUiBKHpYO8tZfQztFFRIdySwrUZoHTTqhD67rKX+wY9RwLjjU /w1lbmRzdHJlYW0NZW5kb2JqDTM0OCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDQx IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiAvRjMg NDMwIDAgUiA+PiAvWE9iamVjdCA8PCAvaW04MiA0MjYgMCBSID4+IA0vUHJvY1NldCA0NTggMCBS ID4+IA0vQ29udGVudHMgMzQ5IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BC b3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzQ5IDAgb2JqDVsgDTM1 MSAwIFIgNDM0IDAgUiAzNTMgMCBSIA1dDWVuZG9iag0zNTAgMCBvYmoNMzQ5IA1lbmRvYmoNMzUx IDAgb2JqDTw8IC9MZW5ndGggMzUwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQopT4GduRM36LTwhlfk3Bu03tpoa8vwiMwk1YvqFy7n/440D2I1vSi+sU/18D6WVt8LSm78jgYl 6VVzljLStryd7thYbmMvVbyy/sDT/RKDv0HpZVlCyJel1MNI0UbhOOGjkB4rCMfhMjv+CzRQuBTw E0EYNHEk8uNFrt7ajcoeO/ShRrFqRu+VE0sIbCZZOOmNASphaoAERxUDEaxM+V6574wd6w/ILB0T Fey+r2v8xGfKSTKNtQ4LXRKae9vJ3gtGn0XJNNHxq33IzGpwKtH0TwMyp2fKGcH20yxRSfYbJAXa 5Fy1M5sbkykLNvU4QB79dovhx12zOMiNkWTQleJ3KZLpvhb2JEbTRq/MV4fFzxpxHYhajtD/ihQe 7OJUlKP5CV2fhdjgriODINHz6wrpQsjMgXqlMKlNQWNqMtR2XLRijaDMG+db5RwmAp3H5m4Q/BWq ku+DAqeKzuQLDWVuZHN0cmVhbQ1lbmRvYmoNMzUyIDAgb2JqDTYxMCANZW5kb2JqDTM1MyAwIG9i ag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM1MiAwIFIgPj4gDXN0cmVhbQ0KTdlx lrpmt8o3yRFto+YevpYMmE95pC/MWcuJwz8tUEBGlftGpUao0LEoevyDji5tYn82Fm3HMpzVUs3t Q3czhQJHdPJWZu36mv3suzMeCEZ4KCHUeckoCZlXEvmKIETA7e/8TeSBhttMwGlFvCTuGN464bfZ CZPzi1+3rQBpSTceiZS8PyqFo1Yox8uYXnUijvlWYucTJ3kYBUeAqyVZP8aMTKtAmNzrFgRow/ZB 286UnDct+jqIoh7WCrlxRyFwnGGgxiVJVkciV8KW4v0C7bVF2QjgTd6PNpDAorwZGtL5mmCPoAVM e0mDHEgFcnuQ5e0ZsUbHPalk9mFTMmBHYGuuUnkoB/t79ZwOlCrHLwkD0oiobHsCDWiDYf275BQe nmiFC9/aSCtSvYlnnkAt/g37AjyZrKqG9AqKEA869Rg+dgtEibvPmjBvVkW5YrLoLIqDW4KEM3Ip Wmr9fNMkp0NC2Tq+dVsBmFw5jnbPLSZC/zcKWbULaT32tr1uwDEwSZ8GVgIbNYXHOtGZCoxGpDX9 IlBHwIaR1P9ZyHhWchKTy5Mx2u8JYHMGI+almOaPad3ZGC8lOTMNJPy1eKbx5stG9K/q4LpyjCsI mWc2068myAhWf8aCv0BQGyhWsV5lw0NTW1XPVRtB2w8yh4d0SHYxDL1eYI3/sVn5gOv9FDeMJVOv 0qh3/a6Gi/oqffBffVm78Xnfi0r+FjSAlwlLyrPF+n34n7g8kaMu/XV6jC1jfuU/lTs0VaWLizrW ftZzaig7Vu75LPEp0w2aZd4by/SdDz6GQHV7onCVRgJz5O/whQ1lbmRzdHJlYW0NZW5kb2JqDTM1 NCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDQxIDAgUiANL1Jlc291cmNlcyA8PCAv Rm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiAvRjMgNDMwIDAgUiA+PiAvWE9iamVjdCA8 PCAvaW04MyA0MjYgMCBSID4+IA0vUHJvY1NldCA0NTggMCBSID4+IA0vQ29udGVudHMgMzU1IDAg UiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0v Um90YXRlIDAgDT4+IA1lbmRvYmoNMzU1IDAgb2JqDVsgDTM1NyAwIFIgNDM0IDAgUiAzNTkgMCBS IA1dDWVuZG9iag0zNTYgMCBvYmoNMzQ5IA1lbmRvYmoNMzU3IDAgb2JqDTw8IC9MZW5ndGggMzU2 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQq9H/5Se+WA63B3aPAUun/Y4xMd OHUK4eiHkhBNoXoF05fWiW5qg6XvjeAyKhIb5aDzRwLvCEfbza1u57IIyoEYTq6VNo19D7iA5lOy hMeyUiQhzSKVrVe4yUJyNcxT+inQiURZstH7Ob2wZczAIMH7B1e96ebHDdHbO3nJUK9p8wZv2sSi Ca0T8HIiX26+Rm4JqKTU7h1vkLI8ObfJh+eRDn6N4V29GKTouSIRrtADAXz7Uww3ixfcwbw3Cfdy HBQay0VvxTHZ75U+DxRyv4kQ53CuoJazqAsqPZUgmAbcwFfmqqKcb5YfSf3SwFRhBoGDTkAMF7NF nnOYn4cxIYXSW3+kbMytDFeU0ZqE9J2q2wyHOCwEZf7oIOCKUG8l2zZv7L5/dChBC7T/AIuX0JyJ 1qCbN6tIRSNEsLHFJSEId4uj0DStoFguwzNJ3il+JSpvQHHpnldZloAYOxs8DWVuZHN0cmVhbQ1l bmRvYmoNMzU4IDAgb2JqDTQyMyANZW5kb2JqDTM1OSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDM1OCAwIFIgPj4gDXN0cmVhbQ0KUXJZLs07KUAXNAUjlSUuKFU6qjpXPPpK ltbtr9KtZTNNX0wo/ruu7uw5gKo99Zv25W3vtDfHmJF8stg8hhJM08weobyPCz2iPdGCJnMVMqYg e4hC5N6u8rmYTow2blNuwvWlbZ1UIMkK6vyAqY3Nn27a4wLWHYjjjHB80KAg9UHF1WFF6hjykgma T1KnEE9OS6ZgYmCCTgQAiuxFhRZ9s4v6M4paO3kzkJOS2kP8o+4OYh8EQDHI7zTkA/XXlFcjPy/1 7tbiqS9Xhg0VSSd4XemvgonUQR9AnfWQ/LJOFNkgRpt48O85X2sABus4o/+BR299Di7lv9yD7yKA /jBh/iBZTH36K81XmOKLtxo+7hNHt+VXEW1NANIRSAcCxadhf4uKkNhDNNDU5tv7Zdsw9IRgA2XI b9RX5osTOHL+a6J9GtYzZCrDmnlPiOnGXQ6e6YuJCanuVSDELrhnIqGtEvs8Sh+nIj1rcEp6ABAF vQD8X3YMenZaOxNo23fy2d8og3ub87uyW32HJUuY1JgrWADJ58gUUdSfnlJhta2U7Y+j+/fUb+A2 DWVuZHN0cmVhbQ1lbmRvYmoNMzYwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NDEg MCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA0NDkgMCBSIC9GMSA0NTMgMCBSIC9GMyA0 MzAgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTg0IDQyNiAwIFIgPj4gDS9Qcm9jU2V0IDQ1OCAwIFIg Pj4gDS9Db250ZW50cyAzNjEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJv eCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zNjEgMCBvYmoNWyANMzYz IDAgUiA0MzQgMCBSIDM2NSAwIFIgDV0NZW5kb2JqDTM2MiAwIG9iag0zNDkgDWVuZG9iag0zNjMg MCBvYmoNPDwgL0xlbmd0aCAzNjIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CgBUbBA0Y6BRfs1iCABzNsayrEVsc6Iy0lDMVEfJjeitqSsTsVmBY7uh/8a0TDjTi5t7nYNNh5RQ pt83xYVcusOlj/YwHxyzNZpLxRW0aAU6U1+381btxwHASmRMrQprCHxhkgRm0M7gd28oi6vyN1yo VaKM3OwTX60UJlUGvBpfeH5nfJwMeicnyw8YVUa6CnsOe8yvd6FImrp2ePEG/dTZS1PoSTYxIe9P +EebgdN2bWTsu6CqMZ06EV527Lww3pMUEtPq+nrmXYPWREKoaG3RvwvpmqGlqBe45Sjn23My46AE qXLskXtDa7IouGQeHYZ2gWTSrnZ6qZ1yoREPOf8TjiAWgB5G7QilTZUyGdjlLCaH3EMj2WGlQ5PF InaA/1yOu3SlrT0UIdE0JZa1vErUyPEDtaTNAhWDEUwWehIS6bVY/cfikmizI73Adj+K68XtfgpY P3GPg/qSlc0NZW5kc3RyZWFtDWVuZG9iag0zNjQgMCBvYmoNNjc0IA1lbmRvYmoNMzY1IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzY0IDAgUiA+PiANc3RyZWFtDQosA891 03jMHKz9pdPxSCS9oswQvTiIQXCVllORSWp1YFKt9bvXCDxz8ffpEDOA3cybPQXqwIZGZ+S0ytM/ A+kZU4Fia7bCU5Kb4Xe/VLyrgMIhAz4BTL/Oqgw5/eZbYVp3dOZlSxsR5WoQFUdFSqe88f2fYZfE 1FQkZWPZZgZw+ZUHW0OtGFkdNTgfH+z0K8qvKzCQsX4I+Jh6ePyMuiwYJ9ucqcDjNAFStnL/3myT caC9ivttQBNEZDLAC9fbNlGYgg3OaA7C/VuUidzdsRj9ck2i0BMlG5MKTtbE/6z1dwkK9qkHrWvx syHVCLu52UkloN4BiBlqK1cLMQjQVJ67Vqw1GB4YFUPdfo3kFn5Tt8JNOs6tHcuH1ORo0b4niVlp ofOtmpZHVM/fWIvrr4dSrGhw6UeRPgmjEz6d7s0cr+yqulwKRFB6IPi/W4Kv6X06wnaYeQh6j1Ax dY4uVlpuoHAtZM2DXHokcSj3i/fRYzrVTxnMAE4CYnl6XEVasG8WU148js0F7RlZ/ihOBe4ob9SK V+7nszt6buwhxVKYS6xPH0Z91cb1WPyj5E7BAKXr2L0nUSDsXfUkAoFTv2/10z3mIzeUo06fsVfe Y9uNfei95q/3PSVZgUG2sRkOYj8U4i7K1Wrai6OnraDYGX7n+Szp2OEHwBX5SfTrUG1YcsgGVZiG KvUIYTOXUKZUjUNedCDkRskCONZ9O4cl2Xh93/RAiybqTNjfM8RuwoyYVE3+KODo954x0QhQlX7V wq3dTWwZvQyAO6mqFgMNWebPgo9NSwxSWAwQksapU4JnOuJKETG0LKFfsMZJvuTRh30dp/yog9/R m3OZDJA1mVGjHSCrby393r3rNULZxfKiHu0zhGi50ec8eGNEHdNKA8VoAg1lbmRzdHJlYW0NZW5k b2JqDTM2NiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDQxIDAgUiANL1Jlc291cmNl cyA8PCAvRm9udCA8PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiAvRjMgNDMwIDAgUiA+PiAvWE9i amVjdCA8PCAvaW04NSA0MjYgMCBSID4+IA0vUHJvY1NldCA0NTggMCBSID4+IA0vQ29udGVudHMg MzY3IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzY3IDAgb2JqDVsgDTM2OSAwIFIgNDM0IDAgUiAz NzEgMCBSIA1dDWVuZG9iag0zNjggMCBvYmoNMzQ5IA1lbmRvYmoNMzY5IDAgb2JqDTw8IC9MZW5n dGggMzY4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQreMKJmHqnveDvTaE+D EqjHVGNj+TWTWjYtg+LuXSLidnriKeW6knQ4VcLwUJnf/KM0pQUAVdynuShA+J1eJm8hwPUoKzdH S66GwlxMXP3Z6t9/RdDevV/HacTwiusFOVc6W7+JoiRqeUR2v7y5M1xUUSf79ou8KLkYVTv+YWJj a6PP2eQH0Pbw9VJc8gQg1LIDBgH1RvWZQ5samXxt/IErWhs4HK/OxXw1nNURu1WXKP+VHYhg7giz ZI9tuMh880BoDxRRLk7757F4C/9+fnyOkqfqXXfBRtHPHYGDPiA0u8sWCt4acqQ6aX+lETdARWvZ 684Oo0xvfj9aaYs6UZBwCQFpq+lbfTxbhsqw8YDoBMqcCCrorTTpgp6itJOwd1dnMtL++3l9wNYo PRqjQtAaUNYyqu2x7N5P1bAimwvebt/p1ubM9qtI0PyzJjPreWinep6AXfF4hgeNXc15DWVuZHN0 cmVhbQ1lbmRvYmoNMzcwIDAgb2JqDTEzMDkgDWVuZG9iag0zNzEgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAzNzAgMCBSID4+IA1zdHJlYW0NCpfXmow67OKuEfVyd9RuUJYI QEbH2XYuo24XN7KjjengrlaBynCkk8k9pw7reAwHYcmPjqfQwm7W5PjMJJ5k2GLdPM4xBrYAxnLR OWcJrQubk8TzhP4hHHVqhKrBqsPmsHCCw9xZe1+K8jegIjif7CP2oe6FayUXBq8LHJb1dgVgO2p+ 8EECkdP+ZUCaGzmf8HBvidq4R+2vy64g23uN261o/L+DDiEsk6vTHJvlKII6iQlHa/TdN8jOQI0X Os2E7xooNAhtmEBNiBomQ610bU4b51eQ3UzdujPR5KVJvMjSchtti3ml4aCVfxVJ71dBbDBcOkgB uPQdTKnaTOxTDxgr0vmGfEsVPbHpcPtoO8WuZBOlPLSes9iLU3un46iliYxt3rJimZEUSxC/tdlF 4wTz3HmcTj/j16EKb/qiv+7+LCoDjb9ie38P+l2aifsgReb9i92r0WkXaR4L52QzbMlKBi443YtO WoeD2pZz+3Zi7jF6Ihc3Tpdr21l9OsNN5uXgDHLZVVGlVG8Snbc52dWu+QfVFF7szmhsnI/nwI6C iSzHN/H3HmPP6EUzUKwgR4somRSVP4YM3melW7qbgio4/argkggGLDbypML2eS8zUvNBQs3pimrb aXT3LpqX/4+6qDqbI7KSDlMfQI3BharWxNWWVAf9WoEsjUVbHTeEksufDRcsbTIgSLZKFBwLCObD ic4+cTo6goFi8xOYrYOcBMcW8VJmcp8s36oE93XEvLHyO0a+tbhnQq/Kd0lebFImm5FrppYH/BSG FVACv5wOM8w766B9onQ/9aW+o/pi4JrJw97XivYH1wZiN9HTotlDndGl3R3uMKSTAXc62ih6clap 0mRuB8VXRvUT/ssNbZFGWntsc+52nasT9rsq1jOO4pUs6EGN0kKZk6O5YzL+m6u6iSLWZ6TH7xBg 9mLOZIOVaz+FJJtiwyXQGQF2LwSWBFpeeyDZg6wwn+bWPZhs/hPfNLxsp9mMheymUSQjVNhgorrX AouF52SPxg7N0kf+xzPPLJxxl9awedy2brScATQRQDVk4+eezidra4vw4x5v41Iwq868YsBKFY10 +9URL5FtvqkF4kIKegXSQ55WOriUURpgk4f7E8BEb3yClDKhsMjlPN4XSZJhxBg7RrZmgBVoBEjw KnDq4RDQ4WS6ORxofNrwWPs0mubdQEovrlioSbVXdcX1QoTkAjFv0OmAD8HQ/bKx69PImJAOyIR9 yxHt5WiONelPquRLok2Hjd4EtaMg0a5pIYiNLibRs9AH567ZcDhnvQMbIfH/mRb4S9Ysk4PzRIuU 00oenW150LuH3yG+WnjO9f51GPJLQ1EUsrSMQN4gmB4AMxmBNM8VxKfB10CYka/0+AV3uwACQjgn X52DF9/W25MF9vEzFkwnUuS37MdyQ8bdLTMto0B6nooCvOxwJKFZqM8/kadsjfzNJRPexG2OXWdy p49K+XxKv8KGYAqGtEVufh1cu8b6jU/P56FnarYWYnJRcOb0kkB5hgqvhS4BSgInt82rmP/Vucqx qPUhbF3aDnYjXQm3ksnyn1blumnwUkOydIWwROReW/VeW5W2QQBwFnroDbFIUilWeC5CGvz4QQOn okxCstneO4mVxQajODcxWcHdUgFO3PiyFKWSLBP4nb8ZzxKuZAFqCSJ1T4Hx20pipz3wRPA2MBLd ynQoV6iNwISxzZzSVZ2DM3zd1hYxM1hGB1hhYzx5+Nmm0IaPyhkNZW5kc3RyZWFtDWVuZG9iag0z NzIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ0MiAwIFIgDS9SZXNvdXJjZXMgPDwg L0ZvbnQgPDwgL0YwIDQ0OSAwIFIgL0YxIDQ1MyAwIFIgL0YzIDQzMCAwIFIgPj4gL1hPYmplY3Qg PDwgL2ltODYgNDI2IDAgUiA+PiANL1Byb2NTZXQgNDU4IDAgUiA+PiANL0NvbnRlbnRzIDM3MyAw IFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSAN L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTM3MyAwIG9iag1bIA0zNzUgMCBSIDQzNCAwIFIgMzc3IDAg UiANXQ1lbmRvYmoNMzc0IDAgb2JqDTM1MCANZW5kb2JqDTM3NSAwIG9iag08PCAvTGVuZ3RoIDM3 NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KVF9tFhVVfD/uJNthufpLW/8K zprhXFVl8R5y4nLKvKPREjE2yq/5g7H31h3+92XVq9xTTltQ/matmO4QZM7n3SPACEueusnjoov3 pnAd97j6Eh+VsFelFGzhN8bQwRrCWFZNNn+/zG+XqQEZ8M0QvnukCJzKCHVpbcRtkpuS4zKZEdM6 /QiNyFajYgTTQLSUqRdGQpbIVPznGcUUbHLKupYdNZvcajVNvu1l5AJdzpKgXOMsBXqWK0MHjrwr EL539qTFMhCD6hBw+YGcXqKi4EsewC+ddDuDzInOVKZY7cn9DTODQ/Ti0bLoavAA9XnBjvAxaKkL Y0kNZ+tg5pu1EBBp0/h+0UqkcXjZwYgjsTNmUOUWbUvQFfZGW2fqz/Qlcmf9IM9MezR0CXMSfoc+ yvaGyWPWElDSomvr09tIRU9xYdfstd7cFAhf+XTvd8WLHDl3aExbKKJXLj2wpswNZW5kc3RyZWFt DWVuZG9iag0zNzYgMCBvYmoNOTE5IA1lbmRvYmoNMzc3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggMzc2IDAgUiA+PiANc3RyZWFtDQqUdCCL4nb8zsEpPuHjMolCk/tTwrUX uhJN5uex0aietjEbRLtoUopiT7sodpfumtqJzjCoDUMALKn8Z6JaFu3vMnHteu2x5WKfEHrZwJ/y BaRMig83Z0u81OkQBA1b/ujIAOy0tFCoXifC2euN2C2RjNYG2ISgHwzFfjZtRQWXMCglvAeMwnzR OdpIUSj8j71Rr9Z6KBNeGx776z2SIso/YO+kNT6OYcbPChpfr5LGFzmWVJtvqvFQI7zNs5ZonxVh 4tqalBnwjqa9eGK3HEW3LXScg1twANMLFCYWrwg89coLqCRTLgiA1AUZRAABrBDYUi4O3/Qd3DsA 8H9pzpIit+lEl6qXJOISyUQAdPjC8qd63lLvYO/QYDR9hrnX4XT1rH6PSioIVETJnm2JDC37Z1iI mr6A8lcCBkEpgITgZo/vQ1EO6A+qHyqH4RDPcXQZDhJL353482tB3qt6bfbfp47mBgbnL7lqr1L5 P/Z8OI+FFuJE8f6vYCQ9GXlzzLm+mAEXr+CdrioNWY81X+rQr3Ld8Vr4C0jj2C6VJeAPedZAYtTg hRgC7U25c7YyaId56tWwz1nyiXdUNFkY/piBpxjfQIbadgkSaABcsfjYtF3Qm2lzUGqZC9OP1FuR EuYytDSQfWGTIdi7edp9JX5fxTNlqI3c60dQz2NxlN4EEZ3fC6w9VwX7pGeqMxxqCRdW2xhZm7tC yfL8j5ADJdxpP6iOveJVjaETntmD5M9owtzBeDJ/UGpTvPYQX7mdphAgc6V9a9ZHL8UB3ibS5phf WI8EBEiVo704pxhGqGmpmcT2hZLuFpK+vLdLtPR8S9K08Yhg+lvUPyYNflxaACo8kPRABYmyDIK/ TOjtLqdrD48vL+MW3L1X4zftyZZXjec25dsrxJFPqcK42Az+PRH/svu3VkOpPSQU4nmI2vUdeCWj vcUrH7+fUPx1Gq3aTVil/FqBDAlLp0WFFz9tdAyOynOjZWMPu6mdGdMH+bxfd1REBJMosEQbwNgP c26UEJuRpdbvrhFhVGN8nehL4FzCuHsm1uu2gpyNjwhdF6fJJjEIc+dW8I6cOYu+HZGOwKvoewCa sV5fIoPTabg2fVPDnowr8uUxwc5279uURBikrgSwJ2lGBAkE4+Txi38qYGPRty8+Far0FmoeDe5Y jJLulVgW59+SfwcYYQHOO1NdBkrLxMColgUUF3DbgYExjJg3hDyMlWwnDWVuZHN0cmVhbQ1lbmRv YmoNMzc4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NDIgMCBSIA0vUmVzb3VyY2Vz IDw8IC9Gb250IDw8IC9GMCA0NDkgMCBSIC9GMyA0MzAgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTg3 IDQyNiAwIFIgPj4gDS9Qcm9jU2V0IDQ1OCAwIFIgPj4gDS9Db250ZW50cyAzNzkgMCBSIA0vTWVk aWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUg MCANPj4gDWVuZG9iag0zNzkgMCBvYmoNWyANMzgxIDAgUiA0MzQgMCBSIDM4MyAwIFIgDV0NZW5k b2JqDTM4MCAwIG9iag0zNDkgDWVuZG9iag0zODEgMCBvYmoNPDwgL0xlbmd0aCAzODAgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCoTK+9LpmAjDj9CW8t5XZp0zzqvW6w32C1y2 dbIGLybciDR3lGm+EU0ln6T/uR0fNR1jXOxWrr2eHtbCNfLM8BSLPuysja1Xfq25z0OKAp1fqHvO Bbj62p5PklCZS5d5xwR7zgdtOnZPQb6yoWk8WEQ68iuRwwbWHjkd2XffOl1COnPHKBGyYeq9yJ3Y 9BMmMwcjT8uy7ncZj9Qk9lVxVT1cGG0yQDwD3oKzLsfREDohOaGJQjctZcGVRrfFwU6HO+zgqTYN Uk1YAZ7pBDtcNoTP7GpwE/GOqesyml+9wFiF3diDbT7L/3AOAG6oTTl2oEpIFzw7Upl21gsHGUtQ l3J5cFLVNaCYWcUTZlmxTBBuEFxWyFaoN1Y2SbKoQefIJK6XzB2UTdBBWaAkzx1/tWK9jWgandMq j1olPu6Tcz1XzKzdrnqBBHrz95Vch04v7UYTHJsCUt4Yvc4v3qsNZW5kc3RyZWFtDWVuZG9iag0z ODIgMCBvYmoNNjU3IA1lbmRvYmoNMzgzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9M ZW5ndGggMzgyIDAgUiA+PiANc3RyZWFtDQqSF078T3mHIyf0bME4bgA1nwbEkD0j/3ho6AUPr76v 3OzgMpfPOVOBls1nUjt2CkS9YCv9Ajk31b/7A7/xwk4quEvdlH1dwpVspA2DnTSyTt0MDTxVvrdg s9tQD98f7FwwD4mnEPRtVr8ick66LwvMZGMGFgQjVDQO75hiG0OjiIqRkr+LOz2yY0Diq4HDBPxn H1WXLCkDL03IY017XiMK/JXUMVgtT6/3SfgH2Glf27vPp0avebi733yqxsw8VgvuHv7+UU+1ArRo EzUzyDhM5trdZpKwc5VDULvKX4pMt1dFI158vNXsrScpAP1dtx3vPZnOStbGLVTTLlMjb+M0vqAK pg6JUCmGVntNt/nR08QNWwsIlXJubu1JCbGye2ihqIUA8ywnzffNaA/foECITCmgHVH5GPATPNh8 FRbHRWq0pqpxjD5Az3dUA8FWbCEA5XYn2KvwEmdtOo1F6fQTRR6xqicKYjyU/pLf05mSB7sndGmQ 6+Yg3RygCeF+slK5IBEmviCqKwcvNQeVRh+SAOz4w4yUrxIEGp4F6QDJrYIF8Cl7gMy5gPzlnE99 j+giMXSiV8yqTtpC0qI4GRT0FxiO/QCvhk/Dmo3bw0ldTVW1xcHQo5uAl0ETW4zbFLUdLOxEi3vf 9/VDu9iDn7AliUmevs19eBuzTRTa0lefZjMZ38dGlhF8CWGl86TZ/qAVMREug7+qG9nBVthJkLlr LA64qS2mxGvb4gKz2td6HIvaIFYraYkLRssBeZ9xGiB61Cb43eJgdUUcxjww8Vp5gKAabcrkoqDg ebHP6cVzZ8v+FqpkedHPXju+Ej21ErhxId/lPblOlc004XZnzYiUnb5MR9nKG46rpNWrQhINpH0N ZW5kc3RyZWFtDWVuZG9iag0zODQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ0MiAw IFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDQ0OSAwIFIgL0YxIDQ1MyAwIFIgL0YzIDQz MCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltODggNDI2IDAgUiA+PiANL1Byb2NTZXQgNDU4IDAgUiA+ PiANL0NvbnRlbnRzIDM4NSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94 IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTM4NSAwIG9iag1bIA0zODcg MCBSIDQzNCAwIFIgMzg5IDAgUiANXQ1lbmRvYmoNMzg2IDAgb2JqDTM0OSANZW5kb2JqDTM4NyAw IG9iag08PCAvTGVuZ3RoIDM4NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K O794NHp4NjsUzSxrJs93d6OgF3oGY+kCWiDY55ZU83+vqyiuPJQy6Eucg605SYpMaAf2VcE0RG3A eLwpoqxyvpPuFJJTf2SELgjLDdMlYtSVp1np0ETnK5ZXyy1dUUwdj58XjQ/6VMlS/x1318A5wT1u 0JFMOW0I8UqpKgbGJYRmejDeiuQUucy5NnK6+f9+dv6gSLFgXMegkxCB7c50ec5RtRswKvmPFpg4 +vhecavG8/hvlWLGOTy/fyngjCcRi9XtfcfbSRazC1CcdaZ6VE2OyNKPlsCRzfCRcoL9+LXEb/lE UeV6wyxzkUGeQubhlRNznSZaO3scA9QQamcP0vbySwOYTY0B6ub49DKtfQ4PxkgStzRnVOlIw4f3 dCbZaIPMk6hz3hYzb1PcdVdQ5T+FQBCNVQd0H+6qypU340FhkceezcXq8oRqhe7n5ftbfg+WDRQ0 MpDkNgozbw1lbmRzdHJlYW0NZW5kb2JqDTM4OCAwIG9iag00MDEgDWVuZG9iag0zODkgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzODggMCBSID4+IA1zdHJlYW0NCpIXTeKE Z0fKJBKRN2vtGcrimnKpal1zf0S8yor8/HpQFnH7E0Y+gD3yOvlkAOIyJlcekL+yXmkg4kJ6C4IS 5Dg1S1IkrqOs347SZmGhFtovbwaJe18ZDkW+FIrfchAuAPZFQRwBjWGjdlaEM0HoacAKhSfONXA4 34223Bd4M1GAPp0kyOA9UCvxZJoAcsjbXyP/svrTrAsD4054wJxUEmPIkGeH+UI6N96tewSzziu/ deSkRUOfS00L+f8NMs9B4mwiq1NubnCzj5gGHQwIchIJ645xP1rRnYlIkJSyAvVFOVsJyiH3CoL1 ilUyl3SdgTrvQ3ZipSGRiujWxObd1VGaNvrGALQpoG4Suk/EQnHFKYNJ73xyc/EKTPAfagbYFTZi eUAXSIvoeslEvlFuhPUU5hjFVKD37FK4pQBJ6i7RfxtUV4j9yE8rFqjuisABVe1w5vymWTz+r3kb h2PfjW7aTjoMrkI7+Ff5zglyW+eW82LUWoUdT1cCdQSQINhiqgEbeJnruh0kGtTbkUxd3yJoDWVu ZHN0cmVhbQ1lbmRvYmoNMzkwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NDIgMCBS IA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA0NDkgMCBSIC9GMSA0NTMgMCBSIC9GMyA0MzAg MCBSID4+IC9YT2JqZWN0IDw8IC9pbTg5IDQyNiAwIFIgPj4gDS9Qcm9jU2V0IDQ1OCAwIFIgPj4g DS9Db250ZW50cyAzOTEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBb IDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zOTEgMCBvYmoNWyANMzkzIDAg UiA0MzQgMCBSIDM5NSAwIFIgDV0NZW5kb2JqDTM5MiAwIG9iag0zNTAgDWVuZG9iag0zOTMgMCBv YmoNPDwgL0xlbmd0aCAzOTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCjh7 WmIyLpwQGJW+IHz5xBffPukMp2dFBh3V//sDRTMpyxX8oAQE6/rZRGyKKvNofo55qx3l+6vkE2/R J5kF3yII6Ppi41kwaRYih6NI4P+V11mTNV6NjtPSQ9nFXsLRYsKPP2oHz9ReWR32+iaDTKafrF84 fqvw6alhDJohTKl5mL0JKKpnI2oyElrTg1gXLSx5DqhLFTVn41QJbMNBB3UCw5X8t8ikiXWI0IzZ 521Tk92E95bTmm6Vfvfj7KYo3+6gnKwoBRZBeY+cQsAiYti95k+rr2s57yNQ8g3K7ysekkKjfZc4 i8jQga/in1cbxWmh39qU/Hyq0GARPPCId+mbzpLxLnlY5ncaZvGHU74N7+0NVUs/eZqJ0HmEOQer gl203QRepu58swnyitbNG0oRTU/1pm1XjrxmqGdnVUqqcnf3uQjmbVihspHyVoa5AEOesJl1yJUb 52gHO2oPDWVuZHN0cmVhbQ1lbmRvYmoNMzk0IDAgb2JqDTM5OSANZW5kb2JqDTM5NSAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM5NCAwIFIgPj4gDXN0cmVhbQ0K1VjotwTF Cn1f3VT/MN2p2MXwciDtk4a2jwJcpbYgGD6IYEAHg2oIYzHbNUKbdoFUtrfSwmduxpcPtXRn3S3t K7SfQ5yaQNv1BHw9WewHLX/sRwBHFNcZbIQokhjtZiJq2HP1ZVHiRhwbxF1g/EZrYGpe+/jwaQKJ ND3mRS34AT3Ck97acDK+aWVsoGgPQMe15eoCaOpvPBGGMmWCXcHf85b/u3xV5hbbTAQvjAoGVdMU aiQwAv7YJp41hOBYUELAXAO5xA84oL5zYvKtv3zdffDtXyXppD8liRvDsR3Vl5Mg7zdYNLr65zk5 6vXSIYY3zo78KVr+9BBXs9+V0UYZSLjN6+Pgbd5UETn5wDOQKL0hW5FiP4Uu9t0+okXT0qqTjhTc 2fK6+d96MhoK0Llnw3aNad8RZka9t+vWotOqV/MRgCyUZznDY6jJ+pr184hO49BF3KfW2ojJhJYL CdmMDWeMojvFCZmXd2FTEr/rT8EDLOz4JSoFY1T+kmrMSKZgs2certxXtcY0QnvTu4deDWVuZHN0 cmVhbQ1lbmRvYmoNMzk2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NDIgMCBSIA0v UmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA0NDkgMCBSIC9GMSA0NTMgMCBSIC9GMyA0MzAgMCBS ID4+IC9YT2JqZWN0IDw8IC9pbTkwIDQyNiAwIFIgPj4gDS9Qcm9jU2V0IDQ1OCAwIFIgPj4gDS9D b250ZW50cyAzOTcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAg MCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zOTcgMCBvYmoNWyANMzk5IDAgUiA0 MzQgMCBSIDQwMSAwIFIgDV0NZW5kb2JqDTM5OCAwIG9iag0zNTAgDWVuZG9iag0zOTkgMCBvYmoN PDwgL0xlbmd0aCAzOTggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCqkeU8LS iNrN4PSj4jXh9YsO6hDM+lZuB2hxkmGM6lWCCoUbJ+WJ+gQ3LiaaP7Nqw4BUzndgZRqGjPxQVnft jCClpq5K1Z9/zimSWxTO+G9UwaCUs4qhUgczPAHUv8WnAccFlykdIP5spywJcMUk3+70sqkVn37r t+mQp3TO+n1vvGsMzofpF68XUBlm2wjy127zEhEatMtnAjvRSEk0U9sORFRUBs4alMJVr+7muEC3 SnNSlabFnol7f/ORp0TifnOku/+PpE6T7pGDo4Y8CPflNqujNktPjkBfI3WyV2ADi3OGNwfWnfaC mZDIKdhJgAsJ6R0hXVp0345krup0xZtHq5uP+EGEjt6JiPWHb5XjZv+f+w6CbY7jfO47LDnC98BB rCZtlLzXQ4MSsO1LhOZM8+jBBVY2ET95P0+U3Z0vR+zp93C/BWxoRx4RnNK4slxY424YidJ2ThHg qaiSDWVuZHN0cmVhbQ1lbmRvYmoNNDAwIDAgb2JqDTc3MyANZW5kb2JqDTQwMSAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQwMCAwIFIgPj4gDXN0cmVhbQ0KHHwoTvSzL7aY BYzBY5jpkv6tqjg1J0+c9TzsEmXNs3CUKpy/K1rzdHWcKOABaOuFX9b3jD8eRJT5IbImEZOcfK/g yn3na6BSSfRtmXhbNZ7pIq6+K55REQPG71V+We++fjox9Chz5KseYpA42C/95a/Pqk7UHQqH3nie 1y7qwc0BG9T7+MiWJQUmzi0iAT/oYJu44eALa/4Gqjs8g0Ei9QwhSVKsYCXtLwJUA/NisDKcz9JK d1o9s+G0KqN7H32iIjs82tpZ5YmAg5BSLK3/iGcQIXuRQOtD1adCdBoZ94mvfyQIIdhkpa6Z+d83 +2ZuhYulCyYKZEVW2yxRKSZanRzedGa7dpAZBHUs8ekJE06Ym9HFfjQPWfCiDte9po+4KVCVAent Oeuuhz2hmeg+s4C/LwFNe2/Mr7zbO/twQ5C8hx7ynA74SpV943ORhpc8R2XZrG/43+astWEr7a1x ntXvdXz/E0USdDDbAnxFwLHCMGZOfZcyK3RDPy5KozRaGIubjkEdsQ1q2Bk8Rcr5+pzIl0cRKHJd zqp1goTW+uORjd6PUaljpQ3CVDb9h8sOPlnoaKh4UDccTsHzjqKT/JSVw0trepaiU2cUcHOO3y9s cQpCj2wQSZWoi58F4wmEYsefEU3YbEnbxA9S2Uo59tbeqge6Sw/9BatHovDsmMW22m9dr4aGDrU3 ozKW4PFSCPr/I83moEYhC87LPbYDTPujZU7Z8pFCWIcBgATSetot9ZYCdBqcYNmek3TC8wlaTRsO MPIIzcHpPWNVr/jYP+HP2jiJDyyivlxYjvX7tShd9qP2ozqUbHzhl1E7ejp+FnD3C2M+YHDOoCON 80SZrwTnIfaUpjo4wMDsNjce0CLtUauC4UPmHFGjYhJNRJQCj/G3PzZVQ7HVqG/3C/ATkc9KdOMH Jvi59CEMM4FgxxXO7JQUeAlLjhNb/9JCFzIodxwp+GzfUl6wV1gakIuJidBO/rPRlxe+VC4sP0x3 uFqWJ9SODmnk+cd5IioWtT8gohY1IfwNZW5kc3RyZWFtDWVuZG9iag00MDIgMCBvYmoNPDwgDS9U eXBlIC9QYWdlIA0vUGFyZW50IDQ0MiAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDQ0 OSAwIFIgL0YxIDQ1MyAwIFIgL0YzIDQzMCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltOTEgNDI2IDAg UiA+PiANL1Byb2NTZXQgNDU4IDAgUiA+PiANL0NvbnRlbnRzIDQwMyAwIFIgDS9NZWRpYUJveCBb IDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiAN ZW5kb2JqDTQwMyAwIG9iag1bIA00MDUgMCBSIDQzNCAwIFIgNDA3IDAgUiANXQ1lbmRvYmoNNDA0 IDAgb2JqDTM0OSANZW5kb2JqDTQwNSAwIG9iag08PCAvTGVuZ3RoIDQwNCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KLj157TrCJN5XtmTPcN+j3+4KPSQmmD+6/5vWxomiYCPA YCNPNQEKJUsECIJRv1t1ij4DyGH8uTG7D9IkNcpzvLgN7D6H9QVxYw2hBKesqPPWULOR1Vs5rhtG xMsAXuduiq0ld8y3RVEOyMg8ku3M9neMrJfLjGBCWTa2l3wEzUdO1jzaTf9K0hQfa9sctPI7DwDl MmLSsTZMvfb582H998nYnNMcqLLMgZ0rDhZ6E2NP0hznh7D8fCdq/Celc+VsohqOcEdcOL0qZXya lsrmDxNxXyvoPJMkt9OPEX7bRpBWxBjWxQWXRXdvT+O8xoCJpIbaIuOnXvcSoky/eAkQNNseUapy Cs+D3s07oLZU/0gxuFTJfuDc/XCu1yOaw0CFS1rXvEgBN693SO4iJJTJe9bd2r0BfuTi1y3qLvJB vB1Iv/Vql8tiiieYZhH+v9vOtf19a3v4DfAuCZUnZQ1lbmRzdHJlYW0NZW5kb2JqDTQwNiAwIG9i ag02MTkgDWVuZG9iag00MDcgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0 MDYgMCBSID4+IA1zdHJlYW0NCg36DkOS/SgiNDioZrN1fd6+P5gmgcxx0h6ElEVox9PH7h3izuwq CYKBDPN7AwiwQujH3sVhKgn84JQZLVB9shXHpNQER9uvYjzl5AYM8ovuGO9EjdRIzvkHrIXo8DG7 rE/qY9QgASlQ2plIo/dUkD6ZZGym7WduJYoO9sDjLiXL6+UGr6YIACJ/P+kQ63fuJmSQlaUq6bIK LSL8Zl2ZUdFkFFYXTmkMiXkvbq/jw5cXi5h94nvrCMZcOCIHxvTz/or+J+WI4JO9VjKGC0hYaDZQ Tx+EPzI7k1GDEOTNvU/hZE8H2q3/0QOqE1WcHCTxD/HN9CkI0oLxfachVlFgQ1t/XKZd0bVT6wEG ge69PCBNPUF3dbGzPrsj/onHkkbALtRiZfP74OjJGU57waChHw4ZkgqIN+hE9QVYfNB6Y3kRaBtP gQAqHTVKPFVY3ABHn/ySDfdU4M6cHjB00VyWVDU8Cb2ceT+6+Is4TPwNte5zDwQYm+76KsBUdJ6d QyEEUceYax7m5Z9Z0guRaaMvzsObdIXz968wkDa6EhcmYnogAlh0ISsX+8qB7WvF9x+js3Nf2Ti/ H2i54t9ylua4wtzT32ggDnh9S+ROnhg27dpwmDqAAvN7gsHjHt9jFddS8CGd/8/nteAn+MM3JTvM 1enpRfNLTCRRgwsBaDkc69J9OganQCJlMbpXwHcisUCR+KECQwkVAvpmH7QsPwJhgq684AosDedK aAMfPE88BlYwy4CfpNzLwxxe8YqS1wvfztWxOaIusJrEctOw3mn2jz9vwCBhvUxdE0KA+oL4T8qB xxtsdMXxkW0VtoINZW5kc3RyZWFtDWVuZG9iag00MDggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v UGFyZW50IDQ0MyAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDQ0OSAwIFIgL0YxIDQ1 MyAwIFIgL0YzIDQzMCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltOTIgNDI2IDAgUiA+PiANL1Byb2NT ZXQgNDU4IDAgUiA+PiANL0NvbnRlbnRzIDQwOSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQy IF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTQwOSAw IG9iag1bIA00MTEgMCBSIDQzNCAwIFIgNDEzIDAgUiANXQ1lbmRvYmoNNDEwIDAgb2JqDTM1MCAN ZW5kb2JqDTQxMSAwIG9iag08PCAvTGVuZ3RoIDQxMCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KhtG4tyMpI6JsnCizflKNehF1Pmsvv0Ot66x3vxOnrFBJotL/SqwRKAkb+fhX IdhWs8AdQYwCbXwJqNO6B3Tqs/m3tjOfa/JQj6GYU51hfsNpQSpQn/+H2knI2UaRg8g7L7FJJNsq X4GLL1dfwxTTlloqVg7ayZkKGWmKzzKaTJFw5YEzM7mVV0iFXSSwqe0/q5DF1azC7kDKt/egJy2N sNMRBU/7XsMFuaqcqvB7VHXQeEbEXxFfFtpP2GimFZXBlDX1HrZ2lTBXkBP1G5LINrMhnzT10w9M 3C4nBkheBpIHFY79AeZXRuyEEBWgasMz7bm86xLW78Y4cjWJXBRLRf2Hr19srmCgrnEtoxkkXvmX YnwLjXLYo2d5Iz4Tlq9eR8ZJNkpsN21yQf7pdPtznTmuzbBhb67DJgYLfVGtS8b4VndiUkYPzPoS En14Uiqe+tb7W2+d2FJoHVxXPPUNZW5kc3RyZWFtDWVuZG9iag00MTIgMCBvYmoNNjE5IA1lbmRv YmoNNDEzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNDEyIDAgUiA+PiAN c3RyZWFtDQoz+dwihR4PpQaDA+BF9jl4hnOE7q9bl3eO3XRyMpFBHI6TVWfxtOnI7WE6wvnElERy n4f6jjaPghE5EkLtxP3JBYsOukyLyvDgnvdP2zcAy0CG0mUcTyoGhPOeAAsdmSuK9ovWyaLQzdwQ w1fqLIPV9X0sNMO6FHkgeQmaOUYpRr1ToNfDNX7yIQiiGKiTsJGDsP8cu5CCEZP1J4b6HlAA+xa/ 6G1maIJTCntm7f5x1z6TU5MiB8qddN4nD/F5j06dX6BR2H9z9klqPGgA17LbkpsHxLBNRVRvP2xc 3bpLtEAlFglKeUwQLg3AmznDyxIrnUZKmntq523y3rKU7+MNiSAwYNc+kqxJ+Bzr8uIe/Sp8bAUG /FOvqEytnRu1cg0dKmwnWu4Iywfk+KkRURgA7s7v8KInd6wogk1FQ7d87SiXiL4cb2FKTWNtiure qcA0deaPK05Fidd1VRgOez3GtkA/PeY0OlnXBezCIC06CqrcT/R79PR9/NqmZE0xn97wS1DVQ0HU OjuK3YuJTpEdbDJtbKPGexsX2rnjna978rWsjYFvae3De1em3zfToATwAz8GVRsKxiMaS/YRm325 GT7u2xcSwWrkwCKqjgcPrdzKGSTXavwVEvlDSke/vGkBWAYxnSIeUONIHOF/g3Fnmmn0NAyrfQkp PFEiDeOUc6bdoiBuS8Az2kkh/RdpgEp3Zz5lDk2+Jc9gh1ZtPVZ4F1zS8mQkpsoRMqaSqPPPtd73 Y9RMfjQXFo1uRbSn4e9qBN5RJyvMNiWSBkEBOLqVyQ3aj8iPAkhqvIlBp37YqpJyutXeWg3cfGww DWVuZHN0cmVhbQ1lbmRvYmoNNDE0IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NDMg MCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA0NDkgMCBSIC9GMSA0NTMgMCBSIC9GMyA0 MzAgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTkzIDQyNiAwIFIgPj4gDS9Qcm9jU2V0IDQ1OCAwIFIg Pj4gDS9Db250ZW50cyA0MTUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJv eCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag00MTUgMCBvYmoNWyANNDE3 IDAgUiA0MzQgMCBSIDQxOSAwIFIgDV0NZW5kb2JqDTQxNiAwIG9iag0zNTAgDWVuZG9iag00MTcg MCBvYmoNPDwgL0xlbmd0aCA0MTYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N Cir/0NpRL2ejO8/mbBxePkF5M0QyIVBbDtlyIT6J53kWC1mpPWAwOeI7Ew83SbR6uFz0cpv7qMAb +UUJKqer/Gr3cxRl+wT30onbj7oFJ1hHvcZtNCTSo6T04Dy72J8SFpiXHjx64PE2KtpMyWxY1vkT thnrCZwI6+KGaiWfUcI3Iw5VT43acIKWqB8fbwMHBWAPGYBHeb1+VLhX5tpzwFYzgFaTwj5ERDyj fLOVFpgdG2xq0p+PqPmrzDhpDWERlxjZHKQOK38sF3OQeaEz10LB3hzrhQb/7G+c/LqOCgzwaxRf nZripC7vVD9fPiis27eqOkpnFcPZD66xRrFKC/eXk6sQF1tT9YeMES6pAgLYO8KTumNDLD3cDxAj fzey+8v5ERvYmiVeK+4xgkpcUnfmiV4HLwepuOh27DHnG7seYb8P2yrURJYsWYap4Xaz663eutQs xOC4nz1ngq7qDWVuZHN0cmVhbQ1lbmRvYmoNNDE4IDAgb2JqDTgzMiANZW5kb2JqDTQxOSAwIG9i ag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQxOCAwIFIgPj4gDXN0cmVhbQ0Kzm4s myFQYGyiQdGrSEawduCMT16zUN2AGRz76Dz/xalWIpvFB8sMIlhy/yyPf9YMqIzPGqoRYcLQgIfp dNZojHUFCvgXbfMfvivgVXVAXdoTwG3EG+DsRZYeAmAPYN8QNrmOr+C6ynBqnwq6W6ZW3gsBSKDZ DzMNp+EE8N7K1OQagBCCK7Sh9emRIJiebMyKr9cHRmB5zGs8Uf+e9ev3k2iO7vbHQAvMK4HZQn48 feFXTQfhiEpAwnY0v8y3gza2m0kFzyqUKSjros3yrt7mZQSaIdg+t7hD61amYtNDKBHsZmLiz5Tz EEySX0x7cWssdSDMw7E068U4Xrx0P563P/ZPLSKeIQvumWozS8kornvp02O53YknG08tFBzLrIKU GJKLJrh4luWCIIY5kAojx20aG9yws6WM+bfWeKt5YOFxomaZwg/SdF7Q7RCG3Jx45Jn7jH0x2VXe mk+hzV3CBNVFD4SMdpCpsZ/vc2iT6AQMPqOzv5oqU7YGLd+tywzRx8huPtya3fGB75NZiN7UfWoW 1qZRJLJCjJcctpH90eJEMwy2fn5xKEgabMn1s0Zm0uZPnJqODD7m32q24TsNf7/cRzjeLM/rtQAn T78cmcQ54Po8YQcxzccExdnZHBtxiSDO+6d1AjmfAylhAqNF1wynxTruKIUxtbcwBKEEq1tPm/gg QsmA3HTa/JDBRUZuZhfQHiBpBgR6W2DFoIGhURhcUOlOh5z60plerm253ymKjM/RPYxd0hON6IAL Eh9b0AWoIL601VAYgLOxiXC8N7N9wgtO4Xxyr91jG2XG7uUD++BD8TI6Yk1qpSRwMbBUh+fAFS4R NKyPFFOcyrnC/bQVxNzVQHGX+j9LGzGsLrdC4ue6XUr6CST9+CB+uWoZBZ/qdqPcFVMXPe0CjbkK N+ANin4yrVlq9J67wx7uqooi7Jf0usrz5pq2PFqTB7NVupZ0Le9gQFHMbWtvsbwGf/DO1C/Cj+7y 7Xd0AIRxt+7x9Ca75slHqJpCY3RjhCXumvxKQV74mAB2sIcGxEdTE7uc5sLdw6YrbayLxqZWzAQF JdTP3Z8iFwrpZyLdiBaClMhzPhlioAYL5GPD/Vue9Q1lbmRzdHJlYW0NZW5kb2JqDTQyMCAwIG9i ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDQzIDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8 PCAvRjAgNDQ5IDAgUiAvRjEgNDUzIDAgUiA+PiAvWE9iamVjdCA8PCAvaW05NCA0MjYgMCBSID4+ IA0vUHJvY1NldCA0NTggMCBSID4+IA0vQ29udGVudHMgNDIxIDAgUiANL01lZGlhQm94IFsgMCAw IDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv YmoNNDIxIDAgb2JqDVsgDTQyMyAwIFIgNDM0IDAgUiA0MjUgMCBSIA1dDWVuZG9iag00MjIgMCBv YmoNMzQ5IA1lbmRvYmoNNDIzIDAgb2JqDTw8IC9MZW5ndGggNDIyIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQqJpjfP2eBzriHZxAnNpMOcme8/z3VoZIsaBcQJmyHKI7dT4I78 2I12h4PR425mtGDn6+HjVAEnbLVgKkdGdPy8U562IM4X9/SSKkHz29bkQcoJIRWz1KuVMH4/nesw JMxJuSO05wtTerILzHhRa4ouPJ7qUuqJVhbKsEAv+HucnfsgZ5bJIwWPfBy2CeU1SpwxNQxiBd2w 3hmVrfc3A37AxTSI7V73xmquRG16sG0TNV0MxhfQ92+/SOUEHSXbg+V3IefPWfk68Y84Rlw4q5Fs R7JOT0kVaCE5JQKo4eBhPFRkFNtc1nicN/jkQ37OpV+7H2cijsRGiSvzxF04zScpmdTeNpBJBWVL s6LQx8N2jYj9eCObk/D3EWZfDGaVAFfkl0Xcqhy2KrQCpxmM3hcN49rhtkZEC0LV5WFDlSHz/Zd9 5oxZn2fIwMkuEmwKK+Hn9Dk0DDg+Q2cCydA9DWVuZHN0cmVhbQ1lbmRvYmoNNDI0IDAgb2JqDTI3 MyANZW5kb2JqDTQyNSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQyNCAw IFIgPj4gDXN0cmVhbQ0KBZNKBB6n/b6s278lPsXNKLJx6Op79QdfXin6mZPKN+j/qmrfGsTTmA0L WW3rcCIuMtdz60VzdGgmtZ6ZrbbRD3iqTRhzfmmptDETtdW2MkqlHpjr4ajGDjaC2WjWKHNTQL8o 8IVIphXyRkvp4TlwPpfSw1zqZFXGcMVf+PzsKZSpAEzp1XQ68EgfJJPCObOMr+BKwpmjEamZ+MR4 0wb+Kqjz39zNeLQAovfupAM9MEzEKMdJmwy5bK8y+spFPupWbL4UEgK8FiCzIOP1y6kAsf+g4PNP adQ/8TstZTgKWLKr4Dh1CaquXqXGCBobFl1eFWrrq9y3aFGriPbhIt9JhBjfw2gSaoT6nXEt1LL6 TGUjDWVuZHN0cmVhbQ1lbmRvYmoNNDI2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvTmFtZSAvaW0yIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTE1IA0vSGVpZ2h0 IDI3IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDQy NyAwIFIgPj4gDXN0cmVhbQ0Kebk8jJ7eVlpcM+14rJzl4mS06Er/FJdBawym3TQFocuBMFQi5S8A nV6gJT4SxnKWAmhcxtqhbhAHy36zGxRYtgLXWAi113wXEd+z5wOx5+gG9SIy9EgQ5telQDCA87hN OjUBOSTcNrE7a4dRLwdQeWfkpr2yqvri8BAo9rcGDuXDY1atYfgbgwsyXN4/XsLTE0yulNnvYI7s ogf0FHX5J5qwnlTmsEZvi7OikTZZKsbCTxKw7VCJeX5DAT013LKzB1IOWGlxNM3bH25y1zmbv66p IFIFsKnschGBzw0sPIOgPl4Av8jGGa8B2CBpUiYE+KZ6/hGeNnZc8g8W1yBztcXDrJDaPyQGB4Wq N3xvgov6vrE/hHZar+rWgQ2N7W95n24xQyijNE0SmARUUGgPgwC7MwFVS9+/GpglN4yd4XbVPrSL U3mXtkEFwYxRzO2UNQPP7ZeXFVQJIL5kG9xGljL5PauJY7ugtUVRmb1LjzfLI37hTnkY4ywOyNCB b0YvX/qsUwFklPgCzf0UkXJDdjyqOMY+LcEz3b7FPY7pTb347ISZZCa/q/8tnJdvi/PZkfMkAWdj cCspxbjLHTc9/p5anyYutsSge1OL4bDNs4JAZmjHQazsuctoJvnGCSdH9yKLzugL0ffN6r6jkMCq G5hhCp9zaRXJg0QgFle1RlnVl35mnDrqIxGZEIwIQRaD+D+zux55e2AU1gZtlEMuXPRB2RGaZEG6 HC4v/8ZtxgF4iRvfSkpKpfcLZ8TFv9GE78iBCHURR7SlN9sCf029ow9dgVrgIBHYeJ8TItpGehGs yyAXcfuWhiXG5SGY7Uukp73HFIVj6spIcB9nJTIVwzksazvIMRujsyzsw8lpezm4JNf0I5fhtAgs 4WzF1CS1qGUnxPALts7cGyQBXk5SuivsojDwZbhY6k0q1HTnFiElTVliIZkN3stnAtO9MWCmuSXC bK+346omS+ni45hG3ZM9nnvcEl/p76VeD47n4r5Ar6eEaVt5cZ4ZA/UFnLSVdLwnFiRx/NZ/9SDq fKXsTooJXSAQcgteeZvo8UnSA0rag4SHio42x/Y40OTtiAZmSUwBpNI57I2gEcHhZY99tDN1/XUQ lAp57+ygMYSCjucdfrTxugGwMzcCmgh9BFyb0mc+y4r0sJqHmGKFs1+kDAG6ohKeKhtzW/bnv/e7 iE1wufqKQzcnky/myOhQwkvoXZ3vvw6P2QF+av6k/mTLIPYtvVzG9Peg9CTeSGDeJ+H4nEzoARjI kUroXMfUNNJ25RA7b5aF1knimYWB2CD/Z9Z3CWgwCIxoc153QI91LopoNpn2y77kR/x4XqffLPGC iRDEJ6Fb9+q4/8IbdqaTmZ8o7A2F62JssdSLDKDvuVMLt/CUDOjz/ntenwcDI95V2iN3wqm0Pb5Z n1bUVjySbUbiTObvUKfD35XVYNwDZx1Ag7LNHGadCZ6J9I39kHbBrz2bw15XJzEbP8jKvCCkd8LO ZqnmMgg21J4YPgy+2g61KrUgmus3+w11pAjQG7518hW0uZB/0CCjwcRH8AUGC4IZJmtDUl7Xx3RW aP4RsJqyD5q2tWxyC6bkXdIjHkoJ/wzPKst/AVfpWr6txy+8FnZLJLzssiBZGv9u3l0ld3V7/Mio mCpG5a16iIbHI/tkIVSTPWj205JpEsxU6OtuQ1AtjZaiBidvY656SnmXWBPKg3tvkk65LHPUQhD4 b8m+/HOp9qqeiEpEWVcLAYSoanKy/4hpgurnBoEk2LpfWvC53CKLA2P0OQOXY1TKLGkjb5+1/X+i ExyIqTQUwKq05AJrtXVebcT6Hn22/GidaWpmfixiWdlJxptjA933rnSysTEh2WEPv5QFxVx+VR8u iyll2mduX+ZYaFj8vDNkTj4oRMKkkEbnfoZt6xLh/nyZB+pGkoyeowQOBAAW5+wbPFMTgY9/vo38 LK63CAiA9hI2zFaimmhLjTbsV/m2XMX5LwIEY+WgHNvUlgSvkLdUsyGiFXJbKmWndlfX+IVgeDlB xs1O51QkyGWcl6PmyHtyf+AxyYckKE0tLnd9nc7N0uM3NKoBN0OwTGFWgxY/syLsQH4zLtjEQXbq bRcigXAYeG3ZqsoiJsIDLq2owoCOAIe5KslXvcSWY7BaKzgk17sLcvlXvhoEPjmTpfe2sj5n4+Ez MP+rFjOz/IXS6bMoBFvJl+Cbv1NynJfd748NMOpQqog+d91QhDpWVP4YZQgjobjS+DLV712ZSnIH bBQkbakvThdYCR12kMWVo34mtpniLoVDfmHLCVHFMekk3cXW1NX+p/l3rzLnIwixA7YYRCPzgH0T 3UXwW0Qkkt1RU5g3+uf5OzlPwgYvzNRzrfCEYKy2AnB4uWov9Bio6g5JFn7h1FbDndUVF+2YhFsV tqJ3/5SoH1EkY+lLVptZev1Ok1NYCA84FeoYbVP4n4y5xQvqPSf776Fg68190Z49dWqk7V99G70B bStezoXmZ8YAQejF1PrTvXsLBKOGa9q+CzDt0pq7Igs54GG+d0grjZ4ne8UEEwQnZeMfgVk/DopC dTok1N4JXoEO2oR7uEl6gEIdHPQh8bFTxSEgsCj/vfZZ4ien138SrtfcmHvQdRmK6EJQeS8bwZXq Bfrj7U8nhBdSPngj6Q7OOF5IyLcml+lKwkglLCW5roufIJZTcPU1sJ410SRh+dNIMHBV3Cn4yO34 XStG9nKYA4XQfvAknv4qIays1izy7+OaJBtVEEvoxDzlwRq2LZ3YP8Mzod4R26siA6Fy/sAE14nC lCkda7r6FAlgnJCyqCNhanWM/EvP9EeyoEVHmPUoIaDrth1YseU4RgnH3AYX1oR2r/Pw+JreuRO2 8WFvbEdZyTJ3GaMBSngHo6xOrMEW1mb8xIas1zQB6hrJkRxba09psf0IdYpO3PjeGyMJ6foKHlCV elT11C4gWWqnKWVytMkzlf9n3kBz3iUCovQeJR1IT0m1VSgSa6BMh/+x/pyseMkov5a2kmWY9IQH fUjMOIVu43hfnlv3VksqK0ktCg1yYyPug+P0e7lHzz5Q9ZtdvDWu0zh6atgwIhIedZ0CKalS4cah 5fVw1x/JAehI3gaLs5pvwByarYg4ZDdVGiw2bySTrQ4PqHwxEPr6fm4n8iBfMZrNcjjxUJuaeqd4 AeUcibWQ2p3lk6qqce/8dnyFQazN/G1nQc4e+2tydqe8VeIggYo8W+l6dmK0vSmIuNLTW3TwyJ+x P8aFloKjg4DtfY3FYza7q2CofyUsEPwaI8b0d3l1sWRQ8Lud6l9YMANQWdxMDRdPtcMF8zzSzC3M Q/hdZVY8nX7mVuorAUUi/NZ9fSDL3ENpfROxsWT5Xt0JsyXuerraPhG2fgJlDrxV/r1MITfaGKMX fjUe9piUnVxB+e4XeVP9vbcNXMsqGmEeJ7CQiBthWkTcacr2Pb6aV8kcavN6lchpxq10xMYMHwUu m6zNuriTYtsEvd0xHX9ukSyOJpZr3S4LxPtKM8If9klOTd2IXExFyefr4eMh3yWDNIXqhCRN6DW9 X6C3RA38niEh598bgBsd4rNUX9p7cJ+iwVuENLb+WDyi3LkI/O+SLPx0Ggd0E+MV70O0b/7C0Dye AZ3QRyzamVwmNE+Yp8t2oB7lcNV8sOV0WSCyxun52MTr10y+IAiFeY42ItAMGPBv6+eGF4pshByv sb3vh3eFFOULoFvexJXk0KYa2i0rQv/CNPiEDXVap1KUsroxuE0NZtqZBpsf68XWIp1FrYxLJgmu RW4Gi4fOYuqa1swAoUqFF29GBn/Yy1DwCwi9fZkFZVztsQ47OLeG5lCegsS3yYdt68zQynI2xcm5 7gMxzoTFrhE9UZi8EwREjS0DkKnvLtBC1npqQqZAZl4HTCAJugrxXigifQJRDTKSEhhv39ATLBE/ FGTG+NIRk8kcuWZ10upJfw7bXdTt8JeUPNf0wqoF6O8ywYo4IYOctzybDziYZATF4wOQJIuKRBQp +ixk6OG6M8s2g8pOVcsivHcjIP88IGVwvvrClIlXrFSDkvZFs5LMUG1BJCERTMj/sOn5dQknCg70 MeeQ1FpUCw7pZrKZgFGetrz4/V3zu9HDQh8Yd3Vuz09WMqfg0OzC6VB40vx+AD7+ekPDjBXx9wtI H5hyKWO9xYmBkqTYD2/hlOIe9hoHrCBLK5M1n3yEng6Zj7Rl2KhtB1FTqRBnfXMll6DT4EfjR2Y1 jVM/XXqsSfXo9KEaeCBVZTV2fDJLLd7rJypW+E2Rf+y3dAKHI8MRJeU6FotlR4jey4ovHP6K6SSU BRP7WzREXSvl6yzrftNaVE9/En51AZTOyfyfRASpUijvLzCbbxQB+B/02yD4taH84g/s/Ew9KamA EdkGtzzZe1gvDwiCZNWwfORlqT9JsVB4OsmojpJghEgetlCW3RhFW+TizeUnFPGPk7mf1fsyH/Er 3hX3Gbwtz3Q8aWbyXszOcUdjug9I5HgCvrIVk/+En+16ielk4VOHGptEdwl1fJfr3XBKs1H4xsKs gMvMVDLEcSoRga6KCwC34R7vQMNHiK2D7qMpj4YDlFyZnRvKjo9p6P3bEcs+Ysn08tcsK3hVYtay ZTiF3v1f2969SrIre+vDXKrhDoYZURuBEUm3B7HciHtBp2U9sXTaLTSCldVKVPCe+wUm8yjI5lLQ fKrDMkIU39tSDTGKH95l93I2rgzDelVgW9AAvwDjgSeOLW2DPHAGaW84Sz+yLI5wVBm0eaCfyNfI NAWTxdb+hGQSglq6XunrdRI8psdFktVDunpUfqkUJtS/IsJasqUC8qFr/ZbAlQx8Uux9n4LSa0GS j/IKVPpSORc1NZfJy2AOKUiIMsrLi1BtiHptSXdPOaVAeYLapj14SDwfXi/kBlnsNjMvo9OBz1C4 24jVlO31nuCbcgx1q57krhPywxZG6qSc97kdRrIVEcYrBQ6+LTpKEsI5ALCVeZzfrK/6Ib9vC9rS pr4AnfHHPqGnVVWuPTW1/vU1xpDm1wHX/6eaREG4BOdTZdb3OM1P6iKfKR3z5Vw1NryrGhMl4NEa L2xt4W/0ikAPOabfLUgUL9qF3Sh2YemHEo5nPMz1lUAFr46fyUGBS/XBCLAq6dDl+uS5mf0IUMDc uM2LiwrGhsmS01CZV0bnqmov/DCRmQ8yXPXTKTDkFXpnXl87Xl6mPc/UMbvDiH6PrLq2nFAFma9R bwh6U9a7aea4gAItP31U4FeiBWjQSSSm/OAMv66OW6XjztgjnPSQCiW2/TlFtj2JMD29aCNY4hok d8rZDWVuZHN0cmVhbQ1lbmRvYmoNNDI3IDAgb2JqDTM5NzUgDWVuZG9iag00MjggMCBvYmoNPDwg DS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9OYW1lIC9GMiANL0Jhc2VGb250IC9U aW1lc05ld1JvbWFuIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMjU1IA0vV2lkdGhzIFsgMjYw IDMwNCAzOTEgNTAwIDUwMCA4MjYgNzgyIDE3MyAzMjYgMzI2IDQ1NiA1NjUgMjYwIDMyNiAyNjAg MjgyIDUwMCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjYwIDI4MiA1NjUg NTY1IDU2NSA0MzQgOTEzIA02OTUgNjUyIDY3MyA3MTcgNjA4IDU2NSA3MTcgNzE3IDMyNiAzOTEg NzE3IDYwOCA4OTEgNzE3IDcxNyA1NjUgDTcxNyA2NzMgNTY1IDYzMCA2OTUgNjk1IDkzNCA3MTcg Njk1IDYwOCAzMjYgMjYwIDMyNiA0NzggNTAwIDMyNiANNDU2IDUwMCA0MzQgNDc4IDQxMyAzMjYg NDc4IDQ3OCAyNjAgMjYwIDQ3OCAyNjAgNzM5IDQ3OCA0NzggNTAwIA00NzggMzQ3IDM5MSAyODIg NTAwIDQ3OCA2OTUgNTAwIDQ3OCA0MzQgNDc4IDE3MyA0NzggNTQzIDc4MiA1NjUgDTc4MiA1NjUg NTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUgNTY1IDc4MiA1NjUgNzgyIDc4MiAN NTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUgNzgyIDU2NSA1 NjUgMjYwIA0zMDQgNDc4IDUwMCA1MDAgNTAwIDE3MyA1MDAgMzA0IDc2MCAyODIgNDc4IDU2NSAz MjYgNzYwIDUwMCAzOTEgDTU0MyAzMDQgMzA0IDI4MiA1ODYgNDM0IDI2MCAzMDQgMzA0IDMwNCA0 NzggNzM5IDc2MCA3NjAgNDM0IDY5NSANNjk1IDY5NSA2OTUgNjk1IDY5NSA5MTMgNjczIDYwOCA2 MDggNjA4IDYwOCAzMjYgMzI2IDMyNiAzMjYgNzE3IA03MTcgNzE3IDcxNyA3MTcgNzE3IDcxNyA1 NjUgNzE3IDY5NSA2OTUgNjk1IDY5NSA2OTUgNTY1IDUwMCA0NTYgDTQ1NiA0NTYgNDU2IDQ1NiA0 NTYgNjUyIDQzNCA0MTMgNDEzIDQxMyA0MTMgMjYwIDI2MCAyNjAgMjYwIDUwMCANNDc4IDQ3OCA0 NzggNDc4IDQ3OCA0NzggNTQzIDUwMCA1MDAgNTAwIDUwMCA1MDAgNDc4IDUyMSA0NzggXSANL0Vu Y29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9Gb250RGVzY3JpcHRvciA0MjkgMCBSIA0+PiANZW5k b2JqDTQyOSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vRm9udE5hbWUgL1RpbWVz TmV3Um9tYW4gDS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTI1MCAtMjE2IDExMjIgMTA0MCBdIA0v TWlzc2luZ1dpZHRoIDMyNiANL1N0ZW1WIDczIA0vU3RlbUggNzMgDS9JdGFsaWNBbmdsZSAwIA0v Q2FwSGVpZ2h0IDg5MSANL1hIZWlnaHQgNDQ2IA0vQXNjZW50IDg5MSANL0Rlc2NlbnQgLTIxNiAN L0xlYWRpbmcgMTQ5IA0vTWF4V2lkdGggOTM1IA0vQXZnV2lkdGggNDAxIA0+PiANZW5kb2JqDTQz MCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL05hbWUgL0YzIA0v QmFzZUZvbnQgL0NvdXJpZXJOZXcgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTUgDS9XaWR0 aHMgWyA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSAN NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0ZvbnREZXNjcmlwdG9yIDQzMSAwIFIg DT4+IA1lbmRvYmoNNDMxIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Gb250TmFt ZSAvQ291cmllck5ldyANL0ZsYWdzIDM0IA0vRm9udEJCb3ggWyAtMjUwIC0zMDAgNzI2IDEwMDAg XSANL01pc3NpbmdXaWR0aCA2MDUgDS9TdGVtViAxMDkgDS9TdGVtSCAxMDkgDS9JdGFsaWNBbmds ZSAwIA0vQ2FwSGVpZ2h0IDgzMyANL1hIZWlnaHQgNDE3IA0vQXNjZW50IDgzMyANL0Rlc2NlbnQg LTMwMCANL0xlYWRpbmcgMTMzIA0vTWF4V2lkdGggNjA1IA0vQXZnV2lkdGggNjAwIA0+PiANZW5k b2JqDTQzMiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL05hbWUg L0Y0IA0vQmFzZUZvbnQgL0NvdXJpZXJOZXcsQm9sZCANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFy IDI1NSANL1dpZHRocyBbIDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1 IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1 IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1 IDYwNSA2MDUgNjA1IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vRm9udERlc2NyaXB0 b3IgNDMzIDAgUiANPj4gDWVuZG9iag00MzMgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRv ciANL0ZvbnROYW1lIC9Db3VyaWVyTmV3LEJvbGQgDS9GbGFncyAxNjQxOCANL0ZvbnRCQm94IFsg LTI1MCAtMzAwIDcyNiAxMDAwIF0gDS9NaXNzaW5nV2lkdGggNjA1IA0vU3RlbVYgMTkxIA0vU3Rl bUggMTkxIA0vSXRhbGljQW5nbGUgMCANL0NhcEhlaWdodCA4MzMgDS9YSGVpZ2h0IDQxNyANL0Fz Y2VudCA4MzMgDS9EZXNjZW50IC0zMDAgDS9MZWFkaW5nIDEzMyANL01heFdpZHRoIDYwNSANL0F2 Z1dpZHRoIDYwMCANPj4gDWVuZG9iag00MzQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCA0MzUgMCBSID4+IA1zdHJlYW0NCjajrDHJGIrjjoeWNbSQu3p2VezCmU68nFQ0XhIy Kjc90cc5Fv5XueSZnrr4LG4YZ32Q4hitNS2x6cmpyAtUckJaPlJCuhX8ocwcKnCDCoUqeTvwflab YcOZfL80LkNVkM5HTQKzqAMS59pEl0h4EZiFP+grx91WE6CSjCA6S2Z65flouThkVVAD81N2Ia+5 vZUUESbQ8TBDJMr+sX/vF+5JRj8vC3fcOgNgXYld2DIObjDpWfKxY+kze1wnALiTbRvz1iLzDicQ /KixgBLB2thXK90Fck94BwqOIrAZKGQGQwKFxiHiJCTBsnY3fBX1s746ein5NABS/b85Fvfq7bfN ySRSLgF3h6vVyIPirrokTzc/Uol9Zb+7qDRTCv0XAoE5iA3Bq6y4KhSGjbYZYWjp6HVaivmMnIdQ TxFCgY8a4/OumXE83q5PpOz5MAwk6MI5UZat7Z1L8cSRO0YyzzcKylY66blTBPNs09AhnCrJMpvh A5EjB0eLYkpfIC6OqsWJxfG//Z7CG6O7ql1MYvUJ7CV5l3hKwf09u/4iYQJvyqLvnRyDIDV5GtbT 5hMgxhQMlLHLfKAXgi3/IFp98NDUnNABCJVpNyWLEx610fvgm9HWkWNrWDu4nTo/TA+b83EvUsQV 5ULlXAswSX1/jDUUDec8K/5A6200yvvAjeh5YqFeK+t9wrXrBg03jgz9eFgnGI7kMdecYm3xMl1X GUaqNKR7/qft7r+ZLx+hRbcPdF58eXuASkHCFoF70hdtDh+AbMA8k6rjP0ppSY+wfuyq2ibcVt3Y Pv1/oUai//sJaZvEggEDWcpJFZiTcDdxufSMIWk+YnuOFHq0I+XspXFLDS9U+6P6mTGpYmZcjfa1 ln9f86oMZDVeYqSrbwjDR/kJmPbO+WYv8XnTc0iW0kF4KlqlMEuySA7JWin8aITXUG16bKlLqr1M 8mR4ZxHqtezaYKQGtGSn8gJBLgJi29noQY+PQ4sK2odRk9VFLxH6JgzQUMRxKWHlk4k5/WqgpifV U/fCKZiwKf+RxzQsEgYx6sAbHw1LUGEIWvGOZGDv8YLQQKXh/h2+PgOvJVfN/NJJDEXB9NyP2S2z aDKy4agBdB/Ykk4Bp3x4z9ck3cDGbqJjN+6Ha3nrKSmaOhtxpi3VQWS9vvPBdrtR7AABWJCg39+c s1tnpOswHf2SfpMYmWqz9iSZDIYsP79NUDwd7qRpUEEsIhTYIOALReA2oy272UpsO+5RSWEcr/cK 58Wy+otfcZlmrb18KANiww59Ha8gYew+8TyHbUy2T+uDONOazyDjpclpmUjRyGptTftdLfFtIxHK tzLzIlaheVESaBS/ELQVO1ZVrEXHjWCGnlsm+XYvthgCCr7GzI+fVlsttM8bW8FKqWTR0b6Hgw8O W6POLARfZdB8G06rw/eWRKv3EgtsDPreL+CJO0ba0M5Ioq1KjtM90PNno31WNjGxH2B6Xx8RXjh5 YSfDokYefSJrR2j0WVdCy3b/y+T6yrLwkESxJ5u3CcrwQQ/PwvWsOBeBWa55f8otBEEERcZAZM+r U1B9TI4pqCT+Li1dP97xgtXBMzjMZXPtg/J31gALhAzBzWAdknDPZeW2tQKsQFbNc3iDkIdTgBO6 kVIYi6wwizVUUVGT0oyrBmf3y83J68zzxW1g+GE8C+SAHpZ1VmDgfaI/qJbLOtGxcsb0ks0gcCY3 xJVuuykLLkbL4W7gLxAO7N6kxVPNEsihUDpOgej+FsWjIcG701uovxC463WBlax75EyuTWfgtq4O DWLyLVI+i0WxlbARUsbyEh4CpVQ3x3QMqVyuDT+Sta1t0nc+LhAzNstfU1uCb7i5tcJ+dqiEI/im i8YvSMl5wsClv/G3FaSfXWrG+501KgXvaVaDMjZQi3mh3RNow10Qp0XVRm9JElsDclgqP9jYgAxk bLnX5V2T9rmQmNWPRHQA6NROA1gjvdsXhicDN320Lr77XWu+rW+iFYXLe+MYV/hP8oz6ICV/m2C7 r+eV1o55V1yG8KoQdMyueMX/HvqVrEesYuhfoMDyY1GCucVK/EImm8mIOTXdTCpZ3SiaTZwkNFM4 O6o1Ehu7MAisEVtmCufSwW7H3m2n+f06LRxtoB+Guej2dWsfY0WvLzy7DlybPPHR3jDgVho6XBXp Oi0BZc5CTbNOXUdRQpvKb5RH1yzBy9XdOHpbgtixtIhZEyPDwfeaMjpiLTWg6ZWBrU+Rq+v6JyDr 7gR+2D5u6WqlyLxlLvelxzqu4zpkEJuTJyPv/3ygMt1SOpaUA7RmqiLqhEyDNmEam02+6rXcf06F MHwpJBRPKFbSL4tGOY2xuofkLJM7XExnHUkhLY0ywBbONXFEX06q5A/oxzFpLAO11KB9GJumtDMh uHhtPA7fX9ZCePWjJNGbyWT57pyICPANyi69Wan2A18gXq5I0LjGFWBs4EIPYR2/LMR8SJg+cTow 0kf1eMjb7px+BQheMu+WiIcsSpaO93PFhuOtIj6VLIfx0muhwFqVcjslLUDRnBT0fX9iARQWKEG2 9XJbTIghv5vMQ/cU651OeFYuWVM4REAx/V7I8ext+F+K6PKFP6fRdjX6vBsW72hNuA1z3SzzIwTM NxMbBMD9S7WoQ+8QiPjZ3Xn9bd9s3gwAwCG8mSt5H+a9bekRXgH5WYp7o1BvEhbGaDEt0PLxtEpT 2QvS2oqOsdDLdjl6dGU1eEwJR1JXO6z51oGBF3vuQ5LFfqzQpPJJauIgBsPIBsg2kQZ1KWNjb7K0 DOOKk4SEYlfofRLl5g1lbmRzdHJlYW0NZW5kb2JqDTQzNSAwIG9iag0yMDk0IA1lbmRvYmoNNDM2 IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNDM3IDAgUiA+PiANc3RyZWFt DQolRrAvSi6H8jSq2fObrw1lbmRzdHJlYW0NZW5kb2JqDTQzNyAwIG9iag0xNCANZW5kb2JqDTQz OCAwIG9iag08PCANL0NyZWF0b3IgKHJ5tf1cKZEYTUOWDAz7+zTac6szTH+cuF2VEjTbqO2FsOOn XHJCMOwj5ZCzsPaZ6ug7FQ8x9/z0Ej4pDS9DcmVhdGlvbkRhdGUgKHsq5L9200cZBoNqWryvJMcp DS9UaXRsZSAodn6i6jSNB05F1zlcbuX2YI5ztjhLbs6URIMDOpSL9IKt6uIrCRPcRSkNL0F1dGhv ciAoVXG34SkNL1Byb2R1Y2VyICh+c6TgJIMDC2fyHTT79mCSIcJuFirc912REjSZluiCoPXwKgdc cswpDS9LZXl3b3JkcyAoKQ0vU3ViamVjdCAoKQ0vTW9kRGF0ZSAoeyrkv3bTRxkGg2pavKkhxykN Pj4gDWVuZG9iag00MzkgMCBvYmoNPDwgDS9LaWRzIFsgNDQ4IDAgUiAxIDAgUiA3IDAgUiAxMyAw IFIgMTkgMCBSIDI1IDAgUiBdIA0vQ291bnQgNiANL1R5cGUgL1BhZ2VzIA0vUGFyZW50IDQ0NCAw IFIgDT4+IA1lbmRvYmoNNDQwIDAgb2JqDTw8IA0vS2lkcyBbIDMwMCAwIFIgMzA2IDAgUiAzMTIg MCBSIDMxOCAwIFIgMzI0IDAgUiAzMzAgMCBSIF0gDS9Db3VudCA2IA0vVHlwZSAvUGFnZXMgDS9Q YXJlbnQgNDQ0IDAgUiANPj4gDWVuZG9iag00NDEgMCBvYmoNPDwgDS9LaWRzIFsgMzM2IDAgUiAz NDIgMCBSIDM0OCAwIFIgMzU0IDAgUiAzNjAgMCBSIDM2NiAwIFIgXSANL0NvdW50IDYgDS9UeXBl IC9QYWdlcyANL1BhcmVudCA0NDQgMCBSIA0+PiANZW5kb2JqDTQ0MiAwIG9iag08PCANL0tpZHMg WyAzNzIgMCBSIDM3OCAwIFIgMzg0IDAgUiAzOTAgMCBSIDM5NiAwIFIgNDAyIDAgUiBdIA0vQ291 bnQgNiANL1R5cGUgL1BhZ2VzIA0vUGFyZW50IDQ0NCAwIFIgDT4+IA1lbmRvYmoNNDQzIDAgb2Jq DTw8IA0vS2lkcyBbIDQwOCAwIFIgNDE0IDAgUiA0MjAgMCBSIF0gDS9Db3VudCAzIA0vVHlwZSAv UGFnZXMgDS9QYXJlbnQgNDQ0IDAgUiANPj4gDWVuZG9iag00NDQgMCBvYmoNPDwgDS9LaWRzIFsg NDM5IDAgUiA0NDAgMCBSIDQ0MSAwIFIgNDQyIDAgUiA0NDMgMCBSIF0gDS9Db3VudCAyNyANL1R5 cGUgL1BhZ2VzIA0+PiANZW5kb2JqDXhyZWYNMCA0NDUgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDA0MDA3MSAwMDAwMCBuDQowMDAwMDQwMzA0IDAwMDAwIG4NCjAwMDAwNDAzNTMgMDAwMDAgbg0K MDAwMDA0MDM3MyAwMDAwMCBuDQowMDAwMDQwODAwIDAwMDAwIG4NCjAwMDAwNDA4MjAgMDAwMDAg bg0KMDAwMDA0MTg2OCAwMDAwMCBuDQowMDAwMDQyMTAxIDAwMDAwIG4NCjAwMDAwNDIxNTIgMDAw MDAgbg0KMDAwMDA0MjE3MiAwMDAwMCBuDQowMDAwMDQyNjAwIDAwMDAwIG4NCjAwMDAwNDI2MjEg MDAwMDAgbg0KMDAwMDA0MzI3MiAwMDAwMCBuDQowMDAwMDQzNTA3IDAwMDAwIG4NCjAwMDAwNDM1 NTkgMDAwMDAgbg0KMDAwMDA0MzU4MCAwMDAwMCBuDQowMDAwMDQ0MDA5IDAwMDAwIG4NCjAwMDAw NDQwMzEgMDAwMDAgbg0KMDAwMDA0NTI2NCAwMDAwMCBuDQowMDAwMDQ1NTEyIDAwMDAwIG4NCjAw MDAwNDU1NjQgMDAwMDAgbg0KMDAwMDA0NTU4NSAwMDAwMCBuDQowMDAwMDQ2MDEzIDAwMDAwIG4N CjAwMDAwNDYwMzQgMDAwMDAgbg0KMDAwMDA0NjYxMiAwMDAwMCBuDQowMDAwMDQ2ODQ3IDAwMDAw IG4NCjAwMDAwNDc4ODcgMDAwMDAgbg0KMDAwMDA0ODQ0OSAwMDAwMCBuDQowMDAwMDQ4NDcwIDAw MDAwIG4NCjAwMDAwNDg4OTkgMDAwMDAgbg0KMDAwMDA0ODkyMCAwMDAwMCBuDQowMDAwMDQ5NzAw IDAwMDAwIG4NCjAwMDAwNDk3MjAgMDAwMDAgbg0KMDAwMDA0OTg0OSAwMDAwMCBuDQowMDAwMDQ5 ODY5IDAwMDAwIG4NCjAwMDAwNDk5OTkgMDAwMDAgbg0KMDAwMDA1MDAxOSAwMDAwMCBuDQowMDAw MDUwMTUxIDAwMDAwIG4NCjAwMDAwNTAxNzEgMDAwMDAgbg0KMDAwMDA1MDMwMSAwMDAwMCBuDQow MDAwMDUwMzIxIDAwMDAwIG4NCjAwMDAwNTA0NTIgMDAwMDAgbg0KMDAwMDA1MDQ3MiAwMDAwMCBu DQowMDAwMDUwNjA1IDAwMDAwIG4NCjAwMDAwNTA2MjUgMDAwMDAgbg0KMDAwMDA1MDc1NCAwMDAw MCBuDQowMDAwMDUwNzc0IDAwMDAwIG4NCjAwMDAwNTA5MDUgMDAwMDAgbg0KMDAwMDA1MDkyNSAw MDAwMCBuDQowMDAwMDUxMDU1IDAwMDAwIG4NCjAwMDAwNTEwNzUgMDAwMDAgbg0KMDAwMDA1MTIw NSAwMDAwMCBuDQowMDAwMDUxMjI1IDAwMDAwIG4NCjAwMDAwNTEzNTggMDAwMDAgbg0KMDAwMDA1 MTM3OCAwMDAwMCBuDQowMDAwMDUxNTEwIDAwMDAwIG4NCjAwMDAwNTE1MzAgMDAwMDAgbg0KMDAw MDA1MTY1OSAwMDAwMCBuDQowMDAwMDUxNjc5IDAwMDAwIG4NCjAwMDAwNTE4MTEgMDAwMDAgbg0K MDAwMDA1MTgzMSAwMDAwMCBuDQowMDAwMDUxOTY0IDAwMDAwIG4NCjAwMDAwNTE5ODQgMDAwMDAg bg0KMDAwMDA1MjExNiAwMDAwMCBuDQowMDAwMDUyMTM2IDAwMDAwIG4NCjAwMDAwNTIyNjggMDAw MDAgbg0KMDAwMDA1MjI4OCAwMDAwMCBuDQowMDAwMDUyNDE4IDAwMDAwIG4NCjAwMDAwNTI0Mzgg MDAwMDAgbg0KMDAwMDA1MjU3MSAwMDAwMCBuDQowMDAwMDUyNTkxIDAwMDAwIG4NCjAwMDAwNTI3 MjQgMDAwMDAgbg0KMDAwMDA1Mjc0NCAwMDAwMCBuDQowMDAwMDUyODc2IDAwMDAwIG4NCjAwMDAw NTI4OTYgMDAwMDAgbg0KMDAwMDA1MzAyOSAwMDAwMCBuDQowMDAwMDUzMDQ5IDAwMDAwIG4NCjAw MDAwNTMxODEgMDAwMDAgbg0KMDAwMDA1MzIwMSAwMDAwMCBuDQowMDAwMDUzMzMyIDAwMDAwIG4N CjAwMDAwNTMzNTIgMDAwMDAgbg0KMDAwMDA1MzQ4MyAwMDAwMCBuDQowMDAwMDUzNTAzIDAwMDAw IG4NCjAwMDAwNTM2MzQgMDAwMDAgbg0KMDAwMDA1MzY1NCAwMDAwMCBuDQowMDAwMDUzNzg2IDAw MDAwIG4NCjAwMDAwNTM4MDYgMDAwMDAgbg0KMDAwMDA1MzkzNyAwMDAwMCBuDQowMDAwMDUzOTU3 IDAwMDAwIG4NCjAwMDAwNTQwODUgMDAwMDAgbg0KMDAwMDA1NDEwNSAwMDAwMCBuDQowMDAwMDU0 MjMzIDAwMDAwIG4NCjAwMDAwNTQyNTMgMDAwMDAgbg0KMDAwMDA1NDM4MyAwMDAwMCBuDQowMDAw MDU0NDAzIDAwMDAwIG4NCjAwMDAwNTQ1MzQgMDAwMDAgbg0KMDAwMDA1NDU1NCAwMDAwMCBuDQow MDAwMDU0NjgyIDAwMDAwIG4NCjAwMDAwNTQ3MDIgMDAwMDAgbg0KMDAwMDA1NDgzMSAwMDAwMCBu DQowMDAwMDU0ODUyIDAwMDAwIG4NCjAwMDAwNTQ5ODUgMDAwMDAgbg0KMDAwMDA1NTAwNiAwMDAw MCBuDQowMDAwMDU1MTM5IDAwMDAwIG4NCjAwMDAwNTUxNjAgMDAwMDAgbg0KMDAwMDA1NTI5NSAw MDAwMCBuDQowMDAwMDU1MzE2IDAwMDAwIG4NCjAwMDAwNTU0NDYgMDAwMDAgbg0KMDAwMDA1NTQ2 NyAwMDAwMCBuDQowMDAwMDU1NjAxIDAwMDAwIG4NCjAwMDAwNTU2MjIgMDAwMDAgbg0KMDAwMDA1 NTc1NyAwMDAwMCBuDQowMDAwMDU1Nzc4IDAwMDAwIG4NCjAwMDAwNTU5MTMgMDAwMDAgbg0KMDAw MDA1NTkzNCAwMDAwMCBuDQowMDAwMDU2MDY3IDAwMDAwIG4NCjAwMDAwNTYwODggMDAwMDAgbg0K MDAwMDA1NjIyMiAwMDAwMCBuDQowMDAwMDU2MjQzIDAwMDAwIG4NCjAwMDAwNTYzNzQgMDAwMDAg bg0KMDAwMDA1NjM5NSAwMDAwMCBuDQowMDAwMDU2NTI2IDAwMDAwIG4NCjAwMDAwNTY1NDcgMDAw MDAgbg0KMDAwMDA1NjY4MiAwMDAwMCBuDQowMDAwMDU2NzAzIDAwMDAwIG4NCjAwMDAwNTY4MzYg MDAwMDAgbg0KMDAwMDA1Njg1NyAwMDAwMCBuDQowMDAwMDU2OTg5IDAwMDAwIG4NCjAwMDAwNTcw MTAgMDAwMDAgbg0KMDAwMDA1NzE0NCAwMDAwMCBuDQowMDAwMDU3MTY1IDAwMDAwIG4NCjAwMDAw NTcyOTkgMDAwMDAgbg0KMDAwMDA1NzMyMCAwMDAwMCBuDQowMDAwMDU3NDU0IDAwMDAwIG4NCjAw MDAwNTc0NzUgMDAwMDAgbg0KMDAwMDA1NzYxMCAwMDAwMCBuDQowMDAwMDU3NjMxIDAwMDAwIG4N CjAwMDAwNTc3NjMgMDAwMDAgbg0KMDAwMDA1Nzc4NCAwMDAwMCBuDQowMDAwMDU3OTE0IDAwMDAw IG4NCjAwMDAwNTc5MzUgMDAwMDAgbg0KMDAwMDA1ODA2OSAwMDAwMCBuDQowMDAwMDU4MDkwIDAw MDAwIG4NCjAwMDAwNTgyMjMgMDAwMDAgbg0KMDAwMDA1ODI0NCAwMDAwMCBuDQowMDAwMDU4Mzc5 IDAwMDAwIG4NCjAwMDAwNTg0MDAgMDAwMDAgbg0KMDAwMDA1ODUzNSAwMDAwMCBuDQowMDAwMDU4 NTU2IDAwMDAwIG4NCjAwMDAwNTg2OTAgMDAwMDAgbg0KMDAwMDA1ODcxMSAwMDAwMCBuDQowMDAw MDU4ODQyIDAwMDAwIG4NCjAwMDAwNTg4NjMgMDAwMDAgbg0KMDAwMDA1ODk5OCAwMDAwMCBuDQow MDAwMDU5MDE5IDAwMDAwIG4NCjAwMDAwNTkxNDkgMDAwMDAgbg0KMDAwMDA1OTE3MCAwMDAwMCBu DQowMDAwMDU5MzA0IDAwMDAwIG4NCjAwMDAwNTkzMjUgMDAwMDAgbg0KMDAwMDA1OTQ1NiAwMDAw MCBuDQowMDAwMDU5NDc3IDAwMDAwIG4NCjAwMDAwNTk2MDkgMDAwMDAgbg0KMDAwMDA1OTYzMCAw MDAwMCBuDQowMDAwMDU5NzY0IDAwMDAwIG4NCjAwMDAwNTk3ODcgMDAwMDAgbg0KMDAwMDA2MzA4 MiAwMDAwMCBuDQowMDAwMDYzMTA0IDAwMDAwIG4NCjAwMDAwNjM2NDQgMDAwMDAgbg0KMDAwMDA2 MzY2NiAwMDAwMCBuDQowMDAwMDY0MjkzIDAwMDAwIG4NCjAwMDAwNjQzMTUgMDAwMDAgbg0KMDAw MDA2NDk1MiAwMDAwMCBuDQowMDAwMDY0OTc0IDAwMDAwIG4NCjAwMDAwNjU1ODAgMDAwMDAgbg0K MDAwMDA2NTYwMiAwMDAwMCBuDQowMDAwMDY2MjMxIDAwMDAwIG4NCjAwMDAwNjYyNTMgMDAwMDAg bg0KMDAwMDA2Njg4MSAwMDAwMCBuDQowMDAwMDY2OTAzIDAwMDAwIG4NCjAwMDAwNjc2MTMgMDAw MDAgbg0KMDAwMDA2NzYzNSAwMDAwMCBuDQowMDAwMDY4Mzc3IDAwMDAwIG4NCjAwMDAwNjgzOTkg MDAwMDAgbg0KMDAwMDA2OTExMCAwMDAwMCBuDQowMDAwMDY5MTMyIDAwMDAwIG4NCjAwMDAwNjk4 NjggMDAwMDAgbg0KMDAwMDA2OTg5MCAwMDAwMCBuDQowMDAwMDcwNTA2IDAwMDAwIG4NCjAwMDAw NzA1MjggMDAwMDAgbg0KMDAwMDA3MTM1MCAwMDAwMCBuDQowMDAwMDcxMzcyIDAwMDAwIG4NCjAw MDAwNzIyMTEgMDAwMDAgbg0KMDAwMDA3MjIzMyAwMDAwMCBuDQowMDAwMDczMDc4IDAwMDAwIG4N CjAwMDAwNzMxMDAgMDAwMDAgbg0KMDAwMDA3Mzg5NyAwMDAwMCBuDQowMDAwMDczOTE5IDAwMDAw IG4NCjAwMDAwNzQ3NTggMDAwMDAgbg0KMDAwMDA3NDc4MCAwMDAwMCBuDQowMDAwMDc1NTg1IDAw MDAwIG4NCjAwMDAwNzU2MDcgMDAwMDAgbg0KMDAwMDA3NjQ3NyAwMDAwMCBuDQowMDAwMDc2NDk5 IDAwMDAwIG4NCjAwMDAwNzczMTcgMDAwMDAgbg0KMDAwMDA3NzMzOSAwMDAwMCBuDQowMDAwMDc4 MTYwIDAwMDAwIG4NCjAwMDAwNzgxODIgMDAwMDAgbg0KMDAwMDA3OTAyMCAwMDAwMCBuDQowMDAw MDc5MDQyIDAwMDAwIG4NCjAwMDAwNzk5NzIgMDAwMDAgbg0KMDAwMDA3OTk5NCAwMDAwMCBuDQow MDAwMDgwODg1IDAwMDAwIG4NCjAwMDAwODA5MDcgMDAwMDAgbg0KMDAwMDA4MTczNiAwMDAwMCBu DQowMDAwMDgxNzU4IDAwMDAwIG4NCjAwMDAwODI2MjkgMDAwMDAgbg0KMDAwMDA4MjY1MSAwMDAw MCBuDQowMDAwMDgzMjc0IDAwMDAwIG4NCjAwMDAwODMyOTYgMDAwMDAgbg0KMDAwMDA4MzkyMSAw MDAwMCBuDQowMDAwMDgzOTQzIDAwMDAwIG4NCjAwMDAwODQ3NzQgMDAwMDAgbg0KMDAwMDA4NDc5 NiAwMDAwMCBuDQowMDAwMDg1NjIyIDAwMDAwIG4NCjAwMDAwODU2NDQgMDAwMDAgbg0KMDAwMDA4 NjI4NiAwMDAwMCBuDQowMDAwMDg2MzA4IDAwMDAwIG4NCjAwMDAwODY5MzkgMDAwMDAgbg0KMDAw MDA4Njk2MSAwMDAwMCBuDQowMDAwMDg3NTkxIDAwMDAwIG4NCjAwMDAwODc2MTMgMDAwMDAgbg0K MDAwMDA4ODMwOCAwMDAwMCBuDQowMDAwMDg4MzMwIDAwMDAwIG4NCjAwMDAwODg4OTEgMDAwMDAg bg0KMDAwMDA4ODkxMyAwMDAwMCBuDQowMDAwMDg5NDcyIDAwMDAwIG4NCjAwMDAwODk0OTQgMDAw MDAgbg0KMDAwMDA5MDA2NyAwMDAwMCBuDQowMDAwMDkwMDg5IDAwMDAwIG4NCjAwMDAwOTA2OTgg MDAwMDAgbg0KMDAwMDA5MDcyMCAwMDAwMCBuDQowMDAwMDkxNTM2IDAwMDAwIG4NCjAwMDAwOTE1 NTggMDAwMDAgbg0KMDAwMDA5MjE4OSAwMDAwMCBuDQowMDAwMDkyMjExIDAwMDAwIG4NCjAwMDAw OTMwNzQgMDAwMDAgbg0KMDAwMDA5MzA5NiAwMDAwMCBuDQowMDAwMDkzOTgyIDAwMDAwIG4NCjAw MDAwOTQwMDQgMDAwMDAgbg0KMDAwMDA5NDg0NiAwMDAwMCBuDQowMDAwMDk0ODY4IDAwMDAwIG4N CjAwMDAwOTU0OTIgMDAwMDAgbg0KMDAwMDA5NTUxNCAwMDAwMCBuDQowMDAwMDk2MzM4IDAwMDAw IG4NCjAwMDAwOTYzNjAgMDAwMDAgbg0KMDAwMDA5NzAwNCAwMDAwMCBuDQowMDAwMDk3MDI2IDAw MDAwIG4NCjAwMDAwOTc2MzUgMDAwMDAgbg0KMDAwMDA5NzY1NyAwMDAwMCBuDQowMDAwMDk4NDE2 IDAwMDAwIG4NCjAwMDAwOTg0MzggMDAwMDAgbg0KMDAwMDA5OTIyNCAwMDAwMCBuDQowMDAwMDk5 MjQ2IDAwMDAwIG4NCjAwMDAxMDAwNDQgMDAwMDAgbg0KMDAwMDEwMDA2NiAwMDAwMCBuDQowMDAw MTAwODYzIDAwMDAwIG4NCjAwMDAxMDA4ODUgMDAwMDAgbg0KMDAwMDEwMTY1OCAwMDAwMCBuDQow MDAwMTAxNjgwIDAwMDAwIG4NCjAwMDAxMDI0ODMgMDAwMDAgbg0KMDAwMDEwMjUwNSAwMDAwMCBu DQowMDAwMTAzMjg0IDAwMDAwIG4NCjAwMDAxMDMzMDYgMDAwMDAgbg0KMDAwMDEwNDA3NyAwMDAw MCBuDQowMDAwMTA0MDk5IDAwMDAwIG4NCjAwMDAxMDQ4OTUgMDAwMDAgbg0KMDAwMDEwNDkxNyAw MDAwMCBuDQowMDAwMTA1Njc5IDAwMDAwIG4NCjAwMDAxMDU3MDEgMDAwMDAgbg0KMDAwMDEwNjQ0 MiAwMDAwMCBuDQowMDAwMTA2NDY0IDAwMDAwIG4NCjAwMDAxMDcyMzkgMDAwMDAgbg0KMDAwMDEw NzI2MSAwMDAwMCBuDQowMDAwMTA4MDA5IDAwMDAwIG4NCjAwMDAxMDgwMzEgMDAwMDAgbg0KMDAw MDEwODc5MiAwMDAwMCBuDQowMDAwMTA4ODE0IDAwMDAwIG4NCjAwMDAxMDk0ODggMDAwMDAgbg0K MDAwMDEwOTUxMCAwMDAwMCBuDQowMDAwMTEwMTYxIDAwMDAwIG4NCjAwMDAxMTAxODMgMDAwMDAg bg0KMDAwMDExMDgxOCAwMDAwMCBuDQowMDAwMTEwODQwIDAwMDAwIG4NCjAwMDAxMTE0MzUgMDAw MDAgbg0KMDAwMDExMTQ1NyAwMDAwMCBuDQowMDAwMTEyMDcyIDAwMDAwIG4NCjAwMDAxMTIwOTQg MDAwMDAgbg0KMDAwMDExMjcwNiAwMDAwMCBuDQowMDAwMTEyNzI4IDAwMDAwIG4NCjAwMDAxMTMy ODggMDAwMDAgbg0KMDAwMDExMzUzOSAwMDAwMCBuDQowMDAwMTEzNTk0IDAwMDAwIG4NCjAwMDAx MTM2MTYgMDAwMDAgbg0KMDAwMDExNDA0OCAwMDAwMCBuDQowMDAwMTE0MDcxIDAwMDAwIG4NCjAw MDAxMTU0NDEgMDAwMDAgbg0KMDAwMDExNTY5MiAwMDAwMCBuDQowMDAwMTE1NzM5IDAwMDAwIG4N CjAwMDAxMTU3NjEgMDAwMDAgbg0KMDAwMDExNjE5MyAwMDAwMCBuDQowMDAwMTE2MjE1IDAwMDAw IG4NCjAwMDAxMTcwMzcgMDAwMDAgbg0KMDAwMDExNzI4OCAwMDAwMCBuDQowMDAwMTE3MzM1IDAw MDAwIG4NCjAwMDAxMTczNTcgMDAwMDAgbg0KMDAwMDExNzc4OSAwMDAwMCBuDQowMDAwMTE3ODEx IDAwMDAwIG4NCjAwMDAxMTg1MTMgMDAwMDAgbg0KMDAwMDExODc2NCAwMDAwMCBuDQowMDAwMTE4 ODExIDAwMDAwIG4NCjAwMDAxMTg4MzMgMDAwMDAgbg0KMDAwMDExOTI2MiAwMDAwMCBuDQowMDAw MTE5Mjg1IDAwMDAwIG4NCjAwMDAxMjA0NjggMDAwMDAgbg0KMDAwMDEyMDczMSAwMDAwMCBuDQow MDAwMTIwNzc4IDAwMDAwIG4NCjAwMDAxMjA4MDAgMDAwMDAgbg0KMDAwMDEyMTIyOSAwMDAwMCBu DQowMDAwMTIxMjUxIDAwMDAwIG4NCjAwMDAxMjIxMzEgMDAwMDAgbg0KMDAwMDEyMjM4MiAwMDAw MCBuDQowMDAwMTIyNDI5IDAwMDAwIG4NCjAwMDAxMjI0NTEgMDAwMDAgbg0KMDAwMDEyMjg4MSAw MDAwMCBuDQowMDAwMTIyOTAzIDAwMDAwIG4NCjAwMDAxMjM5MjAgMDAwMDAgbg0KMDAwMDEyNDE3 MSAwMDAwMCBuDQowMDAwMTI0MjE4IDAwMDAwIG4NCjAwMDAxMjQyNDAgMDAwMDAgbg0KMDAwMDEy NDY2OSAwMDAwMCBuDQowMDAwMTI0NjkyIDAwMDAwIG4NCjAwMDAxMjU3ODIgMDAwMDAgbg0KMDAw MDEyNjAyMSAwMDAwMCBuDQowMDAwMTI2MDY4IDAwMDAwIG4NCjAwMDAxMjYwOTAgMDAwMDAgbg0K MDAwMDEyNjUxOSAwMDAwMCBuDQowMDAwMTI2NTQxIDAwMDAwIG4NCjAwMDAxMjcwNzIgMDAwMDAg bg0KMDAwMDEyNzMyMyAwMDAwMCBuDQowMDAwMTI3MzcwIDAwMDAwIG4NCjAwMDAxMjczOTIgMDAw MDAgbg0KMDAwMDEyNzgyMSAwMDAwMCBuDQowMDAwMTI3ODQzIDAwMDAwIG4NCjAwMDAxMjg1MzMg MDAwMDAgbg0KMDAwMDEyODc4NCAwMDAwMCBuDQowMDAwMTI4ODMxIDAwMDAwIG4NCjAwMDAxMjg4 NTMgMDAwMDAgbg0KMDAwMDEyOTI4MiAwMDAwMCBuDQowMDAwMTI5MzA0IDAwMDAwIG4NCjAwMDAx Mjk4MDcgMDAwMDAgbg0KMDAwMDEzMDA1OCAwMDAwMCBuDQowMDAwMTMwMTA1IDAwMDAwIG4NCjAw MDAxMzAxMjcgMDAwMDAgbg0KMDAwMDEzMDU1NiAwMDAwMCBuDQowMDAwMTMwNTc4IDAwMDAwIG4N CjAwMDAxMzEzMzIgMDAwMDAgbg0KMDAwMDEzMTU4MyAwMDAwMCBuDQowMDAwMTMxNjMwIDAwMDAw IG4NCjAwMDAxMzE2NTIgMDAwMDAgbg0KMDAwMDEzMjA4MSAwMDAwMCBuDQowMDAwMTMyMTA0IDAw MDAwIG4NCjAwMDAxMzM0OTMgMDAwMDAgbg0KMDAwMDEzMzc0NCAwMDAwMCBuDQowMDAwMTMzNzkx IDAwMDAwIG4NCjAwMDAxMzM4MTMgMDAwMDAgbg0KMDAwMDEzNDI0MyAwMDAwMCBuDQowMDAwMTM0 MjY1IDAwMDAwIG4NCjAwMDAxMzUyNjQgMDAwMDAgbg0KMDAwMDEzNTUwMyAwMDAwMCBuDQowMDAw MTM1NTUwIDAwMDAwIG4NCjAwMDAxMzU1NzIgMDAwMDAgbg0KMDAwMDEzNjAwMSAwMDAwMCBuDQow MDAwMTM2MDIzIDAwMDAwIG4NCjAwMDAxMzY3NjAgMDAwMDAgbg0KMDAwMDEzNzAxMSAwMDAwMCBu DQowMDAwMTM3MDU4IDAwMDAwIG4NCjAwMDAxMzcwODAgMDAwMDAgbg0KMDAwMDEzNzUwOSAwMDAw MCBuDQowMDAwMTM3NTMxIDAwMDAwIG4NCjAwMDAxMzgwMTIgMDAwMDAgbg0KMDAwMDEzODI2MyAw MDAwMCBuDQowMDAwMTM4MzEwIDAwMDAwIG4NCjAwMDAxMzgzMzIgMDAwMDAgbg0KMDAwMDEzODc2 MiAwMDAwMCBuDQowMDAwMTM4Nzg0IDAwMDAwIG4NCjAwMDAxMzkyNjMgMDAwMDAgbg0KMDAwMDEz OTUxNCAwMDAwMCBuDQowMDAwMTM5NTYxIDAwMDAwIG4NCjAwMDAxMzk1ODMgMDAwMDAgbg0KMDAw MDE0MDAxMyAwMDAwMCBuDQowMDAwMTQwMDM1IDAwMDAwIG4NCjAwMDAxNDA4ODggMDAwMDAgbg0K MDAwMDE0MTEzOSAwMDAwMCBuDQowMDAwMTQxMTg2IDAwMDAwIG4NCjAwMDAxNDEyMDggMDAwMDAg bg0KMDAwMDE0MTYzNyAwMDAwMCBuDQowMDAwMTQxNjU5IDAwMDAwIG4NCjAwMDAxNDIzNTggMDAw MDAgbg0KMDAwMDE0MjYwOSAwMDAwMCBuDQowMDAwMTQyNjU2IDAwMDAwIG4NCjAwMDAxNDI2Nzgg MDAwMDAgbg0KMDAwMDE0MzEwOCAwMDAwMCBuDQowMDAwMTQzMTMwIDAwMDAwIG4NCjAwMDAxNDM4 MjkgMDAwMDAgbg0KMDAwMDE0NDA4MCAwMDAwMCBuDQowMDAwMTQ0MTI3IDAwMDAwIG4NCjAwMDAx NDQxNDkgMDAwMDAgbg0KMDAwMDE0NDU3OSAwMDAwMCBuDQowMDAwMTQ0NjAxIDAwMDAwIG4NCjAw MDAxNDU1MTMgMDAwMDAgbg0KMDAwMDE0NTc1MiAwMDAwMCBuDQowMDAwMTQ1Nzk5IDAwMDAwIG4N CjAwMDAxNDU4MjEgMDAwMDAgbg0KMDAwMDE0NjI1MCAwMDAwMCBuDQowMDAwMTQ2MjcyIDAwMDAw IG4NCjAwMDAxNDY2MjUgMDAwMDAgbg0KMDAwMDE1MDc4NiAwMDAwMCBuDQowMDAwMTUwODA5IDAw MDAwIG4NCjAwMDAxNTE5MDkgMDAwMDAgbg0KMDAwMDE1MjE4OCAwMDAwMCBuDQowMDAwMTUzMjg1 IDAwMDAwIG4NCjAwMDAxNTM1NjIgMDAwMDAgbg0KMDAwMDE1NDY2NCAwMDAwMCBuDQowMDAwMTU0 OTQ5IDAwMDAwIG4NCjAwMDAxNTcxMjMgMDAwMDAgbg0KMDAwMDE1NzE0NiAwMDAwMCBuDQowMDAw MTU3MjQwIDAwMDAwIG4NCjAwMDAxNTcyNjEgMDAwMDAgbg0KMDAwMDE1NzU1OSAwMDAwMCBuDQow MDAwMTU3Njc3IDAwMDAwIG4NCjAwMDAxNTc4MDIgMDAwMDAgbg0KMDAwMDE1NzkyNyAwMDAwMCBu DQowMDAwMTU4MDUyIDAwMDAwIG4NCjAwMDAxNTgxNTMgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6 ZSA0NDUNL0lEWzxlOWI3NzM2N2NjNjM4MmQzNjg5ZDk5MDdhMWNlODMzNT48ZTliNzczNjdjYzYz ODJkMzY4OWQ5OTA3YTFjZTgzMzU+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== ------_=_NextPart_000_01C09783.37C82F30-- From owner-mpls@UU.NET Thu Feb 15 15:58:59 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29792 for ; Thu, 15 Feb 2001 15:58: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 QQkcnj24064; Thu, 15 Feb 2001 20:56:22 GMT Received: by mail-control.mail.uu.net id QQkcnj27915 for mpls-outgoing; Thu, 15 Feb 2001 20:55:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcnj27909 for ; Thu, 15 Feb 2001 20:55:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcnj19179 for ; Thu, 15 Feb 2001 20:55:17 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkcnj22355 for ; Thu, 15 Feb 2001 20:55:17 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id 71DE494008; Thu, 15 Feb 2001 15:55:16 -0500 (EST) Message-ID: <3A8C4234.77B7885C@sandburst.com> Date: Thu, 15 Feb 2001 15:55:16 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter Cc: mpls@UU.NET Subject: Re: PID in LDP References: <200102151742.JAA77527@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov, Could you be a little more specific? I looked through all of the messages in January and this month and likely ones from December and while there was a pretty lively chat on the subject in December and a few light discussions last month, I could see no direct reference to the issues with TTL expiry mid-LSP. I'd like to do due-diligence in finding this discussion as I have no real desire to re-ignite it. But I fail to see how it is relevant. If TTL expires, you discard the packet and - if you would not know how to forward it, that is all you can do anyway. You wrote: > Eric, > > > David, > > > > First: > > > > I fail to see why you have demonstrated a real need to > > tell intermediate LSRs what kind of traffic they are forwarding > > on a specific LSP. > > > > It seems to me that you need only to indicate if the packets > > are something that the intermediate LSR might know how to > > forward or not. Since you stipulate that you would only need > > to be able to make this distinction when using CR-LDP, then > > this is only needed for CR-LDP. > > Please recall the discussion ~1 month ago on the subject of > handling TTL=0 in the "shim" header by the intermediate LSRs. > > Yakov. From owner-mpls@UU.NET Thu Feb 15 16:00:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29847 for ; Thu, 15 Feb 2001 16:00: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 QQkcnj26698; Thu, 15 Feb 2001 20:57:45 GMT Received: by mail-control.mail.uu.net id QQkcnj28073 for mpls-outgoing; Thu, 15 Feb 2001 20:57:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcnj28058 for ; Thu, 15 Feb 2001 20:57:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcnj23546 for ; Thu, 15 Feb 2001 20:57:01 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 QQkcnj04421 for ; Thu, 15 Feb 2001 20:57:00 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA05674; Thu, 15 Feb 2001 12:56:59 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id MAA13939; Thu, 15 Feb 2001 12:56:59 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102152056.MAA13939@garnet.juniper.net> To: Eric Gray cc: mpls@UU.NET Subject: Re: PID in LDP In-Reply-To: Your message of "Thu, 15 Feb 2001 15:55:16 EST." <3A8C4234.77B7885C@sandburst.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13936.982270619.1@garnet.juniper.net> Date: Thu, 15 Feb 2001 12:56:59 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Eric, > Could you be a little more specific? I looked through all > of the messages in January and this month and likely ones > from December and while there was a pretty lively chat on > the subject in December and a few light discussions last > month, I could see no direct reference to the issues with > TTL expiry mid-LSP. > > I'd like to do due-diligence in finding this discussion as > I have no real desire to re-ignite it. But I fail to see how it > is relevant. If TTL expires, you discard the packet and - > if you would not know how to forward it, that is all you can > do anyway. Would you also send ICMP TTL expired ? Yakov. > > You wrote: > > > Eric, > > > > > David, > > > > > > First: > > > > > > I fail to see why you have demonstrated a real need to > > > tell intermediate LSRs what kind of traffic they are forwarding > > > on a specific LSP. > > > > > > It seems to me that you need only to indicate if the packets > > > are something that the intermediate LSR might know how to > > > forward or not. Since you stipulate that you would only need > > > to be able to make this distinction when using CR-LDP, then > > > this is only needed for CR-LDP. > > > > Please recall the discussion ~1 month ago on the subject of > > handling TTL=0 in the "shim" header by the intermediate LSRs. > > > > Yakov. > From owner-mpls@UU.NET Thu Feb 15 16:35:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00669 for ; Thu, 15 Feb 2001 16:35: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 QQkcnm18483; Thu, 15 Feb 2001 21:32:41 GMT Received: by mail-control.mail.uu.net id QQkcnm14574 for mpls-outgoing; Thu, 15 Feb 2001 21:32:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcnm14562 for ; Thu, 15 Feb 2001 21:31:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcnm11569 for ; Thu, 15 Feb 2001 21:30:36 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkcnm28059 for ; Thu, 15 Feb 2001 21:30:35 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id 555B494007; Thu, 15 Feb 2001 16:30:35 -0500 (EST) Message-ID: <3A8C4A7B.90203572@sandburst.com> Date: Thu, 15 Feb 2001 16:30:35 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: PID in LDP References: <200102151626.LAA15497@erosen-sun.cisco.com> <3A8C08D3.FBCFD900@marconi.com> <3A8C13CE.231F1895@sandburst.com> <3A8C19B5.7074BFE3@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Wish I could avoid embedding comments, but please see below... You wrote: > Eric Gray wrote: > > > > I fail to see why you have demonstrated a real need to tell > > intermediate LSRs what kind of traffic they are forwarding on a > > specific LSP. > > > > It seems to me that you need only to indicate if the packets are > > something that the intermediate LSR might know how to forward or not. > > Since you stipulate that you would only need to be able to make this > > distinction when using CR-LDP, then this is only needed for CR-LDP. > > I stipulate that streaming media applications only make sense over > CR-LDP. > > But there is a second category of non-IP traffic, namely legacy LAN > traffic. While an ISP core network won't be seeing this (except as part > of a VPN connection), an enterprise network might. > > In such a situation, merely knowing whether or not the packet can be > routed isn't enough. The router also has to know what the packet is, so > it can locate appropriate addressing information. > > I realize that most MPLS work is focussing on ISP core networks, but you > shouldn't assume that those are the only networks that will ever want to > use it. An optional TLV to carry L3PID information isn't a big deal. I see at least three issues here: 1) whether or not it makes sense to transport non-IP packets using (base) LDP; 2) whether or not it makes sense to use CR-LDP to setup LSPs for multiple L3 protocols in an enterprise LAN environment; 3) under what circumstances will it make sense to try to route non-IP packets even in an enterprise LAN environment. I believe one answer could be made to address all of these issues: simply define a new FEC type for additional L3 protocols. The main reason why I would advocate this approach - as opposed to defining an L3PID TLV, is that it can only make sense for an intermediate LSR to attempt to route ANY L3 packet if it knows how to route that L3 packet. That would imply the analog of a route table entry for that L3 protocol address in each intermediate LSR on an LSP intended to carry packets for that L3. A secondary reason for advocating this approach is that (base) LDP is fundamentally a hop-by-hop LSP signaling protocol: it only really makes sense to signal labels between two adjacent LDP peers if each of them knows how to deal with inserting or removing packets in the corresponding LSP. Obviously, any enterprise routers that do not know how to route L3 "X" would have to have "X" packets tunneled through them, either using IP tunneling and LDP, or using CR-LDP (or RSVP-TE to be fair). Certainly there is the possibility of adding new FEC types in an as-yet unwritten RFC. That's part of what makes this "MP"LS. Yes, this approach would be a big deal, but I am not convinced that merely adding an L3 PID TLV adds any real value. Even a no-op is a wasted instruction if it is not needed. > > > > CR-LDP defines a FEC which carries the meaning you seek. > > Where? I just re-read it again and didn't find this. CR-LDP only defines one FEC Element type (the others were previously defined in LDP). See section 4.10. I confess that the meaning "don't expect to be able to route these packets" is implicit - simply because the FEC type is unspecified - however, it is possible to use an explicit FEC type and the way I would interpret an "opaque" FEC type is exactly this way. I made this argument several times during the process of getting the draft to where it is and I am slightly dissappointed not to find this meaning more explicitly stated. I certainly recall that there was agreement that this was implied by the new FEC type. > > > > Second: > > > > Have you looked at proposals for transporting compressed headers > > over MPLS? With such an approach, it is difficult to see what the > > real advantage is in omitting the IP header when transporting data via > > an LSP. > > The means of encapsulating streaming data in an LSP I mentioned is just > an example. I did not mean to suggest it as the way things should be > done. > > -- David > > > David Charlap wrote: > >> Eric Rosen wrote: > >>> > >>> It seems to me that label explosion occurs whether the LSPs are set > >>> up in an unsolicited manner or whether they are set up explicitly. > >>> You must be assuming that the number of labels needed to represent > >>> VPN or layer 2 tunnels is just a small fraction of the total number > >>> of labels per node. > >> > >> Who said anything about VPN? You know as well as I do that a private > >> address is meningless outside of its own network. If a transient > >> condition would cause such a packet to hit a router without an NHLFE, > >> there's no way the packet is going to be forwarded, no matter how > >> it's encoded. > >> > >> I explicitly said that a PID field is needed for non-IP traffic. > >> This is not an IP packet with a private address being tunneled across > >> a public network. > >> > >> There are two uses for non-IP traffic I can think of: > >> > >> 1: Streaming data (like voice). > >> > >> It makes sense for media server or media gateway to strip off as > >> much overhead as possible (like IP headers) and just send the PCM > >> (or MPEG, or H.323, or whatever) stream directly in the LSP. > >> > >> A transit router won't be able to forward these packets without > >> the labels, since there's no address information in the data > >> stream, but it will be able to identify the traffic as something > >> that is not routable. > >> > >> Of course, this is really not applicable for LDP, but CR-LDP, > >> since some level of QoS will be desired for these applications. I > >> doubt customers would be happy if this traffic was treated like > >> all other traffic to the destination. > >> > >> Yes, DiffServ and the EXP bits can be used, but not everyone is > >> going to support DS, and DS may not provide the required > >> granularity. (Imagine 20 different streams, each with a different > >> QoS requirement?) > >> > >> In this situation, you're not changing the potential for label > >> explosion, because a customer in this scenario is going to have to > >> be using CR-LDP and L-LSPs anyway. Tacking on an extra TLV so > >> that the content can be identified is not a big deal. > >> > >> 2: Legacy LAN traffic. > >> > >> If someone wants to connect two legagy Netware (or Appletalk, > >> etc.) servers across the internet, it would be nicer to pass the > >> packets in an LSP instead of tunneling them through IP. A transit > >> router may know how to route these. (Probably not in an ISP core, > >> but possibly in an enterprise network.) > >> > >> I can't imagine this being a large amount of traffic, however. From owner-mpls@UU.NET Thu Feb 15 16:45:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01017 for ; Thu, 15 Feb 2001 16:45: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 QQkcnm05224; Thu, 15 Feb 2001 21:43:12 GMT Received: by mail-control.mail.uu.net id QQkcnm15345 for mpls-outgoing; Thu, 15 Feb 2001 21:42: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 QQkcnm15335 for ; Thu, 15 Feb 2001 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 QQkcnm17314 for ; Thu, 15 Feb 2001 21:41:39 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkcnm11841 for ; Thu, 15 Feb 2001 21:41:39 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id B106494008; Thu, 15 Feb 2001 16:41:38 -0500 (EST) Message-ID: <3A8C4D12.B60FBDC2@sandburst.com> Date: Thu, 15 Feb 2001 16:41:38 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter Cc: mpls@UU.NET Subject: Re: PID in LDP References: <200102152056.MAA13939@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov, Hmmm. Thought it might be that. The answer is that you would not be likely to be able to send an ICMP error message to the packet source if you would not be able to route the original packet - if unexpired - to the packet destination. However, there is a back-doorsy kind of way to send an ICMP error message to the LSP ingress if the LSP was established using either CR-LDP or RSVP-TE. Also, I am pretty sure that Ron Bonica's efforts to resolve this little problem in the general tunneling case have not yet been abandoned. And I sure don't see how having an L3 PID identifying an LSP as having been established to carry non-IP packets is going to help with this specific problem (therefore the question on relevancy). -- Eric Gray You wrote: > Eric, > > > Could you be a little more specific? I looked through all > > of the messages in January and this month and likely ones > > from December and while there was a pretty lively chat on > > the subject in December and a few light discussions last > > month, I could see no direct reference to the issues with > > TTL expiry mid-LSP. > > > > I'd like to do due-diligence in finding this discussion as > > I have no real desire to re-ignite it. But I fail to see how it > > is relevant. If TTL expires, you discard the packet and - > > if you would not know how to forward it, that is all you can > > do anyway. > > Would you also send ICMP TTL expired ? > > Yakov. > > > > > You wrote: > > > > > Eric, > > > > > > > David, > > > > > > > > First: > > > > > > > > I fail to see why you have demonstrated a real need to > > > > tell intermediate LSRs what kind of traffic they are forwarding > > > > on a specific LSP. > > > > > > > > It seems to me that you need only to indicate if the packets > > > > are something that the intermediate LSR might know how to > > > > forward or not. Since you stipulate that you would only need > > > > to be able to make this distinction when using CR-LDP, then > > > > this is only needed for CR-LDP. > > > > > > Please recall the discussion ~1 month ago on the subject of > > > handling TTL=0 in the "shim" header by the intermediate LSRs. > > > > > > Yakov. > > From owner-mpls@UU.NET Thu Feb 15 16:58:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01253 for ; Thu, 15 Feb 2001 16:58: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 QQkcnn04313; Thu, 15 Feb 2001 21:56:00 GMT Received: by mail-control.mail.uu.net id QQkcnn16879 for mpls-outgoing; Thu, 15 Feb 2001 21:55: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 QQkcnn16853 for ; Thu, 15 Feb 2001 21:55:11 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 QQkcnn14020 for ; Thu, 15 Feb 2001 21:54:48 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkcnn15661 for ; Thu, 15 Feb 2001 21:54:48 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05019 for ; Thu, 15 Feb 2001 16:54:45 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20562 for ; Thu, 15 Feb 2001 16:54:49 -0500 (EST) Message-ID: <3A8C5044.5976B144@marconi.com> Date: Thu, 15 Feb 2001 16:55:16 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PID in LDP References: <200102151626.LAA15497@erosen-sun.cisco.com> <3A8C08D3.FBCFD900@marconi.com> <3A8C13CE.231F1895@sandburst.com> <3A8C19B5.7074BFE3@marconi.com> <3A8C4A7B.90203572@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > I see at least three issues here: > > 1) whether or not it makes sense to transport non-IP packets > using (base) LDP; > 2) whether or not it makes sense to use CR-LDP to setup LSPs > for multiple L3 protocols in an enterprise LAN environment; > 3) under what circumstances will it make sense to try to route > non-IP packets even in an enterprise LAN environment. > > I believe one answer could be made to address all of these issues: > simply define a new FEC type for additional L3 protocols. The > main reason why I would advocate this approach - as opposed > to defining an L3PID TLV, is that it can only make sense for an > intermediate LSR to attempt to route ANY L3 packet if it knows > how to route that L3 packet. That would imply the analog of a > route table entry for that L3 protocol address in each intermediate > LSR on an LSP intended to carry packets for that L3. This would work. There would still, however, need to be a way to indicate that the data in the LSP is not the same type as the FEC, however. This way a transit router will know not to try and forward a packet that leaves the LSP in the middle (due to a transient condition). If the router handles transient conditions by always dropping packets, this isn't a problem. If it tries to forward them, it must know what's inside. For instance, a raw digitized audio stream may have a packet where the first 20 bytes resemble an IP header - nevertheless, you wouldn't want to use those bytes for a forwarding decision. The main reason for my advocacy of a L3PID TLV is simply because that's what RSVP-TE already does (it's a field in the LABEL_REQUEST object). > A secondary reason for advocating this approach is that (base) > LDP is fundamentally a hop-by-hop LSP signaling protocol: it > only really makes sense to signal labels between two adjacent > LDP peers if each of them knows how to deal with inserting or > removing packets in the corresponding LSP. True. CR-LDP is tunnel-oriented, but LDP is not. -- David From owner-mpls@UU.NET Thu Feb 15 17:22:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01599 for ; Thu, 15 Feb 2001 17:22: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 QQkcnp02979; Thu, 15 Feb 2001 22:20:10 GMT Received: by mail-control.mail.uu.net id QQkcnp03058 for mpls-outgoing; Thu, 15 Feb 2001 22:19:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcnp03050 for ; Thu, 15 Feb 2001 22:19:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcnp12600 for ; Thu, 15 Feb 2001 22:18:15 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkcnp16322 for ; Thu, 15 Feb 2001 22:18: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 RAA07633 for ; Thu, 15 Feb 2001 17:18:11 -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 RAA26433 for ; Thu, 15 Feb 2001 17:18:14 -0500 (EST) Message-ID: <3A8C55C1.2A193623@marconi.com> Date: Thu, 15 Feb 2001 17:18:41 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PID in LDP References: <200102152056.MAA13939@garnet.juniper.net> <3A8C4D12.B60FBDC2@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [RE: ICMP generation on TTL expiry] Eric Gray wrote: > > Hmmm. Thought it might be that. The answer is that > you would not be likely to be able to send an ICMP error > message to the packet source if you would not be able to > route the original packet - if unexpired - to the packet > destination. You may have a route to the source, even if you don't have one to the destination. > However, there is a back-doorsy kind of way to send > an ICMP error message to the LSP ingress if the LSP was > established using either CR-LDP or RSVP-TE. Also, I > am pretty sure that Ron Bonica's efforts to resolve this > little problem in the general tunneling case have not yet > been abandoned. > > And I sure don't see how having an L3 PID identifying > an LSP as having been established to carry non-IP packets > is going to help with this specific problem (therefore the > question on relevancy). If the packet is not IP, then the source won't expect or want an ICMP response. It might, however, expect something else, depending on what that L3 protocol is. If the L3 protocol is unknown, there isn't much it can do. If it knows what the protocol is (IP or otherwise), it can generate an appropriate response (assuming, of course, that the response can be routed back to the source.) The mechanism with which it uses to know the protocol doesn't matter, as long as it knows. -- David From owner-mpls@UU.NET Thu Feb 15 18:58:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02520 for ; Thu, 15 Feb 2001 18:58: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 QQkcnv16601; Thu, 15 Feb 2001 23:55:56 GMT Received: by mail-control.mail.uu.net id QQkcnv25930 for mpls-outgoing; Thu, 15 Feb 2001 23:55: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 QQkcnv25923 for ; Thu, 15 Feb 2001 23:55: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 QQkcnv08430 for ; Thu, 15 Feb 2001 23:54:56 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcnv09404 for ; Thu, 15 Feb 2001 23:54:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA24634 for mpls@uu.net; Thu, 15 Feb 2001 18:54:54 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcnv25839 for ; Thu, 15 Feb 2001 23:54:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcnv17762 for ; Thu, 15 Feb 2001 23:54:09 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkcnv00283 for ; Thu, 15 Feb 2001 23:54:08 GMT Received: from lir.cisco.com (lir.cisco.com [161.44.172.144]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA06732; Thu, 15 Feb 2001 18:54:06 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id SAA09672; Thu, 15 Feb 2001 18:54:06 -0500 (EST) Message-Id: <200102152354.SAA09672@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Cc: swallow@cisco.com, vijay@cosinecom.com Subject: Time to set the agenda Date: Thu, 15 Feb 2001 18:54:05 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - MPLS is scheduled for one slot - Monday morning. Please send your requests for presentation slots. Those of you who've already sent me requests need not resend. Cheers, George & Vijay ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Feb 15 19:04:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02592 for ; Thu, 15 Feb 2001 19:04: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 QQkcnw24771; Fri, 16 Feb 2001 00:01:22 GMT Received: by mail-control.mail.uu.net id QQkcnw29942 for mpls-outgoing; Fri, 16 Feb 2001 00:00:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcnw29897 for ; Fri, 16 Feb 2001 00:00:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcnw03421 for ; Fri, 16 Feb 2001 00:00:11 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcnw19963 for ; Fri, 16 Feb 2001 00:00:08 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA25266 for mpls@uu.net; Thu, 15 Feb 2001 19:00: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 QQkcnv26468 for ; Thu, 15 Feb 2001 23:59:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcnv20809 for ; Thu, 15 Feb 2001 23:58:35 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 QQkcnv16480 for ; Thu, 15 Feb 2001 23:58:31 GMT Received: from lir.cisco.com (lir.cisco.com [161.44.172.144]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA07069; Thu, 15 Feb 2001 18:58:29 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA20948; Thu, 15 Feb 2001 15:59:45 -0500 (EST) Message-Id: <200102152059.PAA20948@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Cc: swallow@cisco.com, vijay@cosinecom.com Subject: Time to set the agenda Date: Thu, 15 Feb 2001 15:59:45 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Polks - MPLS is scheduled for one slot - Monday morning. Please send your requests for presentation slots. Those of you who've already sent me requests need not resend. Cheers, George & Vijay ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Feb 15 21:16:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04448 for ; Thu, 15 Feb 2001 21:16: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 QQkcoe29273; Fri, 16 Feb 2001 02:13:51 GMT Received: by mail-control.mail.uu.net id QQkcoe20582 for mpls-outgoing; Fri, 16 Feb 2001 02: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 QQkcoe20566 for ; Fri, 16 Feb 2001 02:13:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcoe20487 for ; Fri, 16 Feb 2001 02:12:27 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcoe16495 for ; Fri, 16 Feb 2001 02:12:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA02171 for mpls@uu.net; Thu, 15 Feb 2001 21:12: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 QQkcoe20419 for ; Fri, 16 Feb 2001 02:11:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcoe06013 for ; Fri, 16 Feb 2001 02:11:54 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQkcoe15304 for ; Fri, 16 Feb 2001 02:11:53 GMT Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 15 Feb 2001 18:18:57 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3LVB6>; Thu, 15 Feb 2001 18:18:58 -0500 Message-ID: <6DDA62170439D31185750000F80826AC05395EF1@zmerd004.ca.nortel.com> From: "Mina Azad" To: mpls@UU.NET Subject: subscribe Date: Thu, 15 Feb 2001 18:18:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C097A5.A927CDD0" 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_01C097A5.A927CDD0 Content-Type: text/plain; charset="iso-8859-1" subscribe ------_=_NextPart_001_01C097A5.A927CDD0 Content-Type: text/html; charset="iso-8859-1" subscribe

subscribe

------_=_NextPart_001_01C097A5.A927CDD0-- From owner-mpls@UU.NET Fri Feb 16 10:15:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01499 for ; Fri, 16 Feb 2001 10:15: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 QQkcqe26954; Fri, 16 Feb 2001 15:12:20 GMT Received: by mail-control.mail.uu.net id QQkcqe26237 for mpls-outgoing; Fri, 16 Feb 2001 15:12: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 QQkcqe26230 for ; Fri, 16 Feb 2001 15:11: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 QQkcqe28224 for ; Fri, 16 Feb 2001 15:11:18 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcqe24759 for ; Fri, 16 Feb 2001 15:11:18 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA07177 for mpls@uu.net; Fri, 16 Feb 2001 10:11: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 QQkcqe26053 for ; Fri, 16 Feb 2001 15:10: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 QQkcqe25209 for ; Fri, 16 Feb 2001 15:10:21 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 QQkcqe22148 for ; Fri, 16 Feb 2001 15:10:20 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 HAA04500; Fri, 16 Feb 2001 07:09:57 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BGMK4>; Fri, 16 Feb 2001 07:12:59 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A83@BBY1EXM01> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'neil.2.harrison@bt.com'" , Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, mpls@UU.NET Subject: RE: PHP negotiation Date: Fri, 16 Feb 2001 07:12:54 -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 Eric, I forgot to mention that duplicating the original user-label under the OAM label, is not a good enough solution for PHP case. The reasons are: 1) The Performance packets could be identified uniquely, but the user data packets can't. Because we can't duplicate the user label in user data packets. So basically LSP QoS measurements can't be done with PHP. 2) The Connectivity verification packets could be uniquely identified, but in case of mis-merging or mis-routing it would be very difficult to track the problem, because we don't know from which LSP the CV packets are arriving. Yours, -Shahram > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, February 15, 2001 10:03 AM > To: Shahram Davari > Cc: 'neil.2.harrison@bt.com'; Indra.Widjaja@fnc.fujitsu.com; > Ben.Mack-Crane@tellabs.com; mpls@UU.NET > Subject: Re: PHP negotiation > > > So PHP doesn't make OAM impossible after all! I guess I'm > not surprised. > > Shahram> after a PHP, the egress can not uniquely identify > the LSP that the > Shahram> OAM packet belongs to. > > You haven't forgotten that LSPs are multipoint-to-point, > have you? Do you > have a way to tell where the OAM came from? > From owner-mpls@UU.NET Fri Feb 16 14:05:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07198 for ; Fri, 16 Feb 2001 14:05: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 QQkcqu19811; Fri, 16 Feb 2001 19:05:16 GMT Received: by mail-control.mail.uu.net id QQkcqu12041 for mpls-outgoing; Fri, 16 Feb 2001 19: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 QQkcqu11653 for ; Fri, 16 Feb 2001 19:04: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 QQkcqu26352 for ; Fri, 16 Feb 2001 19:04:29 GMT Received: from develop.eu.level3.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQkcqu09085 for ; Fri, 16 Feb 2001 19:04:28 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14TqAM-0004jo-00; Fri, 16 Feb 2001 19:03:38 +0000 Message-ID: <3A8A6F21.C7555805@level3.net> Date: Wed, 14 Feb 2001 11:42:25 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: MPLS OAM? (was Re: PHP negotiation) 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: > > Hi Indra, > > >From a quick analysis I think you are right (Ben and Shahram may wish to > confirm this). However, this is a fortuitous consequence rather than a > planned one, ie a lack of protocol ID in the normal labelled header forces > one to create a special bottom-of-stack OAM alert label, and so increase the > label stack by + 1, thereby fortuitously negating the effect of PHP. > However, PHP must not be allowed on the OAM alert labelled header. Hi Neil, I think there might be a potential problem lurking in your OAM solution... Imagine the network shown below (apologies for the quality of my ASCII art): LER LSR LSR LER |---| |---|-----|---| |---| | A |-----| B | | C |-----| D | |---| |---|-----|---| |---| LSPs from A to D need to be load-balanced across the two links from B to C. This may be done using explicit routes, but I would expect it is more likely to be done using some form of automated load-balancing. This load-balancing is quite likely to use a hash on the top label in the stack. Because OAM packets will have the stack bit unset to indicate the presence of an additional label they will most likely hash onto a different link to user packets? So you can't be sure that the OAM packets have taken the same path as your data? I guess if vendors implement load balancing to ignore the stack bit in their hash then there won't be a problem, but I'll leave it to the vendors here present to comment on that ;-) BTW, is there any way you can share your proposal with the list in more detail? I'm having to guess at what you're doing by reading between the lines on these posts :( Giles > > Neil > > -----Original Message----- > > From: Indra Widjaja [mailto:Indra.Widjaja@fnc.fujitsu.com] > > Sent: 14 February 2001 21:28 > > To: Ben Mack-Crane > > Cc: erosen@cisco.com; neil.2.harrison@bt.com; kireeti@juniper.net; > > mpls@UU.NET > > Subject: Re: PHP negotiation > > > > > > Hi Ben and Neil: > > > > If I may get back to the technical discussion on why PHP > > impacts OAM ... > > > > I still don't quite understand how PHP would specifically > > break the behavior > > of your OAM proposal. > > > > Behavior 1: OAM with PHP > > Penultimate node pops the top label and sends an OAM packet > > to the ultimate node. > > Upon receiving the packet, the ultimate node sees an OAM > > alert label and > > forwards the packet to the local OAM engine for further processing. > > > > Behavior 2: OAM without PHP > > Penultimate node forwards an OAM packet without popping the top label. > > Upon receiving the packet, the ultimate node pops the top label. > > Since the next label indicates an OAM alert label, the packet > > is forwarded > > to the local OAM engine for further processing. > > > > So it looks like the OAM engine will see no difference in the > > two behaviors. > > On the other hand, it would be different if the recently > > popped label is saved. > > Appreciate your clarification. > > > > indra > > > > > > Ben Mack-Crane wrote: > > > > > Eric, > > > > > > I don't know if one could describe the OAM proposal we're > > working on as > > > a "connection-oriented ITU-like scheme," but I have often > > found functional > > > modeling of layered networks (defined by ITU) useful in > > understanding how > > > networks work (or fail to work) in various configurations. > > I have even > > > found it useful in understanding connectionless networks. > > > > > > It seems to me that during its evolution MPLS has developed > > two personas. > > > It has a connectionless persona, exemplified by features > > like independent > > > unsolicited label distribution and PHP. It also has > > developed a connection- > > > oriented persona with features like LSP tunnels and VPN > > applications. > > > > > > For cases in which an LSP must have well-defined endpoints > > and there is > > > a need to be able to effectively detect MPLS layer defects > > (e.g. mis-merging) > > > some additional OAM features are needed. These OAM > > features apply to the > > > MPLS (shim header) packet layer, not to sub-ip layers (for > > which similar > > > OAM features are already defined). > > > > > > Regards, > > > Ben Mack-Crane > > > > > > Eric Rosen wrote: > > > > > > > > Neil> I guess the discussion above gave enough > > pointers as to why an > > > > Neil> unambiguous location of the trail termination > > function is important > > > > > > > > Well, I can say that it didn't give me a clue. Repeated > > unsupported claims > > > > that it is "vital" to follow ITU architectures just > > aren't very persuasive. > > > > > > > > Are you expecting to achieve WG consensus on an OAM > > proposal? If the > > > > proposal is an attempt to warp an IP-based architecture > > into some kind of > > > > connection-oriented ITU-like scheme, my guess is that > > there is very little > > > > chance of achieving consensus. > > > > > > > > Actually, I wonder if the OAM stuff falls under the > > charter of the CCAMP > > > > group rather than the MPLS group. > > -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Fri Feb 16 14:48:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08314 for ; Fri, 16 Feb 2001 14:48: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 QQkcqx24535; Fri, 16 Feb 2001 19:48:48 GMT Received: by mail-control.mail.uu.net id QQkcqx18091 for mpls-outgoing; Fri, 16 Feb 2001 19:48:03 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 QQkcqx18057 for ; Fri, 16 Feb 2001 19:47: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 QQkcqx13145 for ; Fri, 16 Feb 2001 19:47:38 GMT From: jorge.rodriguez@telefonica-data.com Received: from infomail.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nie2.infomail.es [195.235.39.19]) id QQkcqx26782 for ; Fri, 16 Feb 2001 19:47:38 GMT Received: from notes06.telefonica-data.com ([192.168.100.59]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #982352807.112960001; Fri, 16 Feb 2001 20:46:47 +0100 Received: by notes06.telefonica-data.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C12569F5.006C7CFA ; Fri, 16 Feb 2001 20:44:58 +0100 X-Lotus-FromDomain: TTD To: mpls@UU.NET, ccamp@ops.ietf.org Message-ID: Date: Fri, 16 Feb 2001 20:47:00 +0100 Subject: Interoperability Juniper-Passport Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Infomail-Id: 982352807.2C20010A81107C.32807 Sender: owner-mpls@UU.NET Precedence: bulk Anybody has done interoperability tests between Juniper and Passport 7000 (Nortel)? Success? What sw releases? I'm about to do tests in both MPLS level and with Juniper's CCC. If this lists weren't the right place, where could I get this kind of information? I appreciate any input. Thanks & regards, Jorge ____________________________________ Jorge Rodriguez-Gabilondo Telefonica Data Network Planning and Design jorge.rodriguez@telefonica-data.com +34 91 514 4082 _________________________________________________________________ Hemos renovado nuestra web. Esperamos su visita en http://www.telefonica-data.com From owner-mpls@UU.NET Fri Feb 16 16:13:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09833 for ; Fri, 16 Feb 2001 16:13: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 QQkcrc10659; Fri, 16 Feb 2001 21:13:42 GMT Received: by mail-control.mail.uu.net id QQkcrc22811 for mpls-outgoing; Fri, 16 Feb 2001 21:13: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 QQkcrc22803 for ; Fri, 16 Feb 2001 21:13:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcrc01733 for ; Fri, 16 Feb 2001 21:10:38 GMT From: neil.2.harrison@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 QQkcrc04065 for ; Fri, 16 Feb 2001 21:10:38 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Fri, 16 Feb 2001 20:58:45 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id <1PC39G4Z>; Fri, 16 Feb 2001 20:59:21 -0000 Message-ID: To: giles@level3.net Cc: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: MPLS OAM? (was Re: PHP negotiation) Date: Fri, 16 Feb 2001 20:59:12 -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 Giles Heron [mailto:giles@level3.net] wrote 14 February 2001 11:42 > > Hi Neil, > > I think there might be a potential problem lurking in your OAM > solution... > > Imagine the network shown below (apologies for the quality of my ASCII > art): > > LER LSR LSR LER > |---| |---|-----|---| |---| > | A |-----| B | | C |-----| D | > |---| |---|-----|---| |---| > > LSPs from A to D need to be load-balanced across the two > links from B to > C. This may be done using explicit routes, but I would expect it is > more likely to be done using some form of automated load-balancing. NH=> We are only considering explicitly routed pt-pt LSPs, as one would set-up by RSVP or CR-LDP and not plain LDP LSPs, ie no merging. So the way I would look at this diagram is that: - there is a single LSP A-D - there are 2 server LSPs B-C So there would be one OAM flow on the (client) LSP from A-D, and seperate OAM flows on each of the server LSPs going between B-C. Note - Architecturally load splitting like this is functionally creating 2 lower level trails that need management. So if traffic (which includes the OAM pkts from A->D) is 'split' to load share for some reason on each of the server LSPs B-C, then as far as LSP A-D is concerned this is still a single LSP and it does not see the 2 server layer LSPs....just as they don't see (for example) the SDH VC4s they might be carried on, etc to the duct. > This load-balancing is quite likely to use a hash on the top label in > the stack. > Because OAM packets will have the stack bit unset to > indicate the presence of an additional label they will most > likely hash > onto a different link to user packets? So you can't be sure that the > OAM packets have taken the same path as your data? I guess if vendors > implement load balancing to ignore the stack bit in their hash then > there won't be a problem, but I'll leave it to the vendors > here present > to comment on that ;-) NH=> From the soure LSR 'normal' pkts will have a single normal label header, and OAM pkts will have a normal label header (top) and an OAM labelled header (bottom)....so yes, normal pkts will have S bit set and OAM pkts will not (as they arrive at LSR B). > > BTW, is there any way you can share your proposal with the > list in more > detail? I'm having to guess at what you're doing by reading > between the > lines on these posts :( NH=> Shahram is producing an ID at the moment. But in the meantime I will sent what others asked for in Word format by separate mail. BTW I am out all next week and unlikely to be looking at mail, so sorry if I can't respond to any further questions. > > From owner-mpls@UU.NET Fri Feb 16 16:43:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10188 for ; Fri, 16 Feb 2001 16:43: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 QQkcre06843; Fri, 16 Feb 2001 21:43:14 GMT Received: by mail-control.mail.uu.net id QQkcre25419 for mpls-outgoing; Fri, 16 Feb 2001 21:42:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkcre25408 for ; Fri, 16 Feb 2001 21:42:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcre25456 for ; Fri, 16 Feb 2001 21:42:03 GMT Received: from develop.eu.level3.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQkcre26687 for ; Fri, 16 Feb 2001 21:42:03 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14TsdE-0000gZ-00; Fri, 16 Feb 2001 21:41:36 +0000 Message-ID: <3A8D9E0A.2D6BB162@level3.net> Date: Fri, 16 Feb 2001 21:39:22 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: Re: MPLS OAM? (was Re: PHP negotiation) 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: > > Giles Heron [mailto:giles@level3.net] wrote 14 February 2001 11:42 > > > > Hi Neil, > > > > I think there might be a potential problem lurking in your OAM > > solution... > > > > Imagine the network shown below (apologies for the quality of my ASCII > > art): > > > > LER LSR LSR LER > > |---| |---|-----|---| |---| > > | A |-----| B | | C |-----| D | > > |---| |---|-----|---| |---| > > > > LSPs from A to D need to be load-balanced across the two > > links from B to > > C. This may be done using explicit routes, but I would expect it is > > more likely to be done using some form of automated load-balancing. > NH=> We are only considering explicitly routed pt-pt LSPs, as one would > set-up by RSVP or CR-LDP and not plain LDP LSPs, ie no merging. So the way > I would look at this diagram is that: > - there is a single LSP A-D > - there are 2 server LSPs B-C > So there would be one OAM flow on the (client) LSP from A-D, and seperate > OAM flows on each of the server LSPs going between B-C. Note - > Architecturally load splitting like this is functionally creating 2 lower > level trails that need management. > So if traffic (which includes the OAM pkts from A->D) is 'split' to load > share for some reason on each of the server LSPs B-C, then as far as LSP A-D > is concerned this is still a single LSP and it does not see the 2 server > layer LSPs....just as they don't see (for example) the SDH VC4s they might > be carried on, etc to the duct. I guess this would imply that on any set of parallel links between two MPLS routers you'd be pushing an extra level of label to handle the linkset? I'm not sure that's the most efficient way of doing load-sharing? And in any case you'd come back to the same issue. How does B decide which packets of a given LSP from A-D need to be placed on the "upper" link and which on the "lower"? If OAM packets are routed on a different physical link than user data packets then the OAM no longer measures the LSP accurately? [rest of original message snipped] Giles -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Fri Feb 16 16:44:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10201 for ; Fri, 16 Feb 2001 16:44:02 -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 QQkcre04362; Fri, 16 Feb 2001 21:44:03 GMT Received: by mail-control.mail.uu.net id QQkcre25472 for mpls-outgoing; Fri, 16 Feb 2001 21:43:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcre25458 for ; Fri, 16 Feb 2001 21:43:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkcre18083 for ; Fri, 16 Feb 2001 21:43:14 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkcre28254 for ; Fri, 16 Feb 2001 21:43:14 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08313 for mpls@uu.net; Fri, 16 Feb 2001 16:43: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 QQkcre25401 for ; Fri, 16 Feb 2001 21:42:27 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 QQkcre09111 for ; Fri, 16 Feb 2001 21:41: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 QQkcre28149 for ; Fri, 16 Feb 2001 21:41:50 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 NAA19060; Fri, 16 Feb 2001 13:40:59 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BGWW6>; Fri, 16 Feb 2001 13:44:02 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A8B@BBY1EXM01> From: Shahram Davari To: "'Giles Heron'" , neil.2.harrison@bt.com Cc: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, mpls@UU.NET Subject: RE: MPLS OAM? (was Re: PHP negotiation) Date: Fri, 16 Feb 2001 13:40:53 -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 Giles, 1) As you said, if you know that you are using OAM, and if the stack depth without OAM label is 1, then you probably should not configure your load balancing node to hash on S-bit. 2) If the A-D LSP is using a label stack of depth > 1 (excluding OAM label), then S=0 in both OAM packets and user data packets. And there won't be any problem. 3) I think MPLS has enough capabilities for load balancing using TE methods, so that there probably is no need to do load balancing by hashing methods. Yours, -Shahram > -----Original Message----- > From: Giles Heron [mailto:giles@level3.net] > Sent: Wednesday, February 14, 2001 6:42 AM > To: neil.2.harrison@bt.com > Cc: Indra.Widjaja@fnc.fujitsu.com; Ben.Mack-Crane@tellabs.com; Shahram > Davari; mpls@UU.NET > Subject: MPLS OAM? (was Re: PHP negotiation) > > > neil.2.harrison@bt.com wrote: > > > > Hi Indra, > > > > >From a quick analysis I think you are right (Ben and > Shahram may wish to > > confirm this). However, this is a fortuitous consequence > rather than a > > planned one, ie a lack of protocol ID in the normal > labelled header forces > > one to create a special bottom-of-stack OAM alert label, > and so increase the > > label stack by + 1, thereby fortuitously negating the effect of PHP. > > However, PHP must not be allowed on the OAM alert labelled header. > > Hi Neil, > > I think there might be a potential problem lurking in your OAM > solution... > > Imagine the network shown below (apologies for the quality of my ASCII > art): > > LER LSR LSR LER > |---| |---|-----|---| |---| > | A |-----| B | | C |-----| D | > |---| |---|-----|---| |---| > > LSPs from A to D need to be load-balanced across the two > links from B to > C. This may be done using explicit routes, but I would expect it is > more likely to be done using some form of automated load-balancing. > This load-balancing is quite likely to use a hash on the top label in > the stack. Because OAM packets will have the stack bit unset to > indicate the presence of an additional label they will most > likely hash > onto a different link to user packets? So you can't be sure that the > OAM packets have taken the same path as your data? I guess if vendors > implement load balancing to ignore the stack bit in their hash then > there won't be a problem, but I'll leave it to the vendors > here present > to comment on that ;-) > > BTW, is there any way you can share your proposal with the > list in more > detail? I'm having to guess at what you're doing by reading > between the > lines on these posts :( > > Giles > > > > > Neil > > > -----Original Message----- > > > From: Indra Widjaja [mailto:Indra.Widjaja@fnc.fujitsu.com] > > > Sent: 14 February 2001 21:28 > > > To: Ben Mack-Crane > > > Cc: erosen@cisco.com; neil.2.harrison@bt.com; kireeti@juniper.net; > > > mpls@UU.NET > > > Subject: Re: PHP negotiation > > > > > > > > > Hi Ben and Neil: > > > > > > If I may get back to the technical discussion on why PHP > > > impacts OAM ... > > > > > > I still don't quite understand how PHP would specifically > > > break the behavior > > > of your OAM proposal. > > > > > > Behavior 1: OAM with PHP > > > Penultimate node pops the top label and sends an OAM packet > > > to the ultimate node. > > > Upon receiving the packet, the ultimate node sees an OAM > > > alert label and > > > forwards the packet to the local OAM engine for further > processing. > > > > > > Behavior 2: OAM without PHP > > > Penultimate node forwards an OAM packet without popping > the top label. > > > Upon receiving the packet, the ultimate node pops the top label. > > > Since the next label indicates an OAM alert label, the packet > > > is forwarded > > > to the local OAM engine for further processing. > > > > > > So it looks like the OAM engine will see no difference in the > > > two behaviors. > > > On the other hand, it would be different if the recently > > > popped label is saved. > > > Appreciate your clarification. > > > > > > indra > > > > > > > > > Ben Mack-Crane wrote: > > > > > > > Eric, > > > > > > > > I don't know if one could describe the OAM proposal we're > > > working on as > > > > a "connection-oriented ITU-like scheme," but I have often > > > found functional > > > > modeling of layered networks (defined by ITU) useful in > > > understanding how > > > > networks work (or fail to work) in various configurations. > > > I have even > > > > found it useful in understanding connectionless networks. > > > > > > > > It seems to me that during its evolution MPLS has developed > > > two personas. > > > > It has a connectionless persona, exemplified by features > > > like independent > > > > unsolicited label distribution and PHP. It also has > > > developed a connection- > > > > oriented persona with features like LSP tunnels and VPN > > > applications. > > > > > > > > For cases in which an LSP must have well-defined endpoints > > > and there is > > > > a need to be able to effectively detect MPLS layer defects > > > (e.g. mis-merging) > > > > some additional OAM features are needed. These OAM > > > features apply to the > > > > MPLS (shim header) packet layer, not to sub-ip layers (for > > > which similar > > > > OAM features are already defined). > > > > > > > > Regards, > > > > Ben Mack-Crane > > > > > > > > Eric Rosen wrote: > > > > > > > > > > Neil> I guess the discussion above gave enough > > > pointers as to why an > > > > > Neil> unambiguous location of the trail termination > > > function is important > > > > > > > > > > Well, I can say that it didn't give me a clue. Repeated > > > unsupported claims > > > > > that it is "vital" to follow ITU architectures just > > > aren't very persuasive. > > > > > > > > > > Are you expecting to achieve WG consensus on an OAM > > > proposal? If the > > > > > proposal is an attempt to warp an IP-based architecture > > > into some kind of > > > > > connection-oriented ITU-like scheme, my guess is that > > > there is very little > > > > > chance of achieving consensus. > > > > > > > > > > Actually, I wonder if the OAM stuff falls under the > > > charter of the CCAMP > > > > > group rather than the MPLS group. > > > > > -- > =================================================== > Giles Heron - IP Architect - Level 3 Communications > phone: +44 20 7864 0719 mobile: +44 7880 506185 > =================================================== > From owner-mpls@UU.NET Fri Feb 16 16:54:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10349 for ; Fri, 16 Feb 2001 16:54:21 -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 QQkcrf22140; Fri, 16 Feb 2001 21:54:15 GMT Received: by mail-control.mail.uu.net id QQkcrf26536 for mpls-outgoing; Fri, 16 Feb 2001 21:53:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcrf26523 for ; Fri, 16 Feb 2001 21:53:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkcrf11282 for ; Fri, 16 Feb 2001 21:53:03 GMT Received: from develop.eu.level3.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQkcrf20516 for ; Fri, 16 Feb 2001 21:53:02 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14TsoB-0000xv-00; Fri, 16 Feb 2001 21:52:55 +0000 Message-ID: <3A8DA0B1.9A0673E7@level3.net> Date: Fri, 16 Feb 2001 21:50:41 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: neil.2.harrison@bt.com, Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, mpls@UU.NET Subject: Re: MPLS OAM? (was Re: PHP negotiation) References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A8B@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 Giles, > > 1) As you said, if you know that you are using OAM, and if the stack depth without OAM label is 1, then you probably should not configure your load balancing node to hash on S-bit. Agreed (though this is rather unlikely to be configurable!) > 2) If the A-D LSP is using a label stack of depth > 1 (excluding OAM label), then S=0 in both OAM packets and user data packets. And there won't be any problem. Agreed. > 3) I think MPLS has enough capabilities for load balancing using TE methods, so that there probably is no need to do load balancing by hashing methods. Probably true for the CR-LDP and RSVP-TE case. But if you want to extend the OAM idea to support LDP then I suspect you'll have a problem with this... Giles > > Yours, > -Shahram > > > -----Original Message----- > > From: Giles Heron [mailto:giles@level3.net] > > Sent: Wednesday, February 14, 2001 6:42 AM > > To: neil.2.harrison@bt.com > > Cc: Indra.Widjaja@fnc.fujitsu.com; Ben.Mack-Crane@tellabs.com; Shahram > > Davari; mpls@UU.NET > > Subject: MPLS OAM? (was Re: PHP negotiation) > > > > > > neil.2.harrison@bt.com wrote: > > > > > > Hi Indra, > > > > > > >From a quick analysis I think you are right (Ben and > > Shahram may wish to > > > confirm this). However, this is a fortuitous consequence > > rather than a > > > planned one, ie a lack of protocol ID in the normal > > labelled header forces > > > one to create a special bottom-of-stack OAM alert label, > > and so increase the > > > label stack by + 1, thereby fortuitously negating the effect of PHP. > > > However, PHP must not be allowed on the OAM alert labelled header. > > > > Hi Neil, > > > > I think there might be a potential problem lurking in your OAM > > solution... > > > > Imagine the network shown below (apologies for the quality of my ASCII > > art): > > > > LER LSR LSR LER > > |---| |---|-----|---| |---| > > | A |-----| B | | C |-----| D | > > |---| |---|-----|---| |---| > > > > LSPs from A to D need to be load-balanced across the two > > links from B to > > C. This may be done using explicit routes, but I would expect it is > > more likely to be done using some form of automated load-balancing. > > This load-balancing is quite likely to use a hash on the top label in > > the stack. Because OAM packets will have the stack bit unset to > > indicate the presence of an additional label they will most > > likely hash > > onto a different link to user packets? So you can't be sure that the > > OAM packets have taken the same path as your data? I guess if vendors > > implement load balancing to ignore the stack bit in their hash then > > there won't be a problem, but I'll leave it to the vendors > > here present > > to comment on that ;-) > > > > BTW, is there any way you can share your proposal with the > > list in more > > detail? I'm having to guess at what you're doing by reading > > between the > > lines on these posts :( > > > > Giles > > > > > > > > Neil > > > > -----Original Message----- > > > > From: Indra Widjaja [mailto:Indra.Widjaja@fnc.fujitsu.com] > > > > Sent: 14 February 2001 21:28 > > > > To: Ben Mack-Crane > > > > Cc: erosen@cisco.com; neil.2.harrison@bt.com; kireeti@juniper.net; > > > > mpls@UU.NET > > > > Subject: Re: PHP negotiation > > > > > > > > > > > > Hi Ben and Neil: > > > > > > > > If I may get back to the technical discussion on why PHP > > > > impacts OAM ... > > > > > > > > I still don't quite understand how PHP would specifically > > > > break the behavior > > > > of your OAM proposal. > > > > > > > > Behavior 1: OAM with PHP > > > > Penultimate node pops the top label and sends an OAM packet > > > > to the ultimate node. > > > > Upon receiving the packet, the ultimate node sees an OAM > > > > alert label and > > > > forwards the packet to the local OAM engine for further > > processing. > > > > > > > > Behavior 2: OAM without PHP > > > > Penultimate node forwards an OAM packet without popping > > the top label. > > > > Upon receiving the packet, the ultimate node pops the top label. > > > > Since the next label indicates an OAM alert label, the packet > > > > is forwarded > > > > to the local OAM engine for further processing. > > > > > > > > So it looks like the OAM engine will see no difference in the > > > > two behaviors. > > > > On the other hand, it would be different if the recently > > > > popped label is saved. > > > > Appreciate your clarification. > > > > > > > > indra > > > > > > > > > > > > Ben Mack-Crane wrote: > > > > > > > > > Eric, > > > > > > > > > > I don't know if one could describe the OAM proposal we're > > > > working on as > > > > > a "connection-oriented ITU-like scheme," but I have often > > > > found functional > > > > > modeling of layered networks (defined by ITU) useful in > > > > understanding how > > > > > networks work (or fail to work) in various configurations. > > > > I have even > > > > > found it useful in understanding connectionless networks. > > > > > > > > > > It seems to me that during its evolution MPLS has developed > > > > two personas. > > > > > It has a connectionless persona, exemplified by features > > > > like independent > > > > > unsolicited label distribution and PHP. It also has > > > > developed a connection- > > > > > oriented persona with features like LSP tunnels and VPN > > > > applications. > > > > > > > > > > For cases in which an LSP must have well-defined endpoints > > > > and there is > > > > > a need to be able to effectively detect MPLS layer defects > > > > (e.g. mis-merging) > > > > > some additional OAM features are needed. These OAM > > > > features apply to the > > > > > MPLS (shim header) packet layer, not to sub-ip layers (for > > > > which similar > > > > > OAM features are already defined). > > > > > > > > > > Regards, > > > > > Ben Mack-Crane > > > > > > > > > > Eric Rosen wrote: > > > > > > > > > > > > Neil> I guess the discussion above gave enough > > > > pointers as to why an > > > > > > Neil> unambiguous location of the trail termination > > > > function is important > > > > > > > > > > > > Well, I can say that it didn't give me a clue. Repeated > > > > unsupported claims > > > > > > that it is "vital" to follow ITU architectures just > > > > aren't very persuasive. > > > > > > > > > > > > Are you expecting to achieve WG consensus on an OAM > > > > proposal? If the > > > > > > proposal is an attempt to warp an IP-based architecture > > > > into some kind of > > > > > > connection-oriented ITU-like scheme, my guess is that > > > > there is very little > > > > > > chance of achieving consensus. > > > > > > > > > > > > Actually, I wonder if the OAM stuff falls under the > > > > charter of the CCAMP > > > > > > group rather than the MPLS group. > > > > > > > > -- > > =================================================== > > Giles Heron - IP Architect - Level 3 Communications > > phone: +44 20 7864 0719 mobile: +44 7880 506185 > > =================================================== > > -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Fri Feb 16 22:02:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14693 for ; Fri, 16 Feb 2001 22:02: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 QQkcsa11762; Sat, 17 Feb 2001 03:02:28 GMT Received: by mail-control.mail.uu.net id QQkcsa08920 for mpls-outgoing; Sat, 17 Feb 2001 03:01:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcsa08875 for ; Sat, 17 Feb 2001 03:01:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcsa09517 for ; Sat, 17 Feb 2001 03:01:30 GMT Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.121.21.2]) id QQkcsa25898 for ; Sat, 17 Feb 2001 03:01:30 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Feb 2001 19:04:36 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B8B4C@ICARIAN> From: Fong Liaw To: "'lberger@movaz.com'" Cc: "'mpls@uu.net'" Subject: signaling in draft-kompella-mpls-bundle-04.txt Date: Fri, 16 Feb 2001 19:04:33 -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 Lou, I have a question regarding why the bundled draft specifies both upstream and downstream component link while GMPLS draft assumes the same link is used for both upstream and downstream LSP. I believe the GMPLS model make more sense. If we are going to assume the same link should be used for both upstream and downstream LSP, we really do not need the new component link identifier object since the RSVP HOP object already has the ability to identify a local (component) index along with an IP address. Thanks. -Fong From owner-mpls@UU.NET Sat Feb 17 04:35:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02330 for ; Sat, 17 Feb 2001 04:35: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 QQkcta24326; Sat, 17 Feb 2001 09:35:11 GMT Received: by mail-control.mail.uu.net id QQkcta11690 for mpls-outgoing; Sat, 17 Feb 2001 09:34:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkcta11670 for ; Sat, 17 Feb 2001 09:34:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkcta16931 for ; Sat, 17 Feb 2001 09:33:58 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 QQkcta22824 for ; Sat, 17 Feb 2001 09:33:58 GMT Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP; Sat, 17 Feb 2001 09:33:04 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <1RBRKKVJ>; Sat, 17 Feb 2001 09:34:08 -0000 Message-ID: To: giles@level3.net Cc: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: MPLS OAM? (was Re: PHP negotiation) Date: Sat, 17 Feb 2001 09:34:11 -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 Giles Heron [mailto:giles@level3.net] wrote on 16 February 2001 21:39 > I guess this would imply that on any set of parallel links between two > MPLS routers you'd be pushing an extra level of label to handle the > linkset? I'm not sure that's the most efficient way of doing > load-sharing? NH=> No I am not suggesting this. I am only pointing out that (architecturally) load splitting is effectively an inverse multiplexing function. This is creating lower level trails that need their own management (by whatever method one sees fit)....for example, if one of these links fail one would need to (i) know about this (ii) take appropriate consequential actions, eg stop sending traffic down it, alert Ops people, etc. All I was pointing out was that one *could* put an OAM flow on these lower level trails.....though of course you could use some other method....but the key point is they need management. > > And in any case you'd come back to the same issue. How does B decide > which packets of a given LSP from A-D need to be placed on the "upper" > link and which on the "lower"? If OAM packets are routed on > a different > physical link than user data packets then the OAM no longer > measures the > LSP accurately? NH=> As Shahram pointed out you would not hash on S bit.....assuming you wanted to do what you are suggesting. Whether the (low frequency) OAM pkt took the 1st or 2nd load sharing link would be a matter for the inverse muxing algorithm used. The OAM pkt would still measure the A-D LSP OK I think, due to these factors: - CV flow....the load sharing is (conceptually) providing resilience to the B-C partition of the trail. So providing the management of the inv muxing algorithm could detect failures and take the right actions the the CV flow would still get from A-D....and since all defects (dLOCV, dTTSI, dLoop) are only relevant at the sink point (ie at D) then these would still be detectable. - P flow....the fact that the traffic splits is irrelevant....providing it still comes back at D (there are some ordering issues here, ie if grossly out of sync then short-term measures would have errors, but this error->0 and T->large). The P flow simply measure pkt/octet loss between A and D and does not care how the pkts are routed between these. Question: I am puzzled by the requirement to measure "accurately" here. Measure what exactly? For example A-B1st-C-D is a different trail to A-B2nd-C-D....so are you implying you want to measure each trail separately or some joint metric (and which metric)? Note: OAM is not usually about accurate measurement of QoS metrics....OAM is more about detecting failures and taking appropriate consequent actions (eg protecting customer data, alerting Ops people). Accurate QoS measurements cost money to measure/collect/process/analyse, and one 1st has to define what are the 'up' and 'down' states, since the QoS metrics/objectives should really only apply to the up-state (otheriwse they can quickly become meaningless) > > [rest of original message snipped] > From owner-mpls@UU.NET Sun Feb 18 18:42:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12485 for ; Sun, 18 Feb 2001 18:42: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 QQkcyw24990; Sun, 18 Feb 2001 23:42:14 GMT Received: by mail-control.mail.uu.net id QQkcyw18366 for mpls-outgoing; Sun, 18 Feb 2001 23:41: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 QQkcyw18354 for ; Sun, 18 Feb 2001 23:41: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 QQkcyw19870 for ; Sun, 18 Feb 2001 23:40:30 GMT Received: from esngs144.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.126.247.144]) id QQkcyw07770 for ; Sun, 18 Feb 2001 23:40:29 GMT Received: from zsngd101.asiapac.nortel.com (actually znsgd101) by esngs144.nortelnetworks.com; Mon, 19 Feb 2001 07:38:06 +0800 Received: by zsngd101.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Feb 2001 07:38:38 +0800 Message-ID: <41FA509D0CF0D311B5D500508B6FE750A6931A@zmelc003.asiapac.nortel.com> From: "Callum Dodd" To: "'jorge.rodriguez@telefonica-data.com'" , mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Interoperability Juniper-Passport Date: Mon, 19 Feb 2001 07:38:35 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09A03.E9054530" 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_01C09A03.E9054530 Content-Type: text/plain Jorge, The Passports currently supports CR-LDP signalling. There are plans to support RSVP-TE, however for further information then it would be best to contact your Nortel Account Manager. Other interoperability ie ATM Ip routing etc has been tested and works very well. Regards, Callum Network Support Engineer Nortel Networks Enterprise - Data Global Customer Care Services Ph. +613 8866 4859 (ESN 640) Mob. +61 419 215 801 Fax. +613 9206 4644 > -----Original Message----- > From: jorge.rodriguez@telefonica-data.com > [SMTP:jorge.rodriguez@telefonica-data.com] > Sent: Saturday, February 17, 2001 6:47 AM > To: mpls@UU.NET; ccamp@ops.ietf.org > Subject: Interoperability Juniper-Passport > > > > > Anybody has done interoperability tests between Juniper and Passport 7000 > (Nortel)? Success? What sw releases? > I'm about to do tests in both MPLS level and with Juniper's CCC. > > If this lists weren't the right place, where could I get this kind of > information? > > I appreciate any input. > Thanks & regards, > Jorge > > ____________________________________ > Jorge Rodriguez-Gabilondo > Telefonica Data > Network Planning and Design > jorge.rodriguez@telefonica-data.com > +34 91 514 4082 > > _________________________________________________________________ > Hemos renovado nuestra web. Esperamos su visita en > http://www.telefonica-data.com > > ------_=_NextPart_001_01C09A03.E9054530 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Interoperability Juniper-Passport

Jorge,

The Passports = currently supports CR-LDP signalling.  There are plans to support = RSVP-TE, however for further information then it would be best to = contact your Nortel Account Manager.

Other = interoperability ie ATM Ip routing etc has been tested and works very = well.

Regards,

Callum

Network Support Engineer
Nortel Networks
Enterprise - Data
Global Customer Care Services
Ph. +613 8866 4859 (ESN 640)
Mob. +61 419 215 801
Fax. +613 9206 4644


    -----Original Message-----
    From:   jorge.rodriguez@telefonica-data.com = [SMTP:jorge.rodriguez@telefonica-data.com]
    Sent:   Saturday, February 17, 2001 6:47 AM
    To:     mpls@UU.NET; ccamp@ops.ietf.org
    Subject:       = Interoperability = Juniper-Passport




    Anybody has done interoperability = tests between Juniper and Passport 7000
    (Nortel)? Success? What sw = releases?
    I'm about to do tests in both MPLS = level and with Juniper's CCC.

    If this lists weren't the right place, = where could I get this kind of
    information?

    I appreciate any input.
    Thanks & regards,
    Jorge

    ____________________________________
    Jorge Rodriguez-Gabilondo
    Telefonica Data
    Network Planning and Design
    jorge.rodriguez@telefonica-data.com
    +34 91 514 4082

    _________________________________________________________= ________
    Hemos renovado nuestra web. Esperamos = su visita en
    http://www.telefonica-data.com


------_=_NextPart_001_01C09A03.E9054530-- From owner-mpls@UU.NET Mon Feb 19 00:24:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16046 for ; Mon, 19 Feb 2001 00: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 QQkczt23282; Mon, 19 Feb 2001 05:24:14 GMT Received: by mail-control.mail.uu.net id QQkczt01246 for mpls-outgoing; Mon, 19 Feb 2001 05:23: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 QQkczt01241 for ; Mon, 19 Feb 2001 05:23:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkczt28740 for ; Mon, 19 Feb 2001 05:22:34 GMT Received: from web10503.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web10503.mail.yahoo.com [216.136.130.153]) id QQkczt12354 for ; Mon, 19 Feb 2001 05:22:33 GMT Message-ID: <20010219052233.67487.qmail@web10503.mail.yahoo.com> Received: from [198.206.187.100] by web10503.mail.yahoo.com; Sun, 18 Feb 2001 21:22:33 PST Date: Sun, 18 Feb 2001 21:22:33 -0800 (PST) From: Mahadevan Iyer Subject: RE: MPLS OAM? (was Re: PHP negotiation) To: neil.2.harrison@bt.com, giles@level3.net Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk --- neil.2.harrison@bt.com wrote: > or some joint metric (and which metric)? Note: OAM > is not usually about > accurate measurement of QoS metrics....OAM is more > about detecting failures > and taking appropriate consequent actions (eg > protecting customer data, > alerting Ops people). Accurate QoS measurements > cost money to > measure/collect/process/analyse, and one 1st has to > define what are the 'up' > and 'down' states, since the QoS metrics/objectives > should really only apply > to the up-state (otheriwse they can quickly become > meaningless) Neil, From a service provider point of view, do they 1)use QoS measurements at all or are they 2)satisfied with detecting failures ? I guess this will tie into the billing/accounting for customers. As a follow up question(if the answer to the previous question is 2) could one infer that billing/accounting is not actual usage/actual volume based. The customer gets charged for whatever was negotiated upfront. If there is a problem, the provider pays whatever is mentioned in the penalty clause. Thanks __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Mon Feb 19 04:36:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00699 for ; Mon, 19 Feb 2001 04:36: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 QQkdak00251; Mon, 19 Feb 2001 09:36:00 GMT Received: by mail-control.mail.uu.net id QQkdak10871 for mpls-outgoing; Mon, 19 Feb 2001 09:35: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 QQkdak10866 for ; Mon, 19 Feb 2001 09:35:25 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 QQkdak00760 for ; Mon, 19 Feb 2001 09:35:18 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 QQkdak27207 for ; Mon, 19 Feb 2001 09:35:18 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Mon, 19 Feb 2001 09:32:52 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <1TTGZG36>; Mon, 19 Feb 2001 09:34:00 -0000 Message-ID: To: iyermahadevan@yahoo.com, giles@level3.net Cc: mpls@UU.NET Subject: RE: MPLS OAM? (was Re: PHP negotiation) Date: Mon, 19 Feb 2001 09:33:55 -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 Mahadevan Iyer [mailto:iyermahadevan@yahoo.com] wrote 19 February 2001 05:23 > --- neil.2.harrison@bt.com wrote: > > or some joint metric (and which metric)? Note: OAM > > is not usually about > > accurate measurement of QoS metrics....OAM is more > > about detecting failures > > and taking appropriate consequent actions (eg > > protecting customer data, > > alerting Ops people). Accurate QoS measurements > > cost money to > > measure/collect/process/analyse, and one 1st has to > > define what are the 'up' > > and 'down' states, since the QoS metrics/objectives > > should really only apply > > to the up-state (otheriwse they can quickly become > > meaningless) > > Neil, > > From a service provider point of view, do they 1)use > QoS measurements at all or are they 2)satisfied with > detecting failures ? NH=> This is not a simple question with a 'one solution fits all' answer. It depends on the customer and the service. And this can vary even for the same type of 'service'....for example, I can imagine various VPN-types with varying SLAs. The technological solution (ie is it SDH-based, ATM-based, FR-based, MPLS-based, IPSec-based) constrains the service and, even within a given technology type, the nature of the SLAs can vary. All I was trying to point out in the initial response was that: - OAM will not do everything one wants performance-wise (you could overload it, but my 80/20 experience suggest this is not a cost-effective route) - OAM needs augmneting by detailed population sampling (to give overall network figure of merit, which is usually not related to a given customer, and to identify latent problems) - nodal/link utilisations (that feed into planning/forecast cycle and TE activities) - and one may want to monitor UPC-like actions (ie reclassification/discards) to check traffic profiles. I am looking at OAM very much with an Operations perspective, ie I need to be able to dectect/diagnose/handle failures 1st and foremost.....once I have that sorted then I can worry about the other stuff afterwards. > > I guess this will tie into the billing/accounting for > customers. NH=> In some way yes. > > As a follow up question(if the answer to the previous > question is 2) could one infer that billing/accounting > is not actual usage/actual volume based. The customer > gets charged for whatever was negotiated upfront. If > there is a problem, the provider pays whatever is > mentioned in the penalty clause. NH=> This depends on the service and the customer. The variables here are too large to give a single answer. > From owner-mpls@UU.NET Mon Feb 19 06:17:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01301 for ; Mon, 19 Feb 2001 06:17: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 QQkdar01957; Mon, 19 Feb 2001 11:17:39 GMT Received: by mail-control.mail.uu.net id QQkdar14729 for mpls-outgoing; Mon, 19 Feb 2001 11:17: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 QQkdar14724 for ; Mon, 19 Feb 2001 11:16: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 QQkdar11806 for ; Mon, 19 Feb 2001 11:15:33 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdar29175 for ; Mon, 19 Feb 2001 11:15:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA28064 for mpls@uu.net; Mon, 19 Feb 2001 06:15: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 QQkdaq14321 for ; Mon, 19 Feb 2001 11:14: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 QQkdaq02649 for ; Mon, 19 Feb 2001 11:14:41 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkdaq04867 for ; Mon, 19 Feb 2001 11:14:41 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01204; Mon, 19 Feb 2001 06:14:38 -0500 (EST) Message-Id: <200102191114.GAA01204@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-ext-08.txt Date: Mon, 19 Feb 2001 06:14: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 : MPLS Support of Differentiated Services Author(s) : F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen Filename : draft-ietf-mpls-diff-ext-08.txt Pages : 54 Date : 16-Feb-01 This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-diff-ext-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-diff-ext-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010216130621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-ext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-ext-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010216130621.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Feb 19 06:30:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01446 for ; Mon, 19 Feb 2001 06:30: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 QQkdas21805; Mon, 19 Feb 2001 11:30:32 GMT Received: by mail-control.mail.uu.net id QQkdas15448 for mpls-outgoing; Mon, 19 Feb 2001 11: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 QQkdas15443 for ; Mon, 19 Feb 2001 11:30: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 QQkdar18765 for ; Mon, 19 Feb 2001 11:29:31 GMT From: jorge.rodriguez@telefonica-data.com Received: from infomail.es by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nie2.infomail.es [195.235.39.19]) id QQkdar26081 for ; Mon, 19 Feb 2001 11:29:31 GMT Received: from notes06.telefonica-data.com ([192.168.100.59]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #982582118.104850002; Mon, 19 Feb 2001 12:28:38 +0100 Received: by notes06.telefonica-data.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C12569F8.003EE37C ; Mon, 19 Feb 2001 12:26:54 +0100 X-Lotus-FromDomain: TTD To: mpls@UU.NET Message-ID: Date: Mon, 19 Feb 2001 12:15:45 +0100 Subject: TECHNICAL GMPLS Congress Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Infomail-Id: 982582118.28F5020A81107C.22118 Sender: owner-mpls@UU.NET Precedence: bulk Somebody recommends me a good TECHNICAL GMPLS congress? I'm interested in the interoperability issues between Juniper and the layers below. Thanks Jorge Rodriguez Gabilondo Telefonica Data _________________________________________________________________ Hemos renovado nuestra web. Esperamos su visita en http://www.telefonica-data.com From owner-mpls@UU.NET Mon Feb 19 07:55:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03090 for ; Mon, 19 Feb 2001 07:55: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 QQkdax01690; Mon, 19 Feb 2001 12:55:18 GMT Received: by mail-control.mail.uu.net id QQkdax04314 for mpls-outgoing; Mon, 19 Feb 2001 12:54:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdax04309 for ; Mon, 19 Feb 2001 12:54:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdax10473 for ; Mon, 19 Feb 2001 12:54:20 GMT From: jorge.rodriguez@telefonica-data.com Received: from infomail.es by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nie2.infomail.es [195.235.39.19]) id QQkdax00453 for ; Mon, 19 Feb 2001 12:54:19 GMT Received: from notes06.telefonica-data.com ([192.168.100.59]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #982587204.194310001; Mon, 19 Feb 2001 13:53:24 +0100 Received: by notes06.telefonica-data.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C12569F8.0046A6D7 ; Mon, 19 Feb 2001 13:51:42 +0100 X-Lotus-FromDomain: TTD To: mpls@UU.NET Message-ID: Date: Mon, 19 Feb 2001 13:56:27 +0100 Subject: Interoperability Cisco-Juniper Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Infomail-Id: 982587204.4BE7010A81107C.27204 Sender: owner-mpls@UU.NET Precedence: bulk Can somebody give me any interoperability test information with Cisco 12000 and Juniper? Sorry if this is not the proper forum... Is there another forum for this issues? _____________________________ Jorge Rodriguez Gabilondo Telefonica Network Planning and Design _________________________________________________________________ Hemos renovado nuestra web. Esperamos su visita en http://www.telefonica-data.com From owner-mpls@UU.NET Mon Feb 19 10:27:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05924 for ; Mon, 19 Feb 2001 10:27: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 QQkdbh23961; Mon, 19 Feb 2001 15:27:51 GMT Received: by mail-control.mail.uu.net id QQkdbh27174 for mpls-outgoing; Mon, 19 Feb 2001 15:27:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdbh27168 for ; Mon, 19 Feb 2001 15:27:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdbh04705 for ; Mon, 19 Feb 2001 15:26:13 GMT Received: from guayacan.uninorte.edu.co by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.72.67.3]) id QQkdbh07953 for ; Mon, 19 Feb 2001 15:26:10 GMT Received: from guayacan.uninorte.edu.co ([172.16.8.34]) by guayacan.uninorte.edu.co (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA20202 for ; Mon, 19 Feb 2001 10:25:36 -0500 Message-ID: <3A913A0E.E9DCDD08@guayacan.uninorte.edu.co> Date: Mon, 19 Feb 2001 10:21:50 -0500 From: Yezid Donoso Reply-To: ydonoso@guayacan.uninorte.edu.co Organization: Universidad del Norte X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Information about LDP tree X-Priority: 1 (Highest) Content-Type: multipart/mixed; boundary="------------D4A90C716DAB22C45E341AB5" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------D4A90C716DAB22C45E341AB5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi. I am needing more information about LDP trees (Vanilla and ER). What is the method to building these trees ??? Thank --------------D4A90C716DAB22C45E341AB5 Content-Type: text/x-vcard; charset=us-ascii; name="ydonoso.vcf" Content-Description: Card for Yezid Donoso Content-Disposition: attachment; filename="ydonoso.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Donoso;Yezid tel;work:(57)(5)3509550 x-mozilla-html:FALSE url:http://mango.uninorte.edu.co/~ydonoso/ org:Universidad del Norte;Dpto. de Sistemas adr:;;Km. 5 via a Puerto Colombia;Barranquilla;Atlantico;;Colombia version:2.1 email;internet:ydonoso@uninorte.edu.co title:Ing. Yezid Donoso Meisel note;quoted-printable:Profesor Departamento de Sistemas=0D=0ACoordinador Especializaci=F3n en Redes de Computadores=0D=0ACoordinador Laboratorio de redes de Computadores fn:Yezid Donoso Meisel end:vcard --------------D4A90C716DAB22C45E341AB5-- From owner-mpls@UU.NET Mon Feb 19 11:21:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07953 for ; Mon, 19 Feb 2001 11:21: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 QQkdbl14137; Mon, 19 Feb 2001 16:21:14 GMT Received: by mail-control.mail.uu.net id QQkdbl15285 for mpls-outgoing; Mon, 19 Feb 2001 16:20: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 QQkdbl15278 for ; Mon, 19 Feb 2001 16:20: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 QQkdbl16561 for ; Mon, 19 Feb 2001 16:20:13 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 QQkdbl12725 for ; Mon, 19 Feb 2001 16:20:12 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 RAA53938; Mon, 19 Feb 2001 17:20:02 +0100 Message-ID: <3A9147B2.D6ACA1E5@zurich.ibm.com> Date: Mon, 19 Feb 2001 17:20:02 +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: Francois Le Faucheur , mpls@UU.NET Subject: Question to draft-ietf-mpls-diff-te-ext-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, draft-ietf-mpls-diff-te-ext-00.txt describes the handling of the RSVP CLASSTYPE Object. Is it correct to say that for E-LSPs, the CLASSTYPE object should be omitted, since a single E-LSP might be associated with multiple class types? But then, omitting a CLASTYPE object automatically associates the LSP with CLASTYPE 0?!? Is omitting the correct behaviour? Thanks, -Daniel From owner-mpls@UU.NET Mon Feb 19 12:14:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09524 for ; Mon, 19 Feb 2001 12:14: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 QQkdbo27106; Mon, 19 Feb 2001 17:14:44 GMT Received: by mail-control.mail.uu.net id QQkdbo02639 for mpls-outgoing; Mon, 19 Feb 2001 17:14:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdbo02631 for ; Mon, 19 Feb 2001 17:14:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdbo03691 for ; Mon, 19 Feb 2001 17:13:33 GMT From: djiang1@lucent.com Received: from hoemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkdbo04564 for ; Mon, 19 Feb 2001 17:13:32 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA05292 for ; Mon, 19 Feb 2001 12:13:32 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA05279 for ; Mon, 19 Feb 2001 12:13:31 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA06720; Mon, 19 Feb 2001 12:13:30 -0500 (EST) Subject: CR-LDP and RSVP implementation To: mpls@UU.NET Date: Mon, 19 Feb 2001 12:10:03 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/19/2001 12:10:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Everyone, I have a question regarding CR-LDP and RSVP implementation. I guess it is possible that both CR-LDP and RSVP implementations will be supported on one LSR. However, is there any chance that both the implementations will be called for one LSP setup? Say, at the incoming interface, CR-LDP will take the PATH message and pass it to some other MPLS processes. At the out going interface, RSVP will get some message from other MPLS processes and does something in the middle and sends out another PATH message to its neighbor node. Thanks. Regards, Jane D. Jiang djiang1@lucent.com (301) 809-4497 From owner-mpls@UU.NET Mon Feb 19 12:33:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09890 for ; Mon, 19 Feb 2001 12:33:29 -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 QQkdbq15716; Mon, 19 Feb 2001 17:33:28 GMT Received: by mail-control.mail.uu.net id QQkdbq04139 for mpls-outgoing; Mon, 19 Feb 2001 17:32:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdbq04134 for ; Mon, 19 Feb 2001 17:32:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdbq15886 for ; Mon, 19 Feb 2001 17:31: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 QQkdbq18942 for ; Mon, 19 Feb 2001 17:31: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 MAA27122 for ; Mon, 19 Feb 2001 12:31:31 -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 MAA24044 for ; Mon, 19 Feb 2001 12:31:31 -0500 (EST) Message-ID: <3A91588F.B4D45E75@marconi.com> Date: Mon, 19 Feb 2001 12:31:59 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: CR-LDP and RSVP implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit djiang1@lucent.com wrote: > > I have a question regarding CR-LDP and RSVP implementation. > > I guess it is possible that both CR-LDP and RSVP implementations will > be supported on one LSR. Definitely possible. And quite probable in the future. > However, is there any chance that both the implementations will be > called for one LSP setup? Say, at the incoming interface, CR-LDP will > take the PATH message and pass it to some other MPLS processes. At > the out going interface, RSVP will get some message from other MPLS > processes and does something in the middle and sends out another PATH > message to its neighbor node. I don't think so. The only way I can picture such a setup would require a transit router's ability to terminate one LSP, then initiate setup of another, and connect them internally. Theoretically possible, but difficult to automate and of questionable utility. I think you may find MPLS networks where RSVP-TE, LDP and CR-LDP are all used for LSP setup at once. And this may well result in multiple redundant LSPs between edge nodes. But each individual LSP will almost certainly be set up through exactly one protocol. -- David From owner-mpls@UU.NET Mon Feb 19 12:53:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10212 for ; Mon, 19 Feb 2001 12:53: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 QQkdbr11747; Mon, 19 Feb 2001 17:53:47 GMT Received: by mail-control.mail.uu.net id QQkdbr05782 for mpls-outgoing; Mon, 19 Feb 2001 17:53: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 QQkdbr05777 for ; Mon, 19 Feb 2001 17:53:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdbr04421 for ; Mon, 19 Feb 2001 17:53:09 GMT Received: from femail1.sdc1.sfba.home.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail1.sdc1.sfba.home.com [24.0.95.81]) id QQkdbr16058 for ; Mon, 19 Feb 2001 17:53:09 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010219175240.VXLU24004.femail1.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Mon, 19 Feb 2001 09:52:40 -0800 Message-ID: <006201c09b01$176bfec0$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "David Charlap" , References: <3A91588F.B4D45E75@marconi.com> Subject: Re: CR-LDP and RSVP implementation Date: Mon, 19 Feb 2001 21:50:55 -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 I think one commercial MPLS stack vendor has support for one side of LSP setup using LDP(CR) and the other using RSVP. I am not sure about the extent of support. For instance Explicit and crankback semantics and how they can be translated between the two sides. However I can imagine, instead of horizontal participation of the two signaling protocols, a vertical participation where a tunnel might be setup using RSVP-TE and inside the tunnel number of LSPs to be setup using CR-LDP for instance. Again probably it is best avoided using multiple signaling protocols over a single provider network. 2547 does mention use of LDP to setup PE-PE tunnles. I remember a discussion on removing explicit reference to one particular signaling protocol from 2547. If 2547 does require LDP then probably the underlying physical connectivity between PE routers can be setup using RSVP-TE and VPNs provisioned or PE-PE (per VPN specific) inner LSPs setup using LDP. Some one can comment whether this makes sense. -Manohar ----- Original Message ----- From: "David Charlap" To: Sent: Monday, February 19, 2001 9:31 AM Subject: Re: CR-LDP and RSVP implementation > djiang1@lucent.com wrote: > > > > I have a question regarding CR-LDP and RSVP implementation. > > > > I guess it is possible that both CR-LDP and RSVP implementations will > > be supported on one LSR. > > Definitely possible. And quite probable in the future. > > > However, is there any chance that both the implementations will be > > called for one LSP setup? Say, at the incoming interface, CR-LDP will > > take the PATH message and pass it to some other MPLS processes. At > > the out going interface, RSVP will get some message from other MPLS > > processes and does something in the middle and sends out another PATH > > message to its neighbor node. > > I don't think so. > > The only way I can picture such a setup would require a transit router's > ability to terminate one LSP, then initiate setup of another, and > connect them internally. Theoretically possible, but difficult to > automate and of questionable utility. > > I think you may find MPLS networks where RSVP-TE, LDP and CR-LDP are all > used for LSP setup at once. And this may well result in multiple > redundant LSPs between edge nodes. But each individual LSP will almost > certainly be set up through exactly one protocol. > > -- David > From owner-mpls@UU.NET Mon Feb 19 13:08:03 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10603 for ; Mon, 19 Feb 2001 13:08: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 QQkdbs13739; Mon, 19 Feb 2001 18:08:00 GMT Received: by mail-control.mail.uu.net id QQkdbs20121 for mpls-outgoing; Mon, 19 Feb 2001 18:07:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdbs20089 for ; Mon, 19 Feb 2001 18:07:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdbs22396 for ; Mon, 19 Feb 2001 18:07:02 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdbs12194 for ; Mon, 19 Feb 2001 18:06:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA15773 for mpls@uu.net; Mon, 19 Feb 2001 13:06: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 QQkdbs19902 for ; Mon, 19 Feb 2001 18:06: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 QQkdbs13978 for ; Mon, 19 Feb 2001 18:05: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 QQkdbs27222 for ; Mon, 19 Feb 2001 18:05: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 KAA13862; Mon, 19 Feb 2001 10:05:21 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BHJJT>; Mon, 19 Feb 2001 10:08:30 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A91@BBY1EXM01> From: Shahram Davari To: "'Daniel N. Bauer'" , Francois Le Faucheur , mpls@UU.NET Subject: RE: Question to draft-ietf-mpls-diff-te-ext-00.txt Date: Mon, 19 Feb 2001 10:08:29 -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, > -----Original Message----- > From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] > Sent: Monday, February 19, 2001 11:20 AM > To: Francois Le Faucheur; mpls@UU.NET > Subject: Question to draft-ietf-mpls-diff-te-ext-00.txt > > > Hello, > > draft-ietf-mpls-diff-te-ext-00.txt describes the > handling of the RSVP CLASSTYPE Object. > Is it correct to say that for E-LSPs, the CLASSTYPE > object should be omitted, since a single E-LSP might > be associated with multiple class types? Any operator who wants to take advantage of Diffserv TE extension, should configure its E-LSPs to support a set of PHBs that belong to a single ClassType. So in summary to support Diffserv TE extension, a single E-LSP MUST not be associated with more than one ClassType. And in case ClassType is not "0" you MUST include it in the signaling. Yours, -Shahram But then, > omitting a CLASTYPE object automatically associates the > LSP with CLASTYPE 0?!? > Is omitting the correct behaviour? > > Thanks, > > -Daniel > From owner-mpls@UU.NET Mon Feb 19 14:10:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12206 for ; Mon, 19 Feb 2001 14:10: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 QQkdbw25742; Mon, 19 Feb 2001 19:10:07 GMT Received: by mail-control.mail.uu.net id QQkdbw02878 for mpls-outgoing; Mon, 19 Feb 2001 19:09:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdbw02847 for ; Mon, 19 Feb 2001 19:09:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdbw05299 for ; Mon, 19 Feb 2001 19:09:32 GMT Received: from ewey.excite.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ewey-rwcmta.excite.com [198.3.99.191]) id QQkdbw24936 for ; Mon, 19 Feb 2001 19:09:32 GMT Received: from scorch.excite.com ([199.172.152.240]) by ewey.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010219190931.HUIF2935.ewey.excite.com@scorch.excite.com>; Mon, 19 Feb 2001 11:09:31 -0800 Message-ID: <3747684.982609771584.JavaMail.imail@scorch.excite.com> Date: Mon, 19 Feb 2001 11:09:31 -0800 (PST) From: Mark Lewis To: jorge.rodriguez@telefonica-data.com Subject: Re: Interoperability Cisco-Juniper Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite UK Inbox X-Sender-Ip: 213.120.56.53 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Try this link: http://www.juniper.net/products/interoperability/250004.html Mark Lewis Frontrunner Solutions On Mon, 19 Feb 2001 13:56:27 +0100, jorge.rodriguez@telefonica-data.com wrote: > > > > Can somebody give me any interoperability test information with Cisco 12000 and > Juniper? > > Sorry if this is not the proper forum... Is there another forum for this issues? > > _____________________________ > Jorge Rodriguez Gabilondo > Telefonica > Network Planning and Design > > > _________________________________________________________________ > Hemos renovado nuestra web. Esperamos su visita en > http://www.telefonica-data.com > > _______________________________________________________ Get 100% private, FREE email for life from Excite UK Visit http://inbox.excite.co.uk/ From owner-mpls@UU.NET Mon Feb 19 15:32:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14087 for ; Mon, 19 Feb 2001 15:32: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 QQkdcc20696; Mon, 19 Feb 2001 20:32:45 GMT Received: by mail-control.mail.uu.net id QQkdcc00627 for mpls-outgoing; Mon, 19 Feb 2001 20:32: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 QQkdcc00614 for ; Mon, 19 Feb 2001 20:32:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdcc22096 for ; Mon, 19 Feb 2001 20:31:59 GMT Received: from develop.eu.level3.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQkdcc05345 for ; Mon, 19 Feb 2001 20:31:58 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14UwyJ-0006OI-00; Mon, 19 Feb 2001 20:31:47 +0000 Message-ID: <3A9182B0.C9896A12@level3.net> Date: Mon, 19 Feb 2001 20:31:44 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: Re: MPLS OAM? (was Re: PHP negotiation) 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: > > Giles Heron [mailto:giles@level3.net] wrote on 16 February 2001 21:39 > > > I guess this would imply that on any set of parallel links between two > > MPLS routers you'd be pushing an extra level of label to handle the > > linkset? I'm not sure that's the most efficient way of doing > > load-sharing? > NH=> No I am not suggesting this. I am only pointing out that > (architecturally) load splitting is effectively an inverse multiplexing > function. This is creating lower level trails that need their own > management (by whatever method one sees fit)....for example, if one of these > links fail one would need to (i) know about this (ii) take appropriate > consequential actions, eg stop sending traffic down it, alert Ops people, > etc. All I was pointing out was that one *could* put an OAM flow on these > lower level trails.....though of course you could use some other > method....but the key point is they need management. Agreed, these links need management. But they are under the control of the IGP, so there is no need to do any "trail" management on them. Wonderful things these IGPs ;-) > > And in any case you'd come back to the same issue. How does B decide > > which packets of a given LSP from A-D need to be placed on the "upper" > > link and which on the "lower"? If OAM packets are routed on > > a different > > physical link than user data packets then the OAM no longer > > measures the > > LSP accurately? > NH=> As Shahram pointed out you would not hash on S bit.....assuming you > wanted to do what you are suggesting. Whether the (low frequency) OAM pkt > took the 1st or 2nd load sharing link would be a matter for the inverse > muxing algorithm used. The OAM pkt would still measure the A-D LSP OK I > think, due to these factors: > - CV flow....the load sharing is (conceptually) providing resilience > to the B-C partition of the trail. So providing the management of the inv > muxing algorithm could detect failures and take the right actions the the CV > flow would still get from A-D....and since all defects (dLOCV, dTTSI, dLoop) > are only relevant at the sink point (ie at D) then these would still be > detectable. > - P flow....the fact that the traffic splits is > irrelevant....providing it still comes back at D (there are some ordering > issues here, ie if grossly out of sync then short-term measures would have > errors, but this error->0 and T->large). The P flow simply measure > pkt/octet loss between A and D and does not care how the pkts are routed > between these. I don't think the traffic split is irrelevant at all. If the OAM flow follows a different path to the user data flow for any reason (for example load sharing algorithms that include the S bit) then the P flow measurements may be inaccurate (for example due to congestion/bit errors on one of the links.) I would be surprised if any of the equipment vendors have thought to exclude the S bit from their hash functions (though I am prepared to be proven wrong on this point.) (As Shahram has pointed out this may be moot if MPLS TE is used, since a given LSP from A to D would be explicity routed over either B1st-C or B2nd-C.) > Question: I am puzzled by the requirement to measure "accurately" here. > Measure what exactly? For example A-B1st-C-D is a different trail to > A-B2nd-C-D....so are you implying you want to measure each trail separately > or some joint metric (and which metric)? Note: OAM is not usually about > accurate measurement of QoS metrics....OAM is more about detecting failures > and taking appropriate consequent actions (eg protecting customer data, > alerting Ops people). Accurate QoS measurements cost money to > measure/collect/process/analyse, and one 1st has to define what are the 'up' > and 'down' states, since the QoS metrics/objectives should really only apply > to the up-state (otheriwse they can quickly become meaningless) What I want to do is to measure, reasonably accurately, the packet loss (and latency) of any given LSP through the network. This is useful for SLA monitoring etc. Whether this is strictly an "OAM" function doesn't concern me overly. If this can be done as a small delta to providing an OAM facility without this capability then it would seem like a good idea (presumably that is the reason you specified the P flow in the first place?) Giles -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Tue Feb 20 02:22:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08476 for ; Tue, 20 Feb 2001 02:22: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 QQkddt27915; Tue, 20 Feb 2001 07:22:13 GMT Received: by mail-control.mail.uu.net id QQkddt11446 for mpls-outgoing; Tue, 20 Feb 2001 07:21:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkddt11441 for ; Tue, 20 Feb 2001 07:21:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkddt17649 for ; Tue, 20 Feb 2001 07:21:18 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 QQkddt26722 for ; Tue, 20 Feb 2001 07:21:17 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 IAA55196; Tue, 20 Feb 2001 08:20:33 +0100 Message-ID: <3A921AC0.B712B8AC@zurich.ibm.com> Date: Tue, 20 Feb 2001 08:20:32 +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, Francois Le Faucheur Subject: Re: Question to draft-ietf-mpls-diff-te-ext-00.txt References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A91@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, thanks for your reply. From your answer, it follows that if the PHBs of an E-LSP span multiple class types, then a PathErr with code `Diff-Serv TE Error' and some value indicating the error condition should be sent towards the sender. Otherwise, unexpected results may occur. -Daniel Shahram Davari wrote: > > Hi, > > > -----Original Message----- > > From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] > > Sent: Monday, February 19, 2001 11:20 AM > > To: Francois Le Faucheur; mpls@UU.NET > > Subject: Question to draft-ietf-mpls-diff-te-ext-00.txt > > > > > > Hello, > > > > draft-ietf-mpls-diff-te-ext-00.txt describes the > > handling of the RSVP CLASSTYPE Object. > > Is it correct to say that for E-LSPs, the CLASSTYPE > > object should be omitted, since a single E-LSP might > > be associated with multiple class types? > > Any operator who wants to take advantage of Diffserv TE extension, should configure its E-LSPs to support a set of PHBs that belong to a single ClassType. So in summary to support Diffserv TE extension, a single E-LSP MUST not be associated with more than one ClassType. And in case ClassType is not "0" you MUST include it in the signaling. > > Yours, > -Shahram > > But then, > > omitting a CLASTYPE object automatically associates the > > LSP with CLASTYPE 0?!? > > Is omitting the correct behaviour? > > > > Thanks, > > > > -Daniel > > From owner-mpls@UU.NET Tue Feb 20 04:57:37 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09483 for ; Tue, 20 Feb 2001 04:57: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 QQkded26700; Tue, 20 Feb 2001 09:57:35 GMT Received: by mail-control.mail.uu.net id QQkded18387 for mpls-outgoing; Tue, 20 Feb 2001 09:57:06 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 QQkded18382 for ; Tue, 20 Feb 2001 09:56:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkded16099 for ; Tue, 20 Feb 2001 09:56:05 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkded24638 for ; Tue, 20 Feb 2001 09:56:04 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA02117 for ; Tue, 20 Feb 2001 04:56:04 -0500 (EST) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA02081 for ; Tue, 20 Feb 2001 04:56:02 -0500 (EST) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <1GKM3BDS>; Tue, 20 Feb 2001 15:25:58 +0530 Message-ID: From: "B, Prakash K (Prakash)" To: "'mpls@uu.net'" Subject: Hop Count Procedures Date: Tue, 20 Feb 2001 15:25:56 +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 ATM LSRS do not perform TTL decrement. RFC 3036 says that while propogating the label mapping message upstream, if an LSR (Rd) finds out that its upstream LSR (Ru) is a part of domain that does not perform TTL decrement(ATM segment), it must reset the Hop Count value to 1. Will this not lead to erroneous computation of final TTL in the long run when the packet exits out of MPLS domain?Will not the true Hop count value assist the ingress in determining in advance the TTL value that must be, when the packet emerges out of a Non -TTL-decrement segment? RFC 3031 clearly states that the final TTL value must reflect the true number of hops that a packet takes to exit a MPLS domain . Clarification solicited. Prakash K.B. From owner-mpls@UU.NET Tue Feb 20 05:18:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09603 for ; Tue, 20 Feb 2001 05: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 QQkdef23155; Tue, 20 Feb 2001 10:18:20 GMT Received: by mail-control.mail.uu.net id QQkdef03384 for mpls-outgoing; Tue, 20 Feb 2001 10:17:50 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 QQkdef03379 for ; Tue, 20 Feb 2001 10:17: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 QQkdef20640 for ; Tue, 20 Feb 2001 10:17:30 GMT Received: from EXCHANGE.kerenix.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.150.1.82]) id QQkdef07514 for ; Tue, 20 Feb 2001 10:17:29 GMT Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id <1086C430>; Tue, 20 Feb 2001 12:18:51 +0200 Message-ID: <2B15221907365C468941FDFC02C87769CED2@EXCHANGE.kerenix.com> From: Vadim Suraev To: "'Daniel N. Bauer'" Cc: mpls@UU.NET, Francois Le Faucheur Subject: RE: Question to draft-ietf-mpls-diff-te-ext-00.txt Date: Tue, 20 Feb 2001 12:18:40 +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 Daniel, I think, if I'm not mistaken, draft-ietf-mpls-diff-te-ext-00.txt does not imply PathErr with code `Diff-Serv TE Error' is to be sent in this case since this draft does not define (should not define?): 1. How PHBs are mapped into Class Type; 2. Which PHBs exist in Class Type; 3. A way to check, if PHBs which are carried by E-LSP, match the signaled Class Type; However IMHO, you have to avoid signaling EXP<-->PHB mappings (draft-ietf-mpls-diff-ext-07.txt) in such a way that will cause the same PHB to be associated with different Class Types or you have to avoid signaling the different Class Types for E-LSP if EXP<-->PHB mapping is preconfigured. Otherwise, one class, say EF, may allocate BW from each Class Type's (0,1,2) pool , for example. -----Original Message----- From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] Sent: Tuesday, February 20, 2001 9:21 AM To: Shahram Davari Cc: mpls@UU.NET; Francois Le Faucheur Subject: Re: Question to draft-ietf-mpls-diff-te-ext-00.txt Shahram, thanks for your reply. From your answer, it follows that if the PHBs of an E-LSP span multiple class types, then a PathErr with code `Diff-Serv TE Error' and some value indicating the error condition should be sent towards the sender. Otherwise, unexpected results may occur. -Daniel Shahram Davari wrote: > > Hi, > > > -----Original Message----- > > From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] > > Sent: Monday, February 19, 2001 11:20 AM > > To: Francois Le Faucheur; mpls@UU.NET > > Subject: Question to draft-ietf-mpls-diff-te-ext-00.txt > > > > > > Hello, > > > > draft-ietf-mpls-diff-te-ext-00.txt describes the > > handling of the RSVP CLASSTYPE Object. > > Is it correct to say that for E-LSPs, the CLASSTYPE > > object should be omitted, since a single E-LSP might > > be associated with multiple class types? > > Any operator who wants to take advantage of Diffserv TE extension, should configure its E-LSPs to support a set of PHBs that belong to a single ClassType. So in summary to support Diffserv TE extension, a single E-LSP MUST not be associated with more than one ClassType. And in case ClassType is not "0" you MUST include it in the signaling. > > Yours, > -Shahram > > But then, > > omitting a CLASTYPE object automatically associates the > > LSP with CLASTYPE 0?!? > > Is omitting the correct behaviour? > > > > Thanks, > > > > -Daniel > > From owner-mpls@UU.NET Tue Feb 20 07:16:55 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10731 for ; Tue, 20 Feb 2001 07:16: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 QQkden21976; Tue, 20 Feb 2001 12:16:52 GMT Received: by mail-control.mail.uu.net id QQkden08006 for mpls-outgoing; Tue, 20 Feb 2001 12:16:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkden07999 for ; Tue, 20 Feb 2001 12:16:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkden24174 for ; Tue, 20 Feb 2001 12:16:01 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkden20690 for ; Tue, 20 Feb 2001 12:16:00 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA22665 for mpls@uu.net; Tue, 20 Feb 2001 07:15:59 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkden07837 for ; Tue, 20 Feb 2001 12:15:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdem21510 for ; Tue, 20 Feb 2001 12:14:52 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 QQkdem19018 for ; Tue, 20 Feb 2001 12:14:42 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 EAA25836; Tue, 20 Feb 2001 04:14:19 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BH4HP>; Tue, 20 Feb 2001 04:17:29 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A93@BBY1EXM01> From: Shahram Davari To: "'Vadim Suraev'" , "'Daniel N. Bauer'" Cc: mpls@UU.NET, Francois Le Faucheur Subject: RE: Question to draft-ietf-mpls-diff-te-ext-00.txt Date: Tue, 20 Feb 2001 04:17:29 -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, I also think that dealing with this scenario is not addressed in the draft, and is probably left to the operator. Yours, -Shahram > -----Original Message----- > From: Vadim Suraev [mailto:Vadim_Suraev@KereniX.com] > Sent: Tuesday, February 20, 2001 5:19 AM > To: 'Daniel N. Bauer' > Cc: mpls@UU.NET; Francois Le Faucheur > Subject: RE: Question to draft-ietf-mpls-diff-te-ext-00.txt > > > Daniel, > I think, if I'm not mistaken, > draft-ietf-mpls-diff-te-ext-00.txt does not > imply > PathErr with code `Diff-Serv TE Error' is to be sent in this > case since > this draft does not define (should not define?): > 1. How PHBs are mapped into Class Type; > 2. Which PHBs exist in Class Type; > 3. A way to check, if PHBs which are carried by E-LSP, > match the signaled > Class Type; > > However IMHO, you have to avoid signaling EXP<-->PHB mappings > (draft-ietf-mpls-diff-ext-07.txt) > in such a way that will cause the same PHB to be associated > with different > Class Types > or you have to avoid signaling the different Class Types for E-LSP if > EXP<-->PHB mapping is preconfigured. > Otherwise, one class, say EF, may allocate BW from each Class > Type's (0,1,2) > pool , for example. > > -----Original Message----- > From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] > Sent: Tuesday, February 20, 2001 9:21 AM > To: Shahram Davari > Cc: mpls@UU.NET; Francois Le Faucheur > Subject: Re: Question to draft-ietf-mpls-diff-te-ext-00.txt > > > Shahram, > > thanks for your reply. > > From your answer, it follows that if the PHBs > of an E-LSP span multiple class types, then > a PathErr with code `Diff-Serv TE Error' and > some value indicating the error condition > should be sent towards the sender. Otherwise, > unexpected results may occur. > > -Daniel > > > Shahram Davari wrote: > > > > Hi, > > > > > -----Original Message----- > > > From: Daniel N. Bauer [mailto:dnb@zurich.ibm.com] > > > Sent: Monday, February 19, 2001 11:20 AM > > > To: Francois Le Faucheur; mpls@UU.NET > > > Subject: Question to draft-ietf-mpls-diff-te-ext-00.txt > > > > > > > > > Hello, > > > > > > draft-ietf-mpls-diff-te-ext-00.txt describes the > > > handling of the RSVP CLASSTYPE Object. > > > Is it correct to say that for E-LSPs, the CLASSTYPE > > > object should be omitted, since a single E-LSP might > > > be associated with multiple class types? > > > > Any operator who wants to take advantage of Diffserv TE > extension, should > configure its E-LSPs to support a set of PHBs that belong to a single > ClassType. So in summary to support Diffserv TE extension, a > single E-LSP > MUST not be associated with more than one ClassType. And in > case ClassType > is not "0" you MUST include it in the signaling. > > > > Yours, > > -Shahram > > > > But then, > > > omitting a CLASTYPE object automatically associates the > > > LSP with CLASTYPE 0?!? > > > Is omitting the correct behaviour? > > > > > > Thanks, > > > > > > -Daniel > > > > From owner-mpls@UU.NET Tue Feb 20 07:42:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11082 for ; Tue, 20 Feb 2001 07:42: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 QQkdeo29539; Tue, 20 Feb 2001 12:42:03 GMT Received: by mail-control.mail.uu.net id QQkdeo09525 for mpls-outgoing; Tue, 20 Feb 2001 12:41: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 QQkdeo09520 for ; Tue, 20 Feb 2001 12:41:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdeo04186 for ; Tue, 20 Feb 2001 12:41:03 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkdeo08305 for ; Tue, 20 Feb 2001 12:41:03 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Tue, 20 Feb 2001 12:41:48 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id <1PCPCPJA>; Tue, 20 Feb 2001 12:40:52 -0000 Message-ID: To: giles@level3.net Cc: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: MPLS OAM? (was Re: PHP negotiation) Date: Tue, 20 Feb 2001 12:40:52 -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 Giles, you asked: > What I want to do is to measure, reasonably accurately, the > packet loss > (and latency) of any given LSP through the network. This is > useful for > SLA monitoring etc. Whether this is strictly an "OAM" > function doesn't > concern me overly. If this can be done as a small delta to > providing an > OAM facility without this capability then it would seem like > a good idea > (presumably that is the reason you specified the P flow in the first > place?) NH=> Yes. But the only metrics I have considered so far are loss. We could add others (like errors and delay) but I have not considered these at this time to keep it simple.....indeed, initally I wondered whether we should be trying to do any QoS measurements at all above basic defect handling. But if other metrics are considered important then these should be considered....noting that there is a cost associated with their measurement/processing so the wish list should not be too large. From owner-mpls@UU.NET Tue Feb 20 08:17:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11576 for ; Tue, 20 Feb 2001 08:17: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 QQkder15351; Tue, 20 Feb 2001 13:17:07 GMT Received: by mail-control.mail.uu.net id QQkder25836 for mpls-outgoing; Tue, 20 Feb 2001 13:16: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 QQkder25831 for ; Tue, 20 Feb 2001 13:16:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkder16465 for ; Tue, 20 Feb 2001 13:16:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkder13710 for ; Tue, 20 Feb 2001 13:15:56 GMT Received: from gmarceli-u10.cisco.com (gmarceli-u10.cisco.com [161.44.134.107]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA25896 for ; Tue, 20 Feb 2001 08:15:55 -0500 (EST) Received: (erosen@localhost) by gmarceli-u10.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id IAA29870 for mpls@uu.net; Tue, 20 Feb 2001 08:15:54 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdbt22008 for ; Mon, 19 Feb 2001 18:29:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdbt00171 for ; Mon, 19 Feb 2001 18:28:54 GMT Received: from smtp1.gtsgroup.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp1.gtsgroup.com [195.158.230.16]) id QQkdbt11343 for ; Mon, 19 Feb 2001 18:28:53 GMT Received: from 207.77.231.73 by smtp1.gtsgroup.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 19:21:31 +0100 (W. Europe Standard Time) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Feb 2001 19:26:31 +0100 Message-ID: From: "Mannie, Eric" To: "'Maarten Vissers'" Cc: ip-optical@lists.bell-labs.com, "Ben Mack-Crane (E-mail)" , "Greg Bernstein (E-mail)" , "Bala Rajagopalan (E-mail)" , "Debanjan Saha (E-mail)" , "Michael Raftelis (E-mail)" , "Shash Chatterjee (E-mail)" , "Jeff Connell (E-mail)" , "Xu, Yangguang" , "Lin, Zhi-Wei (Zhi)" , Vishal Sharma , "'ccamp@ops.ietf.org'" , "'mpls@uu.net'" Subject: RE: [IP-Optical] GMPLS enhancements Date: Mon, 19 Feb 2001 19:26:30 +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 Hi Maarten, I think that you misunderstood some important things about the label, I'll try to clarify in the following. First, as you know, - All AUGs ("STM-1s" ) in an STM-N are byte interleaved : no hierarchy, "flat" stuff ! - The AUs, TUGs, TUs in an AUG ("STM-1") are nested following some specific rules: "tree-like" hierarchy. - A label identifies the first time-slot (or component) of a particular signal, not the full aggregate. Consequently, you need separate values to identify the nesting (UKLM) and only one value to identify any component in the interleaving (S = index). We just need to identify ONE STM-1/AUG in a group of N STM-1s/AUGs. The S field is a simple index, it is flat and there is no reason to represent something flat as a hierarchy. So there is no reason to use E, D, C, B ! And yes, one STM-1 can be seen as a time-slot if all STM-1s are (logically) time-division multiplexed. For instance, if you want to transport four STM-1s "transparently" you will have four STM-1s, each one with an independent overhead. This can be achieved by interleaving the four overheads, or by tunneling the overheads. How this transparency is achieved is proprietary in the data plane, different vendors have different solutions. At least we would like to have a standardized solution to request and use it in the control plane. I understand your confusion since we don't use a regular SDH/SONET, but their are common tricks that vendors are implementing and that are useful to control in a generic way via the GMPLS control plane. So, we are not 100% glued to G.707. The same apply for protection/restoration since we are not tied anymore to only the protection/restoration schemes standardized by ITU-T, the fast meshed restoration is an example. In addition, you want to indicate some fixed concatenation levels (AU-4-4c, AU-4-16c, AU-4-64c and AU-4-256c) in the label. This is not appropriate since there are plenty of other different levels of concatenation, indeed all levels are possible, e.g. AU-4-7c. The concatenation is anyway better indicated separately, it is orthogonal with a label. Think also about contiguous concatenation for example, I could want to concatenate the 3rd, 4th and 5th STM-1/AUG, so I just need to say S=3 to indicate where begins my concatenation. Arbitrary concatenation is commonly used. Moreover, we want to be able to manipulate circuits of any size, concatenated or not (e.g. an STM-7 or STM-255). With you proposal it would be impossible to do so since we can only encode the index of a few time-slots. We really need to encode the index of each possible STM-1/AUG. We go further than a pure G.707. Concerning your comment about SDH ADM and cross connect equipment that may have separate Higher Order and Lower Order fabrics, please refer to our discussion that occurred two months ago when I explained the nesting of LSPs and how it can be applied to SDH/SONET. One of the benefits of GMPLS is to allow different classes of equipments, those that can switch higher orders in the core and those that can switches lower orders in the metro/access. Indeed, you can design any kind of equipment. Circuits are just nested in circuits. That's why the higher part or lower part of a label (respectively) can be zeroed to indicate irrelevant (see editorial bug that we discussed, should be corrected in the next version of GMPLS, S=0 is valid). Kind regards, Eric > Note that the latest version of G.707 (10/00) has defined a naming > structure for the AU's, similar to that for the TU's. AUs are now named > according the EDCBA structure (TUs are named according the KLM > structure). It is thus possible to replace the S,U number by the > standardised number E,D,C,B,A. The specification could be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | E | D | C | B | A | K | L | M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For SDH, this is an extension of the numbering scheme defined in > G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For > SONET the K field is not significant and must be set to zero. > > Each letter indicates a possible branch number starting at the parent > node in the multiplex structure. Branches are considered as numbered > in increasing order, starting from the top of the multiplexing > structure. The numbering starts at 1, zero is used to indicate a non- > significant field. > > When a field is not significant in a particular context it MUST be > set to zero when transmitted, and MUST be ignored when received. > > 1. E indicates possible branches of a STM-256/OC786. It is not > meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12, > STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case. > E=1 indicates that the STM-256/OC768 is not further sub-divided > and contains an AU-4-256c/STS768c. > E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768. > > 2. D indicates possible branches of either an AUG-64 or a > STM-64/OC192. > It is not meaningful for the cases of STM-16/OC48, STM-4/OC12, > STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case. > D=1 indicates that the AUG-64 or STM-64/OC192 is not further > sub-divided and contains an AU-4-64c/STS192c. > D=2->5 indicates a specific AUG-16 inside the given AUG-64 or > STM-64/OC192. > > 3. C indicates possible branches of either an AUG-16 or a > STM-16/OC48. > It is not meaningful for the cases of STM-4/OC12, STM-1/OC3, > STM-0/OC1 multiplexing and must be 0 in that case. > C=1 indicates that the AUG-16 or STM-16/OC48 is not further > sub-divided and contains an AU-4-16c/STS48c. > C=2->5 indicates a specific AUG-4 inside the given AUG-16 or > STM-16/OC48. > > 4. B indicates possible branches of either an AUG-4 or a STM-4/OC12. > It is not meaningful for the cases of STM-1/OC3, STM-0/OC1 > multiplexing and must be 0 in that case. > B=1 indicates that the AUG-4 or STM-4/OC12 is not further > sub-divided and contains an AU-4-4c/STS12c. > B=2->5 indicates a specific AUG-1 inside the given AUG-4 or > STM-4/OC12. > > 5. A indicates possible branches of either an AUG-1 or a STM-1/OC3. > It is not meaningful for the case of STM-0/OC1 multiplexing > and must be 0 in that case. A=1 indicates that the AUG-1 or > STM-1/OC3 is not further sub-divided and contains an > AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given > AUG-1 or STM-1/OC3. > > 6. K is only significant for SDH and must be ignored for SONET. It > indicates a specific branch of a VC-4. K=1 indicates that the > VC-4 is not further sub-divided and contains a C-4. K=2->4 > indicates a specific TUG-3 inside the VC-4. K is not > significant when the STM-1 is divided into VC-3s (easy to read > and test). > > 7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It > is not significant for an unstructured VC-4. L=1 indicates that > the TUG-3/VC-3/STS-1 SPE is not further sub-divided and > contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 > indicates a specific TUG-2/VT Group inside the corresponding > higher order signal. > > 8. M indicates a specific branch of a TUG-2/VT Group. It is not > significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 > SPE. M=1 indicates that the TUG-2/VT Group is not further > sub-divided and contains a VC-2/VT-6. M=2->3 indicates a > specific VT-3 inside the corresponding VT Group, these values > MUST NOT be used for SDH since there is no equivalent of VT-3 > with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the > corresponding TUG-2/VT Group. M=7->10 indicates a specific > VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried > within a TU-11. M=11->13 indicates a specific VC-11 inside the > corresponding TUG-2 carried within a TU-12. Note that M=0 denotes > an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). > > Some examples: > EDCBAKLM > - 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0) > in a STM-16/OC48 > - 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768 > - 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0) > in a STM-256/OC768 > - 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192 > - 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal. > > The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3) > structure in a STM-16 could then consist of the following set of labels: > > EDCBAKLM > - 00210000 AU-4-4c (1,0,0) > - 00321000 AU-4 (2,1,0) > - 00331000 AU-4 (2,2,0) > - 00341000 AU-4 (2,3,0) > - 00351000 AU-4 (2,4,0) > - 00410000 AU-4-4c (3,0,0) > - 00521000 AU-4 (4,1,0) > - 00532000 AU-3 (4,2,1) > - 00533000 AU-3 (4,2,2) > - 00534000 AU-3 (4,2,3) > - 00541000 AU-4 (4,3,0) > - 00551000 AU-4 (4,4,0) > > For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering > scheme has the bandwidth implied. There is no need to code this > bandwidth seperately anylonger. > > Question related to the definition of "M": > ------------------------------------------ > "M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to > transport a VC-11 via a TU-12, I believe that the M range should be > extended with values 11 to 13 as follows: > > The M encoding is summarized in the following table: > > M SDH SONET > ---------------------------------------------------------- > 0 unstructured VC-4/VC-3 unstructured STS-1 SPE > 1 VC-2 VT-6 > 2 - 1st VT-3 > 3 - 2nd VT-3 > 4 1st VC-12 1st VT-2 > 5 2nd VC-12 2nd VT-2 > 6 3rd VC-12 3rd VT-2 > 7 1st VC-11 in TU-11 1st VT-1.5 > 8 2nd VC-11 in TU-11 2nd VT-1.5 > 9 3rd VC-11 in TU-11 3rd VT-1.5 > 10 4th VC-11 in TU-11 4th VT-1.5 > 11 1st VC-11 in TU-12 - > 12 2nd VC-11 in TU-12 - > 13 3rd VC-11 in TU-12 - > > At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive > monitors) as a VC-12. At the path endpoints however, the VC-11 is > treated as a VC-11. > > Coding the lower order VC (LOVC)/VT signals: > -------------------------------------------- > SDH ADM and cross connect equipment may have separate Higher Order and > Lower Order fabrics. This decouples the TU identification from the AU > timeslot and associated physical port. I.e. EDCBAKLM label should be > split into separate EDCBA and KLM labels. > > Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M" > VC4 termination points connected to the LO Fabric. > > The TU timeslots are defined with reference to a VC4 termination point. > The VC4 signal geenrated by a VC4 termination point can be transported > over any of the STM-N signals; there is no predefined relationship, > neither is there a permanent relationship (i.e. it is possible to > re-route the VC-4 without tearing it down, or tearing down the LOVC > connection over it). > > As such, the TU timeslots should be numbered with respect to its VC4 > termination point, not with respect to the AU4 timeslot in an STM-N; The > AU4/STM-N part of the label may change over time, whereas the TU link > connection and TU connection point stay the same. > Resulting label should be "". > > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO > FABRIC > signal PORT timeslots | | Term. timeslots > | | Points per VC4 TP > | | > STM-N --- PHY --- "N" AU -------| | > timeslots | > STM-N --- PHY --- "N" AU ----------| > timeslots > > Figure 1 - SDH ADM with separate HO and LO Fabrics > > The HO Fabric contains the relation between AU number and VC4 TP number, > as well as between between two AU numbers (case of STM-N - AU - STM-N > connection). > > <-- phys. <--- EDCBA <--- VC4 <--- KLM > port AU TP TU > number number number number > > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO > FABRIC > signal PORT timeslots | | Term. timeslots > | | Points per VC4 TP > > Figure 2 - numbering > > Regards, > > Maarten From owner-mpls@UU.NET Tue Feb 20 10:20:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13301 for ; Tue, 20 Feb 2001 10:20: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 QQkdez08611; Tue, 20 Feb 2001 15:20:32 GMT Received: by mail-control.mail.uu.net id QQkdez01816 for mpls-outgoing; Tue, 20 Feb 2001 15:20:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdez01806 for ; Tue, 20 Feb 2001 15:20:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdez22602 for ; Tue, 20 Feb 2001 15:18:44 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdez05987 for ; Tue, 20 Feb 2001 15:18:43 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id 9C14594007; Tue, 20 Feb 2001 10:18:43 -0500 (EST) Message-ID: <3A928AD3.84D8E36C@sandburst.com> Date: Tue, 20 Feb 2001 10:18:43 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: CR-LDP and RSVP implementation References: <3A91588F.B4D45E75@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Hmmm. There is the interworking scenario: --- R1 --- R2 --- R3 --- in which R1 only "speaks" CR-LDP/LDP and R3 only speaks RSVP-TE (and maybe LDP). In this scenario, it is quite reasonable for R2 to "translate" between the two protocols for LSP set-up. Also, there is very little difference between setting up a single LSP through (for example) R2 above and terminating one LSP (from R1, for instance), making a new LSP (toward R3) and connecting them internally (at R2) - as long as the mapping (might be a FEC) is one-to-one from one LSP to the other. -- Eric Gray You wrote: > djiang1@lucent.com wrote: > > > > I have a question regarding CR-LDP and RSVP implementation. > > > > I guess it is possible that both CR-LDP and RSVP implementations will > > be supported on one LSR. > > Definitely possible. And quite probable in the future. > > > However, is there any chance that both the implementations will be > > called for one LSP setup? Say, at the incoming interface, CR-LDP will > > take the PATH message and pass it to some other MPLS processes. At > > the out going interface, RSVP will get some message from other MPLS > > processes and does something in the middle and sends out another PATH > > message to its neighbor node. > > I don't think so. > > The only way I can picture such a setup would require a transit router's > ability to terminate one LSP, then initiate setup of another, and > connect them internally. Theoretically possible, but difficult to > automate and of questionable utility. > > I think you may find MPLS networks where RSVP-TE, LDP and CR-LDP are all > used for LSP setup at once. And this may well result in multiple > redundant LSPs between edge nodes. But each individual LSP will almost > certainly be set up through exactly one protocol. > > -- David From owner-mpls@UU.NET Tue Feb 20 10:28:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13857 for ; Tue, 20 Feb 2001 10:28: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 QQkdez08188; Tue, 20 Feb 2001 15:28:46 GMT Received: by mail-control.mail.uu.net id QQkdez02591 for mpls-outgoing; Tue, 20 Feb 2001 15:28: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 QQkdez02566 for ; Tue, 20 Feb 2001 15:27:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdez10624 for ; Tue, 20 Feb 2001 15:27:49 GMT Received: from develop.eu.level3.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQkdez06778 for ; Tue, 20 Feb 2001 15:27:48 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14VEgo-0001kc-00; Tue, 20 Feb 2001 15:26:54 +0000 Message-ID: <3A928CBC.40D4714F@level3.net> Date: Tue, 20 Feb 2001 15:26:52 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: Re: MPLS OAM? (was Re: PHP negotiation) 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: > > Hi Giles, you asked: > > > What I want to do is to measure, reasonably accurately, the > > packet loss > > (and latency) of any given LSP through the network. This is > > useful for > > SLA monitoring etc. Whether this is strictly an "OAM" > > function doesn't > > concern me overly. If this can be done as a small delta to > > providing an > > OAM facility without this capability then it would seem like > > a good idea > > (presumably that is the reason you specified the P flow in the first > > place?) > NH=> Yes. But the only metrics I have considered so far are loss. We could > add others (like errors and delay) but I have not considered these at this > time to keep it simple.....indeed, initally I wondered whether we should be > trying to do any QoS measurements at all above basic defect handling. But > if other metrics are considered important then these should be > considered....noting that there is a cost associated with their > measurement/processing so the wish list should not be too large. I'd say that you'd want to decouple defect handling from QoS measurement? As far as I can tell the CV, BDI, and FDI flows are aimed at defect handling, and the P flow at performance/QoS measurement? It may be that this is an "either, or, or both" type of situation? Defect handling could be applied to "trunk" LSPs in the network (though in some ways I'd question the need for this in the presence of the label distribution protocols - surely if a connectivity defect occurs then the label mapping will be withdrawn by RSVP or LDP?) However performance measurement is required on LSPs relating to user circuits. In some cases these LSPs may have implicit connectivity (for example in the "draft-martini" case where targetted LDP is run from PE to PE to signal "VC" labels, which are layered over "IGP" labels signaled by LDP, RSVP, or whatever) and so connectivity verification makes no sense? The CV, BDI and FDI flows should all be sent through the network with EXP values set for minimum loss/delay (I think you have specified this in your doc.) The P flow should be sent with the same EXP value as the user data, to ensure equal forwarding treatment. Load balancing is an issue here - the P flow MUST be forwarded over the same links as the user data to ensure reasonably accurate measurement. This brings us back to hash functions which ignore the S bit, or to use of TE LSPs to enable deterministic path selection for each LSP. In fact use of TE for these LSPs is unlikely in large SP networks, precisely because these are "user" LSPs rather than "trunk" LSPs (so TE is unlikely to scale to the number of LSPs required?) Giles -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Tue Feb 20 10:31:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14004 for ; Tue, 20 Feb 2001 10:31: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 QQkdfa25447; Tue, 20 Feb 2001 15:31:58 GMT Received: by mail-control.mail.uu.net id QQkdfa03140 for mpls-outgoing; Tue, 20 Feb 2001 15:31: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 QQkdfa03088 for ; Tue, 20 Feb 2001 15:31:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdfa04109 for ; Tue, 20 Feb 2001 15:30:19 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdfa26884 for ; Tue, 20 Feb 2001 15:30:18 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA05767 for mpls@uu.net; Tue, 20 Feb 2001 10:30:17 -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 QQkdez02680 for ; Tue, 20 Feb 2001 15:29: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 QQkdez28894 for ; Tue, 20 Feb 2001 15:28:36 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 QQkdez07846 for ; Tue, 20 Feb 2001 15:28:36 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13835; Tue, 20 Feb 2001 10:28:35 -0500 (EST) Message-Id: <200102201528.KAA13835@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-01.txt Date: Tue, 20 Feb 2001 10:28:35 -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 Filename : draft-ietf-mpls-diff-te-ext-01.txt Pages : 12 Date : 19-Feb-01 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-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-diff-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-ietf-mpls-diff-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: <20010219142602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-te-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-te-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010219142602.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Feb 20 10:38:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14130 for ; Tue, 20 Feb 2001 10:38: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 QQkdfa22306; Tue, 20 Feb 2001 15:38:19 GMT Received: by mail-control.mail.uu.net id QQkdfa03883 for mpls-outgoing; Tue, 20 Feb 2001 15:37:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdfa03864 for ; Tue, 20 Feb 2001 15:37:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdfa14949 for ; Tue, 20 Feb 2001 15:36:53 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdfa02819 for ; Tue, 20 Feb 2001 15:36:52 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id CF3BD94007; Tue, 20 Feb 2001 10:36:51 -0500 (EST) Message-ID: <3A928F13.8E9B1439@sandburst.com> Date: Tue, 20 Feb 2001 10:36:51 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Manohar Ellanti Cc: David Charlap , mpls@UU.NET Subject: Re: CR-LDP and RSVP implementation References: <3A91588F.B4D45E75@marconi.com> <006201c09b01$176bfec0$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 Manohar, Please see embedded comments below... You wrote: > I think one commercial MPLS stack vendor has support > for one side of LSP setup using LDP(CR) and the other > using RSVP. I am not sure about the extent of support. > For instance Explicit and crankback semantics and how > they can be translated between the two sides. Whenever there are a number of elements cooperating to communicate (in series, as it were), the limitations of the things they might be able to communicate is likely to be the intersection of their communication capabilities. What you say above would be just as true if the same protocol were in use but some of these features were not supported at every node. > > However I can imagine, instead of horizontal participation > of the two signaling protocols, a vertical participation > where a tunnel might be setup using RSVP-TE and inside > the tunnel number of LSPs to be setup using CR-LDP for > instance. This makes sense. I believe you might find the opposite could make sense in some scenarios as well. It is even conceivable that you could have alternating layers. > > Again probably it is best avoided using multiple signaling > protocols over a single provider network. 2547 does > mention use of LDP to setup PE-PE tunnles. I remember > a discussion on removing explicit reference to one > particular signaling protocol from 2547. If 2547 does require > LDP then probably the underlying physical connectivity > between PE routers can be setup using RSVP-TE and > VPNs provisioned or PE-PE (per VPN specific) inner > LSPs setup using LDP. Some one can comment whether > this makes sense. Certainly. :-) For BGP-MPLS, it is necessary to have some protocol in use to establish LSPs between non-adjacent BGP speakers since - otherwise - the labels exchanged between such speakers are not meaningful. It also makes sense that the protocol used should be in-tune with the IGP used to route packets between these non-adjacent BGP speakers. Hence, LDP makes sense - although another protocol could be used. I believe this is something like what the current state of affairs with BGP-MPLS says. > > -Manohar > > ----- Original Message ----- > From: "David Charlap" > To: > Sent: Monday, February 19, 2001 9:31 AM > Subject: Re: CR-LDP and RSVP implementation > > > djiang1@lucent.com wrote: > > > > > > I have a question regarding CR-LDP and RSVP implementation. > > > > > > I guess it is possible that both CR-LDP and RSVP implementations will > > > be supported on one LSR. > > > > Definitely possible. And quite probable in the future. > > > > > However, is there any chance that both the implementations will be > > > called for one LSP setup? Say, at the incoming interface, CR-LDP will > > > take the PATH message and pass it to some other MPLS processes. At > > > the out going interface, RSVP will get some message from other MPLS > > > processes and does something in the middle and sends out another PATH > > > message to its neighbor node. > > > > I don't think so. > > > > The only way I can picture such a setup would require a transit router's > > ability to terminate one LSP, then initiate setup of another, and > > connect them internally. Theoretically possible, but difficult to > > automate and of questionable utility. > > > > I think you may find MPLS networks where RSVP-TE, LDP and CR-LDP are all > > used for LSP setup at once. And this may well result in multiple > > redundant LSPs between edge nodes. But each individual LSP will almost > > certainly be set up through exactly one protocol. > > > > -- David > > From owner-mpls@UU.NET Tue Feb 20 10:49:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14389 for ; Tue, 20 Feb 2001 10:49: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 QQkdfb24263; Tue, 20 Feb 2001 15:49:41 GMT Received: by mail-control.mail.uu.net id QQkdfb05172 for mpls-outgoing; Tue, 20 Feb 2001 15:48: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 QQkdfb05159 for ; Tue, 20 Feb 2001 15:48:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdfb00154 for ; Tue, 20 Feb 2001 15:48:36 GMT Received: from sol.extremenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sol.extremenetworks.com [216.52.8.2]) id QQkdfb22604 for ; Tue, 20 Feb 2001 15:48:35 GMT Received: by SOL with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Feb 2001 07:44:03 -0800 Message-ID: <2F5F27915881D411B43F00508BD8935F81119F@sc-sol-04.extremenetworks.com> From: Paul Billinghurst To: "'mpls@uu.net'" Subject: Downstream unsolicited and conservative retention Date: Tue, 20 Feb 2001 07:45:40 -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 Regarding the scenario discussed in Section 3.5.7.1.4. of RFC 3036 "The combination of Downstream Unsolicited mode and conservative label retention can lead to a situation where an LSR releases the label for a FEC that it later needs. For example, if LSR Rd advertises to LSR Ru the label for a FEC for which it is not Ru's next hop, Ru will release the label. If Ru's next hop for the FEC later changes to Rd, it needs the previously released label " The section says the following "To deal with this situation either Ru can explicitly request the label when it needs it, or Rd can periodically readvertise it to Ru ". Does this mean that even though during session initialization Ru stated it was configured for downstream unsolicited it is allowed to send a label request message. Have I understood this correctly ? and does this mean the downstream will accept a request from an upstream router that has signaled that it is configured for Du ? The latter mentioned solution i.e. periodically readvertise, is this inferring periodic label refresh ? Thanks Paul From owner-mpls@UU.NET Tue Feb 20 10:56:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14586 for ; Tue, 20 Feb 2001 10:56: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 QQkdfb04203; Tue, 20 Feb 2001 15:56:26 GMT Received: by mail-control.mail.uu.net id QQkdfb05638 for mpls-outgoing; Tue, 20 Feb 2001 15:55: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 QQkdfb05632 for ; Tue, 20 Feb 2001 15:55:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdfb20926 for ; Tue, 20 Feb 2001 15:55:25 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdfb17179 for ; Tue, 20 Feb 2001 15:55:25 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id C92CA94007; Tue, 20 Feb 2001 10:55:19 -0500 (EST) Message-ID: <3A929367.E1DB8C0@sandburst.com> Date: Tue, 20 Feb 2001 10:55:19 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "B, Prakash K (Prakash)" Cc: "'mpls@uu.net'" Subject: Re: Hop Count Procedures References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "B, Prakash K (Prakash)" wrote: > ATM LSRS do not perform TTL decrement. RFC 3036 says that while propogating > the label mapping message upstream, if an LSR (Rd) finds out that its > upstream LSR (Ru) is a part of domain that does not perform TTL > decrement(ATM segment), it must reset the Hop Count value to 1. Will this > not lead to erroneous computation of final TTL in the long run when the > packet exits out of MPLS domain?Will not the true Hop count value assist the > ingress in determining in advance the TTL value that must be, when the > packet emerges out of a Non -TTL-decrement segment? > > RFC 3031 clearly states that the final TTL value must reflect the true > number of hops that a packet takes to exit a MPLS domain . > Clarification solicited. > > Prakash K.B. Prakash, The intention is to allow the ATM ingress LSR to be able to decrement the TTL by the value of the hop count in LSP setup messages used to establish an LSP that will be used to forward data. Note that the ATM ingress LSR does not have to do this, but it could (if configured to do so, for instance, by the network operator). In other words, when the ingress ATM LSR is about to put a packet on a specific LSP, one of the things that it should get in the FTN lookup is the decrement value for the packet's TTL. The source of this value may be the hop count received in the LSP setup messages. This will be the case if the operator intends their ATM "tunnel" to be apparent to the end user. Once the packet arrives at the egress from the ATM cloud, the next hop will decrement the TTL by some non-zero value and this will happen for each of the non-ATM LSRs in the remainder of the LSP - up to and including the hop count of the LSP setup. If the hop count was not reset to 1 by the LSR at the egress from the ATM cloud (instead, reflecting all of the hops in the LSP downstream), the result would be to (possibly) decrement the TTL of packets arriving at the ingress to the ATM cloud by the number of hops in the entire LSP and then decrementing it again at every non-ATM LSR hop. This could cause premature packet demise. -- Eric Gray From owner-mpls@UU.NET Tue Feb 20 11:30:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15424 for ; Tue, 20 Feb 2001 11:30: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 QQkdfe23771; Tue, 20 Feb 2001 16:30:50 GMT Received: by mail-control.mail.uu.net id QQkdfe23484 for mpls-outgoing; Tue, 20 Feb 2001 16:30: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 QQkdfe23477 for ; Tue, 20 Feb 2001 16:30:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdfd05331 for ; Tue, 20 Feb 2001 16:29:47 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdfd17930 for ; Tue, 20 Feb 2001 16:29:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA12284 for mpls@uu.net; Tue, 20 Feb 2001 11:29: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 QQkdfd23379 for ; Tue, 20 Feb 2001 16:29: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 QQkdfd00737 for ; Tue, 20 Feb 2001 16:28:19 GMT Received: from brixcorp2.brixnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.122.27.34]) id QQkdfd15666 for ; Tue, 20 Feb 2001 16:28:18 GMT Received: by BRIXCORP2 with Internet Mail Service (5.5.2650.21) id <10VY0W2M>; Tue, 20 Feb 2001 11:28:17 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7F83@BRIXCORP2> From: "Cucchiara, Joan" To: "'Edward Harrison'" , "'mohanvak@future.futsoft.com'" , "Cucchiara, Joan" Cc: "'mpls@uu.net'" Subject: RE: Question on Generic Label Range Table in LDP MIB Date: Tue, 20 Feb 2001 11:28:16 -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, The way we envisioned the generic label range table would work is along with the interface stack, such that there is a single (perPlatform) ifIndex at some point in the stack, which represents a generic label range. What you are suggesting is a finer break down of this (I think). The ifIndex which corresponds to a generic label range would be used in the generic label range table. The ifStack would then lead to a physical port for a specific generic label (which was actually one of the earlier tables, but was subsequently removed from the mib since the feedback we received was that reserving a group of generic labels was what was important.) If you want a break down (or mapping) of a specific generic labels to a specific ifIndex (say an ifIndex which corresponds to the shim layer), that does not appear in the MIB, because our understanding of the generic label range was that it applies to a perPlatform scenario. -Joan > -----Original Message----- > From: Edward Harrison [mailto:eph@dataconnection.com] > Sent: Thursday, February 15, 2001 1:39 PM > To: 'mohanvak@future.futsoft.com'; 'jcucchiara@brixnet.com' > Cc: 'mpls@uu.net' > Subject: RE: Question on Generic Label Range Table in LDP MIB > > > Hi, > > I'd forgotten that the generic label range table was only > added in one of > the more recent versions of the MIB. I guess this means that > this problem in > the MIB has only been around since then. > > Joan, have you any comments on this? Is there any chance of adding an > additional index field to the mplsLdpEntityConfGenericTable to cover > scenarios where two interfaces advertise the same label range > for the same > LDP entity? > > Regards, > > Ed > > -------------- > Ed Harrison > Network Convergence Group > Data Connection Ltd > Tel: +44 20 8366 1177 Fax: +44 20 8366 5084 > Email: eph@dataconnection.com Web:http://www.dataconnection.com > > > -----Original Message----- > From: Mohan Varma K [mailto:mohanvak@future.futsoft.com] > Sent: 07 February 2001 08:57 > To: Edward Harrison > Cc: 'mpls@uu.net' > Subject: RE: Question on Generic Label Range Table in LDP MIB > > > > Hi, > Yes, creation of row will be a problem if we go with the > assumption of the earlier ldp-mibs. > > As per ldp-mib 7 they have defined a generic label range > on a per Interface level. > If we ensure a slight different label range in configuration( > for eg 16-10000 (mplsLdpEntityConfGenericIfIndexOrZero 1), > 17-10000 (mplsLdpEntityConfGenericIfIndexOrZero 2) > we have almost same labels available on each interface,which > we don't have earlier. > > However if we want to create a row wth the similar label range > we can have additional index to this table. > > with regards > Mohan Varma > > > > > Hi Joan, > > I have a question regarding the use of the > mplsLdpEntityConfGenericIfIndexOrZero object within the LDP MIB > (draft-ietf-mpls-ldp-mib-07.txt). > > My understanding is that it is possible to have multiple > interfaces using > the generic label space and that, typically, each of these > interfaces would > advertise the same label ranges. > > Furthermore, I thought that it was possible to have a single > (non-targeted) > LDP Entity for the generic label range - this entity being > associated with > all the interfaces using the generic label range. > > If this is correct then I believe one ends up with a single row in the > Generic Label Range Table which corresponds to more than one > interface - for > each interface the LDP ID, Entity Index and Label Range will > all be the same > as each interface uses the same LDP entity and shares the > same label range. > > In this scenario what should the value of > mplsLdpEntityConfGenericIfIndexOrZero be (as there are > multiple possible > interface indices that are appropriate)? Should it be zero, > meaning the > index is unknown, or should it correspond to one of the > interfaces for the > Entity? > > Thanks very much for your help, > > Ed > > ---------------- > > Ed Harrison > Network Convergence Group > Data Connection Ltd > Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 > Email: eph@dataconnection.com Web:http://www.dataconnection.com > From owner-mpls@UU.NET Tue Feb 20 11:37:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15662 for ; Tue, 20 Feb 2001 11:37: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 QQkdfe00037; Tue, 20 Feb 2001 16:37:36 GMT Received: by mail-control.mail.uu.net id QQkdfe24422 for mpls-outgoing; Tue, 20 Feb 2001 16:37:11 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 QQkdfe24412 for ; Tue, 20 Feb 2001 16:37: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 QQkdfe25920 for ; Tue, 20 Feb 2001 16:36:22 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdfe27845 for ; Tue, 20 Feb 2001 16:36:21 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id D57AB94007; Tue, 20 Feb 2001 11:36:20 -0500 (EST) Message-ID: <3A929D04.75579A67@sandburst.com> Date: Tue, 20 Feb 2001 11:36:20 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Billinghurst Cc: "'mpls@uu.net'" Subject: Re: Downstream unsolicited and conservative retention References: <2F5F27915881D411B43F00508BD8935F81119F@sc-sol-04.extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Paul, See below... You wrote: > Regarding the scenario discussed in Section 3.5.7.1.4. of RFC 3036 > > "The combination of Downstream Unsolicited mode and conservative label > retention can lead to a situation where an LSR releases the label for > a FEC that it later needs. For example, if LSR Rd advertises to LSR > Ru the label for a FEC for which it is not Ru's next hop, Ru will > release the label. If Ru's next hop for the FEC later changes to Rd, > it needs the previously released label " > > The section says the following "To deal with this situation either Ru > can explicitly request the label when it needs it, or Rd can periodically > readvertise it to Ru ". > > Does this mean that even though during session initialization Ru stated it > was configured for downstream unsolicited it is allowed to send a label > request message. Have I understood this correctly ? Yes. > > > and does this mean the downstream will accept a request from an > upstream router that has signaled that it is configured for Du ? Again, yes. > > The latter mentioned solution i.e. periodically readvertise, is this > inferring periodic label refresh? There are a couple of things to realize here: 1 it does - in general - not make sense to combine the two modes that are discussed in this citation (i.e. - Downstream unsolicited and conservative retention) and 2 the upstream LSR should have sent a release message for any labels it has decided not to use. The latter of these two things is a BIG part of the reason why the former is true (i.e. - the two modes do not make sense together). This would tend to support the idea that the combination is unlikely in practice. Plus the fact that the upstream LSR is supposed to send release messages is a mitigation for the behavior you describe: the behavior is not refresh, in the usual sense, since the labels being readvertised have been explicitly released. Whether or not it makes sense to litterally refresh label mappings - either to support a bad upstream implementation (one that does not explicitly release labels which does not intend to use) or to allow a downstream LSR to avoid keeping state on labels it has issued - is another matter. I don't think it's a good idea. > > > Thanks > > Paul -- Eric Gray From owner-mpls@UU.NET Tue Feb 20 12:54:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18472 for ; Tue, 20 Feb 2001 12:54: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 QQkdfj21977; Tue, 20 Feb 2001 17:54:11 GMT Received: by mail-control.mail.uu.net id QQkdfj16565 for mpls-outgoing; Tue, 20 Feb 2001 17:53:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdfj16556 for ; Tue, 20 Feb 2001 17:53:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdfj08343 for ; Tue, 20 Feb 2001 17:53:39 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 QQkdfj21154 for ; Tue, 20 Feb 2001 17:53:39 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25298 for ; Tue, 20 Feb 2001 12:53:36 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03452 for ; Tue, 20 Feb 2001 12:53:38 -0500 (EST) Message-ID: <3A92AF51.30F5C0DB@marconi.com> Date: Tue, 20 Feb 2001 12:54:25 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: CR-LDP and RSVP implementation References: <3A91588F.B4D45E75@marconi.com> <3A928AD3.84D8E36C@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > Hmmm. There is the interworking scenario: > > --- R1 --- R2 --- R3 --- > > in which R1 only "speaks" CR-LDP/LDP and R3 only speaks RSVP-TE (and > maybe LDP). In this scenario, it is quite reasonable for R2 to > "translate" between the two protocols for LSP set-up. Would you want to have R2 translate one signalling protocol to another? This seems unmanagable and needlessly complicated. In this scenario, I think it would make more sense to use LDP to signal an LSP that terminates on R2. R2 can then signal a different LSP that goes through R3 to the edge of the MPLS cloud. R2 can then configure itself to forward packets between the two LSPs. While the effect is the same, the mechanism is different. It avoids a few nasty problems that would result from the differences in the protocols: - RSVP-TE uses a different QoS representation from CR-LDP - RSVP-TE explicltly LSPs from a known ingress router to a known egress router. LDP distributes labels without a firm concept of an LSP during the signalling. CR-LDP appears to be like LDP in this respect, although the presence of an explicit route mitigates the difference somewhat. - There is no LDP or CR-LDP way to signal multiple LSPs that share resources. (RSVP's "SE" reservation style) These problems can all be worked around, of course, but it they can be avoided altogether if the routers create two LSPs, connected at R2 intead of trying to signal one LSP with two protocols. > Also, there is very little difference between setting up a single LSP > through (for example) R2 above and terminating one LSP (from R1, for > instance), making a new LSP (toward R3) and connecting them > internally (at R2) - as long as the mapping (might be a FEC) is > one-to-one from one LSP to the other. In the data plane, there is no difference. But the setup procedures will be different. IMO, the two-connected-LSP method will be simpler. -- David From owner-mpls@UU.NET Tue Feb 20 12:56:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18605 for ; Tue, 20 Feb 2001 12:56: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 QQkdfj25359; Tue, 20 Feb 2001 17:56:23 GMT Received: by mail-control.mail.uu.net id QQkdfj16757 for mpls-outgoing; Tue, 20 Feb 2001 17:55:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdfj16750 for ; Tue, 20 Feb 2001 17:55:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdfj03516 for ; Tue, 20 Feb 2001 17:55: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 QQkdfj20990 for ; Tue, 20 Feb 2001 17:54:58 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 JAA14103 for ; Tue, 20 Feb 2001 09:55:13 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA00925 for mpls@uu.net; Tue, 20 Feb 2001 12:54:56 -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 QQkdfh13957 for ; Tue, 20 Feb 2001 17:29:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdfh26768 for ; Tue, 20 Feb 2001 17:28:19 GMT From: thomas.huang@att.net Received: from mtiwmhc23.worldnet.att.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mtiwmhc23.worldnet.att.net [204.127.131.48]) id QQkdfh02750 for ; Tue, 20 Feb 2001 17:28:19 GMT Received: from webmail.worldnet.att.net ([204.127.135.29]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20010220172818.MZBJ19355.mtiwmhc23.worldnet.att.net@webmail.worldnet.att.net> for ; Tue, 20 Feb 2001 17:28:18 +0000 Received: from [216.15.8.242] by webmail.worldnet.att.net; Tue, 20 Feb 2001 17:28:18 +0000 To: mpls@UU.NET Subject: How the merged traffic to be splitted? Date: Tue, 20 Feb 2001 17:28:18 +0000 X-Mailer: AT&T Message Center Version 1 (Dec 14 2000) X-Authenticated-Sender: thomas.huang@att.net Message-Id: <20010220172818.MZBJ19355.mtiwmhc23.worldnet.att.net@webmail.worldnet.att.net> Sender: owner-mpls@UU.NET Precedence: bulk Hello: It seems to me that the MPLS drafts related to the Label Merging have not shown how the Label Merge feature can be used in a practical application. I would appreciate your pointers on the following two questions: 1) in the following configuration, how the merged label traffic can be split to two different destination LERs E and F? and how the x and y signaled? Ingress A \ label:1 / LER E \ /?x LSR C ----Label 3-------LSR D / \?y Ingress B / label 2 \LER F Note: with label merge, we should not push the label 1 or or label 2 at LSR C and pop them at LSR D.Right? 2) or the label merge only valid for the following configuration for IP traffic (not ATM/FR!)? Ingress A \ label:1 \ LSR C ----Label 3-------LER D / Ingress B / label 2 Regards, THomas From owner-mpls@UU.NET Tue Feb 20 13:41:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20307 for ; Tue, 20 Feb 2001 13:41: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 QQkdfm28016; Tue, 20 Feb 2001 18:41:27 GMT Received: by mail-control.mail.uu.net id QQkdfm05129 for mpls-outgoing; Tue, 20 Feb 2001 18:41: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 QQkdfm05122 for ; Tue, 20 Feb 2001 18:41: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 QQkdfm21342 for ; Tue, 20 Feb 2001 18:41:08 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdfm25701 for ; Tue, 20 Feb 2001 18:40:57 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA24755 for mpls@uu.net; Tue, 20 Feb 2001 13:40:56 -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 QQkdfm05042 for ; Tue, 20 Feb 2001 18:40:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdfm08702 for ; Tue, 20 Feb 2001 18:39:32 GMT Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.dataconnection.com [192.91.191.8]) id QQkdfm25078 for ; Tue, 20 Feb 2001 18:39:32 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <1Z4MYYLB>; Tue, 20 Feb 2001 18:39:20 -0000 Message-ID: From: Adrian Farrel To: Zaffire - Fong Liaw , "'lberger@movaz.com'" Cc: "'mpls@uu.net'" Subject: RE: signaling in draft-kompella-mpls-bundle-04.txt Date: Tue, 20 Feb 2001 18:39:23 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Fong, The point with LIH in RSVP_HOP is that it identifies the link from the sender perspective. (NB, it is not really GMPLS, it is base RSVP). What Kireeti has described in the bundling draft is the ability to have multiple component links of a single link. Clearly when the Path message is sent (e.g. on a control channel) the downstream node must be able to work out which component link is going to be used for the data. The LIH cannot be used since it provides the sender's identifier for the link and may have no meaning to the receiver. Hence a new object is introduced. Now turning to bi-directional LSPs. The component links in a bundle are quite possibly uni-directional. If they are, they may be paired so that you could consider one component link to be built from one forward and one reverse link, but there is no reason why this should be the case. So you need to identify the component links that will be used for each direction on the LSP. Hence the two objects in the bundling draft. Hope this helps. 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: Zaffire - Fong Liaw >Sent: Saturday, February 17, 2001 3:05 AM >To: 'lberger@movaz.com' >Cc: 'mpls@uu.net' >Subject: signaling in draft-kompella-mpls-bundle-04.txt > > >Hi Lou, > >I have a question regarding why the bundled draft >specifies both upstream and downstream component link >while GMPLS draft assumes the same link is used for >both upstream and downstream LSP. I believe the GMPLS >model make more sense. > >If we are going to assume the same link should be >used for both upstream and downstream LSP, we really >do not need the new component link identifier object >since the RSVP HOP object already has the ability to >identify a local (component) index along with an >IP address. > >Thanks. >-Fong > From owner-mpls@UU.NET Tue Feb 20 14:15:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21342 for ; Tue, 20 Feb 2001 14:15: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 QQkdfp15003; Tue, 20 Feb 2001 19:15:02 GMT Received: by mail-control.mail.uu.net id QQkdfo21984 for mpls-outgoing; Tue, 20 Feb 2001 19:14: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 QQkdfo21975 for ; Tue, 20 Feb 2001 19:14:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdfo05692 for ; Tue, 20 Feb 2001 19:14:28 GMT Received: from hoemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkdfo14162 for ; Tue, 20 Feb 2001 19:14:28 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA15157 for ; Tue, 20 Feb 2001 14:14:27 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA15130; Tue, 20 Feb 2001 14:14:26 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA23743; Tue, 20 Feb 2001 14:14:25 -0500 (EST) Message-ID: <3A92C210.E4FBA6F8@lucent.com> Date: Tue, 20 Feb 2001 14:14:24 -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: Adrian Farrel CC: Zaffire - Fong Liaw , "'lberger@movaz.com'" , "'mpls@uu.net'" Subject: Re: signaling in draft-kompella-mpls-bundle-04.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adrian, > > The point with LIH in RSVP_HOP is that it identifies the link from the > sender perspective. (NB, it is not really GMPLS, it is base RSVP). > > What Kireeti has described in the bundling draft is the ability to have > multiple component links of a single link. Clearly when the Path message is > sent (e.g. on a control channel) the downstream node must be able to work > out which component link is going to be used for the data. The LIH cannot > be used since it provides the sender's identifier for the link and may have > no meaning to the receiver. Hence a new object is introduced. I don't think this is the reason. For RSVP in GMPLS case, LIH should be used to identify the signaling control interface, not for logical links (or component links) in data plane. Remember, in transport network, signaling are typically out-of-band and non-associated. Yangguang From owner-mpls@UU.NET Tue Feb 20 14:57:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22706 for ; Tue, 20 Feb 2001 14:57: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 QQkdfr02675; Tue, 20 Feb 2001 19:56:53 GMT Received: by mail-control.mail.uu.net id QQkdfr26614 for mpls-outgoing; Tue, 20 Feb 2001 19:56: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 QQkdfr26603 for ; Tue, 20 Feb 2001 19:56:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdfr06055 for ; Tue, 20 Feb 2001 19:55:20 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.121.21.2]) id QQkdfr13266 for ; Tue, 20 Feb 2001 19:55:17 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Feb 2001 11:58:28 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B8B55@ICARIAN> From: Fong Liaw To: "'Adrian Farrel'" , Fong Liaw , "'lberger@movaz.com'" Cc: "'mpls@uu.net'" Subject: RE: signaling in draft-kompella-mpls-bundle-04.txt Date: Tue, 20 Feb 2001 11:58:23 -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, Adrian Thanks for replying. My question is really "if a component link of a bundled link may be uni-directional, then a regular link may also be uni-directional and we also need an (upstream link) object in ERO (or somewhere). Bundle is a method of aggregation, it should not change the fundamental of link selection." Is this logic flaw somewhere ? Also, the (new) component_interface_ID also requires the other node to know what the (sender) remote ID as well, using LIH to mean component_interface_ID, by agreement for GMPLS, would be a fine approach. This is a minor point, I am fine with a different object if most people feel the a new object is needed. Regards, -Fong > -----Original Message----- > From: Adrian Farrel [mailto:AF@dataconnection.com] > Sent: Tuesday, February 20, 2001 10:39 AM > To: Zaffire - Fong Liaw; 'lberger@movaz.com' > Cc: 'mpls@uu.net' > Subject: RE: signaling in draft-kompella-mpls-bundle-04.txt > > > Fong, > > The point with LIH in RSVP_HOP is that it identifies the > link from the > sender perspective. (NB, it is not really GMPLS, it is base RSVP). > > What Kireeti has described in the bundling draft is the > ability to have > multiple component links of a single link. Clearly when the > Path message is > sent (e.g. on a control channel) the downstream node must be > able to work > out which component link is going to be used for the data. > The LIH cannot > be used since it provides the sender's identifier for the > link and may have > no meaning to the receiver. Hence a new object is introduced. > > Now turning to bi-directional LSPs. The component links in > a bundle are > quite possibly uni-directional. If they are, they may be > paired so that you > could consider one component link to be built from one > forward and one > reverse link, but there is no reason why this should be the case. > > So you need to identify the component links that will be > used for each > direction on the LSP. Hence the two objects in the bundling draft. > > Hope this helps. > 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: Zaffire - Fong Liaw > >Sent: Saturday, February 17, 2001 3:05 AM > >To: 'lberger@movaz.com' > >Cc: 'mpls@uu.net' > >Subject: signaling in draft-kompella-mpls-bundle-04.txt > > > > > >Hi Lou, > > > >I have a question regarding why the bundled draft > >specifies both upstream and downstream component link > >while GMPLS draft assumes the same link is used for > >both upstream and downstream LSP. I believe the GMPLS > >model make more sense. > > > >If we are going to assume the same link should be > >used for both upstream and downstream LSP, we really > >do not need the new component link identifier object > >since the RSVP HOP object already has the ability to > >identify a local (component) index along with an > >IP address. > > > >Thanks. > >-Fong > > > From owner-mpls@UU.NET Tue Feb 20 15:07:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23109 for ; Tue, 20 Feb 2001 15:07: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 QQkdfs21041; Tue, 20 Feb 2001 20:07:03 GMT Received: by mail-control.mail.uu.net id QQkdfs10853 for mpls-outgoing; Tue, 20 Feb 2001 20:06:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdfs10750 for ; Tue, 20 Feb 2001 20:06:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdfs23179 for ; Tue, 20 Feb 2001 20:05:39 GMT Received: from icarian.ZAFFIRE.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.121.21.2]) id QQkdfs02164 for ; Tue, 20 Feb 2001 20:05:39 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Feb 2001 12:08:52 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B8B56@ICARIAN> From: Fong Liaw To: "'Yangguang Xu'" , Adrian Farrel Cc: Fong Liaw , "'lberger@movaz.com'" , "'mpls@uu.net'" Subject: RE: signaling in draft-kompella-mpls-bundle-04.txt Date: Tue, 20 Feb 2001 12:08:47 -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, Yangquang > > I don't think this is the reason. For RSVP in GMPLS case, > LIH should be used to > identify the signaling control interface, not for logical > links (or component > links) in data plane. Remember, in transport network, > signaling are typically > out-of-band and non-associated. Out-of-band or in-band, the fact that the Path needs to select the link is still there. Consider a regular (non-bundled) link, if one does not specify (strict) ERO, there is no other object to select the link in either direction. RSVP-HOP is the mechanism. IMHO, the IPv4 address in RSVP-HOP selects the control interface, and LIH selects the individual link. BTW, this (which object to use) is a minor point. As my reply to Adrian, the bi-directionality of link (bundled or non-bundled) is my real question. Regards, -Fong > > Yangguang > From owner-mpls@UU.NET Tue Feb 20 16:25:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25932 for ; Tue, 20 Feb 2001 16:25: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 QQkdfx26441; Tue, 20 Feb 2001 21:25:37 GMT Received: by mail-control.mail.uu.net id QQkdfx01472 for mpls-outgoing; Tue, 20 Feb 2001 21:24: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 QQkdfx01462 for ; Tue, 20 Feb 2001 21:24: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 QQkdfx24915 for ; Tue, 20 Feb 2001 21:24:54 GMT Received: from mail.makesys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.makesys.com [204.30.100.64]) id QQkdfx19711 for ; Tue, 20 Feb 2001 21:24:54 GMT Received: from makesys.com (mlclient13 [204.30.100.103]) by mail.makesys.com (8.11.1/8.10.1) with ESMTP id f1KLN3Z22214; Tue, 20 Feb 2001 16:23:03 -0500 (EST) Message-ID: <3A92E037.1D85FCA5@makesys.com> Date: Tue, 20 Feb 2001 16:23:03 -0500 From: Weigang Cao X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tnadeau@cisco.com, cheenu@tachion.com, arun@force10networks.com CC: mpls@UU.NET Subject: Imports TimeStamp FROM SNMPv2-SMI ? Content-Type: multipart/alternative; boundary="------------30A3C805EEBD70C7432B7510" Sender: owner-mpls@UU.NET Precedence: bulk --------------30A3C805EEBD70C7432B7510 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Hi, Tom, I beleive that TimeStamp is imported from SNMPv2-TC. -- Weigang Cao Make Systems, Inc http://www.makesys.com --------------30A3C805EEBD70C7432B7510 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 7bit Hi, Tom,

I beleive that TimeStamp is imported from SNMPv2-TC. 

-- 
Weigang Cao             
Make Systems, Inc       
http://www.makesys.com
  --------------30A3C805EEBD70C7432B7510-- From owner-mpls@UU.NET Tue Feb 20 16:53:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26633 for ; Tue, 20 Feb 2001 16:53: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 QQkdfz29033; Tue, 20 Feb 2001 21:53:00 GMT Received: by mail-control.mail.uu.net id QQkdfz03759 for mpls-outgoing; Tue, 20 Feb 2001 21:52:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdfz03747 for ; Tue, 20 Feb 2001 21:52:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdfz26173 for ; Tue, 20 Feb 2001 21:51:24 GMT Received: from hoemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkdfz26311 for ; Tue, 20 Feb 2001 21:51:23 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA13046 for ; Tue, 20 Feb 2001 16:51:22 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA13010; Tue, 20 Feb 2001 16:51:22 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA22214; Tue, 20 Feb 2001 16:51:21 -0500 (EST) Message-ID: <3A92E6D9.9959394E@lucent.com> Date: Tue, 20 Feb 2001 16:51:21 -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: Fong Liaw , "'mpls@uu.net'" Subject: Re: signaling in draft-kompella-mpls-bundle-04.txt References: <4611AD058694D4118FD5009027B0A6622B8B56@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Fong, My point is LIH is not the right place to put interface ID or Port ID. LIH should be used to specify control plane signaling interface ID NOT data plane transport interface ID. As for the port ID/or component_interface_ID, it should be part of a Label. The definition of label in current GMPLS-Signaling functional spec. is incomplete. A label should be associated with a specific switchable data flow (my definition). Port ID + channel ID together form a meaningful unit. Separating them into two objects is not necessary. The procedure is that (1) source node computes ERO in logical link/bundle level of granularity (2) Each intermediate node specifies the exact physical interface (the label) for connection creation according to ERO and local information BTW, there seem to be some misunderstanding of bi-directional LSP creation in transport network. In SONET/SDH transport network, (and also IP, ATM switches) ports are normally bi-directionally identified (which means one port ID actually indicates two physical ports, one IN, one OUT). So a label has bidirectionally itself. If all ports within a network are bi-directionally identified, for a bi-directional LSP, only one bi-directional label is needed. Upstream label, from concept to implementation, is a redundancy. Regards, Yangguang Fong Liaw wrote: > > Hi, Yangquang > > > > > I don't think this is the reason. For RSVP in GMPLS case, > > LIH should be used to > > identify the signaling control interface, not for logical > > links (or component > > links) in data plane. Remember, in transport network, > > signaling are typically > > out-of-band and non-associated. > > Out-of-band or in-band, the fact that the Path needs to > select the link is still there. Consider a regular (non-bundled) > link, if one does not specify (strict) ERO, there is no other object > to select the link in either direction. RSVP-HOP is the mechanism. > IMHO, the IPv4 address in RSVP-HOP selects the control > interface, and LIH selects the individual link. > > BTW, this (which object to use) is a minor point. As my reply > to Adrian, the bi-directionality of link (bundled or non-bundled) > is my real question. > > Regards, > -Fong > > > > > Yangguang > > From owner-mpls@UU.NET Tue Feb 20 17:05:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27287 for ; Tue, 20 Feb 2001 17:05: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 QQkdga08650; Tue, 20 Feb 2001 22:05:10 GMT Received: by mail-control.mail.uu.net id QQkdga13400 for mpls-outgoing; Tue, 20 Feb 2001 22:04:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdga13266 for ; Tue, 20 Feb 2001 22:04:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdga27307 for ; Tue, 20 Feb 2001 22:04:29 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdga07645 for ; Tue, 20 Feb 2001 22:04:29 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id 1835894006; Tue, 20 Feb 2001 17:04:29 -0500 (EST) Message-ID: <3A92E9EA.A72C4B24@sandburst.com> Date: Tue, 20 Feb 2001 17:04:29 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: CR-LDP and RSVP implementation References: <3A91588F.B4D45E75@marconi.com> <3A928AD3.84D8E36C@sandburst.com> <3A92AF51.30F5C0DB@marconi.com> Content-Type: multipart/alternative; boundary="------------3049B368FCDED6601D3E8F6A" Sender: owner-mpls@UU.NET Precedence: bulk --------------3049B368FCDED6601D3E8F6A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, Let me do a little constructive reasoning. IF it is not possible to create an LSP from R2 forward that - even closely - matches LSP(s) we are going to consider terminating at R2, then there will necessarily be some degree of complexity associated with both the process of determining what sets of LSPs to signal (to R2 and beyond R2) and the process of mapping data arriving on an LSP to R2 onto an LSP going forward from R2. There will definitely be zero or more traffic streams to which this will apply in any case. Let's assume that for one or more traffic streams, however, there is a simple mapping of data arriving on an LSP to R2 to an LSP going forward from R2. Let's call the arriving LSP, LSP-A and the departing LSP LSP-A'. If this is the case, then it is very likely the case that requirements for forwarding packets on LSP-A are a subset of requirements for packet forwarding on LSP-A' since - if this is not the case - packet forwarding resources associated with LSP-A will have been needlessly expended since the same resource commitment does not exist for LSP-A'. Similarly, the reverse is true: if resources are committed for LSP-A' and not for LSP-A. As near as I can tell, this applies generally to all kinds of resources - including built in fault-tolerance, queuing behavior, etc. This being the case, then R2 should not commit resources for LSP-A until it is known that it can create LSP-A' or can otherwise ensure that packets will obtain similar consideration and treatment going forward from R2. In my mind, that implies that R2 should signal to obtain LSP-A' prior to "granting" LSP-A. Not only does this compare closely to "tranlation" of the signaling message, but it also preserves the "ordered control" mode common to both RSVP-TE and CR-LDP. Moreover, the example given was deliberatly simplistic. How will either RSVP-TE or CR-LDP satisfy an explicit routing for an LSP if the egress is not within the same signaling domain? It would be a lot simpler for the user if they can setup LSPs across multiple signaling domains within their administrative domain - as opposed to having to treat each signaling domain as if it is also an administrative domain. Finally, in following the development of both RSVP-TE and CR-LDP, one thing I can definitely say is that a lot of effort has gone into making sure that there was very little you could do (in terms of providing a service) with one protocol that you could not also do with the other. I think I would focus on the types of services that you can provide with either or both - this being a larger number than the kinds of services you cannot. Please see embedded comments below. -- Eric Gray You wrote: > Eric Gray wrote: > > > > Hmmm. There is the interworking scenario: > > > > --- R1 --- R2 --- R3 --- > > > > in which R1 only "speaks" CR-LDP/LDP and R3 only speaks RSVP-TE (and > > maybe LDP). In this scenario, it is quite reasonable for R2 to > > "translate" between the two protocols for LSP set-up. > > Would you want to have R2 translate one signalling protocol to another? > This seems unmanagable and needlessly complicated. In most cases, there are some very simple and - in many cases - fairly obvious mappings form the objects in one protocol to the analog objects in the other. These mappings require very little in the way of configuration (defaults will work in most cases) - especially in comparison with the management effort I would think would be associated with seperate LSP setup. > > In this scenario, I think it would make more sense to use LDP to signal > an LSP that terminates on R2. R2 can then signal a different LSP that > goes through R3 to the edge of the MPLS cloud. R2 can then configure > itself to forward packets between the two LSPs. In some (zero or more) cases, this may be necessary. In theory, this couldbe necessary for all LSPs. For example, in the case where the signaling domain coincides with an administrative domain or "trust" boundary. Where the mapping of forwarding requirements is 1:1, however, the semantic difference between an approach that uses translation of singaling and one that does not is nil. > > > While the effect is the same, the mechanism is different. It avoids a > few nasty problems that would result from the differences in the > protocols: > > - RSVP-TE uses a different QoS representation from CR-LDP Most of the objects associated with QoS in CR-LDP were lifted bodily from RSVP-TE and the resemblence is striking. > > - RSVP-TE explicltly LSPs from a known ingress router to a known > egress router. LDP distributes labels without a firm concept of an > LSP during the signalling. CR-LDP appears to be like LDP in this > respect, although the presence of an explicit route mitigates the > difference somewhat. CR-LDP includes Explicit Routing using mechanisms and objects that are very nearly identical to the objects included in RSVP-TE (this time, both efforts "borrowed" from the same bank). > > - There is no LDP or CR-LDP way to signal multiple LSPs that share > resources. (RSVP's "SE" reservation style) CR-LDP accomplishes this using LSP-ID. > > These problems can all be worked around, of course, but it they can be > avoided altogether if the routers create two LSPs, connected at R2 > intead of trying to signal one LSP with two protocols. As near as I can tell, the means to resolve the above "issues" are available natively in both RSVP-TE and CR-LDP. Work-arounds are not needed. > > > Also, there is very little difference between setting up a single LSP > > through (for example) R2 above and terminating one LSP (from R1, for > > instance), making a new LSP (toward R3) and connecting them > > internally (at R2) - as long as the mapping (might be a FEC) is > > one-to-one from one LSP to the other. > > In the data plane, there is no difference. But the setup procedures > will be different. IMO, the two-connected-LSP method will be simpler. > > -- David -- Eric Gray --------------3049B368FCDED6601D3E8F6A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit David,

    Let me do a little constructive reasoning.

    IF it is not possible to create an LSP from R2 forward that
- even closely - matches LSP(s) we are going to consider
terminating at R2, then there will necessarily be some degree
of complexity associated with both the process of determining
what sets of LSPs to signal (to R2 and beyond R2) and the
process of mapping data arriving on an LSP to R2 onto an LSP
going forward from R2.

    There will definitely be zero or more traffic streams to which
this will apply in any case.

    Let's assume that for one or more traffic streams, however,
there is a simple mapping of data arriving on an LSP to R2 to
an LSP going forward from R2.  Let's call the arriving LSP,
LSP-A and the departing LSP LSP-A'.  If this is the case,
then it is very likely the case that requirements for forwarding
packets on LSP-A are a subset of requirements for packet
forwarding on LSP-A' since - if this is not the case - packet
forwarding resources associated with LSP-A will have been
needlessly expended since the same resource commitment
does not exist for LSP-A'.  Similarly, the reverse is true: if
resources are committed for LSP-A' and not for LSP-A.  As
near as I can tell, this applies generally to all kinds of resources
- including built in fault-tolerance, queuing behavior, etc.

    This being the case, then R2 should not commit resources
for LSP-A until it is known that it can create LSP-A' or can
otherwise ensure that packets will obtain similar consideration
and treatment going forward from R2.

    In my mind, that implies that R2 should signal to obtain LSP-A'
prior to "granting" LSP-A.  Not only does this compare closely
to "tranlation" of the signaling message, but it also preserves the
"ordered control" mode common to both RSVP-TE and CR-LDP.

    Moreover, the example given was deliberatly simplistic.  How
will either RSVP-TE or CR-LDP satisfy an explicit routing for
an LSP if the egress is not within the same signaling domain?  It
would be a lot simpler for the user if they can setup LSPs across
multiple signaling domains within their administrative domain -
as opposed to having to treat each signaling domain as if it is
also an administrative domain.

    Finally, in following the development of both RSVP-TE and
CR-LDP, one thing I can definitely say is that a lot of effort
has gone into making sure that there was very little you could
do (in terms of providing a service) with one protocol that you
could not also do with the other.  I think I would focus on the
types of services that you can provide with either or both - this
being a larger number than the kinds of services you cannot.

    Please see embedded comments below.

--
Eric Gray

You wrote:

Eric Gray wrote:
>
>     Hmmm.  There is the interworking scenario:
>
>   --- R1 --- R2 --- R3 ---
>
> in which R1 only "speaks" CR-LDP/LDP and R3 only speaks RSVP-TE (and
> maybe LDP).  In this scenario, it is quite reasonable for R2 to
> "translate" between the two protocols for LSP set-up.

Would you want to have R2 translate one signalling protocol to another?
This seems unmanagable and needlessly complicated.

In most cases, there are some very simple and - in many cases -
fairly obvious mappings form the objects in one protocol to the
analog objects in the other.  These mappings require very little
in the way of configuration (defaults will work in most cases)
- especially in comparison with the management effort I would
think would be associated with seperate LSP setup.
 
In this scenario, I think it would make more sense to use LDP to signal
an LSP that terminates on R2.  R2 can then signal a different LSP that
goes through R3 to the edge of the MPLS cloud.  R2 can then configure
itself to forward packets between the two LSPs.
In some (zero or more) cases, this may be necessary. In theory, this
couldbe necessary for all LSPs.  For example, in the case where the
signaling domain coincides with an administrative domain or "trust"
boundary.  Where the mapping of forwarding requirements is 1:1,
however, the semantic difference between an approach that uses
translation of singaling and one that does not is nil.
 

While the effect is the same, the mechanism is different.  It avoids a
few nasty problems that would result from the differences in the
protocols:

- RSVP-TE uses a different QoS representation from CR-LDP

Most of the objects associated with QoS in CR-LDP were lifted
bodily from RSVP-TE and the resemblence is striking.
 
- RSVP-TE explicltly LSPs from a known ingress router to a known
  egress router.  LDP distributes labels without a firm concept of an
  LSP during the signalling.  CR-LDP appears to be like LDP in this
  respect, although the presence of an explicit route mitigates the
  difference somewhat.
CR-LDP includes Explicit Routing using mechanisms and objects
that are very nearly identical to the objects included in RSVP-TE
(this time, both efforts "borrowed" from the same bank).
 
- There is no LDP or CR-LDP way to signal multiple LSPs that share
  resources.  (RSVP's "SE" reservation style)
CR-LDP accomplishes this using LSP-ID.
 
These problems can all be worked around, of course, but it they can be
avoided altogether if the routers create two LSPs, connected at R2
intead of trying to signal one LSP with two protocols.
As near as I can tell, the means to resolve the above "issues" are
available natively in both RSVP-TE and CR-LDP.  Work-arounds
are not needed.
 
> Also, there is very little difference between setting up a single LSP
> through (for example) R2 above and terminating one LSP (from R1, for
> instance), making a new LSP (toward R3) and connecting them
> internally (at R2) - as long as the mapping (might be a FEC) is
> one-to-one from one LSP to the other.

In the data plane, there is no difference.  But the setup procedures
will be different.  IMO, the two-connected-LSP method will be simpler.

-- David

--
Eric Gray
  --------------3049B368FCDED6601D3E8F6A-- From owner-mpls@UU.NET Tue Feb 20 17:21:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27742 for ; Tue, 20 Feb 2001 17:21: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 QQkdgb24885; Tue, 20 Feb 2001 22:21:31 GMT Received: by mail-control.mail.uu.net id QQkdgb21676 for mpls-outgoing; Tue, 20 Feb 2001 22:20:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdgb21666 for ; Tue, 20 Feb 2001 22:20:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdgb08883 for ; Tue, 20 Feb 2001 22:19:38 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 QQkdgb29024 for ; Tue, 20 Feb 2001 22:19:38 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 120764CE02; Tue, 20 Feb 2001 17:19:34 -0500 (EST) Received: from research.att.com (dhcp177.research.att.com [135.207.28.177]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id RAA17188; Tue, 20 Feb 2001 17:19:33 -0500 (EST) Message-ID: <3A92EDED.7DC2C937@research.att.com> Date: Tue, 20 Feb 2001 17:21:33 -0500 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yangguang Xu Cc: Fong Liaw , "'mpls@uu.net'" Subject: Re: signaling in draft-kompella-mpls-bundle-04.txt References: <4611AD058694D4118FD5009027B0A6622B8B56@ICARIAN> <3A92E6D9.9959394E@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I agree with Yangguang. There are some confusion between IP networks and transport networks. (1) IP network signaling is in-band but most transport signaling is out-band or out-fiber. For transport network, there is a "separate" signaling network. (2) IP network LSPs are fundamental uni-directioanl but most transport network LSPs are bi-directional. (3) IP network bi-directional LSPs need two labels but most transport network bi-directional LSPs only need one label. Of course it is due to engineering design not fundamental requirement. (4) Careful thinking and design are required if a signaling protocol combines them together, such as GMPLS ...... -- Guangzhi Yangguang Xu wrote: > Fong, > > My point is LIH is not the right place to put interface ID or Port ID. LIH > should be used to specify control plane signaling interface ID NOT data plane > transport interface ID. > > As for the port ID/or component_interface_ID, it should be part of a Label. The > definition of label in current GMPLS-Signaling functional spec. is incomplete. A > label should be associated with a specific switchable data flow (my definition). > Port ID + channel ID together form a meaningful unit. Separating them into two > objects is not necessary. The procedure is that (1) source node computes ERO in > logical link/bundle level of granularity (2) Each intermediate node specifies > the exact physical interface (the label) for connection creation according to > ERO and local information > > BTW, there seem to be some misunderstanding of bi-directional LSP creation in > transport network. In SONET/SDH transport network, (and also IP, ATM switches) > ports are normally bi-directionally identified (which means one port ID actually > indicates two physical ports, one IN, one OUT). So a label has bidirectionally > itself. If all ports within a network are bi-directionally identified, for a > bi-directional LSP, only one bi-directional label is needed. Upstream label, > from concept to implementation, is a redundancy. > > Regards, > > Yangguang From owner-mpls@UU.NET Tue Feb 20 17:33:58 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28205 for ; Tue, 20 Feb 2001 17:33: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 QQkdgc18824; Tue, 20 Feb 2001 22:33:57 GMT Received: by mail-control.mail.uu.net id QQkdgc22780 for mpls-outgoing; Tue, 20 Feb 2001 22:33:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdgc22771 for ; Tue, 20 Feb 2001 22:33:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdgc11062 for ; Tue, 20 Feb 2001 22:33:16 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkdgc26488 for ; Tue, 20 Feb 2001 22:33:15 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA01757 for ; Tue, 20 Feb 2001 17:32: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 RAA15012 for ; Tue, 20 Feb 2001 17:28:15 -0500 (EST) Message-ID: <3A92EFAF.B60A6DD1@marconi.com> Date: Tue, 20 Feb 2001 17:29:03 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: CR-LDP and RSVP implementation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >> - RSVP-TE uses a different QoS representation from CR-LDP > > Most of the objects associated with QoS in CR-LDP were lifted > bodily from RSVP-TE and the resemblence is striking. They both use the concept of a token bucket. But the number of buckets and their use is different. >> - RSVP-TE explicltly LSPs from a known ingress router to a known >> egress router. LDP distributes labels without a firm concept of >> an LSP during the signalling. CR-LDP appears to be like LDP in >> this respect, although the presence of an explicit route mitigates >> the difference somewhat. > > CR-LDP includes Explicit Routing using mechanisms and objects > that are very nearly identical to the objects included in RSVP-TE > (this time, both efforts "borrowed" from the same bank). But CR-LDP doesn't have a concept of a tunnel endpoint address. One can be derived from the ERO, but the ERO is not necessarily present. >> - There is no LDP or CR-LDP way to signal multiple LSPs that share >> resources. (RSVP's "SE" reservation style) > > CR-LDP accomplishes this using LSP-ID. I don't see this explicitly documented anywhere. The closest thing I see is the Action Indicator Flag, and it says nothing about reservation styles. It specifies whether the LSP being signalled is a new LSP or a modification. There is still no way to signal two separate LSPs that share resources. This can be for reasons other than a make-before-break operation. (For example, one could be a standby LSP waiting for a failover.) -- David From owner-mpls@UU.NET Tue Feb 20 21:55:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03088 for ; Tue, 20 Feb 2001 21:55: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 QQkdgt28465; Wed, 21 Feb 2001 02:55:24 GMT Received: by mail-control.mail.uu.net id QQkdgt14709 for mpls-outgoing; Wed, 21 Feb 2001 02:55: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 QQkdgt14704 for ; Wed, 21 Feb 2001 02:55:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdgt23820 for ; Wed, 21 Feb 2001 02:52:58 GMT Received: from mason2.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkdgt25295 for ; Wed, 21 Feb 2001 02:52:56 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id VAA01867; Tue, 20 Feb 2001 21:48:40 -0500 (EST) Date: Tue, 20 Feb 2001 21:48:40 -0500 (EST) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: jorge.rodriguez@telefonica-data.com cc: Callum Dodd , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Interoperability Juniper-Passport Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Jorge, Please see my inline comments On Fri, 16 Feb 2001 jorge.rodriguez@telefonica-data.com wrote: > Anybody has done interoperability tests between Juniper and Passport > 7000 (Nortel)? I just wanted to make sure that we are talking about the MPLS interoperability. We at AIL have done LDP interoperability testing between Juniper M20 and Nortel Passport 7440. This testing was also publicly demonstrated at the Ist Public MPLS Interoperability Demonstration that followed the MPLS 2000 conference held at George Mason University in October last year. >Success? We achieved success in what ever we tested and the high level results can be found at the following site: http://www.ail.gmu.edu/MPLS2000/proceedings/TUESDAY/03-Jabbari_IOTest_Results.pdf The presentation also higlights the topology that was used for performing the tests and the list of tests that were suceesfully performed. The 2nd Public MPLS Interoperability Demonstration will take place immediately after the MPLS2001 Conference which is scheduled for 7-9th October. The date for the demo. will be 10-12th of Oct. We will be putting up the the schedule shortly at the follwoing URL: http://www.ail.gmu.edu/MPLS2001.htm If you need any further information regarding the testing and conference please send a mail to ail@gmu.edu. Thanks. Regards, - Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4700 email: rpapneja@osf1.gmu.edu ******************************** > I'm about to do tests in > both MPLS level and with Juniper's CCC. > > If this lists weren't the right place, where could I get this kind of > information? > > I appreciate any input. > Thanks & regards, > Jorge > > ____________________________________ > Jorge Rodriguez-Gabilondo > Telefonica Data > Network Planning and Design > jorge.rodriguez@telefonica-data.com > +34 91 514 4082 > Hemos renovado nuestra web. Esperamos su visita en > http://www.telefonica-data.com From owner-mpls@UU.NET Tue Feb 20 22:07:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03230 for ; Tue, 20 Feb 2001 22:07: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 QQkdgu04518; Wed, 21 Feb 2001 03:07:15 GMT Received: by mail-control.mail.uu.net id QQkdgu00542 for mpls-outgoing; Wed, 21 Feb 2001 03:06:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdgu00533 for ; Wed, 21 Feb 2001 03:06:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdgu20062 for ; Wed, 21 Feb 2001 03:06:13 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdgu13530 for ; Wed, 21 Feb 2001 03:06:12 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA02591 for mpls@uu.net; Tue, 20 Feb 2001 22:06:12 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdgu00353 for ; Wed, 21 Feb 2001 03:05:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdgu19323 for ; Wed, 21 Feb 2001 03:05:55 GMT Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQkdgu13145 for ; Wed, 21 Feb 2001 03:05:54 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 TAA13754; Tue, 20 Feb 2001 19:05:57 -0800 (PST) Received: from jlawrenc-pc.cisco.com (dhcp-shinjuku-64-104-3-148.cisco.com [64.104.3.148]) by bulkrate.cisco.com (Mirapoint) with ESMTP id AFA06423; Tue, 20 Feb 2001 19:05:52 -0800 (PST) Message-Id: <4.3.2.7.2.20010221140003.00b2c8e0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Feb 2001 14:05:42 +1100 To: Paul Billinghurst From: Jeremy Lawrence Subject: Re: Downstream unsolicited and conservative retention Cc: "'mpls@uu.net'" In-Reply-To: <2F5F27915881D411B43F00508BD8935F81119F@sc-sol-04.extremene tworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Paul, My reading is that this paragraph amounts to "The combination of Downstream Unsolicited mode and conservative label retention is a bad idea and should not be implemented." Less flippant answers follow inline... At 07:45 02/20/2001 -0800, Paul Billinghurst wrote: >Regarding the scenario discussed in Section 3.5.7.1.4. of RFC 3036 > >"The combination of Downstream Unsolicited mode and conservative label > retention can lead to a situation where an LSR releases the label for > a FEC that it later needs. For example, if LSR Rd advertises to LSR > Ru the label for a FEC for which it is not Ru's next hop, Ru will > release the label. If Ru's next hop for the FEC later changes to Rd, > it needs the previously released label " > >The section says the following "To deal with this situation either Ru can >explicitly request the >label when it needs it, or Rd can periodically readvertise it to Ru ". > >Does this mean that even though during session initialization Ru stated it >was configured for downstream unsolicited it is allowed to send a label >request message. Have I understood this correctly ? Yes. >and does this mean the >downstream will accept a request from an upstream router that has signaled >that it is configured for Du ? Yes. >The latter mentioned solution i.e. periodically readvertise, is this >inferring periodic label refresh ? Yes, though it does seem a silly thing to imply. Regards, Jeremy Lawrence From owner-mpls@UU.NET Tue Feb 20 22:17:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03309 for ; Tue, 20 Feb 2001 22: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 QQkdgv27327; Wed, 21 Feb 2001 03:16:49 GMT Received: by mail-control.mail.uu.net id QQkdgv01746 for mpls-outgoing; Wed, 21 Feb 2001 03:16:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdgv01676 for ; Wed, 21 Feb 2001 03:16:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdgv13112 for ; Wed, 21 Feb 2001 03:16:03 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdgv25289 for ; Wed, 21 Feb 2001 03:16:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA03605 for mpls@uu.net; Tue, 20 Feb 2001 22:16:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdgv01573 for ; Wed, 21 Feb 2001 03:15:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdgv11573 for ; Wed, 21 Feb 2001 03:15:24 GMT Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQkdgv25436 for ; Wed, 21 Feb 2001 03:15:23 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 TAA17955; Tue, 20 Feb 2001 19:15:25 -0800 (PST) Received: from jlawrenc-pc.cisco.com (dhcp-shinjuku-64-104-3-148.cisco.com [64.104.3.148]) by bulkrate.cisco.com (Mirapoint) with ESMTP id AFA06474; Tue, 20 Feb 2001 19:15:21 -0800 (PST) Message-Id: <4.3.2.7.2.20010221140629.00b344a0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Feb 2001 14:15:11 +1100 To: thomas.huang@att.net From: Jeremy Lawrence Subject: Re: How the merged traffic to be splitted? Cc: mpls@UU.NET In-Reply-To: <20010220172818.MZBJ19355.mtiwmhc23.worldnet.att.net@webmai l.worldnet.att.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Thomas, The ASCII diagrams seem not to have survived intact, but: At 17:28 02/20/2001 +0000, thomas.huang@att.net wrote: >Hello: > >It seems to me that the MPLS drafts related to the Label >Merging have not shown how the Label Merge feature can >be used in a practical application. > >I would appreciate your pointers on the following two >questions: > >1) in the following configuration, how the merged label >traffic can be split to two different destination LERs E >and F? > and how the x and y signaled? > > Ingress A \ >label:1 / LER E > >\ /?x > LSR C ----Label 3-------LSR D > / > \?y > Ingress B / label >2 \LER F That is a situation which will not happen by label merging. >2) or the label merge only valid for the following >configuration for IP traffic (not ATM/FR!)? > > Ingress A \ >label:1 > >\ > LSR C ----Label 3-------LER D > / > > Ingress B / label 2 #2 is true. Only labels of the same FEC (e.g. the same CoS and destination) may be merged. Merged traffic is split only at the destination eLSR. Label merge can be done by ATM-LSRs which support VC-merge, by the way. Jeremy Lawrence From owner-mpls@UU.NET Wed Feb 21 01:16:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07598 for ; Wed, 21 Feb 2001 01:16: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 QQkdhh27379; Wed, 21 Feb 2001 06:16:40 GMT Received: by mail-control.mail.uu.net id QQkdhh29425 for mpls-outgoing; Wed, 21 Feb 2001 06:16:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdhh29349 for ; Wed, 21 Feb 2001 06:15:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdhh11025 for ; Wed, 21 Feb 2001 06:15:38 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 QQkdhh27785 for ; Wed, 21 Feb 2001 06:15:38 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 BAA05913 for ; Wed, 21 Feb 2001 01:15:38 -0500 (EST) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id BAA05880 for ; Wed, 21 Feb 2001 01:15:35 -0500 (EST) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <1GKM3JSN>; Wed, 21 Feb 2001 11:45:31 +0530 Message-ID: From: "B, Prakash K (Prakash)" To: "'Eric Gray'" Cc: "'mpls@uu.net'" Subject: RE: Hop Count Procedures Date: Wed, 21 Feb 2001 11:45:28 +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 Hello Eric, Assume an LSP comprises LSRs Ra, Rb, Rc and Rd with Ra as the ingress and Rd as the eggress nodes and all of them are capable of TTL decrement. There is a tunnel1 between Ra and Rb comprising LSRs R1, R2, R3 and R4. Similarily, R5-R8 is the tunnel2 connecting Rc and Rd. Rb and Rc are direct neighbours. R1 to R8 are ATM LSRs. From the above configuration, it follows that Ra is the ingress to tunnel1 whose eggress is Rb. Similarily Rc and Rd are the ingress and egress LSRs of tunnel2. If a packet enters this network, it encounters 12 nodes in all. Will the TTL of the packet emerging from Rd be (Original TTL - 12) or should it be simply(Original TTL - 4).?? TTL -4 will be the case if the tunnels are of Non TTL decrement type and one of the feature claimed here is the concept of tunnels being oblivious to the end user (possibly an IP cloud connected to Rd). Do the same rules apply when the tunnels are capable of TTL decrement?? Regards, Prakash -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Tuesday, February 20, 2001 9:25 PM To: B, Prakash K (Prakash) Cc: 'mpls@uu.net' Subject: Re: Hop Count Procedures "B, Prakash K (Prakash)" wrote: > ATM LSRS do not perform TTL decrement. RFC 3036 says that while propogating > the label mapping message upstream, if an LSR (Rd) finds out that its > upstream LSR (Ru) is a part of domain that does not perform TTL > decrement(ATM segment), it must reset the Hop Count value to 1. Will this > not lead to erroneous computation of final TTL in the long run when the > packet exits out of MPLS domain?Will not the true Hop count value assist the > ingress in determining in advance the TTL value that must be, when the > packet emerges out of a Non -TTL-decrement segment? > > RFC 3031 clearly states that the final TTL value must reflect the true > number of hops that a packet takes to exit a MPLS domain . > Clarification solicited. > > Prakash K.B. Prakash, The intention is to allow the ATM ingress LSR to be able to decrement the TTL by the value of the hop count in LSP setup messages used to establish an LSP that will be used to forward data. Note that the ATM ingress LSR does not have to do this, but it could (if configured to do so, for instance, by the network operator). In other words, when the ingress ATM LSR is about to put a packet on a specific LSP, one of the things that it should get in the FTN lookup is the decrement value for the packet's TTL. The source of this value may be the hop count received in the LSP setup messages. This will be the case if the operator intends their ATM "tunnel" to be apparent to the end user. Once the packet arrives at the egress from the ATM cloud, the next hop will decrement the TTL by some non-zero value and this will happen for each of the non-ATM LSRs in the remainder of the LSP - up to and including the hop count of the LSP setup. If the hop count was not reset to 1 by the LSR at the egress from the ATM cloud (instead, reflecting all of the hops in the LSP downstream), the result would be to (possibly) decrement the TTL of packets arriving at the ingress to the ATM cloud by the number of hops in the entire LSP and then decrementing it again at every non-ATM LSR hop. This could cause premature packet demise. -- Eric Gray From owner-mpls@UU.NET Wed Feb 21 02:45:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20547 for ; Wed, 21 Feb 2001 02:45: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 QQkdhn16040; Wed, 21 Feb 2001 07:45:44 GMT Received: by mail-control.mail.uu.net id QQkdhn20180 for mpls-outgoing; Wed, 21 Feb 2001 07:45: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 QQkdhm20099 for ; Wed, 21 Feb 2001 07:44:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdhm26508 for ; Wed, 21 Feb 2001 07:43:06 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkdhm12827 for ; Wed, 21 Feb 2001 07:43:06 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 CAA11168 for ; Wed, 21 Feb 2001 02:43:05 -0500 (EST) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA11161 for ; Wed, 21 Feb 2001 02:43:02 -0500 (EST) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <1GKM3K5W>; Wed, 21 Feb 2001 13:13:00 +0530 Message-ID: From: "B, Prakash K (Prakash)" To: "'mpls@uu.net'" Subject: Hello parameters TLV Date: Wed, 21 Feb 2001 13:12:58 +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 Hello messages are exchanged in the Discovery phase of operation. The message also carries optional parameters that could either be IPV4 or IPV6 transport address of the sender. What will be the case if the LSRs were ATM switches. Will the IP addresses be replaced by E.164 equivalent? Regards, Prakash From owner-mpls@UU.NET Wed Feb 21 04:53:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21427 for ; Wed, 21 Feb 2001 04:53: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 QQkdhv08582; Wed, 21 Feb 2001 09:53:57 GMT Received: by mail-control.mail.uu.net id QQkdhv29837 for mpls-outgoing; Wed, 21 Feb 2001 09:53:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdhv29832 for ; Wed, 21 Feb 2001 09:53:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdhv08836 for ; Wed, 21 Feb 2001 09:53:14 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdhv11494 for ; Wed, 21 Feb 2001 09:53:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA20711 for mpls@uu.net; Wed, 21 Feb 2001 04:53:13 -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 QQkdhv29823 for ; Wed, 21 Feb 2001 09:52:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdhv29106 for ; Wed, 21 Feb 2001 09:51:06 GMT Received: from miles.dataconnection.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.dataconnection.com [192.91.191.8]) id QQkdhv07862 for ; Wed, 21 Feb 2001 09:51:06 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <1Z4MYZK6>; Wed, 21 Feb 2001 09:50:51 -0000 Message-ID: From: Adrian Farrel To: Guangzhi Li , Yangguang Xu Cc: Zaffire - Fong Liaw , "'mpls@uu.net'" Subject: RE: signaling in draft-kompella-mpls-bundle-04.txt Date: Wed, 21 Feb 2001 09:50:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In summary... - I agree with Yangguang, and this is what I intended to convey. LIH is NOT the field to use to identify a component link. - I agree with Fong that identifying a component link in a unidirectional or bidirectional LSP is not entirely clear from the drafts. However, - on a hop-by-hop basis we have everything we need from the bundling draft - from the perspective of the ERO there are three options - number the component links and use the IP addresses as the hops in the ERO - consider the component links as unnumbered and use the extensions from draft-ietf-mpls-rsvp-unnum and draft-ietf-mpls-crldp-unnum to identify the links - GMPLS introduces explicit label subobjects in the ERO, these are generalized labels and are strictly for the interpretation of the LSR that the hop identifies - they could easily encode a component link id if that is what you need/want I favor the third option. Note, however, that many people consider it a private and local matter how an LSR chooses which component link of a bundle to use for a particular LSP. If the LSR wanted it to be a public matter it would advertise the components of the bundle as distinct links (and we would then use option 1 or 2, above). 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: Guangzhi Li [mailto:gli@research.att.com] >Sent: Tuesday, February 20, 2001 10:22 PM >To: Yangguang Xu >Cc: Zaffire - Fong Liaw; 'mpls@uu.net' >Subject: Re: signaling in draft-kompella-mpls-bundle-04.txt > > >Hi, > >I agree with Yangguang. There are some confusion between IP >networks and transport >networks. >(1) IP network signaling is in-band but most transport >signaling is out-band or >out-fiber. For transport network, there is a "separate" >signaling network. >(2) IP network LSPs are fundamental uni-directioanl but most >transport network LSPs >are bi-directional. >(3) IP network bi-directional LSPs need two labels but most >transport network >bi-directional LSPs only need one label. Of course it is due >to engineering design >not fundamental requirement. >(4) Careful thinking and design are required if a signaling >protocol combines them >together, such as GMPLS ...... > >-- Guangzhi > > >Yangguang Xu wrote: > >> Fong, >> >> My point is LIH is not the right place to put interface ID >or Port ID. LIH >> should be used to specify control plane signaling interface >ID NOT data plane >> transport interface ID. >> >> As for the port ID/or component_interface_ID, it should be >part of a Label. The >> definition of label in current GMPLS-Signaling functional >spec. is incomplete. A >> label should be associated with a specific switchable data >flow (my definition). >> Port ID + channel ID together form a meaningful unit. >Separating them into two >> objects is not necessary. The procedure is that (1) source >node computes ERO in >> logical link/bundle level of granularity (2) Each >intermediate node specifies >> the exact physical interface (the label) for connection >creation according to >> ERO and local information >> >> BTW, there seem to be some misunderstanding of >bi-directional LSP creation in >> transport network. In SONET/SDH transport network, (and also >IP, ATM switches) >> ports are normally bi-directionally identified (which means >one port ID actually >> indicates two physical ports, one IN, one OUT). So a label >has bidirectionally >> itself. If all ports within a network are bi-directionally >identified, for a >> bi-directional LSP, only one bi-directional label is needed. >Upstream label, >> from concept to implementation, is a redundancy. >> >> Regards, >> >> Yangguang > > > From owner-mpls@UU.NET Wed Feb 21 08:43:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25843 for ; Wed, 21 Feb 2001 08:43:02 -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 QQkdik00967; Wed, 21 Feb 2001 13:43:02 GMT Received: by mail-control.mail.uu.net id QQkdik16485 for mpls-outgoing; Wed, 21 Feb 2001 13:42:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdik16475 for ; Wed, 21 Feb 2001 13:42:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdik01863 for ; Wed, 21 Feb 2001 13:41:53 GMT From: djiang1@lucent.com Received: from auemlsrv.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkdik29387 for ; Wed, 21 Feb 2001 13:41:52 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 IAA13004 for ; Wed, 21 Feb 2001 08:41:52 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA12989; Wed, 21 Feb 2001 08:41:51 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA01501; Wed, 21 Feb 2001 08:41:49 -0500 (EST) Subject: RE: Hop Count Procedures To: "B, Prakash K (Prakash)" Cc: "'Eric Gray'" , "'mpls@uu.net'" Date: Wed, 21 Feb 2001 08:38:19 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/21/2001 08:38:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Prahash, I believe the TTL in your case should be deducted by 12 instead of 4. 12 is the number of routers the traffic has been through. There should be no reason to deduct less that 12. It should not matter whether the traffic was tunneled or not. Regards, Jane D. Jiang "B, Prakash K (Prakash)" @UU.NET on 02/21/2001 01:15:28 AM Sent by: owner-mpls@UU.NET To: "'Eric Gray'" cc: "'mpls@uu.net'" Subject: RE: Hop Count Procedures Hello Eric, Assume an LSP comprises LSRs Ra, Rb, Rc and Rd with Ra as the ingress and Rd as the eggress nodes and all of them are capable of TTL decrement. There is a tunnel1 between Ra and Rb comprising LSRs R1, R2, R3 and R4. Similarily, R5-R8 is the tunnel2 connecting Rc and Rd. Rb and Rc are direct neighbours. R1 to R8 are ATM LSRs. From the above configuration, it follows that Ra is the ingress to tunnel1 whose eggress is Rb. Similarily Rc and Rd are the ingress and egress LSRs of tunnel2. If a packet enters this network, it encounters 12 nodes in all. Will the TTL of the packet emerging from Rd be (Original TTL - 12) or should it be simply(Original TTL - 4).?? TTL -4 will be the case if the tunnels are of Non TTL decrement type and one of the feature claimed here is the concept of tunnels being oblivious to the end user (possibly an IP cloud connected to Rd). Do the same rules apply when the tunnels are capable of TTL decrement?? Regards, Prakash -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Tuesday, February 20, 2001 9:25 PM To: B, Prakash K (Prakash) Cc: 'mpls@uu.net' Subject: Re: Hop Count Procedures "B, Prakash K (Prakash)" wrote: > ATM LSRS do not perform TTL decrement. RFC 3036 says that while propogating > the label mapping message upstream, if an LSR (Rd) finds out that its > upstream LSR (Ru) is a part of domain that does not perform TTL > decrement(ATM segment), it must reset the Hop Count value to 1. Will this > not lead to erroneous computation of final TTL in the long run when the > packet exits out of MPLS domain?Will not the true Hop count value assist the > ingress in determining in advance the TTL value that must be, when the > packet emerges out of a Non -TTL-decrement segment? > > RFC 3031 clearly states that the final TTL value must reflect the true > number of hops that a packet takes to exit a MPLS domain . > Clarification solicited. > > Prakash K.B. Prakash, The intention is to allow the ATM ingress LSR to be able to decrement the TTL by the value of the hop count in LSP setup messages used to establish an LSP that will be used to forward data. Note that the ATM ingress LSR does not have to do this, but it could (if configured to do so, for instance, by the network operator). In other words, when the ingress ATM LSR is about to put a packet on a specific LSP, one of the things that it should get in the FTN lookup is the decrement value for the packet's TTL. The source of this value may be the hop count received in the LSP setup messages. This will be the case if the operator intends their ATM "tunnel" to be apparent to the end user. Once the packet arrives at the egress from the ATM cloud, the next hop will decrement the TTL by some non-zero value and this will happen for each of the non-ATM LSRs in the remainder of the LSP - up to and including the hop count of the LSP setup. If the hop count was not reset to 1 by the LSR at the egress from the ATM cloud (instead, reflecting all of the hops in the LSP downstream), the result would be to (possibly) decrement the TTL of packets arriving at the ingress to the ATM cloud by the number of hops in the entire LSP and then decrementing it again at every non-ATM LSR hop. This could cause premature packet demise. -- Eric Gray From owner-mpls@UU.NET Wed Feb 21 09:38:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27912 for ; Wed, 21 Feb 2001 09:38: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 QQkdio27715; Wed, 21 Feb 2001 14:38:02 GMT Received: by mail-control.mail.uu.net id QQkdio06722 for mpls-outgoing; Wed, 21 Feb 2001 14:37: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 QQkdio06707 for ; Wed, 21 Feb 2001 14:37: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 QQkdio04479 for ; Wed, 21 Feb 2001 14:36: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 QQkdio25615 for ; Wed, 21 Feb 2001 14:36: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 GAA11494 for ; Wed, 21 Feb 2001 06:36:53 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA01867 for mpls@uu.net; Wed, 21 Feb 2001 09:36:35 -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 QQkdhu28567 for ; Wed, 21 Feb 2001 09:40:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdhu26928 for ; Wed, 21 Feb 2001 09:40:38 GMT Received: from smtp1.gtsgroup.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp1.gtsgroup.com [195.158.230.16]) id QQkdhu17526 for ; Wed, 21 Feb 2001 09:40:36 GMT Received: from 207.77.231.73 by smtp1.gtsgroup.com (InterScan E-Mail VirusWall NT); Wed, 21 Feb 2001 10:33:13 +0100 (W. Europe Standard Time) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Feb 2001 10:38:14 +0100 Message-ID: From: "Mannie, Eric" To: "'ip-optical@lists.bell-labs.com'" , "'mpls@uu.net'" Subject: FW: [IP-Optical] GMPLS enhancements Date: Wed, 21 Feb 2001 10:38:13 +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 Hi all, Apparently my e-mail didn't come thru on some mailing lists for some reasons. So, I resend it. Sorry, if you receive it twice. Eric -----Original Message----- From: Mannie, Eric Sent: Monday, February 19, 2001 7:27 PM To: 'Maarten Vissers' Cc: ip-optical@lists.bell-labs.com; Ben Mack-Crane (E-mail); Greg Bernstein (E-mail); Bala Rajagopalan (E-mail); Debanjan Saha (E-mail); Michael Raftelis (E-mail); Shash Chatterjee (E-mail); Jeff Connell (E-mail); Xu, Yangguang; Lin, Zhi-Wei (Zhi); Vishal Sharma; 'ccamp@ops.ietf.org'; 'mpls@uu.net' Subject: RE: [IP-Optical] GMPLS enhancements Hi Maarten, I think that you misunderstood some important things about the label, I'll try to clarify in the following. First, as you know, - All AUGs ("STM-1s" ) in an STM-N are byte interleaved : no hierarchy, "flat" stuff ! - The AUs, TUGs, TUs in an AUG ("STM-1") are nested following some specific rules: "tree-like" hierarchy. - A label identifies the first time-slot (or component) of a particular signal, not the full aggregate. Consequently, you need separate values to identify the nesting (UKLM) and only one value to identify any component in the interleaving (S = index). We just need to identify ONE STM-1/AUG in a group of N STM-1s/AUGs. The S field is a simple index, it is flat and there is no reason to represent something flat as a hierarchy. So there is no reason to use E, D, C, B ! And yes, one STM-1 can be seen as a time-slot if all STM-1s are (logically) time-division multiplexed. For instance, if you want to transport four STM-1s "transparently" you will have four STM-1s, each one with an independent overhead. This can be achieved by interleaving the four overheads, or by tunneling the overheads. How this transparency is achieved is proprietary in the data plane, different vendors have different solutions. At least we would like to have a standardized solution to request and use it in the control plane. I understand your confusion since we don't use a regular SDH/SONET, but their are common tricks that vendors are implementing and that are useful to control in a generic way via the GMPLS control plane. So, we are not 100% glued to G.707. The same apply for protection/restoration since we are not tied anymore to only the protection/restoration schemes standardized by ITU-T, the fast meshed restoration is an example. In addition, you want to indicate some fixed concatenation levels (AU-4-4c, AU-4-16c, AU-4-64c and AU-4-256c) in the label. This is not appropriate since there are plenty of other different levels of concatenation, indeed all levels are possible, e.g. AU-4-7c. The concatenation is anyway better indicated separately, it is orthogonal with a label. Think also about contiguous concatenation for example, I could want to concatenate the 3rd, 4th and 5th STM-1/AUG, so I just need to say S=3 to indicate where begins my concatenation. Arbitrary concatenation is commonly used. Moreover, we want to be able to manipulate circuits of any size, concatenated or not (e.g. an STM-7 or STM-255). With you proposal it would be impossible to do so since we can only encode the index of a few time-slots. We really need to encode the index of each possible STM-1/AUG. We go further than a pure G.707. Concerning your comment about SDH ADM and cross connect equipment that may have separate Higher Order and Lower Order fabrics, please refer to our discussion that occurred two months ago when I explained the nesting of LSPs and how it can be applied to SDH/SONET. One of the benefits of GMPLS is to allow different classes of equipments, those that can switch higher orders in the core and those that can switches lower orders in the metro/access. Indeed, you can design any kind of equipment. Circuits are just nested in circuits. That's why the higher part or lower part of a label (respectively) can be zeroed to indicate irrelevant (see editorial bug that we discussed, should be corrected in the next version of GMPLS, S=0 is valid). Kind regards, Eric > Note that the latest version of G.707 (10/00) has defined a naming > structure for the AU's, similar to that for the TU's. AUs are now named > according the EDCBA structure (TUs are named according the KLM > structure). It is thus possible to replace the S,U number by the > standardised number E,D,C,B,A. The specification could be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | E | D | C | B | A | K | L | M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For SDH, this is an extension of the numbering scheme defined in > G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For > SONET the K field is not significant and must be set to zero. > > Each letter indicates a possible branch number starting at the parent > node in the multiplex structure. Branches are considered as numbered > in increasing order, starting from the top of the multiplexing > structure. The numbering starts at 1, zero is used to indicate a non- > significant field. > > When a field is not significant in a particular context it MUST be > set to zero when transmitted, and MUST be ignored when received. > > 1. E indicates possible branches of a STM-256/OC786. It is not > meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12, > STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case. > E=1 indicates that the STM-256/OC768 is not further sub-divided > and contains an AU-4-256c/STS768c. > E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768. > > 2. D indicates possible branches of either an AUG-64 or a > STM-64/OC192. > It is not meaningful for the cases of STM-16/OC48, STM-4/OC12, > STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case. > D=1 indicates that the AUG-64 or STM-64/OC192 is not further > sub-divided and contains an AU-4-64c/STS192c. > D=2->5 indicates a specific AUG-16 inside the given AUG-64 or > STM-64/OC192. > > 3. C indicates possible branches of either an AUG-16 or a > STM-16/OC48. > It is not meaningful for the cases of STM-4/OC12, STM-1/OC3, > STM-0/OC1 multiplexing and must be 0 in that case. > C=1 indicates that the AUG-16 or STM-16/OC48 is not further > sub-divided and contains an AU-4-16c/STS48c. > C=2->5 indicates a specific AUG-4 inside the given AUG-16 or > STM-16/OC48. > > 4. B indicates possible branches of either an AUG-4 or a STM-4/OC12. > It is not meaningful for the cases of STM-1/OC3, STM-0/OC1 > multiplexing and must be 0 in that case. > B=1 indicates that the AUG-4 or STM-4/OC12 is not further > sub-divided and contains an AU-4-4c/STS12c. > B=2->5 indicates a specific AUG-1 inside the given AUG-4 or > STM-4/OC12. > > 5. A indicates possible branches of either an AUG-1 or a STM-1/OC3. > It is not meaningful for the case of STM-0/OC1 multiplexing > and must be 0 in that case. A=1 indicates that the AUG-1 or > STM-1/OC3 is not further sub-divided and contains an > AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given > AUG-1 or STM-1/OC3. > > 6. K is only significant for SDH and must be ignored for SONET. It > indicates a specific branch of a VC-4. K=1 indicates that the > VC-4 is not further sub-divided and contains a C-4. K=2->4 > indicates a specific TUG-3 inside the VC-4. K is not > significant when the STM-1 is divided into VC-3s (easy to read > and test). > > 7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It > is not significant for an unstructured VC-4. L=1 indicates that > the TUG-3/VC-3/STS-1 SPE is not further sub-divided and > contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 > indicates a specific TUG-2/VT Group inside the corresponding > higher order signal. > > 8. M indicates a specific branch of a TUG-2/VT Group. It is not > significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 > SPE. M=1 indicates that the TUG-2/VT Group is not further > sub-divided and contains a VC-2/VT-6. M=2->3 indicates a > specific VT-3 inside the corresponding VT Group, these values > MUST NOT be used for SDH since there is no equivalent of VT-3 > with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the > corresponding TUG-2/VT Group. M=7->10 indicates a specific > VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried > within a TU-11. M=11->13 indicates a specific VC-11 inside the > corresponding TUG-2 carried within a TU-12. Note that M=0 denotes > an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). > > Some examples: > EDCBAKLM > - 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0) > in a STM-16/OC48 > - 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768 > - 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0) > in a STM-256/OC768 > - 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192 > - 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal. > > The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3) > structure in a STM-16 could then consist of the following set of labels: > > EDCBAKLM > - 00210000 AU-4-4c (1,0,0) > - 00321000 AU-4 (2,1,0) > - 00331000 AU-4 (2,2,0) > - 00341000 AU-4 (2,3,0) > - 00351000 AU-4 (2,4,0) > - 00410000 AU-4-4c (3,0,0) > - 00521000 AU-4 (4,1,0) > - 00532000 AU-3 (4,2,1) > - 00533000 AU-3 (4,2,2) > - 00534000 AU-3 (4,2,3) > - 00541000 AU-4 (4,3,0) > - 00551000 AU-4 (4,4,0) > > For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering > scheme has the bandwidth implied. There is no need to code this > bandwidth seperately anylonger. > > Question related to the definition of "M": > ------------------------------------------ > "M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to > transport a VC-11 via a TU-12, I believe that the M range should be > extended with values 11 to 13 as follows: > > The M encoding is summarized in the following table: > > M SDH SONET > ---------------------------------------------------------- > 0 unstructured VC-4/VC-3 unstructured STS-1 SPE > 1 VC-2 VT-6 > 2 - 1st VT-3 > 3 - 2nd VT-3 > 4 1st VC-12 1st VT-2 > 5 2nd VC-12 2nd VT-2 > 6 3rd VC-12 3rd VT-2 > 7 1st VC-11 in TU-11 1st VT-1.5 > 8 2nd VC-11 in TU-11 2nd VT-1.5 > 9 3rd VC-11 in TU-11 3rd VT-1.5 > 10 4th VC-11 in TU-11 4th VT-1.5 > 11 1st VC-11 in TU-12 - > 12 2nd VC-11 in TU-12 - > 13 3rd VC-11 in TU-12 - > > At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive > monitors) as a VC-12. At the path endpoints however, the VC-11 is > treated as a VC-11. > > Coding the lower order VC (LOVC)/VT signals: > -------------------------------------------- > SDH ADM and cross connect equipment may have separate Higher Order and > Lower Order fabrics. This decouples the TU identification from the AU > timeslot and associated physical port. I.e. EDCBAKLM label should be > split into separate EDCBA and KLM labels. > > Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M" > VC4 termination points connected to the LO Fabric. > > The TU timeslots are defined with reference to a VC4 termination point. > The VC4 signal geenrated by a VC4 termination point can be transported > over any of the STM-N signals; there is no predefined relationship, > neither is there a permanent relationship (i.e. it is possible to > re-route the VC-4 without tearing it down, or tearing down the LOVC > connection over it). > > As such, the TU timeslots should be numbered with respect to its VC4 > termination point, not with respect to the AU4 timeslot in an STM-N; The > AU4/STM-N part of the label may change over time, whereas the TU link > connection and TU connection point stay the same. > Resulting label should be "". > > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO > FABRIC > signal PORT timeslots | | Term. timeslots > | | Points per VC4 TP > | | > STM-N --- PHY --- "N" AU -------| | > timeslots | > STM-N --- PHY --- "N" AU ----------| > timeslots > > Figure 1 - SDH ADM with separate HO and LO Fabrics > > The HO Fabric contains the relation between AU number and VC4 TP number, > as well as between between two AU numbers (case of STM-N - AU - STM-N > connection). > > <-- phys. <--- EDCBA <--- VC4 <--- KLM > port AU TP TU > number number number number > > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO > FABRIC > signal PORT timeslots | | Term. timeslots > | | Points per VC4 TP > > Figure 2 - numbering > > Regards, > > Maarten From owner-mpls@UU.NET Wed Feb 21 10:44:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00179 for ; Wed, 21 Feb 2001 10:44: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 QQkdis29695; Wed, 21 Feb 2001 15:43:59 GMT Received: by mail-control.mail.uu.net id QQkdis28983 for mpls-outgoing; Wed, 21 Feb 2001 15:43: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 QQkdis28964 for ; Wed, 21 Feb 2001 15:43:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdis17098 for ; Wed, 21 Feb 2001 15:42:16 GMT Received: from rly-ip01.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip01.mx.aol.com [205.188.156.49]) id QQkdis26884 for ; Wed, 21 Feb 2001 15:42:16 GMT Received: from tot-wj.proxy.aol.com (tot-wj.proxy.aol.com [205.188.198.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id KAA23829; Wed, 21 Feb 2001 10:42:13 -0500 (EST) Received: from cs.columbia.edu (AC8059B4.ipt.aol.com [172.128.89.180]) by tot-wj.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f1LFgCx20424; Wed, 21 Feb 2001 10:42:12 -0500 (EST) Message-ID: <3A93E1BC.25270509@cs.columbia.edu> Date: Wed, 21 Feb 2001 07:41:48 -0800 From: Ping Pan X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "B, Prakash K (Prakash)" CC: "'mpls@uu.net'" Subject: Re: Hello parameters TLV References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "B, Prakash K (Prakash)" wrote: > > Hello messages are exchanged in the Discovery phase of operation. The > message also carries optional parameters that could either be IPV4 or IPV6 > transport address of the sender. What will be the case if the LSRs were ATM > switches. Will the IP addresses be replaced by E.164 equivalent? > Doubt it. Hello is to provide IP-level neighbor "liveness". It is useful during RSVP processing and to provide information on nhop/nhop. Since ATM address is not involved (or visible) in RSVP, so don't think there is a need for having it in hello. - Ping From owner-mpls@UU.NET Wed Feb 21 10:59:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00782 for ; Wed, 21 Feb 2001 10:59: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 QQkdit29084; Wed, 21 Feb 2001 15:59:42 GMT Received: by mail-control.mail.uu.net id QQkdit01171 for mpls-outgoing; Wed, 21 Feb 2001 15:59:11 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 QQkdit01148 for ; Wed, 21 Feb 2001 15:58: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 QQkdit24960 for ; Wed, 21 Feb 2001 15:58:33 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 QQkdit05332 for ; Wed, 21 Feb 2001 15:58:32 GMT Received: from zsc4c002.us.nortel.com by smtprch2.nortel.com; Wed, 21 Feb 2001 09:53:14 -0600 Received: from zsc4c004.us.nortel.com ([47.81.138.49]) by zsc4c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1QB2VZZ9; Wed, 21 Feb 2001 07:58:06 -0800 Received: from tsenevir-2 (archt1yd.us.nortel.com [47.134.241.41]) by zsc4c004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1AMWNVSV; Wed, 21 Feb 2001 07:58:04 -0800 Message-Id: <3.0.32.20010221075200.00c0e100@Zsc4c004.us.nortel.com> X-Sender: tsenevir@Zsc4c004.us.nortel.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 21 Feb 2001 07:52:03 -0800 To: mpls@UU.NET X-Sybari-Space: 00000000 00000000 00000000 From: "Tissa Senevirathne" Subject: Secure MPLS Cc: Olivier.Paridaens@alcatel.be Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Hi All Attached below are two drafts we published recently on MPLS payload encryption. First draft discuss the architecture and signaling for Secure MPLS. The second draft discuss the Domain of Interpretation for the Secure MPLS. http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-01.txt http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt Encryption of MPLS payload has specially become an important requirement in Metro Services Infrastructure, where Port based VPN is provided by the PE devices. Please provide us with the feedback, especially how the Security architecture is mapped in to the MPLS architecture. Thanks All Tissa Senevirathne (Nortel) Olivier Paridaens (alcatel) From owner-mpls@UU.NET Wed Feb 21 11:31:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01943 for ; Wed, 21 Feb 2001 11:31: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 QQkdiw28560; Wed, 21 Feb 2001 16:31:36 GMT Received: by mail-control.mail.uu.net id QQkdiw20351 for mpls-outgoing; Wed, 21 Feb 2001 16:31: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 QQkdiw20332 for ; Wed, 21 Feb 2001 16:31: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 QQkdiw04392 for ; Wed, 21 Feb 2001 16:30:37 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdiw06631 for ; Wed, 21 Feb 2001 16:30:37 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id B417F94006; Wed, 21 Feb 2001 11:30:36 -0500 (EST) Message-ID: <3A93ED2C.4C831C53@sandburst.com> Date: Wed, 21 Feb 2001 11:30:36 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "B, Prakash K (Prakash)" Cc: "'mpls@uu.net'" Subject: Re: Hop Count Procedures References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Prakash, The reason for decrementing TTL is to prevent packets from endlessly looping. Hence technologies which do not support decrementing TTL need to provide another means for loop prevention or mitigation. If a technology provides - for example - a mechanism to prevent loop formation in LSPs, then the network may gain very little from having accelerated aging. In fact, the prevalence of accelerated aging tends to lead to higher initial TTL values in the network off-setting at least some of the benefits expected in networks which use TTL exclusively. So there are two questions the network operator has to ask themselves: 1) do they want to treat the tunnel as a link? and 2) can they do this without harming the network? In some cases, not treating a tunnel as a link can harm the network. For example, in the not too distant past, initial TTL values were set fairly low in some operating systems. During that time, all it took was for a service provider to insert one more router in the transit network and suddenly numerous network destinations were no longer reachable. In an ideal world, there should not be a detrimental impact on the service being provided as a result of deliberate changes in the network infrastructure. The networking community's response to this was to increase the default TTL in their operating systems by as much as a factor of 8 - thus increasing the impact of looping traffic (originating from these hosts) on the network by a factor of between 2 and 4. However, it is not safe to treat a tunnel as a link if it can be arbitrarily long (for example - as a result of the fact that it can have transient looping). It may also be unsafe to treat a tunnel as a link if its egress can change without detection at the ingress - however this can happen in an L2 network with a real L3 link, so it is not really clear just how unsafe this is. I would think it is much less safe in a network where this can happen fairly often. So, I would say that you cannot compare the use of TTL in tunneling across a network technology that does not support decrementing TTL with the use of TTL in other network technologies. -- Eric Gray You wrote: > Hello Eric, > Assume an LSP comprises LSRs Ra, Rb, Rc and Rd with Ra as the ingress and Rd > as the eggress nodes and all of them are capable of TTL decrement. > There is a tunnel1 between Ra and Rb comprising LSRs R1, R2, R3 and R4. > Similarily, R5-R8 is the tunnel2 connecting Rc and Rd. > Rb and Rc are direct neighbours. R1 to R8 are ATM LSRs. > > >From the above configuration, it follows that Ra is the ingress to tunnel1 > whose eggress is Rb. Similarily Rc and Rd are the ingress and egress LSRs of > tunnel2. > > If a packet enters this network, it encounters 12 nodes in all. > > Will the TTL of the packet emerging from Rd be (Original TTL - 12) or should > it be simply(Original TTL - 4).?? > > TTL -4 will be the case if the tunnels are of Non TTL decrement type and one > of the feature claimed here is the concept of tunnels being oblivious to the > end user (possibly an IP cloud connected to Rd). > > Do the same rules apply when the tunnels are capable of TTL decrement?? > > Regards, > Prakash > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Tuesday, February 20, 2001 9:25 PM > To: B, Prakash K (Prakash) > Cc: 'mpls@uu.net' > Subject: Re: Hop Count Procedures > > "B, Prakash K (Prakash)" wrote: > > > ATM LSRS do not perform TTL decrement. RFC 3036 says that while > propogating > > the label mapping message upstream, if an LSR (Rd) finds out that its > > upstream LSR (Ru) is a part of domain that does not perform TTL > > decrement(ATM segment), it must reset the Hop Count value to 1. Will this > > not lead to erroneous computation of final TTL in the long run when the > > packet exits out of MPLS domain?Will not the true Hop count value assist > the > > ingress in determining in advance the TTL value that must be, when the > > packet emerges out of a Non -TTL-decrement segment? > > > > RFC 3031 clearly states that the final TTL value must reflect the true > > number of hops that a packet takes to exit a MPLS domain . > > Clarification solicited. > > > > Prakash K.B. > > Prakash, > > The intention is to allow the ATM ingress LSR to be able to > decrement the TTL by the value of the hop count in LSP setup > messages used to establish an LSP that will be used to forward > data. Note that the ATM ingress LSR does not have to do this, > but it could (if configured to do so, for instance, by the network > operator). > > In other words, when the ingress ATM LSR is about to put a > packet on a specific LSP, one of the things that it should get in > the FTN lookup is the decrement value for the packet's TTL. > The source of this value may be the hop count received in the > LSP setup messages. This will be the case if the operator > intends their ATM "tunnel" to be apparent to the end user. > > Once the packet arrives at the egress from the ATM cloud, > the next hop will decrement the TTL by some non-zero value > and this will happen for each of the non-ATM LSRs in the > remainder of the LSP - up to and including the hop count of > the LSP setup. > > If the hop count was not reset to 1 by the LSR at the egress > from the ATM cloud (instead, reflecting all of the hops in the > LSP downstream), the result would be to (possibly) decrement > the TTL of packets arriving at the ingress to the ATM cloud by > the number of hops in the entire LSP and then decrementing it > again at every non-ATM LSR hop. > > This could cause premature packet demise. > > -- > Eric Gray From owner-mpls@UU.NET Wed Feb 21 13:14:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04790 for ; Wed, 21 Feb 2001 13:14: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 QQkdjc07942; Wed, 21 Feb 2001 18:14:40 GMT Received: by mail-control.mail.uu.net id QQkdjc18386 for mpls-outgoing; Wed, 21 Feb 2001 18:14:06 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 QQkdjc18363 for ; Wed, 21 Feb 2001 18:13:54 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 QQkdjc16803 for ; Wed, 21 Feb 2001 18:12:17 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdjc03173 for ; Wed, 21 Feb 2001 18:12:17 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id 456B694009; Wed, 21 Feb 2001 13:11:07 -0500 (EST) Message-ID: <3A9403E0.AC0BEA27@sandburst.com> Date: Wed, 21 Feb 2001 13:07:28 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: djiang1@lucent.com Cc: "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: Re: Hop Count Procedures References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jane, See my reply to Prakash. Essentially, the issue is that it is not necessarily how many routers a packet goes through as how many you want (or have) to make it seem like the packet goes through. More is not always better. -- Eric Gray You wrote: > Hi Prahash, > > I believe the TTL in your case should be deducted by 12 instead of 4. 12 > is the number of routers the traffic has been through. There should be no > reason to deduct less that 12. It should not matter whether the traffic > was tunneled or not. > > Regards, > Jane D. Jiang > > "B, Prakash K (Prakash)" @UU.NET on 02/21/2001 > 01:15:28 AM > > Sent by: owner-mpls@UU.NET > > To: "'Eric Gray'" > cc: "'mpls@uu.net'" > Subject: RE: Hop Count Procedures > > Hello Eric, > Assume an LSP comprises LSRs Ra, Rb, Rc and Rd with Ra as the ingress and > Rd > as the eggress nodes and all of them are capable of TTL decrement. > There is a tunnel1 between Ra and Rb comprising LSRs R1, R2, R3 and R4. > Similarily, R5-R8 is the tunnel2 connecting Rc and Rd. > Rb and Rc are direct neighbours. R1 to R8 are ATM LSRs. > > >From the above configuration, it follows that Ra is the ingress to tunnel1 > whose eggress is Rb. Similarily Rc and Rd are the ingress and egress LSRs > of > tunnel2. > > If a packet enters this network, it encounters 12 nodes in all. > > Will the TTL of the packet emerging from Rd be (Original TTL - 12) or > should > it be simply(Original TTL - 4).?? > > TTL -4 will be the case if the tunnels are of Non TTL decrement type and > one > of the feature claimed here is the concept of tunnels being oblivious to > the > end user (possibly an IP cloud connected to Rd). > > Do the same rules apply when the tunnels are capable of TTL decrement?? > > Regards, > Prakash > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Tuesday, February 20, 2001 9:25 PM > To: B, Prakash K (Prakash) > Cc: 'mpls@uu.net' > Subject: Re: Hop Count Procedures > > "B, Prakash K (Prakash)" wrote: > > > ATM LSRS do not perform TTL decrement. RFC 3036 says that while > propogating > > the label mapping message upstream, if an LSR (Rd) finds out that its > > upstream LSR (Ru) is a part of domain that does not perform TTL > > decrement(ATM segment), it must reset the Hop Count value to 1. Will this > > not lead to erroneous computation of final TTL in the long run when the > > packet exits out of MPLS domain?Will not the true Hop count value assist > the > > ingress in determining in advance the TTL value that must be, when the > > packet emerges out of a Non -TTL-decrement segment? > > > > RFC 3031 clearly states that the final TTL value must reflect the true > > number of hops that a packet takes to exit a MPLS domain . > > Clarification solicited. > > > > Prakash K.B. > > Prakash, > > The intention is to allow the ATM ingress LSR to be able to > decrement the TTL by the value of the hop count in LSP setup > messages used to establish an LSP that will be used to forward > data. Note that the ATM ingress LSR does not have to do this, > but it could (if configured to do so, for instance, by the network > operator). > > In other words, when the ingress ATM LSR is about to put a > packet on a specific LSP, one of the things that it should get in > the FTN lookup is the decrement value for the packet's TTL. > The source of this value may be the hop count received in the > LSP setup messages. This will be the case if the operator > intends their ATM "tunnel" to be apparent to the end user. > > Once the packet arrives at the egress from the ATM cloud, > the next hop will decrement the TTL by some non-zero value > and this will happen for each of the non-ATM LSRs in the > remainder of the LSP - up to and including the hop count of > the LSP setup. > > If the hop count was not reset to 1 by the LSR at the egress > from the ATM cloud (instead, reflecting all of the hops in the > LSP downstream), the result would be to (possibly) decrement > the TTL of packets arriving at the ingress to the ATM cloud by > the number of hops in the entire LSP and then decrementing it > again at every non-ATM LSR hop. > > This could cause premature packet demise. > > -- > Eric Gray From owner-mpls@UU.NET Wed Feb 21 13:22:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05030 for ; Wed, 21 Feb 2001 13:22:02 -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 QQkdjd21515; Wed, 21 Feb 2001 18:21:57 GMT Received: by mail-control.mail.uu.net id QQkdjd19533 for mpls-outgoing; Wed, 21 Feb 2001 18:21: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 QQkdjd19523 for ; Wed, 21 Feb 2001 18:21: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 QQkdjd24745 for ; Wed, 21 Feb 2001 18:21:08 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkdjd21418 for ; Wed, 21 Feb 2001 18:21:08 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27561 for ; Wed, 21 Feb 2001 13:21:01 -0500 (EST) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27111 for ; Wed, 21 Feb 2001 13:20:55 -0500 (EST) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Feb 2001 13:20:52 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446C1C@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'mpls@UU.NET'" Cc: "Choudhury, Sanjaya" Subject: Questions related to Class-Type (in DiffServ-TE context) Date: Wed, 21 Feb 2001 13:20:50 -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 some basic questions regarding the Class-Types in the context for the DiffServ-TE. Your help will be appreciated. Questions regarding Definition of Class Types: ------------------------------------------------------- Q1. Who defines the Class-Types (0,1,2,3) ? Q2. If these Class-Types are administrator defined and is configured in all the LSR of the DiffServ-TE domain, why is the Class-Type signaled ? (Signaling messages already signals the PSC(s) being carried by the LSP, can't one determine the class-type from local configuration ?) Q3. The diff-te-reqts-00 draft states that "per Class TE" can be viewed as a special case of per Class-Type TE, where each Class-Type is degenerated into a single Diff-Serv class. In this cases, is the Class-Type information in the signaling messages redundant ? Questions regarding the Admission Control of L-LSP in DiffServ-TE environment. ------------------------------------------------------------------------- Q1. The mpls-diff-ext-07 draft, indicates that the signaled bandwidth can be used by the LSR to perform admission control of the signaled LSP over the DiffServ resources provisioned for the relevant PSC(s). The diff-te-ext-01 draft, states that if the CLASSTYPE object is not present in the Path message, the LSR must associate the Class-Type 0 to the LSP. This implies that one is expected to do admission control against the resource available for Class-Type 0. How can I read these two together ? Pre-emption and Class-Type -------------------------------------------------------------------------- Q1. Based on the diff-te-reqts-01, can I assume that the pre-emption should NOT work across the class-types (unlike the suggestion in the 00 version of the draft) ? Thanks for your help, sanjay From owner-mpls@UU.NET Wed Feb 21 17:01:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12034 for ; Wed, 21 Feb 2001 17:01: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 QQkdjs00046; Wed, 21 Feb 2001 22:01:22 GMT Received: by mail-control.mail.uu.net id QQkdjs29660 for mpls-outgoing; Wed, 21 Feb 2001 22:00: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 QQkdjs29487 for ; Wed, 21 Feb 2001 22:00: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 QQkdjs17949 for ; Wed, 21 Feb 2001 22:00:07 GMT Received: from EXCHANGE.kerenix.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.150.1.82]) id QQkdjr03034 for ; Wed, 21 Feb 2001 21:59:50 GMT Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id <1086CWC0>; Thu, 22 Feb 2001 00:00:41 +0200 Message-ID: <2B15221907365C468941FDFC02C87769CED7@EXCHANGE.kerenix.com> From: Vadim Suraev To: "'Choudhury, Sanjaya'" Cc: "'mpls@UU.NET'" Subject: RE: Questions related to Class-Type (in DiffServ-TE context) Date: Thu, 22 Feb 2001 00:00:38 +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 Sanjay, if I'm not mistaken: > Questions regarding Definition of Class Types: > ------------------------------------------------------- > Q1. Who defines the Class-Types (0,1,2,3) ? If you ask about which PHBs are associated with which Class Type - I think, this is task of network operator to define, which PHB is in which Class Type. I think, the signaling for PHB(s)<-->Class Types mapping is not defined, but there is - ability to signal which PHBs LSP carries (draft-ietf-mpls-diff-ext-08.txt); - ability to allocate BW for particular LSP from unreserved BW of certain Class Type (draft-ietf-mpls-diff-te-ext-01.txt). So, I think, operator have to define this in such way, that particular set of PHBs will share BW from BW pool (unreserved BW), associated with same Class Type and particular PHB will not allocate BW from more than one Class Type. > Q2. If these Class-Types are administrator defined and is configured > in all the LSR of the DiffServ-TE domain, why is the Class-Type > signaled ? > (Signaling messages already signals the PSC(s) being carried by > the LSP, can't one determine the class-type from local configuration?) I think, this allows you to avoid configuration of PHBs<-->Class Type mapping (and checking at LSP setup) at each LSR. > Q3. The diff-te-reqts-00 draft states that "per Class TE" can be > viewed as a special case of per Class-Type TE, where each Class-Type > is degenerated into a single Diff-Serv class. In this cases, is the > Class-Type information in the signaling messages redundant ? I think, it is not redundant because when you insert Class Type information into signaling message, you tell to each LSR on the path that you wish to allocate BW from BW pool of the Class Type. For example, you may associate EF with Class Type 1 and AFxx with Class Type 2. Then Class Type 1 includes only one DiffServ class (EF) and BW which should be allocated for LSP, which carries this class (EF), should be taken from BW pool (unreserved BW) of Class Type 1. Therefore, Class Type 1 should be signaled for LSP, which carries EF, in this case. Also, you may setup LSP for AF11 only rather than for AFxx. Since AF11 is subset of AFxx (it means here that AF11 may share BW with other AFs) and AFxx is associated logically with Class Type 2, you must to to signal the Class Type 2. > Questions regarding the Admission Control of L-LSP in DiffServ-TE > environment. > > ------------------------------------------------------------------------- > Q1. The mpls-diff-ext-07 draft, indicates that the signaled > bandwidth can be used by the LSR to perform admission control of the signaled LSP > over the DiffServ resources provisioned for the relevant PSC(s). > The diff-te-ext-01 draft, states that if the CLASSTYPE object is not > present in the Path message, the LSR must associate the Class-Type 0 > to the LSP. This implies that one is expected to do admission control > against the resource available for Class-Type 0. > How can I read these two together ? I think, mpls-diff-ext-08 means, that each LSR is provisioned initially (using SNMP, for example) with per-PSC (per Class Type) reservable BW (i.e. all link's reservable BW may be divided into per PSC (per Class Type) BW pools). So, if you do not include the CLASSTYPE object into the Path message, LSP is automatically associated with Class Type 0 and (if I'm not mistaken), LSP's signaled PSC (described in mpls-diff-ext-08) is expected to be associated (logically) with Class Type 0. Otherwise (if LSP's signaled PSC is associated logically with other Class Type), LSP will try to allocate BW from unreserved BW, intended to other PSC(s). > Pre-emption and Class-Type > > -------------------------------------------------------------------------- > Q1. Based on the diff-te-reqts-01, can I assume that the pre-emption > should NOT work across the class-types (unlike the suggestion in the > 00 version of the draft) ? Do you mean the preemption priority levels? If so, I think it remains (there is draft-ietf-ospf-diff-te-00.txt, describes unreserved BW advertisements for different preemption priority levels). From owner-mpls@UU.NET Wed Feb 21 19:02:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14484 for ; Wed, 21 Feb 2001 19:02: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 QQkdka24870; Thu, 22 Feb 2001 00:02:24 GMT Received: by mail-control.mail.uu.net id QQkdka11286 for mpls-outgoing; Thu, 22 Feb 2001 00:01: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 QQkdka11220 for ; Thu, 22 Feb 2001 00:01: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 QQkdka03948 for ; Thu, 22 Feb 2001 00:00:08 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdka10710 for ; Thu, 22 Feb 2001 00:00:07 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA21726 for mpls@uu.net; Wed, 21 Feb 2001 19:00:07 -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 QQkdjz07208 for ; Wed, 21 Feb 2001 23:59: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 QQkdjz29119 for ; Wed, 21 Feb 2001 23:58:31 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkdjz19224 for ; Wed, 21 Feb 2001 23:58:30 GMT Received: from lir.cisco.com (lir.cisco.com [161.44.172.144]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA03905 for ; Wed, 21 Feb 2001 18:58:29 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA28636 for ; Wed, 21 Feb 2001 15:53:04 -0500 (EST) Message-Id: <200102212053.PAA28636@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: MPLS scheduled time Date: Wed, 21 Feb 2001 15:53:04 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk For those of you making travel arrangements... According to the latest IETF agenda, MPLS is nos on Thursday PM. As far as I know that's for real. I've sent mail to verify, and will confirm to the list when I hear back. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Feb 21 19:54:52 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15222 for ; Wed, 21 Feb 2001 19:54: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 QQkdkd22745; Thu, 22 Feb 2001 00:54:52 GMT Received: by mail-control.mail.uu.net id QQkdkd26094 for mpls-outgoing; Thu, 22 Feb 2001 00:54:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdkd26089 for ; Thu, 22 Feb 2001 00:54:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdkd10258 for ; Thu, 22 Feb 2001 00:53:25 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdkd02365 for ; Thu, 22 Feb 2001 00:53:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA24908 for mpls@uu.net; Wed, 21 Feb 2001 19:53:20 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdkd26017 for ; Thu, 22 Feb 2001 00:52:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdkd08494 for ; Thu, 22 Feb 2001 00:52:37 GMT Received: from shell-beach.layer8.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQkdkd00526 for ; Thu, 22 Feb 2001 00:52:37 GMT Received: (qmail 50369 invoked by uid 1000); 22 Feb 2001 00:49:32 -0000 Date: Wed, 21 Feb 2001 16:49:32 -0800 From: Ben Black To: mpls@UU.NET Subject: MTU Signalling Extensions for LDP Message-ID: <20010221164932.B50026@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mpls@UU.NET Precedence: bulk I'd like to have this draft accepted as a working group document. The feedback has indicated little resistance to the idea or the details of the extension. http://www.ietf.org/internet-drafts/draft-black-ldp-mtu-extensions-00.txt Ben From owner-mpls@UU.NET Wed Feb 21 19:58:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15313 for ; Wed, 21 Feb 2001 19:58: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 QQkdkd27871; Thu, 22 Feb 2001 00:58:25 GMT Received: by mail-control.mail.uu.net id QQkdkd26413 for mpls-outgoing; Thu, 22 Feb 2001 00:57:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdkd26399 for ; Thu, 22 Feb 2001 00:57:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdkd19502 for ; Thu, 22 Feb 2001 00:57:32 GMT Received: from smtp.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQkdkd07565 for ; Thu, 22 Feb 2001 00:57:27 GMT Received: from z97716 ([10.110.10.147]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G94VTZ02.X07 for ; Thu, 22 Feb 2001 08:53:59 +0800 Message-ID: <006201c09c6a$7fa414e0$930a6e0a@huawei.com> From: "Heqing Zhu" To: Subject: Label Request Event Date: Thu, 22 Feb 2001 08:57:57 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C09CAD.8D271D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C09CAD.8D271D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksSSBoYXZlIG9uZSBiYXNpYyBxdWVzdGlvbiByZWdhcmRpbmcgInJlY2VpdmUgbGFiZWwgcmVx dWVzdCIgaW4gUkZDMzAzNi4NClRoZXJlIGlzIGFuIGFsZ29yaXRobSBpbiBwYWdlIDk2LiBJdCBk ZXNjcmliZSBsaWtlIHRoaXM6DQoNCiJMUnEuMiAgICAgSXMgdGhlcmUgYSBOZXh0IEhvcCBmb3Ig RkVDPw0KICAgICAgICAgICAgICAgICAgSWYgbm90ICxnb3RvIExScS41Lg0KICAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4NCiBMUnEuNSAgICBFeGVjdXRlIHByb2NlZHVyZSBTZW5kX05vdGlm aWNhdGlvbihNc2dTb3VyY2UsTm8gUm91dGUpLiIgIA0KDQpJIHRoaW5rIG1heWJlIHRoZSBGRUMg aGFzIGJlZW4gdG8gdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MsDQpXaHkgbm90IGNoZWNrIHRoaXMg Pw0KDQpUaGFua3MgZm9yIHlvdXIgaGVscA0KDQpIZXFpbmcgWmh1DQogICAgICAgICAgIA0KDQo= ------=_NextPart_000_005F_01C09CAD.8D271D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjYxNC4zNTAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGksSSBoYXZlIG9u ZSBiYXNpYyBxdWVzdGlvbiByZWdhcmRpbmcgInJlY2VpdmUgbGFiZWwgcmVxdWVzdCIgDQppbiBS RkMzMDM2LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoZXJlIGlzIGFuIGFsZ29y aXRobSBpbiBwYWdlIDk2LiBJdCBkZXNjcmliZSBsaWtlIA0KdGhpczo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4i TFJxLjImbmJzcDsmbmJzcDsmbmJzcDsgIElzIHRoZXJlIGEgTmV4dCBIb3AgZm9yIA0KRkVDPzwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7IElmIG5vdCAsZ290byBMUnEuNS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj4mbmJzcDsmbmJzcDsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4mbmJzcDtMUnEuNSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0V4ZWN1 dGUgcHJvY2VkdXJlIA0KU2VuZF9Ob3RpZmljYXRpb24oTXNnU291cmNlLE5vIFJvdXRlKS4iJm5i c3A7Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSB0aGluayZuYnNwO21heWJlIHRoZSBGRUMgaGFzIGJl ZW4gdG8mbmJzcDt0aGUgZGVzdGluYXRpb24gDQphZGRyZXNzLDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPldoeSBub3QgY2hlY2sgdGhpcyA/PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzIGZv ciB5b3VyIGhlbHA8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+SGVxaW5nIFpodTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_005F_01C09CAD.8D271D40-- From owner-mpls@UU.NET Thu Feb 22 00:09:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20629 for ; Thu, 22 Feb 2001 00:09: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 QQkdku16564; Thu, 22 Feb 2001 05:09:49 GMT Received: by mail-control.mail.uu.net id QQkdku27066 for mpls-outgoing; Thu, 22 Feb 2001 05:09:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdku27059 for ; Thu, 22 Feb 2001 05:09:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdku02623 for ; Thu, 22 Feb 2001 05:08:13 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkdku15702 for ; Thu, 22 Feb 2001 05:08:11 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id LAA18498 for ; Thu, 22 Feb 2001 11:03:31 +0530 Received: from JAIKUMARPC ([192.168.232.131]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FBRAXX6Q; Thu, 22 Feb 2001 10:37:43 +0530 From: "Vijayanand Chandrasekar" To: Subject: Owner of LSP? Date: Thu, 22 Feb 2001 10:41:57 +0530 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 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This question has already been asked but no reply has been received. Can anyone reply to this or give a pointer to the mail archive if this has alredy been discussed. The LDP mib draft says: The mplsLdpSessionXCMapTable provides a way to map LDP LSPs in the LSR MIB's mplsXCTable to the LDP session which created them in this MIB's mplsLdpSessionTable. DESCRIPTION "A table of Session's Labels which are Mapped to the LSR MIB 's XConnect table. Each row represents a single cross connect." Since a cross-connect involves two LDP sessions, how can we interpret the session which created the LSP. Does it depend on the label distribution mode used? Regards, Vijay From owner-mpls@UU.NET Thu Feb 22 00:44:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21323 for ; Thu, 22 Feb 2001 00:44: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 QQkdkw01889; Thu, 22 Feb 2001 05:44:41 GMT Received: by mail-control.mail.uu.net id QQkdkw28714 for mpls-outgoing; Thu, 22 Feb 2001 05:44:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdkw28709 for ; Thu, 22 Feb 2001 05:44:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdkw05624 for ; Thu, 22 Feb 2001 05:42:07 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQkdkw28939 for ; Thu, 22 Feb 2001 05:42:07 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 AAA07163 for ; Thu, 22 Feb 2001 00:42:07 -0500 (EST) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA07132 for ; Thu, 22 Feb 2001 00:42:04 -0500 (EST) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <1GKM34SJ>; Thu, 22 Feb 2001 11:11:54 +0530 Message-ID: From: "B, Prakash K (Prakash)" To: "'Eric Gray'" Cc: "'mpls@uu.net'" Subject: RE: Hop Count Procedures Date: Thu, 22 Feb 2001 11:11:46 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric, Another question on Hop count. If we continue to disregard tunnels as links, the number of hierarchial levels in a given AS or a domain must not influence the final TTL value. Is there something Iam overlooking? Regards, Prakash. -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Wednesday, February 21, 2001 10:01 PM To: B, Prakash K (Prakash) Cc: 'mpls@uu.net' Subject: Re: Hop Count Procedures Prakash, The reason for decrementing TTL is to prevent packets from endlessly looping. Hence technologies which do not support decrementing TTL need to provide another means for loop prevention or mitigation. If a technology provides - for example - a mechanism to prevent loop formation in LSPs, then the network may gain very little from having accelerated aging. In fact, the prevalence of accelerated aging tends to lead to higher initial TTL values in the network off-setting at least some of the benefits expected in networks which use TTL exclusively. So there are two questions the network operator has to ask themselves: 1) do they want to treat the tunnel as a link? and 2) can they do this without harming the network? In some cases, not treating a tunnel as a link can harm the network. For example, in the not too distant past, initial TTL values were set fairly low in some operating systems. During that time, all it took was for a service provider to insert one more router in the transit network and suddenly numerous network destinations were no longer reachable. In an ideal world, there should not be a detrimental impact on the service being provided as a result of deliberate changes in the network infrastructure. The networking community's response to this was to increase the default TTL in their operating systems by as much as a factor of 8 - thus increasing the impact of looping traffic (originating from these hosts) on the network by a factor of between 2 and 4. However, it is not safe to treat a tunnel as a link if it can be arbitrarily long (for example - as a result of the fact that it can have transient looping). It may also be unsafe to treat a tunnel as a link if its egress can change without detection at the ingress - however this can happen in an L2 network with a real L3 link, so it is not really clear just how unsafe this is. I would think it is much less safe in a network where this can happen fairly often. So, I would say that you cannot compare the use of TTL in tunneling across a network technology that does not support decrementing TTL with the use of TTL in other network technologies. -- Eric Gray You wrote: > Hello Eric, > Assume an LSP comprises LSRs Ra, Rb, Rc and Rd with Ra as the ingress and Rd > as the eggress nodes and all of them are capable of TTL decrement. > There is a tunnel1 between Ra and Rb comprising LSRs R1, R2, R3 and R4. > Similarily, R5-R8 is the tunnel2 connecting Rc and Rd. > Rb and Rc are direct neighbours. R1 to R8 are ATM LSRs. > > >From the above configuration, it follows that Ra is the ingress to tunnel1 > whose eggress is Rb. Similarily Rc and Rd are the ingress and egress LSRs of > tunnel2. > > If a packet enters this network, it encounters 12 nodes in all. > > Will the TTL of the packet emerging from Rd be (Original TTL - 12) or should > it be simply(Original TTL - 4).?? > > TTL -4 will be the case if the tunnels are of Non TTL decrement type and one > of the feature claimed here is the concept of tunnels being oblivious to the > end user (possibly an IP cloud connected to Rd). > > Do the same rules apply when the tunnels are capable of TTL decrement?? > > Regards, > Prakash > From owner-mpls@UU.NET Thu Feb 22 00:50:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21338 for ; Thu, 22 Feb 2001 00:50: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 QQkdkx10332; Thu, 22 Feb 2001 05:50:53 GMT Received: by mail-control.mail.uu.net id QQkdkx29286 for mpls-outgoing; Thu, 22 Feb 2001 05:50: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 QQkdkx29277 for ; Thu, 22 Feb 2001 05:50: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 QQkdkx09682 for ; Thu, 22 Feb 2001 05:49:19 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQkdkx17214 for ; Thu, 22 Feb 2001 05:49:19 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 AAA11015 for ; Thu, 22 Feb 2001 00:49:18 -0500 (EST) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA11008 for ; Thu, 22 Feb 2001 00:49:16 -0500 (EST) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <1GKM34WG>; Thu, 22 Feb 2001 11:19:12 +0530 Message-ID: From: "B, Prakash K (Prakash)" To: "'seenu@samsung.co.kr'" Cc: "'mpls@uu.net'" Subject: RE: (Reply) Hello parameters TLV Date: Thu, 22 Feb 2001 11:19:02 +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 Seenu, An ATM LSR will require pure ATM switching(on a Non MPLS)link with LLC-SNAP encapsulation to forward the LDP messages to peers provided there is this Ship in the Night Mode supported. -Prakash -----Original Message----- From: seenu@samsung.co.kr [mailto:seenu@samsung.co.kr] Sent: Wednesday, February 21, 2001 4:42 PM To: prakashk@lucent.com Subject: (Reply) Hello parameters TLV Hi Prakash, To be an LSR, it should a switch and a router....I mean it should support atleast one routing protocol, without which LDP won't work. At the same time it needs ATM for switching. Hence the optional IPv4/6 transport will be that of a sender (since it is a outer, it will have IP address ) If I am wrong, plz correct me. Regards Seenu Samsung Electronics India Software operations Prestige Meridian-2 M.G. Road, Bangalore From owner-mpls@UU.NET Thu Feb 22 03:18:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05966 for ; Thu, 22 Feb 2001 03:18: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 QQkdlh28566; Thu, 22 Feb 2001 08:18:00 GMT Received: by mail-control.mail.uu.net id QQkdlh20770 for mpls-outgoing; Thu, 22 Feb 2001 08:17:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdlh20765 for ; Thu, 22 Feb 2001 08:17:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdlh00644 for ; Thu, 22 Feb 2001 08:17:04 GMT Received: from wiprom2mx2.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQkdlh06720 for ; Thu, 22 Feb 2001 08:16:57 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id OAA27123 for ; Thu, 22 Feb 2001 14:24:28 +0530 Received: from Vinayhv ([192.168.220.177]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA930 for ; Thu, 22 Feb 2001 13:42:42 +0530 Message-ID: <00ab01c09ca6$f31ad4e0$b1dca8c0@alc.wipinfo.soft.net> From: "Vinay Vernekar" To: "'mpls@uu.net'" Subject: LSP control mode of peer... Date: Thu, 22 Feb 2001 13:40:37 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01C09CD5.09E8E940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01C09CD5.09E8E940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have a query which came up when implementing the LDP as in rfc3036 - = "LDP Specification", keeping in mind the MPLS architecture as given be = rfc3031. As discussed in rfc3031 - 5.2.1. Schemes for LSRs that Support Label = Merging - If Ru and Rd are label distribution peers, and both support labelmerging = one of the supported scheme is - 3. This implies that the label retention mode of the upstream can be = conservative given that the downstream is operating in Unsolicited label = distribution mode and its LSP control mode is Ordered. But how can the = LSP control mode of the peer be determined? This is not available in any = of the LDP messages/TLVs. Thanks & Regards Vinay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That's why it's called the Present!! *************************************************************************= **** Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. *************************************************************************= **** ------=_NextPart_000_00A8_01C09CD5.09E8E940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
I have a query which came up when = implementing the=20 LDP as in rfc3036 - "LDP Specification", keeping in mind = the MPLS=20 architecture as given be rfc3031.
As discussed in rfc3031 - 5.2.1.=20 Schemes for LSRs that Support Label Merging -
If Ru and Rd are label = distribution peers,=20 and both support labelmerging one of the supported scheme is=20 -
 
3. = <PushConditional,=20 RequestWhenNeeded, RequestNoRetry,ReleaseOnChange,=20 *>
This implies that = the label=20 retention mode of the upstream can be conservative given that the = downstream is=20 operating in Unsolicited label distribution mode and its LSP control = mode is=20 Ordered. But how can the LSP control mode of the peer be determined? = This is not=20 available in any of the LDP messages/TLVs.
 
Thanks &=20 Regards
Vinay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday = is history.=20 Tomorrow is mystery.
Today is a gift. That’s why it’s = called the=20 Present!!
************************************************************= *****************
Vinay=20 H. Vernekar
Sr. Software Engineer - Global R&D Solutions
Wipro = Technologies
No.26, Hosur Main Road, Bommanahalli,
Bangalore-560 = 068,=20 India.
***************************************************************= **************
------=_NextPart_000_00A8_01C09CD5.09E8E940-- From owner-mpls@UU.NET Thu Feb 22 03:32:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06109 for ; Thu, 22 Feb 2001 03:32: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 QQkdli09734; Thu, 22 Feb 2001 08:32:07 GMT Received: by mail-control.mail.uu.net id QQkdli21279 for mpls-outgoing; Thu, 22 Feb 2001 08:31:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdli21273 for ; Thu, 22 Feb 2001 08:31:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdli03755 for ; Thu, 22 Feb 2001 08:31:15 GMT Received: from wiprom2mx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQkdli03478 for ; Thu, 22 Feb 2001 08:31:13 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id OAA29664 for ; Thu, 22 Feb 2001 14:38:49 +0530 Received: from Vinayhv ([192.168.220.177]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA165E for ; Thu, 22 Feb 2001 13:53:39 +0530 Message-ID: <00ca01c09ca8$7a6bd560$b1dca8c0@alc.wipinfo.soft.net> From: "Vinay Vernekar" To: "'mpls@uu.net'" Subject: Multiple label spaces per link?? Date: Thu, 22 Feb 2001 13:51:38 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C7_01C09CD6.93C883E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C7_01C09CD6.93C883E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I have a question on the following from rfc3036 "LDP Specification". Under 2.5.3. Session Initialization page 15, para 4 it is given that - "In general when there are multiple links between LSR1 and LSR2 and = multiple label spaces to be advertised by each...." Does this mean that each link will advertise multiple spaces. In other = words is it possible for a single link to advertise more than one label = space?? Regards Vinay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That's why it's called the Present!! *************************************************************************= **** Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. Tel: 91-80-5722293/5722296 Extn. 4019 Fax: 91-80-5722696 Email: vinay.vernekar@wipro.com The World's First SEI CMM Level 5 Software Services Company *************************************************************************= **** ------=_NextPart_000_00C7_01C09CD6.93C883E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
I have a question on the following = from rfc3036 "LDP=20 Specification".
Under 2.5.3. Session = Initialization page 15,=20 para 4 it is given that -
"In general when there are multiple links = between LSR1 and=20 LSR2 and multiple label spaces to be advertised by = each...."
Does this mean that each link will advertise = multiple=20 spaces. In other words is it possible for a single link to advertise = more than=20 one label space??
 
Regards
Vinay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday = is history.=20 Tomorrow is mystery.
Today is a gift. That’s why it’s = called the=20 Present!!
************************************************************= *****************
Vinay=20 H. Vernekar
Sr. Software Engineer - Global R&D Solutions
Wipro = Technologies
No.26, Hosur Main Road, Bommanahalli,
Bangalore-560 = 068,=20 India.
Tel: 91-80-5722293/5722296 Extn. 4019
Fax: = 91-80-5722696
Email:=20 vinay.vernekar@wipro.com
= The=20 World's First SEI CMM Level 5 Software Services=20 Company
**************************************************************= ***************
------=_NextPart_000_00C7_01C09CD6.93C883E0-- From owner-mpls@UU.NET Thu Feb 22 03:39:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06168 for ; Thu, 22 Feb 2001 03:39: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 QQkdli23272; Thu, 22 Feb 2001 08:39:12 GMT Received: by mail-control.mail.uu.net id QQkdli21645 for mpls-outgoing; Thu, 22 Feb 2001 08:38:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdli21633 for ; Thu, 22 Feb 2001 08:38:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdli19905 for ; Thu, 22 Feb 2001 08:38:13 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkdli24746 for ; Thu, 22 Feb 2001 08:38:12 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA11247 for ; Thu, 22 Feb 2001 03:38:11 -0500 (EST) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA11228 for ; Thu, 22 Feb 2001 03:38:09 -0500 (EST) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <1GKM3W9Y>; Thu, 22 Feb 2001 14:08:05 +0530 Message-ID: From: "B, Prakash K (Prakash)" To: "'Vijayanand Chandrasekar'" Cc: "'mpls@uu.net'" Subject: RE: (Reply) Hello parameters TLV Date: Thu, 22 Feb 2001 14:08:04 +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 Very True. Switching of labelled packets as well as signalling messages(OSPF,LDP, RSVP etc) has to be ATM based. Its only that fewer resources (fewer VPI/VCI) are set aside for signalling, hence the necessity for LLC/SNAP encapsulation is acute. In either case as you say, L2 is ATM. -Prakash. -----Original Message----- From: Vijayanand Chandrasekar [mailto:vijayc@hclt.com] Sent: Thursday, February 22, 2001 11:38 AM To: B, Prakash K (Prakash) Cc: seenu@samsung.co.kr Subject: RE: (Reply) Hello parameters TLV Prakash, If we have an LC-ATM interface then we will associate an IP address with that, ATM is the link-layer for IP in this case. Regards, Vijay From owner-mpls@UU.NET Thu Feb 22 04:07:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06336 for ; Thu, 22 Feb 2001 04:07: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 QQkdlk19242; Thu, 22 Feb 2001 09:07:15 GMT Received: by mail-control.mail.uu.net id QQkdlk07621 for mpls-outgoing; Thu, 22 Feb 2001 09:06:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdlk07616 for ; Thu, 22 Feb 2001 09:06:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdlk25082 for ; Thu, 22 Feb 2001 09:06:15 GMT Received: from localhost.ipunplugged.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQkdlk17835 for ; Thu, 22 Feb 2001 09:06:15 GMT Received: from hanssjostrand (c30.local.ipunplugged.com [192.168.4.229]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA32174; Thu, 22 Feb 2001 10:05:22 +0100 From: =?iso-8859-1?Q?Hans_Sj=F6strand?= To: "Vijayanand Chandrasekar" Cc: "IETF MPLS list" Subject: RE: Owner of LSP? Date: Thu, 22 Feb 2001 10:04:55 +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.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sorry for not answering timely, The mplsLdpSessionXCMapTable is used to identify which LSP XCs belongs to a given session, not the other way around. So, both sessions involved in the setup of the LSP should be represented in the table. So for a given LSP XC there will be two entries in the table with incoming_session.incoming_interface_and_label.outgoing_interface_and_label and outgoing_session.incoming_interface_and_label.outgoing_interface_and_label The table is sorted on session, so it's very easy for a manager to list all LSP XCs concerned with given session, it's just to get_next it's way through the table with the desired session id until it hits a new session id. Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Vijayanand Chandrasekar > Sent: den 22 februari 2001 06:12 > To: mpls@UU.NET > Subject: Owner of LSP? > > > This question has already been asked but no reply has been received. Can > anyone reply to this or give a pointer to the mail archive if this has > alredy been discussed. > > The LDP mib draft says: > > The mplsLdpSessionXCMapTable provides a way to map LDP LSPs in the > LSR MIB's mplsXCTable to the LDP session which created them in this > MIB's mplsLdpSessionTable. > > DESCRIPTION > "A table of Session's Labels which > are Mapped to the LSR MIB 's XConnect table. > Each row represents a single cross connect." > > Since a cross-connect involves two LDP sessions, how can we interpret the > session which created the LSP. Does it depend on the label > distribution mode > used? > > Regards, > Vijay From owner-mpls@UU.NET Thu Feb 22 04:08:06 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06348 for ; Thu, 22 Feb 2001 04:08: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 QQkdlk12550; Thu, 22 Feb 2001 09:08:05 GMT Received: by mail-control.mail.uu.net id QQkdlk07694 for mpls-outgoing; Thu, 22 Feb 2001 09:07: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 QQkdlk07661 for ; Thu, 22 Feb 2001 09:07: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 QQkdlk10986 for ; Thu, 22 Feb 2001 09:06:24 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkdlk17953 for ; Thu, 22 Feb 2001 09:06:20 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id OAA28485; Thu, 22 Feb 2001 14:59:44 +0530 Received: from JAIKUMARPC ([192.168.232.131]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FBRAXZGN; Thu, 22 Feb 2001 14:33:56 +0530 From: "Vijayanand Chandrasekar" To: "Vinay Vernekar" Cc: "Balasubramanian Mandakolathur B" , Subject: RE: Multiple label spaces per link?? Date: Thu, 22 Feb 2001 14:38:11 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C09CDD.14AA6270" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <00ca01c09ca8$7a6bd560$b1dca8c0@alc.wipinfo.soft.net> Importance: Normal 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_000A_01C09CDD.14AA6270 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkdlk12550 Content-Transfer-Encoding: quoted-printable Vinay, Yes. A single link can advertise more than one label space. This will hap= pen in multicasting and in the case of diffserv/QoS when we create L-LSPs. Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vinay Vernekar Sent: Thursday, February 22, 2001 1:52 PM To: 'mpls@uu.net' Subject: Multiple label spaces per link?? Hello, I have a question on the following from rfc3036 "LDP Specification". Under 2.5.3. Session Initialization page 15, para 4 it is given that - "In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each...." Does this mean that each link will advertise multiple spaces. In other words is it possible for a single link to advertise more than one label space?? Regards Vinay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That=92s why it=92s called the Present!! *************************************************************************= *** * Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. Tel: 91-80-5722293/5722296 Extn. 4019 Fax: 91-80-5722696 Email: vinay.vernekar@wipro.com The World's First SEI CMM Level 5 Software Services Company *************************************************************************= *** * ------=_NextPart_000_000A_01C09CDD.14AA6270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Vinay,
Yes. A=20 single link can advertise more than one label space. This will happen in = multicasting and in the case of diffserv/QoS when we create=20 L-LSPs.
 
 
Regards,
Vijay
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Vinay = Vernekar
Sent:=20 Thursday, February 22, 2001 1:52 PM
To:=20 'mpls@uu.net'
Subject: Multiple label spaces per=20 link??

Hello,
I have a question on the following = from rfc3036=20 "LDP Specification".
Under 2.5.3. Session = Initialization page=20 15, para 4 it is given that -
"In general when there are multiple links = between LSR1=20 and LSR2 and multiple label spaces to be advertised by = each...."
Does this mean that each link will advertise = multiple=20 spaces. In other words is it possible for a single link to advertise = more than=20 one label space??
 
Regards
Vinay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday = is=20 history. Tomorrow is mystery.
Today is a gift. That’s why = it’s called the=20 = Present!!
************************************************************= *****************
Vinay=20 H. Vernekar
Sr. Software Engineer - Global R&D = Solutions
Wipro=20 Technologies
No.26, Hosur Main Road, Bommanahalli,
Bangalore-560 = 068,=20 India.
Tel: 91-80-5722293/5722296 Extn. 4019
Fax:=20 91-80-5722696
Email: vinay.vernekar@wipro.com
= The=20 World's First SEI CMM Level 5 Software Services=20 = Company
**************************************************************= ***************
------=_NextPart_000_000A_01C09CDD.14AA6270-- From owner-mpls@UU.NET Thu Feb 22 04:15:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06386 for ; Thu, 22 Feb 2001 04:15: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 QQkdll18638; Thu, 22 Feb 2001 09:15:46 GMT Received: by mail-control.mail.uu.net id QQkdll08607 for mpls-outgoing; Thu, 22 Feb 2001 09:15:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdll08600 for ; Thu, 22 Feb 2001 09:15:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdlk16875 for ; Thu, 22 Feb 2001 09:13:53 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkdlk28113 for ; Thu, 22 Feb 2001 09:13:51 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id PAA28830; Thu, 22 Feb 2001 15:09:03 +0530 Received: from JAIKUMARPC ([192.168.232.131]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FBRAXZHQ; Thu, 22 Feb 2001 14:43:16 +0530 From: "Vijayanand Chandrasekar" To: "Vinay Vernekar" Cc: Subject: RE: LSP control mode of peer... Date: Thu, 22 Feb 2001 14:47:30 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C09CDE.621749A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <00ab01c09ca6$f31ad4e0$b1dca8c0@alc.wipinfo.soft.net> Importance: Normal 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_000E_01C09CDE.621749A0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkdll18638 Content-Transfer-Encoding: quoted-printable Vinay, I don't think you need to know whether your downstream is Ordered or Independent. You need to just know if it is Ondemand or Unsolicited. Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vinay Vernekar Sent: Thursday, February 22, 2001 1:41 PM To: 'mpls@uu.net' Subject: LSP control mode of peer... Hello, I have a query which came up when implementing the LDP as in rfc3036 - "LDP Specification", keeping in mind the MPLS architecture as given be rfc3031. As discussed in rfc3031 - 5.2.1. Schemes for LSRs that Support Label Merging - If Ru and Rd are label distribution peers, and both support labelmergin= g one of the supported scheme is - 3. This implies that the label retention mode of the upstream can be conservative given that the downstream is operating in Unsolicited label distribution mode and its LSP control mode is Ordered. But how can the LS= P control mode of the peer be determined? This is not available in any of t= he LDP messages/TLVs. Thanks & Regards Vinay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That=92s why it=92s called the Present!! *************************************************************************= *** * Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. *************************************************************************= *** * ------=_NextPart_000_000E_01C09CDE.621749A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Vinay,
I=20 don't think you need to know whether your downstream is Ordered or = Independent.=20 You need to just know if it is Ondemand or Unsolicited. =
 
Regards,
Vijay
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Vinay = Vernekar
Sent:=20 Thursday, February 22, 2001 1:41 PM
To:=20 'mpls@uu.net'
Subject: LSP control mode of=20 peer...

Hello,
I have a query which came up when = implementing=20 the LDP as in rfc3036 - "LDP Specification", keeping in = mind the=20 MPLS architecture as given be rfc3031.
As discussed in rfc3031 - 5.2.1.=20 Schemes for LSRs that Support Label Merging -
If Ru and Rd are label = distribution peers,=20 and both support labelmerging one of the supported scheme is=20 -
 
3. = <PushConditional,=20 RequestWhenNeeded, RequestNoRetry,ReleaseOnChange,=20 *>
This implies = that the label=20 retention mode of the upstream can be conservative given that the = downstream=20 is operating in Unsolicited label distribution mode and its LSP = control mode=20 is Ordered. But how can the LSP control mode of the peer be = determined? This=20 is not available in any of the LDP = messages/TLVs.
 
Thanks &=20 Regards
Vinay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday = is=20 history. Tomorrow is mystery.
Today is a gift. That’s why = it’s called the=20 = Present!!
************************************************************= *****************
Vinay=20 H. Vernekar
Sr. Software Engineer - Global R&D = Solutions
Wipro=20 Technologies
No.26, Hosur Main Road, Bommanahalli,
Bangalore-560 = 068,=20 = India.
***************************************************************= **************
------=_NextPart_000_000E_01C09CDE.621749A0-- From owner-mpls@UU.NET Thu Feb 22 07:04:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07876 for ; Thu, 22 Feb 2001 07:04:57 -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 QQkdlw24468; Thu, 22 Feb 2001 12:04:55 GMT Received: by mail-control.mail.uu.net id QQkdlw26664 for mpls-outgoing; Thu, 22 Feb 2001 12:04:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdlw25225 for ; Thu, 22 Feb 2001 12:04:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdlw07148 for ; Thu, 22 Feb 2001 12:02:54 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdlw18673 for ; Thu, 22 Feb 2001 12:02:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA28850 for mpls@uu.net; Thu, 22 Feb 2001 07:02:53 -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 QQkdlw23288 for ; Thu, 22 Feb 2001 12:02: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 QQkdlw23493 for ; Thu, 22 Feb 2001 12:01: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 QQkdlw17490 for ; Thu, 22 Feb 2001 12:01:53 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA04637; Thu, 22 Feb 2001 04:02:11 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id HAA11118; Thu, 22 Feb 2001 07:01:51 -0500 (EST) Message-Id: <200102221201.HAA11118@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Vinay Vernekar" cc: mpls@UU.NET Subject: Re: Multiple label spaces per link?? In-reply-to: Your message of "Thu, 22 Feb 2001 14:38:11 +0530." Date: Thu, 22 Feb 2001 07:01:51 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Vinay, > I have a question on the following from rfc3036 "LDP Specification". > Under 2.5.3. Session Initialization page 15, para 4 it is given that - > "In general when there are multiple links between LSR1 and LSR2 and > ltiple label spaces to be advertised by each...." > Does this mean that each link will advertise multiple spaces. In other > words is it possible for a single link to advertise more than one label > space?? The sentance in question was written assuming that LSRs, not links, advertise label spaces, and could be rewritten as follows without changing its intended meaning: In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each LSR, ... Bob From owner-mpls@UU.NET Thu Feb 22 07:53:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09330 for ; Thu, 22 Feb 2001 07:53: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 QQkdlz11429; Thu, 22 Feb 2001 12:53:17 GMT Received: by mail-control.mail.uu.net id QQkdlz03164 for mpls-outgoing; Thu, 22 Feb 2001 12:52:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdlz03159 for ; Thu, 22 Feb 2001 12:52:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdlz28540 for ; Thu, 22 Feb 2001 12:52:42 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdlz22352 for ; Thu, 22 Feb 2001 12:52:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA01328 for mpls@uu.net; Thu, 22 Feb 2001 07:52:40 -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 QQkdlz03144 for ; Thu, 22 Feb 2001 12:52: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 QQkdlz19325 for ; Thu, 22 Feb 2001 12:50:13 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.26.42]) id QQkdlz19187 for ; Thu, 22 Feb 2001 12:50:12 GMT Received: from cisco.com ([64.104.42.208]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id EAA08132; Thu, 22 Feb 2001 04:49:20 -0800 (PST) Message-ID: <3A94FC9A.4D90B0B5@cisco.com> Date: Thu, 22 Feb 2001 03:48:42 -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: LOPEZ Miguel Angel CC: "'mpls@uu.net'" Subject: Re: Aggregate label References: <96CD4BAC2E4A6A408056FE8E6C6AF2E7048C92@hermes.ar.logical.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure if you got yr answer yet but are you asking about cisco aggregate label definition and it's functions in the mpls-vpns ? R. > LOPEZ Miguel Angel wrote: > > Hi, > Please, could somebody explain what means an aggregate label > and how it works? > TIA From owner-mpls@UU.NET Thu Feb 22 10:10:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13417 for ; Thu, 22 Feb 2001 10:10: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 QQkdmd03141; Thu, 22 Feb 2001 13:51:04 GMT Received: by mail-control.mail.uu.net id QQkdmd07773 for mpls-outgoing; Thu, 22 Feb 2001 13:50: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 QQkdmd07754 for ; Thu, 22 Feb 2001 13:50: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 QQkdmd20950 for ; Thu, 22 Feb 2001 13:49:55 GMT Received: from wiprom2mx2.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQkdmd08656 for ; Thu, 22 Feb 2001 13:49:53 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id TAA17872 for ; Thu, 22 Feb 2001 19:58:18 +0530 Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA2C80; Thu, 22 Feb 2001 19:16:36 +0530 Message-ID: <3A9519E5.15378941@wipro.com> Date: Thu, 22 Feb 2001 19:23:42 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijayanand Chandrasekar , mpls@UU.NET CC: Bob Thomas Subject: Re: LSP control mode of peer... References: Content-Type: multipart/alternative; boundary="------------4BB01107DC24263805EFD13B" Sender: owner-mpls@UU.NET Precedence: bulk --------------4BB01107DC24263805EFD13B Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkdmd03141 Content-Transfer-Encoding: quoted-printable Hi vijay, Given a combination of upstream LSR (Ru) and downstream LSR (Rd) - Distribution procedure is Downstream's distribution procedure & Request procedure is upstreams. Hence in the combination below, Distribution procedure represents donwstream ' distribution procedure and Request Procedure is Upstream. Am I wrong ? The above conclution is made from the mpls architechture draft (or RFC) 5.1.1 Downstream LSR: Distribution Procedure 5.1.2 Upstream LSR: Request Procedure Regards Amar Vijayanand Chandrasekar wrote: > Amar,This information is needed for configuring the LSRs' on what > schemes WE support. For example PushConditional means Unsolicited > Ordered control is used by us when we distribute labels as a > downstream.It is not what is used ny our downstream.Your question is > why you are not allowed to use - (PushUnCond)UnsolicitedIndependent > with (RWN)Conservative .Unsolicited Independent and Conservative are > not used in combination,You can look at the mail archives for this.The > question should not be not whether ur downstream is ordered or > independent? Vijay > > -----Original Message----- > From: Amarnath Honnavalli Anantharamaiah > [mailto:amarnath.honnavalli@wipro.com] > Sent: Thursday, February 22, 2001 5:39 PM > To: Vijayanand Chandrasekar > Cc: Bob Thomas > Subject: Re: LSP control mode of peer... > > Vijay, > > [1] No, basically question was, From the list of valid > schemes supported for merge capable LSR, we don't find > this combination. > RequestNoRetry,ReleaseOnChange, *> > however we can find the following combination > RequestNoRetry,ReleaseOnChange, *> > > Now, how do we know if downstream is PushConditional or > PushUnconditional ??? > > [2] If this is not needed to know, Why is this combination > given in the list ? > > Regards > Amar > > Vijayanand Chandrasekar wrote: > > > Vinay,I don't think you need to know whether your > > downstream is Ordered or Independent. You need to just > > know if it is Ondemand or Unsolicited. Regards,Vijay > > > > -----Original Message----- > > From: owner-mpls@UU.NET > > [mailto:owner-mpls@UU.NET]On Behalf Of Vinay > > Vernekar > > Sent: Thursday, February 22, 2001 1:41 PM > > To: 'mpls@uu.net' > > Subject: LSP control mode of peer... > > Hello,I have a query which came up when > > implementing the LDP as in rfc3036 - "LDP > > Specification", keeping in mind the MPLS > > architecture as given be rfc3031.As discussed in > > rfc3031 - 5.2.1. Schemes for LSRs that Support > > Label Merging -If Ru and Rd are label > > distribution peers, and both support > > labelmerging one of the supported scheme is - 3. > > > RequestNoRetry,ReleaseOnChange, *>This implies > > that the label retention mode of the upstream > > can be conservative given that the downstream is > > operating in Unsolicited label distribution mode > > and its LSP control mode is Ordered. But how can > > the LSP control mode of the peer be determined? > > This is not available in any of the LDP > > messages/TLVs. Thanks & > > RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Yesterday is history. Tomorrow is mystery. > > Today is a gift. That=92s why it=92s called the > > Present!! > > > > ************************************************************= **************** > > > > Vinay H. Vernekar > > Sr. Software Engineer - Global R&D Solutions > > Wipro Technologies > > No.26, Hosur Main Road, Bommanahalli, > > Bangalore-560 068, India. > > > > ************************************************************= **************** > > --------------4BB01107DC24263805EFD13B Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkdmd03141 Content-Transfer-Encoding: quoted-printable Hi vijay,

Given a combination of upstream LSR (Ru) and downstream LSR (Rd) - Dis= tribution procedure is Downstream's distribution procedure & Request procedure is upstreams. Hence in the combination below,
<PushUnConditional, RequestWhenNeeded, RequestNoRetry,ReleaseOnChange, *> Distribution procedure represents donw= stream ' distribution procedure and Request Procedure is Upstream.=

Am I wrong ?=

The above conclution is made from= the mpls architechture draft (or RFC)
5.1.1 Downstream LSR: Distributi= on Procedure
5.1.2 Upstream LSR: Request Proc= edure

Regards
Amar

Vijayanand Chandrasekar wrote:

 <= font size=3D-1>Amar,This information is needed for configuring the LSRs' on what schemes WE suppor= t. For example PushConditional means Unsolicited Ordered control is used by us when we distribute labels as a downstream.It is not what is used ny our downstream.Your question is why you are not allowed to use - <= font size=3D-1> (PushUnCond)UnsolicitedIndependent with (RWN)Conservative .= <= font size=3D-1>Unsolicited Independent and Conservative are not used in combination,You can look at the mail archives for this.The question should not be not whether ur downstream is ordered or independen= t? <= font size=3D-1>Vijay
-----Original Message-----
From: Amarnath Honnavall= i Anantharamaiah [mailto:a= marnath.honnavalli@wipro.com]
Sent: Thursday, February= 22, 2001 5:39 PM
To: Vijayanand Chandrase= kar
Cc: Bob Thomas
Subject: Re: LSP control= mode of peer...
 
Vijay,

[1] No, basically question was,  From the list of valid schemes supported  for  merge capable LSR, we don't find this combinati= on.
<PushUnConditional, RequestWhenNeeded, RequestNoRetry,ReleaseOnChange, *>
 however we can find the fo= llowing combination
<PushConditional, R= equestWhenNeeded, RequestNoRetry,ReleaseOnChange, *>

Now, how do we know if downstream= is PushConditional or PushUnconditional ???

[2] If this is not needed to know= , Why is this combination given in the list ?

Regards
Amar

Vijayanand Chandrasekar wrote:

Vinay,I don't think you need to know whether your downstream is Ordered or Indepe= ndent. You need to just know if it is Ondemand or Unsolicited. Re= gards,Vijay
-----Original Message-----
From: owner-mpls@UU.NET = [mailto:owner-mpls@UU.NET]On Behalf Of Vinay Vernekar
Sent: Thursday, February= 22, 2001 1:41 PM
To: 'mpls@uu.net'=
Subject: LSP control mod= e of peer...
Hello,I have a query which came up w= hen implementing the LDP as in rfc3036 - "LDP Specification", keeping in mind the MPLS architecture as given be rfc3031.As discussed in rfc3031 - 5.2.1. Schemes for LSRs that Support Label Merging -If Ru and Rd are label distr= ibution peers, and both support labelmerging one of the supported scheme is - 3. <PushConditional, RequestWhenN= eeded, RequestNoRetry,ReleaseOnChange, *>This implies that the label retention mode of the upstream can be conservative given that the downstream is ope= rating in Unsolicited label distribution mode and its LSP control mode is Ordere= d. But how can the LSP control mode of the peer be determined? This is not available in any of the LDP messages/TLVs. Thanks & RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
Yesterday is history. Tomorrow i= s mystery.
Today is a gift. That=92s why it= =92s called the Present!!
********************************= *********************************************
Vinay H. Vernekar
Sr. Software Engineer - Global R= &D Solutions
Wipro Technologies
No.26, Hosur Main Road, Bommanah= alli,
Bangalore-560 068, India.=
********************************= *********************************************
--------------4BB01107DC24263805EFD13B-- From owner-mpls@UU.NET Thu Feb 22 10:53:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14808 for ; Thu, 22 Feb 2001 10:53: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 QQkdml12991; Thu, 22 Feb 2001 15:53:12 GMT Received: by mail-control.mail.uu.net id QQkdml03916 for mpls-outgoing; Thu, 22 Feb 2001 15:52:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdml03871 for ; Thu, 22 Feb 2001 15:52:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdml10206 for ; Thu, 22 Feb 2001 15:52:24 GMT Received: from web1002.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web1002.mail.yahoo.com [128.11.23.92]) id QQkdml29241 for ; Thu, 22 Feb 2001 15:52:24 GMT Received: (qmail 23178 invoked by uid 60001); 22 Feb 2001 15:52:23 -0000 Message-ID: <20010222155223.23177.qmail@web1002.mail.yahoo.com> Received: from [130.207.231.77] by web1002.mail.yahoo.com; Thu, 22 Feb 2001 07:52:23 PST Date: Thu, 22 Feb 2001 07:52:23 -0800 (PST) From: Vasos Vassiliou Subject: Signalled and un-signalled E-LSPs To: mpls@UU.NET In-Reply-To: <4FBEA8857476D311A03300204840E1CF446C1C@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have a few questions regarding signaling QOS parameters in DifServ/MPLS 1. Just to make sure that I have everything right in my mind: What exactly is the difference between signalled and unsignalled E-LSPs? 2. Are QoS parameters other than BW/Bit rate signalled in the MPLS net and how? Thanks in advance. Vasos Vassiliou Georgia Tech __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ From owner-mpls@UU.NET Thu Feb 22 11:18:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15859 for ; Thu, 22 Feb 2001 11:18: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 QQkdmn06730; Thu, 22 Feb 2001 16:18:34 GMT Received: by mail-control.mail.uu.net id QQkdmn22481 for mpls-outgoing; Thu, 22 Feb 2001 16:18:11 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 QQkdmn22476 for ; Thu, 22 Feb 2001 16:18: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 QQkdmn21455 for ; Thu, 22 Feb 2001 16:17:36 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 QQkdmn02289 for ; Thu, 22 Feb 2001 16:17: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 IAA05457 for ; Thu, 22 Feb 2001 08:17:50 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA06001 for mpls@uu.net; Thu, 22 Feb 2001 11:17:33 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdkw28490 for ; Thu, 22 Feb 2001 05:40:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdkw17116 for ; Thu, 22 Feb 2001 05:40:11 GMT Received: from exchange.satyam.net.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.144.12.32]) id QQkdkw25059 for ; Thu, 22 Feb 2001 05:40:05 GMT Received: from HQBNG01EXFE01.mindtree.com (lan-202-144-95-250.maa.sify.net [202.144.95.250] (may be forged)) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id LAA04869; Thu, 22 Feb 2001 11:09:48 +0530 Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by HQBNG01EXFE01.mindtree.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 22 Feb 2001 11:10:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Label Request Event Date: Thu, 22 Feb 2001 11:10:06 +0530 Message-ID: <2330401A6FE03445ADA682F5EBB7502D344E5C@mtv01ex01.mindtree.com> Thread-Topic: Label Request Event Thread-Index: AcCcasa8LMUXkoLOQpuaHOVjlO05jwAJteEg From: "Murali Krishna Policharla" To: "Heqing Zhu" , X-OriginalArrivalTime: 22 Feb 2001 05:40:07.0157 (UTC) FILETIME=[E9B5CA50:01C09C91] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15859 Hi Hequing, the LSR first checks whether the packet is meant for a destination that is reachable on the local interface (ethernet) , if it is reachable, then it will not say that no next hop is available it will assign a label and replies backs with the label mapping. Only if it cannot find an entry in the routing table and also the destination is not reachable via the local interface (ethernet) then it will say there is no Next Hop for this destination address . So then it is valid to send the following notifcation of no route. LRq.5 Execute procedure Send_Notification(MsgSource,No Route)." I think maybe the FEC has been to the destination address, Why not check this ? Thanks for your help Heqing Zhu -------->some one correct me if i am wrong murali krishna P. [Murali Krishna Policharla] From owner-mpls@UU.NET Thu Feb 22 11:26:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16211 for ; Thu, 22 Feb 2001 11:26: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 QQkdmn22642; Thu, 22 Feb 2001 16:26:11 GMT Received: by mail-control.mail.uu.net id QQkdmn23261 for mpls-outgoing; Thu, 22 Feb 2001 16:25: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 QQkdmn23249 for ; Thu, 22 Feb 2001 16:25: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 QQkdmn15404 for ; Thu, 22 Feb 2001 16:25:29 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 QQkdmn20752 for ; Thu, 22 Feb 2001 16:25:28 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 IAA12132 for ; Thu, 22 Feb 2001 08:25:43 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA06039 for mpls@uu.net; Thu, 22 Feb 2001 11:25:26 -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 QQkdmn23010 for ; Thu, 22 Feb 2001 16:23: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 QQkdmn19272 for ; Thu, 22 Feb 2001 16:22:08 GMT Received: from ss8mail1.ss8ott by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ss8.ca [209.87.228.147]) id QQkdmn12257 for ; Thu, 22 Feb 2001 16:22:07 GMT Received: from jianlipc (JIANLI_PC [192.168.1.78]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1R48ADPS; Thu, 22 Feb 2001 11:22:47 -0500 From: "Jianli Wang" To: Subject: CR-LDP MIBs Date: Thu, 22 Mar 2001 11:22:14 -0500 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) Importance: Normal In-Reply-To: <3747684.982609771584.JavaMail.imail@scorch.excite.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Does the WG have any plan for CR-LDP MIBs or is anybody (individual) working on it? Thanks. Jianli -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mark Lewis Sent: Monday, February 19, 2001 2:10 PM To: jorge.rodriguez@telefonica-data.com Cc: mpls@UU.NET Subject: Re: Interoperability Cisco-Juniper Try this link: http://www.juniper.net/products/interoperability/250004.html Mark Lewis Frontrunner Solutions On Mon, 19 Feb 2001 13:56:27 +0100, jorge.rodriguez@telefonica-data.com wrote: > > > > Can somebody give me any interoperability test information with Cisco 12000 and > Juniper? > > Sorry if this is not the proper forum... Is there another forum for this issues? > > _____________________________ > Jorge Rodriguez Gabilondo > Telefonica > Network Planning and Design > > > _________________________________________________________________ > Hemos renovado nuestra web. Esperamos su visita en > http://www.telefonica-data.com > > _______________________________________________________ Get 100% private, FREE email for life from Excite UK Visit http://inbox.excite.co.uk/ From owner-mpls@UU.NET Thu Feb 22 11:36:45 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16785 for ; Thu, 22 Feb 2001 11:36:45 -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 QQkdmo03171; Thu, 22 Feb 2001 16:36:41 GMT Received: by mail-control.mail.uu.net id QQkdmo24621 for mpls-outgoing; Thu, 22 Feb 2001 16:36: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 QQkdmo24552 for ; Thu, 22 Feb 2001 16:35:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdmo26184 for ; Thu, 22 Feb 2001 16:35:00 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdmo15724 for ; Thu, 22 Feb 2001 16:34:59 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA20337 for mpls@uu.net; Thu, 22 Feb 2001 11:34:58 -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 QQkdmo24329 for ; Thu, 22 Feb 2001 16: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 QQkdmo22319 for ; Thu, 22 Feb 2001 16:33:38 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 QQkdmo28824 for ; Thu, 22 Feb 2001 16:33:38 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 LAA24560; Thu, 22 Feb 2001 11:33:03 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-158.cisco.com [161.44.134.158]) by bucket.cisco.com (Mirapoint) with ESMTP id AAW38456; Thu, 22 Feb 2001 11:33:36 -0500 (EST) Message-Id: <4.3.2.7.2.20010222113425.01fa6368@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Feb 2001 11:35:55 -0500 To: "Jianli Wang" , From: "Thomas D. Nadeau" Subject: Re: CR-LDP MIBs In-Reply-To: References: <3747684.982609771584.JavaMail.imail@scorch.excite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Take a look at the MPLS-TE-MIB. It has (most) of the functionality you need right now. A forthcoming version (the result of the WG last call editions) does contain all necessary components for CR-LDP. --Tom >Does the WG have any plan for CR-LDP MIBs or is anybody (individual) >working on it? > >Thanks. > >Jianli > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mark >Lewis >Sent: Monday, February 19, 2001 2:10 PM >To: jorge.rodriguez@telefonica-data.com >Cc: mpls@UU.NET >Subject: Re: Interoperability Cisco-Juniper > > > > >Try this link: > >http://www.juniper.net/products/interoperability/250004.html > > >Mark Lewis >Frontrunner Solutions > >On Mon, 19 Feb 2001 13:56:27 +0100, jorge.rodriguez@telefonica-data.com >wrote: > > > > > > > > > Can somebody give me any interoperability test information with Cisco >12000 and > > Juniper? > > > > Sorry if this is not the proper forum... Is there another forum for this >issues? > > > > _____________________________ > > Jorge Rodriguez Gabilondo > > Telefonica > > Network Planning and Design > > > > > > _________________________________________________________________ > > Hemos renovado nuestra web. Esperamos su visita en > > http://www.telefonica-data.com > > > > > > > > > >_______________________________________________________ > Get 100% private, FREE email for life from Excite UK > Visit http://inbox.excite.co.uk/ From owner-mpls@UU.NET Thu Feb 22 11:37:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16822 for ; Thu, 22 Feb 2001 11:37: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 QQkdmo21772; Thu, 22 Feb 2001 16:37:43 GMT Received: by mail-control.mail.uu.net id QQkdmo24791 for mpls-outgoing; Thu, 22 Feb 2001 16:37: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 QQkdmo24766 for ; Thu, 22 Feb 2001 16:36:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdmo18670 for ; Thu, 22 Feb 2001 16:36:18 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdmo18827 for ; Thu, 22 Feb 2001 16:36:18 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id D826F94006; Thu, 22 Feb 2001 11:36:12 -0500 (EST) Message-ID: <3A953FFC.DF819168@sandburst.com> Date: Thu, 22 Feb 2001 11:36:12 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben Black Cc: mpls@UU.NET Subject: Re: MTU Signalling Extensions for LDP References: <20010221164932.B50026@layer8.net> Content-Type: multipart/alternative; boundary="------------097DF40CD17C8ED33FC14BB3" Sender: owner-mpls@UU.NET Precedence: bulk --------------097DF40CD17C8ED33FC14BB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben, Some feedback. In general, I feel that this is a good idea. There are some issues, however, with signaling over-head which need to be thought through. In particular, an effort needs to be made to reduce the number of label mapping messages required when updating the LSP MTU size (due, for instance to a next-hop change). Once you start advertising MTU, it is necessary that the ingress of the LSP is notified any time when the MTU becomes smaller and - at least periodically - when it becomes larger. It seems to me that it would be a good idea to avoid advertising MTU in LDP until you have received a real MTU value from an egress (as determined, for example, by the presence of a known hop-count). It also seems to me to be a good idea to allow implementations to employ some strategy to reduce the number of re-advertisements needed. Specific comments follow. Section 2.1 item 1)a): --------------------- The egress LSR would know what interface it will be using to forward packets it receives on an LSP (otherwise, it would not have advertised reachability for the FEC for this LSP, and it would be required to refuse a corresponding LSP request). It will know what the MTU is for that interface. Therefore, it should provide a "real" MTU rather than 0xffff. An LSR should be permitted, by wording in the specification, to use either the MTU of the interface it will forward packets on, or the minimum of a set of interfaces (up to and including all interfaces) over which it might forward the packet. For a simple router, the set of intefaces might be all interfaces - simply because a route change is likely to result in packets being forwarded on any interface. It isn't necessary to include the interface(s) on which a label is being supplied, since - if the new route has packets being forwarded using that interface - the labels supplied for that interface would have to be withdrawn anyway. However, unless the MTU size limitation is one-way, it will not make any difference if this interface is excluded since the upstream LSR will need to include it in any advertisements or forwarding it does using that label. For a more complex router (one which employs some sort of virtual routing paradigm) there may be a set of interfaces which is a proper subset of all interfaces on which packets associated with a specific FEC might be forwarded. The LSR need only consider those interfaces, in this case. I would suggest that the choice between using the MTU for the current known forwarding interface(s) and a set of interfaces might be a operator-configurable parameter. A specific operator may feel - as a result of network experiences, for example, that it is more beneficial with some LSRs to use one approach rather than the other. Section 2.1 item 1)b): --------------------- Applying the reasoning above, an LSR that is not the egress for a FEC should not include an MTU TLV (or it should include a TLV with an "unknown" MTU) until it receives a label mapping from a downstream LSR that does include an MTU TLV with a "real" MTU. In order to include information about the ability to negotiate LSP MTU, a non-egress LSR might advertise an MTU of either 0x0000 or 0xffff to indicate that it currently does not know the MTU for the LSP downstream. This follows the paradigm used for hop-count and for exactly the same reason: as long as each new label advertisement arrives with the same (unknown) MTU, it is not necessary to re-advertise any labels which have been previously advertised (including the new MTU). If a technique such as this is not employed, there may be some horrendous strobing of the network with label mappings if the predominant mode is independent downstream unsolicited label advertisement. Also, advertising an "unknown" MTU size at least lets each LSR (up to and including the ingress LSR) know that the capability for MTU negotiation exists. Again, implementations should be allowed by the specification to advertise the minimum MTU of a set of interfaces ranging from the set it might currently use (the "active Mapping"s in your current draft) to the set of all interfaces. Section 2.1 item 1)c): --------------------- If the above approach is bought into, the case where an LSR receives a label mapping which does not contain an MTU TLV becomes the example of the backward compatibility case (an existing LSR will not include this TLV) and indicates that there is no end to end MTU negotiation capability for this LSP. At this point, my thinking is that this should be refelected all the way to the ingress (for example, to allow the ingress to "prefer" an LSP which does have MTU negotiation) by omission of the MTU TLV in all label mappings issued corresponding to this downstream LSP. I could be persuaded that this is not a good idea, however - if there are sound (or numerous) arguments against it. Also, in the event that (using independent mode) the LSR has previously provided label mappings that includes an MTU TLV of "unknonw" MTU size, it must send new label mappings which omit this TLV. Section 2.1 item 1)d): --------------------- The meaning of "neighbor to which it is not directly connected" is a little obscure for me. If the neighbor is connected via some sort of logical link, then an LSR should be smart enough to use the MTU corresponding to the logical link. Is this what you are saying? If so, it applies - I believe - more generally than to the LSP case. For example, there may be different MTU sizes associated with different VLAN tags and it is likely (in the Ethernet case) that there will be different MTU sizes depending on the next-hop (MAC address) - somewhat independent of the physical interface. Section 2.1 item 2): ------------------- I am not sure what value the second paragraph adds to the specification. Again the concept of "remote" neighbors is getting in the way. (BTW, does anyone need to have it pointed out that "remote neighbor" is an oxymoron? :-)) Section 2.1 item 3): ------------------- If the items above are changed, this step is correct - i.e. - it will not result in excessive label mapping messages. Section 2.2: ----------- Why is the "Reserved" field included? The 'U' and 'F' bits are set correctly (IMO), but there may be some value in mentioning why they are set this way. Section 5: --------- The procedures in this specification do introduce a new security issue: it is now possible to introduce a new type of "attack" in which a forged TCP segment contains an MTU TLV with an incorrect value. For example, an attacker may insert a TLV with an MTU one smaller than the last MTU advertised (forcing new advertisements to be strobed upstream) and continue in this vein until the MTU reaches zero. The procedures defined in RFC 3036, however, provide some protection against such an attack. Hence, while a new hazard is introduced, the risk of an attack in general is not increased. -- Eric Gray You wrote: > I'd like to have this draft accepted as a working group document. The > feedback has indicated little resistance to the idea or the details of > the extension. > > http://www.ietf.org/internet-drafts/draft-black-ldp-mtu-extensions-00.txt > > Ben --------------097DF40CD17C8ED33FC14BB3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ben,

    Some feedback.

    In general, I feel that this is a good idea.  There are some
issues, however, with signaling over-head which need to be
thought through.  In particular, an effort needs to be made to
reduce the number of label mapping messages required when
updating the LSP MTU size (due, for instance to a next-hop
change).  Once you start advertising MTU, it is necessary
that the ingress of the LSP is notified any time when the
MTU becomes smaller and - at least periodically - when it
becomes larger.  It seems to me that it would be a good idea
to avoid advertising MTU in LDP until you have received a
real MTU value from an egress (as determined, for example,
by the presence of a known hop-count).  It also seems to me
to be a good idea to allow implementations to employ some
strategy to reduce the number of re-advertisements needed.

    Specific comments follow.

Section 2.1 item 1)a):
---------------------

    The egress LSR would know what interface it will be using
to forward packets it receives on an LSP (otherwise, it would
not have advertised reachability for the FEC for this LSP, and
it would be required to refuse a corresponding LSP request).
It will know what the MTU is for that interface.  Therefore,
it should provide a "real" MTU rather than 0xffff.

    An LSR should be permitted, by wording in the specification,
to use either the MTU of the interface it will forward packets
on, or the minimum of a set of interfaces (up to and including
all interfaces) over which it might forward the packet.

    For a simple router, the set of intefaces might be all
interfaces - simply because a route change is likely to result
in packets being forwarded on any interface.  It isn't necessary
to include the interface(s) on which a label is being supplied,
since - if the new route has packets being forwarded using that
interface - the labels supplied for that interface would have to
be withdrawn anyway.  However, unless the MTU size limitation is
one-way, it will not make any difference if this interface is
excluded since the upstream LSR will need to include it in any
advertisements or forwarding it does using that label.

    For a more complex router (one which employs some sort of
virtual routing paradigm) there may be a set of interfaces
which is a proper subset of all interfaces on which packets
associated with a specific FEC might be forwarded.  The LSR
need only consider those interfaces, in this case.

    I would suggest that the choice between using the MTU for
the current known forwarding interface(s) and a set of interfaces
might be a operator-configurable parameter.  A specific operator
may feel - as a result of network experiences, for example, that
it is more beneficial with some LSRs to use one approach rather
than the other.

Section 2.1 item 1)b):
---------------------

    Applying the reasoning above, an LSR that is not the egress
for a FEC should not include an MTU TLV (or it should include a
TLV with an "unknown" MTU) until it receives a label mapping from
a downstream LSR that does include an MTU TLV with a "real" MTU.
In order to include information about the ability to negotiate LSP
MTU, a non-egress LSR might advertise an MTU of either 0x0000 or
0xffff to indicate that it currently does not know the MTU for the
LSP downstream.

    This follows the paradigm used for hop-count and for exactly
the same reason: as long as each new label advertisement arrives
with the same (unknown) MTU, it is not necessary to re-advertise
any labels which have been previously advertised (including the
new MTU).  If a technique such as this is not employed, there may
be some horrendous strobing of the network with label mappings
if the predominant mode is independent downstream unsolicited
label advertisement.

    Also, advertising an "unknown" MTU size at least lets each
LSR (up to and including the ingress LSR) know that the capability
for MTU negotiation exists.

    Again, implementations should be allowed by the specification
to advertise the minimum MTU of a set of interfaces ranging from
the set it might currently use (the "active Mapping"s in your
current draft) to the set of all interfaces.

Section 2.1 item 1)c):
---------------------

    If the above approach is bought into, the case where an LSR
receives a label mapping which does not contain an MTU TLV becomes
the example of the backward compatibility case (an existing LSR
will not include this TLV) and indicates that there is no end to
end MTU negotiation capability for this LSP.  At this point, my
thinking is that this should be refelected all the way to the
ingress (for example, to allow the ingress to "prefer" an LSP
which does have MTU negotiation) by omission of the MTU TLV in
all label mappings issued corresponding to this downstream LSP.
I could be persuaded that this is not a good idea, however - if
there are sound (or numerous) arguments against it.

    Also, in the event that (using independent mode) the LSR has
previously provided label mappings that includes an MTU TLV of
"unknonw" MTU size, it must send new label mappings which omit
this TLV.

Section 2.1 item 1)d):
---------------------

    The meaning of "neighbor to which it is not directly
connected" is a little obscure for me.  If the neighbor is
connected via some sort of logical link, then an LSR should
be smart enough to use the MTU corresponding to the logical
link.  Is this what you are saying?  If so, it applies - I
believe - more generally than to the LSP case.  For example,
there may be different MTU sizes associated with different
VLAN tags and it is likely (in the Ethernet case) that there
will be different MTU sizes depending on the next-hop (MAC
address) - somewhat independent of the physical interface.

Section 2.1 item 2):
-------------------

    I am not sure what value the second paragraph adds to
the specification.  Again the concept of "remote" neighbors
is getting in the way.  (BTW, does anyone need to have it
pointed out that "remote neighbor" is an oxymoron? :-))

Section 2.1 item 3):
-------------------

    If the items above are changed, this step is correct -
i.e. - it will not result in excessive label mapping messages.

Section 2.2:
-----------

    Why is the "Reserved" field included?

    The 'U' and 'F' bits are set correctly (IMO), but there
may be some value in mentioning why they are set this way.

Section 5:
---------

    The procedures in this specification do introduce a new
security issue: it is now possible to introduce a new type
of "attack" in which a forged TCP segment contains an MTU
TLV with an incorrect value.  For example, an attacker may
insert a TLV with an MTU one smaller than the last MTU
advertised (forcing new advertisements to be strobed upstream)
and continue in this vein until the MTU reaches zero.

    The procedures defined in RFC 3036, however, provide some
protection against such an attack.  Hence, while a new hazard
is introduced, the risk of an attack in general is not increased.

--
Eric Gray

You wrote:

I'd like to have this draft accepted as a working group document.  The
feedback has indicated little resistance to the idea or the details of
the extension.

http://www.ietf.org/internet-drafts/draft-black-ldp-mtu-extensions-00.txt

Ben

--------------097DF40CD17C8ED33FC14BB3-- From owner-mpls@UU.NET Thu Feb 22 11:47:52 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17366 for ; Thu, 22 Feb 2001 11:47: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 QQkdmp19531; Thu, 22 Feb 2001 16:47:51 GMT Received: by mail-control.mail.uu.net id QQkdmp26317 for mpls-outgoing; Thu, 22 Feb 2001 16:47: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 QQkdmp26306 for ; Thu, 22 Feb 2001 16:47: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 QQkdmp00563 for ; Thu, 22 Feb 2001 16:46:53 GMT Received: from tcb.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQkdmp13801 for ; Thu, 22 Feb 2001 16:46:52 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id JAA26849 for ; Thu, 22 Feb 2001 09:45:42 -0700 Message-Id: <200102221645.JAA26849@tcb.net> X-Mailer: exmh version 2.0.3 To: mpls@UU.NET From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: PWOT Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 09:45:42 -0700 Sender: owner-mpls@UU.NET Precedence: bulk The PWOT mailing list has been created for discussion of Pseudo Wires Over Transport. PWOT is a descendant of CEOT (Circulation Emulation Over Transport), and is a to-be working group. The IESG is working with the chairs to finalize the charter now and a BOF slot has been secured for the meeting in Minneapolis. The charter will be posted once it's been finalized. CEOT list subscription will not be transferred, so if you're interested please subscribe to PWOT. There are two methods of subscribing: o Submit the standard email request to pwot-request@ietf.org o Go to http://www.ietf.org/mailman/listinfo/pwot General posts should be directed to pwot@ietf.org. Member posting only is enabled. Archives will be accessible via the URL above. Additional information (i.e., charter, et al.) will be posted as soon as it's finalized. Thanks! Luca & Danny From owner-mpls@UU.NET Thu Feb 22 12:01:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18169 for ; Thu, 22 Feb 2001 12:01: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 QQkdmq11058; Thu, 22 Feb 2001 17:01:44 GMT Received: by mail-control.mail.uu.net id QQkdmq01099 for mpls-outgoing; Thu, 22 Feb 2001 17:01: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 QQkdmq01067 for ; Thu, 22 Feb 2001 17:01: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 QQkdmq09463 for ; Thu, 22 Feb 2001 17:00:19 GMT Received: from prue.eim.surrey.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQkdmq07243 for ; Thu, 22 Feb 2001 17:00:18 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 14Vz68-0005Zh-00; Thu, 22 Feb 2001 17:00:08 +0000 Date: Thu, 22 Feb 2001 17:00:05 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Danny McPherson cc: mpls@UU.NET, ietf@ietf.org, poised@lists.tislabs.com Subject: Re: PWOT Mailing List In-Reply-To: <200102221645.JAA26849@tcb.net> 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 >From the announcement below: > General posts should be directed to pwot@ietf.org. Member > posting only is enabled. Archives will be accessible via > the URL above. Please clarify exactly what you mean by 'Member posting only' for an IETF WG list. (You may wish to read recent discussion on poisson over the last month first, and consider the implications.) L. isn't it just great how mechanisms turn into policy? PGP On Thu, 22 Feb 2001, Danny McPherson wrote: > Date: Thu, 22 Feb 2001 09:45:42 -0700 > From: Danny McPherson > To: mpls@UU.NET > Subject: PWOT Mailing List > > > The PWOT mailing list has been created for discussion > of Pseudo Wires Over Transport. PWOT is a descendant > of CEOT (Circulation Emulation Over Transport), and is > a to-be working group. > > The IESG is working with the chairs to finalize the > charter now and a BOF slot has been secured for the > meeting in Minneapolis. > > The charter will be posted once it's been finalized. > > CEOT list subscription will not be transferred, so if > you're interested please subscribe to PWOT. There are > two methods of subscribing: > > o Submit the standard email request to pwot-request@ietf.org > o Go to http://www.ietf.org/mailman/listinfo/pwot > > General posts should be directed to pwot@ietf.org. Member > posting only is enabled. Archives will be accessible via > the URL above. > > Additional information (i.e., charter, et al.) will be > posted as soon as it's finalized. > > Thanks! > > Luca & Danny From owner-mpls@UU.NET Thu Feb 22 12:02:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18194 for ; Thu, 22 Feb 2001 12:02: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 QQkdmq09750; Thu, 22 Feb 2001 17:01:59 GMT Received: by mail-control.mail.uu.net id QQkdmq01539 for mpls-outgoing; Thu, 22 Feb 2001 17:01: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 QQkdmq01440 for ; Thu, 22 Feb 2001 17:01: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 QQkdmq04823 for ; Thu, 22 Feb 2001 17:01:04 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdmq08381 for ; Thu, 22 Feb 2001 17:01:04 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id D256894006; Thu, 22 Feb 2001 12:00:58 -0500 (EST) Message-ID: <3A9545CA.9B3D4919@sandburst.com> Date: Thu, 22 Feb 2001 12:00:58 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "B, Prakash K (Prakash)" Cc: MPLS Mailing List Subject: Re: Hop Count Procedures References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Prakash, In the case where all involved LSRs decrement TTL, TTL is decremented exactly once by each LSR using the procedures in RFC 3032, section 2.4. You wrote: > Eric, > Another question on Hop count. If we continue to disregard tunnels as links, > the number of hierarchial levels in a given AS or a domain must not > influence the final TTL value. Is there something Iam overlooking? > > Regards, > Prakash. > > --- From owner-mpls@UU.NET Thu Feb 22 12:19:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19196 for ; Thu, 22 Feb 2001 12:19: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 QQkdmr00267; Thu, 22 Feb 2001 17:19:55 GMT Received: by mail-control.mail.uu.net id QQkdmr14832 for mpls-outgoing; Thu, 22 Feb 2001 17:19: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 QQkdmr14827 for ; Thu, 22 Feb 2001 17:19: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 QQkdmr26784 for ; Thu, 22 Feb 2001 17:16:54 GMT Received: from tcb.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQkdmr10961 for ; Thu, 22 Feb 2001 17:16:54 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA27299; Thu, 22 Feb 2001 10:15:41 -0700 Message-Id: <200102221715.KAA27299@tcb.net> X-Mailer: exmh version 2.0.3 To: L.Wood@eim.surrey.ac.uk cc: mpls@UU.NET, ietf@ietf.org, poised@lists.tislabs.com From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: PWOT Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 10:15:41 -0700 Sender: owner-mpls@UU.NET Precedence: bulk > Please clarify exactly what you mean by 'Member posting only' for an > IETF WG list. (You may wish to read recent discussion on poisson > over the last month first, and consider the implications.) Anti-spam measures are in place (i.e., non-member posts are moderated). I believe this should alleviate your concerns. -danny From owner-mpls@UU.NET Thu Feb 22 12:33:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19736 for ; Thu, 22 Feb 2001 12:33: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 QQkdms13604; Thu, 22 Feb 2001 17:33:08 GMT Received: by mail-control.mail.uu.net id QQkdms15920 for mpls-outgoing; Thu, 22 Feb 2001 17:32:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkdms15903 for ; Thu, 22 Feb 2001 17:32: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 QQkdms07706 for ; Thu, 22 Feb 2001 17:31:15 GMT Received: from mailhost.iitb.ac.in by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQkdms20838 for ; Thu, 22 Feb 2001 17:31:14 GMT Received: (qmail 4180 invoked from network); 22 Feb 2001 17:28:01 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 22 Feb 2001 17:28:01 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id WAA20798; Thu, 22 Feb 2001 22:56:18 +0530 (IST) Date: Thu, 22 Feb 2001 22:56:18 +0530 (IST) From: Abhijit To: Amarnath Honnavalli Anantharamaiah cc: mpls@UU.NET Subject: Re: LSP control mode of peer... In-Reply-To: <3A9519E5.15378941@wipro.com> Message-ID: 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 MAA19736 amar, I think its not at all necessary to know the Downstream Label Distribution Control Mode. If thats what u r asking.. An LSR acting as Ru will never mind whether the bindings it receives is independent or ordered as long as it receives them . (However its a job of Downstream LSR to suppply bindings properly.) perhaps following diagram might help. Ru........ Rd1.........Rd2 consider things at Rd1 PushConditional/unConditional depends upon whether after receiving request from Ru1(Assuming Ru is reqWhenNeeded and ingress) Rd1 should distribute binding to Ru1 independently (pushUnconditional) or only if it has received it from Rd2(pushConditional -- assuming all conditions in 5.1.1. are met.) So its not at all needed by Ru1 to know the Control mode of Rd1.. However if Rd1 chooses to use pushConditional with requestNever with Downsteam on Demand mode (thr' misconfiguration probably) ( READ specifically section 5.2.3 of rfc3031), then its in serious problems as it will never request anything but is expecting a mapping from downstream. Hope it is clear -abhijit On Thu, 22 Feb 2001, Amarnath Honnavalli Anantharamaiah wrote: >Hi vijay, > >Given a combination of upstream LSR (Ru) and downstream LSR (Rd) - >Distribution procedure is Downstream's distribution procedure & Request >procedure is upstreams. Hence in the combination below, >*> Distribution procedure represents donwstream ' distribution procedure >and Request Procedure is Upstream. > >Am I wrong ? > >The above conclution is made from the mpls architechture draft (or RFC) >5.1.1 Downstream LSR: Distribution Procedure >5.1.2 Upstream LSR: Request Procedure > >Regards >Amar > >Vijayanand Chandrasekar wrote: > >> Amar,This information is needed for configuring the LSRs' on what >> schemes WE support. For example PushConditional means Unsolicited >> Ordered control is used by us when we distribute labels as a >> downstream.It is not what is used ny our downstream.Your question is >> why you are not allowed to use - (PushUnCond)UnsolicitedIndependent >> with (RWN)Conservative .Unsolicited Independent and Conservative are >> not used in combination,You can look at the mail archives for this.The >> question should not be not whether ur downstream is ordered or >> independent? Vijay >> >> -----Original Message----- >> From: Amarnath Honnavalli Anantharamaiah >> [mailto:amarnath.honnavalli@wipro.com] >> Sent: Thursday, February 22, 2001 5:39 PM >> To: Vijayanand Chandrasekar >> Cc: Bob Thomas >> Subject: Re: LSP control mode of peer... >> >> Vijay, >> >> [1] No, basically question was, From the list of valid >> schemes supported for merge capable LSR, we don't find >> this combination. >> > RequestNoRetry,ReleaseOnChange, *> >> however we can find the following combination >> > RequestNoRetry,ReleaseOnChange, *> >> >> Now, how do we know if downstream is PushConditional or >> PushUnconditional ??? >> >> [2] If this is not needed to know, Why is this combination >> given in the list ? >> >> Regards >> Amar >> >> Vijayanand Chandrasekar wrote: >> >> > Vinay,I don't think you need to know whether your >> > downstream is Ordered or Independent. You need to just >> > know if it is Ondemand or Unsolicited. Regards,Vijay >> > >> > -----Original Message----- >> > From: owner-mpls@UU.NET >> > [mailto:owner-mpls@UU.NET]On Behalf Of Vinay >> > Vernekar >> > Sent: Thursday, February 22, 2001 1:41 PM >> > To: 'mpls@uu.net' >> > Subject: LSP control mode of peer... >> > Hello,I have a query which came up when >> > implementing the LDP as in rfc3036 - "LDP >> > Specification", keeping in mind the MPLS >> > architecture as given be rfc3031.As discussed in >> > rfc3031 - 5.2.1. Schemes for LSRs that Support >> > Label Merging -If Ru and Rd are label >> > distribution peers, and both support >> > labelmerging one of the supported scheme is - 3. >> > > > RequestNoRetry,ReleaseOnChange, *>This implies >> > that the label retention mode of the upstream >> > can be conservative given that the downstream is >> > operating in Unsolicited label distribution mode >> > and its LSP control mode is Ordered. But how can >> > the LSP control mode of the peer be determined? >> > This is not available in any of the LDP >> > messages/TLVs. Thanks & >> > RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > Yesterday is history. Tomorrow is mystery. >> > Today is a gift. That’s why it’s called the >> > Present!! >> > >> > **************************************************************************** >> > >> > Vinay H. Vernekar >> > Sr. Software Engineer - Global R&D Solutions >> > Wipro Technologies >> > No.26, Hosur Main Road, Bommanahalli, >> > Bangalore-560 068, India. >> > >> > **************************************************************************** >> > > From owner-mpls@UU.NET Thu Feb 22 13:32:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21737 for ; Thu, 22 Feb 2001 13:32: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 QQkdmw18072; Thu, 22 Feb 2001 18:32:32 GMT Received: by mail-control.mail.uu.net id QQkdmw06294 for mpls-outgoing; Thu, 22 Feb 2001 18:32: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 QQkdmw06286 for ; Thu, 22 Feb 2001 18:31: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 QQkdmw26929 for ; Thu, 22 Feb 2001 18:30:35 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe19.law10.hotmail.com [64.4.14.123]) id QQkdmw12708 for ; Thu, 22 Feb 2001 18:30:34 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Feb 2001 10:30:34 -0800 X-Originating-IP: [12.124.181.202] From: "Frank Hujber" To: "MPLS Group" Subject: CR-LDP or RSVP-TE Date: Thu, 22 Feb 2001 13:34:44 -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: 22 Feb 2001 18:30:34.0413 (UTC) FILETIME=[8B4D45D0:01C09CFD] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In considering the choice between CR-LDP and RSVP-TE when controlling an optical network, it seems that the choice is between: 1) Constructing LSPs with soft state but having the advantage of refresh messages that will flag faults on otherwise quiet paths, and allowing the system to autonomously tear down LSPs (RSVP), 2) Constructing persistent LSPs that have no keep-alive capability inherent in the protocol, but that are not torn down unless the user does so pro-actively. Can any of the folks here who are associated with carriers tell which would be preferred? Frank Hujber fhujber@hotmail.com From owner-mpls@UU.NET Thu Feb 22 13:58:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22715 for ; Thu, 22 Feb 2001 13:58: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 QQkdmx20895; Thu, 22 Feb 2001 18:58:40 GMT Received: by mail-control.mail.uu.net id QQkdmx08120 for mpls-outgoing; Thu, 22 Feb 2001 18:58: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 QQkdmx08115 for ; Thu, 22 Feb 2001 18:58:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdmx15537 for ; Thu, 22 Feb 2001 18:58:08 GMT Received: from east.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: east.isi.edu [38.245.76.2]) id QQkdmx20110 for ; Thu, 22 Feb 2001 18:58:08 GMT Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id NAA22068; Thu, 22 Feb 2001 13:57:56 -0500 (EST) Posted-Date: Thu, 22 Feb 2001 14:02:12 -0500 Message-Id: <10102221902.AA08791@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Thu, 22 Feb 01 14:02:13 EST To: L.Wood@eim.surrey.ac.uk Cc: Danny McPherson , mpls@UU.NET, ietf@ietf.org, poised@lists.tislabs.com Reply-To: mankin@east.isi.edu Subject: Re: PWOT Mailing List In-Reply-To: Your message of Thu, 22 Feb 2001 17:00:05 +0000. Date: Thu, 22 Feb 2001 14:02:12 -0500 From: Allison Mankin Sender: owner-mpls@UU.NET Precedence: bulk Danny, Lloyd, Having just been through this with midcom, may I suggest to Danny and Luca that pwot@ietf.org opt out of the member-only posting option on the IETF's mailman? Allison (one of the co-ADs for both midcom and the proposed pwot). From owner-mpls@UU.NET Thu Feb 22 14:53:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24732 for ; Thu, 22 Feb 2001 14:53: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 QQkdnb21165; Thu, 22 Feb 2001 19:53:51 GMT Received: by mail-control.mail.uu.net id QQkdnb27485 for mpls-outgoing; Thu, 22 Feb 2001 19:53:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdnb27463 for ; Thu, 22 Feb 2001 19:53:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdnb28983 for ; Thu, 22 Feb 2001 19:52:41 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkdnb18712 for ; Thu, 22 Feb 2001 19:52:41 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01804; Thu, 22 Feb 2001 14:52:37 -0500 (EST) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA19461; Thu, 22 Feb 2001 14:52:40 -0500 (EST) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Feb 2001 14:52:38 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446C21@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Vadim Suraev'" , "'Francois Le Faucheur'" Cc: "'mpls@UU.NET'" Subject: RE: Questions related to Class-Type (in DiffServ-TE context) Date: Thu, 22 Feb 2001 14:52:38 -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! Thanks for your response. But, I am still not clear about the purpose of sending the Class-Types in the (RSVP-TE & CR-LDP) signaling messages. In your reply you pointed out that PHB<-->Class-Type mapping has not yet been defined. Is it really author's intention to define, yet another higher layer grouping of PHBs (i.e a Class-Type consists of several PHBs ? If the administrator really wanted to define a class for Real-time, or Low-Loss, can't he define a new PHB ?) I thought the draft diff-te-reqts-00, implies that the main purpose of the introduction of Class-Type was to reduce the number of IGP messages required to communicate the per-diffserv class bandwidth information user configured on a LSR. Therefore, I understand that there need for changes to the IGPs, but I am unclear about the purpose of the Class-Type in the signaling messages. Your help in clarifying this will be appreciated. Thanks, sanjay -----Original Message----- From: Vadim Suraev [mailto:Vadim_Suraev@KereniX.com] Sent: Wednesday, February 21, 2001 5:01 PM To: 'Choudhury, Sanjaya' Cc: 'mpls@UU.NET' Subject: RE: Questions related to Class-Type (in DiffServ-TE context) Sanjay, if I'm not mistaken: > Questions regarding Definition of Class Types: > ------------------------------------------------------- > Q1. Who defines the Class-Types (0,1,2,3) ? If you ask about which PHBs are associated with which Class Type - I think, this is task of network operator to define, which PHB is in which Class Type. I think, the signaling for PHB(s)<-->Class Types mapping is not defined, but there is - ability to signal which PHBs LSP carries (draft-ietf-mpls-diff-ext-08.txt); - ability to allocate BW for particular LSP from unreserved BW of certain Class Type (draft-ietf-mpls-diff-te-ext-01.txt). So, I think, operator have to define this in such way, that particular set of PHBs will share BW from BW pool (unreserved BW), associated with same Class Type and particular PHB will not allocate BW from more than one Class Type. > Q2. If these Class-Types are administrator defined and is configured > in all the LSR of the DiffServ-TE domain, why is the Class-Type > signaled ? > (Signaling messages already signals the PSC(s) being carried by > the LSP, can't one determine the class-type from local configuration?) I think, this allows you to avoid configuration of PHBs<-->Class Type mapping (and checking at LSP setup) at each LSR. > Q3. The diff-te-reqts-00 draft states that "per Class TE" can be > viewed as a special case of per Class-Type TE, where each Class-Type > is degenerated into a single Diff-Serv class. In this cases, is the > Class-Type information in the signaling messages redundant ? I think, it is not redundant because when you insert Class Type information into signaling message, you tell to each LSR on the path that you wish to allocate BW from BW pool of the Class Type. For example, you may associate EF with Class Type 1 and AFxx with Class Type 2. Then Class Type 1 includes only one DiffServ class (EF) and BW which should be allocated for LSP, which carries this class (EF), should be taken from BW pool (unreserved BW) of Class Type 1. Therefore, Class Type 1 should be signaled for LSP, which carries EF, in this case. Also, you may setup LSP for AF11 only rather than for AFxx. Since AF11 is subset of AFxx (it means here that AF11 may share BW with other AFs) and AFxx is associated logically with Class Type 2, you must to to signal the Class Type 2. > Questions regarding the Admission Control of L-LSP in DiffServ-TE > environment. > > ------------------------------------------------------------------------- > Q1. The mpls-diff-ext-07 draft, indicates that the signaled > bandwidth can be used by the LSR to perform admission control of the signaled LSP > over the DiffServ resources provisioned for the relevant PSC(s). > The diff-te-ext-01 draft, states that if the CLASSTYPE object is not > present in the Path message, the LSR must associate the Class-Type 0 > to the LSP. This implies that one is expected to do admission control > against the resource available for Class-Type 0. > How can I read these two together ? I think, mpls-diff-ext-08 means, that each LSR is provisioned initially (using SNMP, for example) with per-PSC (per Class Type) reservable BW (i.e. all link's reservable BW may be divided into per PSC (per Class Type) BW pools). So, if you do not include the CLASSTYPE object into the Path message, LSP is automatically associated with Class Type 0 and (if I'm not mistaken), LSP's signaled PSC (described in mpls-diff-ext-08) is expected to be associated (logically) with Class Type 0. Otherwise (if LSP's signaled PSC is associated logically with other Class Type), LSP will try to allocate BW from unreserved BW, intended to other PSC(s). > Pre-emption and Class-Type > > -------------------------------------------------------------------------- > Q1. Based on the diff-te-reqts-01, can I assume that the pre-emption > should NOT work across the class-types (unlike the suggestion in the > 00 version of the draft) ? Do you mean the preemption priority levels? If so, I think it remains (there is draft-ietf-ospf-diff-te-00.txt, describes unreserved BW advertisements for different preemption priority levels). From owner-mpls@UU.NET Thu Feb 22 15:05:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25192 for ; Thu, 22 Feb 2001 15:05: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 QQkdnc23430; Thu, 22 Feb 2001 20:05:17 GMT Received: by mail-control.mail.uu.net id QQkdnc12644 for mpls-outgoing; Thu, 22 Feb 2001 20:04: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 QQkdnc12612 for ; Thu, 22 Feb 2001 20:04:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdnc19394 for ; Thu, 22 Feb 2001 20:03:00 GMT From: djiang1@lucent.com Received: from auemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkdnc20355 for ; Thu, 22 Feb 2001 20:03:00 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA29483 for ; Thu, 22 Feb 2001 15:03:00 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA29460 for ; Thu, 22 Feb 2001 15:02:59 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA07443; Thu, 22 Feb 2001 15:02:58 -0500 (EST) Subject: Outband VCID notification for LDP To: mpls@UU.NET Date: Thu, 22 Feb 2001 14:59:13 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/22/2001 14:59:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Everyone, I have a question regarding outband VCID notiffication for LDP. On page 4 of RFC3038, section 3.1.1, point 2, it says for inband notification: "The node A sends a VCID PROPOSE message which contains the VCID value and a message ID through the newly established VC to the node B." I can understand that it is an inband notification message. However, on page 8 of RFC3038, section 3.2.1, point 2, it says for outband notification: "The upstream LSR sends the VCID PROPOSE message through the VC for LDP to notify the downstream LSR of the association between the BLLI and VCID values." I some how that the above is actually an inband notification as the refered VC is used. Regards, Jane D. Jiang From owner-mpls@UU.NET Thu Feb 22 23:55:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08566 for ; Thu, 22 Feb 2001 23:55: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 QQkdol19414; Fri, 23 Feb 2001 04:55:32 GMT Received: by mail-control.mail.uu.net id QQkdol05055 for mpls-outgoing; Fri, 23 Feb 2001 04:55:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdol05033 for ; Fri, 23 Feb 2001 04:54:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdol28473 for ; Fri, 23 Feb 2001 04:54:11 GMT Received: from hclhprnd.hclt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkdol11927 for ; Fri, 23 Feb 2001 04:54:09 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id KAA28235; Fri, 23 Feb 2001 10:49:13 +0530 Received: from JAIKUMARPC ([192.168.232.131]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FBRAX733; Fri, 23 Feb 2001 10:23:34 +0530 From: "Vijayanand Chandrasekar" To: "Amarnath Honnavalli Anantharamaiah" , Cc: "Bob Thomas" , Subject: RE: LSP control mode of peer... Date: Fri, 23 Feb 2001 10:27:51 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C09D83.46499D40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A9519E5.15378941@wipro.com> Importance: Normal 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_002C_01C09D83.46499D40 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkdol19414 Content-Transfer-Encoding: quoted-printable Hi Amar, Here - downstream distribution procedure means the distribution procedure followed by the LSR as a downstream. So PushUnCond.. means u are using DownstreamUnsolicitedIndependent control as your downstream label distribution procedure. Abhijit has graphically illustrated the scenario in his mail.Hop you are = now clear. Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Amarnath Honnavalli Anantharamaiah Sent: Thursday, February 22, 2001 7:24 PM To: Vijayanand Chandrasekar; mpls@UU.NET Cc: Bob Thomas Subject: Re: LSP control mode of peer... Hi vijay, Given a combination of upstream LSR (Ru) and downstream LSR (Rd) - Distribution procedure is Downstream's distribution procedure & Request procedure is upstreams. Hence in the combination below, Distribution procedure represents donwstream ' distribution procedure and Request Procedure is Upstream. Am I wrong ? The above conclution is made from the mpls architechture draft (or RFC) 5.1.1 Downstream LSR: Distribution Procedure 5.1.2 Upstream LSR: Request Procedure Regards Amar Vijayanand Chandrasekar wrote: Amar,This information is needed for configuring the LSRs' on what schemes WE support. For example PushConditional means Unsolicited Ordered control is used by us when we distribute labels as a downstream.It is not what is used ny our downstream.Your question is why you are not allowed t= o use - (PushUnCond)UnsolicitedIndependent with (RWN)Conservative .Unsolicited Independent and Conservative are not used in combination,You can look at the mail archives for this.The question should not be not whether ur downstream is ordered or independent? Vijay -----Original Message----- From: Amarnath Honnavalli Anantharamaiah [mailto:amarnath.honnavalli@wipro.com] Sent: Thursday, February 22, 2001 5:39 PM To: Vijayanand Chandrasekar Cc: Bob Thomas Subject: Re: LSP control mode of peer... Vijay, [1] No, basically question was, From the list of valid schemes supported for merge capable LSR, we don't find this combination. however we can find the following combination Now, how do we know if downstream is PushConditional or PushUnconditional ??? [2] If this is not needed to know, Why is this combination given in the list ? Regards Amar Vijayanand Chandrasekar wrote: Vinay,I don't think you need to know whether your downstream is Ordered or Independent. You need to just know if it is Ondemand or Unsolicited. Regards,Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vinay Vernekar Sent: Thursday, February 22, 2001 1:41 PM To: 'mpls@uu.net' Subject: LSP control mode of peer... Hello,I have a query which came up when implementing the LDP as= in rfc3036 - "LDP Specification", keeping in mind the MPLS architecture as given be rfc3031.As discussed in rfc3031 - 5.2.1. Schemes for LSRs that Support Label Merging -If Ru and Rd are label distribution peers, and bot= h support labelmerging one of the supported scheme is - 3. This implies that th= e label retention mode of the upstream can be conservative given that the downstream is operating in Unsolicited label distribution mode and its LS= P control mode is Ordered. But how can the LSP control mode of the peer be determined? This is not available in any of the LDP messages/TLVs. Thanks= & RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That=92s why it=92s called the Present!! *************************************************************************= *** * Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. *************************************************************************= *** * ------=_NextPart_000_002C_01C09D83.46499D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Amar,
Here -=20 downstream distribution procedure means the distribution procedure = followed by=20 the LSR as a downstream. So PushUnCond.. means u are using=20 DownstreamUnsolicitedIndependent control as your downstream label = distribution=20 procedure.
 
Abhijit has graphically illustrated the = scenario in his=20 mail.Hop you are now clear.
 
Regards,
Vijay
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Amarnath Honnavalli=20 Anantharamaiah
Sent: Thursday, February 22, 2001 7:24=20 PM
To: Vijayanand Chandrasekar; mpls@UU.NET
Cc: = Bob=20 Thomas
Subject: Re: LSP control mode of=20 peer...

Hi vijay,=20

Given a combination of upstream LSR (Ru) and downstream LSR (Rd) -=20 Distribution procedure is Downstream's distribution procedure & = Request=20 procedure is upstreams. Hence in the combination below,
<PushUnConditional,=20 RequestWhenNeeded, RequestNoRetry,ReleaseOnChange, *> = Distribution=20 procedure represents donwstream ' distribution procedure and Request = Procedure=20 is Upstream.=20

Am I wrong = ?=20

The above conclution is made = from the mpls=20 architechture draft (or RFC)
5.1.1 Downstream LSR: Distribution Procedure =
5.1.2 Upstream LSR: Request=20 Procedure=20

Regards
Amar=20

Vijayanand Chandrasekar wrote:=20

 Amar,This information = is needed for=20 configuring the LSRs' on what schemes WE support. For example=20 PushConditional means Unsolicited Ordered control is used by us when = we=20 distribute labels as a downstream.It is not what is used ny our=20 downstream.Your question is = why you are=20 not allowed to use - =20 (PushUnCond)UnsolicitedIndependent with (RWN)Conservative=20 .Unsolicited Independent and Conservative are not used in=20 combination,You can look at = the mail=20 archives for this.The question = should not be not=20 whether ur downstream is ordered or=20 independent? Vijay=20
-----Original Message-----
From: Amarnath Honnavalli = Anantharamaiah=20 [mailto:amarnath.honnavalli@= wipro.com]=20
Sent: Thursday, = February 22,=20 2001 5:39 PM
To:=20 Vijayanand Chandrasekar
Cc: Bob Thomas
Subject: Re: LSP control mode of = peer...=20
 
Vijay,=20

[1] No, basically question was,  From the list of valid = schemes=20 supported  for  merge capable LSR, we don't find this=20 combination.
<PushUnConditional, RequestWhenNeeded,=20 RequestNoRetry,ReleaseOnChange, *>
 however we can find the = following=20 combination
<PushConditional, RequestWhenNeeded,=20 RequestNoRetry,ReleaseOnChange, *>=20

Now, how do we know if = downstream is=20 PushConditional or PushUnconditional ???=20

[2] If this is not needed to = know, Why=20 is this combination given in the list ?=20

Regards =
Amar=20

Vijayanand Chandrasekar wrote:=20

Vinay,I don't think you need to know = whether your=20 downstream is Ordered or Independent. You need to just know if = it is=20 Ondemand or Unsolicited. Regards,Vijay=20
-----Original Message-----
From: owner-mpls@UU.NET = [mailto:owner-mpls@UU.NET]On=20 Behalf Of Vinay Vernekar
Sent: Thursday, February 22, 2001 1:41 = PM=20
To:=20 'mpls@uu.net'
Subject: LSP control mode of=20 peer...
Hello,I have=20 a query which came up when implementing the LDP as in rfc3036 = - "LDP=20 Specification", keeping in mind the MPLS architecture as given = be=20 rfc3031.As discussed in rfc3031 - 5.2.1. Schemes for LSRs that = Support=20 Label Merging -If Ru and Rd are label distribution peers, and = both=20 support labelmerging one of the supported scheme is = -=20 3. <PushConditional,=20 RequestWhenNeeded, RequestNoRetry,ReleaseOnChange, *>This = implies=20 that the label retention mode of the upstream can be = conservative=20 given that the downstream is operating in Unsolicited label=20 distribution mode and its LSP control mode is Ordered. But how = can the=20 LSP control mode of the peer be determined? This is not = available in=20 any of the LDP messages/TLVs. Thanks &=20 = RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=20
Yesterday is history. = Tomorrow is=20 mystery.
Today is a=20 gift. That’s why it’s called the = Present!!
***************************************************************= **************=20
Vinay H. = Vernekar=20
Sr. Software Engineer - = Global=20 R&D Solutions
Wipro Technologies
No.26, Hosur Main Road, Bommanahalli, =
Bangalore-560 068, = India.=20
***************************************************************= **************
------=_NextPart_000_002C_01C09D83.46499D40-- From owner-mpls@UU.NET Fri Feb 23 00:37:32 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09123 for ; Fri, 23 Feb 2001 00:37: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 QQkdoo05385; Fri, 23 Feb 2001 05:37:15 GMT Received: by mail-control.mail.uu.net id QQkdoo24373 for mpls-outgoing; Fri, 23 Feb 2001 05:36:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdoo24361 for ; Fri, 23 Feb 2001 05:36:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdoo02222 for ; Fri, 23 Feb 2001 05:36:40 GMT Received: from wiprom2mx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQkdoo29016 for ; Fri, 23 Feb 2001 05:36:38 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id LAA05630 for ; Fri, 23 Feb 2001 11:45:12 +0530 Received: from Vinayhv ([192.168.220.177]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA500E; Fri, 23 Feb 2001 11:03:20 +0530 Message-ID: <006101c09d59$da00a760$b1dca8c0@alc.wipinfo.soft.net> From: "Vinay Vernekar" To: "Abhijit" , "Amarnath Honnavalli Anantharamaiah" Cc: References: Subject: Re: LSP control mode of peer... Date: Fri, 23 Feb 2001 11:01:19 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Abhijeet, I have a query on the explanation given by you, kindly find it mentioned below - ----- Original Message ----- From: Abhijit To: Amarnath Honnavalli Anantharamaiah Cc: Sent: Thursday, February 22, 2001 10:56 PM Subject: Re: LSP control mode of peer... amar, I think its not at all necessary to know the Downstream Label Distribution Control Mode. If thats what u r asking.. An LSR acting as Ru will never mind whether the bindings it receives is independent or ordered as long as it receives them . (However its a job of Downstream LSR to suppply bindings properly.) perhaps following diagram might help. Ru........ Rd1.........Rd2 consider things at Rd1 PushConditional/unConditional depends upon whether after receiving request from Ru1(Assuming Ru is reqWhenNeeded and ingress) Rd1 should distribute binding to Ru1 independently (pushUnconditional) -- Since you are assuming Ru is ReqWhenNeeded, does this mean that a MPLS scheme is possible with Ru being RequestWhenNeeded and Rd1 being PushUnconditional?? If yes this scheme is not mentioned in 5.2.1 Schemes for LSRs that Support Label Merging... If no it implies that Ru can be in RequestWhenNeeded only when Rd1 is PushConditional and inorder to determine if Rd1 is in PushConditonal its control mode is to be known by Ru. Hope I have made it clear. or only if it has received it from Rd2(pushConditional -- assuming all conditions in 5.1.1. are met.) So its not at all needed by Ru1 to know the Control mode of Rd1.. However if Rd1 chooses to use pushConditional with requestNever with Downsteam on Demand mode (thr' misconfiguration probably) ( READ specifically section 5.2.3 of rfc3031), then its in serious problems as it will never request anything but is expecting a mapping from downstream. Hope it is clear -abhijit On Thu, 22 Feb 2001, Amarnath Honnavalli Anantharamaiah wrote: >Hi vijay, > >Given a combination of upstream LSR (Ru) and downstream LSR (Rd) - >Distribution procedure is Downstream's distribution procedure & Request >procedure is upstreams. Hence in the combination below, >*> Distribution procedure represents donwstream ' distribution procedure >and Request Procedure is Upstream. > >Am I wrong ? > >The above conclution is made from the mpls architechture draft (or RFC) >5.1.1 Downstream LSR: Distribution Procedure >5.1.2 Upstream LSR: Request Procedure > >Regards >Amar > >Vijayanand Chandrasekar wrote: > >> Amar,This information is needed for configuring the LSRs' on what >> schemes WE support. For example PushConditional means Unsolicited >> Ordered control is used by us when we distribute labels as a >> downstream.It is not what is used ny our downstream.Your question is >> why you are not allowed to use - (PushUnCond)UnsolicitedIndependent >> with (RWN)Conservative .Unsolicited Independent and Conservative are >> not used in combination,You can look at the mail archives for this.The >> question should not be not whether ur downstream is ordered or >> independent? Vijay >> >> -----Original Message----- >> From: Amarnath Honnavalli Anantharamaiah >> [mailto:amarnath.honnavalli@wipro.com] >> Sent: Thursday, February 22, 2001 5:39 PM >> To: Vijayanand Chandrasekar >> Cc: Bob Thomas >> Subject: Re: LSP control mode of peer... >> >> Vijay, >> >> [1] No, basically question was, From the list of valid >> schemes supported for merge capable LSR, we don't find >> this combination. >> > RequestNoRetry,ReleaseOnChange, *> >> however we can find the following combination >> > RequestNoRetry,ReleaseOnChange, *> >> >> Now, how do we know if downstream is PushConditional or >> PushUnconditional ??? >> >> [2] If this is not needed to know, Why is this combination >> given in the list ? >> >> Regards >> Amar >> >> Vijayanand Chandrasekar wrote: >> >> > Vinay,I don't think you need to know whether your >> > downstream is Ordered or Independent. You need to just >> > know if it is Ondemand or Unsolicited. Regards,Vijay >> > >> > -----Original Message----- >> > From: owner-mpls@UU.NET >> > [mailto:owner-mpls@UU.NET]On Behalf Of Vinay >> > Vernekar >> > Sent: Thursday, February 22, 2001 1:41 PM >> > To: 'mpls@uu.net' >> > Subject: LSP control mode of peer... >> > Hello,I have a query which came up when >> > implementing the LDP as in rfc3036 - "LDP >> > Specification", keeping in mind the MPLS >> > architecture as given be rfc3031.As discussed in >> > rfc3031 - 5.2.1. Schemes for LSRs that Support >> > Label Merging -If Ru and Rd are label >> > distribution peers, and both support >> > labelmerging one of the supported scheme is - 3. >> > > > RequestNoRetry,ReleaseOnChange, *>This implies >> > that the label retention mode of the upstream >> > can be conservative given that the downstream is >> > operating in Unsolicited label distribution mode >> > and its LSP control mode is Ordered. But how can >> > the LSP control mode of the peer be determined? >> > This is not available in any of the LDP >> > messages/TLVs. Thanks & >> > RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > Yesterday is history. Tomorrow is mystery. >> > Today is a gift. That's why it's called the >> > Present!! >> > >> > **************************************************************************** >> > >> > Vinay H. Vernekar >> > Sr. Software Engineer - Global R&D Solutions >> > Wipro Technologies >> > No.26, Hosur Main Road, Bommanahalli, >> > Bangalore-560 068, India. >> > >> > **************************************************************************** >> > > From owner-mpls@UU.NET Fri Feb 23 02:41:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23960 for ; Fri, 23 Feb 2001 02:41: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 QQkdow16238; Fri, 23 Feb 2001 07:40:46 GMT Received: by mail-control.mail.uu.net id QQkdow06656 for mpls-outgoing; Fri, 23 Feb 2001 07:40:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdow06647 for ; Fri, 23 Feb 2001 07:40:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdow22060 for ; Fri, 23 Feb 2001 07:40:11 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 QQkdow15433 for ; Fri, 23 Feb 2001 07:40:10 GMT Received: (qmail 29351 invoked from network); 23 Feb 2001 07:36:58 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 23 Feb 2001 07:36:58 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id NAA24664; Fri, 23 Feb 2001 13:05:10 +0530 (IST) Date: Fri, 23 Feb 2001 13:05:09 +0530 (IST) From: Abhijit Reply-To: Abhijit To: Vinay Vernekar cc: mpls@UU.NET Subject: Re: LSP control mode of peer... In-Reply-To: <006101c09d59$da00a760$b1dca8c0@alc.wipinfo.soft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk >-- Since you are assuming Ru is ReqWhenNeeded, does this mean that a MPLS >scheme is possible with Ru being RequestWhenNeeded and Rd1 being >PushUnconditional?? If yes this scheme is not mentioned in 5.2.1 Schemes for >LSRs that Support Label Merging... >If no it implies that Ru can be in RequestWhenNeeded only when Rd1 is >PushConditional and inorder to determine if Rd1 is in PushConditonal its >control mode is to be known by Ru. >Hope I have made it clear. Yes I certainly have missed this point. But i don't understand what precludes Upstream LSR for requesting a Label from Downstream when downstream is distributing it unslolcited with independent control. Consider e.g. Ru1 \ \ Rd1 - - Rd2 - - Rd3 - - D / / Ru2 Let Rd1 be merge capable.. Why can Rd1 not send a request to Rd2 for some FEC F for packets destined for D and coming from Both Ru1 and Ru2.. The fact that Rd2 distributes the label bindings unsolicitedly won't require Rd1 to send the request. But in any case it shouldn't prevent Rd1 from asking for it. How will it matter if Rd2 distributes binding labels for FEC independent control or Ordered control? So in any case Rd1 need not know Control mode of Rd2.. Is it consisitent with architecture? And if Rd1 is also distributing bindings independently.. It will distribute same binding to Ru1 and Ru2. Again why shd it stop Ru1 and Ru2 from requesting it anyways? Is this also consistent with architecture? Again Ru1 and Ru2 need not know the control mode of Rd1 am i missing something? -abhijit From owner-mpls@UU.NET Fri Feb 23 09:22:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02617 for ; Fri, 23 Feb 2001 09:22: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 QQkdpx27115; Fri, 23 Feb 2001 14:22:26 GMT Received: by mail-control.mail.uu.net id QQkdpx29100 for mpls-outgoing; Fri, 23 Feb 2001 14:21:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdpx29070 for ; Fri, 23 Feb 2001 14:21:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdpx19188 for ; Fri, 23 Feb 2001 14:21:36 GMT Received: from wiprom2mx2.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQkdpx09676 for ; Fri, 23 Feb 2001 14:21:35 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id UAA29005 for ; Fri, 23 Feb 2001 20:30:14 +0530 Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA5D69; Fri, 23 Feb 2001 19:48:16 +0530 Date: Fri, 23 Feb 2001 14:38:04 +0000 (Local time zone must be set--see zic manual page) From: "Nagabhushana Ramaswamy Nadig" X-Sender: bhushanr@boochi.alc.wipinfo.soft.net Reply-To: nagabhushana.ramaswamy@wipro.com To: Abhijit cc: Vinay Vernekar , mpls@UU.NET Subject: Re: LSP control mode of peer... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Consider e.g. > > Ru1 > \ > \ > Rd1 - - Rd2 - - Rd3 - - D > / > / > Ru2 > > Let Rd1 be merge capable.. > > Why can Rd1 not send a request to Rd2 for some FEC F for packets destined > for D and coming from Both Ru1 and Ru2.. The fact that Rd2 distributes the > label bindings unsolicitedly won't require Rd1 to send the request. But in > any case it shouldn't prevent Rd1 from asking for it. How will it matter > if Rd2 distributes binding labels for FEC independent control or Ordered > control? So in any case Rd1 need not know Control mode of Rd2.. Is it > consisitent with architecture? > -abhijit exactly! the problem started with the same thing - why should my request procedure depend on my peer's control mode?? I don't need to bother whether he has given the binding indepndently or not. If you look at the architecture doc section 5.2.1 you could find this dependency. So I feel we need to have one more tuple there where my request procedure can be "Request when needed" when I am in conservative retention and the downstream dist procedure is PushUConditional (or a possible restructuring of the tuples so that my request procedure is independant of peer's control mode). best regards Bhushana > > > From owner-mpls@UU.NET Fri Feb 23 10:29:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05147 for ; Fri, 23 Feb 2001 10:29: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 QQkdqb26965; Fri, 23 Feb 2001 15:28:44 GMT Received: by mail-control.mail.uu.net id QQkdqb21119 for mpls-outgoing; Fri, 23 Feb 2001 15:28:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqb21095 for ; Fri, 23 Feb 2001 15:28:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqb15911 for ; Fri, 23 Feb 2001 15:27:25 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdqb24240 for ; Fri, 23 Feb 2001 15:27:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA14610 for mpls@uu.net; Fri, 23 Feb 2001 10:27:24 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdqb20872 for ; Fri, 23 Feb 2001 15:26:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdqb20904 for ; Fri, 23 Feb 2001 15:26:39 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 QQkdqb15867 for ; Fri, 23 Feb 2001 15:26:39 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251] (may be forged)) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA01923; Fri, 23 Feb 2001 07:25:46 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BJWKB>; Fri, 23 Feb 2001 07:29:03 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A9B@BBY1EXM01> From: Shahram Davari To: "'Vinay Vernekar'" , "'mpls@uu.net'" Subject: RE: Multiple label spaces per link?? Date: Fri, 23 Feb 2001 07:29:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09DAD.596BE480" 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_01C09DAD.596BE480 Content-Type: text/plain; charset="iso-8859-1" Hi Vinay, You can have multiple label sapces per interface (or link) if you could differentiate between them, for example, using the virtual channel number. Yours, -Shahram -----Original Message----- From: Vinay Vernekar [mailto:vinay.vernekar@wipro.com] Sent: Thursday, February 22, 2001 3:22 AM To: 'mpls@uu.net' Subject: Multiple label spaces per link?? Hello, I have a question on the following from rfc3036 "LDP Specification". Under 2.5.3. Session Initialization page 15, para 4 it is given that - "In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each...." Does this mean that each link will advertise multiple spaces. In other words is it possible for a single link to advertise more than one label space?? Regards Vinay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That's why it's called the Present!! ***************************************************************************** Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. Tel: 91-80-5722293/5722296 Extn. 4019 Fax: 91-80-5722696 Email: vinay.vernekar@wipro.com The World's First SEI CMM Level 5 Software Services Company ***************************************************************************** ------_=_NextPart_001_01C09DAD.596BE480 Content-Type: text/html; charset="iso-8859-1"
Hi Vinay,
 
You can have multiple label  sapces per interface (or link) if you could differentiate between them, for example, using the virtual channel number.
 
Yours,
-Shahram
-----Original Message-----
From: Vinay Vernekar [mailto:vinay.vernekar@wipro.com]
Sent: Thursday, February 22, 2001 3:22 AM
To: 'mpls@uu.net'
Subject: Multiple label spaces per link??

Hello,
I have a question on the following from rfc3036 "LDP Specification".
Under 2.5.3. Session Initialization page 15, para 4 it is given that -
"In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each...."
Does this mean that each link will advertise multiple spaces. In other words is it possible for a single link to advertise more than one label space??
 
Regards
Vinay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday is history. Tomorrow is mystery.
Today is a gift. That’s why it’s called the Present!!
*****************************************************************************
Vinay H. Vernekar
Sr. Software Engineer - Global R&D Solutions
Wipro Technologies
No.26, Hosur Main Road, Bommanahalli,
Bangalore-560 068, India.
Tel: 91-80-5722293/5722296 Extn. 4019
Fax: 91-80-5722696
Email: vinay.vernekar@wipro.com
The World's First SEI CMM Level 5 Software Services Company
*****************************************************************************
------_=_NextPart_001_01C09DAD.596BE480-- From owner-mpls@UU.NET Fri Feb 23 10:38:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05506 for ; Fri, 23 Feb 2001 10:38: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 QQkdqc22768; Fri, 23 Feb 2001 15:38:06 GMT Received: by mail-control.mail.uu.net id QQkdqc22426 for mpls-outgoing; Fri, 23 Feb 2001 15:37: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 QQkdqc22415 for ; Fri, 23 Feb 2001 15:37:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqc19925 for ; Fri, 23 Feb 2001 15:37:03 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdqc13306 for ; Fri, 23 Feb 2001 15:37:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA16015 for mpls@uu.net; Fri, 23 Feb 2001 10:37:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqc22235 for ; Fri, 23 Feb 2001 15:36:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqc05587 for ; Fri, 23 Feb 2001 15:35:55 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 QQkdqc11042 for ; Fri, 23 Feb 2001 15:35:54 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251] (may be forged)) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA03769; Fri, 23 Feb 2001 07:33:12 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BJWKQ>; Fri, 23 Feb 2001 07:33:12 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A9C@BBY1EXM01> From: Shahram Davari To: "'Vijayanand Chandrasekar'" , Vinay Vernekar Cc: Balasubramanian Mandakolathur B , mpls@UU.NET Subject: RE: Multiple label spaces per link?? Date: Fri, 23 Feb 2001 07:33:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09DAD.EE53DB70" 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_01C09DAD.EE53DB70 Content-Type: text/plain; charset="iso-8859-1" Hi Vijay, I can understand the muticast case, becasue we could differentiate unicast and multicast labels using different link layer ID (such as PPP protocol ID). But I can't understand the L-LSP case! Could you please explain? Yours, _Shahram -----Original Message----- From: Vijayanand Chandrasekar [mailto:vijayc@hclt.com] Sent: Thursday, February 22, 2001 4:08 AM To: Vinay Vernekar Cc: Balasubramanian Mandakolathur B; mpls@UU.NET Subject: RE: Multiple label spaces per link?? Vinay, Yes. A single link can advertise more than one label space. This will happen in multicasting and in the case of diffserv/QoS when we create L-LSPs. Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vinay Vernekar Sent: Thursday, February 22, 2001 1:52 PM To: 'mpls@uu.net' Subject: Multiple label spaces per link?? Hello, I have a question on the following from rfc3036 "LDP Specification". Under 2.5.3. Session Initialization page 15, para 4 it is given that - "In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each...." Does this mean that each link will advertise multiple spaces. In other words is it possible for a single link to advertise more than one label space?? Regards Vinay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That's why it's called the Present!! ***************************************************************************** Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. Tel: 91-80-5722293/5722296 Extn. 4019 Fax: 91-80-5722696 Email: vinay.vernekar@wipro.com The World's First SEI CMM Level 5 Software Services Company ***************************************************************************** ------_=_NextPart_001_01C09DAD.EE53DB70 Content-Type: text/html; charset="iso-8859-1"
Hi Vijay,
 
I can understand the muticast case, becasue we could differentiate unicast and multicast labels using different link layer ID (such as PPP protocol ID). But I can't understand the L-LSP case! Could you please explain?
 
Yours,
_Shahram 
-----Original Message-----
From: Vijayanand Chandrasekar [mailto:vijayc@hclt.com]
Sent: Thursday, February 22, 2001 4:08 AM
To: Vinay Vernekar
Cc: Balasubramanian Mandakolathur B; mpls@UU.NET
Subject: RE: Multiple label spaces per link??

Vinay,
Yes. A single link can advertise more than one label space. This will happen in multicasting and in the case of diffserv/QoS when we create L-LSPs.
 
 
Regards,
Vijay
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vinay Vernekar
Sent: Thursday, February 22, 2001 1:52 PM
To: 'mpls@uu.net'
Subject: Multiple label spaces per link??

Hello,
I have a question on the following from rfc3036 "LDP Specification".
Under 2.5.3. Session Initialization page 15, para 4 it is given that -
"In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each...."
Does this mean that each link will advertise multiple spaces. In other words is it possible for a single link to advertise more than one label space??
 
Regards
Vinay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday is history. Tomorrow is mystery.
Today is a gift. That’s why it’s called the Present!!
*****************************************************************************
Vinay H. Vernekar
Sr. Software Engineer - Global R&D Solutions
Wipro Technologies
No.26, Hosur Main Road, Bommanahalli,
Bangalore-560 068, India.
Tel: 91-80-5722293/5722296 Extn. 4019
Fax: 91-80-5722696
Email: vinay.vernekar@wipro.com
The World's First SEI CMM Level 5 Software Services Company
*****************************************************************************
------_=_NextPart_001_01C09DAD.EE53DB70-- From owner-mpls@UU.NET Fri Feb 23 10:53:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06145 for ; Fri, 23 Feb 2001 10:53: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 QQkdqd14760; Fri, 23 Feb 2001 15:52:40 GMT Received: by mail-control.mail.uu.net id QQkdqd24157 for mpls-outgoing; Fri, 23 Feb 2001 15:51:45 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 QQkdqd24145 for ; Fri, 23 Feb 2001 15:51: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 QQkdqd19054 for ; Fri, 23 Feb 2001 15:50:19 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdqd10040 for ; Fri, 23 Feb 2001 15:50:19 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 2FB3F94006; Fri, 23 Feb 2001 10:50:14 -0500 (EST) Message-ID: <3A9686B6.4C8C5224@sandburst.com> Date: Fri, 23 Feb 2001 10:50:14 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: nagabhushana.ramaswamy@wipro.com Cc: Abhijit , Vinay Vernekar , mpls@UU.NET Subject: Re: LSP control mode of peer... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bhushana, You're all placing too much "authority" in an architecture document. Architecture typically defines a framework for design and specification. In this case, the LDP specification specifically allows Label Request messages to be used by an upstream peer when the downstream peer is using downstream unsolicited label distribution. As a minimum, this is required when the upstream LSR is an ATM LSR and is not able to perform VC-merge. But there is nothing that restricts this support to ATM LSRs. Instead of asking if the architecture allows it, look to see if the protocol specification allows it. You wrote: > > Consider e.g. > > > > Ru1 > > \ > > \ > > Rd1 - - Rd2 - - Rd3 - - D > > / > > / > > Ru2 > > > > Let Rd1 be merge capable.. > > > > Why can Rd1 not send a request to Rd2 for some FEC F for packets destined > > for D and coming from Both Ru1 and Ru2.. The fact that Rd2 distributes the > > label bindings unsolicitedly won't require Rd1 to send the request. But in > > any case it shouldn't prevent Rd1 from asking for it. How will it matter > > if Rd2 distributes binding labels for FEC independent control or Ordered > > control? So in any case Rd1 need not know Control mode of Rd2.. Is it > > consisitent with architecture? > > -abhijit > > exactly! the problem started with the same thing - why should my request > procedure depend on my peer's control mode?? I don't need to bother > whether he has given the binding indepndently or not. If you look at the > architecture doc section 5.2.1 you could find this dependency. So I feel > we need to have one more tuple there where my request procedure can be > "Request when needed" when I am in conservative retention and the > downstream dist procedure is PushUConditional (or a possible restructuring > of the tuples so that my request procedure is independant of peer's > control mode). > > best regards > Bhushana > > > > > From owner-mpls@UU.NET Fri Feb 23 10:53:53 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06176 for ; Fri, 23 Feb 2001 10:53:53 -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 QQkdqd23141; Fri, 23 Feb 2001 15:53:33 GMT Received: by mail-control.mail.uu.net id QQkdqd24291 for mpls-outgoing; Fri, 23 Feb 2001 15:52:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdqd24286 for ; Fri, 23 Feb 2001 15:52:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdqd18473 for ; Fri, 23 Feb 2001 15:51:01 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdqd11043 for ; Fri, 23 Feb 2001 15:51:00 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA17701 for mpls@uu.net; Fri, 23 Feb 2001 10:51:00 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqd24024 for ; Fri, 23 Feb 2001 15:50:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqd07923 for ; Fri, 23 Feb 2001 15:49:56 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkdqd09168 for ; Fri, 23 Feb 2001 15:49:56 GMT Received: from [192.168.123.149] (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id HAA08964; Fri, 23 Feb 2001 07:49:36 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@127.0.0.1 Message-Id: In-Reply-To: <3A9403E0.AC0BEA27@sandburst.com> References: <3A9403E0.AC0BEA27@sandburst.com> Date: Fri, 23 Feb 2001 07:48:35 -0800 To: akyol@akyol.org From: Bora Akyol Subject: New TTL Draft Cc: djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk Note that we (Puneet and I) just posted an Internet Draft on TTL handling in hierarchical MPLS networks. The internet draft is titled: draft-agarwal-mpls-ttl-00.txt http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt We welcome any comments, Bora Akyol From owner-mpls@UU.NET Fri Feb 23 11:16:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07230 for ; Fri, 23 Feb 2001 11:16: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 QQkdqf25616; Fri, 23 Feb 2001 16:16:37 GMT Received: by mail-control.mail.uu.net id QQkdqf12595 for mpls-outgoing; Fri, 23 Feb 2001 16:15:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqf12584 for ; Fri, 23 Feb 2001 16:15:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqe02503 for ; Fri, 23 Feb 2001 16:14:06 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdqe26905 for ; Fri, 23 Feb 2001 16:14:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA20857 for mpls@uu.net; Fri, 23 Feb 2001 11:14:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqe12281 for ; Fri, 23 Feb 2001 16:13:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqe00269 for ; Fri, 23 Feb 2001 16:13:06 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 QQkdqe25079 for ; Fri, 23 Feb 2001 16:13:05 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 IAA18326; Fri, 23 Feb 2001 08:12:18 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BJW69>; Fri, 23 Feb 2001 08:12:18 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A9D@BBY1EXM01> From: Shahram Davari To: "'internet-drafts@ietf.org'" Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: New: draft-harrison-mpls-oam-00.txt Date: Fri, 23 Feb 2001 08:15:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09DB3.D919AFE0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C09DB3.D919AFE0 Content-Type: text/plain; charset="iso-8859-1" Hi, Please post the attached Internet draft on the IETF Internet draft directory. <> Thanks, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 <> ------_=_NextPart_000_01C09DB3.D919AFE0 Content-Type: text/plain; name="draft-harrison-mpls-oam-00.txt.txt" Content-Disposition: attachment; filename="draft-harrison-mpls-oam-00.txt.txt" Content-Transfer-Encoding: quoted-printable Neil Harrison = Internet Draft Peter Willis = Document: draft-harrison-mpls-oam-00.txt British Telecom = Expires: August 2001 = Shahram Davari = PMC-Sierra = = Ben Mack-Crane = Tellabs = = Hiroshi Ohta = NTT = = February 2001 = =20 =20 OAM Functionality for MPLS Networks=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =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 documents = 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 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Copyright Notice=20 =20 Copyright(C) The Internet Society (2001). All Rights Reserved.=20 =20 =20 Abstract=20 =20 This Internet draft provides requirements and mechanisms for OAM=20 (Operation and Maintenance) for the user-plane in MPLS networks. A=20 connectivity verification "CV" OAM packet is defined, which is=20 transmitted periodically from LSP source to LSP sink. The CV flow=20 could be used to detect defects related to misrouting of LSPs as=20 well as link and nodal failure, and if required to trigger=20 protection switching to the protection path.=20 =20 Harrison et.al Expires August 2001 Page 1 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 =20 A forward defect identifier "FDI" and a backward defect identifier=20 "BDI" are defined, which carry the defect type and location to the=20 near end and far end respectively. At every LSP terminating node,=20 the FDI is mapped from server layer to client layer. By doing so FDI = could suppress the alarm storm, and let the appropriate layer take=20 control of protection switching. BDI is used by LSP source to start=20 or stop the QoS aggregation, depending on whether the LSP is in=20 available or unavailable state. The criteria for entry and exit to=20 the available and unavailable states are also defined in this=20 document.=20 =20 =20 Table of Contents=20 =20 1. = Introduction..................................................3=20 2. = Definitions...................................................4=20 3. Symbols and = Abbreviations.....................................5=20 4. Requirements for MPLS = OAM.....................................5=20 5. Principles of OAM = Function....................................6=20 5.1 Client/Server = Recursion-Layering..............................6=20 5.2 OAM Functionality and Layer = Independence......................7=20 5.3 = Defects.......................................................7=20 5.4 Availability..................................................7= =20 5.5 Decoupling of User behavior from Connectivity = Assessment......8=20 5.6 Forward and Backward Defect = Indicators........................8=20 5.7 Connectivity = Verification.....................................9=20 5.8 Customers Should not be Used as Defect = Detectors.............10=20 5.9 The Reliability of OAM Functionality Under Fault = Conditions..10=20 6. Mechanisms of MPLS = OAM.......................................10=20 6.1 Special MPLS Label = Values....................................10=20 6.2 Handling of Errored OAM = Packets..............................10=20 6.3 Label Stack Overhead Encoding Rules for OAM = Packets..........11=20 6.3.1 For CV OAM = Packets...........................................11=20 6.3.2 For P OAM = Packets............................................12=20 6.3.3 For FDI and BDI OAM = Packets..................................12=20 6.3.4 MPLS OAM Function Types for the OAM Alert = Label..............13=20 6.4 MPLS OAM = Packets.............................................14=20 6.4.1 Connectivity Verification (CV) = Packets.......................15=20 6.4.2 Performance =93P=94 = Packets......................................16=20 6.4.3 Forward defect Indicator =93FDI=94 = packets.......................16=20 6.4.4 Backward Defect Indicator = =93BDI=94..............................17=20 6.5 Defect Types and their Entry/Exit = Criteria...................18=20 6.5.1 Defect Type = Codepoints.......................................18=20 6.5.2 dLOCV Entry = Criteria.........................................20=20 6.5.3 DTTSI Entry = Criteria.........................................21=20 6.5.4 dLoop Entry = Criteria.........................................21=20 6.5.5 dLOCV, dTTSI and dLoop exit = criteria.........................22=20 6.6 Available and unavailable state = processing...................23=20 =20 Harrison et. al. Expires August 2001 Page 2 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 6.6.1 Short Break = definition.......................................23=20 6.6.2 Available/Unavailable State = Definition.......................24=20 6.6.3 Near-end and Far-end Measurements of = Availability............24=20 6.6.4 Near-End State Processing = Flow-chart.........................25=20 6.6.5 Far-End State Processing = Flow-chart..........................27=20 6.6.6 A pictorial view of near-end and far-end state = processing....28=20 7. Security = Considerations......................................29=20 8. = References...................................................29=20 9. Author's = Addresses...........................................29=20 =20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [1].=20 =20 =20 1. Introduction=20 =20 This Internet draft provides requirements and mechanisms for OAM=20 (Operation and Maintenance) for the user-plane in MPLS networks. It=20 is recognized that OAM functionality is important in public networks = for ease of network operation, for verifying network performance and = to reduce operational costs. OAM functionality is especially=20 important for networks, which are required to deliver (and hence be=20 measurable against) QoS (Quality of Service) and availability=20 performance parameters/objectives.=20 =20 A connectivity verification "CV" OAM packet is defined in this=20 document, which is transmitted periodically from LSP source to LSP=20 sink. The CV flow could be used to detect defects related misrouting = of LSPs as well as link and nodal failure, and if required to=20 trigger protection switching to the protection path. A forward=20 defect identifier "FDI" and a backward defect identifier "BDI" are=20 defined, which carry the defect type and location to the near end=20 and far end respectively. At every LSP terminating node, the FDI is=20 mapped from server layer to client layer. By doing so FDI could=20 suppress the alarm storm, and let the appropriate layer take control = of protection switching. BDI is used by LSP source to start or stop=20 the QoS aggregation, depending on whether the LSP is in available or = unavailable state. The criteria for entry and exit to the available=20 and unavailable states are also defined in this document.=20 =20 The OAM functionality defined herein is limited to point-point LSP=20 tunnels. OAM functionality for multipoint-point and point-multipoint = LSP tunnels is FFS.=20 =20 =20 Harrison et. al. Expires August 2001 Page 3 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 =20 2. Definitions=20 =20 This document introduces some new terminology, which is required to=20 discuss the functional network components associated with OAM.=20 =20 =20 Functional Architecture Meaning=20 Term =20 ------------------ ------------------=20 =20 Client/server A term referring to the transparent=20 (relationship between transport of a client (ie higher)=20 layer networks) layer link connection by a server=20 (ie lower) layer network trail.=20 =20 Link connection A partition of a layer N trail that=20 exists between two logically=20 adjacent switching points within the = layer N network.=20 =20 LSP Tunnel An LSP Tunnel is an LSP with well- defined source (ingress point) and=20 sink (egress point)=20 =20 Subnetwork A subnetwork is a contiguous=20 topological region of a network=20 delimited by its set of peripheral=20 access points, and is characterized=20 by the possible routing across the=20 subnetwork between those access=20 points. A network is the largest=20 subnetwork and a node is the=20 smallest subnetwork (at least in=20 practical physical terms, though=20 there are smaller sub-networks=20 within nodes).=20 =20 Trail A generic transport entity at layer=20 N which is composed of a client=20 payload (which can be a packet from=20 a client at higher layer N-1) with=20 specific overhead added at layer N=20 to ensure the forwarding integrity=20 of the server transport entity at=20 layer N.=20 =20 Trail termination point A source or sink point of a trail at = layer N, at which the trail overhead = is added or removed respectively. A = trail termination point must have a=20 unique means of identification=20 within the layer network.=20 =20 =20 Harrison et. al. Expires August 2001 Page 4 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 =20 =20 3. Symbols and Abbreviations=20 =20 This list is not exhaustive of all the abbreviations used in this=20 draft. In particular, those in common usage within the MPLS=20 community (like 'MPLS' itself) have been excluded.=20 =20 =20 Abbreviation Meaning=20 --------------- ----------------------------=20 AIS Alarm Indication Signal=20 =20 BDI Backward Defect Indication=20 =20 CV Packet Connectivity Verification Packet=20 =20 FDI Forward Defect Indication=20 =20 FFS For Further Study=20 =20 OAM Operations and Maintenance=20 =20 P Packets Performance Packets=20 =20 QoS Quality of Service=20 =20 SLA Service Level Agreement=20 =20 TTSI Trail Termination Source Identifier=20 =20 =20 =20 4. Requirements for MPLS OAM=20 =20 MPLS layer OAM functionality is not a substitute for physical or=20 server layer OAM (e.g., SDH/SONET) or client layer OAM (e.g., IP).=20 MPLS LSPs create layer networks in their own right, and will have=20 defects that are only relevant to the MPLS LSP layer networks. =20 =20 OAM functionality is useful because:=20 =20 1) It allows the Operator to verify whether Quality of Service=20 guarantees given in SLAs (Service Level Agreements) are in fact = being met by the connection.=20 2) It allows the Operator to reduce network=92s operating costs, = by=20 allowing more efficient detection and handling of defects.=20 Long-term statistics show that the costs of operating a public=20 network are higher than the initial installation costs.=20 3) It gives support for improved accounting/billing procedures.=20 4) It helps provide security for customer traffic by the detection = of traffic mis-connections (which may otherwise be=20 undetectable).=20 =20 =20 Harrison et. al. Expires August 2001 Page 5 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 The following functions are required:=20 =20 1) Connectivity Verification of LSPs to confirm that defects do=20 not exist on the target LSPs.=20 2) Fast and efficient defect detection, notification and=20 localization.=20 3) Measurement of availability performance.=20 =20 The necessity of additional functions are for further study. In=20 particular, the need for in-service measurement of LSP QoS=20 performance (measurement of packet losses, spurious packets, errored = packets, delay and delay variation) is for further study. Note that=20 an LSP needs to be in the available state for QoS assessment to be=20 valid.=20 =20 Defects include following cases:=20 =20 1) Simple loss of LSP connectivity (due to a server layer failure=20 or a failure within the MPLS layer network);=20 2) Swapped LSP trails;=20 3) Unintended LSP mismerging (of 2 or more LSP trails);=20 4) Unintended replication of LSP packets (of the same LSP trail=20 for example, due to routing loops).=20 =20 =20 5. Principles of OAM Function=20 =20 The following principles can, for the most part, be applied to any=20 layer networks, ie not just MPLS. This recommendation defines=20 specific embodiments of these principles, as functional OAM=20 entities, for MPLS layer networks. Although it is recommended that=20 all the OAM functional entities are deployed network-wide, operators = are free to choose if they wish to apply all or only some of these=20 OAM functional entities (ie CV flows but not P flows), and whether=20 deployment is network-wide or limited in scope to LSPs of certain=20 types, e.g. apply only to important LSPs such as those supporting=20 VPNs. In cases of limited OAM functional entity deployment or scope, = then operators should be aware that there could be deficiencies in=20 their ability to detect/handle certain defect cases.=20 =20 =20 5.1 Client/Server Recursion-Layering=20 =20 A very important functional architecture feature of layer networks=20 is client/server recursion (also known as layering). That is, a=20 client layer link connection (ie a partition of a longer client=20 layer trail between two logically adjacent client layer nodes) is=20 created by a server layer trail. This is the basis of client layer=20 topology construction. This recursion principle extends between=20 various client/server layer relationships and ultimately 'to the=20 duct'. Note also that client layer link connections can be multiple=20 in number, ie a single server layer trail entity can support a=20 multiple number of client layer link connections.=20 =20 =20 Harrison et. al. Expires August 2001 Page 6 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 The key points to note here are:=20 =20 (1) The client and server layer trails termination points will=20 generally not be congruent. And since the trail termination=20 points are associated with the addressable access points of a=20 layer network, it follows that the addressing of the two layers = will also generally not be congruent.=20 (2) The 'duct' (or more precisely the environment of physical=20 occupancy and connectivity) is the lowest layer network. The=20 degree of connectivity in this layer effectively defines the=20 degree of independent connectivity in all client layers. This=20 could be put another way, by saying that the availability=20 performance of any client layer network design is determined=20 (and inherited from) the physical infrastructure. This means=20 that if one cannot state which link connections have a common=20 lower server layer trail, then one cannot say anything with=20 certainty about the resilience design of a client layer=20 network.=20 =20 =20 5.2 OAM Functionality and Layer Independence=20 =20 The OAM functionality of a layer network must not be dependent on=20 any specific server or client layer technology. This is critical to=20 ensure that layer networks can evolve (or new/old layer networks be=20 added/removed) without impacting other layer networks.=20 =20 The control-plane of a given layer network must also have its own=20 OAM.=20 =20 [Note - Control-plane OAM is outside the scope of this draft.]=20 =20 =20 5.3 Defects=20 =20 All the major defect conditions must be identified with in-service=20 measurable entry and exit criteria, and all consequent actions must=20 be specified. The entry and exit criteria of various defects should = be temporally harmonized as far as possible to simplify trail=20 defect-state processing. Attention should be paid to relating the=20 defect entry/exit criteria to =91short-breaks=92, which are = generally=20 accepted by many operators as 3-9s periods of gross signal=20 disturbance from which the network may self-recover. If the event=20 lasts for >=3D10s this is the normally accepted threshold for = entering=20 the unavailable state (also see the next item).=20 =20 =20 5.4 Availability=20 =20 The most important performance metric of a trail (or a subnetwork=20 partition thereof) is availability. This means that the entry and=20 exit criteria for the available state must be defined. It is also=20 important to understand how unavailable/available state transitions=20 relate to the stopping/starting of the aggregation of available=20 =20 Harrison et. al. Expires August 2001 Page 7 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 state QoS metrics; noting that from pragmatic considerations this=20 may be effectively applied at an earlier point to preserve the=20 integrity of the available state metrics, e.g. after 3s say, which=20 marks the onset of (at least) a short-break, and which from=20 operational experience is a good practical rule-of-thumb for setting = a point beyond which a network is unlikely to self-recover.=20 =20 =20 5.5 Decoupling of User behavior from Connectivity Assessment=20 =20 User traffic behavior must not be a factor in connectivity status=20 assessment. In practical terms, this means decoupling user traffic=20 behavior from all defects and (the dependent) available state=20 entry/exit criteria.=20 =20 =20 5.6 Forward and Backward Defect Indicators=20 =20 The node in the layer network, which first detects a defect (sourced = from within that layer), should apply a well-known 'Forward Defect=20 Indication' (FDI) signal in the downstream direction. In the=20 majority of current transport network technologies such a signal has = been termed AIS (Alarm Indication Signal). At the trail termination=20 point where the appropriate FDI signal is generated:=20 =20 (1) There should be a complimentary Backward Defect Indication=20 (BDI) signal (which is removed at the upstream trail=20 termination point) and=20 (2) There must be a mapping of the FDI signal from the server layer = to the appropriate FDI signal of the client layer(s) as part of = the server->client adaptation process.=20 =20 The primary purpose of the FDI signal is to suppress client layer=20 alarms (which would otherwise create an 'alarm storm' in places=20 which could be geographically and organizationally far removed from=20 the originating defect source location).=20 =20 Three secondary purposes of FDI (and in some cases BDI) are:=20 =20 (1) To allow correct processing of available state performance=20 metrics.=20 (2) To inform applications that the connection is no longer=20 functioning correctly and to take appropriate action, e.g.=20 perhaps invoke a 're-connect' action, or in the case of voice=20 perhaps mute the speech path.=20 (3) To inform client layer trails (e.g. nested LSPs in the case of=20 MPLS) that a defect has occurred in a lower server layer trail, = and hence to provide some indication that protection-switching=20 in the affected client layer trails could be postponed to give=20 the server layer trail an opportunity to effect protection=20 switching.=20 =20 FDI/BDI signals should also provide information on the defect=20 location and type. Such information is very useful to the lead=20 =20 Harrison et. al. Expires August 2001 Page 8 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 operator in a co-operating domain scenario, and can also=20 differentiate failures, which are internal or external to public and = private domains.=20 =20 Note that, if being used, the BDI signal must be generated (in the=20 backward direction) in response to detecting a defect at a trail=20 sink termination point (in the forward direction) and not from some=20 intermediate point, such as where the defect might be actually=20 located. The reasons for this are that:=20 =20 (1) In the case of bi-directional trails and unidirectional=20 defects, each trail direction might not be congruently routed.=20 (2) In the case of unidirectional trails the BDI signal may be=20 provided out-of-band, e.g. perhaps via a control-plane or=20 management-plane mechanism. [Note: The exact means for=20 providing the BDI functionality in this is FFS]=20 =20 The above requirements mean that the FDI/BDI architecture is valid=20 for all routing cases.=20 =20 =20 5.7 Connectivity Verification=20 =20 An essential characteristic of the trails in a layer network is that = their trail termination points must have a unique identifier (at=20 least within that layer network). However, on link connections=20 between nodes within the layer network, relative identifiers are=20 commonly used for traffic forwarding. These relative identifiers=20 only have to be unique per interface, e.g. the VPI/VCI of ATM, the=20 DLCI of FR, the =91label=92 of MPLS.=20 =20 When relative identifiers are used for traffic forwarding there is a = possibility of trail misconnectivity due to defects. These cover a=20 variety of connectivity failure modes, including:=20 =20 1) Simple loss of continuity (due to a server layer failure or a=20 failure within the layer network considered);=20 2) Swapped connections;=20 3) Unintended mismerging (of 2 or more trails);=20 4) Unintended replication (of the same trail due, for example, to=20 routing loops).=20 =20 Although some of these defects may be rare in practice, unless=20 detected/corrected their consequences can be very severe for an=20 operator; ranging from simple availability/QoS SLA violations=20 through to more serious security, censorship and mis-billing=20 implications.=20 =20 It is therefore required that a unique trail source identifier be=20 periodically transmitted from the trail source to the trail sink to=20 detect these types of defect.=20 =20 =20 =20 Harrison et. al. Expires August 2001 Page 9 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 5.8 Customers Should not be Used as Defect Detectors=20 =20 The OAM tools provided should ensure (as far as reasonably=20 practicable) that customers should not have to act as failure=20 detectors for the operator.=20 =20 =20 5.9 The Reliability of OAM Functionality Under Fault Conditions=20 =20 Under fault conditions a layer network cannot, by definition, be=20 expected to behave in a predictable manner. Therefore care should be = exercised when specifying and using OAM functions that require a=20 layer network to function in a reliable and predictable manner for=20 fault diagnosis.=20 =20 =20 6. Mechanisms of MPLS OAM=20 =20 =20 6.1 Special MPLS Label Values=20 =20 The label structure defined in [1] indicates a single label field of = 20 bits. Label field values 0-3 have already been reserved for=20 special functions. A special label, the 'OAM Alert Label', is=20 defined as follows:=20 =20 Table 1: OAM Alert Label=20 =20 Label value =20 (Decimal) Meaning=20 ------------ -----------------------=20 4 OAM Alert Label. This indicates that the=20 first octet following the OAM Alert Label=20 [Note: this value is in the OAM payload (ie octet 5) is an OAM=20 yet to be officially Function Type field whose value defines=20 assigned by IANA] the type of defect handling OAM function=20 (ie CV, P, FDI or BDI), which follows in=20 the payload area.=20 =20 =20 All OAM packets must have a minimum payload length of 40 octets to=20 facilitate ease of processing. This is achieved by padding with all = 0s when necessary. All padding bits are reserved for future operator = defined usage. =20 =20 =20 6.2 Handling of Errored OAM Packets=20 =20 Each OAM packet uses a BIP16 (in the last two octets of the OAM=20 payload area) to detect errors. The BIP16 is computed over all the=20 fields of the OAM payload, including the initial octet, which=20 =20 Harrison et. al. Expires August 2001 Page 10 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 specifies the Function Type and the BIP16 bit positions (which are=20 all pre-set to zero for initial calculation purposes).=20 =20 BIP16 processing must be performed on all OAM packets prior to being = able to reliably pass their payload for further processing. Any OAM = packets that show a BIP16 violation upon reception processing should = be discarded.=20 =20 In the case of the CV packet flow, persistent BIP16 violations will=20 cause a Loss of Connectivity Verification; this defect is defined=20 later, but for now we can note that it would occur after nominally=20 3s. This behavior is consistent with the nature of the defect. =20 However, it is recommended that at a local equipment level some=20 notification is given to the Network Management System to indicate=20 that BIP16 discards are occurring.=20 =20 In the case of the other OAM packet types, ie the FDI, BDI and P=20 packets (these are defined later), it is again recommended that at a = local equipment level some indication is given to the Network=20 Management System that BIP16 discards are occurring. The threshold=20 to be used for recording/reporting such BIP16 discard activity for=20 these OAM packets should be programmable, and is outside the scope=20 of this Recommendation.=20 =20 =20 6.3 Label Stack Overhead Encoding Rules for OAM Packets=20 =20 =20 6.3.1 For CV OAM Packets=20 =20 CV OAM packets are differentiated from normal user-plane traffic by=20 an increase of one in the label stack depth at a given LSP level at=20 which they are inserted. Therefore, they maintain this label stack=20 difference of one (from normal user-plane traffic) as they traverse=20 any lower layer server LSPs.=20 =20 The OAM Alert Labeled header is added before (ie below) the normal=20 user-plane forwarding labeled header at the LSP trail source point. = The S bit is set only in the OAM Alert Label.=20 =20 The CV OAM packet can be used on both E-LSPs and L-LSPs. However,=20 the coding of the EXP field is different in the two cases.=20 In the case of L-LSPs, the coding of the EXP field should be set to=20 all 0s in both the OAM Alert Labeled header and the preceding normal = user-plane forwarding header. This is to ensure the CV OAM packets=20 have a Per Hop Behavior (PHB), which ensures the lowest drop=20 probability [2].=20 =20 In the case of E-LSPs, the coding of the EXP field should be set to=20 all 0s in the OAM Alert Labeled header and to whatever is the=20 'minimum loss-probability PHB' in the preceding normal user-plane=20 forwarding header for that E-LSP. This is again to ensure the CV=20 OAM packets have a PHB, which ensures the lowest drop probability=20 [2].=20 =20 Harrison et. al. Expires August 2001 Page 11 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 =20 The TTL field should be set to 1 in the OAM Alert Labeled header. =20 The reasons for this are:=20 =20 =B7 CV OAM packets should never travel beyond the LSP trail=20 termination sink point at the LSP level they were originally=20 generated (noting that they are not examined by intermediate=20 label-swapping LSRs, and are only observed at LSP sink points), = and=20 =B7 The TTL of the immediately prior normal user-plane forwarding = header is used to mitigate against damage from looping packets. = =20 =20 6.3.2 For P OAM Packets=20 =20 The label stack overhead encoding rules of performance P OAM packets = are FFS.=20 =20 =20 6.3.3 For FDI and BDI OAM Packets=20 =20 FDI and BDI OAM packets are invoked, on a nominal 1 per second=20 basis, when defects are detected. The FDI packet traces forward and=20 upward through any nested LSP stack. The BDI packet is sent=20 backwards towards its peer-level LSP trail termination sink point in = the reverse direction (assuming a bi-directional in-band LSP exists) = for each LSP at and above the level of the defect.=20 =20 The OAM Alert labeled header is inserted before (ie below) a normal=20 user-plane forwarding labeled header, and a label stack of 2 is only = ever required for either the FDI or BDI packet at their origin. =20 Note that in the case of FDI, it is assumed that the server->client=20 LSP adaptation mappings that were in existence prior to the failure=20 are recursively used to ensure correct FDI forwarding. It is=20 therefore important that the LSP sink point remembers any server- >client LSP labels mappings that were in existence prior to the=20 failure. Although the exact means for achieving this are outside=20 the scope of this Recommendation, some examples of how these server- > client layer label mappings could be configured are as follows:=20 =20 =B7 Manually, via the NMS say;=20 =B7 Automatically on LSP set-up via extensions to LDP/RSVP=20 signaling;=20 =B7 By an automatic 'learning process', i.e. if, during the=20 establishment of the client LSPs, the signaling is tunneled=20 trough the server layer, then the server trail terminating node = could keep the information about the established LSPs in memory = as they occur.=20 =20 When server->client layer LSP relationships are changed (e.g.=20 existing client layer LSP removed, or new client LSP added say),=20 then it is important that the server->client label mappings are also = updated to reflect the new relationships.=20 =20 =20 Harrison et. al. Expires August 2001 Page 12 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 The S bit is set only in the OAM Alert Labeled header. The FDI OAM=20 packet is recursively mapped upwards, through a client/server=20 adaptation process at LSP trail termination sink points, into any=20 further affected higher client layer LSPs. When this arrives at the = top LSP it needs to be mapped into an equivalent FDI for whatever=20 client layer is then being carried. In the case of IP (or indeed=20 any other client layer), this is outside the scope of this document. = =20 Note that higher level LSPs will also see failures (as a result of=20 corruption of their own CV flow) but they will also see an incoming=20 FDI OAM packet flow from the lowest level LSP where the failure=20 originates. This dynamic behavior allows for correct identification = of the true source of the defect and is explained in more detail=20 later. But for now it is sufficient to note that the incoming FDI=20 is needed to:=20 =20 =B7 Suppress unnecessary alarms in the affected higher layer = LSPs.=20 =B7 Give an indication to affected higher-level LSPs that they = may=20 need to hold-off protection switching as the defect is at a=20 lower level LSP.=20 =B7 To allow the appropriate BDI coding at the affected higher=20 layer.=20 =20 It is assumed that when a BDI OAM packet is returned in-band it=20 follows a bi-directional LSP and, like the CV and P OAM packets,=20 that it should never travel beyond the LSP trail termination sink=20 point (of the return LSP).=20 =20 The coding of the EXP field associated with the OAM Alert Labeled=20 header and the preceding normal user-plane forwarding labeled header = at the LSP level at which the FDI or BDI is inserted is the same as=20 that previously described for the CV OAM packet.=20 =20 The TTL field should be set to 1 in the OAM Alert Labeled packet=20 header. The reasons for this are:=20 =20 =B7 The FDI OAM packet is recursively regenerated at each LSP = trail=20 termination sink point into all affected client layer LSPs (if=20 any); so the TTL field is recursively regenerated with a value=20 of 1;=20 =B7 The BDI OAM packet should never travel beyond the LSP trail=20 termination sink point of the return LSP at the LSP level that=20 it was originally generated;=20 =B7 The TTL of the immediately prior normal user-plane forwarding = header is used to mitigate against damage from looping packets. = =20 =20 6.3.4 MPLS OAM Function Types for the OAM Alert Label=20 =20 The first octet of the OAM packet payload specifies the OAM Function = Type as follows:=20 =20 Table 2: OAM Function Types=20 =20 =20 Harrison et. al. Expires August 2001 Page 13 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 OAM Function Type First octet of OAM packet payload=20 codepoint (Hex) Function Type Purpose=20 ----------------- ----------------------------------=20 00 Reserved=20 =20 01 CV (Connectivity Verification). Used=20 to detect/diagnose all types of LSP=20 connectivity defect (sourced either=20 from below or within the MPLS=20 network). This will be the main in- service OAM defect detection tool.=20 =20 02 P (Performance). Used to measure=20 user-plane loss of packets and their=20 aggregate octets.=20 =20 03 FDI (Forward Defect Indicator). This=20 is generated by an MPLS node detecting=20 any defect (defined later) and=20 inserted into affected client layers. =20 Its primary purpose is to suppress=20 alarms being raised within affected=20 higher level client LSPs and (in turn)=20 their client layers. It includes=20 fields to indicate the nature of the=20 defect and its location.=20 =20 04 BDI (Backward Defect Indicator). This=20 is generated at a return LSP trail=20 termination source point in response=20 to a defect being detected at a LSP=20 trail termination sink point in the=20 other direction. The defect type and=20 location codepoints of the=20 complimentary FDI are mapped into=20 similar fields of the BDI. The BDI=20 may be realized either in the user- plane if bi-directional LSPs are being=20 used (the case considered in this=20 document) or out-of-band (e.g. via=20 management-plane function) in the case=20 of uni-directional LSPs. The latter=20 scenario is outside the scope of this=20 document.=20 =20 =20 All other OAM Function Type codepoints are reserved for possible=20 future standardization.=20 =20 =20 6.4 MPLS OAM Packets=20 =20 =20 =20 Harrison et. al. Expires August 2001 Page 14 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 6.4.1 Connectivity Verification (CV) Packets=20 =20 0 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Func Type (1) | (must be 0) |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 + +=20 | Ingress Router ID |=20 + +=20 | |=20 + +=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | LSP ID |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 \\ Reserved (0) 14 bytes \\=20 | |=20 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | | BIP 16 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Figure 1: CV Payload Structure=20 =20 The intention is that the CV OAM packet is transmitted from the LSP=20 trail termination source point at a nominal rate of 1 CV per second. = =20 It is important that the rate of CV OAM packet generation is=20 constant so that simple and deterministic defect processing can be=20 carried out at the LSP trail termination sink point.=20 =20 CV OAM packets within a given LSP are not synchronous to any other=20 CV OAM packets in any other LSP (this includes all nested LSPs, and=20 CV OAM packets from the remote end of an LSP at level N but in the=20 other direction when bi-directional LSPs at level N are being used). = =20 The structure of the LSP Trail Termination Source Identifier (TTSI)=20 is defined by using a 16 octet Router ID IPv6 address plus a 4 octet = LSP Tunnel ID [3]. Note that the first 2 octets of the LSP Tunnel=20 ID are currently padded with all 0s to allow for any future increase = in the Tunnel ID field.=20 =20 For nodes that do not support IPv6 addressing, an IPv4 address can=20 be used for the Router ID using the format described in RFC1884 [4]. = =20 =20 Harrison et. al. Expires August 2001 Page 15 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 That is:=20 =20 0 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 + +=20 | (0) |=20 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | | (FF) |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | IPv4 Address |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Figure 2: IPV6 Compatible IPV4 Address=20 =20 On LSP establishment the LSP trail termination sink point should be=20 configured with the expected TTSI (Ingress router ID + LSP ID). =20 Ideally this should be done automatically via LSP signaling at LSP=20 set-up time (e.g. via a CR-LDP or RSVP control-plane mechanism), but = it could also be configured manually. The mechanism for achieving=20 this configuration is outside the scope of this Recommendation.=20 =20 =20 6.4.2 Performance =93P=94 Packets=20 =20 The structure of the P OAM packet is FFS.=20 =20 =20 6.4.3 Forward defect Indicator =93FDI=94 packets=20 =20 =20 0 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Func Type (3) | (must be 0) | Defect Type |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Defect Location |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 \\ Reserved (0) 30 bytes \\=20 | |=20 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | | BIP 16 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Figure 3: FDI Payload Structure=20 =20 The FDI is sent downstream from the first node detecting the defect. = =20 In the case of MPLS server layer failures (i.e. in a lower layer=20 technology such as SDH) this would be the first MPLS node downstream = of the server layer failure (as a consequence of the appropriate=20 client/server adaptation of the server FDI signal). In the case of=20 MPLS layer failures (i.e. failures within the MPLS fabric) this=20 =20 Harrison et. al. Expires August 2001 Page 16 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 would be the first LSP trail termination sink point at the same LSP=20 level as the failure.=20 =20 The primary function of the FDI is to stop downstream client layer=20 alarm storms and hence correctly focus the attention of Operational=20 personnel. However, FDI can also have an important role in:=20 =20 =B7 Facilitating correctly targeted nested LSP protection = schemes,=20 i.e. one would want a lower level (server) LSP to protection=20 switch before a higher level (client) LSP if the fault was=20 sourced from within the lower level LSP, and=20 =20 =B7 Identifying availability/short-break events and hence suspend = up-state QoS metric aggregation.=20 =20 The format of the Defect Location field and its handing at inter=20 domain NNI boundaries is FFS.=20 =20 The Defect Type field is set at 2 octets here. This is currently=20 considered sufficient, but it should be confirmed once all the=20 Defects Types have been identified and fully specified. A candidate=20 set of Defect Types and their codepoints are given later.=20 =20 The handling of the Defect Type field at inter domain NNI boundaries = is FFS. However, 2 octets have been reserved for this function.=20 =20 When a FDI is to be passed from a server layer LSP to its client=20 layer LSP(s) (ie at the client/server adaptation function following=20 the server layer LSP trail termination sink point), the Defect=20 Location and Defect Type field should be copied from the server=20 layer LSP FDI into the client layer LSP(s) FDI.=20 =20 The mapping of MPLS layer sourced FDI from the highest-level LSP=20 into its client layer (e.g. IP) is outside the scope of this=20 document.=20 =20 =20 6.4.4 Backward Defect Indicator =93BDI=94=20 =20 0 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Func Type (4) | (must be 0) | Defect Type |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Defect Location |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 \\ Reserved(0) 30 bytes \\=20 | |=20 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | | BIP 16 |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Figure 4: BDI Payload Structure=20 =20 Harrison et. al. Expires August 2001 Page 17 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 =20 For the case of bi-directional LSPs, the BDI is sent from the LSP=20 trail source point of the return LSP as a mirror of the appropriate=20 (see Note) FDI at the LSP trail sink point of the other direction. = =20 The Defect Location and Defect Type fields are a direct mapping of=20 those sets in the appropriate (see Note) FDI and have identical=20 formats as described previously for the FDI OAM packet.=20 =20 Note - The word 'appropriate' here signifies that any incoming FDI=20 (i.e. from a lower layer) takes precedence over any FDI that would=20 have been generated at the layer being considered due to detecting=20 defects at this layer (where these defects are only consequential as = a result of a lower layer defect).=20 =20 The BDI does not propagate beyond its return LSP trail termination=20 sink point, and it is discarded at that point after any processing=20 based its observation is carried out, e.g. for single-ended short- break and/or availability measurements.=20 =20 =20 6.5 Defect Types and their Entry/Exit Criteria=20 =20 6.5.1 Defect Type Codepoints=20 =20 The following coding structure is proposed for the various defect=20 types so far identified:=20 =20 Table 3: Defect Types=20 =20 DT code in FDI/BDI =20 OAM packets (Hex) =20 Note: first octet =20 indicates layer and =20 Defect second octet =20 Type indicates defect Meaning=20 ------- -------------------- ------------------------=20 dServer 01 01 Any server layer defect=20 arising below the MPLS layer=20 network. It is not suggested=20 that these are individually=20 identified and defined for=20 each type of server layer,=20 since this function is only=20 appropriate to the server=20 layer itself. Hence, we only=20 need an indication that it is=20 the server layer and not the=20 MPLS layer.=20 =20 dLOCV 02 01 Simple Loss of Connectivity=20 Verification due to missing=20 CV OAM packets with expected=20 TTSI. Note that if the cause=20 =20 Harrison et. al. Expires August 2001 Page 18 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 of dLOCV is the server layer=20 (ie there is also an incoming=20 FDI signal from the server=20 layer) then the DT codepoint=20 01 01_H is used. The dLOCV=20 codepoint 02 01_H is only=20 used for MPLS layer simple=20 connectivity failures only.=20 =20 dTTSI 02 02 Trail Termination Source=20 Identifier Mismatch due to an=20 unexpected TTSI observed in=20 the incoming CV OAM packets. =20 This detects swapped=20 connections and unintended=20 mismerging failures, which=20 can be differentiated by=20 noting whether an expected=20 TTSI is also missing or=20 present respectively. Note=20 that in the case of the=20 former (ie swapped=20 connections), the dTTSI=20 defect condition takes=20 priority over the dLOCV=20 defect condition, which is=20 also present.=20 =20 dLoop 02 03 This detects an unintended=20 replication Looping defect=20 from observation of an=20 increased rate of expected CV=20 OAM packets above the nominal=20 1/sec. (Note this defect is=20 added for completeness, but=20 it is expected to be rare)=20 =20 dUnknown 02 FF Unknown defect detected in=20 the MPLS layer. This is=20 expected to be used for MPLS=20 nodal failures, which are=20 detected within the node=20 (probably by proprietary=20 means) and affect user-plane=20 traffic.=20 =20 None 00 00 Reserved=20 =20 None FF FF Reserved=20 =20 =20 There are 3 MPLS layer user-plane defects, ie dLOCV, dTTSI and=20 dLoop, which we now define in more detail.=20 =20 =20 Harrison et. al. Expires August 2001 Page 19 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 =20 6.5.2 dLOCV Entry Criteria=20 =20 Entry to the dLOCV condition, and hence entry to the LSP Trail Sink=20 Near-End Defect State, occurs when there are no expected CV OAM=20 packets observed in any period of 3 consecutive seconds.=20 =20 In terms of consequent actions:=20 =20 =B7 If there is an incoming FDI signal from a server layer below=20 the MPLS network, then this is mapped to the DT codepoint 01=20 01_H in the FDI OAM packets sent forwards and the BDI OAM=20 packets sent backwards. The local DL codepoint is also=20 inserted in these FDI and BDI OAM packets. There are no alarms=20 associated with the MPLS layer itself but only the server=20 layer, which sourced the FDI signal.=20 =20 Else:=20 =20 =B7 If there is an incoming FDI signal from a lower level LSP=20 within the MPLS network, then that FDI signal's DL/DT=20 codepoints are mapped into the FDI sent to any further client=20 layers (i.e. suppresses generation of FDI DL/DT codepoints from = this point) and the BDI OAM packet sent backwards. There are=20 no alarms generated regarding this LSP (the alarm will be=20 associated with the lowest layer LSP within which the defect=20 originated).=20 =20 Else:=20 =20 =B7 If there is no FDI signal incoming from the server layer or a = lower level LSP AND there are no CV OAM packets observed with=20 an unexpected TTSI which give rise to the dTTSI defect, then=20 the DT codepoint 02 01_H is inserted in the FDI OAM packets=20 sent downstream and the BDI OAM packets sent upstream. The=20 local DL codepoint is also inserted in these FDI and BDI OAM=20 packets. A local alarm is raised relevant to this defect=20 condition.=20 =20 Note:=20 =20 (i) Since OAM packet flows are not synchronized in LSPs at=20 different hierarchical levels (ie when LSPs are nested), = there is a possibility that a client layer LSP detects a = defect before its server layer LSP. This error could be=20 up to 1s due to CV packet arrival time differences plus=20 some additional uncertainty due to network delay=20 effects. This could result in an error of judgment as to = the type of defect that is present and hence which=20 consequent actions are appropriate; especially whether=20 the raising of a local alarm is appropriate and the=20 correct setting of the DL and DT codepoints in FDI/BDI=20 OAM packets. To mitigate this effect, it is recommended = that the raising of an alarm is deferred for at least 2=20 =20 Harrison et. al. Expires August 2001 Page 20 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 seconds after a defect state is detected (the exact=20 value is FFS). This will also allow the network to=20 settle into a stable state as regards defect detection=20 behavior.=20 =20 (ii) The starting/stopping of aggregation of any LSP user- plane packet/octet loss metrics (e.g. if using the P OAM = packet say) is dependent on whether the LSP is in the=20 available or unavailable state.=20 =20 =20 6.5.3 DTTSI Entry Criteria=20 =20 Entry to the dTTSI condition, and hence entry to the LSP Trail Sink=20 Near-End Defect State, occurs when there are >=3D 2 CV OAM packets=20 observed in any period of 3 consecutive seconds each with an=20 unexpected TTSI. Any expected CV OAM packets or any incoming FDI=20 signals (from either the server layer or a lower level LSP) are=20 ignored, and it should be noted that the dTTSI defect overrides the=20 dLOCV defect if both are present (as would be the case, for example, = with swapped LSPs). The DT codepoint 02 02_H is inserted in the FDI=20 OAM packets sent forwards and the BDI OAM packets sent backwards. =20 The local DL codepoint is also inserted in these FDI and BDI OAM=20 packets. A local alarm is raised relevant to this defect condition=20 and the unexpected TTSI captured locally (this may also be=20 optionally sent to the NMS as an exception report say). The=20 downstream traffic must also be suppressed.=20 =20 Note:=20 =20 (i) Since OAM packet flows are not synchronized in LSPs at=20 different hierarchical levels (ie when LSPs are nested), there=20 is a possibility that a client layer LSP detects a defect=20 before its server layer LSP. This error could be up to 1s due=20 to CV packet arrival time differences plus some additional=20 uncertainty due to network delay effects. This could result in=20 an error of judgment as to the type of defect that is present=20 and hence which consequent actions are appropriate; especially=20 whether the raising of a local alarm is appropriate and the=20 correct setting of the DL and DT codepoints in FDI/BDI OAM=20 packets. To mitigate this effect, it is recommended that the=20 raising of an alarm is deferred for at least 2 seconds after a=20 defect state is detected (the exact value is FFS). This will=20 also allow the network to settle into a stable state as regards = defect detection behavior.=20 =20 (ii) The starting/stopping of aggregation of any LSP user-plane=20 packet/octet loss metrics (e.g. if using the P OAM packet say)=20 is dependent on whether the LSP is in the available or=20 unavailable state.=20 =20 =20 6.5.4 dLoop Entry Criteria=20 =20 =20 Harrison et. al. Expires August 2001 Page 21 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 Entry to the dLoop condition, and hence entry to the LSP Trail Sink=20 Near-End Defect State, occurs when there are >=3D 5 CV OAM packets=20 observed in any period of 3 consecutive seconds each with an=20 expected TTSI. The DT codepoint 02 03_H is inserted in the FDI OAM=20 packets sent forwards and the BDI OAM packets sent backwards. The=20 local DL codepoint is also inserted in these FDI and BDI OAM=20 packets. A local alarm is raised relevant to this defect condition.=20 =20 Note:=20 =20 (i) Since OAM packet flows are not synchronized in LSPs at=20 different hierarchical levels (ie when LSPs are nested), there=20 is a possibility that a client layer LSP detects a defect=20 before its server layer LSP. This error could be up to 1s due=20 to CV packet arrival time differences plus some additional=20 uncertainty due to network delay effects. This could result in=20 an error of judgment as to the type of defect that is present=20 and hence which consequent actions are appropriate; especially=20 whether the raising of a local alarm is appropriate and the=20 correct setting of the DL and DT codepoints in FDI/BDI OAM=20 packets. To mitigate this effect, it is recommended that the=20 raising of an alarm is deferred for at least 2 seconds after a=20 defect state is detected (the exact value is FFS). This will=20 also allow the network to settle into a stable state as regards = defect detection behavior.=20 =20 (ii) The starting/stopping of aggregation of any LSP user-plane=20 packet/octet loss metrics (e.g. if using the P OAM packet say)=20 is dependent on whether the LSP is in the available or=20 unavailable state.=20 =20 =20 6.5.5 dLOCV, dTTSI and dLoop exit criteria=20 =20 Exit of the dLOCV, dTTSI or dLoop condition, and hence exit of the=20 LSP Trail Sink Near-End Defect State, occurs when there are:=20 =20 =B7 >=3D 2 but <=3D 4 CV OAM packets observed each with an = expected=20 TTSI, AND=20 =B7 No CV OAM packets observed with an unexpected TTSI in any=20 period of 3 consecutive seconds.=20 =20 Note that the numbers of CV OAM packets observed each with an=20 expected TTSI are a suggested number. It must be further studied if=20 these numbers are appropriate.=20 =20 All the consequent actions invoked when entering the LSP Trail Sink=20 Near-End Defect State (i.e. sending of FDI and BDI OAM packets, the=20 raising of local alarms and the suppression of traffic in the dTTSI=20 case only) are stopped when we exit the LSP Trail Sink Near-End=20 Defect State.=20 =20 Note =96 The starting/stopping of aggregation of any LSP user-plane=20 packet/octet loss metrics (e.g. if using the P OAM packet say) is=20 =20 Harrison et. al. Expires August 2001 Page 22 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 dependent on whether the LSP is in the available or unavailable=20 state.=20 =20 =20 6.6 Available and unavailable state processing=20 =20 The main purpose of defining harmonized defect entry/exit criteria=20 as noted above is in order to significantly simplify:=20 =20 =B7 Near-end/far-end LSP Trail Sink Defect State processing;=20 =B7 Near-end/far-end LSP Available State processing (which will=20 shortly be discussed);=20 =B7 The decision point at which any LSP user-plane traffic QoS=20 metrics (if being collected) are stopped/started with respect=20 to aggregation into long-term registers.=20 =20 In all sections where the evaluation of events is described, the=20 measurement technique is based on a sliding-window with a 1 second=20 granularity of advance. Note that the datum for the commencement of = the sliding window is an arbitrary point in time decided by the each = node independently and is not synchronized to OAM packet arrival=20 events on any LSPs. This is deemed acceptable to allow simpler=20 nodal processing.=20 =20 It should be noted that this Recommendation uses the traditional=20 functional dependency relationship between QoS and availability. =20 That is:=20 =20 =B7 QoS is a unidirectional metric, ie if QoS metrics are being=20 measured then each direction is measured independently.=20 =B7 Availability is a bi-directional metric in the case of bi- directional LSPs, in the sense that if any direction enters the = unavailable state (defined later) then both directions are=20 deemed to be unavailable. In the case of unidirectional LSPs,=20 then availability can only have unidirectional significance.=20 =B7 QoS measurements must be suspended (as regards aggregation = into=20 long-term available state registers) if an LSP enters the=20 unavailable state; noting that this means the QoS measurements=20 of both directions from the definition of the availability=20 metric above in the case of bi-directional LSPs.=20 =20 However, it should also be noted that (for both pragmatic reasons=20 and to preserve their statistical significance) QoS metric=20 aggregation is actually suspended after detecting a short-break=20 event.=20 =20 =20 6.6.1 Short Break definition=20 =20 We first define a short-break event. This is defined as a period=20 where the entry and exit to any of the previously defined defect=20 conditions both occur within 9s, ie the LSP Trail Sink Near-End=20 Defect State lasts for <=3D 9s. The start of the short-break occurs = at the beginning of the defect entry criteria and the end of the=20 =20 Harrison et. al. Expires August 2001 Page 23 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 short-break occurs at the beginning of the defect exit criteria. =20 Clearly this has a minimum period of 3s. Short-breaks are only=20 defined to exist when the LSP is in the Available State.=20 =20 Note =96 Short-breaks are more common than many people realize (in = one=20 operator's network a study of SES (Severely Errored Second) events=20 showed that about 50% of these would have been classified as short- breaks). They can cause severe disruption to some applications and=20 are therefore an important performance metric (perhaps second in=20 importance after availability). Since they exist at the physical=20 layers they will exist (by inheritance) in client layers, such as=20 MPLS and IP. An important property of the short-break, which we=20 will exploit, is that it yields a pragmatic harmonized threshold for = defect evaluation (across all defect types as noted previously) and=20 the stopping/starting of QoS metric aggregation into long-term up- state performance registers.=20 =20 =20 6.6.2 Available/Unavailable State Definition=20 =20 If the LSP Trail Sink Near-End Defect State exceeds 10 consecutive=20 seconds in duration then the LSP enters the Unavailable State. The=20 start point of the Unavailable State is deemed to be at the=20 beginning of these 10 consecutive seconds. We therefore no longer=20 have a short-break (and the event should not be registered as such). = =20 A LSP re-enters the Available State after first exiting the LSP=20 Trail Sink Near-End Defect State and there has been an aggregate=20 period of 10 consecutive seconds in which there have been:=20 =20 =B7 >=3D9 and <=3D 11 CV OAM packets each with an expected TTSI, = AND=20 =B7 No CV OAM packets with an unexpected TTSI.=20 =20 Note that the numbers of CV OAM packets observed each with an=20 expected TTSI are suggested numbers. It must be further studied if=20 these numbers are appropriate.=20 =20 The start point of the Available State is deemed to be at the=20 beginning of these 10 consecutive seconds.=20 =20 6.6.3 Near-end and Far-end Measurements of Availability=20 =20 All of the above discussion is strictly only relevant to the near- end processing when the LSP trail termination sink point is in the=20 LSP Trail Sink Near-End Defect State as discussed previously. We=20 can also measure the far-end availability behavior (useful when only = a single end is accessible for measurement) by using the BDI signal=20 (when bi-directional LSPs are being used) since this is a reflected=20 upstream mirror of the duration over which FDI is sent downstream.=20 =20 We therefore define the LSP Trail Sink Far-End Defect State to be=20 the period over which BDI OAM packets are observed subject to the=20 following entry and exit criteria:=20 =20 Harrison et. al. Expires August 2001 Page 24 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 =20 =B7 Entry of the LSP Trail Sink Far-End Defect State occurs on = the=20 first BDI OAM packet observed.=20 =B7 Exit of the LSP Trail Sink Far-End Defect State occurs after = a=20 period of 3 consecutive seconds in which no BDI OAM packets=20 have been received.=20 =20 Note that this 3s processing delay on exit is to cater for cases in=20 which perhaps a single BDI is lost (say due to congestion or=20 errors). Its effect must be catered for in the far-end processing=20 state machine as discussed later.=20 =20 Since we have fixed the temporal duration of the far-end state to be = directly related to the near-end state (albeit with a +3s exit=20 checking period) we can therefore measure both short-breaks and=20 unavailability of both directions from a single end (on the=20 assumption that bi-directional LSPs are being used).=20 =20 =20 6.6.4 Near-End State Processing Flow-chart=20 =20 The following figure summarizes many of the key points regarding the = near-end state-processing algorithm for a given LSP.=20 =20 Figure 5: LSP Near-End State Processing Flow Chart=20 =20 1. Assume we start in the available state in the box marked=20 =91Start=92. All timers (shown later) can conceptually be = assumed=20 reset at this point. If there are any QoS metrics being=20 collected (e.g. packet/octet loss measurements from the P OAM=20 packet) then this is assumed to be active at this time.=20 2. The first decision box is =91dLOCV, dTTSI or dLoop?=92. These=20 defects were defined previously. If none of these defects are=20 present we keep checking for this condition and stay in the=20 available state. However, if one of these defects is present=20 we enter the Trail Sink Near-End Defect State.=20 3. The consequent actions now required depend on the nature of the = defect observed, and whether there is any incoming FDI from a=20 lower layer, and should follow the rules given previously. But=20 note that any QoS metrics, which are being collected, are=20 suppressed from aggregation into the long-term registers=20 against available time. The registers are effectively=20 backdated 3s to allow for the defect detection time (at this=20 stage we cannot judge whether the event will be a Short-Break,=20 and hence the LSP remains in the Available State, or whether=20 the LSP will enter the Unavailable State).=20 4. We now start timer T1. This timer is used to determine the=20 duration of the Trail Sink Near-End Defect State, and if this=20 persists for a sufficient time (ie a further 10s) then this=20 timer is used to branch the flow-chart into the Unavailable=20 State processing region.=20 5. Below (timer) T1, we loop round the decision boxes = =91T1<10s?=92=20 and =91End dLOCV, dTTSI or dLoop?=92. We can exit this loop if = the=20 defect state ends (in accordance with criteria given=20 =20 Harrison et. al. Expires August 2001 Page 25 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 previously) before T1 reaches 10s. Since we are still in the=20 available state, we restart any QoS metric aggregation into the = long-term registers (noting the last 3s must be accounted for), = we stop FDI/BDI OAM packet generation and capture the short- break event in the local registers. Additionally, if the event=20 was due to a dTTSI, then we should also capture the TTSI of the = offending LSP and cease the suppression of traffic. The=20 timestamp of the event should be related to the onset of the=20 defect, which caused it. If however T1 reaches 10s we enter the = Unavailable State. Note that it is not possible to enter the=20 Unavailable State unless the Trail Sink Near-End Defect State=20 has persisted for at least 10s in the Available State.=20 6. We now record a date/time-stamped Unavailable State entry event = in the local registers together with information on the nature=20 of the defect, which caused it. Note that the date/timestamp=20 must be backdated 13s. Optionally, we may also send an=20 exception report to the NMS with the Unavailable State entry=20 date/timestamp noted above, together with any other relevant=20 information about the defect which caused it, e.g. in the case=20 of dTTSI this should include the TTSI of the offending LSP. We = now stop timer T1 and start timer T2, whose purpose is to=20 record the duration of the Unavailable State. Note that when we = enter the Unavailable State we also remain in the Trail Sink=20 Near-End Defect State.=20 7. We now run round a decision box =91End dLOCV, dTTSI or = dLoop?=92,=20 which is just below the point where we started timer T2, which=20 checks for the end of the defect state. When the defect ends=20 (in accordance with the criteria given previously) we stop=20 FDI/BDI OAM packet generation and exit the Trail Sink Near-End=20 Defect State. Any QoS metric aggregation is still inhibited.=20 =20 8. We now run round the decision loop comprised of the two boxes=20 =91>=3D9 but <=3D 11 expected CV OAM packets in last 10s AND no = unexpected CV OAM packets' and =91dLOCV, dTTSI or dLoop?=92. = If a=20 further defect occurs before we meet the exit criteria of the=20 former decision box, we re-enter the Trail Sink Near-End Defect = State and hence restart the generation of FDI/BDI OAM packets=20 (with DL/DT codepoints and other consequent actions relevant to = the specific defect observed). Any QoS metric aggregation=20 continues to be inhibited. In this case we are back at point 7 = above in the state processing and recommence checking for the=20 end of the defect. Note that timer T2 continues to run.=20 9. To get out of the Unavailable State we must first have exited=20 the Trail Sink Near-End Defect State as noted in 7 above, and=20 then met the criteria of the decision box =91>=3D9 but <=3D 11=20 expected CV OAM packets in last 10s AND no unexpected CV OAM=20 packets?=92 as noted in 8 above. Note that the =91last 10s=92=20 referred to here includes the 3s interval required to check for = the end of the Trail Sink Near-End Defect State as noted above=20 in item 7.=20 10. We now stop timer T2 and record the duration of the=20 unavailability event in the local registers. We recommence any = QoS metric aggregation into the local registers and cease all=20 consequent actions associated with the Unavailable State. Note = =20 Harrison et. al. Expires August 2001 Page 26 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 that T2 will record Unavailable State duration, which is 3s=20 less than the true unavailability event. Note also that the=20 last 10s belong to the Available State and so any QoS metric=20 aggregation will need to take these 10s into account. =20 Optionally, we may also send an exception report to the NMS=20 with the Unavailable State exit date/timestamp suitably=20 corrected as noted above.=20 11. This now takes us back to our starting point in the Available=20 State.=20 =20 =20 6.6.5 Far-End State Processing Flow-chart=20 =20 The following figure summarizes many of the key points regarding the = far-end state-processing algorithm for a given LSP.=20 =20 Figure 6: LSP Far-End State Processing Flow Chart=20 =20 1. Assume we start in the available state at the box marked=20 =91Start=92. All timers shown later in the flow chart can=20 conceptually be assumed to be reset at this point. If there is = any backward QoS aggregation activated on the return direction=20 LSP then this will be via a separate P OAM packet flow on the=20 return LSP.=20 2. The first decision box is =91BDI OAM packet?=92. If the answer = is=20 'No', then we keep looping this check condition and stay in the = Available State. If the answer is 'Yes', then this implies=20 that the near-end processing at the other end of the (outgoing) = LSP has entered the Trail Sink Near-End Defect State. Note=20 that this also implies that the defect has already existed for=20 3s at the other end of this LSP.=20 3. We then enter the Trail Sink Far-End Defect State and inhibit=20 any backward QoS metric aggregation. The QoS registers will=20 need to be corrected for the previous 3s, which should not be,=20 aggregated into the long-term Available State counts.=20 4. We now start timer T3, and run round the loop composed of the=20 decision boxes =91T3 <13s?=92 and =913s BDI-Free?=92. T3 is = used to=20 check the duration of the Trail Sink Far-End Defect State. If=20 T3 does not reach 13s and we get 3s, which are BDI-Free, then=20 we re-start any backward packet level metric aggregation. Note = that the last 6s must be accounted for in any backward QoS=20 metric aggregation registers. This arises since it takes the=20 near-end processing 3s to declare the end of the defect at the=20 other send of the (outgoing) LSP, and a further 3s to declare=20 the end of the Trail Sink Far-End Defect State at this end of=20 the (return) LSP, and all this time should count towards the=20 Available State at this end of the LSP to ensure correct QoS=20 metric aggregation. A Short-Break date/time-stamped event=20 should also be recorded in the local registers together the=20 DL/DT information of the defect as given in the BDI OAM packet. = =20 This Short-Break event must be date/time-stamped relative to 3s = before the time at which the first BDI OAM packet was observed. = =20 This now takes us back to the initial start position. If=20 however T3 reaches 13s we enter the far-end Unavailable State. = =20 Harrison et. al. Expires August 2001 Page 27 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 Note that it is not possible to enter the Unavailable State=20 unless the Trail Sink Far-End Defect State has effectively=20 persisted for at least 13s (and which means that at the other=20 end of the (outgoing) LSP the Trail Sink Near-End Defect State=20 has persisted for at least 10s) in available time.=20 5. Optionally, we may now send a date/time-stamped unavailability=20 entry exception report to the NMS, which includes the relevant=20 BDI OAM packet DL/DT information. Note that the date/timestamp = of any such exception report should be backdated by 16s (ie 3s=20 prior to the first BDI OAM packet being observed for this=20 event) to align the far-end processing with that of the near- end processing at the other end. We now stop timer T3 and=20 start a timer T4, whose purpose is to record the duration of=20 this unavailability event. Note that when we enter the=20 Unavailable State we also remain in the Trail Sink Far-End=20 Defect State.=20 6. We now run round a loop that checks for 3s which are BDI-Free. = This is used to take us out of the Trail Sink Far-End Defect=20 State. Note that this is not strictly necessary, and this=20 check condition could have been omitted and we could just have=20 shown the following one which checks for a continuous (ie=20 overall) 10s of BDI-Free behavior. However, it has been shown=20 like this to harmonize the =91look=92 of the near-end and = far-end=20 Trail Sink Defect State processing.=20 7. If we get 3s which are BDI-Free then we exit the Trail Sink=20 Far-End Defect State and run a loop which checks if we have had = an overall continuous period of 10s which are BDI-Free. If any = further BDI OAM packets appear within this overall 10s checking = period then we re-enter the Trail Sink Far-End Defect State and = need to repeat the process from step 6 above. If, however, no=20 further BDI OAM packets appear within the 10s checking period=20 we exit the far-end Unavailable State.=20 8. We stop timer T4 and record the duration of the unavailability=20 event. T4 will record a time, which is 3s less than the true=20 unavailability event. A date/time-stamped unavailability exit=20 event, backdated 13s, together with the unavailability duration = should now be recorded in the local registers. Optionally,=20 this information may also be sent to the NMS as an exception=20 report.=20 9. Any backward QoS metric aggregation can now be restarted,=20 noting that the last 13s belong to available time and so the=20 aggregate registers should be corrected accordingly=20 =20 6.6.6 A pictorial view of near-end and far-end state processing =20 =20 The following figure is given to help clarify the temporal=20 relationships between the near-end and far-end state processing=20 given in the previous flow-charts for short-break event and an=20 unavailability event.=20 =20 Figure 7: Near-End and Far-End Temporal Processing of a Short-Break = and Unavailability event=20 =20 =20 =20 Harrison et. al. Expires August 2001 Page 28 = =0C OAM Functionality for MPLS Networks February 2001=20 =20 7. Security Considerations=20 =20 The OAM function described in this document enhances the security of = MPLS networks, by detecting mis-connections, and therefore=20 preventing customers=92 traffic to be exposed to other customers.=20 =20 The MPLS OAM functions as defined in this document do not raise any=20 new security issue, to MPLS networks.=20 =20 =20 8. References=20 =20 =20 [1] Rosen E, et al, RFC 3032, "MPLS label stack encoding".=20 =20 [2] Le Faucheur et al, "MPLS support of Differentiated Services",=20 draft-ietf-mpls-ext-08.txt, work in progress.=20 =20 [3] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",=20 draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, work in progress.=20 =20 [4] Hinden and Deering, RFC 1884, "IP Version 6 Addressing=20 Architecture".=20 =20 9. Author's Addresses=20 =20 Neil Harrison=20 British Telecom Phone: 44-1604-845933=20 Heath Bank Email: neil.2.Harrison@bt.com=20 Iugby Road, Harleston=20 South Hampton, UK=20 =20 Peter Willis=20 British Telecom Phone: 44-1473-645178=20 BT, PP RSB10/PP3 B81 Email: peter.j.willis@bt.com=20 Adastrial Park=20 Martlesham, Ipswich, UK =20 =20 Shahram Davari=20 PMC-Sierra=20 411 Legget Drive Phone: 1-613-271-4018=20 Kanata, ON, Canada Email: Shahram_Davari@pmc-sierra.com=20 =20 Ben Mack-Crane=20 Tellabs=20 4951 Indiana Ave Phone: 1-630-512-7255=20 Lisle, IL, USA Email: ben.mack-crane@tellabs.com=20 =20 Hiroshi Ohta=20 NTT=20 Y-709A, 1-1 Hikarino=92ka phone: 81-468-59-8840 =20 Yokosuka-Shi Email: ohta.hiroshi@nslab.ntt.co.jp=20 Kanagawa, Japan=20 =20 Harrison et. al. Expires August 2001 Page 29 = =0C ------_=_NextPart_000_01C09DB3.D919AFE0 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C09DB3.D919AFE0-- From owner-mpls@UU.NET Fri Feb 23 11:24:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07557 for ; Fri, 23 Feb 2001 11:24: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 QQkdqf06175; Fri, 23 Feb 2001 16:24:05 GMT Received: by mail-control.mail.uu.net id QQkdqf13487 for mpls-outgoing; Fri, 23 Feb 2001 16:23:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqf13452 for ; Fri, 23 Feb 2001 16:23:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdqf21585 for ; Fri, 23 Feb 2001 16:22:37 GMT Received: from bgslc02.TBG.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQkdqf04209 for ; Fri, 23 Feb 2001 16:22:37 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 09:13:39 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE70146D5ED@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Subject: MPLS Resource Center Updates Date: Fri, 23 Feb 2001 09:13:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09DB3.94F74034" 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_01C09DB3.94F74034 Content-Type: text/plain; charset="iso-8859-1" Folks, I've just completed updating the Internet Drafts & RFC's section of the MPLS Resource Center at www.mplsrc.com/drafts.shtml . Given the new WG's in areas such as VPNs, and new drafts in areas such as security, it's getting a bit tougher to keep the page as current as I would like. So if you get a moment, please review and let me know if I'm missing anything or if there are any outdated references that should be removed. Thanks, Irwin ------_=_NextPart_001_01C09DB3.94F74034 Content-Type: text/html; charset="iso-8859-1"
Folks, I've just completed updating the Internet Drafts & RFC's section of the MPLS Resource Center at www.mplsrc.com/drafts.shtml.  Given the new WG's in areas such as VPNs, and new drafts in areas such as security, it's getting a bit tougher to keep the page as current as I would like.  So if you get a moment, please review and let me know if I'm missing anything or if there are any outdated references that should be removed.
 
Thanks,
Irwin
 
 
------_=_NextPart_001_01C09DB3.94F74034-- From owner-mpls@UU.NET Fri Feb 23 11:52:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08528 for ; Fri, 23 Feb 2001 11:52: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 QQkdqh28576; Fri, 23 Feb 2001 16:51:59 GMT Received: by mail-control.mail.uu.net id QQkdqh17479 for mpls-outgoing; Fri, 23 Feb 2001 16:51:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdqh17465 for ; Fri, 23 Feb 2001 16:51:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdqh08404 for ; Fri, 23 Feb 2001 16:50:43 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 QQkdqh05089 for ; Fri, 23 Feb 2001 16:50:41 GMT Received: (qmail 3528 invoked from network); 23 Feb 2001 16:47:30 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 23 Feb 2001 16:47:30 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id WAA25145; Fri, 23 Feb 2001 22:15:43 +0530 (IST) Date: Fri, 23 Feb 2001 22:15:43 +0530 (IST) From: Abhijit To: Eric Gray cc: nagabhushana.ramaswamy@wipro.com, Vinay Vernekar , mpls@UU.NET Subject: Re: LSP control mode of peer... In-Reply-To: <3A9686B6.4C8C5224@sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk LDP specification does in fact allows it. Infact the message processing procedures are quite elaborate about it. But the section 5.2.1 of architecture draft says... 5.2.1. Schemes for LSRs that Support Label Merging If Ru and Rd are label distribution peers, and both support label merging, one of the following schemes must be used: ^^^^ and the case which i was discussing was not included in the list of schemes. thats why there was confusion... -abhijit On Fri, 23 Feb 2001, Eric Gray wrote: >Bhushana, > > You're all placing too much "authority" in an architecture >document. Architecture typically defines a framework for >design and specification. > > In this case, the LDP specification specifically allows >Label Request messages to be used by an upstream peer >when the downstream peer is using downstream unsolicited >label distribution. > > As a minimum, this is required when the upstream LSR is >an ATM LSR and is not able to perform VC-merge. But >there is nothing that restricts this support to ATM LSRs. > > Instead of asking if the architecture allows it, look to see >if the protocol specification allows it. > > >You wrote: > >> > Consider e.g. >> > >> > Ru1 >> > \ >> > \ >> > Rd1 - - Rd2 - - Rd3 - - D >> > / >> > / >> > Ru2 >> > >> > Let Rd1 be merge capable.. >> > >> > Why can Rd1 not send a request to Rd2 for some FEC F for packets destined >> > for D and coming from Both Ru1 and Ru2.. The fact that Rd2 distributes the >> > label bindings unsolicitedly won't require Rd1 to send the request. But in >> > any case it shouldn't prevent Rd1 from asking for it. How will it matter >> > if Rd2 distributes binding labels for FEC independent control or Ordered >> > control? So in any case Rd1 need not know Control mode of Rd2.. Is it >> > consisitent with architecture? >> > -abhijit >> >> exactly! the problem started with the same thing - why should my request >> procedure depend on my peer's control mode?? I don't need to bother >> whether he has given the binding indepndently or not. If you look at the >> architecture doc section 5.2.1 you could find this dependency. So I feel >> we need to have one more tuple there where my request procedure can be >> "Request when needed" when I am in conservative retention and the >> downstream dist procedure is PushUConditional (or a possible restructuring >> of the tuples so that my request procedure is independant of peer's >> control mode). >> >> best regards >> Bhushana >> >> > > > > From owner-mpls@UU.NET Fri Feb 23 12:07:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09100 for ; Fri, 23 Feb 2001 12:07: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 QQkdqi03880; Fri, 23 Feb 2001 17:07:02 GMT Received: by mail-control.mail.uu.net id QQkdqi03510 for mpls-outgoing; Fri, 23 Feb 2001 17:06:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdqi03504 for ; Fri, 23 Feb 2001 17:06:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdqi13639 for ; Fri, 23 Feb 2001 17:05:36 GMT Received: from EXCHANGE.kerenix.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.150.1.82]) id QQkdqi00918 for ; Fri, 23 Feb 2001 17:05:34 GMT Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id <1086CXP0>; Fri, 23 Feb 2001 19:06:55 +0200 Message-ID: <2B15221907365C468941FDFC02C87769CEDF@EXCHANGE.kerenix.com> From: Vadim Suraev To: "'Choudhury, Sanjaya'" Cc: "'mpls@UU.NET'" Subject: RE: Questions related to Class-Type (in DiffServ-TE context) Date: Fri, 23 Feb 2001 19:06:50 +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 Sanjaya, Hi. >I thought the draft diff-te-reqts-00, implies that the main >purpose of the introduction of Class-Type was to reduce >the number of IGP messages required to communicate the >per-diffserv class bandwidth information user configured on >a LSR. Regarding purpose of the introduction of Class-Type - I think, because DiffServ's resources should be divided among different PHBs (or groups of PHBs), we can say, that each group of PHBs has its own "pool" (say "virtual pool") of resources (BW, queues). Lets call group_of_PHBs<-->resources_pool Class-Type. Then in example from draft-ietf-tewg-diff-te-reqts-00.txt: - Class-Type 0 (eg: BE) to reserve up to 9 Gb/s - Class-Type 1 (eg: real time including EF) to reserve up to 5 Gb/s - Class-Type 2 (eg: low loss including AF1 and AF2) to reserve up to 8 Gb/s - on an aggregate basis, the sum of all Class-Types to reserve up to 10 Gb/s. In example above, BE,EF and AF1&2 are groups_of_PHBs (mapped accordingly to Class-Type 0,1 and 2). BW (resource) pools have (initially) accordingly 9Gbps, 5Gbps, 8 Gbps. So, MPLS signaling protocols are required to be able to signal to LSRs, from which "pool" (Class Type) to allocate resources. >Therefore, I understand that there need for changes >to the IGPs, but I am unclear about the purpose of the >Class-Type in the signaling messages. I think, there are drafts - extensions for IGPs (OSPF & ISIS), describe extended sets of metrics for support for TE for DiffServ. >Is it really author's intention to define, yet another higher layer grouping of PHBs (i.e a >Class-Type consists of several PHBs ? I think, there is no any restriction, how to group PHBs into Class-Types, therefore Class-Type may consist of any layer grouping of PHBs as well as one PHBs. If you wish, you can associate, for example, all AFxx and BE with Class-Type 0 and EF with Class-Type 1. Or BE with Class-Type 0, AFxx with Class Type 1 and EF with Class-Type 2. >If the administrator really wanted to define a class for Real-time, or Low-Loss, >can't he define a new PHB ?) I think, regardless of which Class-Types are associated with which PHBs, administrator can define a new PHB (and then associate it with one of Class-Types). Best Regards, Vadim. KereniX Data-Aware Optical NetworksTM ---------------------------------------------------------------------------- ------ Vadim Suraev http://www.kerenix.com Phone: +972-3-9050830 Mobile: 972-53-568711 Fax: +972-3-9347720 vadim_suraev@kerenix.com 70 Pinsker St., POB 10053, Petach-Tikva 49221 ISRAEL ---------------------------------------------------------------------------- ------ From owner-mpls@UU.NET Fri Feb 23 12:35:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10614 for ; Fri, 23 Feb 2001 12:35: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 QQkdqk03928; Fri, 23 Feb 2001 17:34:39 GMT Received: by mail-control.mail.uu.net id QQkdqk06150 for mpls-outgoing; Fri, 23 Feb 2001 17:34:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqk06136 for ; Fri, 23 Feb 2001 17:34:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdqk04175 for ; Fri, 23 Feb 2001 17:34:04 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdqk09811 for ; Fri, 23 Feb 2001 17:34:03 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id BA53194006; Fri, 23 Feb 2001 12:34:02 -0500 (EST) Message-ID: <3A969F0A.6D728BB1@sandburst.com> Date: Fri, 23 Feb 2001 12:34:02 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol Cc: akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: Re: New TTL Draft References: <3A9403E0.AC0BEA27@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora/Puneet, Some comments. In section 2.4, item 3 - PHP does not necessarily expose an IP header. The text in this section is not clear in this respect - possibly because of the textual construct "IP-Header/label". It might be somewhat clearer if you use "header" and add a paragraph stating that the PHP exposed header may be either an IP header or an MPLS label and the appropriate oTTL is written to the corresponding TTL field of this PHP exposed header. Also, in this section, why is oTTL set to the TTL of the exposed header if it is not used for anything? In addition, if your actually specifying a behavior (rather than an architecture), I believe you need to allow that the TTL may be decremented by a number other than one. RFC 791 states that RFC is decremented by at least one. Your draft states in several places that iTTL is decremented (I assume that the underscore in these cases is meant to be a minus sign) by one. There are practical reasons for decrementing TTL by more than one (a high-cost or low-bandwidth link, for example) when it is desirable to accelerate the aging of possibly looping packets. A higher TTL decrement punishes all packets that use the link, but it punishes looping packets much more. Finally, what is the mechanism which the PHP uses to determine whether or not the LSP is using the pipe or the uniform model? I am not sure this information is currently available. -- Eric Gray Bora Akyol wrote: > Note that we (Puneet and I) just posted an Internet Draft on TTL > handling in hierarchical MPLS networks. > > The internet draft is titled: draft-agarwal-mpls-ttl-00.txt > > http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt > > We welcome any comments, > > Bora Akyol From owner-mpls@UU.NET Fri Feb 23 12:41:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10853 for ; Fri, 23 Feb 2001 12:41: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 QQkdqk20218; Fri, 23 Feb 2001 17:41:37 GMT Received: by mail-control.mail.uu.net id QQkdqk06826 for mpls-outgoing; Fri, 23 Feb 2001 17:41:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdqk06801 for ; Fri, 23 Feb 2001 17:41:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqk02885 for ; Fri, 23 Feb 2001 17:39:54 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdqk12526 for ; Fri, 23 Feb 2001 17:39:54 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id EA2FC94006; Fri, 23 Feb 2001 12:39:53 -0500 (EST) Message-ID: <3A96A069.2808CFFD@sandburst.com> Date: Fri, 23 Feb 2001 12:39:53 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Abhijit Cc: nagabhushana.ramaswamy@wipro.com, Vinay Vernekar , mpls@UU.NET Subject: Re: LSP control mode of peer... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abhijit, Yes, but it doesn't say "ONLY one of the ..." :-) You wrote: > LDP specification does in fact allows it. Infact the message processing > procedures are quite elaborate about it. But the section 5.2.1 of > architecture draft says... > > 5.2.1. Schemes for LSRs that Support Label Merging > > If Ru and Rd are label distribution peers, and both support label > merging, one of the following schemes must be used: > ^^^^ > and the case which i was discussing was not included in the list of > schemes. thats why there was confusion... > > -abhijit > > On Fri, 23 Feb 2001, Eric Gray wrote: > > >Bhushana, > > > > You're all placing too much "authority" in an architecture > >document. Architecture typically defines a framework for > >design and specification. > > > > In this case, the LDP specification specifically allows > >Label Request messages to be used by an upstream peer > >when the downstream peer is using downstream unsolicited > >label distribution. > > > > As a minimum, this is required when the upstream LSR is > >an ATM LSR and is not able to perform VC-merge. But > >there is nothing that restricts this support to ATM LSRs. > > > > Instead of asking if the architecture allows it, look to see > >if the protocol specification allows it. > > > > > >You wrote: > > > >> > Consider e.g. > >> > > >> > Ru1 > >> > \ > >> > \ > >> > Rd1 - - Rd2 - - Rd3 - - D > >> > / > >> > / > >> > Ru2 > >> > > >> > Let Rd1 be merge capable.. > >> > > >> > Why can Rd1 not send a request to Rd2 for some FEC F for packets destined > >> > for D and coming from Both Ru1 and Ru2.. The fact that Rd2 distributes the > >> > label bindings unsolicitedly won't require Rd1 to send the request. But in > >> > any case it shouldn't prevent Rd1 from asking for it. How will it matter > >> > if Rd2 distributes binding labels for FEC independent control or Ordered > >> > control? So in any case Rd1 need not know Control mode of Rd2.. Is it > >> > consisitent with architecture? > >> > -abhijit > >> > >> exactly! the problem started with the same thing - why should my request > >> procedure depend on my peer's control mode?? I don't need to bother > >> whether he has given the binding indepndently or not. If you look at the > >> architecture doc section 5.2.1 you could find this dependency. So I feel > >> we need to have one more tuple there where my request procedure can be > >> "Request when needed" when I am in conservative retention and the > >> downstream dist procedure is PushUConditional (or a possible restructuring > >> of the tuples so that my request procedure is independant of peer's > >> control mode). > >> > >> best regards > >> Bhushana > >> > >> > > > > > From owner-mpls@UU.NET Fri Feb 23 13:43:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14471 for ; Fri, 23 Feb 2001 13:43:21 -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 QQkdqo27855; Fri, 23 Feb 2001 18:43:05 GMT Received: by mail-control.mail.uu.net id QQkdqo28174 for mpls-outgoing; Fri, 23 Feb 2001 18:42:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdqo28157 for ; Fri, 23 Feb 2001 18:42:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdqo11031 for ; Fri, 23 Feb 2001 18:42:10 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdqo09511 for ; Fri, 23 Feb 2001 18:42:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA06301 for mpls@uu.net; Fri, 23 Feb 2001 13:42:08 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdqo28040 for ; Fri, 23 Feb 2001 18:41:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdqo26464; Fri, 23 Feb 2001 18:40:32 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 QQkdqo23950; Fri, 23 Feb 2001 18:40:32 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 NAA00824; Fri, 23 Feb 2001 13:37:43 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAW55591; Fri, 23 Feb 2001 13:38:14 -0500 (EST) Message-Id: <4.3.2.7.2.20010223133453.069a9de0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Feb 2001 13:40:40 -0500 To: te-wg@UU.NET, mpls@UU.NET From: "Thomas D. Nadeau" Subject: draft-nadeau-mpls-ds-te-mib-00.txt Cc: tnadeau@cisco.com, flefauch@europe.cisco.com, angela.chiu@celion.com, btownsend@tenornetworks.com, dareks@nortelnetworks.com, martin.tatham@bt.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, FYI a new MIB for managing MPLS DiffServ-Aware TE has been posted. This document goes along with the other four DiffServ-Aware TE documents which have been adopted in the MPLS, TE, ISIS and OSPF WGs. It should be available shortly via the IETF's web site. In the meantime, it is available at the following web/ftp link. As usual, comments are welcome. ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-nadeau-mpls-ds-te-mib-00.txt --Tom From owner-mpls@UU.NET Fri Feb 23 15:13:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19590 for ; Fri, 23 Feb 2001 15:13: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 QQkdqu21291; Fri, 23 Feb 2001 20:13:35 GMT Received: by mail-control.mail.uu.net id QQkdqu06617 for mpls-outgoing; Fri, 23 Feb 2001 20:13: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 QQkdqu06606 for ; Fri, 23 Feb 2001 20:13: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 QQkdqu20196 for ; Fri, 23 Feb 2001 20:12:58 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdqu27094 for ; Fri, 23 Feb 2001 20:12:57 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA13919 for mpls@uu.net; Fri, 23 Feb 2001 15:12:56 -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 QQkdqu06528 for ; Fri, 23 Feb 2001 20:12: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 QQkdqu18897 for ; Fri, 23 Feb 2001 20:09:24 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 QQkdqu15690 for ; Fri, 23 Feb 2001 20:09: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 PAA07557; Fri, 23 Feb 2001 15:08:42 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAW57311; Fri, 23 Feb 2001 15:09:12 -0500 (EST) Message-Id: <4.3.2.7.2.20010223150102.06a62cf8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Feb 2001 15:11:44 -0500 To: pwot@ietf.org, mpls@UU.NET From: "Thomas D. Nadeau" Subject: draft-danenberg-sonet-ces-mpls-mib-00.txt Cc: "Thomas D. Nadeau" , "Andrew G. Malis" , , , "tom k. johnson" , "Scott C. Park" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, FYI a new MIB for managing SONET/SDH Circuit Emulation Service Over MPLS has been posted. It should be available shortly via the IETF's web site. In the meantime, it is available at the following web/ftp link. As usual, comments are welcome. ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces-mpls-mib-00.txt --Tom From owner-mpls@UU.NET Fri Feb 23 15:46:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20961 for ; Fri, 23 Feb 2001 15:46: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 QQkdqx23950; Fri, 23 Feb 2001 20:46:29 GMT Received: by mail-control.mail.uu.net id QQkdqx09819 for mpls-outgoing; Fri, 23 Feb 2001 20:45:56 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 QQkdqx09816 for ; Fri, 23 Feb 2001 20:45:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdqw25263 for ; Fri, 23 Feb 2001 20:44:07 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 QQkdqw09225 for ; Fri, 23 Feb 2001 20:44:07 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 MAA24977 for ; Fri, 23 Feb 2001 12:44:16 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA12045 for mpls@uu.net; Fri, 23 Feb 2001 15:43:59 -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 QQkdqw09295 for ; Fri, 23 Feb 2001 20:41: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 QQkdqw14592 for ; Fri, 23 Feb 2001 20:39:15 GMT Received: from PH01SRV02.photuris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [141.150.26.4]) id QQkdqw17183 for ; Fri, 23 Feb 2001 20:39:15 GMT Received: by PH01SRV02.photuris.com with Internet Mail Service (5.5.2650.21) id <1NZQTKHJ>; Fri, 23 Feb 2001 15:31:33 -0500 Message-ID: From: Murali Krishnaswamy To: "'internet-drafts@ietf.org'" Cc: "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" , "'mpls@uu.net'" Subject: ID: draft-krishnaswamy-optical-rsvp-extn-00.txt Date: Fri, 23 Feb 2001 15:31:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09DD7.9C3C30F6" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C09DD7.9C3C30F6 Content-Type: text/plain; charset="iso-8859-1" Hi, Please post the attached draft on the IETF internet draft directory. From Abstract: We propose an extension to RSVP-TE that would permit setting up optical channel connections whose paths form a topology that is independent of the control layer topology. Thank you, Murali Krishnaswamy Photuris Inc. murali@photuris.com <> ------_=_NextPart_000_01C09DD7.9C3C30F6 Content-Type: text/plain; name="rsvp.txt" Content-Disposition: attachment; filename="rsvp.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Internet Draft Murali Krishnaswamy=0A= Leah Zhang=0A= Antonio Rodriguez-Moral=0A= Photuris Inc.=0A= =0A= Expires August 2001 22 February 2001=0A= =0A= =0A= =0A= Lightpath Route Extensions to RSVP-TE for=0A= optical channel connection setup=0A= =0A= =0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all provisions of Section 10 of RFC2026. Internet-Drafts are = working=0A= documents of the Internet Engineering Task Force (IETF), its = areas,=0A= and its working groups. Note that other groups may also = distribute=0A= working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at = any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= =0A= 1. Abstract=0A= =0A= We propose an extension to RSVP-TE [1][2]that would permit setting = up=0A= OCh (optical channel) connections whose paths form a topology that = is=0A= independent of the control layer topology. This separation of an = OCh=0A= connection path and the associated control layer network may be=0A= necessary for many reasons. First, it may not be possible to = provide=0A= a control channel connection to each one of an optical network=0A= element (ONE)'s neighbor - for many reasons explained in Sec. 2. = (ONE=0A= as used in this draft includes optical cross-connect (OXC), = optical=0A= add-drop multiplexer (OADM) or even optical terminal multiplexer=0A= (OTM). Secondly by providing the means to signal OCh connections=0A= through different multiple control paths, we achieve network=0A= resilience against control channel failure. We propose a new=0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 1]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= extension to RSVP-TE called Lightpath Route Object (LRO) which is = a=0A= list of nodes along OCh connection path. This is carried in the = Path=0A= message by RSVP-TE as an Opaque Object for interpretation and use = by=0A= the optical nodes. This facilitates setting up OCh connections=0A= between nodes that have no adjacency at the IP layer.=0A= =0A= =0A= 2. Introduction=0A= =0A= OCh connections can be setup using a signaling scheme similar to=0A= those proposed in the Generalized MPLS signaling drafts [3][4]. = Due=0A= to the multiple influencing parameters, the end-to-end path for = OCh=0A= connections is always predetermined and signaled as ERO using = RSVP-=0A= TE. An implicit (and required) assumption in such cases is that, = the=0A= OCh path aligns with the control path. This OCh and control path=0A= association is necessary as RSVP-TE requires IP adjacency. = Further=0A= the proposed OSPF extensions to support MPlambdaS [5] and the = opaque=0A= TE extensions in general [6], advertise only those TE parameters=0A= (both control and OCh) that are specific to that control channel=0A= (link). (Note: Even if an OCh connection that doesn't belong to = a=0A= particular link is advertised over that link, still there is no = way=0A= of signaling an OCh path that is different from the control path=0A= (ERO).=0A= Control Channel=0A= ++++++++++++++ +-------+ ++++++++++++++=0A= + -------------| A |------------- +=0A= + | | | OCh-Ring-1 | +=0A= + | --------- | | --------- | +=0A= + | | +-------+ OCh-Ring| | +=0A= + | | -2 | | +=0A= +-------+ +-------+=0A= | D |-------------------------| B |=0A= | | | |=0A= +-------+ +-------+=0A= + | | +=0A= + | | +=0A= + | +-------+ | +=0A= + |------------| C |------------| +=0A= +++++++++++++++| |+++++++++++++++=0A= +-------+=0A= =0A= Fig. 1 - Multiple Rings.=0A= OCh-Ring 1 - A-B-C-D=0A= OCh-Ring 2 - A-B-D (No control channel between = B-D)=0A= =0A= This dependency makes it impossible to set up OCh connections = between=0A= two nodes if they have no adjacency at the IP layer - ie. if there = is=0A= no control channel between them (B-D in Fig.1). Hence a network=0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 2]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= operator can't configure and offer ring configurations similar to=0A= OCh-Ring-2.=0A= =0A= Thus this control/OCh layers topology association puts limitations = in=0A= the deployment and features that can be offered by a network=0A= operator.=0A= =0A= Some of the reasons for not providing control channel between=0A= adjacent nodes are:=0A= =0A= =0A= o Since the control channels are terminated in each node,=0A= optics/hardware architecture may limit the total number of = con-=0A= trol channels in an optical node. This may be especially true = in=0A= a low cost access/metro WDM system or in highly meshed = network.=0A= =0A= o Where an out-of-fiber separate control channel (eg. ethernet) = is=0A= deployed, it is difficult to colocate the controls channel = along=0A= all of the optical paths.=0A= =0A= A more compelling reason for LRO is the case of optical ring = networks=0A= where a network operator would typically prefer to setup "short = side"=0A= connections even in the event of the control channel failure = along=0A= this path (Fig. 2). As the control channel uses a separate wave-=0A= length, for eg. its transmitter/receiver could fail, while all = the=0A= other wavelengths (that carry user data) remain unaffected. One = less=0A= obvious disadvantage of a long side connection is that it could=0A= increase the blocking probability for future wavelength = allocations.=0A= =0A= =0A= +-------+ Control Channel Failure=0A= +++++++++++++++| A |+++++++++ X X X=0A= + ----------| |---------- X=0A= + | +-------+ OCh | X=0A= + | | +=0A= + | | +=0A= +-------+ +-------+=0A= | D | | B |=0A= | | | |=0A= +-------+ +-------+=0A= + | | +=0A= + | | +=0A= + | +-------+ | +=0A= + ----------| C |---------- +=0A= +++++++++++++++| |+++++++++++++++=0A= +-------+=0A= Fig. 2 - Control Channel Failure between A-B=0A= =0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 3]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= When the control channel between A and B fails, it is not possible = to=0A= setup short side (A-B) OCh connections between A and B using = RSVP-TE=0A= even though the data channels between them remain unaffected. = With=0A= LRO extensions we would be able to signal and setup the short side = A-=0A= B OCh connection (by specifying LRO as A-B) while letting the = control=0A= message go through the longer path A-D-C-B (or B-C-D-A).=0A= =0A= =0A= Note: Link Management Protocol [7] proposes protection control = chan-=0A= nels for maintaining link connectivity. The protection control = chan-=0A= nel takes over when the primary one fails. However such = proposals=0A= may not be feasible in many systems for architectural and = economic=0A= reasons.=0A= =0A= =0A= 3. Lightpath Route Object (LRO)=0A= =0A= Owing to the above reasons we propose an extension to RSVP-TE = called=0A= Lightpath Route Object and this is a list of the nodes in the OCh=0A= connection path. LRO is carried in the Path message and is = treated=0A= as an Opaque Object by RSVP-TE. It is up to the applications on = the=0A= nodes to use the path information in LRO to set up the OCh = connec-=0A= tions. RSVP-TE (control path) itself follows the ERO path only.=0A= =0A= The lightpath routes are specified by the LIGHTPATH_ROUTE object=0A= (LRO).=0A= =0A= 3.1 Path Message=0A= =0A= =0A= The format of the Path message is as follows:=0A= =0A= ::=3D [ ]=0A= =0A= =0A= [ ]=0A= [ ]=0A= =0A= [ ]=0A= [ ... ]=0A= =0A= =0A= ::=3D =0A= [ ]=0A= [ ]=0A= =0A= =0A= The relative placement of LIGHTPATH_ROUTE object is simply a=0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 4]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= recommendation. The ordering of the objects is not important, so = an=0A= implementation MUST be prepared to accept objects in any order.=0A= =0A= We define a new Lightpath route class =3D 22 (check), c_type =3D = 1.=0A= =0A= =0A= 3.2 LIGHTPATH_ROUTE Format=0A= =0A= =0A= LIGHTPATH_ROUTE has the following format:=0A= =0A= 0 1 2 = 3=0A= 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=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | = |=0A= // (Subobjects) = //=0A= | = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= The contents of an LIGHTPATH_ROUTE object are a series of = variable-=0A= length data items called subobjects. Each subobject has the = form:=0A= =0A= 0 1=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+=0A= |L| Type | Length | (Subobject contents) = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+=0A= =0A= =0A= L=0A= The L bit is reserved.=0A= =0A= Type=0A= =0A= The Type indicates the type of contents of the = subobject.=0A= Currently defined values are:=0A= =0A= 0 Reserved=0A= 1 IPv4 prefix=0A= 2 IPv6 prefix=0A= =0A= Length=0A= =0A= The Length contains the total length of the subobject in = bytes,=0A= including the L, Type and Length fields. The Length MUST = be at=0A= least 4, and MUST be a multiple of 4.=0A= =0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 5]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= Two Subobjects are defined - for IPv4 and IPv6.=0A= =0A= Subobject 1: IPv4=0A= =0A= 0 1 2 = 3=0A= 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=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= |L| Type | Length | IPv4 address (4 bytes) = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | IPv4 address (continued) | Resvd = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= L=0A= The L bit is reserved.=0A= =0A= Type=0A= 0x01 IPv4 address=0A= =0A= Length=0A= The Length contains the total length of the subobject in=0A= bytes, including the Type and Length fields. The Length=0A= is always 8.=0A= =0A= IPv4 address=0A= An IPv4 address (of the optical node).=0A= =0A= Padding=0A= Zero on transmission. Ignored on receipt.=0A= =0A= =0A= Subobject 2: IPv6=0A= =0A= 0 1 2 = 3=0A= 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=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= |L| Type | Length | IPv6 address (16 bytes) = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | IPv6 address (continued) = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | IPv6 address (continued) = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | IPv6 address (continued) = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | IPv6 address (continued) | Resvd = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= =0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 6]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= L=0A= The L bit is reserved.=0A= =0A= Type=0A= 0x02 IPv6 address=0A= =0A= Length=0A= The Length contains the total length of the subobject in=0A= bytes, including the Type and Length fields. The Length=0A= is always 20.=0A= =0A= IPv6 address=0A= An IPv6 address (of the optical node).=0A= =0A= Padding=0A= Zero on transmission. Ignored on receipt.=0A= =0A= =0A= 4. LRO and ERO=0A= =0A= Though LRO is an Opaque object as far as RSVP-TE is concerned, a = few=0A= guidelines are provided regarding its usage and its co-existence = with=0A= ERO.=0A= =0A= =0A= o First of all to help implementation LRO is defined such that = its=0A= format is similar to ERO.=0A= =0A= =0A= o When the RSVP-TE message has no LRO, then the optical nodes = must=0A= use the path specified in the ERO for the OCh connection.=0A= =0A= =0A= o When the RSVP-TE message carries LRO, then the optical nodes=0A= must use the path specified in the LRO for the OCh = connection.=0A= =0A= =0A= o The LRO nodes must be a sub-set of the ERO nodes.=0A= =0A= =0A= o The source and destination nodes of the LRO and ERO must be = the=0A= same.=0A= =0A= =0A= o On an implementation note a source node must reject a = connection=0A= request if the above two requirements are not satisfied.=0A= =0A= 5. Label operation in the presence of LRO=0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 7]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= In switched optical networks the labels carried in the Resv = message=0A= are generally encoded to represent the WDM channels or lambdas = that=0A= have been selected by the downstream neighbors. In cases where = the=0A= LRO is not the same as ERO (normally this should be the case as = oth-=0A= erwise no LRO is required), the label allocation and usage is=0A= slightly different.=0A= =0A= When LRO is specified, those intermediate nodes which are not a = part=0A= of LRO (non-LRO nodes) must generate "dummy" or some = "pre-assigned"=0A= labels that are recognized by LRO nodes. (A node determines if it = is=0A= a LRO or non-LRO node by looking in to the PSB). Only the LRO = nodes=0A= generate valid labels useful for setting up OCh connections. If = a=0A= LRO member node upon receiving the Resv message, finds that the = top=0A= label is a dummy one, it must then ignore that and look down in = to=0A= the stack till it finds a valid label. (This label will obviously=0A= correspond to that of its predecessor LRO node). It is this label=0A= that a LRO node must use for setting up OCh connections.=0A= =0A= Note: This draft doesn't modify the RSVP-TE behavior.=0A= =0A= =0A= 6. Security Considerations=0A= =0A= This draft doesn't raise any security considerations.=0A= =0A= =0A= 7. References=0A= =0A= =0A= [1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) - = Version=0A= 1, Functional Specification", RFC 2205, September 1997.=0A= =0A= [2] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP = Tunnels",=0A= Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August=0A= 2000.=0A= =0A= [3] Ashwood-Smith, P. et. al., "Generalised MPLS - Signaling Func-=0A= tional Description", Internet Draft, = draft-ietf-mpls-generalised-=0A= signaling -00.txt, October 2000.=0A= =0A= [4] Ashwood-Smith, P. et. al., "Generalised MPLS Signaling - = RSVP-TE=0A= Extensions", Internet Draft, = draft-ietf-mpls-generalised-rsvp-te=0A= -00.txt, November 2000.=0A= =0A= [5] Kompella, K. et. al., "OSPF Extensions in Support of = MPL(ambda)S",=0A= Internet Draft, draft-kompella-ospf-ompls-extensions-00.txt, = July=0A= 2000.=0A= =0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 8]=0A= =0A= =0A= =0A= =0A= =0A= I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt=0A= =0A= =0A= [6] Katz, D. et. al., "Traffic Engineering Extensions to OSPF", = Inter-=0A= net Draft, draft-katz-yeung-ospf-traffic-03.txt, September = 2000.=0A= =0A= [7] Lang, J. et. al., "Link Management Protocol [LMP]", Internet=0A= Draft, draft-lang-mpls-lmp-02.txt, July 2000.=0A= =0A= =0A= 8. Authors' Addresses=0A= =0A= Murali Krishnaswamy, Leah Zhang, Antonio Rodriguez-Moral=0A= Photuris Inc.=0A= 20 Corporate Place South=0A= Piscataway NJ 08854=0A= Tel: +1 (732) 465 1000 x1220, x1252, x1343=0A= Fax: +1 (732) 465 1010=0A= E-mail: murali, lzhang, arodmor@photuris.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Krishnaswamy, et al. [Page = 9]=0A= =0A= =0A= ------_=_NextPart_000_01C09DD7.9C3C30F6-- From owner-mpls@UU.NET Fri Feb 23 16:49:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23220 for ; Fri, 23 Feb 2001 16:49: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 QQkdrb21236; Fri, 23 Feb 2001 21:49:28 GMT Received: by mail-control.mail.uu.net id QQkdrb01416 for mpls-outgoing; Fri, 23 Feb 2001 21:48:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdrb01403 for ; Fri, 23 Feb 2001 21:48:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdrb20336 for ; Fri, 23 Feb 2001 21:48:37 GMT From: djiang1@lucent.com 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 QQkdrb20031 for ; Fri, 23 Feb 2001 21:48:36 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 QAA20929 for ; Fri, 23 Feb 2001 16:48:35 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA20844; Fri, 23 Feb 2001 16:48:30 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA09441; Fri, 23 Feb 2001 16:48:29 -0500 (EST) Subject: MPLS using LDP and ATM VC Switching To: bsd@cisco.com, pdoolan@ennovatenetworks.com, mpls@UU.NET Date: Fri, 23 Feb 2001 16:44:42 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/23/2001 16:44:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Everyone, I have a question regarding RFC3035. There is a paragraph in RFC3035, page 5 to page 6, says, "Label switching is accomplished by associating labels with Forwarding Equivalence Classes, and using the label value to forward packets, including determining the value of any replacement label. See [1] for further details. In an ATM-LSR, the label is carried in the VPI/VCI field, or, when two ATM-LSRs are connected via an ATM "Virtual Path", in the VCI field." I am wondering why it is in the VCI field rather than VPI field. I thought if the two ATM-LSRs are connected via virtual circuit, then forwarding should be based on the VPI/VCI field, if the two ATM-LSRs are connected visa virtual path, then forwarding should be based on the VPI field. Regards, Jane D. Jiang From owner-mpls@UU.NET Fri Feb 23 16:54:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23458 for ; Fri, 23 Feb 2001 16:54: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 QQkdrb12834; Fri, 23 Feb 2001 21:54:16 GMT Received: by mail-control.mail.uu.net id QQkdrb01935 for mpls-outgoing; Fri, 23 Feb 2001 21:53:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdrb01923 for ; Fri, 23 Feb 2001 21:53:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdrb03398 for ; Fri, 23 Feb 2001 21:53:21 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkdrb26692 for ; Fri, 23 Feb 2001 21:53:21 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA10278; Fri, 23 Feb 2001 13:53:15 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Feb 2001 13:53:15 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA0944E4@avalon.pluris.com> From: Puneet Agarwal To: "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , "'shahram_davari@pmc-sierra.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Fri, 23 Feb 2001 13:53:14 -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 Eric, Comments inline. >-----Original Message----- >From: Eric Gray [mailto:eric.gray@sandburst.com] >Sent: Friday, February 23, 2001 9:34 AM >To: Bora Akyol >Cc: akyol@akyol.org; djiang1@lucent.com; B, Prakash K (Prakash); >'mpls@uu.net' >Subject: Re: New TTL Draft > > >Bora/Puneet, > > Some comments. > > In section 2.4, item 3 - PHP does not necessarily expose an >IP header. The text in this section is not clear in this respect >- possibly because of the textual construct "IP-Header/label". >It might be somewhat clearer if you use "header" and add a >paragraph stating that the PHP exposed header may be either >an IP header or an MPLS label and the appropriate oTTL is >written to the corresponding TTL field of this PHP exposed >header. I agree. We will change the wording in the next rev of the draft. > > Also, in this section, why is oTTL set to the TTL of the >exposed header if it is not used for anything? Good point. We do not need to set this. This was a leftover from some text we took out of section 2.5 at the last moment that used this information. We will fix this in the next rev. > > In addition, if your actually specifying a behavior (rather than >an architecture), I believe you need to allow that the TTL may >be decremented by a number other than one. RFC 791 states >that RFC is decremented by at least one. Your draft states in >several places that iTTL is decremented (I assume that the >underscore in these cases is meant to be a minus sign) by one. The underscore is indeed supposed to be a minus. Will be fixed in the next rev. I have no problems in allowing the iTTL to be decremented by more than one. I will change the text to state that the iTTL should be decremented by "N", where "N" is user configured and is greater than 0. The default value of "N" should be 1. > > There are practical reasons for decrementing TTL by more >than one (a high-cost or low-bandwidth link, for example) >when it is desirable to accelerate the aging of possibly looping >packets. A higher TTL decrement punishes all packets that use >the link, but it punishes looping packets much more. > > Finally, what is the mechanism which the PHP uses to determine >whether or not the LSP is using the pipe or the uniform model? I am >not sure this information is currently available. You may be right. I looked through "draft-ietf-mpls-diff-ext-08.txt", but did not see any method to signal the model (pipe or uniform) associated with the LSP, using either RSVP or LDP. If it is a missing piece, then I hope that it will be addressed by the authors of that draft. -Puneet > >-- >Eric Gray > >Bora Akyol wrote: > >> Note that we (Puneet and I) just posted an Internet Draft on TTL >> handling in hierarchical MPLS networks. >> >> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt >> >> http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt >> >> We welcome any comments, >> >> Bora Akyol > From owner-mpls@UU.NET Fri Feb 23 17:03:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24159 for ; Fri, 23 Feb 2001 17:03: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 QQkdrc24802; Fri, 23 Feb 2001 22:02:54 GMT Received: by mail-control.mail.uu.net id QQkdrc05518 for mpls-outgoing; Fri, 23 Feb 2001 22:02: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 QQkdrc05457 for ; Fri, 23 Feb 2001 22:02: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 QQkdrc19056 for ; Fri, 23 Feb 2001 22:00:53 GMT Received: from winstar.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-mail.winstar.com [207.86.108.156]) id QQkdrc17787 for ; Fri, 23 Feb 2001 22:00:52 GMT Received: from vaaws032382 (VAAWS032382.winstar.com [10.1.183.46]) by winstar.com (8.9.3/8.9.1) with SMTP id RAA16801; Fri, 23 Feb 2001 17:00:25 -0500 (EST) Reply-To: From: "Yi Chu" To: , , , Subject: RE: MPLS using LDP and ATM VC Switching Date: Fri, 23 Feb 2001 17:03:08 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit My interpretation is that if two ATM LSR are directly connected, say through an OC3, then vpi/vci pair is used to carry the label encoding. If on the other hand, two ATM LSR are not directly connected, but connected with a VP tunnel (through a carrier's ATM network, e.g.), then only vci is available for label encoding. yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of djiang1@lucent.com Sent: Friday, February 23, 2001 4:45 PM To: bsd@cisco.com; pdoolan@ennovatenetworks.com; mpls@UU.NET Subject: MPLS using LDP and ATM VC Switching Hi Everyone, I have a question regarding RFC3035. There is a paragraph in RFC3035, page 5 to page 6, says, "Label switching is accomplished by associating labels with Forwarding Equivalence Classes, and using the label value to forward packets, including determining the value of any replacement label. See [1] for further details. In an ATM-LSR, the label is carried in the VPI/VCI field, or, when two ATM-LSRs are connected via an ATM "Virtual Path", in the VCI field." I am wondering why it is in the VCI field rather than VPI field. I thought if the two ATM-LSRs are connected via virtual circuit, then forwarding should be based on the VPI/VCI field, if the two ATM-LSRs are connected visa virtual path, then forwarding should be based on the VPI field. Regards, Jane D. Jiang From owner-mpls@UU.NET Fri Feb 23 17:08:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24342 for ; Fri, 23 Feb 2001 17:08: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 QQkdrc16734; Fri, 23 Feb 2001 22:08:12 GMT Received: by mail-control.mail.uu.net id QQkdrc11850 for mpls-outgoing; Fri, 23 Feb 2001 22:07:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdrc11800 for ; Fri, 23 Feb 2001 22:07:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdrc03870 for ; Fri, 23 Feb 2001 22:07:13 GMT Received: from ersfirep1 by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.jasper.com [64.19.21.34] (may be forged)) id QQkdrc00823 for ; Fri, 23 Feb 2001 22:07:12 GMT Received: by ersfirep1; id QAA04764; Fri, 23 Feb 2001 16:08:09 -0600 (CST) Received: from unknown(10.0.0.65) by ersfirep1.erlangtech.com via smap (V5.5) id xma004713; Fri, 23 Feb 01 16:07:59 -0600 Message-ID: <02e401c09de4$e857b3e0$4100000a@internal.erlangtech.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: , , , References: Subject: Re: MPLS using LDP and ATM VC Switching Date: Fri, 23 Feb 2001 16:06:44 -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 ----- Original Message ----- From: To: ; ; Sent: Friday, February 23, 2001 3:44 PM Subject: MPLS using LDP and ATM VC Switching > Hi Everyone, > > I have a question regarding RFC3035. There is a paragraph in RFC3035, page > 5 to page 6, says, > "Label switching is accomplished by associating labels with Forwarding > Equivalence Classes, and using the label value to forward packets, > including determining the value of any replacement label. See [1] for > further details. In an ATM-LSR, the label is carried in the VPI/VCI field, > or, when two ATM-LSRs are connected via an ATM "Virtual Path", in the VCI > field." > > I am wondering why it is in the VCI field rather than VPI field. I thought > if the two ATM-LSRs are connected via virtual circuit, then forwarding > should be based on the VPI/VCI field, if the two ATM-LSRs are connected > visa virtual path, then forwarding should be based on the VPI field. > If the two ATM-LSRs ard connected via Virtual Path, VP switching is conducted by native ATM switching function and can not be controlled (label allocation/deallocation) by MPLS controller/function. In viewpoint of MPLS function, VP is a just virtual link, thus VCI field should be used for MPLS label allcation/deallocation. Take care. From owner-mpls@UU.NET Fri Feb 23 19:26:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27592 for ; Fri, 23 Feb 2001 19:26: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 QQkdrl07743; Sat, 24 Feb 2001 00:26:02 GMT Received: by mail-control.mail.uu.net id QQkdrl04207 for mpls-outgoing; Sat, 24 Feb 2001 00:25: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 QQkdrl04199 for ; Sat, 24 Feb 2001 00:25:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdrl07739 for ; Sat, 24 Feb 2001 00:25:21 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkdrl28550 for ; Sat, 24 Feb 2001 00:25:21 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 8432D94006; Fri, 23 Feb 2001 19:25:17 -0500 (EST) Message-ID: <3A96FF6D.847DA184@sandburst.com> Date: Fri, 23 Feb 2001 19:25:17 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Puneet Agarwal Cc: MPLS Mailing List , Bora Akyol , Francois Le Faucheur , LiWen Wu , Shahram Davari , Bruce Davie Subject: Re: New TTL Draft References: <17C81AD1F1FED411991E006008F6D1CA0944E4@avalon.pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Puneet, Thanks for the reply. One or two comments below... You wrote: > [...] > > > > In addition, if your actually specifying a behavior (rather than > >an architecture), I believe you need to allow that the TTL may > >be decremented by a number other than one. RFC 791 states > >that RFC is decremented by at least one. Your draft states in > >several places that iTTL is decremented (I assume that the > >underscore in these cases is meant to be a minus sign) by one. > > The underscore is indeed supposed to be a minus. Will be fixed in > the next rev. I have no problems in allowing the iTTL to be > decremented by more than one. I will change the text to state that > the iTTL should be decremented by "N", where "N" is user > configured and is greater than 0. The default value of "N" > should be 1. Okay. > [...] > > > > Finally, what is the mechanism which the PHP uses to determine > >whether or not the LSP is using the pipe or the uniform model? I am > >not sure this information is currently available. > > You may be right. I looked through "draft-ietf-mpls-diff-ext-08.txt", but > did not see any method to signal the model (pipe or uniform) associated with > the LSP, using either RSVP or LDP. If it is a missing piece, then I hope > that it will be addressed by the authors of that draft. This would address the case where you are just addressing the disparity between DS usage and TTL. But what about the more general case - i.e. - where DS is not involved? The answer that how the PH knows this is out of scope, might be good enough, but I would like to know what people are thinking. I am not sure that configuration makes sense since it is not necessarily clear in every case which LSRs are going to end up being the penultimate hop for which LSPs. It really doesn't make a lot of sense to punt the issue if the current answer to the question "how could we make it work?" is "magic"... > > > -Puneet > > [...] -- Eric Gray From owner-mpls@UU.NET Fri Feb 23 21:24:00 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28850 for ; Fri, 23 Feb 2001 21:24: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 QQkdrt17112; Sat, 24 Feb 2001 02:23:45 GMT Received: by mail-control.mail.uu.net id QQkdrt15243 for mpls-outgoing; Sat, 24 Feb 2001 02:23:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdrt15231 for ; Sat, 24 Feb 2001 02:23:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdrt18039 for ; Sat, 24 Feb 2001 02:22:17 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkdrt13398 for ; Sat, 24 Feb 2001 02:22:16 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id SAA07125; Fri, 23 Feb 2001 18:22:11 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Feb 2001 18:22:11 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA0944E9@avalon.pluris.com> From: Puneet Agarwal To: "'Eric Gray'" Cc: MPLS Mailing List , Bora Akyol , Francois Le Faucheur , LiWen Wu , Shahram Davari , Bruce Davie Subject: RE: New TTL Draft Date: Fri, 23 Feb 2001 18:22:09 -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 Eric, Thanks for your comments. My comments are inline. -Puneet [...] >> [...] >> > >> > Finally, what is the mechanism which the PHP uses to determine >> >whether or not the LSP is using the pipe or the uniform model? I am >> >not sure this information is currently available. >> >> You may be right. I looked through >"draft-ietf-mpls-diff-ext-08.txt", but >> did not see any method to signal the model (pipe or uniform) >associated with >> the LSP, using either RSVP or LDP. If it is a missing piece, >then I hope >> that it will be addressed by the authors of that draft. > >This would address the case where you are just >addressing the disparity between DS usage and >TTL. But what about the more general case - >i.e. - where DS is not involved? > >The answer that how the PH knows this is out >of scope, might be good enough, but I would like >to know what people are thinking. I am not sure >that configuration makes sense since it is not >necessarily clear in every case which LSRs are >going to end up being the penultimate hop for >which LSPs. It really doesn't make a lot of >sense to punt the issue if the current answer >to the question "how could we make it work?" is >"magic"... > You are correct. In my earlier reply I overlooked the fact that this could be used in non DS cases. The issue is in some sense broader than just PH knowing the model of the LSP. The ingress and the egress LSRs also need to know the model (pipe or uniform) of the LSP so they can consistent in their handling of TTL. The ideal solution would be to add a new object to the PATH message (for RSVP) indicating the LSP model being used so that ingress/PH/egress LSRs can be consistent. Something similar can be done for LDP. In fact, even non ingress/PH/egress LSRs may also need to know the LSP model to support features, like "fast reroute", offered by some vendors. I think you and I agree that there is a hole. I am not convinced that our TTL draft is the correct place to define the signalling mechanism outlined above. I can certainly look into addressing this is in a separate draft depending on the response from the authors of "draft-ietf-mpls-diff-ext-08.txt". Hence I would rather add text to our TTL draft to the effect that "how the LSR knows the model of any LSP is outside the scope of this draft". -Puneet >> >> >> -Puneet >> >> [...] > >-- >Eric Gray > > From owner-mpls@UU.NET Fri Feb 23 22:17:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00257 for ; Fri, 23 Feb 2001 22:17: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 QQkdrx16592; Sat, 24 Feb 2001 03:17:28 GMT Received: by mail-control.mail.uu.net id QQkdrx04292 for mpls-outgoing; Sat, 24 Feb 2001 03:17:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdrx04284 for ; Sat, 24 Feb 2001 03:17:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdrx18882 for ; Sat, 24 Feb 2001 03:15:21 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdrx24495 for ; Sat, 24 Feb 2001 03:15:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA10542 for mpls@uu.net; Fri, 23 Feb 2001 22:15:20 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdrw03942 for ; Sat, 24 Feb 2001 03:14:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdrw04479 for ; Sat, 24 Feb 2001 03:14:46 GMT Received: from avocet.prod.itd.earthlink.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: avocet.prod.itd.earthlink.net [207.217.121.50]) id QQkdrw10191 for ; Sat, 24 Feb 2001 03:14:45 GMT Received: from AMALIS.earthlink.net (1Cust55.tnt2.stuart.fl.da.uu.net [63.29.32.55]) by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id TAA20034; Fri, 23 Feb 2001 19:14:41 -0800 (PST) Message-Id: <5.0.2.1.2.20010223220451.03c06a78@viva.vivacenet.com> X-Sender: andymalis@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 23 Feb 2001 22:07:51 -0500 To: pwot@ietf.org, mpls@UU.NET From: "Andrew G. Malis" Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt Cc: "Thomas D. Nadeau" , "Andrew G. Malis" , , , "tom k. johnson" , "Scott C. Park" In-Reply-To: <4.3.2.7.2.20010223150102.06a62cf8@bucket.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_740102681==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_740102681==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Please note that this MIB is based on draft-malis-sonet-ces-mpls-02.txt, for which comments are also solicited. URL: http://www.ietf.org/internet-drafts/draft-malis-sonet-ces-mpls-02.txt Thanks, Andy --------- At 2/23/2001 03:11 PM -0500, Thomas D. Nadeau wrote: > Hi, > > FYI a new MIB for managing SONET/SDH Circuit Emulation >Service Over MPLS has been posted. It should be available >shortly via the IETF's web site. In the meantime, it is available >at the following web/ftp link. As usual, comments are welcome. > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces-mpls-mib-00.txt > > --Tom --=====================_740102681==_.ALT Content-Type: text/html; charset="us-ascii" Please note that this MIB is based on draft-malis-sonet-ces-mpls-02.txt, for which comments are also solicited.

URL: http://www.ietf.org/internet-drafts/draft-malis-sonet-ces-mpls-02.txt

Thanks,
Andy

---------

At 2/23/2001 03:11 PM -0500, Thomas D. Nadeau wrote:

        Hi,

        FYI a new MIB for managing SONET/SDH Circuit Emulation
Service Over MPLS has been posted. It should be available
shortly via the IETF's web site. In the meantime, it is available
at the following web/ftp link. As usual, comments are welcome.

ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces-mpls-mib-00.txt

        --Tom
--=====================_740102681==_.ALT-- From owner-mpls@UU.NET Sat Feb 24 10:54:38 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20334 for ; Sat, 24 Feb 2001 10:54: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 QQkdtv24423; Sat, 24 Feb 2001 15:54:22 GMT Received: by mail-control.mail.uu.net id QQkdtv21507 for mpls-outgoing; Sat, 24 Feb 2001 15:53:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdtv21502 for ; Sat, 24 Feb 2001 15:53:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdtv22120 for ; Sat, 24 Feb 2001 15:53:39 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkdtv12416 for ; Sat, 24 Feb 2001 15:53:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA06550 for mpls@uu.net; Sat, 24 Feb 2001 10:53:37 -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 QQkdtv21493 for ; Sat, 24 Feb 2001 15:53:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdtv13116 for ; Sat, 24 Feb 2001 15:52:45 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkdtv26664 for ; Sat, 24 Feb 2001 15:52:44 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id HAA12542 for ; Sat, 24 Feb 2001 07:52:44 -0800 (PST) From: Bora Akyol Received: (from akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) id HAA02089 for mpls@uu.net; Sat, 24 Feb 2001 07:52:43 -0800 (PST) Date: Sat, 24 Feb 2001 07:52:43 -0800 (PST) Message-Id: <200102241552.HAA02089@volsung.pluris.com> To: mpls@UU.NET Subject: New Internet Draft on ERO Sender: owner-mpls@UU.NET Precedence: bulk We have posted a new Internet Draft on ERO in RSVP-TE. We welcome comments from the MPLS WG. The draft can be found at: http://www.ietf.org/internet-drafts/draft-akyol-mpls-exp-ero-00.txt Regards Bora Akyol From owner-mpls@UU.NET Sat Feb 24 10:59:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20360 for ; Sat, 24 Feb 2001 10:59: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 QQkdtv05103; Sat, 24 Feb 2001 15:59:35 GMT Received: by mail-control.mail.uu.net id QQkdtv21691 for mpls-outgoing; Sat, 24 Feb 2001 15:59:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdtv21685 for ; Sat, 24 Feb 2001 15:59:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdtv04212 for ; Sat, 24 Feb 2001 15:58:48 GMT From: djiang1@lucent.com Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkdtv04062 for ; Sat, 24 Feb 2001 15:58:48 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25705 for ; Sat, 24 Feb 2001 10:58:48 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25686; Sat, 24 Feb 2001 10:58:43 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA02867; Sat, 24 Feb 2001 10:58:42 -0500 (EST) Subject: MPLS using LDP and ATM VC Switching--2 To: bsd@cisco.com, pdoolan@ennovatenetworks.com, mpls@UU.NET Date: Sat, 24 Feb 2001 10:54:54 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/24/2001 10:54:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Everyone, Second question on RFC3035. On page 6 of RFC3035, paragraph2, it says: "Label packets MUST be transmitted using the null encapsulation, as defined in Section 6.1 of RFC 2684 [5]." Does it mean that IP/MPLS over ATM has to use VC multiplexing, and LLC multiplexing will not be supported? Thanks. Regards, Jane D. Jiang From owner-mpls@UU.NET Sun Feb 25 13:27:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11869 for ; Sun, 25 Feb 2001 13:27: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 QQkdxx19207; Sun, 25 Feb 2001 18:26:52 GMT Received: by mail-control.mail.uu.net id QQkdxx15769 for mpls-outgoing; Sun, 25 Feb 2001 18:26:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdxx15760 for ; Sun, 25 Feb 2001 18:26:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdxx24503 for ; Sun, 25 Feb 2001 18:26:17 GMT Received: from abel.senecanetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQkdxx20933 for ; Sun, 25 Feb 2001 18:26:17 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id IAA32026; Sun, 25 Feb 2001 08:26:26 -0600 Received: from vsharmapc ([10.0.1.69]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id IAA31983; Sun, 25 Feb 2001 08:26:25 -0600 From: "Vipul Sharma" To: , , Cc: Subject: FW: Errored packets in the MPLS MIB... Date: Sun, 25 Feb 2001 13:25:50 -0500 Message-ID: <002801c09f58$62075500$4501000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-scanner: echelon Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi!, In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored packets. For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The number of errored packets received on this segment." My question is what type of errors make these packets errored packets because most errored packets are dropped at the physical interface iteself by the chips (my understanding). So does this stats put a req. to run the phy. interface device in promiscous mode? So that we see all errored packets and then collect stats on them per LSP? Sounds like a lot of overhead... Could some of you experts keep me honest on this one.. Thanx. Vip From owner-mpls@UU.NET Sun Feb 25 13:29:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11880 for ; Sun, 25 Feb 2001 13:29: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 QQkdxx25022; Sun, 25 Feb 2001 18:29:25 GMT Received: by mail-control.mail.uu.net id QQkdxx15958 for mpls-outgoing; Sun, 25 Feb 2001 18:28:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdxx15910 for ; Sun, 25 Feb 2001 18:28:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdxx29142 for ; Sun, 25 Feb 2001 18:28:15 GMT Received: from abel.senecanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQkdxx21277 for ; Sun, 25 Feb 2001 18:28:15 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id IAA32127; Sun, 25 Feb 2001 08:28:45 -0600 Received: from vsharmapc ([10.0.1.69]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id IAA32084; Sun, 25 Feb 2001 08:28:45 -0600 From: "Vipul Sharma" To: , , , Subject: FW: Errored packets in the MPLS MIB... Date: Sun, 25 Feb 2001 13:28:10 -0500 Message-ID: <002901c09f58$b5446230$4501000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-scanner: echelon Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi!, In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored packets. For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The number of errored packets received on this segment." My question is what type of errors make these packets errored packets because most errored packets are dropped at the physical interface iteself by the chips (my understanding). So does this stats put a req. to run the phy. interface device in promiscous mode? So that we see all errored packets and then collect stats on them per LSP? Sounds like a lot of overhead... Could some of you experts keep me honest on this one.. Thanx. Vip From owner-mpls@UU.NET Sun Feb 25 21:32:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14569 for ; Sun, 25 Feb 2001 21:32: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 QQkdze28750; Mon, 26 Feb 2001 02:32:23 GMT Received: by mail-control.mail.uu.net id QQkdze17412 for mpls-outgoing; Mon, 26 Feb 2001 02:31:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkdze17407 for ; Mon, 26 Feb 2001 02:31:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdze08336 for ; Mon, 26 Feb 2001 02:31:40 GMT Received: from inet-tsb.toshiba.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40]) id QQkdze27726 for ; Mon, 26 Feb 2001 02:31:35 GMT Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id LAA10652; Mon, 26 Feb 2001 11:31:33 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id LAA26474; Mon, 26 Feb 2001 11:31:32 +0900 (JST) Received: from chappy.cns.fuchu.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id LAA26467; Mon, 26 Feb 2001 11:31:31 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by chappy.cns.fuchu.toshiba.co.jp (8.11.2/8.11.2) with ESMTP id f1Q2YAZ08611; Mon, 26 Feb 2001 11:34:10 +0900 (JST) Date: Mon, 26 Feb 2001 11:34:05 +0900 Message-ID: From: Ken Nagami To: djiang1@lucent.com Cc: mpls@UU.NET Subject: Re: Outband VCID notification for LDP In-Reply-To: References: User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.4 (i386-unknown-freebsdelf3.3) MULE/4.0 (HANANOEN) Organization: Toshiba MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 990905(IM130) Lines: 32 Sender: owner-mpls@UU.NET Precedence: bulk Hi Jane, >> Hi Everyone, >> I have a question regarding outband VCID notiffication for LDP. >> On page 4 of RFC3038, section 3.1.1, point 2, it says for inband >> notification: >> "The node A sends a VCID PROPOSE message which contains the VCID value and >> a message ID through the newly established VC to the node B." >> I can understand that it is an inband notification message. >> However, on page 8 of RFC3038, section 3.2.1, point 2, it says for outband >> notification: >> "The upstream LSR sends the VCID PROPOSE message through the VC for LDP to >> notify the downstream LSR of the association between the BLLI and VCID >> values." >> I some how that the above is actually an inband notification as the refered >> VC is used. The diffrence between these two is as follows: In section 3.1.1 (Inband notification): VCID PROPOSE message sends through the newly established VC. ~~~~~~~~~~~~~~~~~~~~~~~~ In section 3.2.1 (Outband notification): VCID PROPOSE messasge sends through the VC for LDP. This is not the ~~~~~~~~~~~~~~ newly established VC. Is it clear to you? From owner-mpls@UU.NET Sun Feb 25 21:57:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15569 for ; Sun, 25 Feb 2001 21:57: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 QQkdzf29048; Mon, 26 Feb 2001 02:57:25 GMT Received: by mail-control.mail.uu.net id QQkdzf18966 for mpls-outgoing; Mon, 26 Feb 2001 02:56:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdzf18961 for ; Mon, 26 Feb 2001 02:56:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkdzf19689 for ; Mon, 26 Feb 2001 02:56:03 GMT Received: from smtp.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQkdzf29780 for ; Mon, 26 Feb 2001 02:55:51 GMT Received: from z97716 ([10.110.10.147]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G9CFZ800.210 for ; Mon, 26 Feb 2001 10:52:20 +0800 Message-ID: <002601c09f9f$b234e000$930a6e0a@huawei.com> From: "Heqing Zhu" To: Subject: Backup LSP vs Fast reroute Date: Mon, 26 Feb 2001 10:56:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA15569 Hi,All: Being a new comer, some questions confuse me. I know some difference between Backup LSP and Fast Reroute. But I don't know, If I specify a static LSP like Backup LSP to implement Fast Reroute. What is main difference between Backup LSP and Fast Reroute? Thanks for your help! Heqing Zhu From owner-mpls@UU.NET Mon Feb 26 00:00:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17623 for ; Mon, 26 Feb 2001 00:00: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 QQkdzn01958; Mon, 26 Feb 2001 04:59:57 GMT Received: by mail-control.mail.uu.net id QQkdzn26847 for mpls-outgoing; Mon, 26 Feb 2001 04:59: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 QQkdzn26842 for ; Mon, 26 Feb 2001 04:59:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdzn29108 for ; Mon, 26 Feb 2001 04:58:23 GMT Received: from satoru.prism by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.128.193]) id QQkdzn05369 for ; Mon, 26 Feb 2001 04:58:22 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.1/8.11.1) with ESMTP id f1Q4vfv00341 for ; Mon, 26 Feb 2001 13:57:42 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: mpls@UU.NET Subject: NEW: draft-satoru-mpls-1hop-lsp-00.txt X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010226135741Y.satoru@japan-telecom.co.jp> Date: Mon, 26 Feb 2001 13:57:41 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I have submitted an Internet Draft. Title: TTL Processing expansion for 1-hop LSP File : draft-satoru-mpls-1hop-lsp-00.txt This draft is available at below url until it is moved to the Internet-Drafts repository. http://www.net-work.ne.jp/~satoru/draft-satoru-mpls-1hop-lsp-00.txt We welcom any comments. -- Satoru Matsushima From owner-mpls@UU.NET Mon Feb 26 01:04:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17887 for ; Mon, 26 Feb 2001 01:04: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 QQkdzs19406; Mon, 26 Feb 2001 06:04:11 GMT Received: by mail-control.mail.uu.net id QQkdzs00374 for mpls-outgoing; Mon, 26 Feb 2001 06:03:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkdzs29070 for ; Mon, 26 Feb 2001 06:03:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkdzs08774 for ; Mon, 26 Feb 2001 06:03:11 GMT Received: from satoru.prism by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.128.193]) id QQkdzs17403 for ; Mon, 26 Feb 2001 06:03:10 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.1/8.11.1) with ESMTP id f1Q61kv00439; Mon, 26 Feb 2001 15:01:46 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: puneet@pluris.com Cc: eric.gray@sandburst.com, mpls@UU.NET, akyol@pluris.com, flefauch@cisco.com, liwwu@cisco.com, Shahram_Davari@pmc-sierra.com, bdavie@cisco.com Subject: RE: New TTL Draft In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA0944E9@avalon.pluris.com> References: <17C81AD1F1FED411991E006008F6D1CA0944E9@avalon.pluris.com> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010226150146C.satoru@japan-telecom.co.jp> Date: Mon, 26 Feb 2001 15:01:46 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Puneet, I think you described very well the ttl processing on hierarchical MPLS network. You wrote: > Hence I would rather add text to our TTL draft to the effect that "how the > LSR knows the model of any LSP is outside the scope of this draft". > > -Puneet As a matter of fact, I have submitted an i-d which is described this problem. Please see below url, and give me your thoughts on my i-d. thanks, http://www.net-work.ne.jp/~satoru/draft-satoru-mpls-1hop-lsp-00.txt -- Satoru Matsushima From owner-mpls@UU.NET Mon Feb 26 04:45:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03208 for ; Mon, 26 Feb 2001 04:45: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 QQkeag08275; Mon, 26 Feb 2001 09:44:53 GMT Received: by mail-control.mail.uu.net id QQkeag00172 for mpls-outgoing; Mon, 26 Feb 2001 09:44:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeag00167 for ; Mon, 26 Feb 2001 09:44:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeag08670 for ; Mon, 26 Feb 2001 09:43:29 GMT From: neil.2.harrison@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 QQkeag10845 for ; Mon, 26 Feb 2001 09:43:28 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Mon, 26 Feb 2001 09:32:57 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <1TTHFJY8>; Mon, 26 Feb 2001 09:34:08 -0000 Message-ID: To: giles@level3.net Cc: Indra.Widjaja@fnc.fujitsu.com, Ben.Mack-Crane@tellabs.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: MPLS OAM? (was Re: PHP negotiation) Date: Mon, 26 Feb 2001 09:33:57 -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 Giles Heron [mailto:giles@level3.net] noted 20 February 2001 15:27 > I'd say that you'd want to decouple defect handling from QoS > measurement? NH=> You must do this. As I have said many time now, QoS is only valid when the trail is in the 'up-state'. So unless you know this 1st and foremost (and this means having clear entry/exit criteria for unavailability which, in turn, are predicated on clear entry/exit criteria for defects) then the measurement of QoS has not robust foundation. > > As far as I can tell the CV, BDI, and FDI flows are aimed at defect > handling, and the P flow at performance/QoS measurement? NH=>Effectively yes.....except that (i) the *degree* of QoS we want to measure with the P flow needs agreeing (cost/benefit trade-off), and (ii) availability is a QoS measure itself (indeed its the most important QoS measure for customers). So far in our debates on the P flow we have focused on the next step-up (from defects) that we need to give Ops people for in-service trouble-shooting....and this is somewhat different to 'pure' QoS per se. Recall....there are at least 4 activities that need some form of QoS measurement (and one must overload one of these to do the task of the others....again cost/benefit issue): - defects detection/diagnosis (aimed at Ops people, must measure availability and protect customer traffic, eg security from misrouting).....this is aspect we are concentrating on, since we see it as the most important; - ad hoc detailed network QoS sampling (to give general trends and spot latent problems) - node/link utilisations (feeds to TE and planning/forecast cycle) - policing/shaping actions (to watch for excessive reclassification/discard activity) > > It may be that this is an "either, or, or both" type of situation? > Defect handling could be applied to "trunk" LSPs in the > network (though > in some ways I'd question the need for this in the presence > of the label > distribution protocols - surely if a connectivity defect > occurs then the > label mapping will be withdrawn by RSVP or LDP?) NH=> I think Peter Willis gave you some answers why this is not sufficient. I could add more, but there seems little advantage to labour the clear differences between user-plane and control-plane behaviour and why each needs its own OAM tools. > > > The CV, BDI and FDI flows should all be sent through the network with > EXP values set for minimum loss/delay (I think you have specified this > in your doc.) NH=> We have considered these aspects quite carefully and hopefully got it right. Shahram has given excellent steer here. From owner-mpls@UU.NET Mon Feb 26 05:24:51 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03489 for ; Mon, 26 Feb 2001 05:24: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 QQkeaj18047; Mon, 26 Feb 2001 10:24:35 GMT Received: by mail-control.mail.uu.net id QQkeaj18097 for mpls-outgoing; Mon, 26 Feb 2001 10:24:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeaj18084 for ; Mon, 26 Feb 2001 10:24:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeaj08116; Mon, 26 Feb 2001 10:23:26 GMT Received: from qnsgs000.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31]) id QQkeaj15955; Mon, 26 Feb 2001 10:22:54 GMT Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 26 Feb 2001 10:22:21 +0000 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 10:22:19 -0000 Message-ID: From: "Mark Gibson" To: "'ccamp@ops.ietf.org'" Cc: mpls@UU.NET, te-wg@UU.NET, nbvpn@bbo.com Date: Mon, 26 Feb 2001 10:22:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09FDD.FD4D6330" 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_01C09FDD.FD4D6330 Content-Type: text/plain; charset="iso-8859-1" The following Internet Draft is now available from the online document store: http://search.ietf.org/internet-drafts/draft-gibson-mpls-srcroute-00.txt Abstract This memo sets out an MPLS-based solution to the IP service delivery problems as set out in RFC 2990. The solution is based on source routing of IP flows using MPLS label stacks. The solution elements are introduced sequentially and a usage scenario is mapped out that aligns with the work in the ISSLL working group. It is intended to pursue this as an informational draft but it has relevance to the CCAMP wg directly and to the other wgs CC'd on this email. (apologies for the cross-post spamming but I wanted to make sure I didn't miss anyone out). Mark ------_=_NextPart_001_01C09FDD.FD4D6330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The = following Internet Draft is now available from the online document = store:

http://search.ietf.org/internet-drafts/draft-gibson-mp= ls-srcroute-00.txt

Abstract

   This memo sets out an MPLS-based solution to the IP = service delivery

   problems as set out in RFC 2990. The solution is = based on source

   routing of IP flows using MPLS label stacks.  =

   

   The solution elements are introduced sequentially and = a usage

   scenario is mapped out that aligns with the work in = the ISSLL working

   group.

It is = intended to pursue this as an informational draft but it has relevance = to the CCAMP wg directly and to the other wgs CC'd on this email. (apologies for the cross-post spamming but I = wanted to make sure I didn't miss anyone out).

Mark

------_=_NextPart_001_01C09FDD.FD4D6330-- From owner-mpls@UU.NET Mon Feb 26 07:08:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05336 for ; Mon, 26 Feb 2001 07:08: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 QQkeaq26981; Mon, 26 Feb 2001 12:08:21 GMT Received: by mail-control.mail.uu.net id QQkeaq25013 for mpls-outgoing; Mon, 26 Feb 2001 12:07: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 QQkeaq25007 for ; Mon, 26 Feb 2001 12:07: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 QQkeaq20901 for ; Mon, 26 Feb 2001 12:07:15 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeaq29166 for ; Mon, 26 Feb 2001 12:07:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA07623 for mpls@uu.net; Mon, 26 Feb 2001 07:07:14 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeaq24844 for ; Mon, 26 Feb 2001 12:06:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeaq08943 for ; Mon, 26 Feb 2001 12:06:05 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 QQkeaq07609 for ; Mon, 26 Feb 2001 12:06: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 HAA04649; Mon, 26 Feb 2001 07:06:04 -0500 (EST) Message-Id: <200102261206.HAA04649@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-gibson-mpls-srcroute-00.txt Date: Mon, 26 Feb 2001 07:06:04 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Achieving Assured Service Levels through Source Routed MPLS Author(s) : M. Gibson Filename : draft-gibson-mpls-srcroute-00.txt Pages : 23 Date : 23-Feb-01 This memo sets out an MPLS-based solution to the IP service delivery problems as set out in RFC 2990. The solution is based on source routing of IP flows using MPLS label stacks. The solution elements are introduced sequentially and a usage scenario is mapped out that aligns with the work in the ISSLL working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gibson-mpls-srcroute-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-gibson-mpls-srcroute-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-gibson-mpls-srcroute-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: <20010223130749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gibson-mpls-srcroute-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-gibson-mpls-srcroute-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010223130749.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Feb 26 07:50:32 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07100 for ; Mon, 26 Feb 2001 07:50: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 QQkeat12136; Mon, 26 Feb 2001 12:50:11 GMT Received: by mail-control.mail.uu.net id QQkeat28731 for mpls-outgoing; Mon, 26 Feb 2001 12:49: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 QQkeat28725 for ; Mon, 26 Feb 2001 12:49: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 QQkeat21130 for ; Mon, 26 Feb 2001 12:49:06 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeat10614 for ; Mon, 26 Feb 2001 12:49:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA07676 for mpls@uu.net; Mon, 26 Feb 2001 07:08:15 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeaq24981 for ; Mon, 26 Feb 2001 12:07:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeaq02050 for ; Mon, 26 Feb 2001 12:07:14 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 QQkeaq09756 for ; Mon, 26 Feb 2001 12:07: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 HAA05002; Mon, 26 Feb 2001 07:07:13 -0500 (EST) Message-Id: <200102261207.HAA05002@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-akyol-mpls-exp-ero-00.txt Date: Mon, 26 Feb 2001 07:07:13 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Expanded Explicit Route Object for RSVP-TE Author(s) : B. Akyol et al. Filename : draft-akyol-mpls-exp-ero-00.txt Pages : 16 Date : 23-Feb-01 This document expands the Explicit Route Object (ERO) defined in [RSVP-TE]. The primary reason for the expansion of the ERO is to simplify the processing of abstract nodes and loose routes as well as to specify globally unique interface identifiers in case of unnumbered interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-akyol-mpls-exp-ero-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-akyol-mpls-exp-ero-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-akyol-mpls-exp-ero-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: <20010223130950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-akyol-mpls-exp-ero-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-akyol-mpls-exp-ero-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010223130950.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Feb 26 08:12:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07840 for ; Mon, 26 Feb 2001 08:12: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 QQkeau16523; Mon, 26 Feb 2001 13:12:22 GMT Received: by mail-control.mail.uu.net id QQkeau15977 for mpls-outgoing; Mon, 26 Feb 2001 13:11:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeau15970 for ; Mon, 26 Feb 2001 13:11:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeau27369 for ; Mon, 26 Feb 2001 13:11:19 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkeau09940 for ; Mon, 26 Feb 2001 13:11:19 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f1QDBHR27343 for ; Mon, 26 Feb 2001 14:11:17 +0100 (MET) Received: from alcatel.be ([138.203.169.199]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569FF.00486F4A; Mon, 26 Feb 2001 14:11:10 +0100 Message-ID: <3A9A5601.D47C541A@alcatel.be> Date: Mon, 26 Feb 2001 14:11:29 +0100 From: Paul Moore Organization: Alcatel Bell X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS LSPs and ATM PVCs 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 about MPLS and ATM. ATM point-to-point PVCs can be either uni-directional or bi-directional. MPLS LSPs are only uni-directional. Is there any work being done concerning bi-directional LSPs, for example, to allow two LSPs to be established by a single RSVP signalling operation? I've just joined the list, so apologies if this has already been discussed. Thanks, Paul -- Paul Moore Alcatel Bell +32 3 450 3536 paul-patrick.moore@alcatel.be From owner-mpls@UU.NET Mon Feb 26 08:56:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09306 for ; Mon, 26 Feb 2001 08:56: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 QQkeax24247; Mon, 26 Feb 2001 13:56:07 GMT Received: by mail-control.mail.uu.net id QQkeax19495 for mpls-outgoing; Mon, 26 Feb 2001 13:55:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeax19486 for ; Mon, 26 Feb 2001 13:55: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 QQkeax02473 for ; Mon, 26 Feb 2001 13:55:29 GMT From: djiang1@lucent.com 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 QQkeax23320 for ; Mon, 26 Feb 2001 13:55:29 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 IAA06533 for ; Mon, 26 Feb 2001 08:55:28 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA06520; Mon, 26 Feb 2001 08:55:27 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA25501; Mon, 26 Feb 2001 08:55:27 -0500 (EST) Subject: Re: MPLS LSPs and ATM PVCs To: Paul Moore Cc: mpls@UU.NET Date: Mon, 26 Feb 2001 08:51:36 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/26/2001 08:51:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk HI Paul, I believe RSVP is never intended to set up two LSPs using one single operation. We will have to use two RSVP signalling operations to set up the two LSPs, one for each direction, even if the PVC may be used bidirectionally. Regards, Jane D. Jiang Paul Moore @UU.NET on 02/26/2001 08:11:29 AM Sent by: owner-mpls@UU.NET To: mpls@UU.NET cc: Subject: MPLS LSPs and ATM PVCs Hello, I have a question about MPLS and ATM. ATM point-to-point PVCs can be either uni-directional or bi-directional. MPLS LSPs are only uni-directional. Is there any work being done concerning bi-directional LSPs, for example, to allow two LSPs to be established by a single RSVP signalling operation? I've just joined the list, so apologies if this has already been discussed. Thanks, Paul -- Paul Moore Alcatel Bell +32 3 450 3536 paul-patrick.moore@alcatel.be From owner-mpls@UU.NET Mon Feb 26 09:18:56 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10062 for ; Mon, 26 Feb 2001 09:18: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 QQkeaz13249; Mon, 26 Feb 2001 14:18:39 GMT Received: by mail-control.mail.uu.net id QQkeaz06439 for mpls-outgoing; Mon, 26 Feb 2001 14:18: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 QQkeaz06421 for ; Mon, 26 Feb 2001 14:17: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 QQkeaz02335 for ; Mon, 26 Feb 2001 14:15:53 GMT Received: from edgeflow.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.191.40.82]) id QQkeaz08300 for ; Mon, 26 Feb 2001 14:15:53 GMT Received: from edgsvr01.edgeflow.edgeflow.com ([10.0.1.10]) by watchdog.edgeflow.com with ESMTP id <119043>; Mon, 26 Feb 2001 09:15:42 -0500 Received: by edgsvr01.edgeflow.edgeflow.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 09:12:19 -0500 Message-ID: <89E067900D3FA84A97495C71556140E402D8AA@edgsvr01.edgeflow.edgeflow.com> From: Dmitry Ryumkin To: "'djiang1@lucent.com'" , Paul Moore Cc: mpls@UU.NET Subject: RE: MPLS LSPs and ATM PVCs Date: Mon, 26 Feb 2001 09:12:18 -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 Paul, Generalized MPLS defines procedures for bi-directional LSP setup. Regards, Dmitry Ryumkin -----Original Message----- From: djiang1@lucent.com [mailto:djiang1@lucent.com] Sent: Monday, February 26, 2001 8:52 AM To: Paul Moore Cc: mpls@UU.NET Subject: Re: MPLS LSPs and ATM PVCs HI Paul, I believe RSVP is never intended to set up two LSPs using one single operation. We will have to use two RSVP signalling operations to set up the two LSPs, one for each direction, even if the PVC may be used bidirectionally. Regards, Jane D. Jiang Paul Moore @UU.NET on 02/26/2001 08:11:29 AM Sent by: owner-mpls@UU.NET To: mpls@UU.NET cc: Subject: MPLS LSPs and ATM PVCs Hello, I have a question about MPLS and ATM. ATM point-to-point PVCs can be either uni-directional or bi-directional. MPLS LSPs are only uni-directional. Is there any work being done concerning bi-directional LSPs, for example, to allow two LSPs to be established by a single RSVP signalling operation? I've just joined the list, so apologies if this has already been discussed. Thanks, Paul -- Paul Moore Alcatel Bell +32 3 450 3536 paul-patrick.moore@alcatel.be From owner-mpls@UU.NET Mon Feb 26 09:30:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10420 for ; Mon, 26 Feb 2001 09:30: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 QQkeba01589; Mon, 26 Feb 2001 14:30:41 GMT Received: by mail-control.mail.uu.net id QQkeba07257 for mpls-outgoing; Mon, 26 Feb 2001 14:30:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeba07252 for ; Mon, 26 Feb 2001 14:30:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeaz25984 for ; Mon, 26 Feb 2001 14:29:57 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkeaz00363 for ; Mon, 26 Feb 2001 14:29:56 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 GAA16397 for ; Mon, 26 Feb 2001 06:30:14 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA22128 for mpls@uu.net; Mon, 26 Feb 2001 09:29:55 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkdzi06617 for ; Mon, 26 Feb 2001 03:34:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkdzi12356 for ; Mon, 26 Feb 2001 03:32:42 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 QQkdzi21172 for ; Mon, 26 Feb 2001 03:32:42 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Sun, 25 Feb 2001 19:32:26 -0800 Message-ID: From: Vishal Sharma To: "'Heqing Zhu'" , mpls@UU.NET Subject: RE: Backup LSP vs Fast reroute Date: Sun, 25 Feb 2001 19:32:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Heqing, Typically, the use of the term "backup LSP" tends to imply that you are setting up, a priori, an LSP to which traffic can be switched, in case of failure on that segment of the primary LSP that is protected by the "backup" LSP. This gives a one-for-one or a one-plus-one mode of protection (depending on whether or not you choose to transmit actual data on the backup LSP). A lot of this terminology is clarified and defined in the MPLS-recovery framework document http://search.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-01.tx t However, even to effect "fast reroute" you would need to set up an LSP between the nodes across which you wish to effect "fast reroute"; a "backup LSP", if you will. In case of a failure of the link between the two nodes, the node upstream of the point of failure would perform a label swap and a push, pushing on the label of the "backup LSP." If penultimate hop popping is in effect, the node downstream of the failed link will receive labeled packets with the exact same label with which it would have received them over the link that failed. Assuming the downstream node uses a global label space, it would be able to label switch the data. In this case, the "backup LSP" can rightly be called a "backup tunnel", since it allows for all LSPs traveling on the failed link to be "tunnelled through" the "backup tunnel" to the downstream node. A draft describing this approach is http://search.ietf.org/internet-drafts/draft-swallow-rsvp-bypass-label-01.tx t (Note, however, that the signaling extensions proposed in this draft neither address the case of non-global label spaces nor the case where the nodes between which a backup tunnel is setup are separated by more than one link.) A general solution for signaling "backup LSPs" appears in http://search.ietf.org/internet-drafts/draft-chang-mpls-path-protection-02.t xt and the protocol-specific extensions to realize this solution appear in two companion drafts http://search.ietf.org/internet-drafts/draft-chang-mpls-rsvpte-path-protecti on-ext-01.txt and http://search.ietf.org/internet-drafts/draft-owens-crldp-path-protection-ext -00.txt -Vishal >-----Original Message----- >From: Heqing Zhu [mailto:zhuheqing@huawei.com] >Sent: Sunday, February 25, 2001 6:56 PM >To: mpls@UU.NET >Subject: Backup LSP vs Fast reroute > > >Hi,All: > >Being a new comer, some questions confuse me. >I know some difference between Backup LSP and Fast Reroute. >But I don't know, If I specify a static LSP like Backup LSP to >implement Fast Reroute. >What is main difference between Backup LSP and Fast Reroute? >Thanks for your help! > >Heqing Zhu > From owner-mpls@UU.NET Mon Feb 26 09:33:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10525 for ; Mon, 26 Feb 2001 09:33: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 QQkeba04722; Mon, 26 Feb 2001 14:32:45 GMT Received: by mail-control.mail.uu.net id QQkeba07388 for mpls-outgoing; Mon, 26 Feb 2001 14:32: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 QQkeba07366 for ; Mon, 26 Feb 2001 14:32: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 QQkeba14127 for ; Mon, 26 Feb 2001 14:30:14 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 QQkeba00869 for ; Mon, 26 Feb 2001 14:30:13 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 GAA16753 for ; Mon, 26 Feb 2001 06:30:31 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA22132 for mpls@uu.net; Mon, 26 Feb 2001 09:30:11 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeal20144 for ; Mon, 26 Feb 2001 10:56:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeal23787 for ; Mon, 26 Feb 2001 10:55:05 GMT Received: from cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQkeal26164 for ; Mon, 26 Feb 2001 10:55:03 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 411 for ; Mon, 26 Feb 2001 18:56:36 +0800 Message-ID: <3A9A3623.227928EA@cad.zju.edu.cn> Date: Mon, 26 Feb 2001 18:55:31 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: per interface lable space validity Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I'm reading rfc3036 - "LDP specification", at section 2.2.1 Lable spaces , it is said a per interface lable space only makes sense when the LDP peers are "directly connected". what is "directly connected" ? If two LSRs are connected by a tunnel which generate another layer on Label stack , a per interface label is not meaningful ? thanks a lot. James Shen From owner-mpls@UU.NET Mon Feb 26 09:42:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10886 for ; Mon, 26 Feb 2001 09:42: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 QQkeba15648; Mon, 26 Feb 2001 14:42:35 GMT Received: by mail-control.mail.uu.net id QQkeba08262 for mpls-outgoing; Mon, 26 Feb 2001 14:42: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 QQkeba08257 for ; Mon, 26 Feb 2001 14:42: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 QQkeba14032 for ; Mon, 26 Feb 2001 14:40:35 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeba12983 for ; Mon, 26 Feb 2001 14:40:34 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA19967 for mpls@uu.net; Mon, 26 Feb 2001 09:40:34 -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 QQkeba08059 for ; Mon, 26 Feb 2001 14:39: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 QQkeba08874 for ; Mon, 26 Feb 2001 14:38:46 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 QQkeba04031 for ; Mon, 26 Feb 2001 14:38:45 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 GAA21613; Mon, 26 Feb 2001 06:38:29 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BKTXH>; Mon, 26 Feb 2001 06:41:50 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AA0@BBY1EXM01> From: Shahram Davari To: "'jshen@cad.zju.edu.cn'" , mpls@UU.NET Subject: RE: per interface lable space validity Date: Mon, 26 Feb 2001 06:41:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk Hi, In your scenario, if the signaling (CR-LDP/RSVP-TE) is tunneled through that tunnel then you can use per-interface label space, otherwise you should use per-platform label space, because you don't know from which interface the packet will arrive. Yours, -Shahram > -----Original Message----- > From: shen jing [mailto:jshen@cad.zju.edu.cn] > Sent: Monday, February 26, 2001 5:56 AM > To: mpls@UU.NET > Subject: per interface lable space validity > > > I'm reading rfc3036 - "LDP specification", at section 2.2.1 > Lable spaces > , it is said a per interface > lable space only makes sense when the LDP peers are "directly > connected". > what is "directly connected" ? If two LSRs are connected by a tunnel > which generate > another layer on Label stack , a per interface label is not > meaningful ? > > thanks a lot. > > James Shen > From owner-mpls@UU.NET Mon Feb 26 10:20:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12179 for ; Mon, 26 Feb 2001 10: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 QQkeao26573; Mon, 26 Feb 2001 11:43:53 GMT Received: by mail-control.mail.uu.net id QQkeao08214 for mpls-outgoing; Mon, 26 Feb 2001 11:43:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeao08208 for ; Mon, 26 Feb 2001 11:43:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeao04706 for ; Mon, 26 Feb 2001 11:41:51 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 QQkeao24086 for ; Mon, 26 Feb 2001 11:41:51 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 DAA23660; Mon, 26 Feb 2001 03:41:47 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id DAA17357; Mon, 26 Feb 2001 03:41:47 -0800 (PST) Date: Mon, 26 Feb 2001 03:41:47 -0800 (PST) From: Kireeti Kompella Message-Id: <200102261141.DAA17357@kummer.juniper.net> To: akyol@pluris.com, mpls@UU.NET Subject: Re: New Internet Draft on ERO In-Reply-To: <200102241552.HAA02089@volsung.pluris.com> Sender: owner-mpls@UU.NET Precedence: bulk Hi Bora, I have some comments on your draft. Section 1: Specifically, ERO definition for unnumbered interfaces is context sensitive and dependent on the order of appearance in the ERO. Note that the graph-theoretic definition of a path is an *ordered* sequence of edges (or nodes). What issue does the fact that the ERO needs to be ordered raise? Do you suppose that the EERO format that you propose does not dependent on the order of appearance? For example, if the same interface identifier is repeated twice in the ERO consecutively, the desired behavior is unclear. Actually, the desired behaviour is quite clear; if an ERO consists of <1, 1, 1, 1, 1, 1>, then the path is quite explicit: take interface #1 from the ingress; then take interface #1 from the next hop; then take interface #1 from the next hop, etc. until you reach the egress. The fact that all the interfaces are numbered 1 is wholly irrelevant; each hop is in a different numbering scope. (Note that unnumbered interfaces are always *strict* hops.) c. Different styles of specifying the ERO in different implementations. [RSVP-TE] gives the head-end LSR considerable leeway in specifying the ERO. For example, an LSR that is on the path can be specified by a router ID, an ingress (w.r.t. to the LSP) interface ID (usually an IP address), an egress interface ID or any combination of the above. This "flexibility" may cause LSP establishment and interoperability failures. These "issues" are easily solved (and are solved in practice). A BCP that describes one style for ERO specification *without* protocol changes would be a better solution (IMHO) than an entirely new ERO format that contains twice redundant information. Section 2: Ingress Interface Identifier & Egress Interface Identifier For a given link, the ingress and egress interface indices are assigned by different routers. This means that the scopes are under different router IDs. The draft contradicts that. Can you clarify? By the way, the idea of adding a router ID to unnumbered interface objects was discussed on the MPLS mailing list several months ago and discarded as unnecessary. In any case, what is the value of the router ID when the ingress/egress interface identifiers are IPv4 addresses? Also, loose hops should probably not have any associated interfaces. I'm not sure what it means to have unnumbered interface indices with loose hops. Unfortunately, I cannot make out the use of interface IDs in the context of loose hops from the description in section 3. Section 3: ERO processing There are actually eight cases: with/without EERO-HOPs, with/without AN-HOPs, with/without LR-HOPs. I fail to see how this classification helps, though. You seem to assume that LR-HOPs cannot be interspersed with EERO-HOPs, and that EERO-HOPs must be present. Is that what you meant? IMO the stated goal of "simplification of abstract node and loose route processing" has not been achieved. It may well be that ERO processing should be reworded; if so, the goal should not be to use fewer words, but rather to achieve greater clarity. Of course, the current semantics should be maintained. Kireeti. From owner-mpls@UU.NET Mon Feb 26 11:47:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15861 for ; Mon, 26 Feb 2001 11:47: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 QQkebj27342; Mon, 26 Feb 2001 16:47:30 GMT Received: by mail-control.mail.uu.net id QQkebj22585 for mpls-outgoing; Mon, 26 Feb 2001 16:47: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 QQkebj22576 for ; Mon, 26 Feb 2001 16:47:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkebj07772 for ; Mon, 26 Feb 2001 16:46:48 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkebj11783 for ; Mon, 26 Feb 2001 16:46:47 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA01325 for mpls@uu.net; Mon, 26 Feb 2001 11:46:46 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkebj22453 for ; Mon, 26 Feb 2001 16:46:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkebj12518 for ; Mon, 26 Feb 2001 16:46:04 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkebj24223 for ; Mon, 26 Feb 2001 16:45:59 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id IAA08730; Mon, 26 Feb 2001 08:45:59 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id IAA06354; Mon, 26 Feb 2001 08:45:55 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Mon, 26 Feb 2001 08:45:55 -0800 (PST) From: Bora Akyol To: Kireeti Kompella cc: mpls@UU.NET, akyol@pluris.com Subject: Re: New Internet Draft on ERO In-Reply-To: <200102261141.DAA17357@kummer.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Kireeti Thank you for your comments. The fact that you suggested that a draft without defining a new object but explicitly defining behaviors on ERO generation and processing leads me to believe that you recognize the problem that we are trying to address. I still think a new object is necessary however. Please see my comments within: On Mon, 26 Feb 2001, Kireeti Kompella wrote: > Hi Bora, > > I have some comments on your draft. > > Section 1: > > Specifically, ERO > definition for unnumbered interfaces is context sensitive and > dependent on the order of appearance in the ERO. > > Note that the graph-theoretic definition of a path is an *ordered* > sequence of edges (or nodes). What issue does the fact that the ERO > needs to be ordered raise? Do you suppose that the EERO format that > you propose does not dependent on the order of appearance? > It does depend on the order of appearance but we clearly wanted to make the case you listed below impossible: > For example, if > the same interface identifier is repeated twice in the ERO > consecutively, the desired behavior is unclear. > > Actually, the desired behaviour is quite clear; if an ERO consists of > <1, 1, 1, 1, 1, 1>, then the path is quite explicit: take interface #1 > from the ingress; then take interface #1 from the next hop; then take > interface #1 from the next hop, etc. until you reach the egress. The > fact that all the interfaces are numbered 1 is wholly irrelevant; each > hop is in a different numbering scope. (Note that unnumbered interfaces > are always *strict* hops.) > What you are assuming here is that there is one ERO hop for each hop, however, the RSVP-TE draft allows a hop to be specified by any combination of interface identifiers and router ID. I recognize the point that you are making but I think that it is advantageous to make things as clear as they can be. The EERO that we define achieves this clarity. > c. Different styles of specifying the ERO in different > implementations. [RSVP-TE] gives the head-end LSR considerable > leeway in specifying the ERO. For example, an LSR that is on the > path can be specified by a router ID, an ingress (w.r.t. to the > LSP) interface ID (usually an IP address), an egress interface ID > or any combination of the above. This "flexibility" may cause LSP > establishment and interoperability failures. > > These "issues" are easily solved (and are solved in practice). A BCP > that describes one style for ERO specification *without* protocol > changes would be a better solution (IMHO) than an entirely new ERO > format that contains twice redundant information. > I know that these issues are solved in practice, I know that our implementation solves these issues as well. One of my main motivations for this draft was to stop other implementors from making different assumptions and achieve maximal interoperability. We are still in the earlier stages of deployment for MPLS and as more and more edge devices come on-line, we will see more interoperability problems. The EERO object that we defined prevents interoperability problems since it is very strict in its definition. > Section 2: Ingress Interface Identifier & Egress Interface Identifier > > For a given link, the ingress and egress interface indices are assigned > by different routers. This means that the scopes are under different > router IDs. The draft contradicts that. Can you clarify? Kireeti, what we meant here is: The ingress and the egress interfaces through the same router. Think of threading a needle where the router is the needle. You come in through interface A and leave through interface B and both A & B belong to the same router. > > By the way, the idea of adding a router ID to unnumbered interface > objects was discussed on the MPLS mailing list several months ago and > discarded as unnecessary. I know, I was part of the discussion, but I don't recall anyone objecting to a new EERO at the time ;-) > > In any case, what is the value of the router ID when the ingress/egress > interface identifiers are IPv4 addresses? As stated in the draft, it makes EERO processing very very simple. There are no abstract node lookups, you just see if you are the router with the router ID and then associate with the UP/DOWN-stream interfaces and the LSP setup is on its way. The fact that you don't need to do a AN lookup by itself probably saves about 1/3 to 2/3 of LSP PATH processing in the node. > > Also, loose hops should probably not have any associated interfaces. > I'm not sure what it means to have unnumbered interface indices with > loose hops. Unfortunately, I cannot make out the use of interface IDs > in the context of loose hops from the description in section 3. Why? You can perfectly specify a loose hop where you want the LSP to specifically enter through interface A and leave the hop through interface B. I can see benefits of this in a regular MPLS network as well as an optical network. > > Section 3: ERO processing > > There are actually eight cases: with/without EERO-HOPs, with/without > AN-HOPs, with/without LR-HOPs. I fail to see how this classification > helps, though. You seem to assume that LR-HOPs cannot be interspersed > with EERO-HOPs, and that EERO-HOPs must be present. Is that what you > meant? > The cases that were stated were examples, it is perfectly legal to have only LR-HOPs or AN-HOPs by themselves and add or delete HOPs in the middle of an LSP. We will refine this section in the next version of the draft. > IMO the stated goal of "simplification of abstract node and loose route > processing" has not been achieved. It may well be that ERO processing > should be reworded; if so, the goal should not be to use fewer words, > but rather to achieve greater clarity. Of course, the current semantics > should be maintained. Kireeti, I think you have seen the problem that we are trying to address but do not believe that a new ERO (EERO) is necessary. On the other hand, the fact that we have cut the AN lookup out of most EERO processing, that we have made the EERO very specific and detailed have achieved our goal. If these were in the ERO in the first place, I am sure that at least our implementation would have been shorter. We believe that this draft is useful and adds value to existing MPLS implementations and reduces the chance having un-interoperable MPLS implementations. I know of interoperability problems even between two leading vendors' implementations that have brought networks down for days, and we are trying to prevent that when there are (say) six vendors' equipment in the network. We appreciate your comments and will incorporate these into the next version of our draft. Regards Bora From owner-mpls@UU.NET Mon Feb 26 11:56:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16228 for ; Mon, 26 Feb 2001 11:56: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 QQkebj15681; Mon, 26 Feb 2001 16:56:41 GMT Received: by mail-control.mail.uu.net id QQkebj23373 for mpls-outgoing; Mon, 26 Feb 2001 16:56: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 QQkebj23359 for ; Mon, 26 Feb 2001 16:56: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 QQkebj05057 for ; Mon, 26 Feb 2001 16:54:53 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkebj05797 for ; Mon, 26 Feb 2001 16:54:52 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f1QGshV20183; Mon, 26 Feb 2001 17:54:44 +0100 (MET) Received: from alcatel.be ([138.203.171.133]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569FF.005CE310; Mon, 26 Feb 2001 17:54:34 +0100 Message-ID: <3A9A8A4A.6017AE5F@alcatel.be> Date: Mon, 26 Feb 2001 17:54:35 +0100 From: Paul Moore Organization: Alcatel Bell X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Dmitry Ryumkin CC: "'djiang1@lucent.com'" , mpls@UU.NET, paul-patrick.moore@alcatel.be Subject: Re: MPLS LSPs and ATM PVCs References: <89E067900D3FA84A97495C71556140E402D8AA@edgsvr01.edgeflow.edgeflow.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dmitri, Where is that stated? I've checked in the MPLS Architecture documents, searching with the "bidirectional" and "bi-directional" keywords, and I haven't been able to find it mentioned. On the other hand, the two applicability documents for CR-LDP and RSVP-TE both state that bi-directional LSP set up is not yet supported: Applicability Statement for CR-LDP (13805 bytes): "CR-LDP specification only supports unidirectional LSP setup. Bi-directional LSP setup is FFS." Applicability Statement for Extensions to RSVP for LSP-Tunnels (16573 bytes): "The RSVP-TE specification supports only unidirectional LSP- tunnels. Bidirectional LSP-tunnels are not supported." Many thanks, Paul PS Thanks Jane for the response. Dmitri Ryumkin wrote: > Paul, > > Generalized MPLS defines procedures for bi-directional LSP setup. > > Regards, > Dmitry Ryumkin > > -----Original Message----- > From: djiang1@lucent.com [mailto:djiang1@lucent.com] > Sent: Monday, February 26, 2001 8:52 AM > To: Paul Moore > Cc: mpls@UU.NET > Subject: Re: MPLS LSPs and ATM PVCs > > HI Paul, > > I believe RSVP is never intended to set up two LSPs using one single > operation. We will have to use two RSVP signalling operations to set up > the two LSPs, one for each direction, even if the PVC may be used > bidirectionally. > > Regards, > Jane D. Jiang > > Paul Moore @UU.NET on 02/26/2001 08:11:29 AM > > Sent by: owner-mpls@UU.NET > > To: mpls@UU.NET > cc: > Subject: MPLS LSPs and ATM PVCs > > Hello, > > I have a question about MPLS and ATM. ATM point-to-point PVCs can be > either uni-directional or bi-directional. MPLS LSPs are only > uni-directional. Is there any work being done concerning bi-directional > LSPs, for example, to allow two LSPs to be established by a single RSVP > signalling operation? > > I've just joined the list, so apologies if this has already been > discussed. > > Thanks, > Paul > > -- > Paul Moore > Alcatel Bell > +32 3 450 3536 > paul-patrick.moore@alcatel.be -- Paul Moore, ext 53536 paul-patrick.moore@alcatel.be Alcatel Bell 03/450.3536 From owner-mpls@UU.NET Mon Feb 26 12:14:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16948 for ; Mon, 26 Feb 2001 12:14: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 QQkebk18825; Mon, 26 Feb 2001 17:13:55 GMT Received: by mail-control.mail.uu.net id QQkebk10682 for mpls-outgoing; Mon, 26 Feb 2001 17:13:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkebk10674 for ; Mon, 26 Feb 2001 17:13:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkebk16119 for ; Mon, 26 Feb 2001 17:13:05 GMT Received: from mailrelay1.alcatel.de by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75]) id QQkebk00578 for ; Mon, 26 Feb 2001 17:13:05 GMT Received: from ks.sel.alcatel.de (actually host slsv0d.stgl.sel.alcatel.de) by mailrelay1.alcatel.de with SMTP (XT-PP); Mon, 26 Feb 2001 18:12:39 +0100 Received: from slsv7at ([149.204.245.107] helo=slsv7a) by ks.sel.alcatel.de with esmtp (Exim 3.16) id 14XRCQ-0002Vx-00; Mon, 26 Feb 2001 18:12:38 +0100 Received: from sls7bw ([149.204.78.31] helo=sls7bw.stgl.sel.alcatel.de) by slsv7a with esmtp (Exim 3.16) id 14XRCQ-0007Xr-00; Mon, 26 Feb 2001 18:12:38 +0100 Message-ID: <3A9A8E84.BDE1AC82@alcatel.de> Date: Mon, 26 Feb 2001 18:12:36 +0100 From: Patrick McGleenon Organization: Alcatel X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Moore CC: mpls@UU.NET Subject: Re: MPLS LSPs and ATM PVCs References: <89E067900D3FA84A97495C71556140E402D8AA@edgsvr01.edgeflow.edgeflow.com> <3A9A8A4A.6017AE5F@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Paul, It's true that traditional MPLS supports only unidirectional LSPs; it's also true that if you look in the IETF draft "Generalized MPLS - Signalling Functional Description" (draft-ietf-mpls-generalized-signaling-01.txt) in Section 4 you will find a discussion of bidirectional LSPs in the context of Generalized MPLS. Regards Patrick From owner-mpls@UU.NET Mon Feb 26 12:26:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17503 for ; Mon, 26 Feb 2001 12:26: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 QQkebl19202; Mon, 26 Feb 2001 17:26:31 GMT Received: by mail-control.mail.uu.net id QQkebl12166 for mpls-outgoing; Mon, 26 Feb 2001 17:26: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 QQkebl12124 for ; Mon, 26 Feb 2001 17:26:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkebl09614 for ; Mon, 26 Feb 2001 17:25:30 GMT Received: from edgeflow.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.191.40.82]) id QQkebl04684 for ; Mon, 26 Feb 2001 17:25:30 GMT Received: from edgsvr01.edgeflow.edgeflow.com ([10.0.1.10]) by watchdog.edgeflow.com with ESMTP id <119045>; Mon, 26 Feb 2001 12:25:24 -0500 Received: by edgsvr01.edgeflow.edgeflow.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 12:21:54 -0500 Message-ID: <89E067900D3FA84A97495C71556140E402D8AC@edgsvr01.edgeflow.edgeflow.com> From: Dmitry Ryumkin To: "'mpls@uu.net'" Subject: numbered TE links in GMPLS Date: Mon, 26 Feb 2001 12:21:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In GMPLS, TE links may be numbered (assigned local and remote IP addresses). My question is how such IP addresses should be handled in cases when a TE link is not capable of terminating IP traffic. Can I use such an IP address as a destination when sending IP packets? Some drafts seem to imply that the answer to this question is positive. For example, bundle's IP addresses may be used in ERO; also, as one of the mechanism for selecting a component link from a bundle, the "Link Bundling in MPLS TE" draft proposes sending Path/REQUEST message to the remote IP address of the component link (section 3.3.2). If this is really the case then what interface model should be used? Usually, assigning an IP address to a link means creating an interface on top of the interface corresponding to the link. The IfTable will have an entry for this IP interface and the IfStackTable will link this interface with the one corresponding to the link. In the TE link case, however, it would imply that all TE links (including bundles and FA) have to be put in the IfTable, which currently seems not to be the case. Could somebody please clarify this. Thanks, Dmitry From owner-mpls@UU.NET Mon Feb 26 12:31:00 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17739 for ; Mon, 26 Feb 2001 12:31: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 QQkebm25501; Mon, 26 Feb 2001 17:30:46 GMT Received: by mail-control.mail.uu.net id QQkebm12599 for mpls-outgoing; Mon, 26 Feb 2001 17:30: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 QQkebl12550 for ; Mon, 26 Feb 2001 17:29: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 QQkebl20114 for ; Mon, 26 Feb 2001 17:28:53 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkebl09348 for ; Mon, 26 Feb 2001 17:28:53 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C56E894006; Mon, 26 Feb 2001 12:28:48 -0500 (EST) Message-ID: <3A9A9250.B831AC7B@sandburst.com> Date: Mon, 26 Feb 2001 12:28:48 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Moore Cc: Dmitry Ryumkin , "'djiang1@lucent.com'" , mpls@UU.NET Subject: Re: MPLS LSPs and ATM PVCs References: <89E067900D3FA84A97495C71556140E402D8AA@edgsvr01.edgeflow.edgeflow.com> <3A9A8A4A.6017AE5F@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Paul, Any references to bi-directional LSP establishment that might have appeared in the architecture or applicability in in the MPLS working group would have been either an exceptionally insightful forward references, or wrong. :-) Dmitry refers to relatively new work. -- Eric Gray You wrote: > Dmitri, > > Where is that stated? I've checked in the MPLS Architecture documents, > searching with the "bidirectional" and "bi-directional" keywords, and I > haven't been able to find it mentioned. > > On the other hand, the two applicability documents for CR-LDP and RSVP-TE both > state that bi-directional LSP set up is not yet supported: > > Applicability Statement for CR-LDP (13805 bytes): > "CR-LDP specification only supports unidirectional LSP setup. > Bi-directional LSP setup is FFS." > > Applicability Statement for Extensions to RSVP for LSP-Tunnels (16573 bytes): > "The RSVP-TE specification supports only unidirectional LSP- tunnels. > Bidirectional LSP-tunnels are not supported." > > Many thanks, > Paul > > PS Thanks Jane for the response. > > Dmitri Ryumkin wrote: > > > Paul, > > > > Generalized MPLS defines procedures for bi-directional LSP setup. > > > > Regards, > > Dmitry Ryumkin > > > > -----Original Message----- > > From: djiang1@lucent.com [mailto:djiang1@lucent.com] > > Sent: Monday, February 26, 2001 8:52 AM > > To: Paul Moore > > Cc: mpls@UU.NET > > Subject: Re: MPLS LSPs and ATM PVCs > > > > HI Paul, > > > > I believe RSVP is never intended to set up two LSPs using one single > > operation. We will have to use two RSVP signalling operations to set up > > the two LSPs, one for each direction, even if the PVC may be used > > bidirectionally. > > > > Regards, > > Jane D. Jiang > > > > Paul Moore @UU.NET on 02/26/2001 08:11:29 AM > > > > Sent by: owner-mpls@UU.NET > > > > To: mpls@UU.NET > > cc: > > Subject: MPLS LSPs and ATM PVCs > > > > Hello, > > > > I have a question about MPLS and ATM. ATM point-to-point PVCs can be > > either uni-directional or bi-directional. MPLS LSPs are only > > uni-directional. Is there any work being done concerning bi-directional > > LSPs, for example, to allow two LSPs to be established by a single RSVP > > signalling operation? > > > > I've just joined the list, so apologies if this has already been > > discussed. > > > > Thanks, > > Paul > > > > -- > > Paul Moore > > Alcatel Bell > > +32 3 450 3536 > > paul-patrick.moore@alcatel.be > > -- > Paul Moore, ext 53536 > paul-patrick.moore@alcatel.be > Alcatel Bell > 03/450.3536 From owner-mpls@UU.NET Mon Feb 26 12:38:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18020 for ; Mon, 26 Feb 2001 12:38: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 QQkebm05476; Mon, 26 Feb 2001 17:38:01 GMT Received: by mail-control.mail.uu.net id QQkebm13630 for mpls-outgoing; Mon, 26 Feb 2001 17:37: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 QQkebm13616 for ; Mon, 26 Feb 2001 17:37: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 QQkebm08247 for ; Mon, 26 Feb 2001 17:35:53 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: parker2.sprint.com [199.14.91.106]) id QQkebm18583 for ; Mon, 26 Feb 2001 17:35:53 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 f1QHiUD00352 for ; Mon, 26 Feb 2001 11:44:30 -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 f1QHZqI29592 for ; Mon, 26 Feb 2001 11:35:52 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id LAA25163 for ; Mon, 26 Feb 2001 11:35:52 -0600 (CST) X-OpenMail-Hops: 1 Date: Mon, 26 Feb 2001 11:35:50 -0600 Message-Id: Subject: T1 aggregation into MPLS MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-1c602f92-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1c602f92-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Mon, 26 Feb 2001 11:35:50 -0600" Content-Transfer-Encoding: 8bit All, Any work done on aggregating T1 (TDM, SS7, IP) into MPLS labels? I am not sure if COET BOF or PWOT WG addressed this issue. I know martini drafts are ATM, FR, CEM over MPLS draft-martini-l2circuit-encap-mpls-01.txt draft-martini-l2circuit-trans-mpls-05.txt Thanks. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations & Evaluation Group Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --openmail-part-1c602f92-00000001 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf" ;Creation-Date="Mon, 26 Feb 2001 11:35:50 -0600" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --openmail-part-1c602f92-00000001-- From owner-mpls@UU.NET Mon Feb 26 13:53:46 2001 Received: from cmr1.ash.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 NAA21307 for ; Mon, 26 Feb 2001 13:53: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 QQkebr16263; Mon, 26 Feb 2001 18:53:22 GMT Received: by mail-control.mail.uu.net id QQkebr07230 for mpls-outgoing; Mon, 26 Feb 2001 18:53:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkebr07223 for ; Mon, 26 Feb 2001 18:53:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkebr22384 for ; Mon, 26 Feb 2001 18:52:55 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkebr15572 for ; Mon, 26 Feb 2001 18:52:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA15155 for mpls@uu.net; Mon, 26 Feb 2001 13:52:53 -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 QQkebr06972 for ; Mon, 26 Feb 2001 18:49:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkebr00517 for ; Mon, 26 Feb 2001 18:49:49 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkebr22883 for ; Mon, 26 Feb 2001 18:49:45 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA22175; Mon, 26 Feb 2001 10:49:33 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: References: Date: Mon, 26 Feb 2001 10:48:10 -0800 To: Bora Akyol From: Bora Akyol Subject: Re: New Internet Draft on ERO Cc: Kireeti Kompella , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk Also, how do you do fast reroute with unnumbered interfaces when there is no router ID associated with an ifindex? Thanks Bora At 8:45 AM -0800 2/26/01, Bora Akyol wrote: >Kireeti > >Thank you for your comments. The fact that you suggested that a draft >without defining a new object but explicitly defining behaviors on ERO >generation and processing leads me to believe that you recognize the >problem that we are trying to address. I still think a new object is >necessary however. Please see my comments within: > > > On Mon, 26 Feb 2001, Kireeti Kompella wrote: > >> Hi Bora, >> >> I have some comments on your draft. >> >> Section 1: >> >> Specifically, ERO >> definition for unnumbered interfaces is context sensitive and >> dependent on the order of appearance in the ERO. >> >> Note that the graph-theoretic definition of a path is an *ordered* >> sequence of edges (or nodes). What issue does the fact that the ERO >> needs to be ordered raise? Do you suppose that the EERO format that >> you propose does not dependent on the order of appearance? >> > >It does depend on the order of appearance but we clearly wanted to make >the case you listed below impossible: > >> For example, if >> the same interface identifier is repeated twice in the ERO >> consecutively, the desired behavior is unclear. >> >> Actually, the desired behaviour is quite clear; if an ERO consists of >> <1, 1, 1, 1, 1, 1>, then the path is quite explicit: take interface #1 >> from the ingress; then take interface #1 from the next hop; then take >> interface #1 from the next hop, etc. until you reach the egress. The >> fact that all the interfaces are numbered 1 is wholly irrelevant; each >> hop is in a different numbering scope. (Note that unnumbered interfaces >> are always *strict* hops.) >> > >What you are assuming here is that there is one ERO hop for each hop, >however, the RSVP-TE draft allows a hop to be specified by any combination >of interface identifiers and router ID. I recognize the point that you are >making but I think that it is advantageous to make things as clear as they >can be. The EERO that we define achieves this clarity. > > > c. Different styles of specifying the ERO in different >> implementations. [RSVP-TE] gives the head-end LSR considerable >> leeway in specifying the ERO. For example, an LSR that is on the >> path can be specified by a router ID, an ingress (w.r.t. to the >> LSP) interface ID (usually an IP address), an egress interface ID >> or any combination of the above. This "flexibility" may cause LSP >> establishment and interoperability failures. >> >> These "issues" are easily solved (and are solved in practice). A BCP >> that describes one style for ERO specification *without* protocol >> changes would be a better solution (IMHO) than an entirely new ERO > > format that contains twice redundant information. > > > >I know that these issues are solved in practice, I know that our >implementation solves these issues as well. One of my main motivations for >this draft was to stop other implementors from making different >assumptions and achieve maximal interoperability. We are still in the >earlier stages of deployment for MPLS and as more and more edge devices >come on-line, we will see more interoperability problems. The EERO object >that we defined prevents interoperability problems since it is very strict >in its definition. > > >> Section 2: Ingress Interface Identifier & Egress Interface Identifier > >> For a given link, the ingress and egress interface indices are assigned >> by different routers. This means that the scopes are under different >> router IDs. The draft contradicts that. Can you clarify? > >Kireeti, what we meant here is: > >The ingress and the egress interfaces through the same router. Think of >threading a needle where the router is the needle. You come in through >interface A and leave through interface B and both A & B belong to the >same router. > > >> > By the way, the idea of adding a router ID to unnumbered interface >> objects was discussed on the MPLS mailing list several months ago and >> discarded as unnecessary. > >I know, I was part of the discussion, but I don't recall anyone objecting >to a new EERO at the time ;-) > >> >> In any case, what is the value of the router ID when the ingress/egress >> interface identifiers are IPv4 addresses? > >As stated in the draft, it makes EERO processing very very simple. There >are no abstract node lookups, you just see if you are the router with the >router ID and then associate with the UP/DOWN-stream interfaces and the >LSP setup is on its way. The fact that you don't need to do a AN lookup by >itself probably saves about 1/3 to 2/3 of LSP PATH processing in the node. > > >> > Also, loose hops should probably not have any associated interfaces. >> I'm not sure what it means to have unnumbered interface indices with >> loose hops. Unfortunately, I cannot make out the use of interface IDs >> in the context of loose hops from the description in section 3. > >Why? You can perfectly specify a loose hop where you want the LSP to >specifically enter through interface A and leave the hop through interface >B. I can see benefits of this in a regular MPLS network as well as an >optical network. > >> >> Section 3: ERO processing >> >> There are actually eight cases: with/without EERO-HOPs, with/without >> AN-HOPs, with/without LR-HOPs. I fail to see how this classification >> helps, though. You seem to assume that LR-HOPs cannot be interspersed >> with EERO-HOPs, and that EERO-HOPs must be present. Is that what you >> meant? >> > >The cases that were stated were examples, it is perfectly legal to have >only LR-HOPs or AN-HOPs by themselves and add or delete HOPs in the middle >of an LSP. > >We will refine this section in the next version of the draft. > >> IMO the stated goal of "simplification of abstract node and loose route >> processing" has not been achieved. It may well be that ERO processing >> should be reworded; if so, the goal should not be to use fewer words, >> but rather to achieve greater clarity. Of course, the current semantics >> should be maintained. > >Kireeti, > >I think you have seen the problem that we are trying to address but do not >believe that a new ERO (EERO) is necessary. On the other hand, the fact >that we have cut the AN lookup out of most EERO processing, that we have >made >the EERO very specific and detailed have achieved our goal. If these were >in the ERO in the first place, I am sure that at least our implementation >would have been shorter. > >We believe that this draft is useful and adds value to existing MPLS >implementations and reduces the chance having un-interoperable MPLS >implementations. I know of interoperability problems even between two >leading vendors' implementations that have brought networks down for days, >and we are trying to prevent that when there are (say) six vendors' >equipment in the network. > >We appreciate your comments and will incorporate these into the next >version of our draft. > >Regards > >Bora From owner-mpls@UU.NET Mon Feb 26 16:08:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27597 for ; Mon, 26 Feb 2001 16:08: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 QQkeca24463; Mon, 26 Feb 2001 21:08:22 GMT Received: by mail-control.mail.uu.net id QQkeca05450 for mpls-outgoing; Mon, 26 Feb 2001 21:07:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeca05422 for ; Mon, 26 Feb 2001 21:07:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeca22228 for ; Mon, 26 Feb 2001 21:03:43 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeca06379 for ; Mon, 26 Feb 2001 21:03:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA26039 for mpls@uu.net; Mon, 26 Feb 2001 16:03: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 QQkeca26399 for ; Mon, 26 Feb 2001 21:03:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeca08653 for ; Mon, 26 Feb 2001 21:00:57 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 QQkeca16774 for ; Mon, 26 Feb 2001 21:00:56 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 NAA01910; Mon, 26 Feb 2001 13:00:01 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BK9BW>; Mon, 26 Feb 2001 13:03:23 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AA8@BBY1EXM01> From: Shahram Davari To: "'Puneet Agarwal'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Mon, 26 Feb 2001 13:03: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 Puneet/Eric, 1)You are right we have not described how to signal Pipe/short pipe/uniform models. Since our draft is in its last call and can't be changed substantially, I propose that we get together to write a separate I-D to address the CR-LDP/RSVP-TE extensions for signaling the tunneling model. 2) Section 2.4 does not discuss an important case that is: egress processing of tunnels, i.e. pop and forwarding the packet as MPLS. 3)As you may know, version -08 of our draft has introduced two types of Pipe tunnels a) Short pipe and b) Pipe. The short pipe is what was called the "pipe" in version -07. But the new "pipe" model is a bit different, in the sense that all the egress processing is done based on top label. So your description of TTL processing for the pipe model remains valid for "short pipe" (except that you need to describe the egress processing too, see bullet 2 above), but you need to define another TTL processing rule for the "pipe", which is: the top label TTL is decremented and checked, while the lower label TTL (unchanged) is used for forwarding the packet. Yours, -Shahram > -----Original Message----- > From: Puneet Agarwal [mailto:puneet@pluris.com] > Sent: Friday, February 23, 2001 4:53 PM > To: 'Eric Gray' > Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > 'bsd@cisco.com'; Shahram Davari; Bora Akyol > Subject: RE: New TTL Draft > > > Eric, > > Comments inline. > > >-----Original Message----- > >From: Eric Gray [mailto:eric.gray@sandburst.com] > >Sent: Friday, February 23, 2001 9:34 AM > >To: Bora Akyol > >Cc: akyol@akyol.org; djiang1@lucent.com; B, Prakash K (Prakash); > >'mpls@uu.net' > >Subject: Re: New TTL Draft > > > > > >Bora/Puneet, > > > > Some comments. > > > > In section 2.4, item 3 - PHP does not necessarily expose an > >IP header. The text in this section is not clear in this respect > >- possibly because of the textual construct "IP-Header/label". > >It might be somewhat clearer if you use "header" and add a > >paragraph stating that the PHP exposed header may be either > >an IP header or an MPLS label and the appropriate oTTL is > >written to the corresponding TTL field of this PHP exposed > >header. > > I agree. We will change the wording in the next rev of the draft. > > > > Also, in this section, why is oTTL set to the TTL of the > >exposed header if it is not used for anything? > > Good point. We do not need to set this. This was a leftover > from some text > we took out of section 2.5 at the last moment that used this > information. We > will fix this in the next rev. > > > > In addition, if your actually specifying a behavior (rather than > >an architecture), I believe you need to allow that the TTL may > >be decremented by a number other than one. RFC 791 states > >that RFC is decremented by at least one. Your draft states in > >several places that iTTL is decremented (I assume that the > >underscore in these cases is meant to be a minus sign) by one. > > The underscore is indeed supposed to be a minus. Will be > fixed in the next > rev. > I have no problems in allowing the iTTL to be decremented by > more than one. > I will change the text to state that the iTTL should be > decremented by "N", > where "N" is user configured and is greater than 0. The > default value of "N" > should be 1. > > > > > There are practical reasons for decrementing TTL by more > >than one (a high-cost or low-bandwidth link, for example) > >when it is desirable to accelerate the aging of possibly looping > >packets. A higher TTL decrement punishes all packets that use > >the link, but it punishes looping packets much more. > > > > Finally, what is the mechanism which the PHP uses to determine > >whether or not the LSP is using the pipe or the uniform model? I am > >not sure this information is currently available. > > You may be right. I looked through > "draft-ietf-mpls-diff-ext-08.txt", but > did not see any method to signal the model (pipe or uniform) > associated with > the LSP, using either RSVP or LDP. If it is a missing piece, > then I hope > that it will be addressed by the authors of that draft. > > -Puneet > > > > >-- > >Eric Gray > > > >Bora Akyol wrote: > > > >> Note that we (Puneet and I) just posted an Internet Draft on TTL > >> handling in hierarchical MPLS networks. > >> > >> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt > >> > >> > http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt > >> > >> We welcome any comments, > >> > >> Bora Akyol > > > From owner-mpls@UU.NET Mon Feb 26 17:05:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29805 for ; Mon, 26 Feb 2001 17:05: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 QQkece07735; Mon, 26 Feb 2001 22:04:57 GMT Received: by mail-control.mail.uu.net id QQkece19672 for mpls-outgoing; Mon, 26 Feb 2001 22:04: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 QQkece19661 for ; Mon, 26 Feb 2001 22:04: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 QQkece11561 for ; Mon, 26 Feb 2001 22:02:45 GMT Received: from pulsar.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 200-139.adsl6.netlojix.net [207.71.200.139] (may be forged)) id QQkece13461 for ; Mon, 26 Feb 2001 22:02:45 GMT Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2653.19) id <1QR7834W>; Mon, 26 Feb 2001 14:00:39 -0800 Message-ID: From: Jonathan Lang To: "'Bora Akyol'" Cc: Kireeti Kompella , mpls@UU.NET, Jonathan Lang Subject: RE: New Internet Draft on ERO Date: Mon, 26 Feb 2001 14:00:38 -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 Bora, Please explain how the current ERO and unnumbered interfaces are affected by fast reroute. Thanks, Jonathan > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Monday, February 26, 2001 10:48 AM > To: Bora Akyol > Cc: Kireeti Kompella; mpls@UU.NET > Subject: Re: New Internet Draft on ERO > > > Also, how do you do fast reroute with unnumbered interfaces when > there is no router ID associated with an ifindex? > > Thanks > > Bora > > At 8:45 AM -0800 2/26/01, Bora Akyol wrote: > >Kireeti > > > >Thank you for your comments. The fact that you suggested that a draft > >without defining a new object but explicitly defining > behaviors on ERO > >generation and processing leads me to believe that you recognize the > >problem that we are trying to address. I still think a new object is > >necessary however. Please see my comments within: > > > > > > On Mon, 26 Feb 2001, Kireeti Kompella wrote: > > > >> Hi Bora, > >> > >> I have some comments on your draft. > >> > >> Section 1: > >> > >> Specifically, ERO > >> definition for unnumbered interfaces is > context sensitive and > >> dependent on the order of appearance in the ERO. > >> > >> Note that the graph-theoretic definition of a path is an *ordered* > >> sequence of edges (or nodes). What issue does the fact > that the ERO > >> needs to be ordered raise? Do you suppose that the EERO > format that > >> you propose does not dependent on the order of appearance? > >> > > > >It does depend on the order of appearance but we clearly > wanted to make > >the case you listed below impossible: > > > >> For example, if > >> the same interface identifier is repeated > twice in the ERO > >> consecutively, the desired behavior is unclear. > >> > >> Actually, the desired behaviour is quite clear; if an ERO > consists of > >> <1, 1, 1, 1, 1, 1>, then the path is quite explicit: take > interface #1 > >> from the ingress; then take interface #1 from the next > hop; then take > >> interface #1 from the next hop, etc. until you reach the > egress. The > >> fact that all the interfaces are numbered 1 is wholly > irrelevant; each > >> hop is in a different numbering scope. (Note that > unnumbered interfaces > >> are always *strict* hops.) > >> > > > >What you are assuming here is that there is one ERO hop for each hop, > >however, the RSVP-TE draft allows a hop to be specified by > any combination > >of interface identifiers and router ID. I recognize the > point that you are > >making but I think that it is advantageous to make things as > clear as they > >can be. The EERO that we define achieves this clarity. > > > > > c. Different styles of specifying the ERO in different > >> implementations. [RSVP-TE] gives the head-end > LSR considerable > >> leeway in specifying the ERO. For example, an > LSR that is on the > >> path can be specified by a router ID, an > ingress (w.r.t. to the > >> LSP) interface ID (usually an IP address), an > egress interface ID > >> or any combination of the above. This > "flexibility" may cause LSP > >> establishment and interoperability failures. > >> > >> These "issues" are easily solved (and are solved in > practice). A BCP > >> that describes one style for ERO specification *without* protocol > >> changes would be a better solution (IMHO) than an entirely new ERO > > > format that contains twice redundant information. > > > > > > >I know that these issues are solved in practice, I know that our > >implementation solves these issues as well. One of my main > motivations for > >this draft was to stop other implementors from making different > >assumptions and achieve maximal interoperability. We are still in the > >earlier stages of deployment for MPLS and as more and more > edge devices > >come on-line, we will see more interoperability problems. > The EERO object > >that we defined prevents interoperability problems since it > is very strict > >in its definition. > > > > > >> Section 2: Ingress Interface Identifier & Egress > Interface Identifier > > >> For a given link, the ingress and egress interface > indices are assigned > >> by different routers. This means that the scopes are > under different > >> router IDs. The draft contradicts that. Can you clarify? > > > >Kireeti, what we meant here is: > > > >The ingress and the egress interfaces through the same > router. Think of > >threading a needle where the router is the needle. You come > in through > >interface A and leave through interface B and both A & B > belong to the > >same router. > > > > > >> > By the way, the idea of adding a router ID to > unnumbered interface > >> objects was discussed on the MPLS mailing list several > months ago and > >> discarded as unnecessary. > > > >I know, I was part of the discussion, but I don't recall > anyone objecting > >to a new EERO at the time ;-) > > > >> > >> In any case, what is the value of the router ID when the > ingress/egress > >> interface identifiers are IPv4 addresses? > > > >As stated in the draft, it makes EERO processing very very > simple. There > >are no abstract node lookups, you just see if you are the > router with the > >router ID and then associate with the UP/DOWN-stream > interfaces and the > >LSP setup is on its way. The fact that you don't need to do > a AN lookup by > >itself probably saves about 1/3 to 2/3 of LSP PATH > processing in the node. > > > > > >> > Also, loose hops should probably not have any > associated interfaces. > >> I'm not sure what it means to have unnumbered interface > indices with > >> loose hops. Unfortunately, I cannot make out the use of > interface IDs > >> in the context of loose hops from the description in section 3. > > > >Why? You can perfectly specify a loose hop where you want the LSP to > >specifically enter through interface A and leave the hop > through interface > >B. I can see benefits of this in a regular MPLS network as well as an > >optical network. > > > >> > >> Section 3: ERO processing > >> > >> There are actually eight cases: with/without EERO-HOPs, > with/without > >> AN-HOPs, with/without LR-HOPs. I fail to see how this > classification > >> helps, though. You seem to assume that LR-HOPs cannot be > interspersed > >> with EERO-HOPs, and that EERO-HOPs must be present. Is > that what you > >> meant? > >> > > > >The cases that were stated were examples, it is perfectly > legal to have > >only LR-HOPs or AN-HOPs by themselves and add or delete HOPs > in the middle > >of an LSP. > > > >We will refine this section in the next version of the draft. > > > >> IMO the stated goal of "simplification of abstract node > and loose route > >> processing" has not been achieved. It may well be that > ERO processing > >> should be reworded; if so, the goal should not be to use > fewer words, > >> but rather to achieve greater clarity. Of course, the > current semantics > >> should be maintained. > > > >Kireeti, > > > >I think you have seen the problem that we are trying to > address but do not > >believe that a new ERO (EERO) is necessary. On the other > hand, the fact > >that we have cut the AN lookup out of most EERO processing, > that we have > >made > >the EERO very specific and detailed have achieved our goal. > If these were > >in the ERO in the first place, I am sure that at least our > implementation > >would have been shorter. > > > >We believe that this draft is useful and adds value to existing MPLS > >implementations and reduces the chance having un-interoperable MPLS > >implementations. I know of interoperability problems even between two > >leading vendors' implementations that have brought networks > down for days, > >and we are trying to prevent that when there are (say) six vendors' > >equipment in the network. > > > >We appreciate your comments and will incorporate these into the next > >version of our draft. > > > >Regards > > > >Bora > From owner-mpls@UU.NET Mon Feb 26 17:46:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02104 for ; Mon, 26 Feb 2001 17:46: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 QQkech28093; Mon, 26 Feb 2001 22:46:25 GMT Received: by mail-control.mail.uu.net id QQkech25493 for mpls-outgoing; Mon, 26 Feb 2001 22:45:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkech25486 for ; Mon, 26 Feb 2001 22:45:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkech10794 for ; Mon, 26 Feb 2001 22:45:32 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkech12192 for ; Mon, 26 Feb 2001 22:45:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA04027 for mpls@uu.net; Mon, 26 Feb 2001 17:45:31 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkecg25152 for ; Mon, 26 Feb 2001 22:44:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkecg07968 for ; Mon, 26 Feb 2001 22:44:18 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 QQkecg08516 for ; Mon, 26 Feb 2001 22:44:18 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA11589; Mon, 26 Feb 2001 14:41:02 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: References: Date: Mon, 26 Feb 2001 14:39:37 -0800 To: Jonathan Lang From: Bora Akyol Subject: RE: New Internet Draft on ERO Cc: "'Bora Akyol'" , Kireeti Kompella , mpls@UU.NET, Jonathan Lang Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk My question is as follows: How do you do fast reroute when you have unnumbered interfaces in the ERO as in the unnumbered draft? What out of band information is added to what's in the ERO when we do CSPF? Is everyone doing it the same way? If we use the (newly defined) EERO then fast reroute is the same for both numbered and unnumbered interfaces and it actually becomes quite easy. Bora At 2:00 PM -0800 2/26/01, Jonathan Lang wrote: >Bora, > Please explain how the current ERO and unnumbered interfaces are affected >by fast reroute. > >Thanks, >Jonathan > > >> -----Original Message----- >> From: Bora Akyol [mailto:akyol@pluris.com] >> Sent: Monday, February 26, 2001 10:48 AM >> To: Bora Akyol >> Cc: Kireeti Kompella; mpls@UU.NET >> Subject: Re: New Internet Draft on ERO >> >> >> Also, how do you do fast reroute with unnumbered interfaces when >> there is no router ID associated with an ifindex? >> >> Thanks >> >> Bora >> >> At 8:45 AM -0800 2/26/01, Bora Akyol wrote: >> >Kireeti >> > >> >Thank you for your comments. The fact that you suggested that a draft >> >without defining a new object but explicitly defining >> behaviors on ERO >> >generation and processing leads me to believe that you recognize the >> >problem that we are trying to address. I still think a new object is >> >necessary however. Please see my comments within: >> > >> > >> > On Mon, 26 Feb 2001, Kireeti Kompella wrote: >> > >> >> Hi Bora, >> >> >> >> I have some comments on your draft. >> >> >> >> Section 1: >> >> >> >> Specifically, ERO >> >> definition for unnumbered interfaces is >> context sensitive and >> >> dependent on the order of appearance in the ERO. >> >> >> >> Note that the graph-theoretic definition of a path is an *ordered* >> >> sequence of edges (or nodes). What issue does the fact >> that the ERO >> >> needs to be ordered raise? Do you suppose that the EERO >> format that >> >> you propose does not dependent on the order of appearance? >> >> >> > >> >It does depend on the order of appearance but we clearly >> wanted to make >> >the case you listed below impossible: >> > >> >> For example, if >> >> the same interface identifier is repeated >> twice in the ERO >> >> consecutively, the desired behavior is unclear. >> >> >> >> Actually, the desired behaviour is quite clear; if an ERO >> consists of >> >> <1, 1, 1, 1, 1, 1>, then the path is quite explicit: take >> interface #1 >> >> from the ingress; then take interface #1 from the next >> hop; then take >> >> interface #1 from the next hop, etc. until you reach the >> egress. The >> >> fact that all the interfaces are numbered 1 is wholly >> irrelevant; each >> >> hop is in a different numbering scope. (Note that >> unnumbered interfaces >> >> are always *strict* hops.) >> >> >> > >> >What you are assuming here is that there is one ERO hop for each hop, >> >however, the RSVP-TE draft allows a hop to be specified by >> any combination >> >of interface identifiers and router ID. I recognize the >> point that you are >> >making but I think that it is advantageous to make things as >> clear as they >> >can be. The EERO that we define achieves this clarity. > > > > > > > c. Different styles of specifying the ERO in different > > >> implementations. [RSVP-TE] gives the head-end > > LSR considerable > > >> leeway in specifying the ERO. For example, an >> LSR that is on the >> >> path can be specified by a router ID, an >> ingress (w.r.t. to the >> >> LSP) interface ID (usually an IP address), an >> egress interface ID >> >> or any combination of the above. This >> "flexibility" may cause LSP >> >> establishment and interoperability failures. >> >> >> >> These "issues" are easily solved (and are solved in >> practice). A BCP >> >> that describes one style for ERO specification *without* protocol > > >> changes would be a better solution (IMHO) than an entirely new ERO >> > > format that contains twice redundant information. >> > > >> > >> >I know that these issues are solved in practice, I know that our >> >implementation solves these issues as well. One of my main >> motivations for >> >this draft was to stop other implementors from making different >> >assumptions and achieve maximal interoperability. We are still in the >> >earlier stages of deployment for MPLS and as more and more >> edge devices >> >come on-line, we will see more interoperability problems. >> The EERO object >> >that we defined prevents interoperability problems since it >> is very strict >> >in its definition. >> > >> > >> >> Section 2: Ingress Interface Identifier & Egress >> Interface Identifier > >> >> For a given link, the ingress and egress interface >> indices are assigned >> >> by different routers. This means that the scopes are >> under different >> >> router IDs. The draft contradicts that. Can you clarify? >> > >> >Kireeti, what we meant here is: >> > >> >The ingress and the egress interfaces through the same >> router. Think of >> >threading a needle where the router is the needle. You come >> in through >> >interface A and leave through interface B and both A & B >> belong to the >> >same router. >> > >> > >> >> > By the way, the idea of adding a router ID to >> unnumbered interface >> >> objects was discussed on the MPLS mailing list several >> months ago and >> >> discarded as unnecessary. >> > >> >I know, I was part of the discussion, but I don't recall >> anyone objecting >> >to a new EERO at the time ;-) >> > >> >> >> >> In any case, what is the value of the router ID when the >> ingress/egress >> >> interface identifiers are IPv4 addresses? >> > >> >As stated in the draft, it makes EERO processing very very >> simple. There >> >are no abstract node lookups, you just see if you are the >> router with the >> >router ID and then associate with the UP/DOWN-stream >> interfaces and the >> >LSP setup is on its way. The fact that you don't need to do >> a AN lookup by >> >itself probably saves about 1/3 to 2/3 of LSP PATH >> processing in the node. >> > >> > >> >> > Also, loose hops should probably not have any >> associated interfaces. >> >> I'm not sure what it means to have unnumbered interface >> indices with >> >> loose hops. Unfortunately, I cannot make out the use of >> interface IDs >> >> in the context of loose hops from the description in section 3. >> > >> >Why? You can perfectly specify a loose hop where you want the LSP to >> >specifically enter through interface A and leave the hop >> through interface >> >B. I can see benefits of this in a regular MPLS network as well as an >> >optical network. >> > >> >> >> >> Section 3: ERO processing >> >> >> >> There are actually eight cases: with/without EERO-HOPs, >> with/without >> >> AN-HOPs, with/without LR-HOPs. I fail to see how this >> classification >> >> helps, though. You seem to assume that LR-HOPs cannot be >> interspersed >> >> with EERO-HOPs, and that EERO-HOPs must be present. Is >> that what you >> >> meant? >> >> >> > >> >The cases that were stated were examples, it is perfectly >> legal to have >> >only LR-HOPs or AN-HOPs by themselves and add or delete HOPs >> in the middle >> >of an LSP. >> > >> >We will refine this section in the next version of the draft. >> > >> >> IMO the stated goal of "simplification of abstract node >> and loose route >> >> processing" has not been achieved. It may well be that >> ERO processing >> >> should be reworded; if so, the goal should not be to use >> fewer words, >> >> but rather to achieve greater clarity. Of course, the >> current semantics >> >> should be maintained. >> > >> >Kireeti, >> > >> >I think you have seen the problem that we are trying to >> address but do not >> >believe that a new ERO (EERO) is necessary. On the other >> hand, the fact >> >that we have cut the AN lookup out of most EERO processing, >> that we have >> >made >> >the EERO very specific and detailed have achieved our goal. >> If these were >> >in the ERO in the first place, I am sure that at least our >> implementation >> >would have been shorter. > > > >> >We believe that this draft is useful and adds value to existing MPLS >> >implementations and reduces the chance having un-interoperable MPLS >> >implementations. I know of interoperability problems even between two >> >leading vendors' implementations that have brought networks >> down for days, >> >and we are trying to prevent that when there are (say) six vendors' >> >equipment in the network. >> > >> >We appreciate your comments and will incorporate these into the next >> >version of our draft. >> > >> >Regards >> > >> >Bora >> From owner-mpls@UU.NET Mon Feb 26 18:02:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02733 for ; Mon, 26 Feb 2001 18:02: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 QQkeci02565; Mon, 26 Feb 2001 23:02:22 GMT Received: by mail-control.mail.uu.net id QQkeci03560 for mpls-outgoing; Mon, 26 Feb 2001 23:01:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeci03007 for ; Mon, 26 Feb 2001 23:01:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeci29020 for ; Mon, 26 Feb 2001 23:00:28 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 QQkeci00030 for ; Mon, 26 Feb 2001 23:00:27 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA15170; Mon, 26 Feb 2001 15:00:18 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Feb 2001 15:00:18 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA0944EF@avalon.pluris.com> From: Puneet Agarwal To: "'Shahram Davari'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Mon, 26 Feb 2001 15:00:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, Thanks for your comments. My comments are inline. -Puneet > >Hi Puneet/Eric, > >1)You are right we have not described how to signal Pipe/short >pipe/uniform models. Since our draft is in its last call and >can't be changed substantially, I propose that we get together >to write a separate I-D to address the CR-LDP/RSVP-TE >extensions for signaling the tunneling model. Agreed. We can take this up privately with each other. > >2) Section 2.4 does not discuss an important case that is: >egress processing of tunnels, i.e. pop and forwarding the >packet as MPLS. Pop (or Egress Pop to distinguish from PHP) is actually covered in section 2.3. The possibly operation when forwarding the packet as MPLS are covered in the 3 bullets of section 2.4. Combine section 2.3 and the relevant section of 2.4 and I think your concern about the missing case should be answered. Hence as far as I can see the case is convered, but please let me know if you still think that it is not addressed. > >3)As you may know, version -08 of our draft has introduced two >types of Pipe tunnels a) Short pipe and b) Pipe. The short >pipe is what was called the "pipe" in version -07. But the new >"pipe" model is a bit different, in the sense that all the >egress processing is done based on top label. So your >description of TTL processing for the pipe model remains valid >for "short pipe" (except that you need to describe the egress >processing too, see bullet 2 above), but you need to define >another TTL processing rule for the "pipe", which is: the top >label TTL is decremented and checked, while the lower label >TTL (unchanged) is used for forwarding the packet. We had based our draft on -07 version of the mpls-diff draft. I will take into account the -08 version (where the new model nomenclature was introduced) and update our spec accordingly. -Puneet > >Yours, >-Shahram > > > > >> -----Original Message----- >> From: Puneet Agarwal [mailto:puneet@pluris.com] >> Sent: Friday, February 23, 2001 4:53 PM >> To: 'Eric Gray' >> Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >> 'bsd@cisco.com'; Shahram Davari; Bora Akyol >> Subject: RE: New TTL Draft >> >> >> Eric, >> >> Comments inline. >> >> >-----Original Message----- >> >From: Eric Gray [mailto:eric.gray@sandburst.com] >> >Sent: Friday, February 23, 2001 9:34 AM >> >To: Bora Akyol >> >Cc: akyol@akyol.org; djiang1@lucent.com; B, Prakash K (Prakash); >> >'mpls@uu.net' >> >Subject: Re: New TTL Draft >> > >> > >> >Bora/Puneet, >> > >> > Some comments. >> > >> > In section 2.4, item 3 - PHP does not necessarily expose an >> >IP header. The text in this section is not clear in this respect >> >- possibly because of the textual construct "IP-Header/label". >> >It might be somewhat clearer if you use "header" and add a >> >paragraph stating that the PHP exposed header may be either >> >an IP header or an MPLS label and the appropriate oTTL is >> >written to the corresponding TTL field of this PHP exposed >> >header. >> >> I agree. We will change the wording in the next rev of the draft. >> > >> > Also, in this section, why is oTTL set to the TTL of the >> >exposed header if it is not used for anything? >> >> Good point. We do not need to set this. This was a leftover >> from some text >> we took out of section 2.5 at the last moment that used this >> information. We >> will fix this in the next rev. >> > >> > In addition, if your actually specifying a behavior (rather than >> >an architecture), I believe you need to allow that the TTL may >> >be decremented by a number other than one. RFC 791 states >> >that RFC is decremented by at least one. Your draft states in >> >several places that iTTL is decremented (I assume that the >> >underscore in these cases is meant to be a minus sign) by one. >> >> The underscore is indeed supposed to be a minus. Will be >> fixed in the next >> rev. >> I have no problems in allowing the iTTL to be decremented by >> more than one. >> I will change the text to state that the iTTL should be >> decremented by "N", >> where "N" is user configured and is greater than 0. The >> default value of "N" >> should be 1. >> >> > >> > There are practical reasons for decrementing TTL by more >> >than one (a high-cost or low-bandwidth link, for example) >> >when it is desirable to accelerate the aging of possibly looping >> >packets. A higher TTL decrement punishes all packets that use >> >the link, but it punishes looping packets much more. >> > >> > Finally, what is the mechanism which the PHP uses to determine >> >whether or not the LSP is using the pipe or the uniform model? I am >> >not sure this information is currently available. >> >> You may be right. I looked through >> "draft-ietf-mpls-diff-ext-08.txt", but >> did not see any method to signal the model (pipe or uniform) >> associated with >> the LSP, using either RSVP or LDP. If it is a missing piece, >> then I hope >> that it will be addressed by the authors of that draft. >> >> -Puneet >> >> > >> >-- >> >Eric Gray >> > >> >Bora Akyol wrote: >> > >> >> Note that we (Puneet and I) just posted an Internet Draft on TTL >> >> handling in hierarchical MPLS networks. >> >> >> >> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt >> >> >> >> >> http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt >> >> >> >> We welcome any comments, >> >> >> >> Bora Akyol >> > >> > From owner-mpls@UU.NET Mon Feb 26 18:16:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03199 for ; Mon, 26 Feb 2001 18:16: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 QQkecj26475; Mon, 26 Feb 2001 23:16:10 GMT Received: by mail-control.mail.uu.net id QQkecj07540 for mpls-outgoing; Mon, 26 Feb 2001 23:15:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkecj07526 for ; Mon, 26 Feb 2001 23:15:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeci01940 for ; Mon, 26 Feb 2001 23:14:39 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 QQkeci19386 for ; Mon, 26 Feb 2001 23:14:38 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA12123; Mon, 26 Feb 2001 15:14:38 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id PAA16640; Mon, 26 Feb 2001 15:14:38 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102262314.PAA16640@garnet.juniper.net> To: Bora Akyol cc: mpls@UU.NET Subject: Re: New Internet Draft on ERO In-Reply-To: Your message of "Mon, 26 Feb 2001 14:39:37 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16637.983229278.1@garnet.juniper.net> Date: Mon, 26 Feb 2001 15:14:38 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bora, > My question is as follows: > > How do you do fast reroute when you have unnumbered interfaces in the > ERO as in the unnumbered draft? What out of band information is added > to what's in the ERO when we do CSPF? Is everyone doing it the same > way? > > If we use the (newly defined) EERO then fast reroute is the same for > both numbered and unnumbered interfaces and it actually becomes quite > easy. Could you point me to the MPLS WG document(s) that specifies how to perform fast re-route ? Yakov. From owner-mpls@UU.NET Mon Feb 26 18:55:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04928 for ; Mon, 26 Feb 2001 18:55: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 QQkecl22305; Mon, 26 Feb 2001 23:55:00 GMT Received: by mail-control.mail.uu.net id QQkecl11765 for mpls-outgoing; Mon, 26 Feb 2001 23:53: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 QQkecl11753 for ; Mon, 26 Feb 2001 23:53: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 QQkecl17966 for ; Mon, 26 Feb 2001 23:51:49 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkecl26156 for ; Mon, 26 Feb 2001 23:51:49 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA09570 for mpls@uu.net; Mon, 26 Feb 2001 18:51: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 QQkecl11521 for ; Mon, 26 Feb 2001 23:51: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 QQkecl15297 for ; Mon, 26 Feb 2001 23:50:57 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkecl08866 for ; Mon, 26 Feb 2001 23:50:57 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA21855; Mon, 26 Feb 2001 15:50:52 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <200102262314.PAA16640@garnet.juniper.net> References: <200102262314.PAA16640@garnet.juniper.net> Date: Mon, 26 Feb 2001 15:49:29 -0800 To: Yakov Rekhter From: Bora Akyol Subject: Re: New Internet Draft on ERO Cc: Bora Akyol , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 3:14 PM -0800 2/26/01, Yakov Rekhter wrote: >Bora, > >> My question is as follows: >> >> How do you do fast reroute when you have unnumbered interfaces in the >> ERO as in the unnumbered draft? What out of band information is added >> to what's in the ERO when we do CSPF? Is everyone doing it the same >> way? >> >> If we use the (newly defined) EERO then fast reroute is the same for >> both numbered and unnumbered interfaces and it actually becomes quite >> easy. > >Could you point me to the MPLS WG document(s) that specifies >how to perform fast re-route ? > >Yakov. Well, there was the ID from George Swallow that we discussed in San Diego. And then there were some discussions on the list that I participated in 1998. Vishal Sharma et al, produced IDs on that subject as well. Maybe it is time that we write a BCP on that topic. Would this fall into CCAMP or MPLS? In the last IETF, **all** of the fast reroute/recovery schemes were sent to CCAMP AFAIK. I know how we implemented fast reroute and I am sure you know of at least two implementations. So if there is interest on the WG, I can volunteer to put together a group of people to write such a BCP. But my original question still stands, how do you do fast reroute when you have unnumbered interfaces? It is possible to do, but becomes much easier if you have the router ID as part of the ERO subobject as we did in our EERO specification. Please see draft-akyol-mpls-exp-ero-00.txt Regards Bora From owner-mpls@UU.NET Mon Feb 26 20:22:11 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08243 for ; Mon, 26 Feb 2001 20:22: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 QQkecr10426; Tue, 27 Feb 2001 01:21:55 GMT Received: by mail-control.mail.uu.net id QQkecr05102 for mpls-outgoing; Tue, 27 Feb 2001 01: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 QQkecr05077 for ; Tue, 27 Feb 2001 01:21: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 QQkecr13706 for ; Tue, 27 Feb 2001 01:20:48 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkecr10945 for ; Tue, 27 Feb 2001 01:20:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA14310 for mpls@uu.net; Mon, 26 Feb 2001 20:20: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 QQkecr04973 for ; Tue, 27 Feb 2001 01:20:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkecr10937 for ; Tue, 27 Feb 2001 01:19:55 GMT Received: from nero.doit.wisc.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQkecr07749 for ; Tue, 27 Feb 2001 01:19:55 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id TAA09463 for mpls@uu.net; Mon, 26 Feb 2001 19:19:54 -0600 Date: Mon, 26 Feb 2001 19:19:54 -0600 From: "James R. Leu" To: mpls@UU.NET Subject: RFC3036(LDP): Detect Change in FEC Next Hop Message-ID: <20010226191954.A9419@doit.wisc.edu> Reply-To: jleu@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello, (Excuse me if this has already been discussed, just send me the pointer and I'll be on my way.) In "Detect Change in FEC Next Hop" Note 4 states: 4. Regardless of the Label Request procedure in use by the LSR, it must send a label request if the conditions in NH.8 hold. Therefore it executes the Send_Label_Request procedure directly rather than perform LSR Label Request procedure. .. but when looking at NH.8: NH.8 Execute procedure Send_Message (Old Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request Message ID TLV that carries the message ID of the pending label request. .. I do not see any conditions to hold true. I'm thinking Note 4 was unchanged when the "Label Abort Request" support was added many revisions ago. I think the conditions that need to hold true are: NH.6 Does LSR have a label request pending with Old Next Hop? If not, goto NH.10. NH.7 Is LSR using Conservative label retention? If not, goto NH.10. Could anyone shed any light on this? If not, does anyone remember what revision added the "Label Abort Request" message? Thanks, Jim -- James R. Leu From owner-mpls@UU.NET Mon Feb 26 23:47:06 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14790 for ; Mon, 26 Feb 2001 23:47:06 -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 QQkedf06988; Tue, 27 Feb 2001 04:46:52 GMT Received: by mail-control.mail.uu.net id QQkedf16761 for mpls-outgoing; Tue, 27 Feb 2001 04:46: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 QQkedf16691 for ; Tue, 27 Feb 2001 04:46:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkedf12560 for ; Tue, 27 Feb 2001 04:45:29 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkedf04300 for ; Tue, 27 Feb 2001 04:45:28 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 27 Feb 2001 10:21:50 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.0.14.17]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f1RAJec01044; Tue, 27 Feb 2001 15:49:40 +0530 Message-Id: <00c301c0a077$ac4aa7a0$110e000a@future.futsoft.com> Reply-To: "Abdul Malick" From: "Abdul Malick" To: "Shahram Davari" , Cc: References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AA0@BBY1EXM01> Subject: Re: per interface lable space validity Date: Tue, 27 Feb 2001 10:12:20 +0530 Organization: Future Software Ltd., MIME-Version: 1.0 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 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi I feel that even if you tunnel the signalling b/w a LSR and its remote peer, and if this tunnel may be rerouted (for TE purpose) , then again using per-interface label space could be a problem. Only if the tunnel is permanent we can use per-interface label space, otherwise only per-platform label space should be used. Please correct me if i am wrong Cheers Malick ----- Original Message ----- From: "Shahram Davari" To: ; Sent: Monday, February 26, 2001 8:11 PM Subject: RE: per interface lable space validity > Hi, > > In your scenario, if the signaling (CR-LDP/RSVP-TE) is tunneled through that tunnel then you can use per-interface label space, otherwise you should use per-platform label space, because you don't know from which interface the packet will arrive. > > Yours, > -Shahram > > > -----Original Message----- > > From: shen jing [mailto:jshen@cad.zju.edu.cn] > > Sent: Monday, February 26, 2001 5:56 AM > > To: mpls@UU.NET > > Subject: per interface lable space validity > > > > > > I'm reading rfc3036 - "LDP specification", at section 2.2.1 > > Lable spaces > > , it is said a per interface > > lable space only makes sense when the LDP peers are "directly > > connected". > > what is "directly connected" ? If two LSRs are connected by a tunnel > > which generate > > another layer on Label stack , a per interface label is not > > meaningful ? > > > > thanks a lot. > > > > James Shen > > > From owner-mpls@UU.NET Tue Feb 27 01:03:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15837 for ; Tue, 27 Feb 2001 01:03: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 QQkedk24455; Tue, 27 Feb 2001 06:03:27 GMT Received: by mail-control.mail.uu.net id QQkedk09759 for mpls-outgoing; Tue, 27 Feb 2001 06:03: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 QQkedk09751 for ; Tue, 27 Feb 2001 06:02:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkedk08884 for ; Tue, 27 Feb 2001 06:02:47 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkedk23149 for ; Tue, 27 Feb 2001 06:02:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA28428 for mpls@uu.net; Tue, 27 Feb 2001 01:02: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 QQkedf17451 for ; Tue, 27 Feb 2001 04:55:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkedf01276 for ; Tue, 27 Feb 2001 04:54:30 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 QQkedf05321 for ; Tue, 27 Feb 2001 04:54:30 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA24443; Mon, 26 Feb 2001 20:54:29 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id UAA07382; Mon, 26 Feb 2001 20:54:29 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Mon, 26 Feb 2001 20:54:29 -0800 (PST) From: Bora Akyol To: Abdul Malick cc: Shahram Davari , jshen@cad.zju.edu.cn, mpls@UU.NET Subject: Re: per interface lable space validity In-Reply-To: <00c301c0a077$ac4aa7a0$110e000a@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk When you set up the fast reroute LSP, you use a shared explicit style reservation and set up the ERO for the fast reroute to join the original path as soon as possible. If you do it this way, then you don't need the per platform wide label space. If you do it as described in George Swallow's internet draft on bypass LSPs then you need the per platform wide label space. That method however only protects against link failures and not router failures. Bora On Tue, 27 Feb 2001, Abdul Malick wrote: > Hi > I feel that even if you tunnel the signalling b/w a LSR and its remote peer, > and if this tunnel may be rerouted (for TE purpose) , then again using > per-interface label space could be a problem. Only if the tunnel is > permanent we can use per-interface label space, otherwise only per-platform > label space should be used. > > Please correct me if i am wrong > > Cheers > Malick > ----- Original Message ----- > From: "Shahram Davari" > To: ; > Sent: Monday, February 26, 2001 8:11 PM > Subject: RE: per interface lable space validity > > > > Hi, > > > > In your scenario, if the signaling (CR-LDP/RSVP-TE) is tunneled through > that tunnel then you can use per-interface label space, otherwise you should > use per-platform label space, because you don't know from which interface > the packet will arrive. > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: shen jing [mailto:jshen@cad.zju.edu.cn] > > > Sent: Monday, February 26, 2001 5:56 AM > > > To: mpls@UU.NET > > > Subject: per interface lable space validity > > > > > > > > > I'm reading rfc3036 - "LDP specification", at section 2.2.1 > > > Lable spaces > > > , it is said a per interface > > > lable space only makes sense when the LDP peers are "directly > > > connected". > > > what is "directly connected" ? If two LSRs are connected by a tunnel > > > which generate > > > another layer on Label stack , a per interface label is not > > > meaningful ? > > > > > > thanks a lot. > > > > > > James Shen > > > > > > From owner-mpls@UU.NET Tue Feb 27 03:27:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01645 for ; Tue, 27 Feb 2001 03:27:14 -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 QQkedt11756; Tue, 27 Feb 2001 08:26:59 GMT Received: by mail-control.mail.uu.net id QQkedt08307 for mpls-outgoing; Tue, 27 Feb 2001 08:26: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 QQkedt08264 for ; Tue, 27 Feb 2001 08:26: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 QQkedt25391 for ; Tue, 27 Feb 2001 08:25:55 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkedt25310 for ; Tue, 27 Feb 2001 08:25:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA06104 for mpls@uu.net; Tue, 27 Feb 2001 03:25:54 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkedt08118 for ; Tue, 27 Feb 2001 08:25:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkedt01145 for ; Tue, 27 Feb 2001 08:24:10 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 QQkedt08294 for ; Tue, 27 Feb 2001 08:24:10 GMT Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id DAA23276; Tue, 27 Feb 2001 03:23:22 -0500 (EST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1R8Jpq01545; Tue, 27 Feb 2001 00:19:51 -0800 (PST) Received: from jlawrenc-pc.cisco.com (hongkong-dhcp-85-158.cisco.com [171.68.85.158]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id AAA16568; Tue, 27 Feb 2001 00:19:41 -0800 (PST) Message-Id: <4.3.2.7.2.20010227191307.00b27460@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 19:19:28 +1100 To: Paul Moore From: Jeremy Lawrence Subject: RE: MPLS LSPs and ATM PVCs Cc: mpls@UU.NET, Dmitry Ryumkin In-Reply-To: <89E067900D3FA84A97495C71556140E402D8AA@edgsvr01.edgeflow.e dgeflow.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Dmitry is quite correct, but a comment on applicability: Bi-directional ATM LSPs might be useful for traffic engineering (for example). However scaling ATM VC-based MPLS to any-to-any connectivity amongst more than a couple of hundred or so eLSRs will typically require VC-merge capability. VC merging is an inherently unidirectional concept, so the applicability of bi-directional VCs in ATM VC-based MPLS is somewhat limited. Regards, Jeremy Lawrence At 09:12 02/26/2001 -0500, Dmitry Ryumkin wrote: >Paul, > >Generalized MPLS defines procedures for bi-directional LSP setup. > >Regards, >Dmitry Ryumkin > > -----Original Message----- >From: djiang1@lucent.com [mailto:djiang1@lucent.com] >Sent: Monday, February 26, 2001 8:52 AM >To: Paul Moore >Cc: mpls@UU.NET >Subject: Re: MPLS LSPs and ATM PVCs > > >HI Paul, > >I believe RSVP is never intended to set up two LSPs using one single >operation. We will have to use two RSVP signalling operations to set up >the two LSPs, one for each direction, even if the PVC may be used >bidirectionally. > >Regards, >Jane D. Jiang > > > > >Paul Moore @UU.NET on 02/26/2001 08:11:29 AM > >Sent by: owner-mpls@UU.NET > > >To: mpls@UU.NET >cc: >Subject: MPLS LSPs and ATM PVCs > > >Hello, > >I have a question about MPLS and ATM. ATM point-to-point PVCs can be >either uni-directional or bi-directional. MPLS LSPs are only >uni-directional. Is there any work being done concerning bi-directional >LSPs, for example, to allow two LSPs to be established by a single RSVP >signalling operation? > >I've just joined the list, so apologies if this has already been >discussed. > >Thanks, >Paul > >-- >Paul Moore >Alcatel Bell >+32 3 450 3536 >paul-patrick.moore@alcatel.be From owner-mpls@UU.NET Tue Feb 27 04:00:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01921 for ; Tue, 27 Feb 2001 04:00: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 QQkedw08627; Tue, 27 Feb 2001 09:00:34 GMT Received: by mail-control.mail.uu.net id QQkedw12282 for mpls-outgoing; Tue, 27 Feb 2001 09:00:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkedw11307 for ; Tue, 27 Feb 2001 09:00:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkedv23468 for ; Tue, 27 Feb 2001 08:59:54 GMT From: nagaraj@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 QQkedv16866 for ; Tue, 27 Feb 2001 08:59:53 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id SAA21744 for ; Tue, 27 Feb 2001 18:01:25 +0900 (KST) X-OpenMail-Hops: 2 Date: Tue, 27 Feb 2001 18:00:29 +0900 Message-Id: Subject: RFC-3036(LDP Specs) MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Tue, 27 Feb 2001 17:51:14 +0900" ;Modification-Date="Tue, 27 Feb 2001 18:00:06 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Section 3.5.3 of RFC-3036 states that "A value of 255 or less specifies the default maximum length of 4096 octets". In Common Session Parameters TLV header ,2 octets are reserved for Max PDU Length field. If this is the case how is the number 255 arrived at ? Raj From owner-mpls@UU.NET Tue Feb 27 04:29:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02107 for ; Tue, 27 Feb 2001 04:29: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 QQkedx13596; Tue, 27 Feb 2001 09:29:02 GMT Received: by mail-control.mail.uu.net id QQkedx21492 for mpls-outgoing; Tue, 27 Feb 2001 09:28:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkedx21487 for ; Tue, 27 Feb 2001 09:28:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkedx27100 for ; Tue, 27 Feb 2001 09:27:58 GMT Received: from daewoo.dti.daewoo.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQkedx11759 for ; Tue, 27 Feb 2001 09:27:37 GMT Received: from neelesh ([165.133.13.22]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id OAA06109; Tue, 27 Feb 2001 14:50:11 -0600 (GMT) Message-ID: <012d01c0a09f$90aa54a0$160d85a5@dti.daewoo.co.kr> Reply-To: "Neelesh Dwivedi" From: "Neelesh Dwivedi" To: Cc: Subject: Fw: RFC-3036(LDP Specs) Date: Tue, 27 Feb 2001 14:57:55 +0530 Organization: Mercury Corporation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012A_01C0A0CD.AA37D720" 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_012A_01C0A0CD.AA37D720 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! Please see comments below. =20 "Section 3.5.3 of RFC-3036 states that "A value of 255 or less specifies = the default maximum length of 4096 octets". In Common Session Parameters TLV header ,2 octets are reserved for Max = PDU Length field. If this is the case how is the number 255 arrived at ? = " From what I understand, this means that though 2 octets have been = reserved for the Max. PDU Length, ( i.e., a maximum length of 65535 can = be specified ), if a value of 255 or less is encountered in an initialisation message, = the default value of 4096 octets has to be taken. In other words, any = value of 255 or below is to be overrided and the default 4096 octets is = to be considered while deciding the Max PDU LEngth for the session. I hope that helps. :) Regards, Neelesh. ---------------------------------------------------------------- Engineer Mercury Corporation( Previously Daewoo Telecom Ltd.) New Delhi R & D Centre Gurgaon India ------=_NextPart_000_012A_01C0A0CD.AA37D720 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi!
Please see comments = below.
 
"Section 3.5.3 of RFC-3036 states that = "A value of=20 255 or less specifies the default maximum length of 4096 octets".
In = Common=20 Session Parameters TLV header ,2 octets are reserved for Max PDU Length = field.=20 If this is the case how is the number 255 arrived at ? "
 
From what = I understand, this=20 means that though 2 octets have been reserved for the Max. PDU Length, ( = i.e., a=20 maximum length of 65535 can be specified ),
if a value of 255 or = less is=20 encountered in an initialisation message, the default value of 4096 = octets has=20 to be taken. In other words, any value of 255 or below is to be = overrided and=20 the default 4096 octets is to be considered while deciding the Max = PDU=20 LEngth for the session.
I hope that helps. = :)
 
Regards,
Neelesh.
----------------------------------------------------= ------------
Engineer
Mercury=20 Corporation( Previously Daewoo Telecom Ltd.)
New Delhi R & D=20 Centre
Gurgaon
India
------=_NextPart_000_012A_01C0A0CD.AA37D720-- From owner-mpls@UU.NET Tue Feb 27 06:53:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04250 for ; Tue, 27 Feb 2001 06:53: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 QQkeeh10345; Tue, 27 Feb 2001 11:52:57 GMT Received: by mail-control.mail.uu.net id QQkeeh17461 for mpls-outgoing; Tue, 27 Feb 2001 11:52:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeeh17456 for ; Tue, 27 Feb 2001 11:52:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeeh12527 for ; Tue, 27 Feb 2001 11:52:17 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeeh09497 for ; Tue, 27 Feb 2001 11:52:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA15846 for mpls@uu.net; Tue, 27 Feb 2001 06:52:16 -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 QQkeeh17416 for ; Tue, 27 Feb 2001 11:51:27 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 QQkeeh22208 for ; Tue, 27 Feb 2001 11:51:02 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 QQkeeh08057 for ; Tue, 27 Feb 2001 11:51:02 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03698; Tue, 27 Feb 2001 06:51:01 -0500 (EST) Message-Id: <200102271151.GAA03698@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-nadeau-mpls-ds-te-mib-00.txt Date: Tue, 27 Feb 2001 06:51:01 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diff-Serv-aware MPLS Traffic Engineering Network Management Information Base Using SMIv2 Author(s) : T. Nadeau et al. Filename : draft-nadeau-mpls-ds-te-mib-00.txt Pages : 25 Date : 26-Feb-01 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, in response to customer demands and strong input from vendors, it describes managed objects for modeling and managing Diff-Serv-aware MPLS Traffic Engineering [DSTEREQS][DSTEEXTS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nadeau-mpls-ds-te-mib-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-nadeau-mpls-ds-te-mib-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-nadeau-mpls-ds-te-mib-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: <20010226143155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nadeau-mpls-ds-te-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nadeau-mpls-ds-te-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010226143155.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Feb 27 09:33:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09756 for ; Tue, 27 Feb 2001 09:33: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 QQkees06530; Tue, 27 Feb 2001 14:33:08 GMT Received: by mail-control.mail.uu.net id QQkees26523 for mpls-outgoing; Tue, 27 Feb 2001 14:32:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkees26517 for ; Tue, 27 Feb 2001 14:32:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkees22113 for ; Tue, 27 Feb 2001 14:31:36 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQkees04397 for ; Tue, 27 Feb 2001 14:31:36 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f1RETng29988; Tue, 27 Feb 2001 09:29:50 -0500 (EST) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 09:24:58 -0500 Message-ID: <0CD7D73C734BD411AEE100B0D0220404DFDDA2@mail1.tellium.com> From: Bala Rajagopalan To: "'Bora Akyol'" , Yakov Rekhter Cc: mpls@UU.NET Subject: RE: New Internet Draft on ERO Date: Tue, 27 Feb 2001 09:24: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 Hi, This is all rather mysterious. Following up on Jonathan Lang's and Yakov's earlier questions, could you please describe what the problem is w.r.t fast reroute? Also, in your draft, what's the need to specify both ingress and egress interface identifiers for EERO hops? isn't one of them enough? Regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Monday, February 26, 2001 6:49 PM > To: Yakov Rekhter > Cc: Bora Akyol; mpls@UU.NET > Subject: Re: New Internet Draft on ERO > > > At 3:14 PM -0800 2/26/01, Yakov Rekhter wrote: > >Bora, > > > >> My question is as follows: > >> > >> How do you do fast reroute when you have unnumbered > interfaces in the > >> ERO as in the unnumbered draft? What out of band > information is added > >> to what's in the ERO when we do CSPF? Is everyone doing > it the same > >> way? > >> > >> If we use the (newly defined) EERO then fast reroute is > the same for > >> both numbered and unnumbered interfaces and it actually > becomes quite > >> easy. > > > >Could you point me to the MPLS WG document(s) that specifies > >how to perform fast re-route ? > > > >Yakov. > > Well, there was the ID from George Swallow that we discussed in San > Diego. And then there were some discussions on the list that I > participated in 1998. Vishal Sharma et al, produced IDs on that > subject as well. > > > Maybe it is time that we write a BCP on that topic. Would this fall > into CCAMP or MPLS? In the last IETF, **all** of the fast > reroute/recovery schemes were sent to CCAMP AFAIK. > > I know how we implemented fast reroute and I am sure you know of at > least two implementations. > > So if there is interest on the WG, I can volunteer to put together a > group of people to write such a BCP. > > But my original question still stands, > > how do you do fast reroute when you have unnumbered interfaces? It is > possible to do, but becomes much easier if you have the router ID as > part of the ERO subobject as we did in our EERO specification. Please > see draft-akyol-mpls-exp-ero-00.txt > > > Regards > > Bora > From owner-mpls@UU.NET Tue Feb 27 09:34:38 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09820 for ; Tue, 27 Feb 2001 09:34: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 QQkees08237; Tue, 27 Feb 2001 14:34:11 GMT Received: by mail-control.mail.uu.net id QQkees26590 for mpls-outgoing; Tue, 27 Feb 2001 14:33: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 QQkees26567 for ; Tue, 27 Feb 2001 14:33: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 QQkees29185 for ; Tue, 27 Feb 2001 14:33: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 QQkees06515 for ; Tue, 27 Feb 2001 14:33: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 GAA17263 for ; Tue, 27 Feb 2001 06:33:25 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA26257 for mpls@uu.net; Tue, 27 Feb 2001 09:33: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 QQkeej27499 for ; Tue, 27 Feb 2001 12:22: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 QQkeej25281 for ; Tue, 27 Feb 2001 12:21:24 GMT Received: from willers.employees.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: willers.employees.org [192.31.7.82]) id QQkeej23397 for ; Tue, 27 Feb 2001 12:21:24 GMT Received: from localhost (calin@localhost) by willers.employees.org (8.11.1/8.11.1) with SMTP id f1RCLNB03256; Tue, 27 Feb 2001 04:21:23 -0800 (PST) Date: Tue, 27 Feb 2001 04:21:22 -0800 (PST) From: Calin Poenaru Reply-To: Calin Poenaru To: mpls@UU.NET cc: neil.2.harrison@bt.com Subject: OAM for MPLS networks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello! I have a question about the efficiency of the mechanism for connectivity verification described in draft-harrison-mpls-oam-00: there is proposed a scheme which is very similar with I.610 and (in my opinion) has the same drawback - a time for detect and react too high. In other words: the 10 seconds necessary for detect the unavailable state is far too long to affect all the connections in the failed LSP. And more, the 20 seconds (minimum) required for re-entering in the available state is too much to be useful for the traffic (in this time the Control Plane probably already take some actions like reroute or something else). Could you comment a little bit about this issues? And another question: at 6.6.3 you stated that the exit from Far-End Defect State is conditioned by 3 consecutive seconds without BDI OAM packets. But what if an FDI OAM packet will come? It will not force the exit from this state and go into Near-End Defect State? Thank you in advance for your time! Best regads, Calin --- From owner-mpls@UU.NET Tue Feb 27 10:06:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10971 for ; Tue, 27 Feb 2001 10:06: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 QQkeeu28154; Tue, 27 Feb 2001 15:05:49 GMT Received: by mail-control.mail.uu.net id QQkeeu07621 for mpls-outgoing; Tue, 27 Feb 2001 15:05:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeeu07613 for ; Tue, 27 Feb 2001 15:05:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeeu10000 for ; Tue, 27 Feb 2001 15:04:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeeu03600 for ; Tue, 27 Feb 2001 15:04:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA29102 for mpls@uu.net; Tue, 27 Feb 2001 10:04: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 QQkeeu07586 for ; Tue, 27 Feb 2001 15:04:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeeu12956 for ; Tue, 27 Feb 2001 15:03:16 GMT Received: from franklin.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: franklin.cisco.com [171.70.156.17]) id QQkeeu17910 for ; Tue, 27 Feb 2001 15:03:15 GMT Received: from WMAOW2K (beijing-async-29.cisco.com [171.70.180.29]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA28133 for ; Tue, 27 Feb 2001 07:03:12 -0800 (PST) Message-ID: <002001c0a0ce$6d3d60a0$1db446ab@WMAOW2K> From: "wmao" To: Date: Tue, 27 Feb 2001 23:03:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C0A111.79E28C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C0A111.79E28C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_001D_01C0A111.79E28C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 unsubscribe
 
 

 
------=_NextPart_000_001D_01C0A111.79E28C20-- From owner-mpls@UU.NET Tue Feb 27 10:15:51 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11761 for ; Tue, 27 Feb 2001 10:15: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 QQkeev18730; Tue, 27 Feb 2001 15:15:35 GMT Received: by mail-control.mail.uu.net id QQkeeu08811 for mpls-outgoing; Tue, 27 Feb 2001 15:14: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 QQkeeu08799 for ; Tue, 27 Feb 2001 15:14:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeeu06273 for ; Tue, 27 Feb 2001 15:14:17 GMT Received: from dgesmtp01.wcom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dgesmtp01.wcom.com [199.249.16.16]) id QQkeeu03386 for ; Tue, 27 Feb 2001 15:14:16 GMT Disposition-notification-to: lei.yao@wcom.com Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G9F00MEA8XXV6@firewall.mcit.com> for mpls@uu.net; Tue, 27 Feb 2001 15:13:09 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G9F00M018XHB6@pmismtp04.wcomnet.com> for mpls@uu.net; Tue, 27 Feb 2001 15:13:08 +0000 (GMT) Received: from pc84522 ([166.60.14.88]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G9F00M3C8XF1X@pmismtp04.wcomnet.com>; Tue, 27 Feb 2001 15:12:52 +0000 (GMT) Date: Tue, 27 Feb 2001 10:09:21 -0500 From: Lei Yao Subject: Re: draft-bonica-tunneltrace-01.txt To: rbonica@mci.net Cc: dave.mcdysan@wcom.com, mpls@UU.NET Reply-to: lei.yao@wcom.com Message-id: <001a01c0a0cf$44387900$580e3ca6@loudoun.mci.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook CWS, 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 Ron, I have a couple of comments on the new draft. 1. In section 6, requirement 5 states, " Permit the application user to specify whether the application should yield tunnel details or not". However, there is no indication of user's request on this topic in Trace-probe message. I suggest that a depth parameter is added in Trace-probe message. With the depth parameter, the application user can state the level of details that he would like to learn. 2. Since a trace-response message is returned to the head-end node by every intermediate node, it is possible to compute the delay on each hop. It will be a very useful feature to discover the abnormal node/link. Thanks. Lei From owner-mpls@UU.NET Tue Feb 27 10:35:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12761 for ; Tue, 27 Feb 2001 10:35: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 QQkeew09205; Tue, 27 Feb 2001 15:34:57 GMT Received: by mail-control.mail.uu.net id QQkeew11090 for mpls-outgoing; Tue, 27 Feb 2001 15:34: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 QQkeew11079 for ; Tue, 27 Feb 2001 15:34:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeew16417 for ; Tue, 27 Feb 2001 15:33:35 GMT Received: from hoemlsrv.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkeew00588 for ; Tue, 27 Feb 2001 15:33:35 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA14591 for ; Tue, 27 Feb 2001 10:33:34 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA14582 for ; Tue, 27 Feb 2001 10:33:34 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA28734; Tue, 27 Feb 2001 10:33:33 -0500 (EST) Message-ID: <3A9BC8CD.ADB90F3C@lucent.com> Date: Tue, 27 Feb 2001 10:33:33 -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: mpls@UU.NET Subject: Re: New Internet Draft on ERO References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I don't remember the question was answered in the previous discussion, which ended silently. So, if the router ID is not in ERO, where is it? Thanks for updating me. Yangguang > > > By the way, the idea of adding a router ID to unnumbered interface > > objects was discussed on the MPLS mailing list several months ago and > > discarded as unnecessary. > > I know, I was part of the discussion, but I don't recall anyone objecting > to a new EERO at the time ;-) > From owner-mpls@UU.NET Tue Feb 27 10:50:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13503 for ; Tue, 27 Feb 2001 10:50: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 QQkeex07507; Tue, 27 Feb 2001 15:50:03 GMT Received: by mail-control.mail.uu.net id QQkeex12892 for mpls-outgoing; Tue, 27 Feb 2001 15:49:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeex12879 for ; Tue, 27 Feb 2001 15:48:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeex06932 for ; Tue, 27 Feb 2001 15:48:38 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkeex21088 for ; Tue, 27 Feb 2001 15:48:37 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 8DB8B94006; Tue, 27 Feb 2001 10:48:36 -0500 (EST) Message-ID: <3A9BCC54.DFB77D27@sandburst.com> Date: Tue, 27 Feb 2001 10:48:36 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeremy Lawrence Cc: Paul Moore , mpls@UU.NET, Dmitry Ryumkin Subject: Re: MPLS LSPs and ATM PVCs References: <4.3.2.7.2.20010227191307.00b27460@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, An observation: the ATM model of bi-directionality is being assumed (at least apparently) in you comment. It is not impossible to establish link-by-link bi-directionality - though it is probably more difficult than it is worth. Consider this scenario: --- R1 --- R2 --- All that would be required would be for R1 and R2 to associate a given pair of labels with a pair of FECs in a label negotiation exchange - i.e. (R1, Label-1:FEC-A); (R2, Label-2:FEC-B) where Label-1 is associated with FEC-A at R1 and distributed to R2 while Label-2 is associated with FEC-B at R2 and the association is distributed to R1. Label-1 and Label-2 could be numerically identical and FEC-A unrelated to FEC-B. In fact, the way that LDP is right now, this can be done in 2 PDUs (if not 2 messages): the first one (say from R1) has two mesaages in it: a label request message for FEC-B and an unsolicited label mapping message (with Label-1) for FEC-A. R2 then returns an LDP PDU with a label mapping message (with Label-2 - possibly the same as Label-1) for FEC-A. If the intention is to associate the same label bi- directionally with different FECs, it's almost a shame that two messages are required in the first LDP PDU. But this is not the meaning of bi-directional that you are discussing, is it? :-) -- Eric Gray You wrote: > Dmitry is quite correct, but a comment on applicability: > Bi-directional ATM LSPs might be useful for traffic engineering > (for example). However scaling ATM VC-based MPLS to any-to-any > connectivity amongst more than a couple of hundred or so eLSRs > will typically require VC-merge capability. VC merging is an > inherently unidirectional concept, so the applicability of > bi-directional VCs in ATM VC-based MPLS is somewhat limited. > > Regards, > > Jeremy Lawrence > > At 09:12 02/26/2001 -0500, Dmitry Ryumkin wrote: > >Paul, > > > >Generalized MPLS defines procedures for bi-directional LSP setup. > > > >Regards, > >Dmitry Ryumkin > > > > -----Original Message----- > >From: djiang1@lucent.com [mailto:djiang1@lucent.com] > >Sent: Monday, February 26, 2001 8:52 AM > >To: Paul Moore > >Cc: mpls@UU.NET > >Subject: Re: MPLS LSPs and ATM PVCs > > > > > >HI Paul, > > > >I believe RSVP is never intended to set up two LSPs using one single > >operation. We will have to use two RSVP signalling operations to set up > >the two LSPs, one for each direction, even if the PVC may be used > >bidirectionally. > > > >Regards, > >Jane D. Jiang > > > > > > > > > >Paul Moore @UU.NET on 02/26/2001 08:11:29 AM > > > >Sent by: owner-mpls@UU.NET > > > > > >To: mpls@UU.NET > >cc: > >Subject: MPLS LSPs and ATM PVCs > > > > > >Hello, > > > >I have a question about MPLS and ATM. ATM point-to-point PVCs can be > >either uni-directional or bi-directional. MPLS LSPs are only > >uni-directional. Is there any work being done concerning bi-directional > >LSPs, for example, to allow two LSPs to be established by a single RSVP > >signalling operation? > > > >I've just joined the list, so apologies if this has already been > >discussed. > > > >Thanks, > >Paul > > > >-- > >Paul Moore > >Alcatel Bell > >+32 3 450 3536 > >paul-patrick.moore@alcatel.be From owner-mpls@UU.NET Tue Feb 27 11:04:56 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14278 for ; Tue, 27 Feb 2001 11:04: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 QQkeey20685; Tue, 27 Feb 2001 16:04:39 GMT Received: by mail-control.mail.uu.net id QQkeey22913 for mpls-outgoing; Tue, 27 Feb 2001 16:04: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 QQkeey22763 for ; Tue, 27 Feb 2001 16:04:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeey08635 for ; Tue, 27 Feb 2001 16:03:44 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQkeey11944 for ; Tue, 27 Feb 2001 16:03:43 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA14841 for ; Tue, 27 Feb 2001 17:03:42 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA21734 for ; Tue, 27 Feb 2001 17:03:42 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 17:03:41 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A273C48@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: mpls@UU.NET Subject: resource reservation for LSPs Date: Tue, 27 Feb 2001 17:03:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I'm wondering about the definition for bandwidth reservation for LSPs. Sorry if this is obvious. My understanding is the following: Bandwidth for LSPs can be reserved using e.g. RSVP-TE. However, what does "reservation" mean? It means that at LSP establishment time, the LSR checks whether it has enough resources available. However, it only does a "book keeping" of its resources. It does not need to control their actual use. Admission control and policing must be performed by the LERs. If they don't do it, bandwidth is not guaranteed. I derived this understanding from conversations with others. Cisco seems to implement it this way. Checking on RFCs and IDs however, the picture is not entirely straight: draft-ietf-mpls-diff-ext-08.txt (MPLS Support of Differentiated Services) corroborates the above view: "Establishing an E-LSP or L-LSP with bandwidth reservation means that bandwidth requirements for the LSP are signaled at LSP establishment time. Such signaled bandwidth requirements may be used by LSRs at establishment time to perform admission control of the signaled LSP over the Diff-Serv resources provisioned (e.g. via configuration, SNMP or policy protocols) for the relevant PSC(s)" I.e. there is no mention of using the signaled bandwidth for on-line control of resource usage. I would expect to find something on the subject in the RSVP-TE draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. However, it only seems to talk about "reserving" bandwidth without defining what that is. It also says: "an implementation SHOULD support the Controlled-Load service" Checking, on "Controlled-Load service" one finds: "Network elements must not assume that data sources or upstream elements have taken action to "police" controlled-load flows by limiting their traffic to conform to the flow's TSpec. Each network element providing controlled-load service MUST independently ensure that the requirements given above are met in the presence of nonconformant arriving traffic for one or more controlled-load flows." I.e. each individual LSP is responsible for guaranteeing bandwidth after all. Additionally, RFC 2205 on RSVP states "During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". ... If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. " So RSVP seems to require the individual routers make sure all flows receive their due. Since RSVP-TE is just an extension of RSVP I would assume it works with the same router requirements. I am confused. Which one is it, must LSPs assure bandwidth reservations are met, or not? Thanks for your help, -- Cornelia Kappler From owner-mpls@UU.NET Tue Feb 27 11:43:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16632 for ; Tue, 27 Feb 2001 11:43: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 QQkefa21350; Tue, 27 Feb 2001 16:42:50 GMT Received: by mail-control.mail.uu.net id QQkefa27037 for mpls-outgoing; Tue, 27 Feb 2001 16:42: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 QQkefa27030 for ; Tue, 27 Feb 2001 16:42: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 QQkefa16473 for ; Tue, 27 Feb 2001 16:41:07 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkefa11754 for ; Tue, 27 Feb 2001 16:41:07 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 5A17994006; Tue, 27 Feb 2001 11:41:07 -0500 (EST) Message-ID: <3A9BD8A3.9867FBC6@sandburst.com> Date: Tue, 27 Feb 2001 11:41:07 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Kappler Cornelia Cc: mpls@UU.NET Subject: Re: resource reservation for LSPs References: <4D486782CA36D4118A530000D11EA42A273C48@blns204e.bln.icn.siemens.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Cornelia Kappler, Increasingly often, the systems in production have the basic capability (perhaps a software/firmware upgrade is required) to manage bandwidth. This is necessary in the general case in order to be able to guarantee bandwidth through the network - even when ingress devices are policing and/or traffic shaping the data they admit to the network. This is true because not all traffic is strictly subject to admission control based on a bandwidth guarantee. For example, there is the DiffServ model for QoS provisioning. The purpose of the DiffServ model is to avoid introducing a requirement for a lot of state information in the network relating to bandwidth guarantees. If it is the intention that a network support both bandwidth guarantees and differentiated services, then it is necessary that QoS is more than a book-keeping exercise. :-) You wrote: > I'm wondering about the definition for bandwidth reservation for LSPs. Sorry if this is obvious. > > My understanding is the following: Bandwidth for LSPs can be reserved using e.g. RSVP-TE. However, what does "reservation" mean? It means that at LSP establishment time, the LSR checks whether it has enough resources available. However, it only does a "book keeping" of its resources. It does not need to control their actual use. Admission control and policing must be performed by the LERs. If they don't do it, bandwidth is not guaranteed. > > I derived this understanding from conversations with others. Cisco seems to implement it this way. Checking on RFCs and IDs however, the picture is not entirely straight: > > draft-ietf-mpls-diff-ext-08.txt (MPLS Support of Differentiated Services) corroborates the above view: > > "Establishing an E-LSP or L-LSP with bandwidth reservation means that bandwidth requirements for the LSP are signaled at LSP establishment time. Such signaled bandwidth requirements may be used by LSRs at establishment time to perform admission control of the signaled LSP over the Diff-Serv resources provisioned (e.g. via configuration, SNMP or policy protocols) for the relevant PSC(s)" > > I.e. there is no mention of using the signaled bandwidth for on-line control of resource usage. > > I would expect to find something on the subject in the RSVP-TE draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. However, it only seems to talk about "reserving" bandwidth without defining what that is. It also says: > > "an implementation SHOULD support the Controlled-Load service" > > Checking, on "Controlled-Load service" one finds: > > "Network elements must not assume that data sources or upstream elements have taken action to "police" controlled-load flows by limiting their traffic to conform to the flow's TSpec. Each network element providing controlled-load service MUST independently ensure that the requirements given above are met in the presence of nonconformant arriving traffic for one or more controlled-load flows." > > I.e. each individual LSP is responsible for guaranteeing bandwidth after all. > > Additionally, RFC 2205 on RSVP states > > "During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". ... If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. " > > So RSVP seems to require the individual routers make sure all flows receive their due. Since RSVP-TE is just an extension of RSVP I would assume it works with the same router requirements. > > I am confused. Which one is it, must LSPs assure bandwidth reservations are met, or not? > > Thanks for your help, > > -- Cornelia Kappler From owner-mpls@UU.NET Tue Feb 27 12:09:51 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18332 for ; Tue, 27 Feb 2001 12:09: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 QQkefc29089; Tue, 27 Feb 2001 17:09:30 GMT Received: by mail-control.mail.uu.net id QQkefc08342 for mpls-outgoing; Tue, 27 Feb 2001 17:08: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 QQkefc08330 for ; Tue, 27 Feb 2001 17:08: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 QQkefc09977 for ; Tue, 27 Feb 2001 17:08:28 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkefc27567 for ; Tue, 27 Feb 2001 17:08: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 MAA19338 for ; Tue, 27 Feb 2001 12:08: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 MAA06529 for ; Tue, 27 Feb 2001 12:08:27 -0500 (EST) Message-ID: <3A9BDF1A.430658CB@marconi.com> Date: Tue, 27 Feb 2001 12:08:42 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: resource reservation for LSPs References: <4D486782CA36D4118A530000D11EA42A273C48@blns204e.bln.icn.siemens.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kappler Cornelia wrote: > > My understanding is the following: Bandwidth for LSPs can be reserved > using e.g. RSVP-TE. However, what does "reservation" mean? It means > that at LSP establishment time, the LSR checks whether it has enough > resources available. However, it only does a "book keeping" of its > resources. It does not need to control their actual use. Admission > control and policing must be performed by the LERs. If they don't do > it, bandwidth is not guaranteed. For the most part, this is correct. Transit routers may or may not also do policing. It shouldn't be necessary if the ingress router is properly policing traffic, but it may not be safe to assume that this will always be true. Also note that artifacts of packet queueing algorithms may cause compliant traffic to become non-compliant (at least for short bursts) at some point along the LSP. This may require a transit router to perform policing, in order to enforce any service guarantees. Routers may also perform traffic shaping to try and minimize this effect. > I would expect to find something on the subject in the RSVP-TE draft, > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. However, it only seems to talk > about "reserving" bandwidth without defining what that is. It also > says: RSVP-TE, like RSVP, uses IntServ for its reservations. Check out the IntServ RFCs: RFC 2210 RFC 2211 RFC 2212 RFC 2215 There are other possibly relevant RFCs that I haven't mentioned. Search for "Integrated Services" in the RFC index file to find them all. -- David From owner-mpls@UU.NET Tue Feb 27 12:22:26 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19103 for ; Tue, 27 Feb 2001 12:22: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 QQkefd29668; Tue, 27 Feb 2001 17:22:10 GMT Received: by mail-control.mail.uu.net id QQkefd10193 for mpls-outgoing; Tue, 27 Feb 2001 17:21:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefd10177 for ; Tue, 27 Feb 2001 17:21:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefd29639 for ; Tue, 27 Feb 2001 17:20:53 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefd15169 for ; Tue, 27 Feb 2001 17:20:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA13528 for mpls@uu.net; Tue, 27 Feb 2001 12:20:51 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefd09934 for ; Tue, 27 Feb 2001 17:20:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkefd28132 for ; Tue, 27 Feb 2001 17:20:15 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkefd04960 for ; Tue, 27 Feb 2001 17:20:14 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id JAA28556; Tue, 27 Feb 2001 09:19:56 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <0CD7D73C734BD411AEE100B0D0220404DFDDA2@mail1.tellium.com> References: <0CD7D73C734BD411AEE100B0D0220404DFDDA2@mail1.tellium.com> Date: Tue, 27 Feb 2001 09:18:31 -0800 To: Bala Rajagopalan From: Bora Akyol Subject: RE: New Internet Draft on ERO Cc: "'Bora Akyol'" , Yakov Rekhter , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk 1. You need to specify both ingress and egress identifiers for two reasons: a) On broadcast media (think GigE, 10 GigE) when a router has multiple interfaces attached to the same switch, you want the RSVP packet and MPLS LSPs to use the correct adjacency. And the only way to get that is to specify a pair. This scenario is commonly used in POP architectures where there are two GigE switches in the middle and each router has one link to each GigE switch and the GigE switches are interconnected. b) Specifying both ingress and egress is more explicit and leaves no guesswork. 2. I just asked a simple question with respect to fast reroute: How do you do it when you have unnumbered interfaces. At first thought, I thought it would be very hard to do, after thinking about it for a few minutes I think if you make certain assumptions and make extensive use of the IGP-TE database, you can possibly get by. But why? Why are we arguing over 4 more bytes in the signaling message. We don't have 56K leased line links any more. OC192c has become the standard and 768c is right around the corner. I don't see any point it haggling on four bytes. Hence we defined the EERO. I hope I cleared the "mystery" for you and Jonathan ;-) Bora At 9:24 AM -0500 2/27/01, Bala Rajagopalan wrote: >Hi, > >This is all rather mysterious. Following up >on Jonathan Lang's and Yakov's earlier questions, >could you please describe what the problem is >w.r.t fast reroute? > >Also, in your draft, what's the need to specify >both ingress and egress interface identifiers >for EERO hops? isn't one of them enough? > >Regards, > > > >Bala Rajagopalan >Tellium, Inc. >2 Crescent Place >P.O. Box 901 >Oceanport, NJ 07757-0901 >Tel: (732) 923-4237 >Fax: (732) 923-9804 >Email: braja@tellium.com > >> -----Original Message----- >> From: Bora Akyol [mailto:akyol@pluris.com] >> Sent: Monday, February 26, 2001 6:49 PM >> To: Yakov Rekhter >> Cc: Bora Akyol; mpls@UU.NET >> Subject: Re: New Internet Draft on ERO >> >> >> At 3:14 PM -0800 2/26/01, Yakov Rekhter wrote: >> >Bora, >> > >> >> My question is as follows: >> >> >> >> How do you do fast reroute when you have unnumbered >> interfaces in the >> >> ERO as in the unnumbered draft? What out of band >> information is added >> >> to what's in the ERO when we do CSPF? Is everyone doing >> it the same >> >> way? >> >> >> >> If we use the (newly defined) EERO then fast reroute is >> the same for >> >> both numbered and unnumbered interfaces and it actually >> becomes quite >> >> easy. >> > >> >Could you point me to the MPLS WG document(s) that specifies >> >how to perform fast re-route ? >> > >> >Yakov. >> >> Well, there was the ID from George Swallow that we discussed in San >> Diego. And then there were some discussions on the list that I >> participated in 1998. Vishal Sharma et al, produced IDs on that >> subject as well. >> >> >> Maybe it is time that we write a BCP on that topic. Would this fall >> into CCAMP or MPLS? In the last IETF, **all** of the fast >> reroute/recovery schemes were sent to CCAMP AFAIK. >> >> I know how we implemented fast reroute and I am sure you know of at >> least two implementations. >> >> So if there is interest on the WG, I can volunteer to put together a >> group of people to write such a BCP. >> >> But my original question still stands, >> >> how do you do fast reroute when you have unnumbered interfaces? It is >> possible to do, but becomes much easier if you have the router ID as >> part of the ERO subobject as we did in our EERO specification. Please > > see draft-akyol-mpls-exp-ero-00.txt > > > > > > Regards > > > > Bora > > From owner-mpls@UU.NET Tue Feb 27 12:36:37 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19778 for ; Tue, 27 Feb 2001 12:36: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 QQkefe05935; Tue, 27 Feb 2001 17:36:18 GMT Received: by mail-control.mail.uu.net id QQkefe12318 for mpls-outgoing; Tue, 27 Feb 2001 17:35:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefe12299 for ; Tue, 27 Feb 2001 17:35:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkefe16513 for ; Tue, 27 Feb 2001 17:35:16 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 QQkefe25423 for ; Tue, 27 Feb 2001 17:35:16 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 09:34:57 -0800 Message-ID: From: Vach Kompella To: "Kireeti Kompella (E-mail)" , "'yakov@uniper.net'" , "'mpls@uu.net'" Subject: Expanded ERO draft Date: Tue, 27 Feb 2001 09:34:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I apologize if this has been discussed ad nauseam. I looked through the archives before venturing out on the subject, and couldn't find an (explicit) answer to the question: why isn't the router ID in the ERO, and how come 6.3 of the rsvp-unnum draft says: "If, after processing and removing all initial subobjects in the ERO that refer to itself, the receiving node find a subobject of type Unnumbered Interface ID, it determines the next hop as follows..." I can understand the router ID not being there makes it more concise, at the expense of being a little less readable, and requiring a little more processing at the receiving end. In the interest of clarity and easier processing, I'd have eaten the 4 byte hit. But that's something the WG can vote (has voted?) on. The other aspect is the first clause of the quoted sentence above from the rsvp-unnum draft: "all initial subobjects that refer to itself." Suppose the ERO is made up of Unnum links (1, 1, 1, 1, 1), i.e., a series of hops, each of which used their Interface #1 outbound. Processing according to 6.2, a receiving node would strip out the first subobject, after validating that it received the ERO over its PHOP's interface #1. Then, by the statement above, it looks at the next one which coincidentally appears to refer to itself also. If I'm not missing something here, this first hop removes all the subobjects before it is done, which is not what is was intended. With a router ID in each subobject, the ERO would look like ((r1, 1), (r2, 1), (r3, 1), (r4, 1), (r5, 1)), which would remove the ambiguity. Can someone clarify? Thanks. -Vach From owner-mpls@UU.NET Tue Feb 27 12:57:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20613 for ; Tue, 27 Feb 2001 12:57: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 QQkeff25722; Tue, 27 Feb 2001 17:57:34 GMT Received: by mail-control.mail.uu.net id QQkeff15395 for mpls-outgoing; Tue, 27 Feb 2001 17:57: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 QQkeff15387 for ; Tue, 27 Feb 2001 17:57: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 QQkeff29193 for ; Tue, 27 Feb 2001 17:56:30 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 QQkeff24061 for ; Tue, 27 Feb 2001 17:56:30 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Tue, 27 Feb 2001 17:17:05 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <1TTHJNLX>; Tue, 27 Feb 2001 17:18:14 -0000 Message-ID: To: calin@employees.org, mpls@UU.NET Subject: RE: OAM for MPLS networks Date: Tue, 27 Feb 2001 17:18:07 -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 Calin Poenaru [mailto:calin@employees.org] observed 27 February 2001 12:21: > I have a question about the efficiency of the mechanism for > connectivity > verification described in draft-harrison-mpls-oam-00: there > is proposed > a scheme which is very similar with I.610 NH=> The scheme in I.610 is flawed. It can only detect simple breaks and not generalised misconnectivity defects. To do this requires an adjunct PM flow. Note that PM flow alone has a problem since the PM issue rate is a function of customer activity, ie quiescent customer = zero PM flow = same symptom as a break. But CC+PM flow on all trails is far too heavy a processing burden to scale. So its not really the same at all. (Just taken the best bits and discarded the bits that don't work or don't add-value) > and (in my opinion) > has the same > drawback - a time for detect and react too high. NH=> CV detects all *MPLS layer* defects in same time of 3s. Defect exit time is also 3s. Note that *below MPLS layer* defects (eg in SDH) would be detected faster (consistent with the particular defect and its detection mechanism within the SDH layer affected, eg loss of optics is detected as LOS very quickly), and the FDI would be issued to the lowest layer LSP in this (fast) time. > In other > words: the 10 > seconds necessary for detect NH=> Defects are detected in 3s as noted above for MPLS layer defects, it is not 10s. > the unavailable state is far too long to > affect all the connections in the failed LSP. And more, the 20 seconds > (minimum) required for re-entering in the available state is > too much to > be useful for the traffic (in this time the Control Plane > probably already > take some actions like reroute or something else). Could you comment a > little bit about this issues? NH=> The definition of availability is independent of the defect detection times as noted above. We have used the classical 10s definition of WAN availability for the following reasons: - there is no other as yet defined......so we had to choose something - below MPLS layer network technologies will be working to the 10s value for availability.....so chossing something else would lead to potential conflict of metric base. BTW - it is not 20s to re-enter available state. The process would work like this: - assume in unavailable state with defect X - defect X is cleared (takes 3s) - traffic is re-enabled, ie after 3s - available state declared after 10s of defect-free state - last 10s get associated with up-state for QoS aggregation purposes. Have another read, and if still not clear come back to me Calin. > > And another question: at 6.6.3 you stated that the exit from Far-End > Defect State is conditioned by 3 consecutive seconds without BDI OAM > packets. But what if an FDI OAM packet will come? It will not > force the > exit from this state and go into Near-End Defect State? NH=> FDI pkts do *not* force defect state changes. They are simply indications that defects exist in lower layers and their key purpose is to supress alarm storms. Defects are *only* handled via the CV flow and incoming FDIs get ignored....if this was not the case then there would be a +3s extra 'hold-off' in the defect state at each LSP as one ascended a stacked LSP hierarchy. So, and your particular example,if one sees no BDI pkts (and recall this is on a return LSP) *and* one sees 'good' CV pkts then, irrespective of any rogue FDI pkts arriving (from wherever), its the CV pkts that keep the return LSP in the up-state. Hope its clear. From owner-mpls@UU.NET Tue Feb 27 13:37:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22648 for ; Tue, 27 Feb 2001 13:37: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 QQkefi28912; Tue, 27 Feb 2001 18:37:15 GMT Received: by mail-control.mail.uu.net id QQkefi06160 for mpls-outgoing; Tue, 27 Feb 2001 18:36:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefi06121 for ; Tue, 27 Feb 2001 18:36:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefi09473 for ; Tue, 27 Feb 2001 18:36:17 GMT Received: from alemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQkefi09819 for ; Tue, 27 Feb 2001 18:36:17 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA17556 for ; Tue, 27 Feb 2001 13:36:16 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA17550; Tue, 27 Feb 2001 13:36:16 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA03274; Tue, 27 Feb 2001 13:35:45 -0500 (EST) Message-ID: <3A9BF380.494237C9@lucent.com> Date: Tue, 27 Feb 2001 13:35:44 -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: Vach Kompella CC: "Kireeti Kompella (E-mail)" , "'yakov@uniper.net'" , "'mpls@uu.net'" Subject: Re: Expanded ERO draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ERO should contain the router ID for several reason: 1) Simplify receiving node operation and avoid the ambiguity as Vach and Bora mentioned 2) Keep ERO operation consistent. (A node typically strip off all information of itself before sending to next hop, so the outbound interface ID in ERO should be stripped off) 3) Consistent format of unnumbered FA and unnumbered link. These two types of links don't need to be differentiated especially if the unnumbered FA is through an circuit switched transport network. 4) For CR-LDP, we don't need to invent another PHOP TLV Yangguang Vach Kompella wrote: > > I apologize if this has been discussed ad nauseam. I looked through the > archives before venturing out on the subject, and couldn't find an > (explicit) answer to the question: why isn't the router ID in the ERO, and > how come 6.3 of the rsvp-unnum draft says: > "If, after processing and removing all initial subobjects in the ERO > that refer to itself, the receiving node find a subobject of type Unnumbered > Interface ID, it determines the next hop as follows..." > > I can understand the router ID not being there makes it more concise, at the > expense of being a little less readable, and requiring a little more > processing at the receiving end. In the interest of clarity and easier > processing, I'd have eaten the 4 byte hit. But that's something the WG can > vote (has voted?) on. > > The other aspect is the first clause of the quoted sentence above from the > rsvp-unnum draft: "all initial subobjects that refer to itself." Suppose > the ERO is made up of Unnum links (1, 1, 1, 1, 1), i.e., a series of hops, > each of which used their Interface #1 outbound. Processing according to > 6.2, a receiving node would strip out the first subobject, after validating > that it received the ERO over its PHOP's interface #1. Then, by the > statement above, it looks at the next one which coincidentally appears to > refer to itself also. If I'm not missing something here, this first hop > removes all the subobjects before it is done, which is not what is was > intended. With a router ID in each subobject, the ERO would look like ((r1, > 1), (r2, 1), (r3, 1), (r4, 1), (r5, 1)), which would remove the ambiguity. > > Can someone clarify? Thanks. > > -Vach From owner-mpls@UU.NET Tue Feb 27 14:23:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25097 for ; Tue, 27 Feb 2001 14:23: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 QQkefl21502; Tue, 27 Feb 2001 19:22:51 GMT Received: by mail-control.mail.uu.net id QQkefl26817 for mpls-outgoing; Tue, 27 Feb 2001 19:22:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefl26803 for ; Tue, 27 Feb 2001 19:22:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefl11488 for ; Tue, 27 Feb 2001 19:21:18 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 QQkefl09855 for ; Tue, 27 Feb 2001 19:21:17 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA21291; Tue, 27 Feb 2001 11:21:17 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA60573; Tue, 27 Feb 2001 11:21:17 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102271921.LAA60573@garnet.juniper.net> To: Bora Akyol cc: mpls@UU.NET Subject: Re: New Internet Draft on ERO In-Reply-To: Your message of "Mon, 26 Feb 2001 15:49:29 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60570.983301677.1@garnet.juniper.net> Date: Tue, 27 Feb 2001 11:21:17 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bora, > >> My question is as follows: > >> > >> How do you do fast reroute when you have unnumbered interfaces in the > >> ERO as in the unnumbered draft? What out of band information is added > >> to what's in the ERO when we do CSPF? Is everyone doing it the same > >> way? > >> > >> If we use the (newly defined) EERO then fast reroute is the same for > >> both numbered and unnumbered interfaces and it actually becomes quite > >> easy. > > > >Could you point me to the MPLS WG document(s) that specifies > >how to perform fast re-route ? > > > >Yakov. > > Well, there was the ID from George Swallow that we discussed in San > Diego. And then there were some discussions on the list that I > participated in 1998. Vishal Sharma et al, produced IDs on that > subject as well. > > Maybe it is time that we write a BCP on that topic. Would this fall > into CCAMP or MPLS? In the last IETF, **all** of the fast > reroute/recovery schemes were sent to CCAMP AFAIK. > > I know how we implemented fast reroute and I am sure you know of at > least two implementations. > > So if there is interest on the WG, I can volunteer to put together a > group of people to write such a BCP. > > But my original question still stands, Your original question is ambiguous, as it didn't spell out which *specific* fast reroute scheme is used (and as you indicated above there is more than one such scheme). Also, are you asserting that none of the fast reroute schemes could work with unnumbered interfaces in the ERO as specified in the unnumbered draft ? Yakov. From owner-mpls@UU.NET Tue Feb 27 14:23:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25106 for ; Tue, 27 Feb 2001 14: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 QQkefl11985; Tue, 27 Feb 2001 19:22:52 GMT Received: by mail-control.mail.uu.net id QQkefl26814 for mpls-outgoing; Tue, 27 Feb 2001 19:22:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefl26805 for ; Tue, 27 Feb 2001 19:22:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkefl11220 for ; Tue, 27 Feb 2001 19:21:10 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefl19261 for ; Tue, 27 Feb 2001 19:21:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA26052 for mpls@uu.net; Tue, 27 Feb 2001 14:21:06 -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 QQkefl26543 for ; Tue, 27 Feb 2001 19:20: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 QQkefl15305 for ; Tue, 27 Feb 2001 19:19:41 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 QQkefl07597 for ; Tue, 27 Feb 2001 19:19:41 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 LAA15060; Tue, 27 Feb 2001 11:18:52 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BLRST>; Tue, 27 Feb 2001 11:18:52 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AAD@BBY1EXM01> From: Shahram Davari To: "'Puneet Agarwal'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Tue, 27 Feb 2001 11:18:51 -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 Puneet, Thanks for your reply. Please see my comments in-line: > >2) Section 2.4 does not discuss an important case that is: > >egress processing of tunnels, i.e. pop and forwarding the > >packet as MPLS. > > Pop (or Egress Pop to distinguish from PHP) is actually > covered in section > 2.3. The possibly operation when forwarding the packet as > MPLS are covered > in the 3 bullets of section 2.4. Combine section 2.3 and the relevant > section of 2.4 and I think your concern about the missing > case should be > answered. Hence as far as I can see the case is convered, but > please let me > know if you still think that it is not addressed. > > As you know there are at least 2 distinct operations that are needed for TTL processing: 1) Determining iTTL 2) Determining oTTL Section 2.3 describes the iTTL determination for both PHP and non-PHP case. Section 2.4 however describes the oTTL determination for PHP case only. I can't see anywhere in the draft that talks about oTTL determination for non-PHP case. Do you see any? Yours, Shahram From owner-mpls@UU.NET Tue Feb 27 14:38:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25848 for ; Tue, 27 Feb 2001 14:38: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 QQkefm03730; Tue, 27 Feb 2001 19:38:12 GMT Received: by mail-control.mail.uu.net id QQkefm28756 for mpls-outgoing; Tue, 27 Feb 2001 19:37:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefm28718 for ; Tue, 27 Feb 2001 19:37:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefm18252 for ; Tue, 27 Feb 2001 19:37:02 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 QQkefm01972 for ; Tue, 27 Feb 2001 19:37:01 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA22540; Tue, 27 Feb 2001 11:37:01 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA63462; Tue, 27 Feb 2001 11:36:56 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102271936.LAA63462@garnet.juniper.net> To: Bora Akyol cc: mpls@UU.NET Subject: Re: New Internet Draft on ERO In-Reply-To: Your message of "Tue, 27 Feb 2001 09:18:31 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63459.983302616.1@garnet.juniper.net> Date: Tue, 27 Feb 2001 11:36:56 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bora, > 1. You need to specify both ingress and egress identifiers for two reasons: > a) On broadcast media (think GigE, 10 GigE) when a router has > multiple interfaces attached to the same switch, you want the RSVP > packet and MPLS LSPs to use the correct adjacency. And the only way > to get that is to specify a pair. This scenario is commonly used in > POP architectures where there are two GigE switches in the middle and > each router has one link to each GigE switch and the GigE switches > are interconnected. Could you tell us how the head-end LSR would be able to figure out the "correct adjacency" in the scenario you described above. > b) Specifying both ingress and egress is more explicit and > leaves no guesswork. > > 2. I just asked a simple question with respect to fast reroute: How > do you do it when you have unnumbered interfaces. At first thought, I > thought it would be very hard to do, after thinking about it for a > few minutes I think if you make certain assumptions and make > extensive use of the IGP-TE database, you can possibly get by. But > why? Why are we arguing over 4 more bytes in the signaling message. > We don't have 56K leased line links any more. OC192c has become the > standard and 768c is right around the corner. I don't see any point > it haggling on four bytes. Hence we defined the EERO. We aren't arguing over 4 more bytes - the issue is whether it is truly necessary. And so far you've yet to construct a case that shows that it is necessary. Yakov. From owner-mpls@UU.NET Tue Feb 27 14:48:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26280 for ; Tue, 27 Feb 2001 14:48: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 QQkefn26056; Tue, 27 Feb 2001 19:47:40 GMT Received: by mail-control.mail.uu.net id QQkefn00544 for mpls-outgoing; Tue, 27 Feb 2001 19:46:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefn00518 for ; Tue, 27 Feb 2001 19:46:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkefn10857 for ; Tue, 27 Feb 2001 19:46:31 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 QQkefn24323 for ; Tue, 27 Feb 2001 19:46:30 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA23359; Tue, 27 Feb 2001 11:46:29 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA65711; Tue, 27 Feb 2001 11:46:29 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102271946.LAA65711@garnet.juniper.net> To: Vach Kompella cc: "'mpls@uu.net'" Subject: Re: Expanded ERO draft In-Reply-To: Your message of "Tue, 27 Feb 2001 09:34:49 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <65706.983303189.1@garnet.juniper.net> Date: Tue, 27 Feb 2001 11:46:29 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Vach, > I apologize if this has been discussed ad nauseam. I looked through the > archives before venturing out on the subject, and couldn't find an > (explicit) answer to the question: why isn't the router ID in the ERO, and > how come 6.3 of the rsvp-unnum draft says: > "If, after processing and removing all initial subobjects in the ERO > that refer to itself, the receiving node find a subobject of type Unnumbered > Interface ID, it determines the next hop as follows..." > > I can understand the router ID not being there makes it more concise, at the > expense of being a little less readable, and requiring a little more > processing at the receiving end. In the interest of clarity and easier > processing, I'd have eaten the 4 byte hit. But that's something the WG can > vote (has voted?) on. > > The other aspect is the first clause of the quoted sentence above from the > rsvp-unnum draft: "all initial subobjects that refer to itself." Suppose > the ERO is made up of Unnum links (1, 1, 1, 1, 1), i.e., a series of hops, > each of which used their Interface #1 outbound. Processing according to > 6.2, a receiving node would strip out the first subobject, after validating > that it received the ERO over its PHOP's interface #1. Then, by the > statement above, it looks at the next one which coincidentally appears to > refer to itself also. If I'm not missing something here, this first hop > removes all the subobjects before it is done, which is not what is was > intended. With a router ID in each subobject, the ERO would look like ((r1, > 1), (r2, 1), (r3, 1), (r4, 1), (r5, 1)), which would remove the ambiguity. > > Can someone clarify? Thanks. The text needs to be clarified to say something like "all initial subobjects of type other than Unnumbered Interface ID"...". Yakov. From owner-mpls@UU.NET Tue Feb 27 14:53:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26567 for ; Tue, 27 Feb 2001 14:53: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 QQkefn04456; Tue, 27 Feb 2001 19:53:16 GMT Received: by mail-control.mail.uu.net id QQkefn01589 for mpls-outgoing; Tue, 27 Feb 2001 19:52: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 QQkefn01567 for ; Tue, 27 Feb 2001 19:52:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefn04050 for ; Tue, 27 Feb 2001 19:51:39 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 QQkefn09839 for ; Tue, 27 Feb 2001 19:51:39 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA23729; Tue, 27 Feb 2001 11:51:38 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA66640; Tue, 27 Feb 2001 11:51:38 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102271951.LAA66640@garnet.juniper.net> To: Yangguang Xu cc: "'mpls@uu.net'" Subject: Re: Expanded ERO draft In-Reply-To: Your message of "Tue, 27 Feb 2001 13:35:44 EST." <3A9BF380.494237C9@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66636.983303498.1@garnet.juniper.net> Date: Tue, 27 Feb 2001 11:51:38 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Yangguang, > ERO should contain the router ID for several reason: > > 1) Simplify receiving node operation and avoid the ambiguity as Vach and Bora > mentioned The ambiguity pointed by Vach is the spec ambiguity, and will be addressed in the next revision of the Internet Draft. > > 2) Keep ERO operation consistent. (A node typically strip off all information > of itself before sending to next hop, so the outbound interface ID in ERO > should be stripped off) > > 3) Consistent format of unnumbered FA and unnumbered link. These two types of > links don't need to be differentiated especially if the unnumbered FA is > through an circuit switched transport network. What makes you think that the format is different ? Yakov. From owner-mpls@UU.NET Tue Feb 27 14:53:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26580 for ; Tue, 27 Feb 2001 14:53: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 QQkefn12121; Tue, 27 Feb 2001 19:53:18 GMT Received: by mail-control.mail.uu.net id QQkefn01606 for mpls-outgoing; Tue, 27 Feb 2001 19:52:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefn01583 for ; Tue, 27 Feb 2001 19:52:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefn06720 for ; Tue, 27 Feb 2001 19:51:51 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQkefn23202 for ; Tue, 27 Feb 2001 19:51:51 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f1RJoAv11162; Tue, 27 Feb 2001 14:50:10 -0500 (EST) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 14:45:19 -0500 Message-ID: <0CD7D73C734BD411AEE100B0D0220404DFDDAC@mail1.tellium.com> From: Bala Rajagopalan To: "'Bora Akyol'" Cc: mpls@UU.NET Subject: RE: New Internet Draft on ERO Date: Tue, 27 Feb 2001 14:45:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, > > > 1. You need to specify both ingress and egress identifiers > for two reasons: > a) On broadcast media (think GigE, 10 GigE) when a router has > multiple interfaces attached to the same switch, you want the RSVP > packet and MPLS LSPs to use the correct adjacency. And the only way > to get that is to specify a pair. This scenario is commonly used in > POP architectures where there are two GigE switches in the middle and > each router has one link to each GigE switch and the GigE switches > are interconnected. What is the meaning of "correct adjacency" here? Specifically, is there any reason for distinguishing between such adjacencies ariori at the source? (Or, is there any reason why this sort of decision cannot be left as a local matter to previous hop node?) > > 2. I just asked a simple question with respect to fast reroute: How > do you do it when you have unnumbered interfaces. At first thought, I > thought it would be very hard to do, after thinking about it for a > few minutes I think if you make certain assumptions and make > extensive use of the IGP-TE database, you can possibly get by. But > why? Why are we arguing over 4 more bytes in the signaling message. > We don't have 56K leased line links any more. OC192c has become the > standard and 768c is right around the corner. I don't see any point > it haggling on four bytes. Hence we defined the EERO. Actually, I'm just trying to understand the motivation and problem w.r.t reroute. It would really help if you can describe the problem in some detail. Regards, Bala From owner-mpls@UU.NET Tue Feb 27 15:11:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27350 for ; Tue, 27 Feb 2001 15:11: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 QQkefo07195; Tue, 27 Feb 2001 20:11:30 GMT Received: by mail-control.mail.uu.net id QQkefo16448 for mpls-outgoing; Tue, 27 Feb 2001 20:10: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 QQkefo16079 for ; Tue, 27 Feb 2001 20:10: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 QQkefo28689 for ; Tue, 27 Feb 2001 20:09:09 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkefo03841 for ; Tue, 27 Feb 2001 20:09:09 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA17396; Tue, 27 Feb 2001 12:08:52 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 12:08:52 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA094502@avalon.pluris.com> From: Puneet Agarwal To: "'Shahram Davari'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Tue, 27 Feb 2001 12:08:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, Based on the tunnel mode definitions in the -07 version of mpls-diff draft, the oTTL determination is not needed explicitly for the "Pop" case. After you perform "Pop" (recursively), you need to route (determine the egress interface etc) the exposed header (IP packet or label). You never "Pop" the label you route on - you can only SWAP, SWAP+Push or PHP (+Push) the label. Hence I never added the bullet for "Pop" when determining oTTL as it is not a legal operation. If you want, I can add text in section 2.4 of the draft that a "Pop" is not a legal operation for a label we route on. Would that help? Hope this clarifies. -Puneet >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Tuesday, February 27, 2001 11:19 AM >To: 'Puneet Agarwal'; 'Eric Gray' >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >'bsd@cisco.com'; Bora Akyol >Subject: RE: New TTL Draft > > >Hi Puneet, > >Thanks for your reply. Please see my comments in-line: > >> >2) Section 2.4 does not discuss an important case that is: >> >egress processing of tunnels, i.e. pop and forwarding the >> >packet as MPLS. >> >> Pop (or Egress Pop to distinguish from PHP) is actually >> covered in section >> 2.3. The possibly operation when forwarding the packet as >> MPLS are covered >> in the 3 bullets of section 2.4. Combine section 2.3 and >the relevant >> section of 2.4 and I think your concern about the missing >> case should be >> answered. Hence as far as I can see the case is convered, but >> please let me >> know if you still think that it is not addressed. >> > > >As you know there are at least 2 distinct operations that are needed >for TTL processing: > >1) Determining iTTL >2) Determining oTTL > >Section 2.3 describes the iTTL determination for both PHP and >non-PHP case. >Section 2.4 however describes the oTTL determination for PHP >case only. I >can't see anywhere in the draft that talks about oTTL >determination for non-PHP >case. Do you see any? > > >Yours, >Shahram > From owner-mpls@UU.NET Tue Feb 27 15:18:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27535 for ; Tue, 27 Feb 2001 15:18: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 QQkefp17370; Tue, 27 Feb 2001 20:18:34 GMT Received: by mail-control.mail.uu.net id QQkefp20519 for mpls-outgoing; Tue, 27 Feb 2001 20:18: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 QQkefp20466 for ; Tue, 27 Feb 2001 20:18: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 QQkefp25565 for ; Tue, 27 Feb 2001 20:17:47 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefp16156 for ; Tue, 27 Feb 2001 20:17:47 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA04189 for mpls@uu.net; Tue, 27 Feb 2001 15:17: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 QQkefp20263 for ; Tue, 27 Feb 2001 20:17:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefp21621 for ; Tue, 27 Feb 2001 20:16:32 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkefp14477 for ; Tue, 27 Feb 2001 20:16:32 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA18074; Tue, 27 Feb 2001 12:16:29 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <0CD7D73C734BD411AEE100B0D0220404DFDDAC@mail1.tellium.com> References: <0CD7D73C734BD411AEE100B0D0220404DFDDAC@mail1.tellium.com> Date: Tue, 27 Feb 2001 12:15:04 -0800 To: Bala Rajagopalan From: Bora Akyol Subject: RE: New Internet Draft on ERO Cc: "'Bora Akyol'" , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 2:45 PM -0500 2/27/01, Bala Rajagopalan wrote: >Hello, > >> >> >> 1. You need to specify both ingress and egress identifiers >> for two reasons: >> a) On broadcast media (think GigE, 10 GigE) when a router has >> multiple interfaces attached to the same switch, you want the RSVP >> packet and MPLS LSPs to use the correct adjacency. And the only way >> to get that is to specify a pair. This scenario is commonly used in >> POP architectures where there are two GigE switches in the middle and >> each router has one link to each GigE switch and the GigE switches >> are interconnected. > >What is the meaning of "correct adjacency" here? Specifically, >is there any reason for distinguishing between such adjacencies >ariori at the source? (Or, is there any reason why this >sort of decision cannot be left as a local >matter to previous hop node?) You have two routers that are connected to an ethernet switch via multiple interfaces on each side. The head end LSR has calculated an explicitly routed path that is strict. For one to be able to specify a strict path in a LAN environment you need to be able to specify both ingress and egress interfaces. This is a matter of correctness, IMHO. Now does this matter? Based on the POP architectures that I have seen, this is a case that occurs for redundancy reasons fairly often, so the correctness does matter. Even though the broadcast media is shared, the packet treatment mechanisms are not shared and you need to be able to deliver deterministic service. > > >> 2. I just asked a simple question with respect to fast reroute: How >> do you do it when you have unnumbered interfaces. At first thought, I >> thought it would be very hard to do, after thinking about it for a >> few minutes I think if you make certain assumptions and make >> extensive use of the IGP-TE database, you can possibly get by. But >> why? Why are we arguing over 4 more bytes in the signaling message. >> We don't have 56K leased line links any more. OC192c has become the >> standard and 768c is right around the corner. I don't see any point >> it haggling on four bytes. Hence we defined the EERO. > >Actually, I'm just trying to understand the motivation and problem w.r.t >reroute. It would really help if you can describe the >problem in some detail. Think of an unnumbered ERO of the form <1,1,1,1,1,1,1,1> Now somewhere in the middle, an LSR wants to calculate a fast reroute LSP. Normally, one would ask the TE database the simple question of avoid my next hop and would give the router ID of the next hop, but in this case, first you have to find out who the router at the end of the egress interface is. This is not hard, then you need to find out who the router that is right after the immediate hop. This second one is harder since you have to make a query into the TE database, to find that. Then you have to make a third query into TED, to calculate an LSP that avoids the immediate next hop but merges as soon as possible with the main LSP. And finally, you calculate an ERO that now is a mixture of both numbered and unnumbered interfaces possibly and initiate signaling. As I describe here, this is not undoable, but at what cost. If one adds the extra four bytes of router ID as part of the ERO (as we did in the EERO) this whole thing becomes trivial to implement. I am advocate for putting enough bits on the wire to make implementation simpler. Bora From owner-mpls@UU.NET Tue Feb 27 15:34:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28392 for ; Tue, 27 Feb 2001 15:34: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 QQkefq02429; Tue, 27 Feb 2001 20:34:27 GMT Received: by mail-control.mail.uu.net id QQkefq22858 for mpls-outgoing; Tue, 27 Feb 2001 20:33:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkefq22829 for ; Tue, 27 Feb 2001 20:33: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 QQkefq13744 for ; Tue, 27 Feb 2001 20:33:38 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkefq07896 for ; Tue, 27 Feb 2001 20:33:38 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C2F9A94009; Tue, 27 Feb 2001 15:33:28 -0500 (EST) Message-ID: <3A9C0F18.A47D46AA@sandburst.com> Date: Tue, 27 Feb 2001 15:33:28 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Puneet Agarwal Cc: "'Shahram Davari'" , "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: Re: New TTL Draft References: <17C81AD1F1FED411991E006008F6D1CA094502@avalon.pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Puneet, I am somewhat confused by this reply - especially in the context provided by the enclosed discussion. It is certainly possible to perform an egress pop of a label. I believed that to be what you were saying earlier. Yet this is exactly the same thing as what you are saying you would never do below. For example, if I am providing a port-based VPN service using MPLS, it is very likely that I will use MPLS labels to get packets to the egress port. Now suppose (as is likely to be true at least sometimes) that the next router beyond the service provider router is not an LSR (even of the stripped down version that can only give implicit NULL labels). Then the packets that the egress LSR forwards to this next hop must be IP packets - so the label used to get the packets to the egress port of the egress LSR must be popped after they are used to route the packets to the egress port. From the forwarding engine's point of view, this is exactly the same behavior as you would get using PHP. The question seems to be, would the behavior with respect to TTL defined for PHP also apply in this case? -- Eric Gray You wrote: > Hi Shahram, > > Based on the tunnel mode definitions in the -07 version of mpls-diff draft, > the oTTL determination is not needed explicitly for the "Pop" case. After > you perform "Pop" (recursively), you need to route (determine the egress > interface etc) the exposed header (IP packet or label). You never "Pop" the > label you route on - you can only SWAP, SWAP+Push or PHP (+Push) the label. > > Hence I never added the bullet for "Pop" when determining oTTL as it is not > a legal operation. If you want, I can add text in section 2.4 of the draft > that a "Pop" is not a legal operation for a label we route on. Would that > help? > > Hope this clarifies. > > -Puneet > > >-----Original Message----- > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >Sent: Tuesday, February 27, 2001 11:19 AM > >To: 'Puneet Agarwal'; 'Eric Gray' > >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > >'bsd@cisco.com'; Bora Akyol > >Subject: RE: New TTL Draft > > > > > >Hi Puneet, > > > >Thanks for your reply. Please see my comments in-line: > > > >> >2) Section 2.4 does not discuss an important case that is: > >> >egress processing of tunnels, i.e. pop and forwarding the > >> >packet as MPLS. > >> > >> Pop (or Egress Pop to distinguish from PHP) is actually > >> covered in section > >> 2.3. The possibly operation when forwarding the packet as > >> MPLS are covered > >> in the 3 bullets of section 2.4. Combine section 2.3 and > >the relevant > >> section of 2.4 and I think your concern about the missing > >> case should be > >> answered. Hence as far as I can see the case is convered, but > >> please let me > >> know if you still think that it is not addressed. > >> > > > > >As you know there are at least 2 distinct operations that are needed > >for TTL processing: > > > >1) Determining iTTL > >2) Determining oTTL > > > >Section 2.3 describes the iTTL determination for both PHP and > >non-PHP case. > >Section 2.4 however describes the oTTL determination for PHP > >case only. I > >can't see anywhere in the draft that talks about oTTL > >determination for non-PHP > >case. Do you see any? > > > > > >Yours, > >Shahram > > From owner-mpls@UU.NET Tue Feb 27 15:42:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28787 for ; Tue, 27 Feb 2001 15:42: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 QQkefq19160; Tue, 27 Feb 2001 20:41:42 GMT Received: by mail-control.mail.uu.net id QQkefq23751 for mpls-outgoing; Tue, 27 Feb 2001 20:41:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefq23707 for ; Tue, 27 Feb 2001 20:41:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefq18522 for ; Tue, 27 Feb 2001 20:41:01 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 QQkefq18154 for ; Tue, 27 Feb 2001 20:41:01 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 MAA27693; Tue, 27 Feb 2001 12:40:59 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id MAA26461; Tue, 27 Feb 2001 12:40:59 -0800 (PST) Date: Tue, 27 Feb 2001 12:40:59 -0800 (PST) From: Kireeti Kompella Message-Id: <200102272040.MAA26461@kummer.juniper.net> To: vkompella@JasmineNetworks.com, yakov@juniper.net Subject: Re: Expanded ERO draft Cc: mpls@UU.NET In-Reply-To: <200102271946.LAA65711@garnet.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Vach, Yakov, > > The other aspect is the first clause of the quoted sentence above from the > > rsvp-unnum draft: "all initial subobjects that refer to itself." > > The text needs to be clarified to say something like "all initial subobjects > of type other than Unnumbered Interface ID"...". While the change in text is possible, it is clear that, unless the interface is physically looped back to itself, the second subobject does *not* refer to "itself". 1 1 1 A ----- B ----- C ----- D B receives an ERO of (1, 1, 1) from A (PHOP). B checks that (A, 1) refers to itself, removes it. Now it sees unnum interface 1, which clearly points at C. Why would B think that this "1" refers to B? Kireeti. From owner-mpls@UU.NET Tue Feb 27 15:48:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29040 for ; Tue, 27 Feb 2001 15:48: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 QQkefr22408; Tue, 27 Feb 2001 20:48:28 GMT Received: by mail-control.mail.uu.net id QQkefr24603 for mpls-outgoing; Tue, 27 Feb 2001 20:48: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 QQkefr24591 for ; Tue, 27 Feb 2001 20:48: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 QQkefr27300 for ; Tue, 27 Feb 2001 20:47:34 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkefr27404 for ; Tue, 27 Feb 2001 20:47:33 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 402CC94009; Tue, 27 Feb 2001 15:47:33 -0500 (EST) Message-ID: <3A9C1265.7930735D@sandburst.com> Date: Tue, 27 Feb 2001 15:47:33 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella Cc: vkompella@JasmineNetworks.com, yakov@juniper.net, mpls@UU.NET Subject: Re: Expanded ERO draft References: <200102272040.MAA26461@kummer.juniper.net> Content-Type: multipart/alternative; boundary="------------489815A5F335A8086D711BEF" Sender: owner-mpls@UU.NET Precedence: bulk --------------489815A5F335A8086D711BEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, Out of curiosity, how many un-numbered interfaces can B have that are known to it as interface 1? -- Eric Gray You wrote: > Vach, Yakov, > > > > The other aspect is the first clause of the quoted sentence above from the > > > rsvp-unnum draft: "all initial subobjects that refer to itself." > > > > The text needs to be clarified to say something like "all initial subobjects > > of type other than Unnumbered Interface ID"...". > > While the change in text is possible, it is clear that, unless the > interface is physically looped back to itself, the second subobject > does *not* refer to "itself". > > 1 1 1 > A ----- B ----- C ----- D > > B receives an ERO of (1, 1, 1) from A (PHOP). B checks that (A, 1) > refers to itself, removes it. Now it sees unnum interface 1, which > clearly points at C. Why would B think that this "1" refers to B? > > Kireeti. --------------489815A5F335A8086D711BEF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti,

    Out of curiosity, how many un-numbered interfaces can
B have that are known to it as interface 1?

--
Eric Gray

You wrote:

Vach, Yakov,

> > The other aspect is the first clause of the quoted sentence above from the
> > rsvp-unnum draft: "all initial subobjects that refer to itself."
>
> The text needs to be clarified to say something like "all initial subobjects
> of type other than Unnumbered Interface ID"...".

While the change in text is possible, it is clear that, unless the
interface is physically looped back to itself, the second subobject
does *not* refer to "itself".

             1       1       1
         A ----- B ----- C ----- D

B receives an ERO of (1, 1, 1) from A (PHOP).  B checks that (A, 1)
refers to itself, removes it.  Now it sees unnum interface 1, which
clearly points at C.  Why would B think that this "1" refers to B?

Kireeti.

--------------489815A5F335A8086D711BEF-- From owner-mpls@UU.NET Tue Feb 27 15:50:36 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29148 for ; Tue, 27 Feb 2001 15:50: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 QQkefr01414; Tue, 27 Feb 2001 20:50:20 GMT Received: by mail-control.mail.uu.net id QQkefr24778 for mpls-outgoing; Tue, 27 Feb 2001 20:50: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 QQkefr24749 for ; Tue, 27 Feb 2001 20:49:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefr02754 for ; Tue, 27 Feb 2001 20:49:17 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefr12097 for ; Tue, 27 Feb 2001 20:49:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA02063 for mpls@uu.net; Tue, 27 Feb 2001 14:59: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 QQkefn02676 for ; Tue, 27 Feb 2001 19:57: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 QQkefn22941 for ; Tue, 27 Feb 2001 19:57:43 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkefn18423 for ; Tue, 27 Feb 2001 19:57:43 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA16045; Tue, 27 Feb 2001 11:57:42 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <200102271936.LAA63462@garnet.juniper.net> References: <200102271936.LAA63462@garnet.juniper.net> Date: Tue, 27 Feb 2001 11:56:17 -0800 To: Yakov Rekhter From: Bora Akyol Subject: Re: New Internet Draft on ERO Cc: Bora Akyol , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 11:36 AM -0800 2/27/01, Yakov Rekhter wrote: >Bora, > >> 1. You need to specify both ingress and egress identifiers for two reasons: >> a) On broadcast media (think GigE, 10 GigE) when a router has >> multiple interfaces attached to the same switch, you want the RSVP >> packet and MPLS LSPs to use the correct adjacency. And the only way >> to get that is to specify a pair. This scenario is commonly used in >> POP architectures where there are two GigE switches in the middle and >> each router has one link to each GigE switch and the GigE switches >> are interconnected. > >Could you tell us how the head-end LSR would be able to figure out >the "correct adjacency" in the scenario you described above. Yes By consulting the IGP TE database (TED). > > b) Specifying both ingress and egress is more explicit and >> leaves no guesswork. >> >> 2. I just asked a simple question with respect to fast reroute: How >> do you do it when you have unnumbered interfaces. At first thought, I >> thought it would be very hard to do, after thinking about it for a >> few minutes I think if you make certain assumptions and make >> extensive use of the IGP-TE database, you can possibly get by. But >> why? Why are we arguing over 4 more bytes in the signaling message. >> We don't have 56K leased line links any more. OC192c has become the >> standard and 768c is right around the corner. I don't see any point >> it haggling on four bytes. Hence we defined the EERO. > >We aren't arguing over 4 more bytes - the issue is whether >it is truly necessary. And so far you've yet to construct a >case that shows that it is necessary. 1.It clearly associates an unnumbered interface with a router thereby guaranteeing uniqueness. 2. You don't need to infer anything from the order of the objects in the ERO, the association of an unnumbered interface to a router is clear. 3. It makes ERO processing code much simpler as it removes all of the Abstract Node case (and its associated lookups) from the common path. 4. I believe it improves the chance of both fast reroute and MPLS interoperating. We wrote this draft because we had to make certain decisions and assumptions while developing our own RSVP-TE implementations about the ERO. We think that the idea of clearly specifying the router/interface identifiers and the association between them makes the implementation (and hence the network) more robust. Also see the email that Vach Kompella (one of the co-authors) send to the MPLS mailing list for more reasons. Bora From owner-mpls@UU.NET Tue Feb 27 15:58:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29410 for ; Tue, 27 Feb 2001 15:58: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 QQkefr12567; Tue, 27 Feb 2001 20:58:14 GMT Received: by mail-control.mail.uu.net id QQkefr25630 for mpls-outgoing; Tue, 27 Feb 2001 20:57: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 QQkefr25622 for ; Tue, 27 Feb 2001 20:57: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 QQkefr17035 for ; Tue, 27 Feb 2001 20:57:12 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefr04727 for ; Tue, 27 Feb 2001 20:57:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA11418 for mpls@uu.net; Tue, 27 Feb 2001 15:57: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 QQkefr25525 for ; Tue, 27 Feb 2001 20:56:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefr23391 for ; Tue, 27 Feb 2001 20:55:55 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 QQkefr09177 for ; Tue, 27 Feb 2001 20:55:54 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 MAA13347; Tue, 27 Feb 2001 12:55:09 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BL4D5>; Tue, 27 Feb 2001 12:58:33 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AAF@BBY1EXM01> From: Shahram Davari To: "'Puneet Agarwal'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Tue, 27 Feb 2001 12:58:32 -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 Puneet, I can't follow your reasoning. Let me explain what I am trying to say: If an egress router is the terminating point of a pipe/uniform tunnel, then the egress router must pop the top label and forward the packet using the label (or IP header) that is beneath the popped label. My question is: What TTL is encoded in the forwarding label (or IP header). The answer is: oTTL, which is equal to oTTL= iTTL-1, in which iTTL determination depends on the tunnel model and is described in section 2.3. So my suggestion is to add another bullet (say bullet 4) to section 2.4, that says: 4) Pop : This is the terminating point of an LSP tunnel, in which, first the top label is popped and then the packet is forwarded based on the lower label (or exposed IP header). The TTL of the forwarding label (or IP header) is set to: oTTL = iTTL-1 in which, iTTL is determined based on the type of tunnel (i.e., uniform/pipe) as explained in section 2.3. Yours, -Shahram > -----Original Message----- > From: Puneet Agarwal [mailto:puneet@pluris.com] > Sent: Tuesday, February 27, 2001 3:09 PM > To: Shahram Davari; 'Eric Gray' > Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > 'bsd@cisco.com'; Bora Akyol > Subject: RE: New TTL Draft > > > Hi Shahram, > > Based on the tunnel mode definitions in the -07 version of > mpls-diff draft, > the oTTL determination is not needed explicitly for the "Pop" > case. After > you perform "Pop" (recursively), you need to route (determine > the egress > interface etc) the exposed header (IP packet or label). You > never "Pop" the > label you route on - you can only SWAP, SWAP+Push or PHP > (+Push) the label. > > Hence I never added the bullet for "Pop" when determining > oTTL as it is not > a legal operation. If you want, I can add text in section 2.4 > of the draft > that a "Pop" is not a legal operation for a label we route > on. Would that > help? > > Hope this clarifies. > > -Puneet > > >-----Original Message----- > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >Sent: Tuesday, February 27, 2001 11:19 AM > >To: 'Puneet Agarwal'; 'Eric Gray' > >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > >'bsd@cisco.com'; Bora Akyol > >Subject: RE: New TTL Draft > > > > > >Hi Puneet, > > > >Thanks for your reply. Please see my comments in-line: > > > >> >2) Section 2.4 does not discuss an important case that is: > >> >egress processing of tunnels, i.e. pop and forwarding the > >> >packet as MPLS. > >> > >> Pop (or Egress Pop to distinguish from PHP) is actually > >> covered in section > >> 2.3. The possibly operation when forwarding the packet as > >> MPLS are covered > >> in the 3 bullets of section 2.4. Combine section 2.3 and > >the relevant > >> section of 2.4 and I think your concern about the missing > >> case should be > >> answered. Hence as far as I can see the case is convered, but > >> please let me > >> know if you still think that it is not addressed. > >> > > > > >As you know there are at least 2 distinct operations that are needed > >for TTL processing: > > > >1) Determining iTTL > >2) Determining oTTL > > > >Section 2.3 describes the iTTL determination for both PHP and > >non-PHP case. > >Section 2.4 however describes the oTTL determination for PHP > >case only. I > >can't see anywhere in the draft that talks about oTTL > >determination for non-PHP > >case. Do you see any? > > > > > >Yours, > >Shahram > > > From owner-mpls@UU.NET Tue Feb 27 16:01:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29487 for ; Tue, 27 Feb 2001 16:01: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 QQkefs16783; Tue, 27 Feb 2001 21:00:51 GMT Received: by mail-control.mail.uu.net id QQkefs27190 for mpls-outgoing; Tue, 27 Feb 2001 21:00:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefs26769 for ; Tue, 27 Feb 2001 21:00:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefr14160 for ; Tue, 27 Feb 2001 20:59:15 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkefr14338 for ; Tue, 27 Feb 2001 20:59:15 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 12:58:47 -0800 Message-ID: From: Vach Kompella To: "'Eric Gray'" , Kireeti Kompella Cc: Vach Kompella , yakov@juniper.net, mpls@UU.NET Subject: RE: Expanded ERO draft Date: Tue, 27 Feb 2001 12:58:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A100.0F9BBAF0" 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_01C0A100.0F9BBAF0 Content-Type: text/plain; charset="iso-8859-1" Eric, The interfaces shown are numbered with an outbound perspective, if I understand Kireeti's picture correctly. B understands that the AB link is numbered 1 according to A, and that its own BC link is numbered 1. My comment is on clarifying the processing of the unnum subobjects. -Vach -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Tuesday, February 27, 2001 12:48 PM To: Kireeti Kompella Cc: vkompella@JasmineNetworks.com; yakov@juniper.net; mpls@UU.NET Subject: Re: Expanded ERO draft Kireeti, Out of curiosity, how many un-numbered interfaces can B have that are known to it as interface 1? -- Eric Gray You wrote: Vach, Yakov, > > The other aspect is the first clause of the quoted sentence above from the > > rsvp-unnum draft: "all initial subobjects that refer to itself." > > The text needs to be clarified to say something like "all initial subobjects > of type other than Unnumbered Interface ID"...". While the change in text is possible, it is clear that, unless the interface is physically looped back to itself, the second subobject does *not* refer to "itself". 1 1 1 A ----- B ----- C ----- D B receives an ERO of (1, 1, 1) from A (PHOP). B checks that (A, 1) refers to itself, removes it. Now it sees unnum interface 1, which clearly points at C. Why would B think that this "1" refers to B? Kireeti. ------_=_NextPart_001_01C0A100.0F9BBAF0 Content-Type: text/html; charset="iso-8859-1"
Eric,
 
The interfaces shown are numbered with an outbound perspective, if I understand Kireeti's picture correctly.  B understands that the AB link is numbered 1 according to A, and that its own BC link is numbered 1.
 
My comment is on clarifying the processing of the unnum subobjects.
 
-Vach
-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Tuesday, February 27, 2001 12:48 PM
To: Kireeti Kompella
Cc: vkompella@JasmineNetworks.com; yakov@juniper.net; mpls@UU.NET
Subject: Re: Expanded ERO draft

Kireeti,

    Out of curiosity, how many un-numbered interfaces can
B have that are known to it as interface 1?

--
Eric Gray

You wrote:

Vach, Yakov,

> > The other aspect is the first clause of the quoted sentence above from the
> > rsvp-unnum draft: "all initial subobjects that refer to itself."
>
> The text needs to be clarified to say something like "all initial subobjects
> of type other than Unnumbered Interface ID"...".

While the change in text is possible, it is clear that, unless the
interface is physically looped back to itself, the second subobject
does *not* refer to "itself".

             1       1       1
         A ----- B ----- C ----- D

B receives an ERO of (1, 1, 1) from A (PHOP).  B checks that (A, 1)
refers to itself, removes it.  Now it sees unnum interface 1, which
clearly points at C.  Why would B think that this "1" refers to B?

Kireeti.

------_=_NextPart_001_01C0A100.0F9BBAF0-- From owner-mpls@UU.NET Tue Feb 27 16:12:52 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29949 for ; Tue, 27 Feb 2001 16:12: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 QQkefs26184; Tue, 27 Feb 2001 21:12:37 GMT Received: by mail-control.mail.uu.net id QQkefs12623 for mpls-outgoing; Tue, 27 Feb 2001 21:12:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefs12607 for ; Tue, 27 Feb 2001 21:12:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkefs13837 for ; Tue, 27 Feb 2001 21:11:50 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 QQkefs25079 for ; Tue, 27 Feb 2001 21:11:50 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 NAA00261; Tue, 27 Feb 2001 13:11:49 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id NAA26722; Tue, 27 Feb 2001 13:11:49 -0800 (PST) Date: Tue, 27 Feb 2001 13:11:49 -0800 (PST) From: Kireeti Kompella Message-Id: <200102272111.NAA26722@kummer.juniper.net> To: eric.gray@sandburst.com, kireeti@juniper.net Subject: Re: Expanded ERO draft Cc: mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net In-Reply-To: <3A9C1265.7930735D@sandburst.com> Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, > Out of curiosity, how many un-numbered interfaces can > B have that are known to it as interface 1? One *outgoing* interface. To clarify, in the picture below, the LSP goes left to right, and the interface indices are assigned by the LSR to the left. So, the index on the AB link was assigned by A. B of course also could have assigned an index to the BA link; if so, the value should be distinct from any other index assigned by B. So, the BA link could not (in this instance) get an index of 1. However, B could assign 1 to the BA link if it assigns 2 to the BC link. 1 1 1 A -----> B -----> C -----> D Kireeti. From owner-mpls@UU.NET Tue Feb 27 16:16:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00071 for ; Tue, 27 Feb 2001 16:16: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 QQkeft00935; Tue, 27 Feb 2001 21:15:50 GMT Received: by mail-control.mail.uu.net id QQkefs13081 for mpls-outgoing; Tue, 27 Feb 2001 21:14: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 QQkefs13070 for ; Tue, 27 Feb 2001 21:14: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 QQkefs21411 for ; Tue, 27 Feb 2001 21:14:34 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefs29041 for ; Tue, 27 Feb 2001 21:14:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA13933 for mpls@uu.net; Tue, 27 Feb 2001 16:14:33 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefs12954 for ; Tue, 27 Feb 2001 21:13:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkefs17443 for ; Tue, 27 Feb 2001 21:13: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 QQkefs27545 for ; Tue, 27 Feb 2001 21:13: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 NAA18225; Tue, 27 Feb 2001 13:12:50 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BL4QP>; Tue, 27 Feb 2001 13:16:14 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB0@BBY1EXM01> From: Shahram Davari To: Shahram Davari , "'Puneet Agarwal'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Tue, 27 Feb 2001 13:16:13 -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 All, Interestingly a similar draft was posted today: http://www.ietf.org/internet-drafts/draft-satoru-mpls-1hop-lsp-00.txt Yours, -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Tuesday, February 27, 2001 3:59 PM > To: 'Puneet Agarwal'; 'Eric Gray' > Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > 'bsd@cisco.com'; Bora Akyol > Subject: RE: New TTL Draft > > > Hi Puneet, > > I can't follow your reasoning. Let me explain what I am trying to say: > > If an egress router is the terminating point of a > pipe/uniform tunnel, then the egress router must pop the top > label and forward the packet using the label (or IP header) > that is beneath the popped label. My question is: What TTL is > encoded in the forwarding label (or IP header). The answer > is: oTTL, which is equal to oTTL= iTTL-1, in which iTTL > determination depends on the tunnel model and is described in > section 2.3. > > So my suggestion is to add another bullet (say bullet 4) to > section 2.4, that says: > > 4) Pop : This is the terminating point of an LSP tunnel, in > which, first the top label is popped and then the packet is > forwarded based on the lower label (or exposed IP header). > The TTL of the forwarding label (or IP header) is set to: > > oTTL = iTTL-1 > > in which, iTTL is determined based on the type of tunnel > (i.e., uniform/pipe) as explained in section 2.3. > > > Yours, > -Shahram > > > -----Original Message----- > > From: Puneet Agarwal [mailto:puneet@pluris.com] > > Sent: Tuesday, February 27, 2001 3:09 PM > > To: Shahram Davari; 'Eric Gray' > > Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > > 'bsd@cisco.com'; Bora Akyol > > Subject: RE: New TTL Draft > > > > > > Hi Shahram, > > > > Based on the tunnel mode definitions in the -07 version of > > mpls-diff draft, > > the oTTL determination is not needed explicitly for the "Pop" > > case. After > > you perform "Pop" (recursively), you need to route (determine > > the egress > > interface etc) the exposed header (IP packet or label). You > > never "Pop" the > > label you route on - you can only SWAP, SWAP+Push or PHP > > (+Push) the label. > > > > Hence I never added the bullet for "Pop" when determining > > oTTL as it is not > > a legal operation. If you want, I can add text in section 2.4 > > of the draft > > that a "Pop" is not a legal operation for a label we route > > on. Would that > > help? > > > > Hope this clarifies. > > > > -Puneet > > > > >-----Original Message----- > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > >Sent: Tuesday, February 27, 2001 11:19 AM > > >To: 'Puneet Agarwal'; 'Eric Gray' > > >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > > >'bsd@cisco.com'; Bora Akyol > > >Subject: RE: New TTL Draft > > > > > > > > >Hi Puneet, > > > > > >Thanks for your reply. Please see my comments in-line: > > > > > >> >2) Section 2.4 does not discuss an important case that is: > > >> >egress processing of tunnels, i.e. pop and forwarding the > > >> >packet as MPLS. > > >> > > >> Pop (or Egress Pop to distinguish from PHP) is actually > > >> covered in section > > >> 2.3. The possibly operation when forwarding the packet as > > >> MPLS are covered > > >> in the 3 bullets of section 2.4. Combine section 2.3 and > > >the relevant > > >> section of 2.4 and I think your concern about the missing > > >> case should be > > >> answered. Hence as far as I can see the case is convered, but > > >> please let me > > >> know if you still think that it is not addressed. > > >> > > > > > > >As you know there are at least 2 distinct operations that > are needed > > >for TTL processing: > > > > > >1) Determining iTTL > > >2) Determining oTTL > > > > > >Section 2.3 describes the iTTL determination for both PHP and > > >non-PHP case. > > >Section 2.4 however describes the oTTL determination for PHP > > >case only. I > > >can't see anywhere in the draft that talks about oTTL > > >determination for non-PHP > > >case. Do you see any? > > > > > > > > >Yours, > > >Shahram > > > > > > From owner-mpls@UU.NET Tue Feb 27 16:23:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00443 for ; Tue, 27 Feb 2001 16: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 QQkeft17053; Tue, 27 Feb 2001 21:22:46 GMT Received: by mail-control.mail.uu.net id QQkeft14129 for mpls-outgoing; Tue, 27 Feb 2001 21:22:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeft14108 for ; Tue, 27 Feb 2001 21:22:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeft06615 for ; Tue, 27 Feb 2001 21:21:47 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkeft26795 for ; Tue, 27 Feb 2001 21:21:47 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 113D094009; Tue, 27 Feb 2001 16:21:47 -0500 (EST) Message-ID: <3A9C1A6A.7C7B80F4@sandburst.com> Date: Tue, 27 Feb 2001 16:21:46 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Vach Kompella Cc: Kireeti Kompella , yakov@juniper.net, mpls@UU.NET Subject: Re: Expanded ERO draft References: Content-Type: multipart/alternative; boundary="------------5011659597B507F51FA063A9" Sender: owner-mpls@UU.NET Precedence: bulk --------------5011659597B507F51FA063A9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vach, Thanks for the prompt reply. However, it doesn't really help. :-) Consider that I may have a function "isMe()" that I use to eliminate self-references in an ERO. If, as you say, B recognizes that '1' is an interface by which upstream LSR A knows B, then this function should return true every time it is passed the value '1' in a context in which it has gotten an ERO in a message from LSR A. In this case, iterative calls to "isMe()" would result in removing all of the '1's in the ERO. -- Eric Gray You wrote: > Eric,The interfaces shown are numbered with an outbound perspective, > if I understand Kireeti's picture correctly. B understands that the > AB link is numbered 1 according to A, and that its own BC link is > numbered 1.My comment is on clarifying the processing of the unnum > subobjects.-Vach > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Tuesday, February 27, 2001 12:48 PM > To: Kireeti Kompella > Cc: vkompella@JasmineNetworks.com; yakov@juniper.net; > mpls@UU.NET > Subject: Re: Expanded ERO draft > > Kireeti, > > Out of curiosity, how many un-numbered interfaces can > B have that are known to it as interface 1? > > -- > Eric Gray > > You wrote: > > > Vach, Yakov, > > > > > > The other aspect is the first clause of the quoted > > sentence above from the > > > > rsvp-unnum draft: "all initial subobjects that refer > > to itself." > > > > > > The text needs to be clarified to say something like > > "all initial subobjects > > > of type other than Unnumbered Interface ID"...". > > > > While the change in text is possible, it is clear that, > > unless the > > interface is physically looped back to itself, the second > > subobject > > does *not* refer to "itself". > > > > 1 1 1 > > A ----- B ----- C ----- D > > > > B receives an ERO of (1, 1, 1) from A (PHOP). B checks > > that (A, 1) > > refers to itself, removes it. Now it sees unnum interface > > 1, which > > clearly points at C. Why would B think that this "1" > > refers to B? > > > > Kireeti. > --------------5011659597B507F51FA063A9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Vach,

    Thanks for the prompt reply.  However, it doesn't really
help.  :-)

    Consider that I may have a function "isMe()" that I use
to eliminate self-references in an ERO.  If, as you say, B
recognizes that '1' is an interface by which upstream LSR
A knows B, then this function should return true every time
it is passed the value '1' in a context in which it has gotten
an ERO in a message from LSR A.  In this case, iterative
calls to "isMe()" would result in removing all of the '1's
in the ERO.

--
Eric Gray

You wrote:

 Eric,The interfaces shown are numbered with an outbound perspective, if I understand Kireeti's picture correctly.  B understands that the AB link is numbered 1 according to A, and that its own BC link is numbered 1.My comment is on clarifying the processing of the unnum subobjects.-Vach
-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Tuesday, February 27, 2001 12:48 PM
To: Kireeti Kompella
Cc: vkompella@JasmineNetworks.com; yakov@juniper.net; mpls@UU.NET
Subject: Re: Expanded ERO draft
 
Kireeti,

    Out of curiosity, how many un-numbered interfaces can
B have that are known to it as interface 1?

--
Eric Gray

You wrote:

Vach, Yakov,

> > The other aspect is the first clause of the quoted sentence above from the
> > rsvp-unnum draft: "all initial subobjects that refer to itself."
>
> The text needs to be clarified to say something like "all initial subobjects
> of type other than Unnumbered Interface ID"...".

While the change in text is possible, it is clear that, unless the
interface is physically looped back to itself, the second subobject
does *not* refer to "itself".

             1       1       1
         A ----- B ----- C ----- D

B receives an ERO of (1, 1, 1) from A (PHOP).  B checks that (A, 1)
refers to itself, removes it.  Now it sees unnum interface 1, which
clearly points at C.  Why would B think that this "1" refers to B?

Kireeti.

--------------5011659597B507F51FA063A9-- From owner-mpls@UU.NET Tue Feb 27 16:35:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00887 for ; Tue, 27 Feb 2001 16:35: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 QQkefu22067; Tue, 27 Feb 2001 21:35:30 GMT Received: by mail-control.mail.uu.net id QQkefu15524 for mpls-outgoing; Tue, 27 Feb 2001 21:35: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 QQkefu15501 for ; Tue, 27 Feb 2001 21:34:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefu14730 for ; Tue, 27 Feb 2001 21:34:34 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkefu20607 for ; Tue, 27 Feb 2001 21:34:34 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 98DE694009; Tue, 27 Feb 2001 16:34:33 -0500 (EST) Message-ID: <3A9C1D69.6ECA4510@sandburst.com> Date: Tue, 27 Feb 2001 16:34:33 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella Cc: mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Subject: Re: Expanded ERO draft References: <200102272111.NAA26722@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Thanks, and thanks to Vach as well. I guess the bottom line is - what Yakov said applies: i.e. (paraphrasing) all self references refers to references other than un-numbered interface IDs. This might be a point that would be covered in the BCP you mentioned... -- Eric Gray You wrote: > Hi Eric, > > > Out of curiosity, how many un-numbered interfaces can > > B have that are known to it as interface 1? > > One *outgoing* interface. To clarify, in the picture below, > the LSP goes left to right, and the interface indices are > assigned by the LSR to the left. So, the index on the AB > link was assigned by A. B of course also could have assigned > an index to the BA link; if so, the value should be distinct > from any other index assigned by B. So, the BA link could not > (in this instance) get an index of 1. However, B could assign > 1 to the BA link if it assigns 2 to the BC link. > > 1 1 1 > A -----> B -----> C -----> D > > Kireeti. From owner-mpls@UU.NET Tue Feb 27 16:37:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00964 for ; Tue, 27 Feb 2001 16:37:02 -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 QQkefu24136; Tue, 27 Feb 2001 21:36:45 GMT Received: by mail-control.mail.uu.net id QQkefu15701 for mpls-outgoing; Tue, 27 Feb 2001 21:36: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 QQkefu15673 for ; Tue, 27 Feb 2001 21:36:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefu28877 for ; Tue, 27 Feb 2001 21:35:29 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefu21987 for ; Tue, 27 Feb 2001 21:35:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA16678 for mpls@uu.net; Tue, 27 Feb 2001 16:35:27 -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 QQkefu15420 for ; Tue, 27 Feb 2001 21:33:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefu18411 for ; Tue, 27 Feb 2001 21:32:22 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: madrid.cisco.com [64.103.17.204]) id QQkefu07812 for ; Tue, 27 Feb 2001 21:32:21 GMT Received: from behringer-nt1.cisco.com (mbehring-isdn-home5.cisco.com [10.49.40.230]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA08050 for ; Tue, 27 Feb 2001 22:32:14 +0100 (MET) Message-Id: <4.3.2.20010227222845.025117d0@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Feb 2001 22:30:17 +0100 To: mpls@UU.NET From: "Michael H. Behringer" Subject: ID on MPLS security Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have written up some analysis of the security of MPLS versus "traditional" VPN technologies such as ATM and FR. I would appreciate some feedback on this. http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-00.txt Thanks, Michael --- Subject: I-D ACTION:draft-behringer-mpls-security-00.txt Date: 27 Feb 2001 05:00:05 -0800 From: Internet-Drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of the Security of the MPLS Architecture Author(s) : M. Behringer Filename : draft-behringer-mpls-security-00.txt Pages : 12 Date : 26-Feb-01 This document analyses the security of the MPLS architecture, especially in comparison with other VPN technologies such as ATM and Frame Relay. The target audience is service providers and VPN users. The document consists of two main parts: First the requirements for security in VPN services are defined, second MPLS is examined with respect to these requirements. The analysis shows that MPLS networks can be equally secured as traditional layer-2 networks such as ATM and Frame Relay. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-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-behringer-mpls-security-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-behringer-mpls-security-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: <20010226143050.I-D@ietf.org> -- Michael H. Behringer - Cisco EMEA SP Consulting - mbehring@cisco.com Tel: +34.91.2012606 - Mobile: +34.639.659822 PGP Fingerprint: 28DA C9BE D259 5437 77F8 5ED1 2EE8 D4DB From owner-mpls@UU.NET Tue Feb 27 16:43:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01172 for ; Tue, 27 Feb 2001 16:43: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 QQkefu03450; Tue, 27 Feb 2001 21:42:57 GMT Received: by mail-control.mail.uu.net id QQkefu16435 for mpls-outgoing; Tue, 27 Feb 2001 21:42:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkefu16420 for ; Tue, 27 Feb 2001 21:42: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 QQkefu18091 for ; Tue, 27 Feb 2001 21:41:36 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkefu27406 for ; Tue, 27 Feb 2001 21:41:35 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA25733; Tue, 27 Feb 2001 13:41:33 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <3A9C1D69.6ECA4510@sandburst.com> References: <200102272111.NAA26722@kummer.juniper.net> <3A9C1D69.6ECA4510@sandburst.com> Date: Tue, 27 Feb 2001 13:40:08 -0800 To: Eric Gray From: Bora Akyol Subject: Re: Expanded ERO draft Cc: Kireeti Kompella , mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk Or alternately, one can add the router ID to the unnumbered ERO to remove any ambiguities and also simplify fast reroute. Bora At 4:34 PM -0500 2/27/01, Eric Gray wrote: >Kireeti, > > Thanks, and thanks to Vach as well. > > I guess the bottom line is - what Yakov said applies: >i.e. (paraphrasing) all self references refers to references >other than un-numbered interface IDs. This might be a >point that would be covered in the BCP you mentioned... > >-- >Eric Gray > >You wrote: > >> Hi Eric, >> >> > Out of curiosity, how many un-numbered interfaces can >> > B have that are known to it as interface 1? >> >> One *outgoing* interface. To clarify, in the picture below, >> the LSP goes left to right, and the interface indices are >> assigned by the LSR to the left. So, the index on the AB >> link was assigned by A. B of course also could have assigned >> an index to the BA link; if so, the value should be distinct >> from any other index assigned by B. So, the BA link could not >> (in this instance) get an index of 1. However, B could assign >> 1 to the BA link if it assigns 2 to the BC link. > > > > 1 1 1 > > A -----> B -----> C -----> D > > > > Kireeti. From owner-mpls@UU.NET Tue Feb 27 16:49:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01433 for ; Tue, 27 Feb 2001 16:49:21 -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 QQkefv12128; Tue, 27 Feb 2001 21:49:01 GMT Received: by mail-control.mail.uu.net id QQkefv17387 for mpls-outgoing; Tue, 27 Feb 2001 21: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 QQkefv17381 for ; Tue, 27 Feb 2001 21:48: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 QQkefv05764 for ; Tue, 27 Feb 2001 21:47:19 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkefv08677 for ; Tue, 27 Feb 2001 21:47:17 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 13:46:58 -0800 Message-ID: From: Vach Kompella To: "'Eric Gray'" Cc: mpls@UU.NET Subject: RE: Expanded ERO draft Date: Tue, 27 Feb 2001 13:46:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A106.CC9CFCD0" 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_01C0A106.CC9CFCD0 Content-Type: text/plain; charset="iso-8859-1" Eric, OK, I didn't get: you were basically restating my point. However, I think you don't resolve such ambiguities in BCPs. Changes in the text of the draft (or more explicit EROs) are more apropos. -Vach -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Tuesday, February 27, 2001 1:22 PM To: Vach Kompella Cc: Kireeti Kompella; yakov@juniper.net; mpls@UU.NET Subject: Re: Expanded ERO draft Vach, Thanks for the prompt reply. However, it doesn't really help. :-) Consider that I may have a function "isMe()" that I use to eliminate self-references in an ERO. If, as you say, B recognizes that '1' is an interface by which upstream LSR A knows B, then this function should return true every time it is passed the value '1' in a context in which it has gotten an ERO in a message from LSR A. In this case, iterative calls to "isMe()" would result in removing all of the '1's in the ERO. -- Eric Gray You wrote: Eric,The interfaces shown are numbered with an outbound perspective, if I understand Kireeti's picture correctly. B understands that the AB link is numbered 1 according to A, and that its own BC link is numbered 1.My comment is on clarifying the processing of the unnum subobjects.-Vach -----Original Message----- From: Eric Gray [ mailto:eric.gray@sandburst.com ] Sent: Tuesday, February 27, 2001 12:48 PM To: Kireeti Kompella Cc: vkompella@JasmineNetworks.com; yakov@juniper.net; mpls@UU.NET Subject: Re: Expanded ERO draft Kireeti, Out of curiosity, how many un-numbered interfaces can B have that are known to it as interface 1? -- Eric Gray You wrote: Vach, Yakov, > > The other aspect is the first clause of the quoted sentence above from the > > rsvp-unnum draft: "all initial subobjects that refer to itself." > > The text needs to be clarified to say something like "all initial subobjects > of type other than Unnumbered Interface ID"...". While the change in text is possible, it is clear that, unless the interface is physically looped back to itself, the second subobject does *not* refer to "itself". 1 1 1 A ----- B ----- C ----- D B receives an ERO of (1, 1, 1) from A (PHOP). B checks that (A, 1) refers to itself, removes it. Now it sees unnum interface 1, which clearly points at C. Why would B think that this "1" refers to B? Kireeti. ------_=_NextPart_001_01C0A106.CC9CFCD0 Content-Type: text/html; charset="iso-8859-1"
Eric,
 
OK, I didn't get: you were basically restating my point.  However, I think you don't resolve such ambiguities in BCPs.  Changes in the text of the draft (or more explicit EROs) are more apropos.
 
-Vach
-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Tuesday, February 27, 2001 1:22 PM
To: Vach Kompella
Cc: Kireeti Kompella; yakov@juniper.net; mpls@UU.NET
Subject: Re: Expanded ERO draft

Vach,

    Thanks for the prompt reply.  However, it doesn't really
help.  :-)

    Consider that I may have a function "isMe()" that I use
to eliminate self-references in an ERO.  If, as you say, B
recognizes that '1' is an interface by which upstream LSR
A knows B, then this function should return true every time
it is passed the value '1' in a context in which it has gotten
an ERO in a message from LSR A.  In this case, iterative
calls to "isMe()" would result in removing all of the '1's
in the ERO.

--
Eric Gray

You wrote:

 Eric,The interfaces shown are numbered with an outbound perspective, if I understand Kireeti's picture correctly.  B understands that the AB link is numbered 1 according to A, and that its own BC link is numbered 1.My comment is on clarifying the processing of the unnum subobjects.-Vach
-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Tuesday, February 27, 2001 12:48 PM
To: Kireeti Kompella
Cc: vkompella@JasmineNetworks.com; yakov@juniper.net; mpls@UU.NET
Subject: Re: Expanded ERO draft
 
Kireeti,

    Out of curiosity, how many un-numbered interfaces can
B have that are known to it as interface 1?

--
Eric Gray

You wrote:

Vach, Yakov,

> > The other aspect is the first clause of the quoted sentence above from the
> > rsvp-unnum draft: "all initial subobjects that refer to itself."
>
> The text needs to be clarified to say something like "all initial subobjects
> of type other than Unnumbered Interface ID"...".

While the change in text is possible, it is clear that, unless the
interface is physically looped back to itself, the second subobject
does *not* refer to "itself".

             1       1       1
         A ----- B ----- C ----- D

B receives an ERO of (1, 1, 1) from A (PHOP).  B checks that (A, 1)
refers to itself, removes it.  Now it sees unnum interface 1, which
clearly points at C.  Why would B think that this "1" refers to B?

Kireeti.

------_=_NextPart_001_01C0A106.CC9CFCD0-- From owner-mpls@UU.NET Tue Feb 27 16:53:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01638 for ; Tue, 27 Feb 2001 16:53: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 QQkefv20415; Tue, 27 Feb 2001 21:53:04 GMT Received: by mail-control.mail.uu.net id QQkefv17884 for mpls-outgoing; Tue, 27 Feb 2001 21:52:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefv17861 for ; Tue, 27 Feb 2001 21:52:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkefv19737 for ; Tue, 27 Feb 2001 21:51:23 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkefv28115 for ; Tue, 27 Feb 2001 21:51:23 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA03568 for ; Tue, 27 Feb 2001 16:51:23 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA03563 for ; Tue, 27 Feb 2001 16:51:22 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA11241; Tue, 27 Feb 2001 16:51:22 -0500 (EST) Message-ID: <3A9C2159.5B97CCAD@lucent.com> Date: Tue, 27 Feb 2001 16:51:21 -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: mpls@UU.NET Subject: Re: Expanded ERO draft References: <200102272111.NAA26722@kummer.juniper.net> <3A9C1D69.6ECA4510@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This is what I proposed in draft-xu-ccamp-gmpls-sig-reorg-00.txt Make it simple and put related pieces of information into one meaningful unit. I don't know why we have to design something complicate intentionally. Yangguang Bora Akyol wrote: > > Or alternately, one can add the router ID to the unnumbered ERO to > remove any ambiguities and also simplify fast reroute. > > Bora > > At 4:34 PM -0500 2/27/01, Eric Gray wrote: > >Kireeti, > > > > Thanks, and thanks to Vach as well. > > > > I guess the bottom line is - what Yakov said applies: > >i.e. (paraphrasing) all self references refers to references > >other than un-numbered interface IDs. This might be a > >point that would be covered in the BCP you mentioned... > > > >-- > >Eric Gray > > > >You wrote: > > > >> Hi Eric, > >> > >> > Out of curiosity, how many un-numbered interfaces can > >> > B have that are known to it as interface 1? > >> > >> One *outgoing* interface. To clarify, in the picture below, > >> the LSP goes left to right, and the interface indices are > >> assigned by the LSR to the left. So, the index on the AB > >> link was assigned by A. B of course also could have assigned > >> an index to the BA link; if so, the value should be distinct > >> from any other index assigned by B. So, the BA link could not > >> (in this instance) get an index of 1. However, B could assign > >> 1 to the BA link if it assigns 2 to the BC link. > > > > > > 1 1 1 > > > A -----> B -----> C -----> D > > > > > > Kireeti. From owner-mpls@UU.NET Tue Feb 27 16:54:26 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01669 for ; Tue, 27 Feb 2001 16:54: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 QQkefv19221; Tue, 27 Feb 2001 21:54:09 GMT Received: by mail-control.mail.uu.net id QQkefv18056 for mpls-outgoing; Tue, 27 Feb 2001 21:53: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 QQkefv17960 for ; Tue, 27 Feb 2001 21:53: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 QQkefv23925 for ; Tue, 27 Feb 2001 21:53:15 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkefv20871 for ; Tue, 27 Feb 2001 21:53:15 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA27074; Tue, 27 Feb 2001 13:53:12 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: Date: Tue, 27 Feb 2001 13:51:47 -0800 To: Bala Rajagopalan From: Bora Akyol Subject: RE: New Internet Draft on ERO Cc: "'Bora Akyol'" , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 2:45 PM -0500 2/27/01, Bala Rajagopalan wrote: >Hello, > >> >> >> 1. You need to specify both ingress and egress identifiers >> for two reasons: >> a) On broadcast media (think GigE, 10 GigE) when a router has >> multiple interfaces attached to the same switch, you want the RSVP >> packet and MPLS LSPs to use the correct adjacency. And the only way >> to get that is to specify a pair. This scenario is commonly used in >> POP architectures where there are two GigE switches in the middle and >> each router has one link to each GigE switch and the GigE switches >> are interconnected. > >What is the meaning of "correct adjacency" here? Specifically, >is there any reason for distinguishing between such adjacencies >ariori at the source? (Or, is there any reason why this >sort of decision cannot be left as a local >matter to previous hop node?) You have two routers that are connected to an ethernet switch via multiple interfaces on each side. The head end LSR has calculated an explicitly routed path that is strict. For one to be able to specify a strict path in a LAN environment you need to be able to specify both ingress and egress interfaces. This is a matter of correctness, IMHO. Now does this matter? Based on the POP architectures that I have seen, this is a case that occurs for redundancy reasons fairly often, so the correctness does matter. Even though the broadcast media is shared, the packet treatment mechanisms are not shared and you need to be able to deliver deterministic service. > > >> 2. I just asked a simple question with respect to fast reroute: How >> do you do it when you have unnumbered interfaces. At first thought, I >> thought it would be very hard to do, after thinking about it for a >> few minutes I think if you make certain assumptions and make >> extensive use of the IGP-TE database, you can possibly get by. But >> why? Why are we arguing over 4 more bytes in the signaling message. >> We don't have 56K leased line links any more. OC192c has become the >> standard and 768c is right around the corner. I don't see any point >> it haggling on four bytes. Hence we defined the EERO. > >Actually, I'm just trying to understand the motivation and problem w.r.t >reroute. It would really help if you can describe the >problem in some detail. Think of an unnumbered ERO of the form <1,1,1,1,1,1,1,1> Now somewhere in the middle, an LSR wants to calculate a fast reroute LSP. Normally, one would ask the TE database the simple question of avoid my next hop and would give the router ID of the next hop, but in this case, first you have to find out who the router at the end of the egress interface is. This is not hard, then you need to find out who the router that is right after the immediate hop. This second one is harder since you have to make a query into the TE database, to find that. Then you have to make a third query into TED, to calculate an LSP that avoids the immediate next hop but merges as soon as possible with the main LSP. And finally, you calculate an ERO that now is a mixture of both numbered and unnumbered interfaces possibly and initiate signaling. As I describe here, this is not undoable, but at what cost. If one adds the extra four bytes of router ID as part of the ERO (as we did in the EERO) this whole thing becomes trivial to implement. I am advocate for putting enough bits on the wire to make implementation simpler. Bora From owner-mpls@UU.NET Tue Feb 27 17:25:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03218 for ; Tue, 27 Feb 2001 17:25: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 QQkefx14452; Tue, 27 Feb 2001 22:25:20 GMT Received: by mail-control.mail.uu.net id QQkefx06973 for mpls-outgoing; Tue, 27 Feb 2001 22:24:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefx06967 for ; Tue, 27 Feb 2001 22:24:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefx06657 for ; Tue, 27 Feb 2001 22:24:32 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 QQkefx00716 for ; Tue, 27 Feb 2001 22:24:31 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 OAA06363; Tue, 27 Feb 2001 14:24:30 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id OAA27375; Tue, 27 Feb 2001 14:24:29 -0800 (PST) Date: Tue, 27 Feb 2001 14:24:29 -0800 (PST) From: Kireeti Kompella Message-Id: <200102272224.OAA27375@kummer.juniper.net> To: akyol@pluris.com, eric.gray@sandburst.com Subject: Re: Expanded ERO draft Cc: kireeti@juniper.net, mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk > Or alternately, one can add the router ID to the unnumbered ERO to > remove any ambiguities and also simplify fast reroute. As Yakov said, no concrete reason for adding the router ID has been given. However, we've wasted enough time and bandwidth. Let's put this to vote: Who all think that adding a router ID to the unnumbered ERO subobject would be beneficial? A simple yes, no or don't care, please. Kireeti. From owner-mpls@UU.NET Tue Feb 27 17:50:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03877 for ; Tue, 27 Feb 2001 17:50: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 QQkefz11350; Tue, 27 Feb 2001 22:50:24 GMT Received: by mail-control.mail.uu.net id QQkefz09733 for mpls-outgoing; Tue, 27 Feb 2001 22:49: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 QQkefz09722 for ; Tue, 27 Feb 2001 22:49:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefz14480 for ; Tue, 27 Feb 2001 22:48:45 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 QQkefz08181 for ; Tue, 27 Feb 2001 22:48:45 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f1RMl4S17761; Tue, 27 Feb 2001 17:47:05 -0500 (EST) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 17:42:13 -0500 Message-ID: <0CD7D73C734BD411AEE100B0D0220404DFDDAE@mail1.tellium.com> From: Bala Rajagopalan To: "'Bora Akyol'" Cc: mpls@UU.NET Subject: RE: New Internet Draft on ERO Date: Tue, 27 Feb 2001 17:41:38 -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 > > Think of an unnumbered ERO of the form <1,1,1,1,1,1,1,1> > > Now somewhere in the middle, an LSR wants to calculate a fast reroute > LSP. Normally, one would ask the TE database the simple question of > avoid my next hop and would give the router ID of the next hop, but > in this case, first you have to find out who the router at the end of > the egress interface is. This is not hard, then you need to find out > who the router that is right after the immediate hop. This second one > is harder since you have to make a query into the TE database, to > find that. Then you have to make a third query into TED, to calculate > an LSP that avoids the immediate next hop but merges as soon as > possible with the main LSP. And finally, you calculate an ERO that > now is a mixture of both numbered and unnumbered interfaces possibly > and initiate signaling. As I describe here, this is not undoable, but > at what cost. > > If one adds the extra four bytes of router ID as part of the ERO (as > we did in the EERO) this whole thing becomes trivial to implement. > Just curious, to implement this type of fast reroute, can't intermediate nodes get downstream information from record route? Bala From owner-mpls@UU.NET Tue Feb 27 18:10:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04468 for ; Tue, 27 Feb 2001 18:10: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 QQkega29933; Tue, 27 Feb 2001 23:09:54 GMT Received: by mail-control.mail.uu.net id QQkega26365 for mpls-outgoing; Tue, 27 Feb 2001 23:09:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkega26353 for ; Tue, 27 Feb 2001 23:09:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkega18574 for ; Tue, 27 Feb 2001 23:08:11 GMT Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQkega10676 for ; Tue, 27 Feb 2001 23:08:11 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 15:06:05 -0800 Message-ID: From: John Drake To: "'Kireeti Kompella'" , akyol@pluris.com, eric.gray@sandburst.com Cc: mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Subject: RE: Expanded ERO draft Date: Tue, 27 Feb 2001 15:05:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Based upon e-mail I've seen, I think we've established that it doesn't provide any additional functionality or utility. There's a colloquial New England expression that covers this - as useful as teats on a boar. -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Tuesday, February 27, 2001 2:24 PM To: akyol@pluris.com; eric.gray@sandburst.com Cc: kireeti@juniper.net; mpls@UU.NET; vkompella@JasmineNetworks.com; yakov@juniper.net Subject: Re: Expanded ERO draft > Or alternately, one can add the router ID to the unnumbered ERO to > remove any ambiguities and also simplify fast reroute. As Yakov said, no concrete reason for adding the router ID has been given. However, we've wasted enough time and bandwidth. Let's put this to vote: Who all think that adding a router ID to the unnumbered ERO subobject would be beneficial? A simple yes, no or don't care, please. Kireeti. From owner-mpls@UU.NET Tue Feb 27 18:29:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04888 for ; Tue, 27 Feb 2001 18:29: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 QQkegb08034; Tue, 27 Feb 2001 23:29:12 GMT Received: by mail-control.mail.uu.net id QQkegb28893 for mpls-outgoing; Tue, 27 Feb 2001 23:28: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 QQkegb28888 for ; Tue, 27 Feb 2001 23:28: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 QQkegb04129 for ; Tue, 27 Feb 2001 23:28:11 GMT Received: from hoemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkegb15550 for ; Tue, 27 Feb 2001 23:28:11 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA19640 for ; Tue, 27 Feb 2001 18:28:10 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA19596; Tue, 27 Feb 2001 18:28:05 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA24074; Tue, 27 Feb 2001 18:28:05 -0500 (EST) Message-ID: <3A9C3804.C4650CB8@lucent.com> Date: Tue, 27 Feb 2001 18:28:04 -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: Kireeti Kompella CC: akyol@pluris.com, eric.gray@sandburst.com, mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Subject: Re: Expanded ERO draft References: <200102272224.OAA27375@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Would you please tell me which one is simpler and more straight forward? Isn't being simpler and more straight forward a concrete reason? Yangguang Kireeti Kompella wrote: > > > Or alternately, one can add the router ID to the unnumbered ERO to > > remove any ambiguities and also simplify fast reroute. > > As Yakov said, no concrete reason for adding the router ID has been > given. However, we've wasted enough time and bandwidth. Let's put > this to vote: > > Who all think that adding a router ID to the unnumbered ERO subobject > would be beneficial? A simple yes, no or don't care, please. > > Kireeti. From owner-mpls@UU.NET Tue Feb 27 18:33:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05004 for ; Tue, 27 Feb 2001 18:33: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 QQkegc13829; Tue, 27 Feb 2001 23:33:21 GMT Received: by mail-control.mail.uu.net id QQkegc29487 for mpls-outgoing; Tue, 27 Feb 2001 23:32:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkegc29471 for ; Tue, 27 Feb 2001 23:32:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegc29669 for ; Tue, 27 Feb 2001 23:32:33 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkegc11236 for ; Tue, 27 Feb 2001 23:32:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA00386 for mpls@uu.net; Tue, 27 Feb 2001 18:32:31 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkegc29343 for ; Tue, 27 Feb 2001 23:32:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegc28566 for ; Tue, 27 Feb 2001 23:32:04 GMT Received: from boyle.eng.level3.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQkegc10312 for ; Tue, 27 Feb 2001 23:32:04 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id KAA01198 for ; Tue, 27 Feb 2001 10:07:46 -0700 X-Authentication-Warning: boyle.eng.level3.com: jboyle owned process doing -bs Date: Tue, 27 Feb 2001 10:07:46 -0700 (MST) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: mpls@UU.NET Subject: comments on draft-dubuc-mpls-bundle-mib-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Martin, good idea, if we're going to start thinking about having link bundles, we should probably think about mibs to get relevant information out of network (for nms) or into network (if that is one's manner). I do think that this mib reaches too far, and replicates information that is available elsewhere. You mention an example of grouping 3 component links into 1 bundled link. For some reason you mention 2 primary and 1 secondary, is this 1:N protection, and if so, is there a relevant APS/Sonet/SDH mib where this assocation of the secondary to the protected links should be made? In general, the mib should be able to grab interfaces and group them together, however it's my view that these become standard interfaces, seen in ifTable, in relevant OSPF mibs, TE mibs, etc... The bundled mib keeps track of the relationship only (e.g. id 10 really is a composite of 1,2,3) Why would one want to be able to not only get the OSPF TE metric from the bundled mib, and from the TEMIB? Anyways, my comment would be that the bundle mib should stick to a core business, and leverage information that exist (rightfully) in other places. regards, Jim From owner-mpls@UU.NET Tue Feb 27 18:51:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05372 for ; Tue, 27 Feb 2001 18:51: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 QQkegd06219; Tue, 27 Feb 2001 23:50:38 GMT Received: by mail-control.mail.uu.net id QQkegd01448 for mpls-outgoing; Tue, 27 Feb 2001 23:49: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 QQkegd01437 for ; Tue, 27 Feb 2001 23:49:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkegd08712 for ; Tue, 27 Feb 2001 23:49:11 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkegd12413 for ; Tue, 27 Feb 2001 23:49:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA00387 for mpls@uu.net; Tue, 27 Feb 2001 18:32:31 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkegc29344 for ; Tue, 27 Feb 2001 23:32:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegc28549 for ; Tue, 27 Feb 2001 23:32:04 GMT Received: from boyle.eng.level3.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQkegc10292 for ; Tue, 27 Feb 2001 23:32:03 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id MAA00986; Tue, 27 Feb 2001 12:24:16 -0700 X-Authentication-Warning: boyle.eng.level3.com: jboyle owned process doing -bs Date: Tue, 27 Feb 2001 12:24:16 -0700 (MST) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: "Thomas D. Nadeau" cc: mpls@UU.NET Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt In-Reply-To: <4.3.2.7.2.20010223150102.06a62cf8@bucket.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk pretend you are a service provider, a customer calls in and says he's seeing errors on his service (in particular, bip violalations in POH). He is directly connected to your network via port A. On the far end, he connects to a clec, which hands it off to you at port Z. He connects to a CLEC adm on port Z'. His path terminating equipment (maybe a router) is port Ac, and Zc, such that the service looks like: Ac-A-[IP]-Z-CLEC-Z'-Zc Looking at lines Ac-A and Z-CLEC shows clean lines. How does the operator determine if his IP network is to blame, or the CLECs network is to blame? i'd recomend a few things: o) Andy's draft should have some sort of way to determine if there are bit errors hapenning across the IP network that affect the service payload. This would provide the same sort of delineation of where a problem is occuring by looking at LOHs in more traditional transport network. o) your mib should include analogues to the SONET mib, such as bip-8 violations, errored seconds, etc... (working off memory here). o) addition of a "reason for last down" might be nice. This way, when you, as the service provider, replies that "it's not our problem, must be the clec", they can say at least go look at it later to see if they were telling the truth. As usual, excellent attention paid to the configuration aspects. regards, Jim On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > Hi, > > FYI a new MIB for managing SONET/SDH Circuit Emulation > Service Over MPLS has been posted. It should be available > shortly via the IETF's web site. In the meantime, it is available > at the following web/ftp link. As usual, comments are welcome. > > ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces-mpls-mib-00.txt > > --Tom > From owner-mpls@UU.NET Tue Feb 27 19:13:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06424 for ; Tue, 27 Feb 2001 19: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 QQkege04958; Wed, 28 Feb 2001 00:12:42 GMT Received: by mail-control.mail.uu.net id QQkege18776 for mpls-outgoing; Wed, 28 Feb 2001 00:12: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 QQkege18758 for ; Wed, 28 Feb 2001 00:11:52 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 QQkege15004 for ; Wed, 28 Feb 2001 00:10:44 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkege10150 for ; Wed, 28 Feb 2001 00:10:43 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA10060; Tue, 27 Feb 2001 16:07:32 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: References: Date: Tue, 27 Feb 2001 16:05:52 -0800 To: John Drake From: Bora Akyol Subject: RE: Expanded ERO draft Cc: "'Kireeti Kompella'" , akyol@pluris.com, eric.gray@sandburst.com, mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk John Since you commented on this topic would you care to comment on the rest of our draft as well? You can find it as draft-akyol-mpls-exp-ero-00.txt. Regards Bora At 3:05 PM -0800 2/27/01, John Drake wrote: >Based upon e-mail I've seen, I think we've established that it doesn't >provide any additional functionality or utility. There's a colloquial New >England expression that covers this - as useful as teats on a boar. > >-----Original Message----- >From: Kireeti Kompella [mailto:kireeti@juniper.net] >Sent: Tuesday, February 27, 2001 2:24 PM >To: akyol@pluris.com; eric.gray@sandburst.com >Cc: kireeti@juniper.net; mpls@UU.NET; vkompella@JasmineNetworks.com; >yakov@juniper.net >Subject: Re: Expanded ERO draft > > >> Or alternately, one can add the router ID to the unnumbered ERO to >> remove any ambiguities and also simplify fast reroute. > >As Yakov said, no concrete reason for adding the router ID has been >given. However, we've wasted enough time and bandwidth. Let's put >this to vote: > >Who all think that adding a router ID to the unnumbered ERO subobject >would be beneficial? A simple yes, no or don't care, please. > >Kireeti. From owner-mpls@UU.NET Tue Feb 27 19:14:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06462 for ; Tue, 27 Feb 2001 19:14: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 QQkege13900; Wed, 28 Feb 2001 00:13:44 GMT Received: by mail-control.mail.uu.net id QQkege18920 for mpls-outgoing; Wed, 28 Feb 2001 00:13: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 QQkege18891 for ; Wed, 28 Feb 2001 00:12: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 QQkege26843 for ; Wed, 28 Feb 2001 00:10:27 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkege09776 for ; Wed, 28 Feb 2001 00:10:27 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA10294; Tue, 27 Feb 2001 16:10:16 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <200102272224.OAA27375@kummer.juniper.net> References: <200102272224.OAA27375@kummer.juniper.net> Date: Tue, 27 Feb 2001 16:08:39 -0800 To: Kireeti Kompella From: Bora Akyol Subject: Re: Expanded ERO draft Cc: akyol@pluris.com, eric.gray@sandburst.com, mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk You know my answer already, I think adding the router ID simplifies code, and is much clearer. It is 4 bytes. Bora At 2:24 PM -0800 2/27/01, Kireeti Kompella wrote: > > Or alternately, one can add the router ID to the unnumbered ERO to >> remove any ambiguities and also simplify fast reroute. > >As Yakov said, no concrete reason for adding the router ID has been >given. However, we've wasted enough time and bandwidth. Let's put >this to vote: > >Who all think that adding a router ID to the unnumbered ERO subobject >would be beneficial? A simple yes, no or don't care, please. > >Kireeti. From owner-mpls@UU.NET Tue Feb 27 19:33:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07353 for ; Tue, 27 Feb 2001 19:33: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 QQkegg07525; Wed, 28 Feb 2001 00:33:26 GMT Received: by mail-control.mail.uu.net id QQkegg21771 for mpls-outgoing; Wed, 28 Feb 2001 00:32: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 QQkegg21754 for ; Wed, 28 Feb 2001 00:32: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 QQkegg19442 for ; Wed, 28 Feb 2001 00:31:58 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkegg07695 for ; Wed, 28 Feb 2001 00:31:57 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA12478; Tue, 27 Feb 2001 16:31:55 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <0CD7D73C734BD411AEE100B0D0220404DFDDAE@mail1.tellium.com> References: <0CD7D73C734BD411AEE100B0D0220404DFDDAE@mail1.tellium.com> Date: Tue, 27 Feb 2001 16:30:14 -0800 To: Bala Rajagopalan From: Bora Akyol Subject: RE: New Internet Draft on ERO Cc: "'Bora Akyol'" , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 5:41 PM -0500 2/27/01, Bala Rajagopalan wrote: > > >> Think of an unnumbered ERO of the form <1,1,1,1,1,1,1,1> >> >> Now somewhere in the middle, an LSR wants to calculate a fast reroute >> LSP. Normally, one would ask the TE database the simple question of >> avoid my next hop and would give the router ID of the next hop, but >> in this case, first you have to find out who the router at the end of >> the egress interface is. This is not hard, then you need to find out >> who the router that is right after the immediate hop. This second one >> is harder since you have to make a query into the TE database, to >> find that. Then you have to make a third query into TED, to calculate >> an LSP that avoids the immediate next hop but merges as soon as >> possible with the main LSP. And finally, you calculate an ERO that >> now is a mixture of both numbered and unnumbered interfaces possibly >> and initiate signaling. As I describe here, this is not undoable, but >> at what cost. >> >> If one adds the extra four bytes of router ID as part of the ERO (as >> we did in the EERO) this whole thing becomes trivial to implement. >> > >Just curious, to implement this type of fast reroute, can't intermediate >nodes >get downstream information from record route? > >Bala Bala As I wrote in my previous email, there are other ways of getting this info. The point that I was trying to make is that when you add the router ID, things become clearer and simpler. Bora From owner-mpls@UU.NET Tue Feb 27 19:42:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07519 for ; Tue, 27 Feb 2001 19:42: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 QQkegg24894; Wed, 28 Feb 2001 00:42:24 GMT Received: by mail-control.mail.uu.net id QQkegg22571 for mpls-outgoing; Wed, 28 Feb 2001 00:41:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkegg22561 for ; Wed, 28 Feb 2001 00:41:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkegg06845 for ; Wed, 28 Feb 2001 00:40:36 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkegg11018 for ; Wed, 28 Feb 2001 00:40:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA08092 for mpls@uu.net; Tue, 27 Feb 2001 19:40:34 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkegg22407 for ; Wed, 28 Feb 2001 00:40:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkegg20231 for ; Wed, 28 Feb 2001 00:39:49 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 QQkegg09961 for ; Wed, 28 Feb 2001 00:39:49 GMT Received: from mira1.cisco.com (mira1.cisco.com [171.71.208.193]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA20421 for ; Tue, 27 Feb 2001 16:40:06 -0800 (PST) Received: from cisco.com (skatukam-u5.cisco.com [171.71.213.88]) by mira1.cisco.com (Mirapoint) with ESMTP id ACJ17497; Tue, 27 Feb 2001 16:39:47 -0800 (PST) Message-ID: <3A9C48B7.952061DB@cisco.com> Date: Tue, 27 Feb 2001 16:39:19 -0800 From: Suresh Katukam Organization: Cisco Systems X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: OSPF TE Extensions.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am sorry if these things have been already discussed.. Current OSPF-TE extensions do not take care of lot of TDM related issues. Is there a new draft or a work going on this? Shall I go ahead and send the list of issues that need to be covered in this draft? I already talked to Kireeti and Yakov about these earlier. But I have not heard any progress yet. Thanks, Suresh From owner-mpls@UU.NET Tue Feb 27 20:02:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07823 for ; Tue, 27 Feb 2001 20:02: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 QQkegi15403; Wed, 28 Feb 2001 01:01:57 GMT Received: by mail-control.mail.uu.net id QQkegi28535 for mpls-outgoing; Wed, 28 Feb 2001 01:01: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 QQkegi28247 for ; Wed, 28 Feb 2001 01:01:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegi19770 for ; Wed, 28 Feb 2001 01:01:23 GMT Received: from WATERTOWN.litchfieldcomm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 121.125.252.64.snet.net [64.252.125.121]) id QQkegi01291 for ; Wed, 28 Feb 2001 01:01:22 GMT Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Date: Tue, 27 Feb 2001 20:02:02 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC031290@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: draft-danenberg-sonet-ces-mpls-mib-00.txt Thread-Index: AcChIg8psOPb4aQ7Q8elCetOVXk/9w== From: "Dave Danenberg" content-class: urn:content-classes:message To: "Jim Boyle" , "Thomas D. Nadeau" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA07823 Jim, Thanx for your input. It sounds like you'd like to see the same sort of statistical information from the emulated SONET that folks are accustomed to seeing from SONET networking equipment. I like that too (from years of developing telecomm equipment for service providers). Although I was considering second order counts (errored seconds) or trends (15 minute, 24 hour interval data), I decided to start with just simple counts - and see what folks think. Andy's CEM does not detect errors over the CEM payload, but it does detect errors within the CEM header (the CEM MIB counts them with mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps CEM header error rates can be extrapolated to indicate payload errors rates. Due to the nature of CEM, other types of errors are detectable (buffer errors, missing packets, etc). Assuming CEM equipment can process this raw info into some nice statistics, another set of objects can be added to the CEM MIB. So, I'd like to include the type of statistical info you suggest as well as your "reason for last down" idea. Would you like to see interval data as well? What do you think Tom? If you agree, I can come up with another set of objects and send it to Jim (and mpls email) for comment. Dave -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle Sent: Tuesday, February 27, 2001 2:24 PM To: Thomas D. Nadeau Cc: mpls@UU.NET Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt pretend you are a service provider, a customer calls in and says he's seeing errors on his service (in particular, bip violalations in POH). He is directly connected to your network via port A. On the far end, he connects to a clec, which hands it off to you at port Z. He connects to a CLEC adm on port Z'. His path terminating equipment (maybe a router) is port Ac, and Zc, such that the service looks like: Ac-A-[IP]-Z-CLEC-Z'-Zc Looking at lines Ac-A and Z-CLEC shows clean lines. How does the operator determine if his IP network is to blame, or the CLECs network is to blame? i'd recomend a few things: o) Andy's draft should have some sort of way to determine if there are bit errors hapenning across the IP network that affect the service payload. This would provide the same sort of delineation of where a problem is occuring by looking at LOHs in more traditional transport network. o) your mib should include analogues to the SONET mib, such as bip-8 violations, errored seconds, etc... (working off memory here). o) addition of a "reason for last down" might be nice. This way, when you, as the service provider, replies that "it's not our problem, must be the clec", they can say at least go look at it later to see if they were telling the truth. As usual, excellent attention paid to the configuration aspects. regards, Jim On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > Hi, > > FYI a new MIB for managing SONET/SDH Circuit Emulation > Service Over MPLS has been posted. It should be available > shortly via the IETF's web site. In the meantime, it is available > at the following web/ftp link. As usual, comments are welcome. > > ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces- mpls-mib-00.txt > > --Tom > From owner-mpls@UU.NET Tue Feb 27 20:50:00 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08974 for ; Tue, 27 Feb 2001 20:50: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 QQkegl04916; Wed, 28 Feb 2001 01:49:44 GMT Received: by mail-control.mail.uu.net id QQkegl14674 for mpls-outgoing; Wed, 28 Feb 2001 01:49:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkegl14658 for ; Wed, 28 Feb 2001 01:49:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkegl15608 for ; Wed, 28 Feb 2001 01:48:56 GMT Received: from radiant.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQkegl14229 for ; Wed, 28 Feb 2001 01:48:55 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 17:46:49 -0800 Message-ID: From: John Drake To: "'Bora Akyol'" , Bala Rajagopalan Cc: mpls@UU.NET Subject: RE: New Internet Draft on ERO Date: Tue, 27 Feb 2001 17:46:43 -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 Bora, Without trying to be difficult, your response to Bala sounds suspiciously like an assertion. Wouldn't the intermediate node processing, with respect to accesses of the TE database, be the same whether dealing with unnumbered or numbered links? So if we don't need router ID for numbered links, why do we need it for unnumbered links? Thanks, John -----Original Message----- From: Bora Akyol [mailto:akyol@pluris.com] Sent: Tuesday, February 27, 2001 4:30 PM To: Bala Rajagopalan Cc: 'Bora Akyol'; mpls@UU.NET Subject: RE: New Internet Draft on ERO At 5:41 PM -0500 2/27/01, Bala Rajagopalan wrote: > > >> Think of an unnumbered ERO of the form <1,1,1,1,1,1,1,1> >> >> Now somewhere in the middle, an LSR wants to calculate a fast reroute >> LSP. Normally, one would ask the TE database the simple question of >> avoid my next hop and would give the router ID of the next hop, but >> in this case, first you have to find out who the router at the end of >> the egress interface is. This is not hard, then you need to find out >> who the router that is right after the immediate hop. This second one >> is harder since you have to make a query into the TE database, to >> find that. Then you have to make a third query into TED, to calculate >> an LSP that avoids the immediate next hop but merges as soon as >> possible with the main LSP. And finally, you calculate an ERO that >> now is a mixture of both numbered and unnumbered interfaces possibly >> and initiate signaling. As I describe here, this is not undoable, but >> at what cost. >> >> If one adds the extra four bytes of router ID as part of the ERO (as >> we did in the EERO) this whole thing becomes trivial to implement. >> > >Just curious, to implement this type of fast reroute, can't intermediate >nodes >get downstream information from record route? > >Bala Bala As I wrote in my previous email, there are other ways of getting this info. The point that I was trying to make is that when you add the router ID, things become clearer and simpler. Bora From owner-mpls@UU.NET Tue Feb 27 21:20:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09623 for ; Tue, 27 Feb 2001 21:20: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 QQkegn00548; Wed, 28 Feb 2001 02:19:43 GMT Received: by mail-control.mail.uu.net id QQkegn02818 for mpls-outgoing; Wed, 28 Feb 2001 02:19:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkegn02811 for ; Wed, 28 Feb 2001 02:19: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 QQkegn16214 for ; Wed, 28 Feb 2001 02:18:33 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkegn21021 for ; Wed, 28 Feb 2001 02:18:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA14839 for mpls@uu.net; Tue, 27 Feb 2001 21:18:31 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkegn02683 for ; Wed, 28 Feb 2001 02:17:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegn05220 for ; Wed, 28 Feb 2001 02:17: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 QQkegn09007 for ; Wed, 28 Feb 2001 02:17:07 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 VAA07629; Tue, 27 Feb 2001 21:16:31 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAI21799; Tue, 27 Feb 2001 21:17:01 -0500 (EST) Message-Id: <4.3.2.7.2.20010227211833.01b070c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 21:19:55 -0500 To: Jim Boyle From: "Thomas D. Nadeau" Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt Cc: mpls@UU.NET In-Reply-To: References: <4.3.2.7.2.20010223150102.06a62cf8@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 12:24 PM 2/27/2001 -0700, Jim Boyle wrote: >pretend you are a service provider, a customer calls in and says he's >seeing errors on his service (in particular, bip violalations in POH). > >He is directly connected to your network via port A. >On the far end, he connects to a clec, which hands it off to you at port >Z. He connects to a CLEC adm on port Z'. His path terminating equipment >(maybe a router) is port Ac, and Zc, such that the service looks like: > >Ac-A-[IP]-Z-CLEC-Z'-Zc > >Looking at lines Ac-A and Z-CLEC shows clean lines. > >How does the operator determine if his IP network is to blame, or the >CLECs network is to blame? > >i'd recomend a few things: > >o) Andy's draft should have some sort of way to determine if there are bit >errors hapenning across the IP network that affect the service >payload. This would provide the same sort of delineation of where a >problem is occuring by looking at LOHs in more traditional transport >network. > >o) your mib should include analogues to the SONET mib, such as bip-8 >violations, errored seconds, etc... (working off memory here). > >o) addition of a "reason for last down" might be nice. > >This way, when you, as the service provider, replies that "it's not our >problem, must be the clec", they can say at least go look at it later to >see if they were telling the truth. > >As usual, excellent attention paid to the configuration aspects. Jim, these are all good recommendations. I will speak with Andy about these issues and will make the additions you recommend to the MIB after going over them with the other co-authors. Thanks for the input. --Tom >regards, > >Jim > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > Hi, > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > Service Over MPLS has been posted. It should be available > > shortly via the IETF's web site. In the meantime, it is available > > at the following web/ftp link. As usual, comments are welcome. > > > > > ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces-mpls-mib-00.txt > > > > --Tom > > From owner-mpls@UU.NET Tue Feb 27 21:30:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09763 for ; Tue, 27 Feb 2001 21:30: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 QQkego20441; Wed, 28 Feb 2001 02:30:08 GMT Received: by mail-control.mail.uu.net id QQkegn03851 for mpls-outgoing; Wed, 28 Feb 2001 02:29: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 QQkegn03841 for ; Wed, 28 Feb 2001 02:29:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkegn03626 for ; Wed, 28 Feb 2001 02:29:14 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkegn18528 for ; Wed, 28 Feb 2001 02:29:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA16058 for mpls@uu.net; Tue, 27 Feb 2001 21:29:12 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkegn03749 for ; Wed, 28 Feb 2001 02:28:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegn15872 for ; Wed, 28 Feb 2001 02:27: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 QQkegn22327 for ; Wed, 28 Feb 2001 02:27:57 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 VAA07817; Tue, 27 Feb 2001 21:27:21 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAI21973; Tue, 27 Feb 2001 21:27:54 -0500 (EST) Message-Id: <4.3.2.7.2.20010227212334.01b059c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 21:30:41 -0500 To: Jim Boyle , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: comments on draft-dubuc-mpls-bundle-mib-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Martin, good idea, if we're going to start thinking about having link >bundles, we should probably think about mibs to get relevant information >out of network (for nms) or into network (if that is one's manner). > >I do think that this mib reaches too far, and replicates information that >is available elsewhere. > >You mention an example of grouping 3 component links into 1 bundled >link. For some reason you mention 2 primary and 1 secondary, is this 1:N >protection, and if so, is there a relevant APS/Sonet/SDH mib where this >assocation of the secondary to the protected links should be made? > >In general, the mib should be able to grab interfaces and group them >together, however it's my view that these become standard interfaces, seen >in ifTable, in relevant OSPF mibs, TE mibs, etc... The bundled mib keeps >track of the relationship only (e.g. id 10 really is a composite of 1,2,3) > >Why would one want to be able to not only get the OSPF TE metric from the >bundled mib, and from the TEMIB? The reason for not putting this stuff in the MPLS-TE-MIB for example, was because it was seen that information from ISIS, OSPF, SONET, etc... might have to be included too. Doing this in the MPLS-TE MIB (or TE-MIB) would pollute the generic model there. >Anyways, my comment would be that the bundle mib should stick to a core >business, and leverage information that exist (rightfully) in other >places. I think that part of the motivation for putting all of this stuff in one place was to make things easier for those managing the bundles. Having to scramble between many different MIBs to collect the information provided might be cumbersome. Having this MIB essentially "point" at the other ifIndexes involved in the bundle seems to be a more general/flexible approach, although I do see your point in re-using what is already out there. We will go back and examine the other relevant MIBs and see if there is any overlap. --Tom >regards, > >Jim From owner-mpls@UU.NET Tue Feb 27 21:46:00 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10874 for ; Tue, 27 Feb 2001 21:46: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 QQkegp20056; Wed, 28 Feb 2001 02:45:43 GMT Received: by mail-control.mail.uu.net id QQkegp05916 for mpls-outgoing; Wed, 28 Feb 2001 02:45:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkegp05906 for ; Wed, 28 Feb 2001 02:45:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkego09071 for ; Wed, 28 Feb 2001 02:44:39 GMT Received: from NOD.RESTON.MCI.NET by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQkego17977 for ; Wed, 28 Feb 2001 02:44:39 GMT Received: from rbonica ([166.60.18.130]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with SMTP id <01K0MBPOAFTQA23C7A@shoe.reston.mci.net> for mpls@uu.net; Tue, 27 Feb 2001 21:44:38 -0500 (EST) Date: Tue, 27 Feb 2001 21:33:09 -0500 From: Ron Bonica Subject: Tunnel Tracing Drafts 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, Apologies in advance to those of you who are receiving multiple notifications... Two drafts that address tracing routes through generic tunnels are available at the following URLs: http://www.ietf.org/internet-drafts/draft-bonica-tunneltrace-01.txt http://www.ietf.org/internet-drafts/draft-bonica-tunproto-00.txt These drafts will be discussed on the CCAMP mailing list, but are of interest to the MPLS community, because they address tracing through MPLS LSPs as well as other tunnel types. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "Not all who wander are lost." -- J.R.R. Tolkien From owner-mpls@UU.NET Tue Feb 27 22:10:13 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11148 for ; Tue, 27 Feb 2001 22:10: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 QQkefq27792; Tue, 27 Feb 2001 20:31:28 GMT Received: by mail-control.mail.uu.net id QQkefq22333 for mpls-outgoing; Tue, 27 Feb 2001 20:30:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkefq22323 for ; Tue, 27 Feb 2001 20:30:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkefp04063 for ; Tue, 27 Feb 2001 20:29:45 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkefp15361 for ; Tue, 27 Feb 2001 20:29:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA06023 for mpls@uu.net; Tue, 27 Feb 2001 15:29:44 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkefo04158 for ; Tue, 27 Feb 2001 20:01:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkefo14202 for ; Tue, 27 Feb 2001 20:00:39 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkefo22486 for ; Tue, 27 Feb 2001 20:00:38 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA16579; Tue, 27 Feb 2001 12:00:38 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <200102271921.LAA60573@garnet.juniper.net> References: <200102271921.LAA60573@garnet.juniper.net> Date: Tue, 27 Feb 2001 11:59:12 -0800 To: Yakov Rekhter From: Bora Akyol Subject: Re: New Internet Draft on ERO Cc: Bora Akyol , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 11:21 AM -0800 2/27/01, Yakov Rekhter wrote: >Bora, > >> >> My question is as follows: >> >> >> >> How do you do fast reroute when you have unnumbered interfaces in the >> >> ERO as in the unnumbered draft? What out of band information is added >> >> to what's in the ERO when we do CSPF? Is everyone doing it the same >> >> way? >> >> >> >> If we use the (newly defined) EERO then fast reroute is the same for >> >> both numbered and unnumbered interfaces and it actually becomes quite >> >> easy. >> > >> >Could you point me to the MPLS WG document(s) that specifies >> >how to perform fast re-route ? >> > >> >Yakov. >> >> Well, there was the ID from George Swallow that we discussed in San >> Diego. And then there were some discussions on the list that I >> participated in 1998. Vishal Sharma et al, produced IDs on that >> subject as well. >> >> Maybe it is time that we write a BCP on that topic. Would this fall >> into CCAMP or MPLS? In the last IETF, **all** of the fast >> reroute/recovery schemes were sent to CCAMP AFAIK. >> >> I know how we implemented fast reroute and I am sure you know of at >> least two implementations. >> >> So if there is interest on the WG, I can volunteer to put together a >> group of people to write such a BCP. >> >> But my original question still stands, > >Your original question is ambiguous, as it didn't spell out >which *specific* fast reroute scheme is used (and as you indicated >above there is more than one such scheme). > >Also, are you asserting that none of the fast reroute schemes >could work with unnumbered interfaces in the ERO as specified >in the unnumbered draft ? > >Yakov. Yakov What I am asserting is the fact that unnumbered interfaces as specified in the unnumbered draft make calculation of a fast reroute LSP difficult even when you make assumptions about which interface belongs to which router. The specific fast reroute scheme that I had in mind was the one where you calculate a fast reroute LSP that avoids the immediate next hop. Also see the point that Vach made in a separate email. Bora From owner-mpls@UU.NET Tue Feb 27 22:18:32 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11258 for ; Tue, 27 Feb 2001 22:18: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 QQkegr13124; Wed, 28 Feb 2001 03:18:17 GMT Received: by mail-control.mail.uu.net id QQkegr24213 for mpls-outgoing; Wed, 28 Feb 2001 03:17: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 QQkegr24206 for ; Wed, 28 Feb 2001 03:17: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 QQkegr17697 for ; Wed, 28 Feb 2001 03:17:13 GMT Received: from cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQkegr12774 for ; Wed, 28 Feb 2001 03:17:11 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 366; Wed, 28 Feb 2001 11:18:51 +0800 Message-ID: <3A9C6DD6.BE5C770C@cad.zju.edu.cn> Date: Wed, 28 Feb 2001 11:17:42 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Guang Xiaoming , "mpls@UU.NET" Subject: Question on MPLS over native ATM Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi : I met some problem with my work, would you please give me some hints? I'm thinking about connect IP host through ATM by using MPLS, which provide both fast transmission and QoS support to multimedia streams. I can not modify the control plane software installed in ATM switch, so I have to use MPLS on end host while native ATM in that switch. Is there any possiblity to integrate MPLS and ATM in a layered model ? IP --- MPLS -- ATM---------ATM --- MPLS--IP ^ ^ ^ | | | MPLS over Native MPLS over ATM ATM ATM Is there any draft on this topic ? or any person has implement a solution? Thanks a lot. Shen From owner-mpls@UU.NET Tue Feb 27 22:46:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12550 for ; Tue, 27 Feb 2001 22:46: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 QQkegt18361; Wed, 28 Feb 2001 03:46:07 GMT Received: by mail-control.mail.uu.net id QQkegt27035 for mpls-outgoing; Wed, 28 Feb 2001 03:45: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 QQkegt27025 for ; Wed, 28 Feb 2001 03:45: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 QQkegs11506 for ; Wed, 28 Feb 2001 03:44:29 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 QQkegs29099 for ; Wed, 28 Feb 2001 03:44:28 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA00642; Tue, 27 Feb 2001 19:44:23 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 19:44:23 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA094506@avalon.pluris.com> From: Puneet Agarwal To: "'Eric Gray'" Cc: "'Shahram Davari'" , "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Tue, 27 Feb 2001 19:44:22 -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 Eric, From the perspective of the LSR in question, the case you described would be equivalent to a PHP (as you suspected) and not an "Egress Pop". The ttl processing for the PHP case would apply. My conceptual model of "Egress Pop" has been that it is performed by the egress LSR to exit the encapsulating tunnel and the exposed packet is then routed. If you route on a label and then pop, then you are essentially performing a PHP (from the perspective of the data path) and not an Egress Pop. Hope this helps. -Puneet >-----Original Message----- >From: Eric Gray [mailto:eric.gray@sandburst.com] >Sent: Tuesday, February 27, 2001 12:33 PM >To: Puneet Agarwal >Cc: 'Shahram Davari'; 'mpls@uu.net'; 'flefauch@cisco.com'; >'liwwu@cisco.com'; 'bsd@cisco.com'; Bora Akyol >Subject: Re: New TTL Draft > > >Puneet, > > I am somewhat confused by this reply - especially in the >context provided by the enclosed discussion. > > It is certainly possible to perform an egress pop of a >label. I believed that to be what you were saying earlier. >Yet this is exactly the same thing as what you are saying >you would never do below. > > For example, if I am providing a port-based VPN service >using MPLS, it is very likely that I will use MPLS labels to >get packets to the egress port. Now suppose (as is likely >to be true at least sometimes) that the next router beyond >the service provider router is not an LSR (even of the >stripped down version that can only give implicit NULL >labels). Then the packets that the egress LSR forwards >to this next hop must be IP packets - so the label used to >get the packets to the egress port of the egress LSR must >be popped after they are used to route the packets to the >egress port. > > From the forwarding engine's point of view, this is exactly >the same behavior as you would get using PHP. The question >seems to be, would the behavior with respect to TTL defined >for PHP also apply in this case? > >-- >Eric Gray > >You wrote: > >> Hi Shahram, >> >> Based on the tunnel mode definitions in the -07 version of >mpls-diff draft, >> the oTTL determination is not needed explicitly for the >"Pop" case. After >> you perform "Pop" (recursively), you need to route >(determine the egress >> interface etc) the exposed header (IP packet or label). You >never "Pop" the >> label you route on - you can only SWAP, SWAP+Push or PHP >(+Push) the label. >> >> Hence I never added the bullet for "Pop" when determining >oTTL as it is not >> a legal operation. If you want, I can add text in section >2.4 of the draft >> that a "Pop" is not a legal operation for a label we route >on. Would that >> help? >> >> Hope this clarifies. >> >> -Puneet >> >> >-----Original Message----- >> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >Sent: Tuesday, February 27, 2001 11:19 AM >> >To: 'Puneet Agarwal'; 'Eric Gray' >> >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >> >'bsd@cisco.com'; Bora Akyol >> >Subject: RE: New TTL Draft >> > >> > >> >Hi Puneet, >> > >> >Thanks for your reply. Please see my comments in-line: >> > >> >> >2) Section 2.4 does not discuss an important case that is: >> >> >egress processing of tunnels, i.e. pop and forwarding the >> >> >packet as MPLS. >> >> >> >> Pop (or Egress Pop to distinguish from PHP) is actually >> >> covered in section >> >> 2.3. The possibly operation when forwarding the packet as >> >> MPLS are covered >> >> in the 3 bullets of section 2.4. Combine section 2.3 and >> >the relevant >> >> section of 2.4 and I think your concern about the missing >> >> case should be >> >> answered. Hence as far as I can see the case is convered, but >> >> please let me >> >> know if you still think that it is not addressed. >> >> > >> > >> >As you know there are at least 2 distinct operations that are needed >> >for TTL processing: >> > >> >1) Determining iTTL >> >2) Determining oTTL >> > >> >Section 2.3 describes the iTTL determination for both PHP and >> >non-PHP case. >> >Section 2.4 however describes the oTTL determination for PHP >> >case only. I >> >can't see anywhere in the draft that talks about oTTL >> >determination for non-PHP >> >case. Do you see any? >> > >> > >> >Yours, >> >Shahram >> > > From owner-mpls@UU.NET Tue Feb 27 22:48:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12578 for ; Tue, 27 Feb 2001 22:48: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 QQkegt03896; Wed, 28 Feb 2001 03:48:12 GMT Received: by mail-control.mail.uu.net id QQkegt27360 for mpls-outgoing; Wed, 28 Feb 2001 03:47:30 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 QQkegt27344 for ; Wed, 28 Feb 2001 03:47:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkegt02747 for ; Wed, 28 Feb 2001 03:46:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkegt06212 for ; Wed, 28 Feb 2001 03:46:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA20989 for mpls@uu.net; Tue, 27 Feb 2001 22:46:56 -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 QQkegt27135 for ; Wed, 28 Feb 2001 03:46:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegt29778 for ; Wed, 28 Feb 2001 03:46:02 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 QQkegt00981 for ; Wed, 28 Feb 2001 03:46:01 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 WAA09094; Tue, 27 Feb 2001 22:45:25 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAI23145; Tue, 27 Feb 2001 22:45:57 -0500 (EST) Message-Id: <4.3.2.7.2.20010227224821.01d79c80@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 22:48:52 -0500 To: "Dave Danenberg" , "Jim Boyle" From: "Thomas D. Nadeau" Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Cc: In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC031290@WATERTOWN.litchfiel dcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote: >Jim, > >Thanx for your input. It sounds like you'd like to see the same sort of >statistical information from the emulated SONET that folks are >accustomed to seeing from SONET networking equipment. I like that too >(from years of developing telecomm equipment for service providers). > >Although I was considering second order counts (errored seconds) or >trends (15 minute, 24 hour interval data), I decided to start with just >simple counts - and see what folks think. > >Andy's CEM does not detect errors over the CEM payload, but it does >detect errors within the CEM header (the CEM MIB counts them with >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps >CEM header error rates can be extrapolated to indicate payload errors >rates. Due to the nature of CEM, other types of errors are detectable >(buffer errors, missing packets, etc). Assuming CEM equipment can >process this raw info into some nice statistics, another set of objects >can be added to the CEM MIB. > >So, I'd like to include the type of statistical info you suggest as well >as your "reason for last down" idea. Would you like to see interval data >as well? > >What do you think Tom? If you agree, I can come up with another set of >objects and send it to Jim (and mpls email) for comment. Yes, as I mentioned earlier, I think these things are a good idea. Lets work on them and get our ideas back out to the list shortly. --Tom >Dave > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle >Sent: Tuesday, February 27, 2001 2:24 PM >To: Thomas D. Nadeau >Cc: mpls@UU.NET >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > >pretend you are a service provider, a customer calls in and says he's >seeing errors on his service (in particular, bip violalations in POH). > >He is directly connected to your network via port A. >On the far end, he connects to a clec, which hands it off to you at port >Z. He connects to a CLEC adm on port Z'. His path terminating >equipment >(maybe a router) is port Ac, and Zc, such that the service looks like: > >Ac-A-[IP]-Z-CLEC-Z'-Zc > >Looking at lines Ac-A and Z-CLEC shows clean lines. > >How does the operator determine if his IP network is to blame, or the >CLECs network is to blame? > >i'd recomend a few things: > >o) Andy's draft should have some sort of way to determine if there are >bit >errors hapenning across the IP network that affect the service >payload. This would provide the same sort of delineation of where a >problem is occuring by looking at LOHs in more traditional transport >network. > >o) your mib should include analogues to the SONET mib, such as bip-8 >violations, errored seconds, etc... (working off memory here). > >o) addition of a "reason for last down" might be nice. > >This way, when you, as the service provider, replies that "it's not our >problem, must be the clec", they can say at least go look at it later to >see if they were telling the truth. > >As usual, excellent attention paid to the configuration aspects. > >regards, > >Jim > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > Hi, > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > Service Over MPLS has been posted. It should be available > > shortly via the IETF's web site. In the meantime, it is available > > at the following web/ftp link. As usual, comments are welcome. > > > > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces- >mpls-mib-00.txt > > > > --Tom > > From owner-mpls@UU.NET Tue Feb 27 23:04:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12640 for ; Tue, 27 Feb 2001 23:04: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 QQkegu07896; Wed, 28 Feb 2001 04:03:53 GMT Received: by mail-control.mail.uu.net id QQkegu07088 for mpls-outgoing; Wed, 28 Feb 2001 04:03:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkegu07070 for ; Wed, 28 Feb 2001 04:03:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegu10424 for ; Wed, 28 Feb 2001 04:03:09 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 QQkegu22579 for ; Wed, 28 Feb 2001 04:03:08 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA02426; Tue, 27 Feb 2001 20:03:03 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id UAA19692; Tue, 27 Feb 2001 20:03:03 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Tue, 27 Feb 2001 20:03:03 -0800 (PST) From: Bora Akyol To: Puneet Agarwal cc: "'Eric Gray'" , "'Shahram Davari'" , "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" Subject: RE: New TTL Draft In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA094506@avalon.pluris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Another way to look at this to treat egress pop as a tunnel termination. Bora On Tue, 27 Feb 2001, Puneet Agarwal wrote: > Eric, > > From the perspective of the LSR in question, the case you described > would be equivalent to a PHP (as you suspected) and not an "Egress Pop". > The ttl processing for the PHP case would apply. > > My conceptual model of "Egress Pop" has been that it is performed by the > egress LSR to exit the encapsulating tunnel and the exposed packet is > then routed. If you route on a label and then pop, then you are > essentially performing a PHP (from the perspective of the data path) and > not an Egress Pop. > > Hope this helps. > > -Puneet > > >-----Original Message----- > >From: Eric Gray [mailto:eric.gray@sandburst.com] > >Sent: Tuesday, February 27, 2001 12:33 PM > >To: Puneet Agarwal > >Cc: 'Shahram Davari'; 'mpls@uu.net'; 'flefauch@cisco.com'; > >'liwwu@cisco.com'; 'bsd@cisco.com'; Bora Akyol > >Subject: Re: New TTL Draft > > > > > >Puneet, > > > > I am somewhat confused by this reply - especially in the > >context provided by the enclosed discussion. > > > > It is certainly possible to perform an egress pop of a > >label. I believed that to be what you were saying earlier. > >Yet this is exactly the same thing as what you are saying > >you would never do below. > > > > For example, if I am providing a port-based VPN service > >using MPLS, it is very likely that I will use MPLS labels to > >get packets to the egress port. Now suppose (as is likely > >to be true at least sometimes) that the next router beyond > >the service provider router is not an LSR (even of the > >stripped down version that can only give implicit NULL > >labels). Then the packets that the egress LSR forwards > >to this next hop must be IP packets - so the label used to > >get the packets to the egress port of the egress LSR must > >be popped after they are used to route the packets to the > >egress port. > > > > From the forwarding engine's point of view, this is exactly > >the same behavior as you would get using PHP. The question > >seems to be, would the behavior with respect to TTL defined > >for PHP also apply in this case? > > > >-- > >Eric Gray > > > >You wrote: > > > >> Hi Shahram, > >> > >> Based on the tunnel mode definitions in the -07 version of > >mpls-diff draft, > >> the oTTL determination is not needed explicitly for the > >"Pop" case. After > >> you perform "Pop" (recursively), you need to route > >(determine the egress > >> interface etc) the exposed header (IP packet or label). You > >never "Pop" the > >> label you route on - you can only SWAP, SWAP+Push or PHP > >(+Push) the label. > >> > >> Hence I never added the bullet for "Pop" when determining > >oTTL as it is not > >> a legal operation. If you want, I can add text in section > >2.4 of the draft > >> that a "Pop" is not a legal operation for a label we route > >on. Would that > >> help? > >> > >> Hope this clarifies. > >> > >> -Puneet > >> > >> >-----Original Message----- > >> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> >Sent: Tuesday, February 27, 2001 11:19 AM > >> >To: 'Puneet Agarwal'; 'Eric Gray' > >> >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > >> >'bsd@cisco.com'; Bora Akyol > >> >Subject: RE: New TTL Draft > >> > > >> > > >> >Hi Puneet, > >> > > >> >Thanks for your reply. Please see my comments in-line: > >> > > >> >> >2) Section 2.4 does not discuss an important case that is: > >> >> >egress processing of tunnels, i.e. pop and forwarding the > >> >> >packet as MPLS. > >> >> > >> >> Pop (or Egress Pop to distinguish from PHP) is actually > >> >> covered in section > >> >> 2.3. The possibly operation when forwarding the packet as > >> >> MPLS are covered > >> >> in the 3 bullets of section 2.4. Combine section 2.3 and > >> >the relevant > >> >> section of 2.4 and I think your concern about the missing > >> >> case should be > >> >> answered. Hence as far as I can see the case is convered, but > >> >> please let me > >> >> know if you still think that it is not addressed. > >> >> > > >> > > >> >As you know there are at least 2 distinct operations that are needed > >> >for TTL processing: > >> > > >> >1) Determining iTTL > >> >2) Determining oTTL > >> > > >> >Section 2.3 describes the iTTL determination for both PHP and > >> >non-PHP case. > >> >Section 2.4 however describes the oTTL determination for PHP > >> >case only. I > >> >can't see anywhere in the draft that talks about oTTL > >> >determination for non-PHP > >> >case. Do you see any? > >> > > >> > > >> >Yours, > >> >Shahram > >> > > > > From owner-mpls@UU.NET Tue Feb 27 23:11:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12671 for ; Tue, 27 Feb 2001 23:11: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 QQkegu06124; Wed, 28 Feb 2001 04:11:34 GMT Received: by mail-control.mail.uu.net id QQkegu14862 for mpls-outgoing; Wed, 28 Feb 2001 04:11:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkegu14825 for ; Wed, 28 Feb 2001 04:11:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegu28385 for ; Wed, 28 Feb 2001 04:10:51 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 QQkegu04772 for ; Wed, 28 Feb 2001 04:10:50 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA03054; Tue, 27 Feb 2001 20:10:45 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 20:10:45 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA094507@avalon.pluris.com> From: Puneet Agarwal To: "'Shahram Davari'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Tue, 27 Feb 2001 20:10:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, As I had briefly mentioned in reply to Eric's earlier email on the Pop issue, we do not perform a "Route and a Pop" - that is actually treated as a "Route and a PHP". To quote from our ttl draft section 2.4: "For packets that are routed as MPLS, we have three cases" the semantics of "routed as MPLS" implies that any egress Pops have already been performed. If you think that this was unclear in the draft then I will clarify it. Some more comments inline. -Puneet >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Tuesday, February 27, 2001 12:59 PM >To: 'Puneet Agarwal'; 'Eric Gray' >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >'bsd@cisco.com'; Bora Akyol >Subject: RE: New TTL Draft > > >Hi Puneet, > >I can't follow your reasoning. Let me explain what I am trying to say: > >If an egress router is the terminating point of a pipe/uniform >tunnel, then the egress router must pop the top label and >forward the packet using the label (or IP header) that is >beneath the popped label. My question is: What TTL is encoded >in the forwarding label (or IP header). The answer is: oTTL, >which is equal to oTTL= iTTL-1, in which iTTL determination >depends on the tunnel model and is described in section 2.3. > >So my suggestion is to add another bullet (say bullet 4) to >section 2.4, that says: > >4) Pop : This is the terminating point of an LSP tunnel, in >which, first the top label is popped and then the packet is >forwarded based on the lower label (or exposed IP header). The >TTL of the forwarding label (or IP header) is set to: > >oTTL = iTTL-1 > >in which, iTTL is determined based on the type of tunnel >(i.e., uniform/pipe) as explained in section 2.3. I would be happy to include the text with a few modifications: 4) Pop : This is the terminating point of an LSP tunnel, in which, first the top label is popped and then the packet is forwarded based on the lower label (or exposed IP header). Note that this operation can occur recursively. The iTTL is updated as explained in section 2.3. The outgoing TTL would be determined by the last non "Pop" operation performed on the packet. Would such a text address your concerns? -Puneet > > >Yours, >-Shahram > >> -----Original Message----- >> From: Puneet Agarwal [mailto:puneet@pluris.com] >> Sent: Tuesday, February 27, 2001 3:09 PM >> To: Shahram Davari; 'Eric Gray' >> Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >> 'bsd@cisco.com'; Bora Akyol >> Subject: RE: New TTL Draft >> >> >> Hi Shahram, >> >> Based on the tunnel mode definitions in the -07 version of >> mpls-diff draft, >> the oTTL determination is not needed explicitly for the "Pop" >> case. After >> you perform "Pop" (recursively), you need to route (determine >> the egress >> interface etc) the exposed header (IP packet or label). You >> never "Pop" the >> label you route on - you can only SWAP, SWAP+Push or PHP >> (+Push) the label. >> >> Hence I never added the bullet for "Pop" when determining >> oTTL as it is not >> a legal operation. If you want, I can add text in section 2.4 >> of the draft >> that a "Pop" is not a legal operation for a label we route >> on. Would that >> help? >> >> Hope this clarifies. >> >> -Puneet >> >> >-----Original Message----- >> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >Sent: Tuesday, February 27, 2001 11:19 AM >> >To: 'Puneet Agarwal'; 'Eric Gray' >> >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >> >'bsd@cisco.com'; Bora Akyol >> >Subject: RE: New TTL Draft >> > >> > >> >Hi Puneet, >> > >> >Thanks for your reply. Please see my comments in-line: >> > >> >> >2) Section 2.4 does not discuss an important case that is: >> >> >egress processing of tunnels, i.e. pop and forwarding the >> >> >packet as MPLS. >> >> >> >> Pop (or Egress Pop to distinguish from PHP) is actually >> >> covered in section >> >> 2.3. The possibly operation when forwarding the packet as >> >> MPLS are covered >> >> in the 3 bullets of section 2.4. Combine section 2.3 and >> >the relevant >> >> section of 2.4 and I think your concern about the missing >> >> case should be >> >> answered. Hence as far as I can see the case is convered, but >> >> please let me >> >> know if you still think that it is not addressed. >> >> > >> > >> >As you know there are at least 2 distinct operations that >are needed >> >for TTL processing: >> > >> >1) Determining iTTL >> >2) Determining oTTL >> > >> >Section 2.3 describes the iTTL determination for both PHP and >> >non-PHP case. >> >Section 2.4 however describes the oTTL determination for PHP >> >case only. I >> >can't see anywhere in the draft that talks about oTTL >> >determination for non-PHP >> >case. Do you see any? >> > >> > >> >Yours, >> >Shahram >> > >> > From owner-mpls@UU.NET Wed Feb 28 00:31:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13861 for ; Wed, 28 Feb 2001 00:31: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 QQkeha27376; Wed, 28 Feb 2001 05:31:17 GMT Received: by mail-control.mail.uu.net id QQkeha07754 for mpls-outgoing; Wed, 28 Feb 2001 05:30: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 QQkeha07737 for ; Wed, 28 Feb 2001 05:30: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 QQkeha07100 for ; Wed, 28 Feb 2001 05:30:33 GMT Received: from hclhprnd.hclt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkeha03554 for ; Wed, 28 Feb 2001 05:30:30 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id LAA30057 for ; Wed, 28 Feb 2001 11:24:55 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FT5A2SQQ; Wed, 28 Feb 2001 11:00:11 +0530 Message-ID: <000b01c0a147$a50b6030$6ee8a8c0@hclt.com> From: "Mallikarjun MLR" To: Subject: How to map LDP sessions to FTN table? Date: Wed, 28 Feb 2001 11:00:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The LDP MIB specifies tables for mapping LDP sessions to InSegment Entries, OutSegment Entries and Cross-Connect Entries. Should there be a table for mapping originating LDP LSPs (the LSR is the Ingress LSR for the LSP) to entries in the FTN Table and FTN map Table? Or do FTN table and FTN Map table contain only user-configured entries? Thanks, Mallikarjun From owner-mpls@UU.NET Wed Feb 28 03:07:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29824 for ; Wed, 28 Feb 2001 03:07: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 QQkehg13897; Wed, 28 Feb 2001 07:13:27 GMT Received: by mail-control.mail.uu.net id QQkehg17982 for mpls-outgoing; Wed, 28 Feb 2001 07:13:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkehg17975 for ; Wed, 28 Feb 2001 07:12:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkehg26095 for ; Wed, 28 Feb 2001 07:12:38 GMT Received: from mxtlv1.corrigent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.203.64.34]) id QQkehg12829 for ; Wed, 28 Feb 2001 07:12:36 GMT Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 09:10:54 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B353370317@mxtlv1.corrigent.com> From: David Zelig To: "'Thomas D. Nadeau'" , Dave Danenberg , Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Date: Wed, 28 Feb 2001 09:10:48 +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 Tom, Dave and Jim, In order to detect payload defects at the STS level there are BIP checking on the path overhead. If an operator want to check errors generated by the CEM operation it may be simpler (and more understood) to monitor the B3 byte for errors in both ends of the tunnel. This can be done on the example below on the interface on the IP edge device. It is very hard to manipulate CEM errors to payload errors, and if the customer bought SONET service (and sign on SONET SLA) the PM should be on SONET "language" and measured at the SONET level. Sure we must cover all potential CEM errors in order to enable detecting the cause of the errors, especially for the case of problems caused by mis-configuration.I think that we need to deliver interval data for all PM related errors, and for events count. David -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, February 28, 2001 5:49 AM To: Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote: >Jim, > >Thanx for your input. It sounds like you'd like to see the same sort of >statistical information from the emulated SONET that folks are >accustomed to seeing from SONET networking equipment. I like that too >(from years of developing telecomm equipment for service providers). > >Although I was considering second order counts (errored seconds) or >trends (15 minute, 24 hour interval data), I decided to start with just >simple counts - and see what folks think. > >Andy's CEM does not detect errors over the CEM payload, but it does >detect errors within the CEM header (the CEM MIB counts them with >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps >CEM header error rates can be extrapolated to indicate payload errors >rates. Due to the nature of CEM, other types of errors are detectable >(buffer errors, missing packets, etc). Assuming CEM equipment can >process this raw info into some nice statistics, another set of objects >can be added to the CEM MIB. > >So, I'd like to include the type of statistical info you suggest as well >as your "reason for last down" idea. Would you like to see interval data >as well? > >What do you think Tom? If you agree, I can come up with another set of >objects and send it to Jim (and mpls email) for comment. Yes, as I mentioned earlier, I think these things are a good idea. Lets work on them and get our ideas back out to the list shortly. --Tom >Dave > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle >Sent: Tuesday, February 27, 2001 2:24 PM >To: Thomas D. Nadeau >Cc: mpls@UU.NET >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > >pretend you are a service provider, a customer calls in and says he's >seeing errors on his service (in particular, bip violalations in POH). > >He is directly connected to your network via port A. >On the far end, he connects to a clec, which hands it off to you at port >Z. He connects to a CLEC adm on port Z'. His path terminating >equipment >(maybe a router) is port Ac, and Zc, such that the service looks like: > >Ac-A-[IP]-Z-CLEC-Z'-Zc > >Looking at lines Ac-A and Z-CLEC shows clean lines. > >How does the operator determine if his IP network is to blame, or the >CLECs network is to blame? > >i'd recomend a few things: > >o) Andy's draft should have some sort of way to determine if there are >bit >errors hapenning across the IP network that affect the service >payload. This would provide the same sort of delineation of where a >problem is occuring by looking at LOHs in more traditional transport >network. > >o) your mib should include analogues to the SONET mib, such as bip-8 >violations, errored seconds, etc... (working off memory here). > >o) addition of a "reason for last down" might be nice. > >This way, when you, as the service provider, replies that "it's not our >problem, must be the clec", they can say at least go look at it later to >see if they were telling the truth. > >As usual, excellent attention paid to the configuration aspects. > >regards, > >Jim > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > Hi, > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > Service Over MPLS has been posted. It should be available > > shortly via the IETF's web site. In the meantime, it is available > > at the following web/ftp link. As usual, comments are welcome. > > > > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces- >mpls-mib-00.txt > > > > --Tom > > From owner-mpls@UU.NET Wed Feb 28 07:02:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03475 for ; Wed, 28 Feb 2001 07:02: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 QQkeia03007; Wed, 28 Feb 2001 12:01:01 GMT Received: by mail-control.mail.uu.net id QQkeia19038 for mpls-outgoing; Wed, 28 Feb 2001 12:00:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeia18504 for ; Wed, 28 Feb 2001 12:00:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkehz29520 for ; Wed, 28 Feb 2001 11:59:55 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkehz25119 for ; Wed, 28 Feb 2001 11:59:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA16820 for mpls@uu.net; Wed, 28 Feb 2001 06:59:53 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkehz16683 for ; Wed, 28 Feb 2001 11:59:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkehz27487 for ; Wed, 28 Feb 2001 11:59:02 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 QQkehz00142 for ; Wed, 28 Feb 2001 11:59:01 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03048; Wed, 28 Feb 2001 06:59:02 -0500 (EST) Message-Id: <200102281159.GAA03048@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-lsp-tunnel-08.txt Date: Wed, 28 Feb 2001 06:59:01 -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 : RSVP-TE: Extensions to RSVP for LSP Tunnels Author(s) : D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow Filename : draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Pages : 61 Date : 27-Feb-01 This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-lsp-tunnel-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227124055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-lsp-tunnel-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227124055.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Feb 28 08:13:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04963 for ; Wed, 28 Feb 2001 08:13: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 QQkeie10452; Wed, 28 Feb 2001 13:13:20 GMT Received: by mail-control.mail.uu.net id QQkeie23466 for mpls-outgoing; Wed, 28 Feb 2001 13:12: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 QQkeie23460 for ; Wed, 28 Feb 2001 13:12: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 QQkeie17574 for ; Wed, 28 Feb 2001 13:12:26 GMT Received: from satoru.prism by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.128.193]) id QQkeie06933 for ; Wed, 28 Feb 2001 13:12:25 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.1/8.11.1) with ESMTP id f1SCtqj01028; Wed, 28 Feb 2001 21:55:53 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: Shahram_Davari@pmc-sierra.com Cc: puneet@pluris.com, eric.gray@sandburst.com, mpls@UU.NET, flefauch@cisco.com, liwwu@cisco.com, bsd@cisco.com, akyol@pluris.com Subject: RE: New TTL Draft In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB0@BBY1EXM01> References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB0@BBY1EXM01> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010228215552Z.satoru@japan-telecom.co.jp> Date: Wed, 28 Feb 2001 21:55:52 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 181 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, This is Satoru Matsushima. > Hi All, > > Interestingly a similar draft was posted today: > > http://www.ietf.org/internet-drafts/draft-satoru-mpls-1hop-lsp-00.txt Thanks,:-) Actually, this draft consist of three elements: - TTL Processing expansion. - Label distribution method for 1-hop LSP. - The possible to "LSP KeepAlive" using 1-hop LSP. So, this draft was not only TTL processing, and it was stated about for using 1-hop LSP. Because, I had to describe these elements when I tried to write about realizing 1-hop LSP in this draft. I think Puneet's draft(and after discussion in ML) described very well TTL procesing for hierarchical LSP, but the 1-hop LSP(Pipe model LSP) is not a thing only for Diff-Serv. It is very usefull for MPLS/VPN operators. (I'm a MPLS/VPN operator.;-) Therefore, I think TTL processing expansion should be described more generally and be careful in label distribution mode; DU or DoD. (we call "Cloud model" and "Per LSP model") "LSP KeepAlive" ability is extremely important for the applications which use LSP but cannnot know the state of LSP itself(for instance, BGP/MPLS VPNs). I described a method of "LSP KeepAlive" using 1-hop LSP in this draft. How do you think about this? regards, -- Satoru Matsushima From: Shahram Davari Subject: RE: New TTL Draft Date: Tue, 27 Feb 2001 13:16:13 -0800 > Hi All, > > Interestingly a similar draft was posted today: > > http://www.ietf.org/internet-drafts/draft-satoru-mpls-1hop-lsp-00.txt > > Yours, > -Shahram > > > -----Original Message----- > > From: Shahram Davari > > Sent: Tuesday, February 27, 2001 3:59 PM > > To: 'Puneet Agarwal'; 'Eric Gray' > > Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > > 'bsd@cisco.com'; Bora Akyol > > Subject: RE: New TTL Draft > > > > > > Hi Puneet, > > > > I can't follow your reasoning. Let me explain what I am trying to say: > > > > If an egress router is the terminating point of a > > pipe/uniform tunnel, then the egress router must pop the top > > label and forward the packet using the label (or IP header) > > that is beneath the popped label. My question is: What TTL is > > encoded in the forwarding label (or IP header). The answer > > is: oTTL, which is equal to oTTL= iTTL-1, in which iTTL > > determination depends on the tunnel model and is described in > > section 2.3. > > > > So my suggestion is to add another bullet (say bullet 4) to > > section 2.4, that says: > > > > 4) Pop : This is the terminating point of an LSP tunnel, in > > which, first the top label is popped and then the packet is > > forwarded based on the lower label (or exposed IP header). > > The TTL of the forwarding label (or IP header) is set to: > > > > oTTL = iTTL-1 > > > > in which, iTTL is determined based on the type of tunnel > > (i.e., uniform/pipe) as explained in section 2.3. > > > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: Puneet Agarwal [mailto:puneet@pluris.com] > > > Sent: Tuesday, February 27, 2001 3:09 PM > > > To: Shahram Davari; 'Eric Gray' > > > Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > > > 'bsd@cisco.com'; Bora Akyol > > > Subject: RE: New TTL Draft > > > > > > > > > Hi Shahram, > > > > > > Based on the tunnel mode definitions in the -07 version of > > > mpls-diff draft, > > > the oTTL determination is not needed explicitly for the "Pop" > > > case. After > > > you perform "Pop" (recursively), you need to route (determine > > > the egress > > > interface etc) the exposed header (IP packet or label). You > > > never "Pop" the > > > label you route on - you can only SWAP, SWAP+Push or PHP > > > (+Push) the label. > > > > > > Hence I never added the bullet for "Pop" when determining > > > oTTL as it is not > > > a legal operation. If you want, I can add text in section 2.4 > > > of the draft > > > that a "Pop" is not a legal operation for a label we route > > > on. Would that > > > help? > > > > > > Hope this clarifies. > > > > > > -Puneet > > > > > > >-----Original Message----- > > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > >Sent: Tuesday, February 27, 2001 11:19 AM > > > >To: 'Puneet Agarwal'; 'Eric Gray' > > > >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; > > > >'bsd@cisco.com'; Bora Akyol > > > >Subject: RE: New TTL Draft > > > > > > > > > > > >Hi Puneet, > > > > > > > >Thanks for your reply. Please see my comments in-line: > > > > > > > >> >2) Section 2.4 does not discuss an important case that is: > > > >> >egress processing of tunnels, i.e. pop and forwarding the > > > >> >packet as MPLS. > > > >> > > > >> Pop (or Egress Pop to distinguish from PHP) is actually > > > >> covered in section > > > >> 2.3. The possibly operation when forwarding the packet as > > > >> MPLS are covered > > > >> in the 3 bullets of section 2.4. Combine section 2.3 and > > > >the relevant > > > >> section of 2.4 and I think your concern about the missing > > > >> case should be > > > >> answered. Hence as far as I can see the case is convered, but > > > >> please let me > > > >> know if you still think that it is not addressed. > > > >> > > > > > > > > >As you know there are at least 2 distinct operations that > > are needed > > > >for TTL processing: > > > > > > > >1) Determining iTTL > > > >2) Determining oTTL > > > > > > > >Section 2.3 describes the iTTL determination for both PHP and > > > >non-PHP case. > > > >Section 2.4 however describes the oTTL determination for PHP > > > >case only. I > > > >can't see anywhere in the draft that talks about oTTL > > > >determination for non-PHP > > > >case. Do you see any? > > > > > > > > > > > >Yours, > > > >Shahram > > > > > > > > > > > From owner-mpls@UU.NET Wed Feb 28 08:14:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04974 for ; Wed, 28 Feb 2001 08:14: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 QQkeid01234; Wed, 28 Feb 2001 12:48:27 GMT Received: by mail-control.mail.uu.net id QQkeid06329 for mpls-outgoing; Wed, 28 Feb 2001 12:48:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeid06322 for ; Wed, 28 Feb 2001 12:48:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeid08141 for ; Wed, 28 Feb 2001 12:46:41 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 QQkeid05546 for ; Wed, 28 Feb 2001 12:46:40 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Wed, 28 Feb 2001 12:44:58 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <1TTHK8V4>; Wed, 28 Feb 2001 12:46:20 -0000 Message-ID: To: kireeti@juniper.net, akyol@pluris.com, eric.gray@sandburst.com Cc: mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Subject: RE: Expanded ERO draft Date: Wed, 28 Feb 2001 12:46:10 -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 Kireeti Kompella [mailto:kireeti@juniper.net] asked on 27 February 2001 22:24 > Who all think that adding a router ID to the unnumbered ERO subobject > would be beneficial? A simple yes, no or don't care, please. I don't think a simple Y/N/DC vote is good enough....the vote has to be supported by rationale. Having carefully followed the discussion I come to the conclusion that (i) there appear to be some advantages to doing what Bora et al are advocating, and (ii) there are no technical disadvantages (or at least none have been stated that I can see....other than a clear reluctance from a few parties to accept a change, which is fair enough if there are serious backwards compatibility issues). Having said that..... I think the biggest advantage is *clarity* of nodal identifier and interface. I am reluctant to buy too hard into the fast-reroute arguments since: - it will not cater for all possible failure modes (but only, I assume , below MPLS-layer failures, eg SDH) - since an intermediate LSR in a LSP is *not* a trail termination point there are some defect handling issues that are not being considered, eg there should be a FDI from the failed LSP segment which gets merged with the 'new' (rerouted) LSP segment.....and since the CV flow will split (at point where new reroute starts) to take the new rerouted segment then (ideally) the FDI should be suppressed from the failed segment at the downstream merge point. The above can be circumvented by always establishing a completely new server-layer LSP between the nodes where one wants to establish a prot-route....and this would have its own CV flow, disjoint from the (protected) segment of the client LSP. So, in conclusion: - do it for clarity *and* if true technical benefits result - don't do it if any backwards compatibility is evident and there are no strong benefits....so are any backwards compatibility problems? - don't do it for fast-rereoute reasons since (IMO) such a device appears to be architecturally flawed. neil From owner-mpls@UU.NET Wed Feb 28 08:45:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05733 for ; Wed, 28 Feb 2001 08:45: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 QQkeig22019; Wed, 28 Feb 2001 13:44:30 GMT Received: by mail-control.mail.uu.net id QQkeig28257 for mpls-outgoing; Wed, 28 Feb 2001 13:44: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 QQkeig28226 for ; Wed, 28 Feb 2001 13:44:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeig05629 for ; Wed, 28 Feb 2001 13:43:00 GMT From: djiang1@lucent.com Received: from hoemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkeig20164 for ; Wed, 28 Feb 2001 13:43:00 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA22382 for ; Wed, 28 Feb 2001 08:42:59 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA22355; Wed, 28 Feb 2001 08:42:58 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA03195; Wed, 28 Feb 2001 08:42:57 -0500 (EST) Subject: Re: Question on MPLS over native ATM To: jshen@cad.zju.edu.cn Cc: "mpls@UU.NET" Date: Wed, 28 Feb 2001 08:39:04 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 02/28/2001 08:39:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Shen, It looks like your IP end host/router needs to change the IP packet into IP/MPLS/ATM (say AAL5) cells. Transport the ATM cells across the native ATM network. Then at the other end, transform the ATM cells back into IP packet. Would you think your IP end host/router has the ability to do that? See whether RFC3035 can give you any help. Regards, Jane D. Jiang shen jing @UU.NET on 02/27/2001 10:17:42 PM Please respond to jshen@cad.zju.edu.cn Sent by: owner-mpls@UU.NET To: Guang Xiaoming , "mpls@UU.NET" cc: Subject: Question on MPLS over native ATM Hi : I met some problem with my work, would you please give me some hints? I'm thinking about connect IP host through ATM by using MPLS, which provide both fast transmission and QoS support to multimedia streams. I can not modify the control plane software installed in ATM switch, so I have to use MPLS on end host while native ATM in that switch. Is there any possiblity to integrate MPLS and ATM in a layered model ? IP --- MPLS -- ATM---------ATM --- MPLS--IP ^ ^ ^ | | | MPLS over Native MPLS over ATM ATM ATM Is there any draft on this topic ? or any person has implement a solution? Thanks a lot. Shen From owner-mpls@UU.NET Wed Feb 28 09:18:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06665 for ; Wed, 28 Feb 2001 09:18: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 QQkeij06477; Wed, 28 Feb 2001 14:17:50 GMT Received: by mail-control.mail.uu.net id QQkeij18021 for mpls-outgoing; Wed, 28 Feb 2001 14:17: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 QQkeij17997 for ; Wed, 28 Feb 2001 14:17: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 QQkeii00551 for ; Wed, 28 Feb 2001 14:14:52 GMT Received: from WATERTOWN.litchfieldcomm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 121.125.252.64.snet.net [64.252.125.121]) id QQkeii16708 for ; Wed, 28 Feb 2001 14:14:50 GMT Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Date: Wed, 28 Feb 2001 09:15:30 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC031291@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: draft-danenberg-sonet-ces-mpls-mib-00.txt Thread-Index: AcChkOfYeAROO3fFTaasZROg3zIFPg== content-class: urn:content-classes:message From: "Dave Danenberg" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 To: "David Zelig" , "Thomas D. Nadeau" , "Jim Boyle" , "Andrew G. Malis (E-mail)" Cc: , "tom k. johnson" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA06665 David Zelig, Jim, Tom, Andy, Deriving SONET-like statistics from the CEM function is worth exploring further. As David Zelig points out, the CEM operation at the ends of the tunnel can monitor the path's B3 (BIP) byte. Although it may be tempting to piggyback on existing functionality (B3), this technique would not be able to easily discern between the errors introduced before the path reached the CEM (Ac-A in the example) and the errors introduced within the tunnel (A-Z). The CEM operation (at A) could regenerate B3, but that would violate the integrity of the path's own error statistics. So I think the way to look at this problem is by thinking of the CEM operation as what it really is - an emulated SONET 'line' carrying the path as its payload. As a 'line', the CEM could generate and terminate its own BIP. This BIP, could then be used to create the same quality and format of statistics as folks expect from SONET. For CEM to support its own payload BIP, a new field would be required in the CEM header. So this needs to carefully considered. If we were to do this, we also need to decide if the CEM payload BIP should be calculated on path or on packet delineations (i.e., calculated on the previous path frame just as B3 does, or on the CEM header to end of packet). (We'll forward this issue to the PWOT email list) Dave Danenberg -----Original Message----- From: David Zelig [mailto:Davidz@corrigent.com] Sent: Wednesday, February 28, 2001 2:11 AM To: 'Thomas D. Nadeau'; Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Tom, Dave and Jim, In order to detect payload defects at the STS level there are BIP checking on the path overhead. If an operator want to check errors generated by the CEM operation it may be simpler (and more understood) to monitor the B3 byte for errors in both ends of the tunnel. This can be done on the example below on the interface on the IP edge device. It is very hard to manipulate CEM errors to payload errors, and if the customer bought SONET service (and sign on SONET SLA) the PM should be on SONET "language" and measured at the SONET level. Sure we must cover all potential CEM errors in order to enable detecting the cause of the errors, especially for the case of problems caused by mis-configuration.I think that we need to deliver interval data for all PM related errors, and for events count. David -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, February 28, 2001 5:49 AM To: Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote: >Jim, > >Thanx for your input. It sounds like you'd like to see the same sort of >statistical information from the emulated SONET that folks are >accustomed to seeing from SONET networking equipment. I like that too >(from years of developing telecomm equipment for service providers). > >Although I was considering second order counts (errored seconds) or >trends (15 minute, 24 hour interval data), I decided to start with just >simple counts - and see what folks think. > >Andy's CEM does not detect errors over the CEM payload, but it does >detect errors within the CEM header (the CEM MIB counts them with >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps >CEM header error rates can be extrapolated to indicate payload errors >rates. Due to the nature of CEM, other types of errors are detectable >(buffer errors, missing packets, etc). Assuming CEM equipment can >process this raw info into some nice statistics, another set of objects >can be added to the CEM MIB. > >So, I'd like to include the type of statistical info you suggest as well >as your "reason for last down" idea. Would you like to see interval data >as well? > >What do you think Tom? If you agree, I can come up with another set of >objects and send it to Jim (and mpls email) for comment. Yes, as I mentioned earlier, I think these things are a good idea. Lets work on them and get our ideas back out to the list shortly. --Tom >Dave > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle >Sent: Tuesday, February 27, 2001 2:24 PM >To: Thomas D. Nadeau >Cc: mpls@UU.NET >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > >pretend you are a service provider, a customer calls in and says he's >seeing errors on his service (in particular, bip violalations in POH). > >He is directly connected to your network via port A. >On the far end, he connects to a clec, which hands it off to you at port >Z. He connects to a CLEC adm on port Z'. His path terminating >equipment >(maybe a router) is port Ac, and Zc, such that the service looks like: > >Ac-A-[IP]-Z-CLEC-Z'-Zc > >Looking at lines Ac-A and Z-CLEC shows clean lines. > >How does the operator determine if his IP network is to blame, or the >CLECs network is to blame? > >i'd recomend a few things: > >o) Andy's draft should have some sort of way to determine if there are >bit >errors hapenning across the IP network that affect the service >payload. This would provide the same sort of delineation of where a >problem is occuring by looking at LOHs in more traditional transport >network. > >o) your mib should include analogues to the SONET mib, such as bip-8 >violations, errored seconds, etc... (working off memory here). > >o) addition of a "reason for last down" might be nice. > >This way, when you, as the service provider, replies that "it's not our >problem, must be the clec", they can say at least go look at it later to >see if they were telling the truth. > >As usual, excellent attention paid to the configuration aspects. > >regards, > >Jim > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > Hi, > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > Service Over MPLS has been posted. It should be available > > shortly via the IETF's web site. In the meantime, it is available > > at the following web/ftp link. As usual, comments are welcome. > > > > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces - >mpls-mib-00.txt > > > > --Tom > > From owner-mpls@UU.NET Wed Feb 28 09:28:32 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07076 for ; Wed, 28 Feb 2001 09:28: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 QQkeij04594; Wed, 28 Feb 2001 14:27:49 GMT Received: by mail-control.mail.uu.net id QQkeij19103 for mpls-outgoing; Wed, 28 Feb 2001 14:27:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeij19079 for ; Wed, 28 Feb 2001 14:27:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeij10508 for ; Wed, 28 Feb 2001 14:25:45 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 QQkeij17714 for ; Wed, 28 Feb 2001 14:25:44 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 GAA26245 for ; Wed, 28 Feb 2001 06:26:01 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA27840 for mpls@uu.net; Wed, 28 Feb 2001 09:25:43 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkegu14320 for ; Wed, 28 Feb 2001 04:08:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkegu08330 for ; Wed, 28 Feb 2001 04:08:15 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 QQkegu29818 for ; Wed, 28 Feb 2001 04:08:14 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 20:07:57 -0800 Message-ID: From: Vishal Sharma To: "'Suresh Katukam'" , mpls@UU.NET Cc: "Eric Mannie (E-mail)" , "Greg Bernstein (E-mail)" , "Ben Mack-Crane (E-mail)" , "Michael Raftelis (E-mail)" , "Hai Vo-Dinh (E-mail)" , "Shash Chatterjee (E-mail)" , "Jeff Connell (E-mail)" , "Bala Rajagopalan (E-mail)" , "Debanjan Saha (E-mail)" Subject: RE: OSPF TE Extensions.. Date: Tue, 27 Feb 2001 20:07:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Suresh, You are correct. The current routing protocol extensions do not adequately cover non-packet technologies in general (TDM being one specific case). The focus of the GMPLS effort over the last 2-3 months has been primarily on signaling issues, and the routing protocol extensions have not been revisited for a while. I think this is work that certainly needs to be picked up again. If you'd like to, it might be useful to post the issues, you feel need to be covered, on this list (although with GMPLS moving to CCAMP, I would think they should be posted on CCAMP as well). -Vishal >-----Original Message----- >From: Suresh Katukam [mailto:skatukam@cisco.com] >Sent: Tuesday, February 27, 2001 4:39 PM >To: mpls@UU.NET >Subject: OSPF TE Extensions.. > > > >I am sorry if these things have been already discussed.. > >Current OSPF-TE extensions do not take care of lot >of TDM related issues. Is there a new draft or a >work going on this? > >Shall I go ahead and send the list of issues that >need to be covered in this draft? > >I already talked to Kireeti and Yakov about these >earlier. But I have not heard any progress yet. > > >Thanks, >Suresh > From owner-mpls@UU.NET Wed Feb 28 09:30:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07123 for ; Wed, 28 Feb 2001 09:30: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 QQkeij06641; Wed, 28 Feb 2001 14:27:55 GMT Received: by mail-control.mail.uu.net id QQkeij19110 for mpls-outgoing; Wed, 28 Feb 2001 14:27:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeij19085 for ; Wed, 28 Feb 2001 14:27:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeij10675 for ; Wed, 28 Feb 2001 14:25:49 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeij01664 for ; Wed, 28 Feb 2001 14:25:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA27994 for mpls@uu.net; Wed, 28 Feb 2001 09:25:48 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeij18886 for ; Wed, 28 Feb 2001 14:25:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeij08908 for ; Wed, 28 Feb 2001 14:25:04 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 QQkeij00667 for ; Wed, 28 Feb 2001 14:25:02 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 GAA18891; Wed, 28 Feb 2001 06:24:12 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BMAW5>; Wed, 28 Feb 2001 06:24:13 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB3@BBY1EXM01> From: Shahram Davari To: "'Puneet Agarwal'" , "'Eric Gray'" Cc: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Wed, 28 Feb 2001 06:27:37 -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 Puneet, > Hi Shahram, > > As I had briefly mentioned in reply to Eric's earlier email on the Pop > issue, we do not perform a "Route and a Pop" - that is > actually treated as a > "Route and a PHP". > I am not talking about "route and pop" rather I am talking about "pop and route". > To quote from our ttl draft section 2.4: > > "For packets that are routed as MPLS, we have three cases" > > the semantics of "routed as MPLS" implies that any egress > Pops have already > been performed. If you think that this was unclear in the > draft then I will > clarify it. > Oh yes. Finally I found the reason for confusion. It is absolutely unclear from "routed as MPLS" that a pop is done before hand. The reason is that the title of the draft says "TTL processing in MPLS networks", while section 2.4 assumes that the title is "TTL processing in MPLS tunnel end-points". Do you intend to cover TTL operation for the intermediate LSRs. If so you have two choices: 1) Clarify that section 2.4 applies to a tunnel ultimate/penultimate node, and then add another section for the TTL processing in the intermediate LSRs. 2) Clarify bullets 1,2,3 in section 2.4 by adding a pop to them such as pop+Swap, pop+swap+push, pop+PHP, and then add one more bullet for swap-only. > >If an egress router is the terminating point of a pipe/uniform > >tunnel, then the egress router must pop the top label and > >forward the packet using the label (or IP header) that is > >beneath the popped label. My question is: What TTL is encoded > >in the forwarding label (or IP header). The answer is: oTTL, > >which is equal to oTTL= iTTL-1, in which iTTL determination > >depends on the tunnel model and is described in section 2.3. > > > >So my suggestion is to add another bullet (say bullet 4) to > >section 2.4, that says: > > > >4) Pop : This is the terminating point of an LSP tunnel, in > >which, first the top label is popped and then the packet is > >forwarded based on the lower label (or exposed IP header). The > >TTL of the forwarding label (or IP header) is set to: > > > >oTTL = iTTL-1 > > > >in which, iTTL is determined based on the type of tunnel > >(i.e., uniform/pipe) as explained in section 2.3. > > I would be happy to include the text with a few modifications: > > 4) Pop : This is the terminating point of an LSP tunnel, in > which, first the top label is popped and then the packet is > forwarded based on the lower label (or exposed IP header). > Note that this operation can occur recursively. The iTTL is > updated as explained in section 2.3. The outgoing TTL would > be determined by the last non "Pop" operation performed > on the packet. > > Would such a text address your concerns? > There is no need for this text. Please see above. Yours, -Shahram From owner-mpls@UU.NET Wed Feb 28 10:01:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08290 for ; Wed, 28 Feb 2001 10:01: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 QQkeil09033; Wed, 28 Feb 2001 14:59:05 GMT Received: by mail-control.mail.uu.net id QQkeil22187 for mpls-outgoing; Wed, 28 Feb 2001 14:58:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeil22177 for ; Wed, 28 Feb 2001 14:58:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeil14922 for ; Wed, 28 Feb 2001 14:57:53 GMT Received: from zcars04e.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQkeil06589 for ; Wed, 28 Feb 2001 14:57:52 GMT Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 28 Feb 2001 09:41:56 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 09:41:58 -0500 Message-ID: <6DDA62170439D31185750000F80826AC0556EEC4@zmerd004.ca.nortel.com> From: "David Allan" To: Calin Poenaru , mpls@UU.NET Cc: neil.2.harrison@bt.com Subject: RE: OAM for MPLS networks Date: Wed, 28 Feb 2001 09:41:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A194.98B1BA30" 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_01C0A194.98B1BA30 Content-Type: text/plain Calin: I think you need to rephrase the questions along the lines of "what failure detection tools do I have" and optimize the hell out of the one that involves the least amount of state and overhead and "garbage collect" with the rest at a much lower level of activity. For many of us, this means fate sharing with the control adjacency whereby a single state machine proxies for all the LSPs on a link, which should quickly catch the majority or gross failures (errant backhoes, melting lasers and the like). The issue is that the control adjacency as a proxy does not catch subtle "per LSP" defects which are much harder to track down. So from that perspective, a mechanism is required to detect such failures, but as we are looking at a less frequent case, I would hope we can live with longer detection time and balance this with the amount of resources we need to commit to per LSP OAM. My read of this draft suggest that the proposed OAM is designed to deal with this type of failure and the 10 second number should not be projected onto detection of all types of failure. In fact we probably could go longer..... cheers Dave > -----Original Message----- > From: Calin Poenaru [SMTP:calin@employees.org] > Sent: Tuesday, February 27, 2001 7:21 AM > To: mpls@UU.NET > Cc: neil.2.harrison@bt.com > Subject: OAM for MPLS networks > > > Hello! > > I have a question about the efficiency of the mechanism for connectivity > verification described in draft-harrison-mpls-oam-00: there is proposed > a scheme which is very similar with I.610 and (in my opinion) has the same > drawback - a time for detect and react too high. In other words: the 10 > seconds necessary for detect the unavailable state is far too long to > affect all the connections in the failed LSP. And more, the 20 seconds > (minimum) required for re-entering in the available state is too much to > be useful for the traffic (in this time the Control Plane probably already > take some actions like reroute or something else). Could you comment a > little bit about this issues? > > And another question: at 6.6.3 you stated that the exit from Far-End > Defect State is conditioned by 3 consecutive seconds without BDI OAM > packets. But what if an FDI OAM packet will come? It will not force the > exit from this state and go into Near-End Defect State? > > Thank you in advance for your time! > > Best regads, > > Calin > > --- > > > > > ------_=_NextPart_001_01C0A194.98B1BA30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: OAM for MPLS networks

Calin:

I think you need to = rephrase the questions along the lines of "what failure detection = tools do I have" and optimize the hell out of the one that = involves the least amount of state and overhead and "garbage = collect" with the rest at a much lower level of activity. For many = of us, this means fate sharing with the control adjacency whereby a = single state machine proxies for all the LSPs on a link, which should = quickly catch the majority or gross failures (errant backhoes, melting = lasers and the like).

The issue is that = the control adjacency as a proxy does not catch subtle "per = LSP" defects which are much harder to track down. So from that = perspective, a mechanism is required to detect such failures, but as we = are looking at a less frequent case, I would hope we can live with = longer detection time and balance this with the amount of resources we = need to commit to per LSP OAM. My read of this draft suggest that the = proposed OAM is designed to deal with this type of failure and the 10 = second number should not be projected onto detection of all types of = failure. In fact we probably could go longer.....

cheers
Dave

    -----Original Message-----
    From:   Calin Poenaru [SMTP:calin@employees.org]
    Sent:   Tuesday, February 27, 2001 7:21 AM
    To:     mpls@UU.NET
    Cc:     neil.2.harrison@bt.com
    Subject:       = OAM for MPLS networks


    Hello!

    I have a question about the efficiency = of the mechanism for connectivity
    verification described in = draft-harrison-mpls-oam-00: there is proposed
    a scheme which is very similar with = I.610 and (in my opinion) has the same
    drawback - a time for detect and = react too high.  In other words: the 10
    seconds necessary for detect the = unavailable state is far too long to
    affect all the connections in the = failed LSP. And more, the 20 seconds
    (minimum) required for re-entering in = the available state is too much to
    be useful for the traffic (in this = time the Control Plane probably already
    take some actions like reroute or = something else). Could you comment a
    little bit about this issues?

    And another question: at 6.6.3 you = stated that the exit from Far-End
    Defect State is conditioned by 3 = consecutive seconds without BDI OAM
    packets. But what if an FDI OAM = packet will come? It will not force the
    exit from this state and go into = Near-End Defect State?

    Thank you in advance for your time!

    Best regads,

    Calin

    ---





------_=_NextPart_001_01C0A194.98B1BA30-- From owner-mpls@UU.NET Wed Feb 28 10:32:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09624 for ; Wed, 28 Feb 2001 10:32: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 QQkeio05745; Wed, 28 Feb 2001 15:31:37 GMT Received: by mail-control.mail.uu.net id QQkeio12075 for mpls-outgoing; Wed, 28 Feb 2001 15:30: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 QQkeio12023 for ; Wed, 28 Feb 2001 15:30: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 QQkein20519 for ; Wed, 28 Feb 2001 15:29:07 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkein02106 for ; Wed, 28 Feb 2001 15:29:06 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 2386F94009; Wed, 28 Feb 2001 10:29:06 -0500 (EST) Message-ID: <3A9D1942.D2A3BBB6@sandburst.com> Date: Wed, 28 Feb 2001 10:29:06 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari Cc: "'Puneet Agarwal'" , "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: Re: New TTL Draft References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB3@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, I see no reason why Puneet's draft should affect TTL processing in intermediate LSRs. I believe this is well defined elsewhere. By the way, an LSR that pops a label is not an intermediate LSR with respect to the LSP for which that label applied. -- Eric Gray You wrote: > Hi Puneet, > > > Hi Shahram, > > > > As I had briefly mentioned in reply to Eric's earlier email on the Pop > > issue, we do not perform a "Route and a Pop" - that is > > actually treated as a > > "Route and a PHP". > > > > I am not talking about "route and pop" rather I am talking about "pop and route". > > > To quote from our ttl draft section 2.4: > > > > "For packets that are routed as MPLS, we have three cases" > > > > the semantics of "routed as MPLS" implies that any egress > > Pops have already > > been performed. If you think that this was unclear in the > > draft then I will > > clarify it. > > > > Oh yes. Finally I found the reason for confusion. It is absolutely unclear from "routed as MPLS" that a pop is done before hand. The reason is that the title of the draft says "TTL processing in MPLS networks", while section 2.4 assumes that the title is "TTL processing in MPLS tunnel end-points". > > Do you intend to cover TTL operation for the intermediate LSRs. If so you have two choices: > > 1) Clarify that section 2.4 applies to a tunnel ultimate/penultimate node, and then add another section for the TTL processing in the intermediate LSRs. > > 2) Clarify bullets 1,2,3 in section 2.4 by adding a pop to them such as pop+Swap, pop+swap+push, pop+PHP, and then add one more bullet for swap-only. > > > >If an egress router is the terminating point of a pipe/uniform > > >tunnel, then the egress router must pop the top label and > > >forward the packet using the label (or IP header) that is > > >beneath the popped label. My question is: What TTL is encoded > > >in the forwarding label (or IP header). The answer is: oTTL, > > >which is equal to oTTL= iTTL-1, in which iTTL determination > > >depends on the tunnel model and is described in section 2.3. > > > > > >So my suggestion is to add another bullet (say bullet 4) to > > >section 2.4, that says: > > > > > >4) Pop : This is the terminating point of an LSP tunnel, in > > >which, first the top label is popped and then the packet is > > >forwarded based on the lower label (or exposed IP header). The > > >TTL of the forwarding label (or IP header) is set to: > > > > > >oTTL = iTTL-1 > > > > > >in which, iTTL is determined based on the type of tunnel > > >(i.e., uniform/pipe) as explained in section 2.3. > > > > I would be happy to include the text with a few modifications: > > > > 4) Pop : This is the terminating point of an LSP tunnel, in > > which, first the top label is popped and then the packet is > > forwarded based on the lower label (or exposed IP header). > > Note that this operation can occur recursively. The iTTL is > > updated as explained in section 2.3. The outgoing TTL would > > be determined by the last non "Pop" operation performed > > on the packet. > > > > Would such a text address your concerns? > > > > There is no need for this text. Please see above. > > Yours, > -Shahram > > > From owner-mpls@UU.NET Wed Feb 28 10:37:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09836 for ; Wed, 28 Feb 2001 10:37: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 QQkeio13133; Wed, 28 Feb 2001 15:36:43 GMT Received: by mail-control.mail.uu.net id QQkeio13068 for mpls-outgoing; Wed, 28 Feb 2001 15:36:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeio13018 for ; Wed, 28 Feb 2001 15:36:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeio22177 for ; Wed, 28 Feb 2001 15:35:33 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeio13542 for ; Wed, 28 Feb 2001 15:35:32 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id HAA01417; Wed, 28 Feb 2001 07:35:30 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id HAA23141; Wed, 28 Feb 2001 07:35:21 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Wed, 28 Feb 2001 07:35:21 -0800 (PST) From: Bora Akyol To: neil.2.harrison@bt.com cc: kireeti@juniper.net, eric.gray@sandburst.com, mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net Subject: RE: Expanded ERO draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Neil Just to follow up on your email: 1) There are no backwards compatibility issues by using the EERO. We devoted a section of the draft to this matter. The main reason for defining a new object was to avoid backwards compatibility issues. 2) The main motivation for this draft is to make ERO processing simpler and to make parsing of an ERO quick and "obvious" I think just the clarity of the EERO sub-objects is worth thinking more seriously about this draft. Bora On Wed, 28 Feb 2001 neil.2.harrison@bt.com wrote: > Kireeti Kompella [mailto:kireeti@juniper.net] asked on 27 February 2001 > 22:24 > > Who all think that adding a router ID to the unnumbered ERO subobject > > would be beneficial? A simple yes, no or don't care, please. > > I don't think a simple Y/N/DC vote is good enough....the vote has to be > supported by rationale. > > Having carefully followed the discussion I come to the conclusion that (i) > there appear to be some advantages to doing what Bora et al are advocating, > and (ii) there are no technical disadvantages (or at least none have been > stated that I can see....other than a clear reluctance from a few parties to > accept a change, which is fair enough if there are serious backwards > compatibility issues). > > Having said that..... > I think the biggest advantage is *clarity* of nodal identifier and > interface. I am reluctant to buy too hard into the fast-reroute arguments > since: > - it will not cater for all possible failure modes (but only, I assume > , below MPLS-layer failures, eg SDH) > - since an intermediate LSR in a LSP is *not* a trail termination > point there are some defect handling issues that are not being considered, > eg there should be a FDI from the failed LSP segment which gets merged with > the 'new' (rerouted) LSP segment.....and since the CV flow will split (at > point where new reroute starts) to take the new rerouted segment then > (ideally) the FDI should be suppressed from the failed segment at the > downstream merge point. > > The above can be circumvented by always establishing a completely new > server-layer LSP between the nodes where one wants to establish a > prot-route....and this would have its own CV flow, disjoint from the > (protected) segment of the client LSP. > > So, in conclusion: > - do it for clarity *and* if true technical benefits result > - don't do it if any backwards compatibility is evident and there are > no strong benefits....so are any backwards compatibility problems? > - don't do it for fast-rereoute reasons since (IMO) such a device > appears to be architecturally flawed. > > neil > From owner-mpls@UU.NET Wed Feb 28 10:49:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10231 for ; Wed, 28 Feb 2001 10:49: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 QQkeip10962; Wed, 28 Feb 2001 15:49:16 GMT Received: by mail-control.mail.uu.net id QQkeip15587 for mpls-outgoing; Wed, 28 Feb 2001 15:48: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 QQkeip15570 for ; Wed, 28 Feb 2001 15:48:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeip05131 for ; Wed, 28 Feb 2001 15:48:31 GMT Received: from prithvi.siliconsystems.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.85.131]) id QQkeip01900 for ; Wed, 28 Feb 2001 15:48:28 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 PAA21357 for ; Wed, 28 Feb 2001 15:48:03 GMT Received: from siliconsystems.co.in (opal.siliconsystems.co.in [172.19.32.37]) by mail.siliconsystems.co.in (8.9.3/8.9.3) with ESMTP id VAA05313 for ; Wed, 28 Feb 2001 21:31:03 +0530 (IST) Message-ID: <3A9D1FF2.52DFA8D8@siliconsystems.co.in> Date: Wed, 28 Feb 2001 21:27:38 +0530 From: Sachin Doshi X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Query Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can someone answer these: 1. Is it possible that on a LAN where R1 (router/switch) is connected to R3 (router/switch) through R2(router/switch), there is a LSP which has only R1 and R3 as LSR's not R2 (assuming that R1,R2 and R3 all are MPLS capable). 2. If a LSR receives a MPLS packet which was not directed to him (mac DA was not this LSR's address), what should it do with the packet? Should it switch the packet based on the L2 address or is it allowed to switch it based on the MPLS label? regards, sachin From owner-mpls@UU.NET Wed Feb 28 10:57:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10485 for ; Wed, 28 Feb 2001 10:57: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 QQkeip16832; Wed, 28 Feb 2001 15:55:57 GMT Received: by mail-control.mail.uu.net id QQkeip16389 for mpls-outgoing; Wed, 28 Feb 2001 15:55:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeip16375 for ; Wed, 28 Feb 2001 15:55:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeip08159 for ; Wed, 28 Feb 2001 15:55:13 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkeip15409 for ; Wed, 28 Feb 2001 15:55:13 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09445; Wed, 28 Feb 2001 10:55:10 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04914; Wed, 28 Feb 2001 10:55:13 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 10:55:11 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446C2B@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Thomas D. Nadeau'" , mpls@UU.NET Cc: "Choudhury, Sanjaya" Subject: RE: draft-nadeau-mpls-ds-te-mib-00.txt -some suggestions Date: Wed, 28 Feb 2001 10:55:11 -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 few suggestions related to the mplsDsTeIfClassTypeTable. I will appreciate, if you can take them in to consideration. Thanks, sanjay Suggestions related to the mplsDsTeIfClassTypeTable: --------------------------------------------------- Advantages of the suggested change: ----------------------------------- (1) Builds the support for the concepts introduced in the DiffServ-TE (mpls-diff-te-reqts-00) draft, based on the earlier MPLS-DiffServ draft(mpls-diff-ext-07). How: (a) mpls-diff-ext-07 support ---------------------------- MPLS-DiffServ draft expects the signaling messages to indicate the PSC (section 5.2.2) for L-LSPs. It also allows the provision by which user can specify the bandwidth associated with each of these PSCs. It allows the LSR to perform admission control to ensure that constraints on the availability of bandwidth for relevant PSC.[Appendix -B.2] (I am aware of the fact that to have MIB support for this draft needs more work (E-LSP etc), but that discussion is beyond the context). --> The suggested changes allows for this support. (b) mpls-diff-te-reqts-00 + ospf-diff-te-00 ------------------------------------------- As the reqts-00 draft points out, at its finest granularity each class-type TE is degenerated into a single Diff-Serv class. This draft allows, per-class parameters into the per-Class-Type parameter for scalability of IGP link state adv. --> The suggested changes allows for this support. (c) mpls-diff-te-ext-01 ---------------------- Allows the class-type to be signaled in the during connection setup. [Personally, I think this information is redundant, specifically for L-LSPs, but I may be wrong.] --> The suggested changes allows for this support. (2) Does not restrict the user from deciding the number of class-types he wants to support in his domain. Changes suggested: ------------------- [This changes listed here just to get the idea across and may not be syntactically correct or complete.] (1) --Add the ability for the user to specify the PSC associated with --a L-LSP. Logically, this field belongs to the extension of the --mplsXCTable and mplsTunnelTable (=>mplsDsTeLspTable or equivalent) mplsDsTeLspPSC OBJECT-TYPE SYNTAX Integer --16bit value [mpls-diff-ext-07, 5.2.2] mplsDsTeTunPSC OBJECT-TYPE SYNTAX Integer --16bit value [mpls-diff-ext-07, 5.2.2] (2) --Add the ability to specify the bandwidth requirement for each class --(mpls-diff-ext-07) --Add the ability to group per class parameters to per-class-type --parameters -- --PSC (class) to class-type mapping (per interface mapping --or should they be per LSR ?) -- mplsDsPscToClassTypeEntry OBJECT-TYPE MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { mplsInterfaceConfIndex, psc } ::= { mplsDsPscToClassTypeTable 1 } MplsDsPscToClassTypeEntry ::= SEQUENCE { psc Unsigned16, --16bit value [mpls-diff-ext-07] classType Integer(0..64) --[mpls-diff-te-reqts-00] } -- --per class-type bandwidth requirement (per interface mapping) -- mplsDsClassTypeEntry OBJECT-TYPE MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { mplsInterfaceConfIndex, classType } ::= { mplsDsClassTypeTable 2 } MplsDsPscToClassTypeEntry ::= SEQUENCE { classType INTEGER(0..64), MaxResBw Unsigned32, UnResBw Unsigned32 } (3) --May be we want to introduce two fields to support maximum number --of class-types that can be supported and the number of class-types -- currently configured. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, February 23, 2001 1:41 PM To: te-wg@UU.NET; mpls@UU.NET Cc: tnadeau@cisco.com; flefauch@europe.cisco.com; angela.chiu@celion.com; btownsend@tenornetworks.com; dareks@nortelnetworks.com; martin.tatham@bt.com Subject: draft-nadeau-mpls-ds-te-mib-00.txt Hi, FYI a new MIB for managing MPLS DiffServ-Aware TE has been posted. This document goes along with the other four DiffServ-Aware TE documents which have been adopted in the MPLS, TE, ISIS and OSPF WGs. It should be available shortly via the IETF's web site. In the meantime, it is available at the following web/ftp link. As usual, comments are welcome. ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-nadeau-mpls-ds-te-mib-00 .txt --Tom From owner-mpls@UU.NET Wed Feb 28 11:19:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11094 for ; Wed, 28 Feb 2001 11:19:21 -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 QQkeir08743; Wed, 28 Feb 2001 16:17:57 GMT Received: by mail-control.mail.uu.net id QQkeir04958 for mpls-outgoing; Wed, 28 Feb 2001 16:17: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 QQkeir04699 for ; Wed, 28 Feb 2001 16:16: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 QQkeir02661 for ; Wed, 28 Feb 2001 16:16:31 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkeir06789 for ; Wed, 28 Feb 2001 16:16:31 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id BA57F94009; Wed, 28 Feb 2001 11:16:27 -0500 (EST) Message-ID: <3A9D245B.20B354EA@sandburst.com> Date: Wed, 28 Feb 2001 11:16:27 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Sachin Doshi Cc: mpls@UU.NET Subject: Re: Query References: <3A9D1FF2.52DFA8D8@siliconsystems.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sachin, I'm not sure what the difference is between the first question and the second, but the second seems like a good question. A router may be configured to "bridge" certain packets (e.g. - based on the MAC header). This used to be called a "BRouter" in the days before the invention of the term "L3 Switch". There are several examples of when this may need to be done, but a currently applicable one would be in the VLAN case. Of course, when a router is configured this way, it appears like a transparent bridge to frames it "bridges". Hence, from the MPLS perspective, it is not visible to the LSRs between which it may be "bridging" --. Does this answer your question? -- Eric Gray You wrote: > Can someone answer these: > > 1. Is it possible that on a LAN where R1 (router/switch) is connected to > R3 (router/switch) through R2(router/switch), there is a LSP which has > only R1 and R3 as LSR's not R2 (assuming that R1,R2 and R3 all are > MPLS capable). > > 2. If a LSR receives a MPLS packet which was not directed to him (mac DA > was not this LSR's address), what should it do with the packet? Should > it switch the packet based on the L2 address or is it allowed to switch > it based on the MPLS label? > > regards, > sachin From owner-mpls@UU.NET Wed Feb 28 11:41:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12323 for ; Wed, 28 Feb 2001 11:41: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 QQkeis11337; Wed, 28 Feb 2001 16:40:19 GMT Received: by mail-control.mail.uu.net id QQkeis08027 for mpls-outgoing; Wed, 28 Feb 2001 16:39:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeis08021 for ; Wed, 28 Feb 2001 16:39:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeis20136 for ; Wed, 28 Feb 2001 16:38:58 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeis08606 for ; Wed, 28 Feb 2001 16:38:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA15106 for mpls@uu.net; Wed, 28 Feb 2001 11:38:53 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeis07797 for ; Wed, 28 Feb 2001 16:38:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeis10032 for ; Wed, 28 Feb 2001 16:38: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 QQkeis08013 for ; Wed, 28 Feb 2001 16:38:26 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 IAA07533; Wed, 28 Feb 2001 08:37:38 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BMC6F>; Wed, 28 Feb 2001 08:41:04 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB4@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" Cc: "'Puneet Agarwal'" , "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Wed, 28 Feb 2001 08:41:04 -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 Eric, > I see no reason why Puneet's draft should affect TTL processing > in intermediate LSRs. I believe this is well defined elsewhere. Sure, but first the authors should decide what is the objective of this draft? Is it explaining the TTL processing after pop or push, in other words is it explaining the TTL processing at tunnel ingress/egress/penultimate? or is it a general TTL processing draft that explains TTL processing at any node be it intermediate or tunnel ingress/egress/penultimate? It seems that the authors intend to talk only about tunnel ingress/egress/penultimate TTL processing. If that is the case then the draft is misleading because neither the title nor the text reflect this. Also section 2.3 second paragraph talks about iTTL determination for push/"SWAP"/php. Which means it is talking about iTTL determination for a "SWAP" case too, which is intermediate TTL processing. > By the way, an LSR that pops a label is not an intermediate LSR > with respect to the LSP for which that label applied. > Yes, I guess I know that. Thanks, -Shahram From owner-mpls@UU.NET Wed Feb 28 12:28:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15075 for ; Wed, 28 Feb 2001 12:28: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 QQkeiv05321; Wed, 28 Feb 2001 17:27:31 GMT Received: by mail-control.mail.uu.net id QQkeiv29465 for mpls-outgoing; Wed, 28 Feb 2001 17:27:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeiv29458 for ; Wed, 28 Feb 2001 17:27:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeiv00196 for ; Wed, 28 Feb 2001 17:26:35 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeiv29995 for ; Wed, 28 Feb 2001 17:26:34 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id JAA09657; Wed, 28 Feb 2001 09:23:09 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: References: Date: Wed, 28 Feb 2001 09:21:16 -0800 To: John Drake From: Bora Akyol Subject: RE: New Internet Draft on ERO Cc: "'Bora Akyol'" , Bala Rajagopalan , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk John When we implemented our fast reroute algorithm, we had to deal with both numbered and unnumbered interfaces, numbered interfaces were much easier to deal with as you avoided two of the steps that I explained below. Basically, when you calculate the exclusion list, the numbered interfaces make it trivial, whereas unnumbered interfaces require judicious use of the TE database as I describe below. How did you implement the fast reroute algorithm when you had unnumbered interfaces? Bora At 5:46 PM -0800 2/27/01, John Drake wrote: >Bora, > >Without trying to be difficult, your response to Bala sounds suspiciously >like an assertion. Wouldn't the intermediate node processing, with respect >to accesses of the TE database, be the same whether dealing with unnumbered >or numbered links? So if we don't need router ID for numbered links, why do >we need it for unnumbered links? > >Thanks, > >John > >-----Original Message----- >From: Bora Akyol [mailto:akyol@pluris.com] >Sent: Tuesday, February 27, 2001 4:30 PM >To: Bala Rajagopalan >Cc: 'Bora Akyol'; mpls@UU.NET >Subject: RE: New Internet Draft on ERO > > >At 5:41 PM -0500 2/27/01, Bala Rajagopalan wrote: >> > >>> Think of an unnumbered ERO of the form <1,1,1,1,1,1,1,1> >>> >>> Now somewhere in the middle, an LSR wants to calculate a fast reroute >>> LSP. Normally, one would ask the TE database the simple question of >>> avoid my next hop and would give the router ID of the next hop, but >>> in this case, first you have to find out who the router at the end of >>> the egress interface is. This is not hard, then you need to find out >>> who the router that is right after the immediate hop. This second one >>> is harder since you have to make a query into the TE database, to >>> find that. Then you have to make a third query into TED, to calculate >>> an LSP that avoids the immediate next hop but merges as soon as >>> possible with the main LSP. And finally, you calculate an ERO that >>> now is a mixture of both numbered and unnumbered interfaces possibly >>> and initiate signaling. As I describe here, this is not undoable, but >>> at what cost. >>> >>> If one adds the extra four bytes of router ID as part of the ERO (as >>> we did in the EERO) this whole thing becomes trivial to implement. >>> >> >>Just curious, to implement this type of fast reroute, can't intermediate >>nodes >>get downstream information from record route? >> >>Bala > >Bala > >As I wrote in my previous email, there are other ways of getting this >info. The point that I was trying to make is that when you add the >router ID, things become clearer and simpler. > >Bora From owner-mpls@UU.NET Wed Feb 28 12:38:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15493 for ; Wed, 28 Feb 2001 12:38: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 QQkeiw04866; Wed, 28 Feb 2001 17:38:11 GMT Received: by mail-control.mail.uu.net id QQkeiw02971 for mpls-outgoing; Wed, 28 Feb 2001 17:37: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 QQkeiw02958 for ; Wed, 28 Feb 2001 17:37:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeiw10240 for ; Wed, 28 Feb 2001 17:37:01 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeiw20636 for ; Wed, 28 Feb 2001 17:37:01 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id JAA10934; Wed, 28 Feb 2001 09:36:57 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB4@BBY1EXM01> References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AB4@BBY1EXM01> Date: Wed, 28 Feb 2001 09:35:04 -0800 To: Shahram Davari From: Bora Akyol Subject: RE: New TTL Draft Cc: "'Eric Gray'" , "'Puneet Agarwal'" , "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk Shahram Puneet has been handling this thread while I dealt with the ERO draft related calls, but if there is something missing in the draft as you pointed out, we will fix it. Our goal is to explain in general how TTL processing works in **hierarchical** MPLS networks. We asked for an agenda slot for this draft, so we can discuss this in more detail in Minn. Bora At 8:41 AM -0800 2/28/01, Shahram Davari wrote: >Hi Eric, > > >> I see no reason why Puneet's draft should affect TTL processing >> in intermediate LSRs. I believe this is well defined elsewhere. > >Sure, but first the authors should decide what is the objective of >this draft? Is it explaining the TTL processing after pop or push, >in other words is it explaining the TTL processing at tunnel >ingress/egress/penultimate? or is it a general TTL processing draft >that explains TTL processing at any node be it intermediate or >tunnel ingress/egress/penultimate? > >It seems that the authors intend to talk only about tunnel >ingress/egress/penultimate TTL processing. If that is the case then >the draft is misleading because neither the title nor the text >reflect this. Also section 2.3 second paragraph talks about iTTL >determination for push/"SWAP"/php. Which means it is talking about >iTTL determination for a "SWAP" case too, which is intermediate TTL >processing. > >> By the way, an LSR that pops a label is not an intermediate LSR >> with respect to the LSP for which that label applied. > > > >Yes, I guess I know that. > >Thanks, >-Shahram From owner-mpls@UU.NET Wed Feb 28 13:26:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17861 for ; Wed, 28 Feb 2001 13:26: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 QQkeiz26678; Wed, 28 Feb 2001 18:25:30 GMT Received: by mail-control.mail.uu.net id QQkeiz27840 for mpls-outgoing; Wed, 28 Feb 2001 18:25: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 QQkeiz27820 for ; Wed, 28 Feb 2001 18:25: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 QQkeiz22161 for ; Wed, 28 Feb 2001 18:24:41 GMT Received: from dnsmx1pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkeiz26292 for ; Wed, 28 Feb 2001 18:24:41 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id NAA14282 for ; Wed, 28 Feb 2001 13:22:30 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256A01.0064D792 ; Wed, 28 Feb 2001 13:21:27 -0500 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256A01.0064CCBB.00@notes949.cc.telcordia.com> Date: Wed, 28 Feb 2001 13:20:34 -0500 Subject: rsvp udp connection Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, When rsvp package is sent out, was UDP connection required? According to the spec 2205, on Appendix c., it means that there are two different scenarios. One is that the rsvp can send and receive by raw network I/O, and another one is that UDP is necessary to put RSVP into the UDP before it is sent out. When we do the real testing, it looks like that the rsvp only require raw network I/O to send and receive IP datagrams using protocol 46. Can anyone tell me which way is the most of switches( supported rsvp )implemented? Thanks, Julia From owner-mpls@UU.NET Wed Feb 28 14:47:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20874 for ; Wed, 28 Feb 2001 14:47: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 QQkejf01054; Wed, 28 Feb 2001 19:46:12 GMT Received: by mail-control.mail.uu.net id QQkejf22550 for mpls-outgoing; Wed, 28 Feb 2001 19:45: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 QQkejf22529 for ; Wed, 28 Feb 2001 19:45:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejf17901 for ; Wed, 28 Feb 2001 19:45:14 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkejf15807 for ; Wed, 28 Feb 2001 19:45:14 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id OAA13060; Wed, 28 Feb 2001 14:41:51 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256A01.006C32C0 ; Wed, 28 Feb 2001 14:41:48 -0500 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: David Charlap cc: mpls@UU.NET Message-ID: <85256A01.006C3114.00@notes949.cc.telcordia.com> Date: Wed, 28 Feb 2001 14:41:18 -0500 Subject: Re: rsvp udp connection Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk David, Thanks for your quick reply. Since rsvp is not route-to-route protocol, it is possible for some systems which does not support raw network I/O, it will use UDP encapsulation. Thanks in advance. Julia David Charlap on 02/28/2001 02:04:17 PM To: Hong Liao cc: (bcc: Hong Liao/Telcordia) Subject: Re: rsvp udp connection Hong Liao wrote: > > When rsvp package is sent out, was UDP connection required? No. > According to the spec 2205, on Appendix c., it means that there are > two different scenarios. > One is that the rsvp can send and receive by raw network I/O, and > another one is that UDP is necessary to put RSVP into the UDP before > it is sent out. When we do the real testing, it looks like that the > rsvp only require raw network I/O to send and receive IP datagrams > using protocol 46. > > Can anyone tell me which way is the most of switches( supported rsvp > )implemented? RSVP, as defined in RFC 2205, is a host-to-host protocol, not router- to-router. The hosts may run RSVP as an application-level protocol, and not as a part of the OS network stack. As such, it may be unable to generate or receive IP packets other than TCP and UDP. UDP encapsulation is a workaround to allow these kinds of hosts to use RSVP. UDP encapsulation should not be required for router-to-router communication, such as when it is used in MPLS. -- David From owner-mpls@UU.NET Wed Feb 28 15:08:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22010 for ; Wed, 28 Feb 2001 15:08: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 QQkejg17442; Wed, 28 Feb 2001 20:07:29 GMT Received: by mail-control.mail.uu.net id QQkejg03600 for mpls-outgoing; Wed, 28 Feb 2001 20:06:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkejg03355 for ; Wed, 28 Feb 2001 20:06:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejg13372 for ; Wed, 28 Feb 2001 20:05:20 GMT Received: from mercury.polarisnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQkejg26153 for ; Wed, 28 Feb 2001 20:05:19 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Wed, 28 Feb 2001 12:07:08 -0800 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <1N85JZ9Y>; Wed, 28 Feb 2001 12:03:31 -0800 Message-ID: From: "Huang, Thomas" To: mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Date: Wed, 28 Feb 2001 12:03:30 -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 To the RSVP-TE 0.8 authors: It would be nice if you could put a small paragraph to enumerate the major changes between 0.8 and 0.7 as it was done in GMPLS. Maybe someone of you could post a small paragraph? Regards, Thomas -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 28, 2001 3:59 AM To: IETF-Announce Cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-rsvp-lsp-tunnel-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : RSVP-TE: Extensions to RSVP for LSP Tunnels Author(s) : D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow Filename : draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Pages : 61 Date : 27-Feb-01 This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-lsp-tunnel-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-mpls@UU.NET Wed Feb 28 15:19:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22443 for ; Wed, 28 Feb 2001 15:19: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 QQkejh27246; Wed, 28 Feb 2001 20:18:42 GMT Received: by mail-control.mail.uu.net id QQkejh12343 for mpls-outgoing; Wed, 28 Feb 2001 20:17:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkejh12306 for ; Wed, 28 Feb 2001 20:17: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 QQkejh07974 for ; Wed, 28 Feb 2001 20:17:21 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkejh24619 for ; Wed, 28 Feb 2001 20:17:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA07335 for mpls@uu.net; Wed, 28 Feb 2001 15:17:20 -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 QQkejh12218 for ; Wed, 28 Feb 2001 20:16: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 QQkejh25031 for ; Wed, 28 Feb 2001 20:16:23 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 QQkejh14204 for ; Wed, 28 Feb 2001 20:16:19 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA10882 for ; Wed, 28 Feb 2001 15:16:18 -0500 (EST) Message-Id: <200102282016.PAA10882@pilgrim.cisco.com> To: mpls@UU.NET Subject: RSVP-TE draft-08 Date: Wed, 28 Feb 2001 15:16:18 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Version -08 of the RSVP-TE draft contains updates based on the IESG last call. They are summarized below. ...George > Hello RSVP Tunnel Editors, > > here are the IESG's comments on > > 1) The null/best-effort service has already been advanced as a > PS. The CoS object in the RSVP-TE (draft > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt) has an object that essentially > serves the same purpose. The CoS object can also provide indications of > better than BE traffic, but such indications can also be provided via the > objects described in draft-ietf-mpls-diff-ext-07.txt. > The IESG would like the now redundant CoS object removed from the > RSVP-TE draft Section removed. > 2) There is some wording that needs tweaking: > > > If the DF bit is set in the IP header, then > > > > (a) the datagram MUST NOT be forwarded > > > > (b) Create an ICMP Destination Unreachable Message: > > i. set its Code field [12] to "Fragmentation Required > > and DF Set", > > ii. set its Next-Hop MTU field [13] to M > > The above is OK for IPv4, but the ICMP message is called "packet too > big" in IPv6. Also, there is no DF bit in the IPv6 header. So some > wordsmithing seems in order. 1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node. 2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram Size" or of (Path MTU - N). When the size of an IPv4 datagram (without labels) exceeds the value of M, If the DF bit is not set in the IPv4 header, then (a) the datagram MUST be broken into fragments, each of whose size is no greater than M, and (b) each fragment MUST be labeled and then forwarded. If the DF bit is set in the IPv4 header, then (a) the datagram MUST NOT be forwarded (b) Create an ICMP Destination Unreachable Message: i. set its Code field [12] to "Fragmentation Required and DF Set", ii. set its Next-Hop MTU field [13] to M (c) If possible, transmit the ICMP Destination Unreachable Message to the source of the of the discarded datagram. When the size of an IPv6 datagram (without labels) exceeds the value of M, (a) the datagram MUST NOT be forwarded (b) Create an ICMP Packet too Big Message with the Next-Hop link MTU field [14] set to M (c) If possible, transmit the ICMP Packet too Big Message to the source of the of the discarded datagram. > 3) Reword. IANA is the authority > > > 7. IANA Considerations > > > > The responsible Internet authority (presently called the IANA) > > assigns values to RSVP protocol parameters. With the current > > Suggested rewording: > > IANA assigns values to RSVP protocol parameters. With the current ... Reworded as suggested. > 4) The IANA section does not give specific guidance on the > conditions under which IANA grants requests for numbers. See RFC 2434 > for details. > EXPLICIT_ROUTE Subobject Type EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies the function of the subobject. There are no range restrictions. All possible values except zero are available for assignment. Following the policies outlined in [15], subobject types in the range 0x00 - 0x3F are allocated through an IETF Consensus action, codes in the range 00x40 - 0x5F are allocated as First Come First Served, and codes in the range 0x60 - 0x7F are reserved for Private Use. ROUTE_RECORD Subobject Type ROUTE_RECORD Subobject Type is an 8-bit number that identifies the function of the subobject. There are no range restrictions. All possible values except zero are available for assignment. Following the policies outlined in [15], subobject types in the range 0x00 - 0x7F are allocated through an IETF Consensus action, codes in the range 00x80 - 0xBF are allocated as First Come First Served, and codes in the range 0xC0 - 0xFF are reserved for Private Use. > 5) Some of the author information is now out of date. > Updated. > thanks, > ---rob Also added the following error value to the Notify error code in response to my own last call comment. 3 Tunnel locally repaired ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Feb 28 15:21:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22624 for ; Wed, 28 Feb 2001 15:21: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 QQkejh13340; Wed, 28 Feb 2001 20:20:57 GMT Received: by mail-control.mail.uu.net id QQkejh12910 for mpls-outgoing; Wed, 28 Feb 2001 20:20:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkejh12884 for ; Wed, 28 Feb 2001 20:20:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejh18511 for ; Wed, 28 Feb 2001 20:20:16 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 QQkejh20287 for ; Wed, 28 Feb 2001 20:20: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 MAA22268 for ; Wed, 28 Feb 2001 12:20:32 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA29664 for mpls@uu.net; Wed, 28 Feb 2001 15:20:13 -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 QQkejg04521 for ; Wed, 28 Feb 2001 20:08:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejg00074 for ; Wed, 28 Feb 2001 20:08:27 GMT Received: from web12810.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web12810.mail.yahoo.com [216.136.174.97]) id QQkejg02442 for ; Wed, 28 Feb 2001 20:08:26 GMT Message-ID: <20010228200826.92714.qmail@web12810.mail.yahoo.com> Received: from [152.148.114.81] by web12810.mail.yahoo.com; Wed, 28 Feb 2001 12:08:26 PST Date: Wed, 28 Feb 2001 12:08:26 -0800 (PST) From: narakasura Dumbo Subject: RSVP & OSPF-TE ... To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I have a couple of questions 1. How do we signal the "color" (32 colors that can be assigned to a link, Katz OSPF-TE draft) using RSVP-TE ? Is this addressed somewhere ? 2. Is there a plan to add interface index as part of OSPF-TE ? Is yes, when is it expected to be available ? Thanks Pappai __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Feb 28 15:22:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22663 for ; Wed, 28 Feb 2001 15:22: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 QQkejh14329; Wed, 28 Feb 2001 20:21:24 GMT Received: by mail-control.mail.uu.net id QQkejh12957 for mpls-outgoing; Wed, 28 Feb 2001 20:20: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 QQkejh12931 for ; Wed, 28 Feb 2001 20:20: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 QQkejh06186 for ; Wed, 28 Feb 2001 20:19:56 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkejh19714 for ; Wed, 28 Feb 2001 20:19:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA07551 for mpls@uu.net; Wed, 28 Feb 2001 15:19: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 QQkejh12464 for ; Wed, 28 Feb 2001 20:18:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejh02226 for ; Wed, 28 Feb 2001 20:18: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 QQkejh17669 for ; Wed, 28 Feb 2001 20:18:39 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA11134; Wed, 28 Feb 2001 15:18:20 -0500 (EST) Message-Id: <200102282018.PAA11134@pilgrim.cisco.com> To: "Hong Liao" cc: mpls@UU.NET, swallow@cisco.com Subject: Re: rsvp udp connection In-reply-to: Your message of "Wed, 28 Feb 2001 13:20:34 EST." <85256A01.0064CCBB.00@notes949.cc.telcordia.com> Date: Wed, 28 Feb 2001 15:18:20 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk I believe essentially everyone does raw. I've even heard that folks would like to remove the UDP option if 2205 is ever re-spun. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Feb 28 15:24:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22788 for ; Wed, 28 Feb 2001 15: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 QQkejh19077; Wed, 28 Feb 2001 20:23:34 GMT Received: by mail-control.mail.uu.net id QQkejh13333 for mpls-outgoing; Wed, 28 Feb 2001 20:23: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 QQkejh13323 for ; Wed, 28 Feb 2001 20:23: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 QQkejh13529 for ; Wed, 28 Feb 2001 20:22:17 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkejh03930 for ; Wed, 28 Feb 2001 20:22:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA08303 for mpls@uu.net; Wed, 28 Feb 2001 15:22: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 QQkejh13008 for ; Wed, 28 Feb 2001 20: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 QQkejh18329 for ; Wed, 28 Feb 2001 20:20: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 QQkejh20898 for ; Wed, 28 Feb 2001 20:20:39 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA11455 for ; Wed, 28 Feb 2001 15:20:38 -0500 (EST) Message-Id: <200102282020.PAA11455@pilgrim.cisco.com> To: mpls@UU.NET Subject: MPLS schedule still Thursday Date: Wed, 28 Feb 2001 15:20:38 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk I got another schedule from the Agenda folks. We're still on Thursday afternoon. This seems pretty certain at this point. The final agenda should be on the web within a day or two. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Feb 28 15:56:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25083 for ; Wed, 28 Feb 2001 15:56: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 QQkejj25948; Wed, 28 Feb 2001 20:54:44 GMT Received: by mail-control.mail.uu.net id QQkejj17919 for mpls-outgoing; Wed, 28 Feb 2001 20:54:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkejj17914 for ; Wed, 28 Feb 2001 20:54:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkejj18971 for ; Wed, 28 Feb 2001 20:54:01 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkejj22062 for ; Wed, 28 Feb 2001 20:54:00 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA12898 for mpls@uu.net; Wed, 28 Feb 2001 15:53:59 -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 QQkejj17891 for ; Wed, 28 Feb 2001 20:53: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 QQkejj19036 for ; Wed, 28 Feb 2001 20:53:14 GMT Received: from mail1.digital.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.digital.com [204.123.2.50]) id QQkejj20429 for ; Wed, 28 Feb 2001 20:53:13 GMT Received: from src-news.pa.dec.com (src-news.pa.dec.com [16.4.16.111]) by mail1.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id MAA24001 for ; Wed, 28 Feb 2001 12:53:08 -0800 (PST) Received: by src-news.pa.dec.com; id MAA05472; Wed, 28 Feb 2001 12:51:52 -0800 (PST) To: dec-mail-lists-ietf@usenet.pa.dec.com Path: pa.dec.com!owner-ietf-redist From: Internet-Drafts@ietf.org Newsgroups: dec.mail.lists.ietf Subject: I-D ACTION:draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Date: 28 Feb 2001 12:51:52 -0800 Organization: Systems Research Center, Compaq Computer Corporation Lines: 88 Distribution: dec Message-ID: <200102281159.GAA03048@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET In-Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03886 for ietf-123-outbound.02@ietf.org; Wed, 28 Feb 2001 15:25:00 -0500 (EST) X-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 GAA00015 for ; Wed, 28 Feb 2001 06:59:00 -0500 (EST) X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03048; Wed, 28 Feb 2001 06:59:02 -0500 (EST) X-Received: by src-news.pa.dec.com; id MAA05866; Wed, 28 Feb 2001 12:51:50 -0800 (PST) X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA01592; Wed, 28 Feb 2001 12:51:50 -0800 X-Received: from nsl-too.pa.dec.com by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA01790; Wed, 28 Feb 2001 12:51:49 -0800 X-Received: by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA27259; Wed, 28 Feb 2001 12:51:49 -0800 X-Received: from pobox1.pa.dec.com by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA18967; Wed, 28 Feb 2001 12:51:49 -0800 X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA24446; Wed, 28 Feb 2001 12:51:49 -0800 X-Received: from zmamail02.nz-tay.cpqcorp.net by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA01662; Wed, 28 Feb 2001 12:51:43 -0800 X-Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 0B39857E4; Wed, 28 Feb 2001 15:51:43 -0500 (EST) X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 9702154F7 for ; Wed, 28 Feb 2001 15:51:42 -0500 (EST) 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 : RSVP-TE: Extensions to RSVP for LSP Tunnels Author(s) : D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow Filename : draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Pages : 61 Date : 27-Feb-01 This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-lsp-tunnel-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227124055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-lsp-tunnel-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227124055.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Feb 28 16:15:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25912 for ; Wed, 28 Feb 2001 16:15: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 QQkejk01000; Wed, 28 Feb 2001 21:13:39 GMT Received: by mail-control.mail.uu.net id QQkejk07086 for mpls-outgoing; Wed, 28 Feb 2001 21:12:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkejk07069 for ; Wed, 28 Feb 2001 21:12:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkejk01545 for ; Wed, 28 Feb 2001 21:12:04 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkejk22611 for ; Wed, 28 Feb 2001 21:12:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA15062 for mpls@uu.net; Wed, 28 Feb 2001 16:12:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkejk06763 for ; Wed, 28 Feb 2001 21:11:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejk29121 for ; Wed, 28 Feb 2001 21:11:04 GMT Received: from shell-beach.layer8.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQkejk01773 for ; Wed, 28 Feb 2001 21:11:03 GMT Received: (qmail 96651 invoked by uid 1000); 28 Feb 2001 21:05:00 -0000 Date: Wed, 28 Feb 2001 13:05:00 -0800 From: Ben Black To: Eric Gray Cc: mpls@UU.NET Subject: Re: MTU Signalling Extensions for LDP Message-ID: <20010228130500.A96372@layer8.net> References: <20010221164932.B50026@layer8.net> <3A953FFC.DF819168@sandburst.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A953FFC.DF819168@sandburst.com>; from eric.gray@sandburst.com on Thu, Feb 22, 2001 at 11:36:12AM -0500 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Feb 22, 2001 at 11:36:12AM -0500, Eric Gray wrote: > > Section 2.1 item 1)a): > --------------------- > > The egress LSR would know what interface it will be using > to forward packets it receives on an LSP (otherwise, it would > not have advertised reachability for the FEC for this LSP, and > it would be required to refuse a corresponding LSP request). > It will know what the MTU is for that interface. Therefore, > it should provide a "real" MTU rather than 0xffff. > The MTU in question is for the LSP, not the end to end path for a given FEC. What happens to packets outside the MPLS domain, which I believe the unlabeled side of an LER is, is not a concern when determining the MTU within the MPLS domain. > An LSR should be permitted, by wording in the specification, > to use either the MTU of the interface it will forward packets > on, or the minimum of a set of interfaces (up to and including > all interfaces) over which it might forward the packet. > This issue was previously raised and I neglected to include it. I will make appropriate changes. > > Section 2.1 item 1)b): > --------------------- > > Applying the reasoning above, an LSR that is not the egress > for a FEC should not include an MTU TLV (or it should include a > TLV with an "unknown" MTU) until it receives a label mapping from > a downstream LSR that does include an MTU TLV with a "real" MTU. > In order to include information about the ability to negotiate LSP > MTU, a non-egress LSR might advertise an MTU of either 0x0000 or > 0xffff to indicate that it currently does not know the MTU for the > LSP downstream. > Perhaps it was not stated clearly enough, but 0xffff is the unknown MTU value. It indicates that MTU signaling is supported, and acts as a placeholder. > > Section 2.1 item 1)c): > --------------------- > > If the above approach is bought into, the case where an LSR > receives a label mapping which does not contain an MTU TLV becomes > the example of the backward compatibility case (an existing LSR > will not include this TLV) and indicates that there is no end to > end MTU negotiation capability for this LSP. At this point, my > thinking is that this should be refelected all the way to the > ingress (for example, to allow the ingress to "prefer" an LSP > which does have MTU negotiation) by omission of the MTU TLV in > all label mappings issued corresponding to this downstream LSP. > I could be persuaded that this is not a good idea, however - if > there are sound (or numerous) arguments against it. > My thinking was that partial information is better than no information (which is the current state of things). My calculating the MTU at each hop, the ingress LSR can learn some approximation of the path MTU, which may be correct, but will be no worse off than if it had no MTU information. I see the advantage of your suggestion to allow differentiation between end to end known MTU and partial path MTU, but I am not sure how to fit that into the hop by hop model of the draft. > Also, in the event that (using independent mode) the LSR has > previously provided label mappings that includes an MTU TLV of > "unknonw" MTU size, it must send new label mappings which omit > this TLV. > I don't understand this point. > Section 2.1 item 1)d): > --------------------- > > The meaning of "neighbor to which it is not directly > connected" is a little obscure for me. If the neighbor is > connected via some sort of logical link, then an LSR should > be smart enough to use the MTU corresponding to the logical > link. Is this what you are saying? If so, it applies - I > believe - more generally than to the LSP case. For example, > there may be different MTU sizes associated with different > VLAN tags and it is likely (in the Ethernet case) that there > will be different MTU sizes depending on the next-hop (MAC > address) - somewhat independent of the physical interface. > Yes, that wording has tripped several people up and I will work to come up with a better phrase. > > Section 2.2: > ----------- > > Why is the "Reserved" field included? > It was originally there to hold a stack depth counter, but this was removed early on. THe reserved field could be safely eliminated. > The 'U' and 'F' bits are set correctly (IMO), but there > may be some value in mentioning why they are set this way. > Agreed. > Section 5: > --------- > > The procedures in this specification do introduce a new > security issue: it is now possible to introduce a new type > of "attack" in which a forged TCP segment contains an MTU > TLV with an incorrect value. For example, an attacker may > insert a TLV with an MTU one smaller than the last MTU > advertised (forcing new advertisements to be strobed upstream) > and continue in this vein until the MTU reaches zero. > > The procedures defined in RFC 3036, however, provide some > protection against such an attack. Hence, while a new hazard > is introduced, the risk of an attack in general is not increased. > I believe the statement that no _new_ security issues are introduced is accurate, as the ability to inject forged TCP segments raises security issues for numerous components of LDP. Thank you for the detailed feedback. Ben From owner-mpls@UU.NET Wed Feb 28 16:48:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27100 for ; Wed, 28 Feb 2001 16:48: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 QQkejn01320; Wed, 28 Feb 2001 21:47:14 GMT Received: by mail-control.mail.uu.net id QQkejn11623 for mpls-outgoing; Wed, 28 Feb 2001 21:46: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 QQkejn11617 for ; Wed, 28 Feb 2001 21:46:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkejn05247 for ; Wed, 28 Feb 2001 21:46:40 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cerebellum.gtinc.com [207.5.81.3] (may be forged)) id QQkejn25453 for ; Wed, 28 Feb 2001 21:46:39 GMT Received: from nayna.com (sonicwall [207.5.81.2]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA00866; Wed, 28 Feb 2001 13:46:33 -0800 X-Authentication-Warning: server.nayna.com: Host sonicwall [207.5.81.2] claimed to be nayna.com Message-ID: <3A9D71B7.1080503@nayna.com> Date: Wed, 28 Feb 2001 13:46:31 -0800 From: Sudheer Dharanikota Reply-To: sudheer@nayna.com Organization: Nayna Networks, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Jim Boyle CC: mpls@UU.NET Subject: Re: comments on draft-dubuc-mpls-bundle-mib-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jim: Thank you for the interest in the work. My comments inline. Jim Boyle wrote: > Martin, good idea, if we're going to start thinking about having link > bundles, we should probably think about mibs to get relevant information > out of network (for nms) or into network (if that is one's manner). > > I do think that this mib reaches too far, and replicates information that > is available elsewhere. > The goal is to not replicate the information. If it is overlapping with other work, we will correct it. > You mention an example of grouping 3 component links into 1 bundled > link. For some reason you mention 2 primary and 1 secondary, is this 1:N > protection, and if so, is there a relevant APS/Sonet/SDH mib where this > assocation of the secondary to the protected links should be made? This association in my opinion should be independent of the physical layer MIB, because this MIB is not restricted to SONET itself. > > In general, the mib should be able to grab interfaces and group them > together, however it's my view that these become standard interfaces, seen > in ifTable, in relevant OSPF mibs, TE mibs, etc... The bundled mib keeps > track of the relationship only (e.g. id 10 really is a composite of 1,2,3) > We realized this problem while writing this MIB. There are two approaches to this. One, extend the other protocol MIBs, which makes our life difficult to approach the protocol MIBs that are in the final stages (also with pre-ietf concepts). Two, keep the relevant protocol extensions in the same MIB but keep them as independent as possible for putting them in the future protocol MIBs. We took the second approach. > Why would one want to be able to not only get the OSPF TE metric from the > bundled mib, and from the TEMIB? > There are few ovrlaps. We have to refine the work. Thank you for pointing us to this. Cheers, sudheer > Anyways, my comment would be that the bundle mib should stick to a core > business, and leverage information that exist (rightfully) in other > places. > > regards, > > Jim From owner-mpls@UU.NET Wed Feb 28 17:05:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27784 for ; Wed, 28 Feb 2001 17:05: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 QQkejo05105; Wed, 28 Feb 2001 22:03:55 GMT Received: by mail-control.mail.uu.net id QQkejo20741 for mpls-outgoing; Wed, 28 Feb 2001 22:03:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkejo20667 for ; Wed, 28 Feb 2001 22:03:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkejo00912 for ; Wed, 28 Feb 2001 22:02:52 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 QQkejo18466 for ; Wed, 28 Feb 2001 22:02:51 GMT Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Wed, 28 Feb 2001 22:02:39 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <1RBR87LR>; Wed, 28 Feb 2001 22:03:55 -0000 Message-ID: To: akyol@pluris.com Cc: mpls@UU.NET Subject: RE: Expanded ERO draft Date: Wed, 28 Feb 2001 22:03:58 -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 Bora....I read the draft and did indeed note that backwards compatibility had been addressed. However, I raised this issue since it had not come up in discussion, and if there was a valid reason to object to the proposal this would be it. If this is not the case, then I cannot see any strong reason for *technical* objection. It therefore seems to me that the matter should be decided on the basis of whether the EERO solves any problems/deficiencies of the existing ERO case. I think that is the key challenge. BTW - The issue I raised in the previous mail on fast-prot-sw is still valid IMO, though we can park that for now since its a different problem. regards, Neil > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: 28 February 2001 15:35 > To: neil.2.harrison@bt.com > Cc: kireeti@juniper.net; eric.gray@sandburst.com; mpls@UU.NET; > vkompella@JasmineNetworks.com; yakov@juniper.net > Subject: RE: Expanded ERO draft > > > > Neil > > Just to follow up on your email: > > 1) There are no backwards compatibility issues by using the EERO. We > devoted a section of the draft to this matter. The main reason for > defining a new object was to avoid backwards compatibility issues. > > 2) The main motivation for this draft is to make ERO > processing simpler > and to make parsing of an ERO quick and "obvious" > > I think just the clarity of the EERO sub-objects is worth > thinking more > seriously about this draft. > > Bora > > On Wed, 28 Feb 2001 neil.2.harrison@bt.com wrote: > > > Kireeti Kompella [mailto:kireeti@juniper.net] asked on 27 > February 2001 > > 22:24 > > > Who all think that adding a router ID to the unnumbered > ERO subobject > > > would be beneficial? A simple yes, no or don't care, please. > > > > I don't think a simple Y/N/DC vote is good enough....the > vote has to be > > supported by rationale. > > > > Having carefully followed the discussion I come to the > conclusion that (i) > > there appear to be some advantages to doing what Bora et al > are advocating, > > and (ii) there are no technical disadvantages (or at least > none have been > > stated that I can see....other than a clear reluctance from > a few parties to > > accept a change, which is fair enough if there are serious backwards > > compatibility issues). > > > > Having said that..... > > I think the biggest advantage is *clarity* of nodal identifier and > > interface. I am reluctant to buy too hard into the > fast-reroute arguments > > since: > > - it will not cater for all possible failure modes (but > only, I assume > > , below MPLS-layer failures, eg SDH) > > - since an intermediate LSR in a LSP is *not* a trail termination > > point there are some defect handling issues that are not > being considered, > > eg there should be a FDI from the failed LSP segment which > gets merged with > > the 'new' (rerouted) LSP segment.....and since the CV flow > will split (at > > point where new reroute starts) to take the new rerouted > segment then > > (ideally) the FDI should be suppressed from the failed > segment at the > > downstream merge point. > > > > The above can be circumvented by always establishing a > completely new > > server-layer LSP between the nodes where one wants to establish a > > prot-route....and this would have its own CV flow, disjoint from the > > (protected) segment of the client LSP. > > > > So, in conclusion: > > - do it for clarity *and* if true technical benefits result > > - don't do it if any backwards compatibility is evident > and there are > > no strong benefits....so are any backwards compatibility problems? > > - don't do it for fast-rereoute reasons since (IMO) such a device > > appears to be architecturally flawed. > > > > neil > > > From owner-mpls@UU.NET Wed Feb 28 17:40:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29510 for ; Wed, 28 Feb 2001 17:40: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 QQkejq00058; Wed, 28 Feb 2001 22:39:29 GMT Received: by mail-control.mail.uu.net id QQkejq02807 for mpls-outgoing; Wed, 28 Feb 2001 22:39: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 QQkejq02793 for ; Wed, 28 Feb 2001 22:39:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkejq17040 for ; Wed, 28 Feb 2001 22:38:26 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkejq13155 for ; Wed, 28 Feb 2001 22:38:26 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 7A4D894006; Wed, 28 Feb 2001 17:38:22 -0500 (EST) Message-ID: <3A9D7DDE.3E48979@sandburst.com> Date: Wed, 28 Feb 2001 17:38:22 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben Black Cc: mpls@UU.NET Subject: Re: MTU Signalling Extensions for LDP References: <20010221164932.B50026@layer8.net> <3A953FFC.DF819168@sandburst.com> <20010228130500.A96372@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ben, Please see embedded comments/responses below... You wrote: > On Thu, Feb 22, 2001 at 11:36:12AM -0500, Eric Gray wrote: > > > > Section 2.1 item 1)a): > > --------------------- > > > > The egress LSR would know what interface it will be using > > to forward packets it receives on an LSP (otherwise, it would > > not have advertised reachability for the FEC for this LSP, and > > it would be required to refuse a corresponding LSP request). > > It will know what the MTU is for that interface. Therefore, > > it should provide a "real" MTU rather than 0xffff. > > > > The MTU in question is for the LSP, not the end to end path for a > given FEC. What happens to packets outside the MPLS domain, which > I believe the unlabeled side of an LER is, is not a concern when > determining the MTU within the MPLS domain. Bitten by the "end-to-end" bug. The devices at either end of an LSP are typically not hosts and - I believe - are responsible for forwarding packets. I can see that existing MTU discovery mechanisms will discover the MTU limitations for non-MPLS packets, but it seems to be silly for an LSR implementation to advertise a maximum MTU size for LSPs that is greater than the maximum IP packet MTU size (plus the size of the MPLS shim header) for the interface on which it will forward packets once it gets them. In the below diagram, assume 'R' nodes are non-MPLS routers (WRT a [set of] LSPs) and 'L' nodes are LSRs. ---- R1 --- L2 --- L3 --- L4 --- R5 --- If R5 is the next hop with respect to a particular LSP for L4, then L4 knows what the MAX MTU size is for IP packets it will forward to R5 and can add to this number the number of bytes that will be present in label(s) associated with any specific LSP. It seems to me that this should be the MTU that it would advertise to L3 for any LSPs that proceed from L3 to L4 that are associated with a FEC for which R5 is the next hop. Is there a reason why this is not true, or an example of when it would not be true? Assuming that this is true, then - if you would like to avoid strobing or rippling the network with LSP setup traffic, you would want to reverse the sense of MTU advertising that you do. IOW, you would want to announce a known MTU only when the announcement comes from an egress LSR (and may be modified by "better knowledge" on the way). You could invent a new usage and have an egress LSR provide 0xffff while non-egress LSRs initially use 0x0000 (to mean MTU unknown) - but doing this would seem to be an attempt to hide correct information about the LSP. One argument I feel you could make is that changing the interface on which the egress LSR will forward non-MPLS packets would result in the same sort of strobing. However, this would only be the case if the MTU size of the new interface is smaller. Hence, the new, smaller, MTU size would have to be discovered the hard-way using IP MTU size discovery edge-to-edge. I think the MPLS approach you are suggesting is intended to be better than the old trial and error approach, so why not take it as far as it can legitimately go? > > > > An LSR should be permitted, by wording in the specification, > > to use either the MTU of the interface it will forward packets > > on, or the minimum of a set of interfaces (up to and including > > all interfaces) over which it might forward the packet. > > > > This issue was previously raised and I neglected to include it. I > will make appropriate changes. Okay. > > > > > > Section 2.1 item 1)b): > > --------------------- > > > > Applying the reasoning above, an LSR that is not the egress > > for a FEC should not include an MTU TLV (or it should include a > > TLV with an "unknown" MTU) until it receives a label mapping from > > a downstream LSR that does include an MTU TLV with a "real" MTU. > > In order to include information about the ability to negotiate LSP > > MTU, a non-egress LSR might advertise an MTU of either 0x0000 or > > 0xffff to indicate that it currently does not know the MTU for the > > LSP downstream. > > > > Perhaps it was not stated clearly enough, but 0xffff is the unknown > MTU value. It indicates that MTU signaling is supported, and acts > as a placeholder. Okay. > > > > > > Section 2.1 item 1)c): > > --------------------- > > > > If the above approach is bought into, the case where an LSR > > receives a label mapping which does not contain an MTU TLV becomes > > the example of the backward compatibility case (an existing LSR > > will not include this TLV) and indicates that there is no end to > > end MTU negotiation capability for this LSP. At this point, my > > thinking is that this should be refelected all the way to the > > ingress (for example, to allow the ingress to "prefer" an LSP > > which does have MTU negotiation) by omission of the MTU TLV in > > all label mappings issued corresponding to this downstream LSP. > > I could be persuaded that this is not a good idea, however - if > > there are sound (or numerous) arguments against it. > > > > My thinking was that partial information is better than no information > (which is the current state of things). My calculating the MTU at each > hop, the ingress LSR can learn some approximation of the path MTU, > which may be correct, but will be no worse off than if it had no MTU > information. I see the advantage of your suggestion to allow > differentiation between end to end known MTU and partial path MTU, but > I am not sure how to fit that into the hop by hop model of the draft. Let's assume that the LSRs in the hop-by-hop MPLS domain are using hop count. Doesn't it seem a bit inconsistent to include a known MTU size and an unknown hop-count? Even in a more general sense, however, the same concern that applied to hop-count applies to MTU size as well - i.e. - use of a known MTU size in each subsequent advertisement can result in excessive rippling of LDP messages when using the downstream unsolicited and independent control modes. > > > > Also, in the event that (using independent mode) the LSR has > > previously provided label mappings that includes an MTU TLV of > > "unknonw" MTU size, it must send new label mappings which omit > > this TLV. > > > > I don't understand this point. If, as you stated above, you are using the inclusion of an MTU TLV as an indication of MTU size negotiation capability, then - when an LSR receives a label mapping from a downstream LSR that will be the next hop for a (set of) LSP(s) - it now knows that this capability does not exist downstream. If the intention in including the TLV is to let upstream LSRs know that this capability exists, then the newly discovered incapability must be announced to the upstream LSRs as well. > > > > Section 2.1 item 1)d): > > --------------------- > > > > The meaning of "neighbor to which it is not directly > > connected" is a little obscure for me. If the neighbor is > > connected via some sort of logical link, then an LSR should > > be smart enough to use the MTU corresponding to the logical > > link. Is this what you are saying? If so, it applies - I > > believe - more generally than to the LSP case. For example, > > there may be different MTU sizes associated with different > > VLAN tags and it is likely (in the Ethernet case) that there > > will be different MTU sizes depending on the next-hop (MAC > > address) - somewhat independent of the physical interface. > > > > Yes, that wording has tripped several people up and I will work to > come up with a better phrase. Okay. > > > > > > Section 2.2: > > ----------- > > > > Why is the "Reserved" field included? > > > > It was originally there to hold a stack depth counter, but this was > removed early on. THe reserved field could be safely eliminated. Okay. > > > > The 'U' and 'F' bits are set correctly (IMO), but there > > may be some value in mentioning why they are set this way. > > > > Agreed. > > > Section 5: > > --------- > > > > The procedures in this specification do introduce a new > > security issue: it is now possible to introduce a new type > > of "attack" in which a forged TCP segment contains an MTU > > TLV with an incorrect value. For example, an attacker may > > insert a TLV with an MTU one smaller than the last MTU > > advertised (forcing new advertisements to be strobed upstream) > > and continue in this vein until the MTU reaches zero. > > > > The procedures defined in RFC 3036, however, provide some > > protection against such an attack. Hence, while a new hazard > > is introduced, the risk of an attack in general is not increased. > > > > I believe the statement that no _new_ security issues are introduced > is accurate, as the ability to inject forged TCP segments raises > security issues for numerous components of LDP. I see the direction of your argument. The question is whether or not a new form of attack constitutes a new issue if the mechanism to combat this form of attack is both a) already in use or defined for defense against existing attack opportunities and b) fool-proof. I believe this same argument could have been stretched to apply to LDP since the mechanism used there is lifted bodily from BGP. Your call, but be prepared to defend your position. :-) Just remember that the term "fool-proof" is usually evidence of a lack of awareness of the resourcefulness of the average fool... > > > Thank you for the detailed feedback. > > Ben From owner-mpls@UU.NET Wed Feb 28 17:50:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00011 for ; Wed, 28 Feb 2001 17:50: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 QQkejr06865; Wed, 28 Feb 2001 22:50:03 GMT Received: by mail-control.mail.uu.net id QQkejr04175 for mpls-outgoing; Wed, 28 Feb 2001 22:49:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkejr04141 for ; Wed, 28 Feb 2001 22:49:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkejr05721 for ; Wed, 28 Feb 2001 22:48:51 GMT Received: from evita2.cs.fredonia.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: evita2.cs.fredonia.edu [141.238.30.9]) id QQkejr04303 for ; Wed, 28 Feb 2001 22:48:51 GMT Received: from Zubairi.cs.fredonia.edu (zubairi.cs.fredonia.edu [141.238.30.211]) by evita2.cs.fredonia.edu (8.9.3/8.9.3) with ESMTP id RAA11474 for ; Wed, 28 Feb 2001 17:48:50 -0500 Message-ID: <07f101c0a1d8$ea4a0020$d31eee8d@cs.fredonia.edu> From: "Junaid Ahmed Zubairi" To: References: Subject: extended abstracts due March 12th Date: Wed, 28 Feb 2001 17:50:48 -0500 Organization: SUNY/Fredonia 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 extended abstract due March 12th CALL FOR PAPERS INVITED SESSION ON BANDWIDTH AND SERVICE QUALITY MANAGEMENT IN THE INTERNET 5th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI 2001) Orlando, Florida, USA July 22-25, 2001 Scope Internet is undergoing a major transformation from being a best effort network to a well organized and well managed system with built-in intelligent protocols to provide predictable performance. Internet Engineering Task Force (IETF) has developed and incorporated a number of new protocols and techniques for managing and allocating network bandwidth and supporting service quality. For bandwidth allocation and management, COPS (Common Open Policy Service) clients and servers work to convey policy decisions and allocate and recover bandwidth across a domain. For QoS, RSVP provides quantitative guarantees by reserved paths and Diffserv provides qualitative assurances by using PHB (per hop behavior) and PDB (per domain behavior) for packets marked with DSCP (DS codepoints). MPLS installs LSP's (Label Switched Path) that satisfy Traffic Engineering requirements. As LSP's are set up and released, the available bandwidth metrics for various links are updated to reflect the current state of the network. An invited session on managing bandwidth and service quality through these new protocols and techniques is being organized at the SCI'2001 conference. This session will serve as a forum to present and discuss the latest research and simulation results of works by researchers and developers across the world. Topics of interest include, but are not limited to: Bandwidth management with COPS and MPLS Effects of shaping and packet coloring on multimedia streams Integrated operation of Intserv and Diffserv Aggregation of flows for scaling of RSVP VoIP performance over Diffserv networks Traffic Engineering architecture for the Internet Impact of congestion resolution schemes on QoS traffic Voice over MPLS Performance of RSVP-MPLS architecture FR/MPLS Network and service interworking Inter-provider MPLS signaling and LSP routing Inter-domain tunneling rules COPS Policy Server/Bandwidth Broker implementation issues Paper Submission Extended abstracts or paper drafts should be sent as per the following format: 1. Extended abstract of 500 to 1500 words or paper drafts of 2000 to 2500 words, in English. 2. Names, addresses, telephone numbers, fax numbers and e-mail addresses of all authors, with the name of the contact author underlined. The abstracts or papers can be submitted in ps or pdf format to session organizer at zubairi@cs.fredonia.edu by March 12th, 2001 via email. Proceedings Accepted papers, which should not exceed six single-spaced typed pages, will be published by means of paper and electronic proceedings. Best papers will be selected for awards and recommended for journal publications. Multiple author books will be published by IIIS, based on the best-invited sessions, the best focus symposia or the best mini-conferences Session Organizer: Dr. Junaid Ahmed Zubairi Department of Mathematics and Computer Science College at Fredonia, State University of New York Fredonia, NY 14063, USA Tel: +1-716-673-4694 Fax: +1-508-256-8324 Email: zubairi@cs.fredonia.edu WWW: http://www.cs.fredonia.edu/~zubairi Session Co-organizer: Wajdi Al-Khateeb Electrical and Computer Engineering Department Kulliyyah of Engineering, Intl' Islamic University Malaysia Jalan Gombak, Kuala Lumpur 53100, Malaysia Tel: +603-2056-4574 Fax: +603-2056-4853 Email: wajdi@iiu.edu.my Important Dates: Extended Abstract/Draft Paper due: March 12th, 2001 Notification of Acceptance: March 20th, 2001 Camera read copy due: April 13th, 2001 If you have questions concerning session paper submission or session content, please contact the invited session organizers at the addresses above. If you have questions concerning conference paper submissions or program, please contact Conference General Chair Prof. Nagib Callaos by email at ncallaos@usb.ve (Academic) or ncallaos@aol.com (Personal). For further information, see conference web site at http://www.iiis.org/sci From owner-mpls@UU.NET Wed Feb 28 18:16:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00988 for ; Wed, 28 Feb 2001 18:16: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 QQkejt00852; Wed, 28 Feb 2001 23:15:25 GMT Received: by mail-control.mail.uu.net id QQkejs22210 for mpls-outgoing; Wed, 28 Feb 2001 23:14:51 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 QQkejs22194 for ; Wed, 28 Feb 2001 23:14:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejs13327 for ; Wed, 28 Feb 2001 23:13:38 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkejs23862 for ; Wed, 28 Feb 2001 23:13:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA26727 for mpls@uu.net; Wed, 28 Feb 2001 18:13:36 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkejs22091 for ; Wed, 28 Feb 2001 23:12:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkejs09177 for ; Wed, 28 Feb 2001 23:11:20 GMT Received: from shell-beach.layer8.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQkejs25111 for ; Wed, 28 Feb 2001 23:11:16 GMT Received: (qmail 98565 invoked by uid 1000); 28 Feb 2001 23:05:14 -0000 Date: Wed, 28 Feb 2001 15:05:14 -0800 From: Ben Black To: Eric Gray Cc: mpls@UU.NET Subject: Re: MTU Signalling Extensions for LDP Message-ID: <20010228150513.D96372@layer8.net> References: <20010221164932.B50026@layer8.net> <3A953FFC.DF819168@sandburst.com> <20010228130500.A96372@layer8.net> <3A9D7DDE.3E48979@sandburst.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A9D7DDE.3E48979@sandburst.com>; from eric.gray@sandburst.com on Wed, Feb 28, 2001 at 05:38:22PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk Comments in-line... On Wed, Feb 28, 2001 at 05:38:22PM -0500, Eric Gray wrote: > > Assuming that this is true, then - if you would like to avoid strobing > or rippling the network with LSP setup traffic, you would want to > reverse the sense of MTU advertising that you do. IOW, you would > want to announce a known MTU only when the announcement comes > from an egress LSR (and may be modified by "better knowledge" on > the way). You could invent a new usage and have an egress LSR > provide 0xffff while non-egress LSRs initially use 0x0000 (to mean > MTU unknown) - but doing this would seem to be an attempt to > hide correct information about the LSP. > If the egress LSR is basing its MTU on the egress link MTU, then why would it ever need to advertise 0xffff? > One argument I feel you could make is that changing the interface > on which the egress LSR will forward non-MPLS packets would > result in the same sort of strobing. However, this would only be > the case if the MTU size of the new interface is smaller. Hence, > the new, smaller, MTU size would have to be discovered the > hard-way using IP MTU size discovery edge-to-edge. I think > the MPLS approach you are suggesting is intended to be better > than the old trial and error approach, so why not take it as far as > it can legitimately go? > Actually, this approach is intended to allow the existing mechanism, path MTU detection, to function properly. I prefer to see LSPs as virtual circuits just as in FR or ATM, for this application. This draft does exactly that, and nothing more. It seems to me that you are suggesting a fairly minor change (using the egress link MTU) which makes the LSP MTU not quite the LSP MTU. This might be a semantic nit, but I don't see a strong reason to deviate from the meaning of MTU for existing VC technologies. > > > > My thinking was that partial information is better than no information > > (which is the current state of things). My calculating the MTU at each > > hop, the ingress LSR can learn some approximation of the path MTU, > > which may be correct, but will be no worse off than if it had no MTU > > information. I see the advantage of your suggestion to allow > > differentiation between end to end known MTU and partial path MTU, but > > I am not sure how to fit that into the hop by hop model of the draft. > > Let's assume that the LSRs in the hop-by-hop MPLS domain are > using hop count. Doesn't it seem a bit inconsistent to include a > known MTU size and an unknown hop-count? > They are orthogonal functions, so I don't see any inconsistency. > Even in a more general sense, however, the same concern that > applied to hop-count applies to MTU size as well - i.e. - use > of a known MTU size in each subsequent advertisement can > result in excessive rippling of LDP messages when using the > downstream unsolicited and independent control modes. > Do you mean re-advertisement of an unchanged MTU value? > > > > > > > Also, in the event that (using independent mode) the LSR has > > > previously provided label mappings that includes an MTU TLV of > > > "unknonw" MTU size, it must send new label mappings which omit > > > this TLV. > > > > > > > I don't understand this point. > > If, as you stated above, you are using the inclusion of an MTU TLV > as an indication of MTU size negotiation capability, then - when an > LSR receives a label mapping from a downstream LSR that will be > the next hop for a (set of) LSP(s) - it now knows that this capability > does not exist downstream. > > If the intention in including the TLV is to let upstream LSRs know > that this capability exists, then the newly discovered incapability > must be announced to the upstream LSRs as well. > Simply not advertising the MTU TLV can convey this. Do we see no use in having partial MTU information? > > Just remember that the term "fool-proof" is usually evidence of a > lack of awareness of the resourcefulness of the average fool... > No more fool-proof than the rest of the protocol. I make no claims as to the strength of the existing protocol mechanisms. Ben From owner-mpls@UU.NET Wed Feb 28 19:42:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03555 for ; Wed, 28 Feb 2001 19:42: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 QQkejy23542; Thu, 1 Mar 2001 00:41:49 GMT Received: by mail-control.mail.uu.net id QQkejy16252 for mpls-outgoing; Thu, 1 Mar 2001 00:41: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 QQkejy16216 for ; Thu, 1 Mar 2001 00:41: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 QQkejy08053 for ; Thu, 1 Mar 2001 00:40:26 GMT Received: from imchub1.cosinecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imchub1.cosinecom.com [63.88.104.18]) id QQkejy26918 for ; Thu, 1 Mar 2001 00:40:25 GMT Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 16:40:31 -0800 Received: from cosinecom.com (HOME [192.168.210.10]) by exchsrv1.cosinecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQ0GBQJR; Wed, 28 Feb 2001 16:37:43 -0800 From: Tatsuya Yanagibashi Cc: narakasura Dumbo , mpls@UU.NET Message-ID: <3A9D9A60.D8F0C57E@cosinecom.com> Date: Thu, 01 Mar 2001 09:40:00 +0900 X-Mailer: Mozilla 4.75 [ja] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 Subject: Re: RSVP & OSPF-TE ... References: <20010228200826.92714.qmail@web12810.mail.yahoo.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Pappai, narakasura Dumbo wrote: > > I have a couple of questions > > 1. How do we signal the "color" (32 colors that > can be assigned to a link, Katz OSPF-TE draft) > using RSVP-TE ? Is this addressed somewhere ? Conceptually the information of TE such like a "color" is used for calculating the PATH under administrative constraints in MPLS cloud. Currently CSPF is able to handle its calculation. After its computation and calculation, Ingress LSR is going to SIGNAL by using RSVP-TE or CR-LDP with ER(O) along the path by CSPF calculation. Rgds, Tatsuya -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +----+----+ Tatsuya Yanagibashi |.. .| | |_~__| | Network Consultant | .. |~~_~| CoSine Communications Inc. | . | | +----+----+ e-mail: tyanagibashi@cosinecom.com C o S i n e Phone # +81-3-5219-1292 Communications Fax # +81-3-5219-1201 /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-mpls@UU.NET Wed Feb 28 19:47:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03707 for ; Wed, 28 Feb 2001 19:47: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 QQkejz05482; Thu, 1 Mar 2001 00:46:58 GMT Received: by mail-control.mail.uu.net id QQkejz16877 for mpls-outgoing; Thu, 1 Mar 2001 00:46:15 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 QQkejz16848 for ; Thu, 1 Mar 2001 00:46: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 QQkejz23130 for ; Thu, 1 Mar 2001 00:45:21 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f29.pav1.hotmail.com [64.4.31.29]) id QQkejz08791 for ; Thu, 1 Mar 2001 00:45:21 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Feb 2001 16:45:20 -0800 Received: from 63.116.202.66 by pv1fd.pav1.hotmail.msn.com with HTTP; Thu, 01 Mar 2001 00:45:20 GMT X-Originating-IP: [63.116.202.66] From: "Rakesh Tiwari" To: sachin@siliconsystems.co.in, mpls@UU.NET Subject: Re: Query Date: Thu, 01 Mar 2001 00:45:20 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Mar 2001 00:45:20.0906 (UTC) FILETIME=[E4C64EA0:01C0A1E8] Sender: owner-mpls@UU.NET Precedence: bulk see the coments below: From: Sachin Doshi To: mpls@UU.NET Subject: Query Date: Wed, 28 Feb 2001 21:27:38 +0530 Can someone answer these: 1. Is it possible that on a LAN where R1 (router/switch) is connected to R3 (router/switch) through R2(router/switch), there is a LSP which has only R1 and R3 as LSR's not R2 (assuming that R1,R2 and R3 all are MPLS capable). >>it is possible provided there is another path from R1 to R3. 2. If a LSR receives a MPLS packet which was not directed to him (mac DA was not this LSR's address), what should it do with the packet? Should it switch the packet based on the L2 address or is it allowed to switch it based on the MPLS label? >>packet should be swithced on the basis of L2 address in this case! regards, sachin _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.