From owner-mpls@UU.NET Tue Jul 1 01:06:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01743 for ; Tue, 1 Jul 2003 01:06:04 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovkm18850 for ; Tue, 1 Jul 2003 05:06:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovkm18760; Tue, 1 Jul 2003 05:06:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQovjg21501 for mpls-outgoing; Mon, 30 Jun 2003 21:01:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovjg21376 for ; Mon, 30 Jun 2003 21:01: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 QQovjg29468 for ; Mon, 30 Jun 2003 21:00:45 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjg06941 for ; Mon, 30 Jun 2003 21:00:45 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovjg06934 for ; Mon, 30 Jun 2003 21:00:44 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UL0gg5017326 for ; Mon, 30 Jun 2003 17:00:42 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI01521; Mon, 30 Jun 2003 17:00:42 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5UL0ga07132 for mpls@uu.net; Mon, 30 Jun 2003 17:00:42 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovje08959 for ; Mon, 30 Jun 2003 20:36: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 QQovje13572 for ; Mon, 30 Jun 2003 20:36:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovje02582 for ; Mon, 30 Jun 2003 20:36:33 GMT Received: from sj-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQovje02548 for ; Mon, 30 Jun 2003 20:36:33 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UKaPIn006809; Mon, 30 Jun 2003 13:36:26 -0700 (PDT) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH99898; Mon, 30 Jun 2003 16:36:24 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA27442; Mon, 30 Jun 2003 16:36:24 -0400 (EDT) Message-Id: <200306302036.QAA27442@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Adrian Farrel" reply-to: nobody@cisco.com cc: mpls@UU.NET Subject: [Alex Zinin: draft-ietf-mpls-ldp-restart-applic approved] Date: Mon, 30 Jun 2003 16:36:24 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk FYI - ------- Forwarded Message Return-Path: Received: from flask.cisco.com [161.44.122.62] by localhost with POP3 (fetchmail-5.6.5) for swallow@localhost (single-drop); Mon, 30 Jun 2003 14:48:25 -0400 (EDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH90346; Mon, 30 Jun 2003 14:26:37 -0400 (EDT) Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5UIQP2K028234 for ; Mon, 30 Jun 2003 11:26:30 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by sj-inbound-1.cisco.com (8.12.8p1/8.11.2) with ESMTP id h5UIQS7Y007196 for ; Mon, 30 Jun 2003 11:26:29 -0700 (PDT) Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19X3M1-000BqY-M7; Mon, 30 Jun 2003 18:26:17 +0000 Date: Mon, 30 Jun 2003 11:25:47 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6747137570.20030630112547@psg.com> To: George Swallow , Loa Andersson CC: "Wijnen, Bert (Bert)" Subject: draft-ietf-mpls-ldp-restart-applic approved MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI, the doc in subj has been approved last Thursday. Feel free to share the news. - -- Alex http://www.psg.com/~zinin/ ------- End of Forwarded Message From owner-mpls@UU.NET Tue Jul 1 01:14:20 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01920 for ; Tue, 1 Jul 2003 01:14:20 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovkm03149 for ; Tue, 1 Jul 2003 05:14:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovkm02986; Tue, 1 Jul 2003 05:14:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQovjl24209 for mpls-outgoing; Mon, 30 Jun 2003 22:20:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovjl23863 for ; Mon, 30 Jun 2003 22:15:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovjk24678 for ; Mon, 30 Jun 2003 22:14:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjk18851 for ; Mon, 30 Jun 2003 22:14:05 GMT Received: from ckmso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQovjk18841 for ; Mon, 30 Jun 2003 22:14:04 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5UMB3B4026520 for ; Mon, 30 Jun 2003 18:14:04 -0400 Received: from OCCLUST03EVS1.ugd.att.com (135.38.164.10) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C006CE568; Mon, 30 Jun 2003 18:13:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on the LDP MIB requirement Date: Mon, 30 Jun 2003 17:14:03 -0500 Message-ID: <1C9A50113894DC459E8AF995EC23112E036A2459@OCCLUST03EVS1.ugd.att.com> Thread-topic: comment on the LDP MIB requirement Thread-index: AcM/Swtzf2eTxSEnQzy3a4coVYXkowABrGCw From: "Chung, Li-Jin W, ALABS" To: , "Ash, Gerald R (Jerry), ALABS" , "Loa Andersson" , "MPLS WG" Cc: "George Swallow" , "Lai, Wai S (Waisum), ALABS" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable Tom, Thank you for your clarification. Please see my added notes.=20 Li Chung -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Monday, June 30, 2003 5:01 PM To: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS; 'Loa Andersson'; 'MPLS WG' Cc: 'George Swallow'; Lai, Wai S (Waisum), ALABS Subject: RE: comment on the LDP MIB requirement > -----Original Message----- > From: Chung, Li-Jin W, ALABS [mailto:lic@att.com]=20 > Sent: Monday, June 30, 2003 4:36 PM > To: tnadeau@cisco.com; Ash, Gerald R (Jerry), ALABS; Loa=20 > Andersson; MPLS WG > Cc: George Swallow; Lai, Wai S (Waisum), ALABS > Subject: RE: comment on the LDP MIB requirement >=20 >=20 > Tom, >=20 > Just to set the record straignt, this is my recollection of=20 > what I did last year. > (1) I did not present any thing at all. Your draft was published first shortly before the MIB doctor meeting in Atlanta. >> yes, but did not given a chance to present.=20 > (2) I do not know what change that you are referring here.=20 You asked us to add the ifIndex to the sessionDown/up notifications in the LDP MIB, which being a non-major change, we all agreed could be made. >> Yes, thank you.=20 > (3) As far as I remember, no agreement was reached at last=20 > year's meeting.=20 Then I suggest you to re-read the meeting minutes. There were definite agreements made, as I mentioned. Specifically, the chair of the meeting suggested=20 (and we all agreed to this) that the purpose of the meeting was to get the existing MIBs into shape. This did NOT include any enhancements (many of which were proposed in your ID). Instead, it was noted that these would be put off as future work. >> OK. So, one year has passed by and how much more "put off" that we can afford to wait. I would suggest that we put those enhancements proposal on the table again for managability sake (its about time). As you already know, we, as a service provider, need those capabilities to manage our MPLS network.=20 --Tom > Thanks, >=20 > Li Chung >=20 > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Sunday, June 29, 2003 3:56 PM > To: Ash, Gerald R (Jerry), ALABS; 'Loa Andersson'; 'MPLS WG' > Cc: 'George Swallow'; Lai, Wai S (Waisum), ALABS; Chung,=20 > Li-Jin W, ALABS > Subject: RE: comment on the LDP MIB requirement >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > Of Ash, Gerald R (Jerry), ALABS > > Sent: Thursday, June 26, 2003 12:41 PM > > To: Loa Andersson; MPLS WG > > Cc: Ash, Gerald R (Jerry), ALABS; George Swallow; Lai, Wai S=20 > > (Waisum), ALABS; Chung, Li-Jin W, ALABS > > Subject: RE: comment on the LDP MIB requirement > >=20 > >=20 > > Loa, All, > >=20 > > > I had to read back a bit to understand the impact of the=20 > input from > > > Wai Sum and Jerry. The working group last call has ended=20 > > but I would > > > nevertheless like to make this comment: > > >=20 > > > - the draft-lai-mpls-mib-rqmts-00.txt includes requirements that > > > will make changes to the LDP necessary > >=20 > > Loa, I'm surprised that you would just parrot this claim > > without technical backup. This is merely an unsubstantiated=20 > > assertion by 2 of the MPLS MIB authors, to deflect the=20 > > requirements in yet one more creative way. No response was=20 > > made to Eric Gray's post requesting specifics to back this up=20 > > http://cell.onecall.net/mhonarc/mpls/current/msg00130.html. > >=20 > > Various posts over the past year have requested specific MPLS > > MIB extensions to meet identified gaps (see below). When the=20 > > specifics were rejected, then a different approach was tried=20 > > to request designers to propose enhancements to meet=20 > > requirements=20 > > http://cell.onecall.net/mhonarc/mpls/2003-May/msg00006.html,=20 > > again without any forward motion. =20 > >=20 > > Despite all this effort to meet a few critical SP > > requirements, no attempt has been made to address the=20 > > requirements or the specific MIB enhancement proposals: > >=20 > > Li Chung initially posted specific enhancements/needs to the > > MPLS list on June 27, 2002=20 > > http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00159.html. =20 > > Go back and review the thread, the specific extensions were=20 > > not addressed. > >=20 > > Wai Sum Lai initially posted to the ppvpn list on August 19, > > 2002 (message attached below, ppvpn archives don't go back=20 > > that far). The specific extensions were not addressed, Tom=20 > > requested and got substantiation of the needs, but that was=20 > > the end of the discussion. > >=20 > > > - the LDP MIB is based on the current LDP spec, thus it is my take > > > that the draft is outside the scope of the current last call > >=20 > > No changes to the LDP spec are proposed or needed. Therefore > > the requirements and proposed extensions, made for one year=20 > > on the list, are well within the LDP MIB discussion window. =20 > > They merely haven't been seriously addressed. >=20 > Jerry,=20 >=20 > Let me parrot the meeting minutes from the > MIB doctor review meeting we had in Atlanta last=20 > Fall. The things proposed in the document in question were=20 > discussed at the MIB Doctor's meeting and it was decided and=20 > agreed upon at that time that we would not include any of=20 > the changes that Li presented (that now appear in this=20 > document) at that time. Instead, they were left for future=20 > study and/or inclusion in future I-Ds. We did in fact include=20 > one change that Li requested (that is not in the document in=20 > question), BTW. >=20 > --Tom >=20 >=20 >=20 From owner-mpls@UU.NET Tue Jul 1 01:18:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02005 for ; Tue, 1 Jul 2003 01:18:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovkn11628 for ; Tue, 1 Jul 2003 05:18:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovkn11536; Tue, 1 Jul 2003 05:18:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQovjh01588 for mpls-outgoing; Mon, 30 Jun 2003 21:25:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovjh01583 for ; Mon, 30 Jun 2003 21:25: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 QQovjh12301 for ; Mon, 30 Jun 2003 21:24:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjh07532 for ; Mon, 30 Jun 2003 21:24:38 GMT Received: from sj-core-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-5.cisco.com [171.71.177.238]) id QQovjh07515 for ; Mon, 30 Jun 2003 21:24:37 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5ULOYO0019069 for ; Mon, 30 Jun 2003 14:24:34 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI02960; Mon, 30 Jun 2003 17:24:33 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5ULOX207427 for mpls@uu.net; Mon, 30 Jun 2003 17:24:33 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovjg21723 for ; Mon, 30 Jun 2003 21:02:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovjg19932 for ; Mon, 30 Jun 2003 21:02:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjg09654 for ; Mon, 30 Jun 2003 21:02:34 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovjg09647 for ; Mon, 30 Jun 2003 21:02:34 GMT Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UL1ig5018050; Mon, 30 Jun 2003 17:01:44 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-24.cisco.com [10.86.242.24]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h5UL1c209729; Mon, 30 Jun 2003 17:01:38 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Chung, Li-Jin W, ALABS'" , "'Ash, Gerald R \(Jerry\), ALABS'" , "'Loa Andersson'" , "'MPLS WG'" Cc: "'George Swallow'" , "'Lai, Wai S \(Waisum\), ALABS'" Subject: RE: comment on the LDP MIB requirement Date: Mon, 30 Jun 2003 17:01:26 -0400 Organization: Cisco Systems Message-ID: <012f01c33f4a$ca752330$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1C9A50113894DC459E8AF995EC23112E036A2456@OCCLUST03EVS1.ugd.att.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Chung, Li-Jin W, ALABS [mailto:lic@att.com] > Sent: Monday, June 30, 2003 4:36 PM > To: tnadeau@cisco.com; Ash, Gerald R (Jerry), ALABS; Loa > Andersson; MPLS WG > Cc: George Swallow; Lai, Wai S (Waisum), ALABS > Subject: RE: comment on the LDP MIB requirement > > > Tom, > > Just to set the record straignt, this is my recollection of > what I did last year. > (1) I did not present any thing at all. Your draft was published first shortly before the MIB doctor meeting in Atlanta. > (2) I do not know what change that you are referring here. You asked us to add the ifIndex to the sessionDown/up notifications in the LDP MIB, which being a non-major change, we all agreed could be made. > (3) As far as I remember, no agreement was reached at last > year's meeting. Then I suggest you to re-read the meeting minutes. There were definite agreements made, as I mentioned. Specifically, the chair of the meeting suggested (and we all agreed to this) that the purpose of the meeting was to get the existing MIBs into shape. This did NOT include any enhancements (many of which were proposed in your ID). Instead, it was noted that these would be put off as future work. --Tom > Thanks, > > Li Chung > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Sunday, June 29, 2003 3:56 PM > To: Ash, Gerald R (Jerry), ALABS; 'Loa Andersson'; 'MPLS WG' > Cc: 'George Swallow'; Lai, Wai S (Waisum), ALABS; Chung, > Li-Jin W, ALABS > Subject: RE: comment on the LDP MIB requirement > > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > Of Ash, Gerald R (Jerry), ALABS > > Sent: Thursday, June 26, 2003 12:41 PM > > To: Loa Andersson; MPLS WG > > Cc: Ash, Gerald R (Jerry), ALABS; George Swallow; Lai, Wai S > > (Waisum), ALABS; Chung, Li-Jin W, ALABS > > Subject: RE: comment on the LDP MIB requirement > > > > > > Loa, All, > > > > > I had to read back a bit to understand the impact of the > input from > > > Wai Sum and Jerry. The working group last call has ended > > but I would > > > nevertheless like to make this comment: > > > > > > - the draft-lai-mpls-mib-rqmts-00.txt includes requirements that > > > will make changes to the LDP necessary > > > > Loa, I'm surprised that you would just parrot this claim > > without technical backup. This is merely an unsubstantiated > > assertion by 2 of the MPLS MIB authors, to deflect the > > requirements in yet one more creative way. No response was > > made to Eric Gray's post requesting specifics to back this up > > http://cell.onecall.net/mhonarc/mpls/current/msg00130.html. > > > > Various posts over the past year have requested specific MPLS > > MIB extensions to meet identified gaps (see below). When the > > specifics were rejected, then a different approach was tried > > to request designers to propose enhancements to meet > > requirements > > http://cell.onecall.net/mhonarc/mpls/2003-May/msg00006.html, > > again without any forward motion. > > > > Despite all this effort to meet a few critical SP > > requirements, no attempt has been made to address the > > requirements or the specific MIB enhancement proposals: > > > > Li Chung initially posted specific enhancements/needs to the > > MPLS list on June 27, 2002 > > http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00159.html. > > Go back and review the thread, the specific extensions were > > not addressed. > > > > Wai Sum Lai initially posted to the ppvpn list on August 19, > > 2002 (message attached below, ppvpn archives don't go back > > that far). The specific extensions were not addressed, Tom > > requested and got substantiation of the needs, but that was > > the end of the discussion. > > > > > - the LDP MIB is based on the current LDP spec, thus it is my take > > > that the draft is outside the scope of the current last call > > > > No changes to the LDP spec are proposed or needed. Therefore > > the requirements and proposed extensions, made for one year > > on the list, are well within the LDP MIB discussion window. > > They merely haven't been seriously addressed. > > Jerry, > > Let me parrot the meeting minutes from the > MIB doctor review meeting we had in Atlanta last > Fall. The things proposed in the document in question were > discussed at the MIB Doctor's meeting and it was decided and > agreed upon at that time that we would not include any of > the changes that Li presented (that now appear in this > document) at that time. Instead, they were left for future > study and/or inclusion in future I-Ds. We did in fact include > one change that Li requested (that is not in the document in > question), BTW. > > --Tom > > > From owner-mpls@UU.NET Tue Jul 1 01:25:46 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02158 for ; Tue, 1 Jul 2003 01:25:46 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovkn24066 for ; Tue, 1 Jul 2003 05:25:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovkn23977; Tue, 1 Jul 2003 05:25:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQovje08882 for mpls-outgoing; Mon, 30 Jun 2003 20:36:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovje08808 for ; Mon, 30 Jun 2003 20:36: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 QQovje25885 for ; Mon, 30 Jun 2003 20:35:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovje01187 for ; Mon, 30 Jun 2003 20:35:36 GMT Received: from almso1.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQovje01179 for ; Mon, 30 Jun 2003 20:35:35 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5UKHiqC002816 for ; Mon, 30 Jun 2003 16:35:35 -0400 Received: from OCCLUST03EVS1.ugd.att.com (135.38.164.10) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C006C5D44; Mon, 30 Jun 2003 16:35:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on the LDP MIB requirement Date: Mon, 30 Jun 2003 15:35:34 -0500 Message-ID: <1C9A50113894DC459E8AF995EC23112E036A2456@OCCLUST03EVS1.ugd.att.com> Thread-topic: comment on the LDP MIB requirement Thread-index: AcM+eMrImlny+BdcQbevZLob49h54QAzUQAA From: "Chung, Li-Jin W, ALABS" To: , "Ash, Gerald R (Jerry), ALABS" , "Loa Andersson" , "MPLS WG" Cc: "George Swallow" , "Lai, Wai S (Waisum), ALABS" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable Tom, Just to set the record straignt, this is my recollection of what I did last year. (1) I did not present any thing at all. (2) I do not know what change that you are referring here.=20 (3) As far as I remember, no agreement was reached at last year's meeting.=20 Thanks, Li Chung -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Sunday, June 29, 2003 3:56 PM To: Ash, Gerald R (Jerry), ALABS; 'Loa Andersson'; 'MPLS WG' Cc: 'George Swallow'; Lai, Wai S (Waisum), ALABS; Chung, Li-Jin W, ALABS Subject: RE: comment on the LDP MIB requirement > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf=20 > Of Ash, Gerald R (Jerry), ALABS > Sent: Thursday, June 26, 2003 12:41 PM > To: Loa Andersson; MPLS WG > Cc: Ash, Gerald R (Jerry), ALABS; George Swallow; Lai, Wai S=20 > (Waisum), ALABS; Chung, Li-Jin W, ALABS > Subject: RE: comment on the LDP MIB requirement >=20 >=20 > Loa, All, >=20 > > I had to read back a bit to understand the impact of the input from=20 > > Wai Sum and Jerry. The working group last call has ended=20 > but I would=20 > > nevertheless like to make this comment: > >=20 > > - the draft-lai-mpls-mib-rqmts-00.txt includes requirements that > > will make changes to the LDP necessary >=20 > Loa, I'm surprised that you would just parrot this claim=20 > without technical backup. This is merely an unsubstantiated=20 > assertion by 2 of the MPLS MIB authors, to deflect the=20 > requirements in yet one more creative way. No response was=20 > made to Eric Gray's post requesting specifics to back this up=20 > http://cell.onecall.net/mhonarc/mpls/current/msg00130.html. >=20 > Various posts over the past year have requested specific MPLS=20 > MIB extensions to meet identified gaps (see below). When the=20 > specifics were rejected, then a different approach was tried=20 > to request designers to propose enhancements to meet=20 > requirements=20 > http://cell.onecall.net/mhonarc/mpls/2003-May/msg00006.html,=20 > again without any forward motion. =20 >=20 > Despite all this effort to meet a few critical SP=20 > requirements, no attempt has been made to address the=20 > requirements or the specific MIB enhancement proposals: >=20 > Li Chung initially posted specific enhancements/needs to the=20 > MPLS list on June 27, 2002=20 > http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00159.html. =20 > Go back and review the thread, the specific extensions were=20 > not addressed. >=20 > Wai Sum Lai initially posted to the ppvpn list on August 19,=20 > 2002 (message attached below, ppvpn archives don't go back=20 > that far). The specific extensions were not addressed, Tom=20 > requested and got substantiation of the needs, but that was=20 > the end of the discussion. >=20 > > - the LDP MIB is based on the current LDP spec, thus it is my take > > that the draft is outside the scope of the current last call >=20 > No changes to the LDP spec are proposed or needed. Therefore=20 > the requirements and proposed extensions, made for one year=20 > on the list, are well within the LDP MIB discussion window. =20 > They merely haven't been seriously addressed. Jerry,=20 Let me parrot the meeting minutes from the MIB doctor review meeting we had in Atlanta last=20 Fall. The things proposed in the document in question were discussed at the MIB Doctor's meeting and it was decided and agreed upon at that time that we would not include any of=20 the changes that Li presented (that now appear in this document) at that time. Instead, they were left for future study and/or inclusion in future I-Ds. We did in fact include one change that Li requested (that is not in the document in question), BTW. --Tom From owner-mpls@UU.NET Tue Jul 1 01:34:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02364 for ; Tue, 1 Jul 2003 01:34:02 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouzh02622; Sat, 28 Jun 2003 04:22:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQouxj15455 for mpls-outgoing; Fri, 27 Jun 2003 15:47:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouxj15442 for ; Fri, 27 Jun 2003 15:47:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouxj19998 for ; Fri, 27 Jun 2003 15:46:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxj07139 for ; Fri, 27 Jun 2003 15:46:16 GMT Received: from jera.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQouxj07084 for ; Fri, 27 Jun 2003 15:45:51 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id E523D1114F for ; Fri, 27 Jun 2003 11:45:49 -0400 (EDT) Message-ID: <04b701c33cc3$2ee7d360$681810ac@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Subject: Nit in draft-ietf-mpls-tc-mib-07.txt Date: Fri, 27 Jun 2003 11:45:49 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B4_01C33CA1.A7B31B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_04B4_01C33CA1.A7B31B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No change in substance. Just a typo. Adrian TeHopAddress ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a generic Tunnel hop address. A TeHopAddress value is always interpreted within the context of an TeHopAddressType value. Every < usage of the TeHopInetAddress TEXTUAL-CONVENTION > usage of the TeHopAddress TEXTUAL-CONVENTION is required to specify the TeHopAddressType object which provides the context. It is suggested that ------=_NextPart_000_04B4_01C33CA1.A7B31B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No change in substance.
Just a typo.
 
Adrian
 
          = TeHopAddress ::=3D=20 TEXTUAL-CONVENTION
        &nb= sp;   =20 STATUS    =20 current
          &n= bsp; =20 DESCRIPTION
         &nbs= p;     =20 "Denotes a generic Tunnel hop address.
 
          &nbs= p;     =20 A TeHopAddress value is always interpreted=20 within
          &nb= sp;     =20 the context of an TeHopAddressType value.  Every
<=20             &= nbsp; =20 usage of the TeHopInetAddress=20 TEXTUAL-CONVENTION
>        = ;       =20 usage of the TeHopAddress=20 TEXTUAL-CONVENTION
        &nb= sp;       =20 is required to specify the TeHopAddressType=20 object
          &nb= sp;     =20 which provides the context.  It is suggested=20 that
------=_NextPart_000_04B4_01C33CA1.A7B31B00-- From owner-mpls@UU.NET Tue Jul 1 02:29:46 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15487 for ; Tue, 1 Jul 2003 02:29:46 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovkr10236 for ; Tue, 1 Jul 2003 06:29:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovkr10040; Tue, 1 Jul 2003 06:29:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQovjw15809 for mpls-outgoing; Tue, 1 Jul 2003 01:01:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovjw15729 for ; Tue, 1 Jul 2003 01:01: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 QQovjw26332 for ; Tue, 1 Jul 2003 01:01:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjw23232 for ; Tue, 1 Jul 2003 01:01:09 GMT Received: from sj-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQovjw23226 for ; Tue, 1 Jul 2003 01:01:08 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61115In025816 for ; Mon, 30 Jun 2003 18:01:06 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI12674; Mon, 30 Jun 2003 21:01:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h61114i12810 for mpls@uu.net; Mon, 30 Jun 2003 21:01:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovjv08993 for ; Tue, 1 Jul 2003 00:48:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovjv06668 for ; Tue, 1 Jul 2003 00:48:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjv08761 for ; Tue, 1 Jul 2003 00:48:11 GMT Received: from sj-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQovjv08722 for ; Tue, 1 Jul 2003 00:48:10 GMT Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h610m9Io017971 for ; Mon, 30 Jun 2003 17:48:09 -0700 (PDT) Date: Mon, 30 Jun 2003 17:48:08 -0700 (PDT) From: Prasad Maganti cc: mpls@UU.NET Subject: unsubscribe In-Reply-To: <001d01c33e52$e9577850$02ffa8c0@wilk> Message-ID: References: <001d01c33e52$e9577850$02ffa8c0@wilk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Tue Jul 1 06:23:45 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05286 for ; Tue, 1 Jul 2003 06:23:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovlh24598 for ; Tue, 1 Jul 2003 10:23:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovlh24435; Tue, 1 Jul 2003 10:23:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQovks19328 for mpls-outgoing; Tue, 1 Jul 2003 06:39:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovks19323 for ; Tue, 1 Jul 2003 06:39:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovks12912 for ; Tue, 1 Jul 2003 06:38:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovks24450 for ; Tue, 1 Jul 2003 06:38:18 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovks24445 for ; Tue, 1 Jul 2003 06:38:17 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h616c8gD017537 for ; Tue, 1 Jul 2003 02:38:09 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI37130; Tue, 1 Jul 2003 02:38:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h616c7o19779 for mpls@uu.net; Tue, 1 Jul 2003 02:38:07 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovks19267 for ; Tue, 1 Jul 2003 06:37:12 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 QQovks05881 for ; Tue, 1 Jul 2003 06:35:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovks04146 for ; Tue, 1 Jul 2003 06:35:22 GMT Received: from sj-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-3.cisco.com [171.68.223.137]) id QQovks04127 for ; Tue, 1 Jul 2003 06:35:21 GMT Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h616ZJvd006513 for ; Mon, 30 Jun 2003 23:35:19 -0700 (PDT) Received: from qliuw2k01 (dhcp-64-104-161-239.cisco.com [64.104.161.239]) by mira-kan-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AAA22142; Mon, 30 Jun 2003 23:35:16 -0700 (PDT) Message-ID: <127701c33f9a$ef9d1af0$c6a16840@amer.cisco.com> From: "Quanhe Liu" To: References: <001d01c33e52$e9577850$02ffa8c0@wilk> Subject: unsubscribe Date: Tue, 1 Jul 2003 14:35:15 +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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mpls@UU.NET Tue Jul 1 08:57:26 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16931 for ; Tue, 1 Jul 2003 08:57:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovlr18912 for ; Tue, 1 Jul 2003 12:57:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovlr18738; Tue, 1 Jul 2003 12:57:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQovlg03527 for mpls-outgoing; Tue, 1 Jul 2003 10:01:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovlg03488 for ; Tue, 1 Jul 2003 10:01:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovlg01697 for ; Tue, 1 Jul 2003 10:01:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovlg27777 for ; Tue, 1 Jul 2003 10:01:07 GMT Received: from sj-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQovlg27608 for ; Tue, 1 Jul 2003 10:00:59 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h61A0s2K004173 for ; Tue, 1 Jul 2003 03:00:55 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI56909; Tue, 1 Jul 2003 06:00:53 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h61A0rC23212 for mpls@uu.net; Tue, 1 Jul 2003 06:00:53 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovld25037 for ; Tue, 1 Jul 2003 09:26:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQovld14738 for ; Tue, 1 Jul 2003 09:26:29 GMT Received: from chi6-2.relay.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: chi6-2.relay.mail.uu.net [199.171.54.99]) id QQovld08648 for ; Tue, 1 Jul 2003 09:26:28 GMT Received: from SIEG-PC by chi6sosrv11.alter.net with ESMTP (peer crosschecked as: pool-68-160-111-243.nwrk.east.verizon.net [68.160.111.243]) id QQovld06675 for ; Tue, 1 Jul 2003 09:26:16 GMT From: Muhammad.Sarwar@tddny.fujitsu.com Message-Id: To: Subject: Re: Application Date: Tue, 1 Jul 2003 5:26:16 --0400 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0ED9914D" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0ED9914D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) Found virus WORM_SOBIG.E in file details.pif (in your_details.zip) The uncleanable file is deleted. If you are an internal Cisco employee, more information can be found at the following internal location: http://mailer.cisco.com/virus/ --------------------------------------------------------- --CSmtpMsgPart123X456_000_0ED9914D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_0ED9914D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) your_details.zip is removed from here because it contains a virus. --------------------------------------------------------- --CSmtpMsgPart123X456_000_0ED9914D-- From owner-mpls@UU.NET Tue Jul 1 09:11:23 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20687 for ; Tue, 1 Jul 2003 09:11:22 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovls06997 for ; Tue, 1 Jul 2003 13:11:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovls06832; Tue, 1 Jul 2003 13:11:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQovlm08819 for mpls-outgoing; Tue, 1 Jul 2003 11:30:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovlm08813 for ; Tue, 1 Jul 2003 11:30: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 QQovlm28980 for ; Tue, 1 Jul 2003 11:30:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovlm02382 for ; Tue, 1 Jul 2003 11:30:20 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovlm02372 for ; Tue, 1 Jul 2003 11:30:19 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61BUGg5018388 for ; Tue, 1 Jul 2003 07:30:17 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI59408; Tue, 1 Jul 2003 07:30:15 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h61BUFD24761 for mpls@uu.net; Tue, 1 Jul 2003 07:30:15 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovll08626 for ; Tue, 1 Jul 2003 11:24: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 QQovll02726 for ; Tue, 1 Jul 2003 11:23:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovll23533 for ; Tue, 1 Jul 2003 11:23:31 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 QQovll23523 for ; Tue, 1 Jul 2003 11:23:31 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07267; Tue, 1 Jul 2003 07:23:28 -0400 (EDT) Message-Id: <200307011123.HAA07267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-query-09.txt Date: Tue, 01 Jul 2003 07:23:27 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multi Protocol Label Switching Label Distribution Protocol Query Message Description Author(s) : P. Ashwood-Smith, A. Paraschiv, D. Allan Filename : draft-ietf-mpls-lsp-query-09.txt Pages : 19 Date : 2003-6-30 This document describes the encoding and procedures for three new Label Distribution Protocol (LDP) messages: Query Message, Query- Reply Message and Partial Query-Reply Message. A Label Edge Router (LER) sends a Query message when it needs to find out information about an established Label Switched Path (LSP). The Query message can be used for LDP LSPs as well as for Constraint-Based Label Switched Paths (CR-LSPs). The queried data is encoded into the Query-Reply messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-query-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-query-09.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: <2003-6-30151514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-query-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-query-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151514.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 1 13:47:39 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08037 for ; Tue, 1 Jul 2003 13:47:19 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovml19483 for ; Tue, 1 Jul 2003 17:47:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovml19349; Tue, 1 Jul 2003 17:47:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQovme20096 for mpls-outgoing; Tue, 1 Jul 2003 16:00:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovme19137 for ; Tue, 1 Jul 2003 16:00: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 QQovmd09319 for ; Tue, 1 Jul 2003 15:58:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovmd02600 for ; Tue, 1 Jul 2003 15:58:45 GMT Received: from mta9.wss.scd.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mta9.wss.scd.yahoo.com [66.218.85.40]) id QQovmd02590 for ; Tue, 1 Jul 2003 15:58:44 GMT Received: from [65.129.57.138] by mta9.wss.scd.yahoo.com with HTTP; Tue, 1 Jul 2003 08:58:43 -0700 Date: Tue, 1 Jul 2003 11:58:43 -0400 Message-ID: <3EDCE819000117CE@mta9.wss.scd.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2003 Conference - Submission Deadline Extended to July 3rd To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable (repost being sent on behalf of Dave McDysan, Conference Technical Co-cha= ir) ----------- From: Dave McDysan The MPLS 2003 Conference will be held in Washington D.C. from October 26 through October 28. This year?s conference will include but is not limite= d to topics such as: - MPLS as a convergence technology - MPLS network management and operational issues - Provisioning and migration strategies - MPLS in multi-AS networks - L2 VPNs (pseudo-wire, VPLS, and other) - L3 VPNs (BGP/MPLS, IPSec interworking, virtual routers, and other) - Scalability and performance - Traffic engineering and QoS - Network processor architectures for next generation applications - Testing MPLS applications and performance - Network security - Disaster recovery - Reliability and graceful restart techniques - Optical Integration and challenges The Program Committee of MPLS 2003 is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution please send a one page long proposal, including speaker?s contact details to the attention of the Technical Program Committee at TPC@mpls2003.com by July 3, 2003 (this will be the last extension.) See www.mpls2003.com for more details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider and user community are solicited on new technologies and operational experience. ---------- From owner-mpls@UU.NET Wed Jul 2 09:20:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15897 for ; Wed, 2 Jul 2003 09:20:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpl05670 for ; Wed, 2 Jul 2003 13:20:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovpl05441; Wed, 2 Jul 2003 13:20:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQovpb12467 for mpls-outgoing; Wed, 2 Jul 2003 10:59:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovpb12453 for ; Wed, 2 Jul 2003 10:59: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 QQovpb20675 for ; Wed, 2 Jul 2003 10:59:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb22145 for ; Wed, 2 Jul 2003 10:59:19 GMT Received: from sj-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-3.cisco.com [171.68.223.137]) id QQovpb22125 for ; Wed, 2 Jul 2003 10:59:18 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h62AxGvd025907 for ; Wed, 2 Jul 2003 03:59:16 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ27102; Wed, 2 Jul 2003 06:59:15 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62AxFp06504 for mpls@uu.net; Wed, 2 Jul 2003 06:59:15 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovpb12391 for ; Wed, 2 Jul 2003 10:57:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovpb18822 for ; Wed, 2 Jul 2003 10:56:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb19027 for ; Wed, 2 Jul 2003 10:56:05 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 QQovpb19006 for ; Wed, 2 Jul 2003 10:56:04 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02781; Wed, 2 Jul 2003 06:56:03 -0400 (EDT) Message-Id: <200307021056.GAA02781@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-tc-mib-08.txt Date: Wed, 02 Jul 2003 06:56:02 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau, J. Cucchiara Filename : draft-ietf-mpls-tc-mib-08.txt Pages : 23 Date : 2003-7-1 This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Mulitprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-tc-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-tc-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1134702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-tc-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-tc-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134702.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 2 09:20:24 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15913 for ; Wed, 2 Jul 2003 09:20:23 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpl05808 for ; Wed, 2 Jul 2003 13:20:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovpl05557; Wed, 2 Jul 2003 13:20:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQovpb12470 for mpls-outgoing; Wed, 2 Jul 2003 10:59:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovpb12454 for ; Wed, 2 Jul 2003 10:59: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 QQovpb20817 for ; Wed, 2 Jul 2003 10:59:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb22183 for ; Wed, 2 Jul 2003 10:59:21 GMT Received: from sj-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-4.cisco.com [171.68.223.138]) id QQovpb22178 for ; Wed, 2 Jul 2003 10:59:21 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h62AxIpp018674 for ; Wed, 2 Jul 2003 03:59:18 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ27103; Wed, 2 Jul 2003 06:59:17 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62AxHG06521 for mpls@uu.net; Wed, 2 Jul 2003 06:59:17 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovpb12420 for ; Wed, 2 Jul 2003 10:58: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 QQovpb19093 for ; Wed, 2 Jul 2003 10:56:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb19311 for ; Wed, 2 Jul 2003 10:56:15 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 QQovpb19253 for ; Wed, 2 Jul 2003 10:56: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 GAA02838; Wed, 2 Jul 2003 06:56:12 -0400 (EDT) Message-Id: <200307021056.GAA02838@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-oam-requirements-01.txt Date: Wed, 02 Jul 2003 06:56:12 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : OAM Requirements for MPLS Networks Author(s) : T. Nadeau et al. Filename : draft-ietf-mpls-oam-requirements-01.txt Pages : 11 Date : 2003-7-1 As transport of diverse traffic types such as voice, frame relay, and ATM over MPLS become more common, the ability to detect, handle and diagnose control and data plane defects becomes critical. Detection and specification of how to handle those defects is not only important because such defects may not only affect the fundamental operation of an MPLS network, but also because they may impact SLA commitments for customers of that network. This Internet draft describes requirements for user and data plane operations and management (OAM) for Multi-Protocol Label Switching (MPLS). These requirements have been gathered from network operators who have extensive experience deploying MPLS networks, similarly some of these requirements have appeared in other documents [Y1710]. This draft specifies OAM requirements for MPLS, as well as for applications of MPLS such as pseudowire voice and VPN services. Those interested in specific issues relating to instrumenting MPLS for OAM purposes are directed to [FRAMEWORK] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-oam-requirements-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-oam-requirements-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: <2003-7-1134724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-oam-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-oam-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134724.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 2 09:21:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16013 for ; Wed, 2 Jul 2003 09:21:31 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpl08431 for ; Wed, 2 Jul 2003 13:21:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovpl08376; Wed, 2 Jul 2003 13:21:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQovpb12433 for mpls-outgoing; Wed, 2 Jul 2003 10:58:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovpb12421 for ; Wed, 2 Jul 2003 10:58: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 QQovpb20514 for ; Wed, 2 Jul 2003 10:57:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb20297 for ; Wed, 2 Jul 2003 10:57:20 GMT Received: from sj-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-3.cisco.com [171.68.223.137]) id QQovpb20281 for ; Wed, 2 Jul 2003 10:57:20 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h62AvDvd025049 for ; Wed, 2 Jul 2003 03:57:14 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ27001; Wed, 2 Jul 2003 06:57:13 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62AvCC06478 for mpls@uu.net; Wed, 2 Jul 2003 06:57:12 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovpb12370 for ; Wed, 2 Jul 2003 10:56: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 QQovpb24054 for ; Wed, 2 Jul 2003 10:56:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb18895 for ; Wed, 2 Jul 2003 10:55:59 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQovpb18884 for ; Wed, 2 Jul 2003 10:55:59 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02756; Wed, 2 Jul 2003 06:55:58 -0400 (EDT) Message-Id: <200307021055.GAA02756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-12.txt Date: Wed, 02 Jul 2003 06:55:57 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani Filename : draft-ietf-mpls-ldp-mib-12.txt Pages : 133 Date : 2003-7-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-12.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: <2003-7-1134652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134652.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 2 10:45:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25420 for ; Wed, 2 Jul 2003 10:45:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpr10718 for ; Wed, 2 Jul 2003 14:45:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovpr10677; Wed, 2 Jul 2003 14:45:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQovpb12436 for mpls-outgoing; Wed, 2 Jul 2003 10:58:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovpb12425 for ; Wed, 2 Jul 2003 10:58: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 QQovpb03172 for ; Wed, 2 Jul 2003 10:58:19 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb21135 for ; Wed, 2 Jul 2003 10:58:18 GMT Received: from sj-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-3.cisco.com [171.68.223.137]) id QQovpb21124 for ; Wed, 2 Jul 2003 10:58:18 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h62AwFvd025492 for ; Wed, 2 Jul 2003 03:58:15 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ27037; Wed, 2 Jul 2003 06:58:14 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62AwEQ06495 for mpls@uu.net; Wed, 2 Jul 2003 06:58:14 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovpb12387 for ; Wed, 2 Jul 2003 10:57:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovpb07491 for ; Wed, 2 Jul 2003 10:56:14 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpb19223 for ; Wed, 2 Jul 2003 10:56:14 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQovpb19113 for ; Wed, 2 Jul 2003 10:56:09 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02822; Wed, 2 Jul 2003 06:56:08 -0400 (EDT) Message-Id: <200307021056.GAA02822@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsr-mib-11.txt Date: Wed, 02 Jul 2003 06:56:07 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-lsr-mib-11.txt Pages : 56 Date : 2003-7-1 This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsr-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsr-mib-11.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: <2003-7-1134714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 2 11:17:15 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26575 for ; Wed, 2 Jul 2003 11:17:14 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpt00687 for ; Wed, 2 Jul 2003 15:17:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovpt00586; Wed, 2 Jul 2003 15:17:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQovpm22245 for mpls-outgoing; Wed, 2 Jul 2003 13:39:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovpm22226 for ; Wed, 2 Jul 2003 13:39: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 QQovpm21834 for ; Wed, 2 Jul 2003 13:38:43 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovpm08778 for ; Wed, 2 Jul 2003 13:38:42 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovpm08759 for ; Wed, 2 Jul 2003 13:38:41 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62DcYfq014652 for ; Wed, 2 Jul 2003 09:38:34 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ35961; Wed, 2 Jul 2003 09:38:33 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62DcXJ15351 for mpls@uu.net; Wed, 2 Jul 2003 09:38:33 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovmp24886 for ; Tue, 1 Jul 2003 18:52:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovmp11658 for ; Tue, 1 Jul 2003 18:51:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovmp09019 for ; Tue, 1 Jul 2003 18:51:44 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 QQovmp05631 for ; Tue, 1 Jul 2003 18:50:47 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10655; Tue, 1 Jul 2003 14:50:34 -0400 (EDT) Message-Id: <200307011850.OAA10655@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET Subject: Protocol Action: Applicability Statement for Restart Mechanisms for the Label Distribution Protocol to Informational Date: Tue, 01 Jul 2003 14:50:34 -0400 From: Michael Lee Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Applicability Statement for Restart Mechanisms for the Label Distribution Protocol' as an Informatinal RFC. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Bert Wijnen and A. Zinin From owner-mpls@UU.NET Wed Jul 2 20:27:58 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05531 for ; Wed, 2 Jul 2003 20:27:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovrd15119 for ; Thu, 3 Jul 2003 00:27:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovrd14696; Thu, 3 Jul 2003 00:27:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQovqo06522 for mpls-outgoing; Wed, 2 Jul 2003 20:37:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovqo06517 for ; Wed, 2 Jul 2003 20:37: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 QQovqo27712 for ; Wed, 2 Jul 2003 20:36:30 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqo28998 for ; Wed, 2 Jul 2003 20:36:30 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovqo28978 for ; Wed, 2 Jul 2003 20:36:29 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62KaRfq017074 for ; Wed, 2 Jul 2003 16:36:27 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ72440; Wed, 2 Jul 2003 16:36:26 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62KaQ421512 for mpls@uu.net; Wed, 2 Jul 2003 16:36:26 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovqo06268 for ; Wed, 2 Jul 2003 20:35: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 QQovqo19589 for ; Wed, 2 Jul 2003 20:33:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqo24933 for ; Wed, 2 Jul 2003 20:33:32 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 QQovqo24904 for ; Wed, 2 Jul 2003 20:33:31 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12828; Wed, 2 Jul 2003 16:32:46 -0400 (EDT) Message-Id: <200307022032.QAA12828@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-fastreroute-03.txt Date: Wed, 02 Jul 2003 16:32:46 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Fast Reroute Extensions to RSVP-TE for LSP Tunnels Author(s) : P. Pan et al. Filename : draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt Pages : 34 Date : 2003-7-2 This document defines extensions to and describes the use of RSVP to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either or both methods and to interoperate in a mixed network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161637.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 2 20:28:49 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05668 for ; Wed, 2 Jul 2003 20:28:49 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovrd16908 for ; Thu, 3 Jul 2003 00:28:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovrd16679; Thu, 3 Jul 2003 00:28:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQovqo06533 for mpls-outgoing; Wed, 2 Jul 2003 20:38:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovqo06528 for ; Wed, 2 Jul 2003 20:37: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 QQovqo06005 for ; Wed, 2 Jul 2003 20:36:30 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqo28961 for ; Wed, 2 Jul 2003 20:36:29 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovqo28948 for ; Wed, 2 Jul 2003 20:36:29 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62KaQfq017064 for ; Wed, 2 Jul 2003 16:36:26 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ72438; Wed, 2 Jul 2003 16:36:25 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62KaPm21503 for mpls@uu.net; Wed, 2 Jul 2003 16:36:25 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovqo06267 for ; Wed, 2 Jul 2003 20:35: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 QQovqo19624 for ; Wed, 2 Jul 2003 20:33:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqo24962 for ; Wed, 2 Jul 2003 20:33:32 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 QQovqo24938 for ; Wed, 2 Jul 2003 20:33:32 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12848; Wed, 2 Jul 2003 16:32:53 -0400 (EDT) Message-Id: <200307022032.QAA12848@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-mib-11.txt Date: Wed, 02 Jul 2003 16:32:53 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-te-mib-11.txt Pages : 70 Date : 2003-7-2 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-mib-11.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: <2003-7-2161647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161647.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 2 20:44:25 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06930 for ; Wed, 2 Jul 2003 20:44:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovre17166 for ; Thu, 3 Jul 2003 00:44:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovre16895; Thu, 3 Jul 2003 00:44:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQovqt02010 for mpls-outgoing; Wed, 2 Jul 2003 21:57:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovqt01894 for ; Wed, 2 Jul 2003 21:56: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 QQovqt29791 for ; Wed, 2 Jul 2003 21:55:35 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqt21967 for ; Wed, 2 Jul 2003 21:55:34 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 QQovqt21947 for ; Wed, 2 Jul 2003 21:55:34 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h62LtVt26884 for ; Wed, 2 Jul 2003 16:55:31 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id <3CJQ9LLZ>; Wed, 2 Jul 2003 17:55:30 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Hariom Prasad'" , ppvpn@nortelnetworks.com Cc: mpls@UU.NET Subject: RE: TTL for the bottom VC label Date: Wed, 2 Jul 2003 17:55:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C340E4.A7146F22" 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_01C340E4.A7146F22 Content-Type: text/plain Hariom, The TTL value of the VC (PW) Label was discussed on the mailing list in the first half of May (see archive). The conclusion was: "The setting of the TTL value in the PW label is application dependent, however in a strict point to point application the TTL should be appropriately set to 2" As you see, the text leaves open the possibility that PWs are spliced together to form connections across multiple hops. In that case, the intermediate hops would switch based on the PW label (and decrease the PW Label's TTL value in the process) Peter -----Original Message----- From: Hariom Prasad [mailto:homp123@yahoo.com] Sent: Wednesday, July 02, 2003 5:11 PM To: ppvpn@nortelnetworks.com Cc: mpls@UU.net Subject: TTL for the bottom VC label All, Generally on the ingress edge hop ( for vpn cases ) 2 labels get pushed, upper tunnel/lsp label and the bottom VC label. The TTL for the upper label should be adequate enough for the hop-count of tunnel/lsp. What should be the TTL value of bottom label.. One possibility is to set it to a value same as the top label..Other possibility is to set it to "1" which ensures that VC does'nt travel more than one hop after it is exposed.. I would really appreciate if someone could point out what is recommended value if there is one... Thanks with regards, homp _____ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! ------_=_NextPart_001_01C340E4.A7146F22 Content-Type: text/html
Hariom,
 
The TTL value of the VC (PW) Label was discussed on the mailing list in the first half of May (see archive). The conclusion was:
 
"The setting of the TTL value in the PW label is application dependent, however in a strict point to point application the TTL should be appropriately set to 2"
 
As you see, the text leaves open the possibility that PWs are spliced together to form connections across multiple hops. In that case, the intermediate hops would switch based on the PW label (and decrease the PW Label's TTL value in the process)
 
Peter
-----Original Message-----
From: Hariom Prasad [mailto:homp123@yahoo.com]
Sent: Wednesday, July 02, 2003 5:11 PM
To: ppvpn@nortelnetworks.com
Cc: mpls@UU.net
Subject: TTL for the bottom VC label

All,
 
Generally on the ingress edge hop ( for vpn cases ) 2 labels get pushed, upper tunnel/lsp label and the bottom VC label. The TTL for the upper label should be adequate enough for the hop-count of tunnel/lsp. What should be the TTL value of bottom label..
 
One possibility is to set it to a value same as the top label..Other possibility is to set it to "1" which ensures that VC does'nt travel more than one hop after it is exposed..
 
I would really appreciate if someone could point out what is recommended value if there is one... Thanks
 
with regards,
homp
 

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
------_=_NextPart_001_01C340E4.A7146F22-- From owner-mpls@UU.NET Wed Jul 2 20:44:28 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06946 for ; Wed, 2 Jul 2003 20:44:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovre17252 for ; Thu, 3 Jul 2003 00:44:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovre16862; Thu, 3 Jul 2003 00:44:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQovqw23524 for mpls-outgoing; Wed, 2 Jul 2003 22:32:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovqw23519 for ; Wed, 2 Jul 2003 22:31: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 QQovqw22796 for ; Wed, 2 Jul 2003 22:30:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqw20940 for ; Wed, 2 Jul 2003 22:30:30 GMT Received: from sj-iport-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQovqw20927 for ; Wed, 2 Jul 2003 22:30:29 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h62MUQrm028500 for ; Wed, 2 Jul 2003 15:30:26 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ80339; Wed, 2 Jul 2003 18:30:25 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h62MUPO24660 for mpls@uu.net; Wed, 2 Jul 2003 18:30:25 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovqu21457 for ; Wed, 2 Jul 2003 22:10:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQovqu17823 for ; Wed, 2 Jul 2003 22:10:43 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqu13505 for ; Wed, 2 Jul 2003 22:10:42 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 QQovqu13492 for ; Wed, 2 Jul 2003 22:10: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 SAA23719; Wed, 2 Jul 2003 18:10:38 -0400 (EDT) Message-Id: <200307022210.SAA23719@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-ping-03.txt Date: Wed, 02 Jul 2003 18:10:37 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting MPLS Data Plane Failures Author(s) : K. Kompella et al. Filename : draft-ietf-mpls-lsp-ping-03.txt Pages : 24 Date : 2003-7-2 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS 'echo request' and 'echo reply' for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-ping-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-ping-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2181630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2181630.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 2 21:35:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09691 for ; Wed, 2 Jul 2003 21:35:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovri06999 for ; Thu, 3 Jul 2003 01:35:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovri06634; Thu, 3 Jul 2003 01:35:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQovqq27739 for mpls-outgoing; Wed, 2 Jul 2003 21:11:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovqq27666 for ; Wed, 2 Jul 2003 21:10: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 QQovqq28986 for ; Wed, 2 Jul 2003 21:10:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovqq04735 for ; Wed, 2 Jul 2003 21:10:39 GMT Received: from web9502.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web9502.mail.yahoo.com [216.136.129.132]) id QQovqq04690 for ; Wed, 2 Jul 2003 21:10:38 GMT Message-ID: <20030702211037.79102.qmail@web9502.mail.yahoo.com> Received: from [206.54.51.125] by web9502.mail.yahoo.com via HTTP; Wed, 02 Jul 2003 14:10:37 PDT Date: Wed, 2 Jul 2003 14:10:37 -0700 (PDT) From: Hariom Prasad Subject: TTL for the bottom VC label To: ppvpn@nortelnetworks.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-897333022-1057180237=:78650" Sender: owner-mpls@UU.NET Precedence: bulk --0-897333022-1057180237=:78650 Content-Type: text/plain; charset=us-ascii All, Generally on the ingress edge hop ( for vpn cases ) 2 labels get pushed, upper tunnel/lsp label and the bottom VC label. The TTL for the upper label should be adequate enough for the hop-count of tunnel/lsp. What should be the TTL value of bottom label.. One possibility is to set it to a value same as the top label..Other possibility is to set it to "1" which ensures that VC does'nt travel more than one hop after it is exposed.. I would really appreciate if someone could point out what is recommended value if there is one... Thanks with regards, homp --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-897333022-1057180237=:78650 Content-Type: text/html; charset=us-ascii
All,
 
Generally on the ingress edge hop ( for vpn cases ) 2 labels get pushed, upper tunnel/lsp label and the bottom VC label. The TTL for the upper label should be adequate enough for the hop-count of tunnel/lsp. What should be the TTL value of bottom label..
 
One possibility is to set it to a value same as the top label..Other possibility is to set it to "1" which ensures that VC does'nt travel more than one hop after it is exposed..
 
I would really appreciate if someone could point out what is recommended value if there is one... Thanks
 
with regards,
homp
 

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-897333022-1057180237=:78650-- From owner-mpls@UU.NET Thu Jul 3 18:51:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18982 for ; Thu, 3 Jul 2003 18:51:54 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovup01059 for ; Thu, 3 Jul 2003 22:51:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovup00543; Thu, 3 Jul 2003 22:51:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQovtn04430 for mpls-outgoing; Thu, 3 Jul 2003 15:59:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovtn04421 for ; Thu, 3 Jul 2003 15:59:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQovtn16911 for ; Thu, 3 Jul 2003 15:58:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovtn20461 for ; Thu, 3 Jul 2003 15:58:49 GMT Received: from smtp6.clb.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.clb.oleane.net [213.56.31.26]) id QQovtn20448 for ; Thu, 3 Jul 2003 15:58:49 GMT Received: from mic (upper-side.rain.fr [194.250.212.114]) (authenticated) by smtp6.clb.oleane.net with ESMTP id h63FwJ5q017267 for ; Thu, 3 Jul 2003 17:58:48 +0200 Message-ID: <002801c3417c$237c3a80$0201a8c0@oleane.com> Reply-To: "Michel Gosse" From: "Michel Gosse" To: Subject: MPLS World Congress 2004 - Call for Proposals Date: Thu, 3 Jul 2003 17:59:51 +0200 Organization: Upper Side Conferences MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C3418C.E6665980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C3418C.E6665980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS World 2004 will stand in Paris from February 10 to 13. The call for proposals dead line has been extended to July 18. Get more details = at:http://www.upperside.fr/mplsworld2004/mplswc2004cfp.htm Thanks Michel Gosse michelg@upperside.fr Upper Side 54 rue du Fbg St Antoine 75012 Paris - France Telephone: 33 1 53 46 63 80 Fax: 33 1 53 46 63 85 http://www.upperside.fr/ ------=_NextPart_000_0025_01C3418C.E6665980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MPLS World 2004 will stand in Paris from February 10 = to=20 13.
 
The call for proposals dead line has been = extended to July=20 18.

Get more details at:http://w= ww.upperside.fr/mplsworld2004/mplswc2004cfp.htm
 
Thanks
 
Michel Gosse
michelg@upperside.fr
<= /DIV>
 
Upper Side
54 rue du Fbg St = Antoine
75012=20 Paris - France
Telephone: 33 1 53 46 63 80
Fax: 33 1 53 46 63 = 85
http://www.upperside.fr/ ------=_NextPart_000_0025_01C3418C.E6665980-- From owner-mpls@UU.NET Thu Jul 3 20:18:14 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28078 for ; Thu, 3 Jul 2003 20:18:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovuv25105 for ; Fri, 4 Jul 2003 00:18:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovuv24710; Fri, 4 Jul 2003 00:18:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQovui17500 for mpls-outgoing; Thu, 3 Jul 2003 21:08:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovui17483 for ; Thu, 3 Jul 2003 21:08:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQovui20908 for ; Thu, 3 Jul 2003 21:07:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovui17947 for ; Thu, 3 Jul 2003 21:07:42 GMT Received: from mailb.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailb.telia.com [194.22.194.6]) id QQovui17907 for ; Thu, 3 Jul 2003 21:07:41 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailb.telia.com (8.12.9/8.12.9) with ESMTP id h63L7fIw018964 for ; Thu, 3 Jul 2003 23:07:41 +0200 (CEST) X-Original-Recipient: Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h63L7ec08418 for ; Thu, 3 Jul 2003 23:07:40 +0200 (CEST) Message-ID: <3F0499C8.2020502@pi.se> Date: Thu, 03 Jul 2003 23:02:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG Subject: agenda slot requests for the mpls wg meeting in Vienna Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I gone over my mail, as careful as I could, and extracted the requests for agenda slots for the Vienna meeting. http://urax.utfors.net/~loa/mpls-agenda.txt Please check if your slot is list, if not please tell me so. Please note that this is not the agenda, nor the slots or times allocated, just a compilation of the requests as I've received them. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Sat Jul 5 13:57:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12323 for ; Sat, 5 Jul 2003 13:57:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowbf06182 for ; Sat, 5 Jul 2003 17:57:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowbf05739; Sat, 5 Jul 2003 17:56:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQovzy20255 for mpls-outgoing; Sat, 5 Jul 2003 09:44:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovzy20248 for ; Sat, 5 Jul 2003 09:44: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 QQovzy27954 for ; Sat, 5 Jul 2003 09:44:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovzy15479 for ; Sat, 5 Jul 2003 09:44:20 GMT Received: from mta0.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQovzy15456 for ; Sat, 5 Jul 2003 09:44:18 GMT Received: from l04955 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HHJ007PFPN664@mta0.huawei.com> for mpls@UU.NET; Sat, 05 Jul 2003 17:42:43 +0800 (CST) Date: Sat, 05 Jul 2003 17:42:56 +0800 From: lidefeng Subject: Questions about draft-ietf-mpls-lsp-query-09.txt To: petera@nortelnetworks.com, antonela@nortelnetworks.com, dallan@nortelnetworks.com Cc: mpls@UU.NET Message-id: <002601c342d9$d0832d20$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT In Section 6.2 of draft-ietf-mpls-lsp-query-09.txt,it states that: " When the Query message gets to a tunnel, it has to be able to handle both the previous label and the tunnel's label. The Query Label TLV behaves like a label stack. The previous label is pushed and the tunnel label is used. At the end of the tunnel, we need to pop the stack and start substituting the lower level labels." Could you please tell me what do "the previous label" and the "tunnel's label" signify respectively?An example to clarify this question will be appreciated ?Thanks Sincerely Yours Defeng Li Huawei Technologies +86-10-82882343 lidefeng@huawei.com From owner-mpls@UU.NET Sat Jul 5 20:27:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20783 for ; Sat, 5 Jul 2003 20:27:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowcf02565 for ; Sun, 6 Jul 2003 00:27:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowcf02172; Sun, 6 Jul 2003 00:27:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQowbn10655 for mpls-outgoing; Sat, 5 Jul 2003 19:50:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQowbn10632 for ; Sat, 5 Jul 2003 19:49: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 QQowbn06302 for ; Sat, 5 Jul 2003 19:49:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowbn08963 for ; Sat, 5 Jul 2003 19:49:31 GMT Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m0.netfirms.com [209.171.43.51]) id QQowbn08953 for ; Sat, 5 Jul 2003 19:49:30 GMT Received: (qmail 53500 invoked from network); 5 Jul 2003 19:49:28 -0000 Received: from pool-138-88-20-173.res.east.verizon.net (HELO Puppy) (138.88.20.173) by 0 with SMTP; 5 Jul 2003 19:49:28 -0000 Message-ID: <002e01c3432e$8e5d9480$ad14588a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Thomas D. Nadeau" Cc: "'mpls@uu.net'" Subject: LSR MIB mplsInSegmentMapTable Date: Sat, 5 Jul 2003 16:13:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm going through the latest LSR MIB updating the Management Overview. I notice that mplsInSegmentMapTable is indexed by a RowPointer. Do you really, really want to do this? Also, the description says... "This table specifies the mapping from the mplsInSegmentIndex to the corresponding mplsInSegmentInterface and mplsInSegmentLabel objects. The purpose of this table is to..." But the indexing is the other way around. That is, it provides a mapping from interface and label to in-segment. Cheers, Adrian From owner-mpls@UU.NET Sun Jul 6 00:56:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24723 for ; Sun, 6 Jul 2003 00:56:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowcx09531 for ; Sun, 6 Jul 2003 04:56:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowcx09239; Sun, 6 Jul 2003 04:56:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQowce23755 for mpls-outgoing; Sun, 6 Jul 2003 00:02:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQowce23739 for ; Sun, 6 Jul 2003 00:01:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQowce27536 for ; Sun, 6 Jul 2003 00:00:45 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowce09497 for ; Sun, 6 Jul 2003 00:00:44 GMT Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQowce09475 for ; Sun, 6 Jul 2003 00:00:44 GMT Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2003 17:02:47 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6600dro021325 for ; Sat, 5 Jul 2003 17:00:41 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAL00876; Sat, 5 Jul 2003 20:00:39 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6600cf18140 for mpls@uu.net; Sat, 5 Jul 2003 20:00:38 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQowcc11296 for ; Sat, 5 Jul 2003 23:34: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 QQowcc23334 for ; Sat, 5 Jul 2003 23:34:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowcc02414 for ; Sat, 5 Jul 2003 23:34:22 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 QQowcc02389 for ; Sat, 5 Jul 2003 23:34:22 GMT Received: by ietf.org (8.9.1a/8.9.1a) id TAA19885; Sat, 5 Jul 2003 19:34:17 -0400 (EDT) Date: Sat, 5 Jul 2003 19:34:17 -0400 (EDT) Message-Id: <200307052334.TAA19885@ietf.org> To: mpls@UU.NET Subject: Re: Movie References: <200307052333.TAA19843@ietf.org> In-Reply-To: <200307052333.TAA19843@ietf.org> X-URL: http://www.ietf.org/ Reply-to: nsyracus@ietf.org Subject: Autoreply from Internet Draft Submission Manager From: ietfauto@ietf.org (Internet Draft Submission Manager) Sender: owner-mpls@UU.NET Precedence: bulk Greetings: This message is being sent to acknowledge receipt of your Internet-Draft submission or message to internet-drafts@ietf.org. Please note that the pre-meeting cutoff date for Internet-Draft submissions was Monday, June 30th 2003 at 9:00 AM Eastern Time. Therefore, if you submitted an Internet-Draft, then your document will NOT be processed or retained. Please resubmit your document on or after Friday, July 18th 2003. All Internet-Drafts submitted on or after July 18th will be processed upon receipt. However, Internet-Draft announcements will not be sent until after the IETF Meeting. The IETF Secretariat From owner-mpls@UU.NET Sun Jul 6 12:20:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16598 for ; Sun, 6 Jul 2003 12:20:06 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQower21281 for ; Sun, 6 Jul 2003 16:20:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQower20944; Sun, 6 Jul 2003 16:19:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQoweg05982 for mpls-outgoing; Sun, 6 Jul 2003 13:41:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoweg05971 for ; Sun, 6 Jul 2003 13: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 QQoweg14393 for ; Sun, 6 Jul 2003 13:39:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoweg04702 for ; Sun, 6 Jul 2003 13:39:09 GMT Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoweg04688 for ; Sun, 6 Jul 2003 13:39:09 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h66Dd5rm018157 for ; Sun, 6 Jul 2003 06:39:05 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAL11862; Sun, 6 Jul 2003 09:39:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h66Dd4K23138 for mpls@uu.net; Sun, 6 Jul 2003 09:39:04 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoweg05749 for ; Sun, 6 Jul 2003 13:37: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 QQoweg26528 for ; Sun, 6 Jul 2003 13:37:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoweg25814 for ; Sun, 6 Jul 2003 13:37:28 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoweg25807 for ; Sun, 6 Jul 2003 13:37:28 GMT Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h66DbOfq029235; Sun, 6 Jul 2003 09:37:25 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-53.cisco.com [10.86.240.53]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h66DbO204196; Sun, 6 Jul 2003 09:37:24 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB mplsInSegmentMapTable Date: Sun, 6 Jul 2003 09:37:11 -0400 Organization: Cisco Systems Message-ID: <074a01c343c3$ba094800$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <002e01c3432e$8e5d9480$ad14588a@Puppy> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Hi, > > I'm going through the latest LSR MIB updating the Management > Overview. I notice that mplsInSegmentMapTable is indexed by > a RowPointer. Do you really, really want to do this? This is what was requested during the last call to support LSP tracing. That is a mapping from the interface + label or interface + label pointer to the inSegmentIndex. The table achieves this by being indexed by: { mplsInSegmentMapInterface, mplsInSegmentMapLabel, mplsInSegmentMapLabelPtrIndex } and returning mplsInSegmentMapIndex as the single object in each row. The reason why a RowPointer is needed is to support the cases where a short MPLS label is mapped, as well as an extended (i.e.: GMPLS) label. Use of a RowPointer in the normal case will result in that index being simply set to 0.0, otherwise it will indicate where to find the label (and the middle index should be set to 0). In both cases, the mapping back to the mplsInSegmentIndex is achieved. > Also, the description says... > > "This table specifies the mapping from the > mplsInSegmentIndex to the corresponding > mplsInSegmentInterface and mplsInSegmentLabel > objects. The purpose of this table is to..." > > But the indexing is the other way around. That is, it > provides a mapping from interface and label to in-segment. I suppose that you can interpret the text that way. Maybe I am dyslexic, but I interpreted it correctly. 8) --Tom > Cheers, > Adrian > From owner-mpls@UU.NET Mon Jul 7 16:16:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12963 for ; Mon, 7 Jul 2003 16:16:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowiz08466 for ; Mon, 7 Jul 2003 20:16:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowiz07978; Mon, 7 Jul 2003 20:16:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQowie28672 for mpls-outgoing; Mon, 7 Jul 2003 15:01:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQowie27944 for ; Mon, 7 Jul 2003 15:00:58 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 QQowie08359 for ; Mon, 7 Jul 2003 15:00:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowie02941 for ; Mon, 7 Jul 2003 15:00:50 GMT Received: from mailg.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQowie02918 for ; Mon, 7 Jul 2003 15:00:49 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.9/8.12.9) with ESMTP id h67F0iZG012879; Mon, 7 Jul 2003 17:00:44 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h67F0ic24779; Mon, 7 Jul 2003 17:00:44 +0200 (CEST) Message-ID: <3F0989BE.8050000@pi.se> Date: Mon, 07 Jul 2003 16:54:54 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel , MPLS WG Subject: Re: draft-ietf-mpls-mgmt-overview-07.txt References: <003001c3432e$90bda490$ad14588a@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adrian, the updated management overview is now avaialble at: http://urax.utfors.net/~loa/draft-ietf-mpls-mgmt-overview-07.txt /Loa Adrian Farrel wrote: > Hi, > > Please find attached a proposed new version of the MPLS Management Overview > draft. > > This has been updated to reflect the changes to the LSR and TE MIBs > published at the end of last month. Apart from the addition of a new TE MIB > table and the change to a few object names, the principal change is the > addition of section 5.3 to describe indexing in the LSR MIB. > > Other changes are cosmetic (although I did find that a couple of the > diagrams had the reference arrows pointing in the wrong direction!). > > >-- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Mon Jul 7 16:34:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13946 for ; Mon, 7 Jul 2003 16:34:32 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowja11626 for ; Mon, 7 Jul 2003 20:34:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowja11337; Mon, 7 Jul 2003 20:34:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQowih16196 for mpls-outgoing; Mon, 7 Jul 2003 15:48:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQowih16189 for ; Mon, 7 Jul 2003 15:48:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQowih15168 for ; Mon, 7 Jul 2003 15:47:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowih12567 for ; Mon, 7 Jul 2003 15:47:36 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQowih12518 for ; Mon, 7 Jul 2003 15:47:34 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h67FlUfs015218 for ; Mon, 7 Jul 2003 11:47:32 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAL49046; Mon, 7 Jul 2003 11:47:30 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h67FlUM00308 for mpls@uu.net; Mon, 7 Jul 2003 11:47:30 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQowig14942 for ; Mon, 7 Jul 2003 15:34: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 QQowig14353 for ; Mon, 7 Jul 2003 15:33:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowig23219 for ; Mon, 7 Jul 2003 15:33:06 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQowig23194 for ; Mon, 7 Jul 2003 15:33:05 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h67FX2Mr018754; Mon, 7 Jul 2003 08:33:03 -0700 (PDT) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAL48001; Mon, 7 Jul 2003 11:33:01 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA05307; Mon, 7 Jul 2003 11:33:01 -0400 (EDT) Message-Id: <200307071533.LAA05307@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "jkchoi" cc: "George Swallow" , marco.carugi@nortelnetworks.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Request for time slot for ITU-T SG13 Q.11 Liaison (Mobile IP service over MPLS) In-reply-to: Your message of "Mon, 07 Jul 2003 21:04:26 +0900." <001b01c3447f$ea6d8fd0$3c856bd2@jkchoi> Date: Mon, 07 Jul 2003 11:33:01 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Jun Kyun Choi - > If you can arrange a time slot for me, I will introduce this document. > 5 min. is enough to present. I'll put you on the agenda. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-mpls@UU.NET Mon Jul 7 21:15:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23691 for ; Mon, 7 Jul 2003 21:15:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowjt23906 for ; Tue, 8 Jul 2003 01:15:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowjt23620; Tue, 8 Jul 2003 01:15:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQowjl19060 for mpls-outgoing; Mon, 7 Jul 2003 23:18:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowjl19053 for ; Mon, 7 Jul 2003 23:18:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQowjl06232 for ; Mon, 7 Jul 2003 23:17:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowjl05612 for ; Mon, 7 Jul 2003 23:17:46 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQowjl05589 for ; Mon, 7 Jul 2003 23:17:44 GMT Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3C88QMVH; Mon, 7 Jul 2003 19:17:43 -0400 Message-Id: <5.2.0.9.0.20030707174919.01e619b0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Jul 2003 19:16:31 -0400 To: ben@layer8.net, kireeti@juniper.net, mpls@UU.NET From: Mark Duffy Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-mtu-extensions-01.txt In-Reply-To: <200306101152.HAA21716@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi and thanks, I am glad to see the LDP MTU extension moving forward! I have a few comments (mostly nits) on the -01 draft that I hope will be helpful: >1. Introduction >... > This information is sufficient for a set of LSRs > along the path followed by an LSP to discover either the exact MTU > for that LSP, or an approximation which is no worse than could be > generated with local information on the ingress LSR. [md] How do we define "no worse"? I'd suggest that it should mean the procedure is not more likely to discover an LSP MTU value that is higher than the actual value. But how to determine if that is the case? It is hard to say how "bad" the locally generated approximation would be without making an assumption about what information would be locally available, and no such assumption is stated here. I would think the goal of the scheme should rather be that the procedure "discover either the exact MTU for that LSP, or a value that is no larger than the exact MTU". I'm not sure though that this goal is achievable -- see my last comments below, regarding sect. 2.4. > Hop MTU: the MTU of an LSP hop between an upstream LSR A and a > downstream LSR B. This size includes the IP header and data (or > other payload) and the part of the label stack that is considered > payload as far as this LSP goes. It does not include any lower-level > headers. (Note: if there are multiple links between A and B, the Hop > MTU is the minimum of the MTU of those links used for forwarding.) [md] The final sentence above seems incorrect. I think that if there are multiple links between A and B, the Hop MTU is the minimum of the Hop MTU that would be computed using the above definition for any of those links alone. Maybe it just needs s/MTU of those links/Hop MTU of those links/ to clarify it is not talking about the link MTUs. >2.2. Example > > Consider LSRs A-F interconnected as follows: > > M P > _____ C ===== > / | \ > A ~~~~~ B ===== D ----- E ----- F > L N Q R > > Say that the link MTU for link L is 9216, for links M, Q and R is > 4470, and for N and P is 1500. [md] A link between C-D is shown in the diagram but it is not given a name like the other links are, nor is it mentioned further except a few paragraphs below in "C's peers for FEC X are B, D and E." Perhaps it should be removed or else involved more fully. [md] In section 2.3 in the list items a), b), c) it uses the term "downstream neighbor". These should probably instead use the term "downstream LSR" that was defined in sect. 2.1. > b) For each downstream neighbor Z, L computes the minimum of > the Hop MTU to Z and the LSP MTU in the MTU TLV that Z [md] The procedure in sect. 2.3 requires each LSR L (in step 1.B.b) to determine the Hop MTU to each Downstream LSR. Based on the definition of Hop MTU, we might presume that this value is arrived at by subtracting 4 octets (1 label size) from the payload capacity of the underlying link. However, in the case of PHP where the LSR L is the penultimate hop, I think the correct Hop MTU is *equal* to the payload capacity of the underlying link. Do you agree? Though it may not be worth the added complexity to get the extra 4 bytes. In any event, I think it would be worthwhile to explicitly state in the document how LSR L is to calculate the Hop MTU, or to enhance the definition of Hop MTU in section 2.1 to explain the effect of PHP on the value. > 2. For each LDP neighbor (direct or targetted) of L to which L > decides to send a Mapping for FEC F, L attaches an MTU TLV with > the MTU that it computed for this FEC. [md] In the last line, to be completely clear, s/the MTU that it computed/the LSP MTU that it computed/ >2.4. MTU TLV >... > Note that the U and F bits are set. An LSR that doesn't recognize > the MTU TLV MUST ignore it when it processes the Label Mapping > message, and forward the TLV to its peers. This may result in the > incorrect computation of the LSP MTU; however, silently forwarding > the MTU TLV preserves maximal amount of information about the LSP > MTU. [md] Is that the best thing to do? This basically leaves the hop(s) immediately downstream of the "dumb" LSR out of the calculation. This can only err in the direction of computing an LSP MTU that is *too large*. If OTOH the TLV were not propagated upstream (F bit cleared) the next upstream LSR could instead make some conservative guess about the MTU of the downstream portion of the LSP. E.g. use a configured value (might typically be set to 1500 minus sizeof a few labels). That's kind of ugly, but it might be pragmatic. But note that right now sect. 2.3, 1.B.b, says in the absence of the MTU TLV to presume an MTU of the downstraem portion of the LSP of 65535! [md] Also, what is an LSR that doesn't recognize the MTU TLV to do if it has more than 1 downstraem LSR? How does it then "forward the TLV to its peers"? Thanks, Mark From owner-mpls@UU.NET Tue Jul 8 14:31:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03271 for ; Tue, 8 Jul 2003 14:31:50 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowmk08790 for ; Tue, 8 Jul 2003 18:31:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowmk08607; Tue, 8 Jul 2003 18:31:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQowlu08994 for mpls-outgoing; Tue, 8 Jul 2003 14:42:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQowlu08982 for ; Tue, 8 Jul 2003 14:42:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQowlu06295 for ; Tue, 8 Jul 2003 14:42:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowlu18706 for ; Tue, 8 Jul 2003 14:42:04 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQowlu18693 for ; Tue, 8 Jul 2003 14:42:04 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h68EfjM08006; Tue, 8 Jul 2003 10:41:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jul 2003 10:41:46 -0400 Message-ID: From: "David Allan" To: "'lidefeng'" , "Peter Ashwood-Smith" , "Antonela Paraschiv" Cc: mpls@UU.NET Subject: RE: Questions about draft-ietf-mpls-lsp-query-09.txt Date: Tue, 8 Jul 2003 10:41:45 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk hi Defeng: The scenario discussed is when hitting a tunnel ingress, the LSR has a choice as to whether to expose the tunnel workings (if the tunnel layer also supports query capability) by continuing the trace at the tunnel layer, or simply forwarding the trace at the current level. If the LSR chooses to expose the tunnel, then the Query Label TLV stack carries the context forward such that the tunnel egress can then appropriately map back to the original top label. R1--------R2- - - - - - R3 - - - - - - -R4-----------R5 ============================== A tunnel connects R2 to R4 via R3 and all LSRs have routable addresses. If R2 chooses not to expose the tunnel, the trace will transit R1-R2-R4-R5. If R2 chooses to expose the tunnel, the trace will transit R1-R2-R3-R4-R5. The Query Label TLV propagated by R2 in the first case only carries the R2-R4 label. In the second case, it would push the R2-R4 label, and carry the R2-R3 label then replace the label at R3 with the R3-R4 label. The scenarios whereby LDP is recursive would be P2P PWs and use of LDP/CR-LDP. hope this helps Dave > -----Original Message----- > From: lidefeng [mailto:lidefeng@huawei.com] > Sent: Saturday, July 05, 2003 5:43 AM > To: Ashwood-Smith, Peter [CAR:1A00:EXCH]; Paraschiv, Antonela > [BL60:NP30:EXCH]; Allan, David [CAR:NS00:EXCH] > Cc: mpls@UU.NET > Subject: Questions about draft-ietf-mpls-lsp-query-09.txt > > > In Section 6.2 of draft-ietf-mpls-lsp-query-09.txt,it states > that: " When the Query message gets to a tunnel, it has to be > able to handle > both the previous label and the tunnel's label. The Query > Label TLV > behaves like a label stack. The previous label is pushed and the > tunnel label is used. At the end of the tunnel, we need to pop the > stack and start substituting the lower level labels." > > Could you please tell me what do "the previous label" and the > "tunnel's label" signify respectively?An example to clarify > this question will be appreciated ?Thanks > > > > Sincerely Yours > > Defeng Li > Huawei Technologies > +86-10-82882343 > lidefeng@huawei.com > > From owner-mpls@UU.NET Tue Jul 8 17:27:26 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11156 for ; Tue, 8 Jul 2003 17:27:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowmv20842 for ; Tue, 8 Jul 2003 21:27:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowmv20734; Tue, 8 Jul 2003 21:27:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQowmp05328 for mpls-outgoing; Tue, 8 Jul 2003 19:49:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowmp05321 for ; Tue, 8 Jul 2003 19:49:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQowmp04578 for ; Tue, 8 Jul 2003 19:48:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowmp20574 for ; Tue, 8 Jul 2003 19:48:15 GMT Received: from thumper.research.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQowmp20388 for ; Tue, 8 Jul 2003 19:48:07 GMT Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id h68Jm6DJ025676 for ; Tue, 8 Jul 2003 15:48:06 -0400 (EDT) Received: from research.telcordia.com (mayayajnik-pc [192.4.12.117]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA06623 for ; Tue, 8 Jul 2003 15:48:06 -0400 (EDT) Message-ID: <3F0B1FE2.CD3E1BFC@research.telcordia.com> Date: Tue, 08 Jul 2003 15:47:46 -0400 From: Maya Yajnik X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Martini tunnels between ERX and Cisco 7206 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, Has anyone set up Mayer 2 tunnels over MPLS between a Juniper ERX and a Cisco 7206. I am trying it and having difficulties. However, I had no trouble setting it up between Cisco 7206s and between ERX virtual routers. The basic problem seems to be that although the targeted LDP session is up between the Cisco and the ERX, the LDP process at the ERX end is not receiving the VC label from the Cisco. The Cisco receives the VC label from the ERX alright. The base LSP looks fine. Your suggestions are welcome. Here is the scenario and the problem that I see. Juniper ERX - Cisco 12008 - Cisco 10008 - Cisco 7206 I am using ATM (aal5) pvcs on both sides and using LDP LSPs as the base LSPs. At the Juniper ERX I see: with show mpls interface shim ATM3/1.333 routed to 222.222.225.5 on base LSP tun mpls:lsp-dedee105-32-cfd group-id 0 vc-id 72 mtu 9180 Label Sent In Label 36 on stack 0 pkts, 0 hcPkts, 0 octets 0 hcOctets, 0 errors, 0 discardPkts At the Cisco 7206 I see: with #show mpls l2transport vc 72 detail Local interface: AT1/0.333 up, line protocol up, ATM AAL5 0/333 up Destination address: 111.1.1.4, VC ID: 72, VC status: down Tunnel label: not ready, LFIB entry present Output interface: unknown, imposed label stack {} Create time: 01:07:15, last status change time: never Signaling protocol: LDP, peer 111.1.1.4:0 up MPLS VC labels: local 25, remote 36 Group ID: local 3, remote 0 MTU: local 9180, remote 9180 Remote interface description: Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 0, send 0 byte totals: receive 0, send 0 packet drops: receive 0, send 0 The relevant configurations at the PE routers are: At the Juniper ERX: ! Juniper Edge Routing Switch ERX-1440 ! Version: 5.0.0 release-0.0 [BuildId 818] (April 25, 2003 08:21) ! Copyright (c) 1999-2003 Juniper Networks, Inc. All rights reserved. ! ! Configuration script generated on SUN JUL 06 2003 17:01:23 UTC ! ! NOTE: This script represents only a subset of the full system configuration. ! virtual-router ler2 aaa authentication ppp default radius aaa accounting ppp default radius ! ip address-pool local mpls ! mpls topology-driven-lsp mpls topology-driven-lsp ip-interfaces egress host-only mpls topology-driven-lsp ip-interfaces ingress host-only ! mpls rsvp interface profile default ! mpls ldp interface profile "PE-FE" hello hold-time 10 no cr-ldp ! mpls ldp interface profile default ! interface null 0 interface loopback 0 ip address 111.1.1.4 255.255.255.255 ! interface pos 0/3 no pos scramble-atm encapsulation ppp ip address 222.222.204.2 255.255.255.252 mpls mpls rsvp profile default mpls ldp profile "PE-FE" ! ! interface atm 3/1.333 point-to-point atm pvc 333 0 33 aal5all 0 0 0 mpls-relay 222.222.225.5 72 ! ! router ospf 1 ! Area 0.0.0.0 network 111.1.1.4 0.0.0.0 area 0.0.0.0 network 222.222.204.0 0.0.0.255 area 0.0.0.0 ! ! At the Cisco 7206: ! ip cef ip audit notify log ip audit po max-events 100 mpls label protocol ldp mpls ldp logging neighbor-changes mpls traffic-eng tunnels mpls traffic-eng reoptimize timers frequency 30 mpls traffic-eng reoptimize events link-up tag-switching tdp discovery directed-hello accept tag-switching tdp router-id Loopback0 force ! interface Loopback0 ip address 222.222.225.5 255.255.255.255 ! ! interface ATM1/0.333 point-to-point mtu 9180 pvc 0/333 l2transport mpls l2transport route 111.1.1.4 72 ! ! ! interface POS6/0 ip address 222.222.28.28 255.255.255.248 encapsulation ppp ip ospf network point-to-point mpls label protocol ldp mpls traffic-eng tunnels tag-switching ip ip rsvp bandwidth 116250 116250 ! router ospf 1 router-id 222.222.225.5 log-adjacency-changes network 222.222.28.24 0.0.0.7 area 0 network 222.222.225.5 0.0.0.0 area 0 ! Maya From owner-mpls@UU.NET Tue Jul 8 22:23:12 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19438 for ; Tue, 8 Jul 2003 22:23:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQownp16946 for ; Wed, 9 Jul 2003 02:23:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQownp16683; Wed, 9 Jul 2003 02:23:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQowmv20300 for mpls-outgoing; Tue, 8 Jul 2003 21:25:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowmv20282 for ; Tue, 8 Jul 2003 21:25:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQowmv08670 for ; Tue, 8 Jul 2003 21:24:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowmv27005 for ; Tue, 8 Jul 2003 21:24:22 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQowmv26985 for ; Tue, 8 Jul 2003 21:24:21 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h68LOIfq012134 for ; Tue, 8 Jul 2003 17:24:18 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM52326; Tue, 8 Jul 2003 17:24:17 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h68LOH616558 for mpls@uu.net; Tue, 8 Jul 2003 17:24:17 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQowmv20212 for ; Tue, 8 Jul 2003 21:22:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQowmv11042 for ; Tue, 8 Jul 2003 21:22:12 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowmv23786 for ; Tue, 8 Jul 2003 21:22:12 GMT Received: from beta.jnpr.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQowmv23766 for ; Tue, 8 Jul 2003 21:22:11 GMT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by beta.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 14:22:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Martini tunnels between ERX and Cisco 7206 Date: Tue, 8 Jul 2003 17:22:09 -0400 Message-ID: <98F04BA831360C4FB5F7FC0118D9182801474E95@pi.jnpr.net> Thread-Topic: Martini tunnels between ERX and Cisco 7206 Thread-Index: AcNFlmob8c51t4crRl+7MWJeF4mSKQAAG2kw From: "Jeffrey \(Zhaohui\) Zhang" To: "Maya Yajnik" , X-OriginalArrivalTime: 08 Jul 2003 21:22:10.0708 (UTC) FILETIME=[FE1AB540:01C34596] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable Maya, The mailing list is not a place to discuss vendor specific issues. Let's take this off-line. Thanks. Jeffrey > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Maya > Yajnik > Sent: Tuesday, July 08, 2003 3:48 PM > To: mpls@UU.NET > Subject: Martini tunnels between ERX and Cisco 7206 >=20 >=20 >=20 > Hello all, > Has anyone set up Mayer 2 tunnels over MPLS between a > Juniper ERX and a Cisco 7206. I am trying it and having difficulties. > However, I had no trouble setting it up between Cisco 7206s and > between ERX virtual routers. > The basic problem seems to be that although the targeted LDP session > is up between the Cisco and the ERX, the LDP process at the ERX > end is not receiving the VC label from the Cisco. The Cisco receives > the VC label from the ERX alright. The base LSP looks fine. > Your suggestions are welcome. >=20 > Here is the scenario and the problem that I see. > Juniper ERX - Cisco 12008 - Cisco 10008 - Cisco 7206 >=20 > I am using ATM (aal5) pvcs on both sides and using > LDP LSPs as the base LSPs. >=20 > At the Juniper ERX I see: > with show mpls interface shim > ATM3/1.333 > routed to 222.222.225.5 on base LSP tun mpls:lsp-dedee105-32-cfd > group-id 0 vc-id 72 mtu 9180 > Label Sent > In Label 36 on stack > 0 pkts, 0 hcPkts, 0 octets > 0 hcOctets, 0 errors, 0 discardPkts >=20 > At the Cisco 7206 I see: > with #show mpls l2transport vc 72 detail > Local interface: AT1/0.333 up, line protocol up, ATM AAL5 0/333 up > Destination address: 111.1.1.4, VC ID: 72, VC status: down > Tunnel label: not ready, LFIB entry present > Output interface: unknown, imposed label stack {} > Create time: 01:07:15, last status change time: never > Signaling protocol: LDP, peer 111.1.1.4:0 up > MPLS VC labels: local 25, remote 36 > Group ID: local 3, remote 0 > MTU: local 9180, remote 9180 > Remote interface description: > Sequencing: receive disabled, send disabled > VC statistics: > packet totals: receive 0, send 0 > byte totals: receive 0, send 0 > packet drops: receive 0, send 0 >=20 > The relevant configurations at the PE routers are: > At the Juniper ERX: > ! Juniper Edge Routing Switch ERX-1440 > ! Version: 5.0.0 release-0.0 [BuildId 818] (April 25, 2003 08:21) > ! Copyright (c) 1999-2003 Juniper Networks, Inc. All rights reserved. > ! > ! Configuration script generated on SUN JUL 06 2003 17:01:23 UTC > ! > ! NOTE: This script represents only a subset of the full system > configuration. > ! > virtual-router ler2 > aaa authentication ppp default radius > aaa accounting ppp default radius > ! > ip address-pool local > mpls > ! > mpls topology-driven-lsp > mpls topology-driven-lsp ip-interfaces egress host-only > mpls topology-driven-lsp ip-interfaces ingress host-only > ! > mpls rsvp interface profile default > ! > mpls ldp interface profile "PE-FE" > hello hold-time 10 > no cr-ldp > ! > mpls ldp interface profile default > ! > interface null 0 > interface loopback 0 > ip address 111.1.1.4 255.255.255.255 > ! > interface pos 0/3 > no pos scramble-atm > encapsulation ppp > ip address 222.222.204.2 255.255.255.252 > mpls > mpls rsvp profile default > mpls ldp profile "PE-FE" > ! > ! > interface atm 3/1.333 point-to-point > atm pvc 333 0 33 aal5all 0 0 0 > mpls-relay 222.222.225.5 72 > ! > ! > router ospf 1 > ! Area 0.0.0.0 > network 111.1.1.4 0.0.0.0 area 0.0.0.0 > network 222.222.204.0 0.0.0.255 area 0.0.0.0 > ! > ! >=20 > At the Cisco 7206: > ! > ip cef > ip audit notify log > ip audit po max-events 100 > mpls label protocol ldp > mpls ldp logging neighbor-changes > mpls traffic-eng tunnels > mpls traffic-eng reoptimize timers frequency 30 > mpls traffic-eng reoptimize events link-up > tag-switching tdp discovery directed-hello accept > tag-switching tdp router-id Loopback0 force > ! > interface Loopback0 > ip address 222.222.225.5 255.255.255.255 > ! > ! > interface ATM1/0.333 point-to-point > mtu 9180 > pvc 0/333 l2transport > mpls l2transport route 111.1.1.4 72 > ! > ! > ! > interface POS6/0 > ip address 222.222.28.28 255.255.255.248 > encapsulation ppp > ip ospf network point-to-point > mpls label protocol ldp > mpls traffic-eng tunnels > tag-switching ip > ip rsvp bandwidth 116250 116250 > ! > router ospf 1 > router-id 222.222.225.5 > log-adjacency-changes > network 222.222.28.24 0.0.0.7 area 0 > network 222.222.225.5 0.0.0.0 area 0 > ! >=20 > Maya >=20 >=20 >=20 >=20 >=20 >=20 From owner-mpls@UU.NET Wed Jul 9 00:34:46 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21520 for ; Wed, 9 Jul 2003 00:34:46 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowny26978 for ; Wed, 9 Jul 2003 04:34:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowny26774; Wed, 9 Jul 2003 04:34:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQowno29285 for mpls-outgoing; Wed, 9 Jul 2003 02:00:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQowno28291 for ; Wed, 9 Jul 2003 02:00: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 QQownn19302 for ; Wed, 9 Jul 2003 01:59:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQownn05254 for ; Wed, 9 Jul 2003 01:59:58 GMT Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQownn05236 for ; Wed, 9 Jul 2003 01:59:57 GMT Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2003 18:57:44 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h691xrpZ006181 for ; Tue, 8 Jul 2003 18:59:54 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM66745; Tue, 8 Jul 2003 21:59:53 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h691xrZ19665 for mpls@uu.net; Tue, 8 Jul 2003 21:59:53 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQownm23835 for ; Wed, 9 Jul 2003 01:37:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQownm07491 for ; Wed, 9 Jul 2003 01:36:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQownm22056 for ; Wed, 9 Jul 2003 01:36:28 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQownm22049 for ; Wed, 9 Jul 2003 01:36:28 GMT Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h691aJMr028013; Tue, 8 Jul 2003 18:36:25 -0700 (PDT) Received: from tnadeauw2k (che-vpn-cluster-1-105.cisco.com [10.86.240.105]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h691aI217659; Tue, 8 Jul 2003 21:36:18 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Maya Yajnik'" , Subject: RE: Martini tunnels between ERX and Cisco 7206 Date: Tue, 8 Jul 2003 21:36:05 -0400 Organization: Cisco Systems Message-ID: <0a2c01c345ba$7a70c3f0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F0B1FE2.CD3E1BFC@research.telcordia.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This is not a mailing list for discussing specific deployment issues. Let me suggest that you try mpls-ops@mplsrc.com for such discussions. --Tom > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Maya Yajnik > Sent: Tuesday, July 08, 2003 3:48 PM > To: mpls@UU.NET > Subject: Martini tunnels between ERX and Cisco 7206 > > > > Hello all, > Has anyone set up Mayer 2 tunnels over MPLS between a > Juniper ERX and a Cisco 7206. I am trying it and having > difficulties. However, I had no trouble setting it up between > Cisco 7206s and between ERX virtual routers. The basic > problem seems to be that although the targeted LDP session is > up between the Cisco and the ERX, the LDP process at the ERX > end is not receiving the VC label from the Cisco. The Cisco > receives the VC label from the ERX alright. The base LSP > looks fine. Your suggestions are welcome. > > Here is the scenario and the problem that I see. > Juniper ERX - Cisco 12008 - Cisco 10008 - Cisco 7206 > > I am using ATM (aal5) pvcs on both sides and using > LDP LSPs as the base LSPs. > > At the Juniper ERX I see: > with show mpls interface shim > ATM3/1.333 > routed to 222.222.225.5 on base LSP tun mpls:lsp-dedee105-32-cfd > group-id 0 vc-id 72 mtu 9180 > Label Sent > In Label 36 on stack > 0 pkts, 0 hcPkts, 0 octets > 0 hcOctets, 0 errors, 0 discardPkts > > At the Cisco 7206 I see: > with #show mpls l2transport vc 72 detail > Local interface: AT1/0.333 up, line protocol up, ATM AAL5 0/333 up > Destination address: 111.1.1.4, VC ID: 72, VC status: down > Tunnel label: not ready, LFIB entry present > Output interface: unknown, imposed label stack {} > Create time: 01:07:15, last status change time: never > Signaling protocol: LDP, peer 111.1.1.4:0 up > MPLS VC labels: local 25, remote 36 > Group ID: local 3, remote 0 > MTU: local 9180, remote 9180 > Remote interface description: > Sequencing: receive disabled, send disabled > VC statistics: > packet totals: receive 0, send 0 > byte totals: receive 0, send 0 > packet drops: receive 0, send 0 > > The relevant configurations at the PE routers are: > At the Juniper ERX: > ! Juniper Edge Routing Switch ERX-1440 > ! Version: 5.0.0 release-0.0 [BuildId 818] (April 25, 2003 > 08:21) ! Copyright (c) 1999-2003 Juniper Networks, Inc. All > rights reserved. ! ! Configuration script generated on SUN > JUL 06 2003 17:01:23 UTC ! ! NOTE: This script represents > only a subset of the full system configuration. ! > virtual-router ler2 aaa authentication ppp default radius aaa > accounting ppp default radius ! ip address-pool local mpls ! > mpls topology-driven-lsp mpls topology-driven-lsp > ip-interfaces egress host-only mpls topology-driven-lsp > ip-interfaces ingress host-only ! mpls rsvp interface profile > default ! mpls ldp interface profile "PE-FE" hello hold-time > 10 no cr-ldp ! mpls ldp interface profile default ! > interface null 0 interface loopback 0 ip address 111.1.1.4 > 255.255.255.255 ! interface pos 0/3 no pos scramble-atm > encapsulation ppp ip address 222.222.204.2 255.255.255.252 > mpls mpls rsvp profile default mpls ldp profile "PE-FE" ! ! > interface atm 3/1.333 point-to-point atm pvc 333 0 33 > aal5all 0 0 0 mpls-relay 222.222.225.5 72 ! ! router ospf 1 > ! Area 0.0.0.0 network 111.1.1.4 0.0.0.0 area 0.0.0.0 > network 222.222.204.0 0.0.0.255 area 0.0.0.0 ! ! > > At the Cisco 7206: > ! > ip cef > ip audit notify log > ip audit po max-events 100 > mpls label protocol ldp > mpls ldp logging neighbor-changes > mpls traffic-eng tunnels > mpls traffic-eng reoptimize timers frequency 30 > mpls traffic-eng reoptimize events link-up > tag-switching tdp discovery directed-hello accept > tag-switching tdp router-id Loopback0 force > ! > interface Loopback0 > ip address 222.222.225.5 255.255.255.255 > ! > ! > interface ATM1/0.333 point-to-point > mtu 9180 > pvc 0/333 l2transport > mpls l2transport route 111.1.1.4 72 > ! > ! > ! > interface POS6/0 > ip address 222.222.28.28 255.255.255.248 > encapsulation ppp > ip ospf network point-to-point > mpls label protocol ldp > mpls traffic-eng tunnels > tag-switching ip > ip rsvp bandwidth 116250 116250 > ! > router ospf 1 > router-id 222.222.225.5 > log-adjacency-changes > network 222.222.28.24 0.0.0.7 area 0 > network 222.222.225.5 0.0.0.0 area 0 > ! > > Maya > > > > > From owner-mpls@UU.NET Wed Jul 9 14:21:30 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12887 for ; Wed, 9 Jul 2003 14:21:29 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowqb17886 for ; Wed, 9 Jul 2003 18:21:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowqb17581; Wed, 9 Jul 2003 18:21:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQowpm02407 for mpls-outgoing; Wed, 9 Jul 2003 14:36:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQowpm02400 for ; Wed, 9 Jul 2003 14:36:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQowpm10195 for ; Wed, 9 Jul 2003 14:36:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowpm09951 for ; Wed, 9 Jul 2003 14:36:21 GMT Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQowpm09937 for ; Wed, 9 Jul 2003 14:36:21 GMT Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2003 07:39:09 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h69EaH7F017308 for ; Wed, 9 Jul 2003 07:36:18 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM94972; Wed, 9 Jul 2003 10:36:17 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h69EaH026686 for mpls@uu.net; Wed, 9 Jul 2003 10:36:17 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQowpm02182 for ; Wed, 9 Jul 2003 14:35: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 QQowpm05325 for ; Wed, 9 Jul 2003 14:35:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowpm08990 for ; Wed, 9 Jul 2003 14:35:05 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQowpm08966 for ; Wed, 9 Jul 2003 14:35:04 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Wed, 9 Jul 2003 15:34:50 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80287058D@baker.datcon.co.uk> From: Nic Neate To: "'ppan@ciena.net'" , "'dhg@juniper.net'" , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" Cc: "'mpls@uu.net'" Subject: Suggested improvements to the Path-Specific merge rules in draft- ietf-mpls-rsvp-lsp-fastreroute-03 Date: Wed, 9 Jul 2003 15:34:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk All, This email sets out some suggested improvements to the Path-Specific merge rules in section 7.1.2 of draft-ietf-mpls-rsvp-lsp-fastreroute-03. The points here are completely distinct from last year's discussion about weaknesses in the Path-Specific method and break-before-make of detours. The changes I suggest won't affect interoperability with existing implementations. In summary, I believe the list of seven merge rules specified in the draft should be reduced to the following three: 1. If one of the Path messages is for the protected LSP (and there can be at most one) then this becomes the chosen Path message. Quit. 2. From the remaining set of detour Path messages, eliminate from consideration any that traverse nodes that others want to avoid. 3. If several still remain, it is a local decision to choose which one to forward. If none remain, then the MP may try and find a new route that does avoid all nodes that all merging detour Paths want to avoid and forward a Path message with that ERO. The reasons why I've eliminated the old rules numbers 2, 4, 5 and 6, and reordered what was left, are as follows. A. I believe LSRs will never want to merge multiple Path messages for the protected LSP. The merge rules 3 and 5 in section 7.1.2 ("If only one Path message contains a FAST_REROUTE object ..." and "If several candidates still remain ... prefer ones with FAST_REROUTE object") imply that we may be merging multiple Paths for the protected LSP. Certainly if an upstream node is changing the route (doing a slow reroute), or just behaving badly, then we may receive multiple Paths for the protected LSP, but in both these cases we should reject all but one before we merge with any other detour Paths. Does anyone know of a reason why an LSR may ever want to merge multiple protected Path messages? B. I believe that if the MP is on the protected LSP (so it is merging a protected Path with one or more detour Paths for the same SESSION, SENDER_TEMPLATE, next hop and outgoing interface) then it MUST always forward the protected Path message. An MP on the protected LSP may receive a detour Path which wishes to avoid some downstream node on the protected LSP. In this case merge rule 1 ("Eliminate from consideration those that traverse nodes that other Path messages want to avoid") will eliminate the protected Path message and forward the detour Path. I think merge rule 3 ("If only one Path message contains FAST_REROUTE object, this becomes the chosen Path message") should be the first rule. Am I right in thinking that this is an error in the draft? C. I can't see the purpose of merge rule 2 "If one LSP is originated from this node, this must be the final LSP". I think it has the disadvantage that we may break-before-make a detour that we don't need to. For example, if we are merging a new PLR detour Path into an existing transit detour Path, then we will swap from the Path we were forwarding to the PLR Path message. The detour will become inactive until the Resv has returned from the MP, meaning that a section of the protected LSP is unprotected for that period. Does anyone know of a reason for this rule, or does everyone agree that it could be left as a local implementation decision? D. I think the draft should allow the MP to determine a new ERO to forward on a detour Path message. The draft doesn't specify what the MP should do if no received Path messages are suitable for forwarding (because all are detours and every one traverses some node that another wants to avoid). I think the MP should be allowed to try and find a new ERO which does avoid all the nodes which all the merging detour Paths require, and forward a detour Path with that ERO. However, the text of the merge rules implies that the MP must forward one of the received Paths (section 7.1.2 paragraph 5 "the MP runs the following procedure to select one of them as the Path message to forward downstream"). Given that the merge point is already discarding all but one of the EROs it has received, it does not feel like a significant change to discard them all if necessary. If merging still fails (because there is no possible route which satisfies all the merging detour Paths) then the draft should specify a course of action. I recommend bouncing the most recently received detour Path with a PathErr. I suggest the following. - Modifying the text from section 7.1.2 paragraph 5 quoted above to read "the MP runs the following procedure to identify a Path message to forward downstream". - Modifying the final merge rule as suggested at the top: "If several still remain, it is a local decision to choose which one to forward. If none remain, then the MP may try and find a new route that does avoid all nodes that all merging detour Paths want to avoid and forward a Path message with that ERO." - Adding the following paragraph to the end of section 7.1.2: "If no merged Path message can be constructed then the MP SHOULD send a PathErr in response to the most recently received detour Path message. If a protected Path is chosen to be forwarded, but it traverses nodes that some detours want to avoid, PathErrs should be sent in response to those detour Paths." Is there a reason why the MP should not be allowed to determine a new ERO? Please can you let me know if you agree with these proposed changes to the draft. Many thanks, Nic -- Nic Neate Network Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 Web: From owner-mpls@UU.NET Wed Jul 9 18:30:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26946 for ; Wed, 9 Jul 2003 18:30:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowqs18196 for ; Wed, 9 Jul 2003 22:31:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowqs17762; Wed, 9 Jul 2003 22:30:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQowpq26181 for mpls-outgoing; Wed, 9 Jul 2003 15:42:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQowpq26176 for ; Wed, 9 Jul 2003 15:42:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQowpq06194 for ; Wed, 9 Jul 2003 15:41:58 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowpq11128 for ; Wed, 9 Jul 2003 15:41:57 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQowpq11098 for ; Wed, 9 Jul 2003 15:41:56 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h69Fftu90253; Wed, 9 Jul 2003 08:41:56 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h69Fft675974; Wed, 9 Jul 2003 08:41:55 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 9 Jul 2003 08:41:55 -0700 (PDT) From: Kireeti Kompella To: Mark Duffy cc: mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-mtu-extensions-01.txt In-Reply-To: <5.2.0.9.0.20030707174919.01e619b0@email> Message-ID: <20030709081340.C75891@kummer.juniper.net> References: <5.2.0.9.0.20030707174919.01e619b0@email> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Mark, On Mon, 7 Jul 2003, Mark Duffy wrote: > Hi and thanks, I am glad to see the LDP MTU extension moving forward! > > I have a few comments (mostly nits) on the -01 draft that I hope will be > helpful: They are, thanks! > >1. Introduction > >... > > This information is sufficient for a set of LSRs > > along the path followed by an LSP to discover either the exact MTU > > for that LSP, or an approximation which is no worse than could be > > generated with local information on the ingress LSR. > > [md] How do we define "no worse"? I'd suggest that it should mean the > procedure is not more likely to discover an LSP MTU value that is higher > than the actual value. Basically, the path MTU discovery problem is to take the min of a set of values (those values being the MTUs of the involved links). If some of those values are missing, the best you can do ("no worse") is to take the min of the values you *do* have. As you point out, this can be too large. (See below also.) > [md] The final sentence above seems incorrect. I think that if there are > multiple links between A and B, the Hop MTU is the minimum of the Hop MTU > that would be computed using the above definition for any of those links > alone. Maybe it just needs > s/MTU of those links/Hop MTU of those links/ > to clarify it is not talking about the link MTUs. That's what was meant; I'll make the clarification. > >2.2. Example > > > > Consider LSRs A-F interconnected as follows: > > > > M P > > _____ C ===== > > / | \ > > A ~~~~~ B ===== D ----- E ----- F > > L N Q R > > > > Say that the link MTU for link L is 9216, for links M, Q and R is > > 4470, and for N and P is 1500. > > [md] A link between C-D is shown in the diagram but it is not given a name > like the other links are, nor is it mentioned further except a few > paragraphs below in "C's peers for FEC X are B, D and E." Perhaps it > should be removed or else involved more fully. Well, the point was, no all links emerging from a router are used for forwarding ... I'll make that explicit. > [md] In section 2.3 in the list items a), b), c) it uses the term > "downstream neighbor". These should probably instead use the term > "downstream LSR" that was defined in sect. 2.1. Okay. > > b) For each downstream neighbor Z, L computes the minimum of > > the Hop MTU to Z and the LSP MTU in the MTU TLV that Z > > [md] The procedure in sect. 2.3 requires each LSR L (in step 1.B.b) to > determine the Hop MTU to each Downstream LSR. Based on the definition of > Hop MTU, we might presume that this value is arrived at by subtracting 4 > octets (1 label size) from the payload capacity of the underlying > link. However, in the case of PHP where the LSR L is the penultimate hop, > I think the correct Hop MTU is *equal* to the payload capacity of the > underlying link. Do you agree? Though it may not be worth the added > complexity to get the extra 4 bytes. I agree, and I didn't put it in just because of the added complexity. However, I can say that a PHP LSR MAY use the full payload. > > 2. For each LDP neighbor (direct or targetted) of L to which L > > decides to send a Mapping for FEC F, L attaches an MTU TLV with > > the MTU that it computed for this FEC. > > [md] In the last line, to be completely clear, > s/the MTU that it computed/the LSP MTU that it computed/ Okay. > >2.4. MTU TLV > >... > > Note that the U and F bits are set. An LSR that doesn't recognize > > the MTU TLV MUST ignore it when it processes the Label Mapping > > message, and forward the TLV to its peers. This may result in the > > incorrect computation of the LSP MTU; however, silently forwarding > > the MTU TLV preserves maximal amount of information about the LSP > > MTU. > > [md] Is that the best thing to do? There are three choices: a) [U=0]: LSP doesn't come up if it passes through a "dumb" LSR (bad!!!) b) [U=1, F=1] c) [U=1, F=0] > This basically leaves the hop(s) > immediately downstream of the "dumb" LSR out of the calculation. Not quite. If the "dumb" LSR faithfully copies the MTU TLV to its upstream, only the one link downstream of the "dumb" LSR gets left out. That's the point of the 'F' bit. > This can > only err in the direction of computing an LSP MTU that is *too large*. If > OTOH the TLV were not propagated upstream (F bit cleared) the next upstream > LSR could instead make some conservative guess about the MTU of the > downstream portion of the LSP. E.g. use a configured value (might > typically be set to 1500 minus sizeof a few labels). That's kind of ugly, > but it might be pragmatic. In which case, every LSP that passes through a "dumb" LSR will have an MTU of (to be even more conservative) 576 minus a few labels! As you say, that's ugly. > But note that right now sect. 2.3, 1.B.b, says > in the absence of the MTU TLV to presume an MTU of the downstraem portion > of the LSP of 65535! Again, not quite. Then again, if the ingress is dumb, that's what you get. If the consensus of the WG is to go with U=1, F=0, I'll be happy to make the change. Otherwise, I'd rather leave it the way it is. > [md] Also, what is an LSR that doesn't recognize the MTU TLV to do if it > has more than 1 downstraem LSR? How does it then "forward the TLV to its > peers"? You're asking how the 'F' bit works. Beyond the scope of this document :-) Good question, though. Anyone care to take a stab? Kireeti. From owner-mpls@UU.NET Wed Jul 9 18:33:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27085 for ; Wed, 9 Jul 2003 18:33:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowqs22613 for ; Wed, 9 Jul 2003 22:33:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowqs22431; Wed, 9 Jul 2003 22:33:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQowqc05767 for mpls-outgoing; Wed, 9 Jul 2003 18:38:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowqc05760 for ; Wed, 9 Jul 2003 18:37: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 QQowqc26036 for ; Wed, 9 Jul 2003 18:37:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowqc08511 for ; Wed, 9 Jul 2003 18:37:35 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQowqc08497 for ; Wed, 9 Jul 2003 18:37:35 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h69IbVpZ023419 for ; Wed, 9 Jul 2003 11:37:31 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAN20470; Wed, 9 Jul 2003 14:37:30 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h69IbUU01355 for mpls@uu.net; Wed, 9 Jul 2003 14:37:30 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowpx11280 for ; Wed, 9 Jul 2003 17:17:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQowpx16245 for ; Wed, 9 Jul 2003 17:16:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowpx27212 for ; Wed, 9 Jul 2003 17:16:54 GMT Received: from rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: webmail35.rediffmail.com [203.199.83.246] (may be forged)) id QQowpx27197 for ; Wed, 9 Jul 2003 17:16:52 GMT Received: (qmail 27103 invoked by uid 510); 9 Jul 2003 17:16:00 -0000 Date: 9 Jul 2003 17:16:00 -0000 Message-ID: <20030709171600.27102.qmail@webmail35.rediffmail.com> Received: from unknown (63.197.247.13) by rediffmail.com via HTTP; 09 jul 2003 17:16:00 -0000 MIME-Version: 1.0 From: "Bhaskara P" Reply-To: "Bhaskara P" To: kireeti@juniper.net, yakov@juniper.net Cc: mpls@UU.NET, ccamp@ops.ietf.org, gmpls-ops@mplsrc.com Subject: unnumberted ERO and RRO Content-type: multipart/alternative; boundary="Next_1057770960---0-203.199.83.246-27100" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart mime message --Next_1057770960---0-203.199.83.246-27100 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =0A=0A --Next_1057770960---0-203.199.83.246-27100 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kireeti and Yokov,=0D=0A=0D=0AWhenever I read RFC 3477(Signalling Unnumb= ered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)= ), it leaves me in more confusion than clarification. If we have a simple = topology of 3 node LSP like below,=0D=0A=0D=0A Interfaces 1 = 2 3 4=0D=0A Node A ----------- Node B -----------= Node C=0D=0A=0D=0ARFC 3477 suggests one can do ERO signalling from ingress= Node A in either of the following formats=0D=0A=0D=0A format 1: ERO wit= h Router ID and out going interface Id of Node=0D=0A=0D=0A , =0D=0A , =0D=0A=0D=0A format 2: ERO with Router ID and in coming interface of= the Node=0D=0A=0D=0A , =0D=0A = , =0D=0A=0D=0A1) If the above state= ment is true, how should RRO for this LSP be encoded i.e., in format 1 or = format 2?. =0D=0A=0D=0A2) Which format should the ingress node A, receive = RRO object? =0D=0A=0D=0A3) Is RRO always seen by ingress Node A, should b= e always in the format of ERO singalled by ingress. i.e., if ingress node = singalls ERO in format 1, then it should recieve RRO in same format. or RRO= should follow always format 1 irrespective of ERO format.=0D=0A=0D=0AThese= formats are very important to inter-op between vendors. Can any please cla= rify the above issues and how the RRO and ERO inerop between the vendors ac= hieved?=0D=0A=0D=0Athank you=0D=0Abhaskara=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A =0A=0A --Next_1057770960---0-203.199.83.246-27100-- From owner-mpls@UU.NET Thu Jul 10 16:41:11 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20920 for ; Thu, 10 Jul 2003 16:41:10 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowuc04908 for ; Thu, 10 Jul 2003 20:41:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowuc04636; Thu, 10 Jul 2003 20:41:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQowtr08190 for mpls-outgoing; Thu, 10 Jul 2003 17:54:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQowtr08185 for ; Thu, 10 Jul 2003 17:54: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 QQowtr02365 for ; Thu, 10 Jul 2003 17:50:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowtr01694 for ; Thu, 10 Jul 2003 17:50:37 GMT Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQowtr01682 for ; Thu, 10 Jul 2003 17:50:37 GMT Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2003 10:48:42 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6AHoVpb003982 for ; Thu, 10 Jul 2003 10:50:34 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAO03502; Thu, 10 Jul 2003 13:50:31 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6AHoVq13796 for mpls@uu.net; Thu, 10 Jul 2003 13:50:31 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQowtr07673 for ; Thu, 10 Jul 2003 17:49:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQowtr27152 for ; Thu, 10 Jul 2003 17:48:54 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowtr00073 for ; Thu, 10 Jul 2003 17:48:53 GMT Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQowtr00066 for ; Thu, 10 Jul 2003 17:48:53 GMT Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2003 10:46:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6AHmo7F021247; Thu, 10 Jul 2003 10:48:51 -0700 (PDT) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAO03374; Thu, 10 Jul 2003 13:48:50 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA22074; Thu, 10 Jul 2003 13:48:50 -0400 (EDT) Message-Id: <200307101748.NAA22074@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: agenda@ietf.org, mpls@UU.NET cc: Dinara Suleymanova Subject: MPLS WG Agenda Date: Thu, 10 Jul 2003 13:48:49 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk is attached. ...George MPLS Agenda Vienna July 15, 2003 ======================================================================== Agenda Bashing 5 min Liaison Jun Kyun Choi 5 min ITU Liaison on Mobile IP services over MPLS opticalip.icu.ac.kr/WD21rev_Ymipompls.doc opticalip.icu.ac.kr/WD26r1_Liaison_To_IETF_ymipompls.doc MIBs Bert Wijnen, Tom Nadeau, Loa Andersson 25 min - first round of MIBs ftn, ldp, lsr, overview, tc, te, draft-te-link Loa Andersson 5 min - next set of MIBs Wai S Lai 10 min Network Management Requirements for MPLS MIBs Operations and Management David Allan 10 min The Case for the 'A' Bit in the MPLS and IP PID George Swallow 10 min Label Switched Router Self-Test MPLS multcast approaches Seisho Yasukawa and Rahul Aggarwal 25 min Extended RSVP-TE for Point-to-Multipoint LSP Tunnels Requirements for Point-to-Multipoint extension to MPLS Establishing Point to Multipoint MPLS TE LSPs MPLS Agenda Page 2 July 15, 2003 ======================================================================== Traffic Engineering J-P Vasseur 10 min Definition of an RRO node-id subobject Reoptimization of MPLS TE loosely routed explicit LSPs Updates on various drafts Kireeti Kompella 5 min MTU Signalling Extensions for LDP Detecting MPLS Data Plane Failures David Allan 5 min MPLS Label Distribution Protocol Query Message Description WG status 15 min George and Loa From owner-mpls@UU.NET Fri Jul 11 01:53:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05034 for ; Fri, 11 Jul 2003 01:53:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowvn10313 for ; Fri, 11 Jul 2003 05:53:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowvn10066; Fri, 11 Jul 2003 05:52:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQowuu10371 for mpls-outgoing; Fri, 11 Jul 2003 01:07:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowuu10359 for ; Fri, 11 Jul 2003 01:07: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 QQowuu11605 for ; Fri, 11 Jul 2003 01:07:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowuu09069 for ; Fri, 11 Jul 2003 01:07:06 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQowuu08758 for ; Fri, 11 Jul 2003 01:06:56 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6B16qpZ018876 for ; Thu, 10 Jul 2003 18:06:53 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAO39496; Thu, 10 Jul 2003 21:06:51 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6B16pc20675 for mpls@uu.net; Thu, 10 Jul 2003 21:06:51 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQowuu09982 for ; Fri, 11 Jul 2003 01:05: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 QQowuu01234 for ; Fri, 11 Jul 2003 01:02:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowuu02130 for ; Fri, 11 Jul 2003 01:02:12 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQowuu02062 for ; Fri, 11 Jul 2003 01:02:11 GMT Received: from juniper.net (lookout.juniper.net [172.17.20.54]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6B11Iu34352; Thu, 10 Jul 2003 18:01:19 -0700 (PDT) (envelope-from dhg@juniper.net) Message-Id: <200307110101.h6B11Iu34352@merlot.juniper.net> To: Nic Neate cc: "'ppan@ciena.net'" , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" , "'mpls@uu.net'" Subject: Re: Suggested improvements to the Path-Specific merge rules in draft- ietf-mpls-rsvp-lsp-fastreroute-03 In-reply-to: Your message of Wed, 09 Jul 2003 15:34:47 +0100. <53F74F5A7B94D511841C00B0D0AB16F80287058D@baker.datcon.co.uk> Date: Thu, 10 Jul 2003 18:01:18 -0700 From: Der-Hwa Gan Sender: owner-mpls@UU.NET Precedence: bulk Hi Nic, > All, > > This email sets out some suggested improvements to the Path-Specific merge > rules in section 7.1.2 of draft-ietf-mpls-rsvp-lsp-fastreroute-03. > > The points here are completely distinct from last year's discussion about > weaknesses in the Path-Specific method and break-before-make of detours. > The changes I suggest won't affect interoperability with existing > implementations. > > In summary, I believe the list of seven merge rules specified in the draft > should be reduced to the following three: > > 1. If one of the Path messages is for the protected LSP > (and there can be at most one) then this becomes the > chosen Path message. Quit. > > 2. From the remaining set of detour Path messages, > eliminate from consideration any that traverse nodes > that others want to avoid. > > 3. If several still remain, it is a local decision to > choose which one to forward. If none remain, then > the MP may try and find a new route that does avoid > all nodes that all merging detour Paths want to > avoid and forward a Path message with that ERO. The proposed text captures the intention of the original merging rules correctly without over-exposing the technical details. I think it is a step forward. > > The reasons why I've eliminated the old rules numbers 2, 4, 5 and 6, and > reordered what was left, are as follows. > > > A. I believe LSRs will never want to merge multiple Path messages for the > protected LSP. > > The merge rules 3 and 5 in section 7.1.2 ("If only one Path message contains > a FAST_REROUTE object ..." and "If several candidates still remain ... > prefer ones with FAST_REROUTE object") imply that we may be merging multiple > Paths for the protected LSP. Certainly if an upstream node is changing the > route (doing a slow reroute), or just behaving badly, then we may receive > multiple Paths for the protected LSP, but in both these cases we should > reject all but one before we merge with any other detour Paths. > > Does anyone know of a reason why an LSR may ever want to merge multiple > protected Path messages? It is possible that an implementation may want to keep all versions of the protected Path message when LSP rerouting itself. It should be a transient situation, and the situation will resolve itself when some of the Path messages times out, leaving just one Path message as the only viable one. As you suggested, an LSR may choose to reject all but one, it is perfectly reasonable too. In this case, rule 3 and 5 become overly complex and unnecessary. > > > B. I believe that if the MP is on the protected LSP (so it is merging a > protected Path with one or more detour Paths for the same SESSION, > SENDER_TEMPLATE, next hop and outgoing interface) then it MUST always > forward the protected Path message. I agree. > > An MP on the protected LSP may receive a detour Path which wishes to avoid > some downstream node on the protected LSP. In this case merge rule 1 This should not happen. But if it does, the original rule would rule out the protected LSP from consideration, which is not good. > ("Eliminate from consideration those that traverse nodes that other Path > messages want to avoid") will eliminate the protected Path message and > forward the detour Path. I think merge rule 3 ("If only one Path message > contains FAST_REROUTE object, this becomes the chosen Path message") should > be the first rule. > > Am I right in thinking that this is an error in the draft? Right, an oversight. > > > C. I can't see the purpose of merge rule 2 "If one LSP is originated from > this node, this must be the final LSP". Which means this is the ingress LSR of the LSP. Again, it is just another way of saying this is the protected LSP itself. > > I think it has the disadvantage that we may break-before-make a detour that we don't need to. > > For example, if we are merging a new PLR detour Path into an existing > transit detour Path, then we will swap from the Path we were forwarding to > the PLR Path message. The detour will become inactive until the Resv has > returned from the MP, meaning that a section of the protected LSP is > unprotected for that period. > > Does anyone know of a reason for this rule, or does everyone agree that it > could be left as a local implementation decision? > > > D. I think the draft should allow the MP to determine a new ERO to forward > on a detour Path message. > > The draft doesn't specify what the MP should do if no received Path messages > are suitable for forwarding (because all are detours and every one traverses > some node that another wants to avoid). I think the MP should be allowed to > try and find a new ERO which does avoid all the nodes which all the merging > detour Paths require, and forward a detour Path with that ERO. I didn't think this is possible. All the detours are originated from some PLR on the protected LSP. Each detour's 'node-to-avoid' information is the address of immediate downstream node of the PLR. If you have two detours with different node-to-avoid, then one of node-to-avoid will be closer to the egress. This detour can safely be the chosen one. > > However, the text of the merge rules implies that the MP must forward one of > the received Paths (section 7.1.2 paragraph 5 "the MP runs the following > procedure to select one of them as the Path message to forward downstream"). > Given that the merge point is already discarding all but one of the EROs it > has received, it does not feel like a significant change to discard them all > if necessary. > > If merging still fails (because there is no possible route which satisfies > all the merging detour Paths) then the draft should specify a course of > action. I recommend bouncing the most recently received detour Path with a > PathErr. > > I suggest the following. > > - Modifying the text from section 7.1.2 paragraph 5 quoted > above to read "the MP runs the following procedure to > identify a Path message to forward downstream". Ok. > > - Modifying the final merge rule as suggested at the top: I think the simplified merging rule should work fine, and is easier to read and understand. I don't know what is the opinion of other authors of the draft. Can this change be incorporated, or will this cause any problems? I have to ask because I am not the editor of the draft. Thanks, Der-Hwa Gan > "If several still remain, it is a local decision to > choose which one to forward. If none remain, then the MP > may try and find a new route that does avoid all nodes > that all merging detour Paths want to avoid and forward a > Path message with that ERO." > > - Adding the following paragraph to the end of section 7.1.2: > "If no merged Path message can be constructed then the MP > SHOULD send a PathErr in response to the most recently > received detour Path message. If a protected Path is > chosen to be forwarded, but it traverses nodes that some > detours want to avoid, PathErrs should be sent in response > to those detour Paths." > > Is there a reason why the MP should not be allowed to determine a new ERO? > > > Please can you let me know if you agree with these proposed changes to the > draft. > > Many thanks, > > Nic > > > -- > Nic Neate > Network Protocols Group > Data Connection Ltd > Tel: +44 20 8366 1177 > Fax: +44 20 8363 1468 > > Web: > > From owner-mpls@UU.NET Fri Jul 11 17:43:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18670 for ; Fri, 11 Jul 2003 17:43:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowxy14610 for ; Fri, 11 Jul 2003 21:43:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowxy14412; Fri, 11 Jul 2003 21:43:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQowxr15342 for mpls-outgoing; Fri, 11 Jul 2003 19:48:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowxr15330 for ; Fri, 11 Jul 2003 19:48: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 QQowxr12590 for ; Fri, 11 Jul 2003 19:48:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowxr17247 for ; Fri, 11 Jul 2003 19:48:32 GMT Received: from mailserver1.opnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserver1.opnet.com [12.145.55.23]) id QQowxr17242 for ; Fri, 11 Jul 2003 19:48:32 GMT Received: from wtn10216.opnet.com (wtn10216.opnet.com [172.16.10.216]) by mailserver1.opnet.com (8.12.9/8.12.8) with ESMTP id h6BJmTUC019357; Fri, 11 Jul 2003 15:48:29 -0400 (EDT) Message-Id: <5.0.0.25.2.20030711153519.00a889f0@mailserver.opnet.com> X-Sender: skalra@mailserver.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jul 2003 15:55:09 -0400 To: mpls@UU.NET From: Sachin Kalra Subject: Question about BGP/MPLS VPNs with NHS disabled Cc: Arun Pasupathy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Not scanned: Sender: owner-mpls@UU.NET Precedence: bulk Dear MPLS Community: I would appreciate if someone can answer the following question about BGP-MPLS VPNs. Lets say we have the following topology: [CE1] [CE11] \ / [PE1]-----------------[Rtr1]-------------------[PE2] / \ [CE2] [CE22] 1. Running IBGP between PE1 and PE2. 2. Running EBGP between all PEs and CEs. 3. BGP "Next Hop Self (NHS)" option is disabled on PEs. Now, when PE1 receive a route from PE2, how will PE1 know "BGP Next Hop" address for that route? As NHS is disabled on PE2, the new route will have CE's address as "BGP Next Hop", and PE1 will not be able to find any LSP going to that CE. Is this correct? I appreciate your response. Thanks, Sachin Kalra From owner-mpls@UU.NET Sat Jul 12 05:56:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07475 for ; Sat, 12 Jul 2003 05:56:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowzv25215 for ; Sat, 12 Jul 2003 09:56:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQowzv24839; Sat, 12 Jul 2003 09:56:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQowzk20907 for mpls-outgoing; Sat, 12 Jul 2003 07:12:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQowzk20720 for ; Sat, 12 Jul 2003 07:12: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 QQowzk04964 for ; Sat, 12 Jul 2003 07:11:45 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowzk14348 for ; Sat, 12 Jul 2003 07:11:45 GMT Received: from web41605.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web41605.mail.yahoo.com [66.218.93.105]) id QQowzk14324 for ; Sat, 12 Jul 2003 07:11:44 GMT Message-ID: <20030712071143.28110.qmail@web41605.mail.yahoo.com> Received: from [64.161.202.25] by web41605.mail.yahoo.com via HTTP; Sat, 12 Jul 2003 00:11:43 PDT Date: Sat, 12 Jul 2003 00:11:43 -0700 (PDT) From: "Gopal@Yahoo" Subject: Re: Question about BGP/MPLS VPNs with NHS disabled To: Sachin Kalra , mpls@UU.NET Cc: Arun Pasupathy In-Reply-To: <5.0.0.25.2.20030711153519.00a889f0@mailserver.opnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Sachin, You wrote "...As NHS is disabled on PE2, the new route will have CE's address as "BGP Next Hop".... That is not right. On remote-PE vpn-v4 route will not have another vpnv4 addr as the next-hop. On PE-1 next-hop addr for vpnv4 routes will not be the CE addr. The next-hop addr would some ipv4 addr of PE-2. There is only one bgp session btw PE1 and PE2. For ipv4 and vpn-v4 address family routes, the next-hop is going to be a ipv4 address. If next-hop-self is disabled, you need to config some ipv4 addr as the next-hop. PE1 will use this ipv4 next-hop's label as the outer label. Does it answer your q? cheers, Gopal --- Sachin Kalra wrote: > Dear MPLS Community: > > I would appreciate if someone can answer the > following question about > BGP-MPLS VPNs. > > Lets say we have the following topology: > > [CE1] > [CE11] > \ > / > > [PE1]-----------------[Rtr1]-------------------[PE2] > / > \ > [CE2] > [CE22] > > > 1. Running IBGP between PE1 and PE2. > 2. Running EBGP between all PEs and CEs. > 3. BGP "Next Hop Self (NHS)" option is disabled on > PEs. > > Now, when PE1 receive a route from PE2, how will PE1 > know "BGP Next Hop" > address for that route? As NHS is disabled on PE2, > the new route will have > CE's address as "BGP Next Hop", and PE1 will not be > able to find any LSP > going to that CE. > > Is this correct? > > I appreciate your response. > Thanks, > Sachin Kalra > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From owner-mpls@UU.NET Sat Jul 12 17:44:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13096 for ; Sat, 12 Jul 2003 17:43:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxbq14507 for ; Sat, 12 Jul 2003 21:44:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxbq14315; Sat, 12 Jul 2003 21:43:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxax23502 for mpls-outgoing; Sat, 12 Jul 2003 16:53:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxax23495 for ; Sat, 12 Jul 2003 16:52:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxax27415 for ; Sat, 12 Jul 2003 16:49:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxax16407 for ; Sat, 12 Jul 2003 16:49:03 GMT Received: from sj-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-4.cisco.com [171.68.223.138]) id QQoxax16397 for ; Sat, 12 Jul 2003 16:49:02 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6CGmxpp009689 for ; Sat, 12 Jul 2003 09:48:59 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAP51170; Sat, 12 Jul 2003 12:48:58 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6CGmw112018 for mpls@uu.net; Sat, 12 Jul 2003 12:48:58 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxax23151 for ; Sat, 12 Jul 2003 16:47:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxax04429 for ; Sat, 12 Jul 2003 16:46:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxax14057 for ; Sat, 12 Jul 2003 16:46:34 GMT Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxax14046 for ; Sat, 12 Jul 2003 16:46:34 GMT Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Jul 2003 09:45:09 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6CGkVuJ004302; Sat, 12 Jul 2003 09:46:32 -0700 (PDT) Received: from cisco.com (dhcp-10-24-17-135.cisco.com [10.24.17.135]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJB78171; Sat, 12 Jul 2003 09:44:04 -0700 (PDT) Message-ID: <3F103B67.91B1DC41@cisco.com> Date: Sat, 12 Jul 2003 09:46:31 -0700 From: Gargi Nalawade X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sachin Kalra CC: mpls@UU.NET, Arun Pasupathy Subject: Re: Question about BGP/MPLS VPNs with NHS disabled References: <5.0.0.25.2.20030711153519.00a889f0@mailserver.opnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Pe-2 need not have NHS in order to set itself as the nexthop. The PE-CE session is eBGP & so the PE will always set tself as the nexthop. -Gargi Sachin Kalra wrote: > > Dear MPLS Community: > > I would appreciate if someone can answer the following question about > BGP-MPLS VPNs. > > Lets say we have the following topology: > > [CE1] [CE11] > \ / > [PE1]-----------------[Rtr1]-------------------[PE2] > / \ > [CE2] [CE22] > > 1. Running IBGP between PE1 and PE2. > 2. Running EBGP between all PEs and CEs. > 3. BGP "Next Hop Self (NHS)" option is disabled on PEs. > > Now, when PE1 receive a route from PE2, how will PE1 know "BGP Next Hop" > address for that route? As NHS is disabled on PE2, the new route will have > CE's address as "BGP Next Hop", and PE1 will not be able to find any LSP > going to that CE. > > Is this correct? > > I appreciate your response. > Thanks, > Sachin Kalra From owner-mpls@UU.NET Sat Jul 12 21:42:33 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27572 for ; Sat, 12 Jul 2003 21:42:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxcg24972 for ; Sun, 13 Jul 2003 01:42:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxcg24781; Sun, 13 Jul 2003 01:42:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxce18301 for mpls-outgoing; Sun, 13 Jul 2003 01:09:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxce18290 for ; Sun, 13 Jul 2003 01:09: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 QQoxce19925 for ; Sun, 13 Jul 2003 01:07:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxce00892 for ; Sun, 13 Jul 2003 01:07:08 GMT Received: from mailsrv01.vasw by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.lopsys.com [209.183.201.132]) id QQoxce00875 for ; Sun, 13 Jul 2003 01:07:07 GMT Received: by mailsrv01.vasw with Internet Mail Service (5.5.2653.19) id <3QX20X1Z>; Sat, 12 Jul 2003 21:05:43 -0400 Message-ID: <35800AB26A91D711A75D00B0D07935F30389CE@mailsrv01.vasw> From: Michael Mandelberg To: mpls@UU.NET Subject: Trivial question Date: Sat, 12 Jul 2003 21:05:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am a bit uncertain about the terminology "sender" in RSVP. In some places it seems clear that it refers to the ingress node of an LSP, but is that what is meant by the Sender Address field in the SENDER_TEMPLATE? Or is it supposed to be the address of the previous hop LSR? Thanks Michael Mandelberg From owner-mpls@UU.NET Sun Jul 13 01:24:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10805 for ; Sun, 13 Jul 2003 01:24:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxcv06675 for ; Sun, 13 Jul 2003 05:24:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxcv06446; Sun, 13 Jul 2003 05:23:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxco07952 for mpls-outgoing; Sun, 13 Jul 2003 03:39:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxco07943 for ; Sun, 13 Jul 2003 03:39: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 QQoxco28314 for ; Sun, 13 Jul 2003 03:39:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxco17990 for ; Sun, 13 Jul 2003 03:39:24 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQoxco17972 for ; Sun, 13 Jul 2003 03:39:24 GMT Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6D3dLu79994; Sat, 12 Jul 2003 20:39:21 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Sat, 12 Jul 2003 20:39:21 -0700 (PDT) From: Arthi Ayyangar To: Michael Mandelberg cc: mpls@UU.NET Subject: Re: Trivial question In-Reply-To: <35800AB26A91D711A75D00B0D07935F30389CE@mailsrv01.vasw> Message-ID: <20030712203832.R5550@zircon.juniper.net> References: <35800AB26A91D711A75D00B0D07935F30389CE@mailsrv01.vasw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, > I am a bit uncertain about the terminology "sender" in RSVP. In some places > it seems clear that it refers to the ingress node of an LSP, but is that > what is meant by the Sender Address field in the SENDER_TEMPLATE? --------> Yes, it is the source address of the LSP. -arthi Or is it > supposed to be the address of the previous hop LSR? > > Thanks > > Michael Mandelberg > From owner-mpls@UU.NET Sun Jul 13 03:41:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00084 for ; Sun, 13 Jul 2003 03:41:47 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxde21522 for ; Sun, 13 Jul 2003 07:41:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxde21384; Sun, 13 Jul 2003 07:41:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxcq28197 for mpls-outgoing; Sun, 13 Jul 2003 04:07:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxcq28190 for ; Sun, 13 Jul 2003 04:07:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoxcq12179 for ; Sun, 13 Jul 2003 04:06:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxcq28302 for ; Sun, 13 Jul 2003 04:06:48 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 QQoxcq28269 for ; Sun, 13 Jul 2003 04:06:46 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.12.9/8.12.9) with SMTP id h6D46dXN024083 for ; Sun, 13 Jul 2003 09:36:44 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 13 Jul 2003 09:36:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: Trivial question Date: Sun, 13 Jul 2003 09:36:38 +0530 Message-ID: <689F43A6CF84E541A721C5C3FD5ADECC1438A9@blr-m3-msg.wipro.com> Thread-Topic: Trivial question Thread-Index: AcNI3S3fBxK3rAxtQkKBd2bIjaLuRwAFibX+ From: "Praveenkumar S Hosangadi" To: "Michael Mandelberg" , X-OriginalArrivalTime: 13 Jul 2003 04:06:39.0284 (UTC) FILETIME=[28F48740:01C348F4] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable RE: Trivial question

Hi,
SENDER_TEMPLATE object carries the address on the ingress. ALso SESSION = and SENDER_TEMPLATE object does not get modified anywhere in the path. = PHOP object carries the address of the previous hop.

Hope this clarifies your doubt.
Regards
Praveen



-----Original Message-----
From:   Michael Mandelberg [mailto:mmandelberg@lopsys.com]=
Sent:   Sun 7/13/2003 6:35 AM
To:     mpls@UU.NET
Cc:    
Subject:        Trivial question

Hi,

I am a bit uncertain about the terminology "sender" in RSVP. = In some places
it seems clear that it refers to the ingress node of an LSP, but is = that
what is meant by the Sender Address field in the SENDER_TEMPLATE? Or is = it
supposed to be the address of the previous hop LSR?

Thanks

Michael Mandelberg

From owner-mpls@UU.NET Sun Jul 13 18:25:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08200 for ; Sun, 13 Jul 2003 18:25:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxfl17716 for ; Sun, 13 Jul 2003 22:25:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxfl17538; Sun, 13 Jul 2003 22:25:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxfj05615 for mpls-outgoing; Sun, 13 Jul 2003 21:46:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxfj05608 for ; Sun, 13 Jul 2003 21:46: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 QQoxfj01678 for ; Sun, 13 Jul 2003 21:46:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxfj18049 for ; Sun, 13 Jul 2003 21:46:10 GMT Received: from smtp807.mail.sc5.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp807.mail.sc5.yahoo.com [66.163.168.186]) id QQoxfj18041 for ; Sun, 13 Jul 2003 21:46:10 GMT Received: from adsl-64-175-247-170.dsl.sntc01.pacbell.net (HELO cs.columbia.edu) (pingpan999@64.175.247.170 with plain) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 13 Jul 2003 21:46:09 -0000 Message-ID: <3F11D325.8070508@cs.columbia.edu> Date: Sun, 13 Jul 2003 14:46:13 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Der-Hwa Gan , Nic Neate CC: "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" , "'mpls@uu.net'" Subject: Re: Suggested improvements to the Path-Specific merge rules in draft- ietf-mpls-rsvp-lsp-fastreroute-03 References: <200307110101.h6B11Iu34352@merlot.juniper.net> In-Reply-To: <200307110101.h6B11Iu34352@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nic, Very sorry about the repeated delay, for I have been overwhelmed by other projects lately. Der-Hwa, Please see below: Der-Hwa Gan wrote: >>A. I believe LSRs will never want to merge multiple Path messages for the >>protected LSP. >> >>The merge rules 3 and 5 in section 7.1.2 ("If only one Path message contains >>a FAST_REROUTE object ..." and "If several candidates still remain ... >>prefer ones with FAST_REROUTE object") imply that we may be merging multiple >>Paths for the protected LSP. Certainly if an upstream node is changing the >>route (doing a slow reroute), or just behaving badly, then we may receive >>multiple Paths for the protected LSP, but in both these cases we should >>reject all but one before we merge with any other detour Paths. >> >>Does anyone know of a reason why an LSR may ever want to merge multiple >>protected Path messages? > > > It is possible that an implementation may want to keep all versions of > the protected Path message when LSP rerouting itself. It should be a transient > situation, and the situation will resolve itself when some of the Path > messages times out, leaving just one Path message as the only viable one. > Exactly. I thought all copies were needed to handle some corner cases. > >> - Modifying the final merge rule as suggested at the top: > > > I think the simplified merging rule should work fine, and is easier to > read and understand. I don't know what is the opinion of other authors > of the draft. Can this change be incorporated, or will this cause > any problems? I have to ask because I am not the editor of the draft. > I have no problem of changing the rule as long as it will work with the existing implementations. My fear is that the changes due to the simplification may cause inter-op problems in the future. If you don't think there is any, please send us the new wording. Thanks! - Ping > Thanks, > Der-Hwa Gan > From owner-mpls@UU.NET Mon Jul 14 10:36:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24852 for ; Mon, 14 Jul 2003 10:36:09 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxhy00356 for ; Mon, 14 Jul 2003 14:35:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxhy00059; Mon, 14 Jul 2003 14:35:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxgt08658 for mpls-outgoing; Mon, 14 Jul 2003 06:46:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxgt08552 for ; Mon, 14 Jul 2003 06:45: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 QQoxgs21993 for ; Mon, 14 Jul 2003 06:44:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxgs19035 for ; Mon, 14 Jul 2003 06:44:18 GMT Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m0.netfirms.com [209.171.43.51]) id QQoxgs19029 for ; Mon, 14 Jul 2003 06:44:17 GMT Received: (qmail 14730 invoked from network); 14 Jul 2003 06:44:17 -0000 Received: from puppy.ietf57.telekom.at (HELO Puppy) (81.160.194.120) by 0 with SMTP; 14 Jul 2003 06:44:17 -0000 Message-ID: <001001c349d3$5bbbd770$78c2a051@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "George Swallow" References: <200307101748.NAA22074@bifocal.cisco.com> Subject: draft-swallow-mpls-lsr-self-test-01.txt Was: MPLS WG Agenda Date: Mon, 14 Jul 2003 07:36:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George, I can only find draft-swallow-mpls-lsr-self-test-00.txt posted. Do you have a pointer to draft-swallow-mpls-lsr-self-test-01.txt? Thanks, Adrian ----- Original Message ----- From: "George Swallow" > George Swallow 10 min > > Label Switched Router Self-Test > From owner-mpls@UU.NET Mon Jul 14 11:40:30 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29613 for ; Mon, 14 Jul 2003 11:40:28 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxic14012 for ; Mon, 14 Jul 2003 15:40:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxic13390; Mon, 14 Jul 2003 15:39:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxgr05787 for mpls-outgoing; Mon, 14 Jul 2003 06:15:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxgr05564 for ; Mon, 14 Jul 2003 06:15: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 QQoxgq26677 for ; Mon, 14 Jul 2003 06:13:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxgq20829 for ; Mon, 14 Jul 2003 06:13:39 GMT Received: from mta0.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQoxgq20457 for ; Mon, 14 Jul 2003 06:13:09 GMT Received: from l20711 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HI00071S3UTZB@mta0.huawei.com> for mpls@UU.NET; Mon, 14 Jul 2003 14:11:30 +0800 (CST) Date: Mon, 14 Jul 2003 14:12:58 +0800 From: Terry Lee Subject: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt To: "'mpls@uu.net'" Cc: Terry Lee Message-id: <000001c349ce$fa5b8ba0$d9226e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/related; boundary="Boundary_(ID_rz4AkEEyGJQNAhijwa78SA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-type: multipart/alternative; boundary="Boundary_(ID_PCl5xcZMrOXNNFrt++gYvA)" --Boundary_(ID_PCl5xcZMrOXNNFrt++gYvA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 1. DETOUR object=92s Class is TBD, Why?=20 2. should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes. 3. in facility technique, a backup tunnel can protected many LSP. Say LSP1and LSP2 in different SESSION. What=20 the FRR backup tunnel=92s SESSION should be?=20 In draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt: Thus, the only field in the SESSION and SENDER_TEMPLATE objects which could be varied between=20 a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE. =20 =20 --Boundary_(ID_PCl5xcZMrOXNNFrt++gYvA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT

1.       DETOUR object’s Class is TBD, Why?

2.       should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes.

3.       in facility technique, a backup tunnel can protected many LSP. Say LSP1and LSP2 in different SESSION. What

the FRR backup tunnel’s SESSION should be?

In draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt:

Thus, the only field in the SESSION and SENDER_TEMPLATE objects which could be varied between

a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE.

 

 

--Boundary_(ID_PCl5xcZMrOXNNFrt++gYvA)-- --Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: application/octet-stream; name=image001.wmz Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.wmz Content-Transfer-Encoding: base64 H4sIAAAAAAACC+29B7RUVbMtvPrkSM4gAhIliCCIooKKiAiKSlBMICIiIl7EHMAABkAMCJJEUaIk lSBJcs45pwOc3HHnWG/W3tj3iPd+w3e/5/h/x7hNn6ZP9w5rzVU1a1attfc5unvLZCHa1R6duKPu aXq1gcBj88cBkS5E4k93CREQH9zJnyXjJzNhdGK72vwuK+FBe3RiEt4lBtJEcoIQGt6KABGJf+dn +WejxeEJo8S6Gd3EvHnvi+EznhRvffeOePXbb8TTXy0RL4zZId4YsV2MenmF+GzwXPH149+IWQM/ FesHfMqNFOc2LxWRzZNE4alPxaEjP4iFx8eLBcc2io05+eK7AxfEgu2m2LrVEvs2F4vcozFRtFsS RTsvivDGY6JFixbiWRxjWKYQQxsJ0b49frkBPzffjJ9+QjR5C7/Mw88Y/LwgGorXxGPiPfF03T7i eWzYsWNHMQLffFVPiHEds0Xv3vjlAfx06yZEl8FC3PIhflmHn2/xM0LcLT4Rw5qMwzv+1wHb9xYT RBXxWykhfnlYiBdfxGb88/zzQjz1vhDdp+KXU2jnr6K9mCj6ie/F+BrzxUIxFUfsIl544QWxWtQV 57HV9iE4wwjvNP6btz4Xot9i/ELo1z5xn1iAr9aJpWKNOCZ+EWtr9cNmI8QJ0RxbCHHybSEmwy7E 1/iZ8Bn+nyXEa+tEmYdIdOqeA5w24Kznse8xjPxakVPrXfH5558LqWlbQYO7CeuLCuKnn7DvEvzM xoEWrwZs+0SZ10k8PSxPfFwhV6zAmbx/nbYJqjVWfPvtt4L6vS7oq0GCFjTBOGHfPWyOC4VYjzcz L4q6k0m8/nlYzGtDYndz7Hsffh49iP9niiVLlggaP17QvDeEtb+hOHwY++YJUeHsdsB2UYjfNNFm MYmx00isfEUTl/pg3+fw8+Ix/MwR69atE8Q/y4YKCtYVl863Z7hEn/ARIcJhIXZrYuB2EjN/wrnH kMh/D/sOx8+Yk4I+Wy0OHDggaOdOQevfhi0LkV88Qoyld8SnhEbgg6fPWmLyccJ5SJxGO/S52HcR fuYVClq4S5w6dUrQORxj7xRsPlgEg3PEalotFlJYDMP+7xWRWHiOxN69JHIPklBXYd+t+FlehPMe F7m5uYKkfEFnfsL+PwhF2SXO0G5xmBQxF/vPVUlsKiBx8iSJ2AUSURyHTjuCTkUEHcsVkUjE98Po Ify/T5jmRRGhoyIf5z+Gz09YJM5FSRQXk5AjJIx8bIv/Kd/AT8jblxnhhgSmAiFaiVS8Vko6TTvq Mm8wj9xZupbYhU9fEk97/soswt81xPunvc+Zcap4320aJf70cP/38b+P/338f/qAnxuG4b/xX/03 juOU/AS/2rbtv7e9B96Ypul/hYe/i7+9/3n8ffwgOJF/WOxuWVa8AfFHyWbgFdv7n2NjvGqaFm+b /1W8Vf4bVVX9g8cPgh1LduSK05V8YC+/2fEj4PUKrEqCUPK9/9B1Pd7g+Nnj2/h9jz9wLn9jHx+8 +n3E9jiO/z7e8fh7/7A+ziUb6X8b3+CKBw7ugxAfoJIPvz0lwfGPgyP7ffR7ER/ikr32P48f+c+m VXIbfwTju8f7Eh8jv6nxUbiikf6roiiIbNjGN4aSvcORASk28A8ex+cKJH27ihtJ/HSAveTox9/g 4DgXTKvkMa8YoP/OuvBJfFjjR4t/dQVQ8Y3xiMViEEDQYJs3b/Y76H8bH+6cnJzvv//+hx9+ABr+ wf19ZVn+7bff3njjjS5durRp0+aGG2647bbbhgwZsmDBgnA47DcYBzx69OjYsWOnTp167ty5/9Iw 8AmO88UXX0DHQcrEe4fzfvPNN5999tmaNWviXYvvfvDgwQkTJkycOPH48eMlRwffHjlyZMaMGePG jfv4448//f2BX3EovI4ZM+aTTz5Bl/2hOXz4MHo3bdo0nNp3kJJYXeF3x44de+yxx6pWrfruu+8G g8E4wnGuWL58OXC48cYb0eu47wBh9A4fpqSkVKhQ4ZZbbmnfvn3jxo0hS+rVq/fWW2+hpz5cK1eu bNq0aYMGDQBF3MF9iHzjKSwsRANKly790EMP7dmzJ77BvHnzmjVrVq1atccff/z06dMlRx8WBfyv vvrqRo0aTZkyJT40fpt//vnn22+/vVSpUuXKlcvKysos8UhPT0eDExMTBwwYEI1GsT1AQy+uu+66 1atX/9murnA3INDey4ReffVVmMoVI46NFy9eXMl7ANV4UwEgPsFe99xzDwZl7969O3fuXLRoUd++ fQEd2jNy5MhQKISNd+/eDSSx5XPPPXfp0qV4A3x2wptDhw7VrVuXM64XXigqKor3GqOflpaGz4Hz 2rVrSzYMJvrEE09w0pqcPGjQIN8afSSB//Tp0/22dejQoVOnTnfffTcyt7u8x5133onOwv4/+ugj IAwE5syZAzsBsPPnz4e/X4FV/DVu6p07d05KSvKx8r0vzhuwhF9++aVOnTo1a9Y8ceKEvwuQ6dmz JxqD7A8AlhwC4AOvxFewJYwvPgQ+MLPU1FQMH7wp3qm4GcyePRvY4hQwpPg4gt8Ago8GbANuUtL9 N23ahC4HAoGMjIw77rgD7YnTGh6gixo1atx6661oMNqPr3xm819xZEmSfKvA0TC+MM5rrrkGrfUV Qsk46JN2nMPPnDkD8HHeoUOH+gx8BfPjaLVr177qqqvAAz6VzZo1Cy6DscNXJanPf2zfvr1ly5bo I0ADdNhgw4YN2B5wjR8/vmRowyuQfNHLr5955pnz58/Hoy2MrWvXrvgcPohX2Fjc5vHt5MmTq1Sp ggPisGgYjDw+sjgsgC1Tpgx4Iz8/P+4dca4rqXbwWLhwIXwZHURf4sKmJFwlo9jJkyfhR2jPyy+/ 7Ltw/FufmpYuXQrYq1evji39XTgZF6Jhw4Zbt269Ynv/gN27d8cG4ASkjWg/xvHJJ58Eemg/rBfg vP7663jFGfv163fttdfCqkH+cTbDSefOnYvPYR4+kqAscAUsxNdU8PTKlSvDtX3zxhD47oOvsAGI HTviXHl5eSV7egVR+7376aefatWqhe0B2p+5vaRR4RXOfu+998IL3nvvvbjmLClXYJz169fH8MHd fCWDUf7vsMIrLB8sHccKx4Tx4yDwMnwIcoBBZmdng9YwmjAAfAgOh1vFBR4aAOoGGjD4H3/8EYSM DRAj/FaB04ADjAENHj16NHAG0QGWuA0giOD4cPm47Cn5Gg+Xvg8CIjQDRwNoV/jgn7GCD8LaERow WFu2bNm3b9/+/fsRkfEGPABfQMBFN2FaBw4c8B3nX9gVkEEQ97GCWwErH0B0ENSKD6EuRowYAWkB l+/fvz+4Ah8OHDgQ1hhXU+gCmBB2+Pbbb1+8eLFFixaAa9KkSf5X0DaAsW3btnB2dBAtx3t8GPdr +CAGAoS5ceNGBFY0G/Fl165deI9OYVBgHvEgAqzQNWAFWsaY/muszp49e//99+OM2B4kD3/Er3iD kIH3gBHxFM2GRwAE3/AgVP6FXWEz3weBFXoaF4fg6rJlyz777LNxX0BnEZIQyhFJCwoK4k2CuzVp 0gSxCSyNjQEsAuKwYcMw7mAtjBTMBs4LdkX3y3gPKLG4boT/YnDhKeB/aL/77rvP7xfcB+MFzscw AUDfRxDlgRV8EJb/F7FC13w+RCMBDpQSoGjevDksGRjiW3wCkeMf5F/4IN7AB3v06IFgAawuXLgQ Z1E/PAFzULHuPeBEiHHwbphxnFLAmRCZQBV+t27dOnyIEa9YsSIEQHFxMfZ6+OGH4cWwdnyFcIA4 goF+/vnnfSoDVnBbaDy0EH3B6fCKpkJ4+PEOxNutW7f/GVZxHwR/Qo9BySCyo5HQ0mu9xzvvvIPj QwIhDvomAZb411jBrnysIEjiVuSfCDvCtGAh6Lg/RtgY5B9P0yB7YDMJCQn4FgaGT8BFcCj0CISA 7qD76DU0pP9Vb6/MDcuBAvcbMHPmTDQYHAvQEILRSLyiR3iFA/76668gmf+ZD/rcDqxAI3+uP+AV ZgBYMPq+bscnIN5/gZXPV8AK3A67iidrIBOkBvgcBoNojsbjDewKPgXPglX4W8Jtb7rpJq9C/7yv ZnFkxDsMPaQCLBAOCM4HMugpjBCiF40HpwGEOLeXL18eB4nn1P8zbv/vNANO98orryDjuyLlxNEw gr7pAlV/l3/BV3gA0gceeACYwH7iWPkPjDh6AfJBv6C+oI5gJBjr+BlBQdD/0FTY/f333/fZHp9D Y6BHjz76KBjeb6rmPQAyjAc9Beb4yhfSOAuiLQbCV+YlM4X/K81QssbiCz8g4OsrkKeftsdh9HfB 0Wp4D6DqSyBYAvoCALdt2xZP83EiP92GrwErP6kBn5QsAfkw4itwDsYdIQMWWLLkBWeEjAfbA0Yo Xr93aBUEQ6tWrRD+br75ZvAq8PHbhoPjmOBVMPngwYN9wYk4iC2vv/56OJrf33i9CK8A3++dXziC JSAQwGtwzD/rqyscDZQCrMAPUIlo1RV1AOwOLQqywrDG7QpYYXvw544dO64oemADhAAggNEHVrAr v3l+MwDF8OHDgRViOgBBrz/88ENfBcVlPEwIkgnd94ndPyaoEhEN2MIsQVbr16+PnxHH7MYTcgLx Drk/PkFUBVbAFlESXgzrKvYeeI9XAAjP9b3bz0qAFUwL3I5D/evcGQqzXbt2vl3FYrE/F/qQVFb2 HqBWHz2fr2BXYMuSasEvXmGgfQ7v06cPgmzJuhDerFixAt7hT5RAF8GLS+penMKXYeBqiKK4ZEIv YDb+XogFvhiLmwqI0a9vQFD5fIUMCJYP023dujVCOWIlCA2vMDa8wXmhMXwDg8NiYwwBDOzPPljS bbExsEICgpCK1Due45Q0FXALwLz99tv9qAQ3RBIBoJC/QwHGK5nxIjA2g8hEy5HC+DWrkgeE5SCI wDZwRtByyTPiAcWFw+Lgo0aN8osS8RT766+/xl6IbojChYWFJVPpKVOmIFACFgwEtoTDwlMwuGW9 B3CAAZf2HqA1yDaAA3v2E0xAhN7BCFetWvXn3PmKMiNsCZEOOGMc49/GS5S+ky7yHuiXz7SIQdOn T4cygYCMW0X8DTaD9kD7Qdq+5oknTb6hIlB+9913OALexGWVTzXwWdAU9oX+uQJk2BIMBjvC9uIU F5eI+GrixIlwVZwCXDFv3jxQPXQaQidccurvj6+9BzbGoPiHBWOAqWBd6OafazJxrOK/wnfiNdt4 p+I1c79+7tuMn4P4JeWSddq4uf53dWk/fJecfSjZ2SsK4H4KGS93lCw4X1GQ90/qNz6ePscDTfxE JSvn/sbxb/1Zg5Kl7P9OM5SsgvrmdEVgvaLqe8WbK6JqyZmUeMPi4MfZEu/jkxp/LvKXPG8cipIF 1ZKV5Hgv4iPlnzHeDN8kSkrK+EnjbSspIa6wq3h74l/9mfD/PD/lj6k/ynGQSw5HvO/xUuGfp5ni X/ni5M/niltRXIpccYR4r0tuEJ86KWkJJY38z/Mp8Tm1+DxUycb8D+cTcWDbe/VOY5uGY5n80T/k 4fGg5T8d13QJg8vPv2nuFRDxk9zfn/bfdK6/q/2e4f/ecgy8yc+/5Vyud3weFP9cePIA/cOw+k+4 /L78Pee6bLS2Y1i2/rsZ/5N8MD5RDirxnpb79/iFTab3tPB0yIUr+gT2j7ErlxsdFy0e87r09zTf IlO3NcM2fZTAWwg+YPd/EFaXn390xr/jAVQ029LhgTbFZLuwSAmFoHb+MVgZOoduGxTllATL+Xvs yg+xJCnO6dMF+/adOXc2bP1zsCouCkfCkqpolvmHJOLfOaZikU6wIhuwgLgNipqkODY7ni4bOmlr V9CrT1tLVlKhQV5EDBmOZvlESYZDsmXH0BAEACYFz2OxOwS0R3L/13GnpJz+I396s7022YZvIcgc TM/FuPm6Q4qJ80NkRi1LAVccyTeWLVUOHJE0KsQ26KFiGzL250bR5TCFz0nVbdX5a84p2QYoCadl fMjgJ96hDYatUmTBYqtPt+jYcaH9ZzkZtkhVJIpGHVXH96Sblq/xdEPjA6BHvnr9PR8CXP9GrKc/ VnV0fsujcDmf8E6Nb3SfiPCNYpiqAeNhcWBY9PMC/cvPpJ2HHYy4C280AKXORoHv/EDFR9BNW7X/ Ki/ZGCmXVT/vyAcxcBDu+7Jtwbvbad3u0dcf0qJuCIZWHNZ2rHYvnXclXcOGFs6t8R6ao1sEBzX8 oOmD5XqR59/H6nKGgpMQ0483HDi25Ydp1adxbrx27qJ65CgVFsF6ZHTl4EF66SXl2Wf1dbtsNO9y 0xjzy7m/Jx0tTzf+JbTY9bw8ldjIYTiefZO2/Yx7TzutdmVp+k8UYpdXImp05Qpn9lf5OTmmQhFu sEbRIPwQp4TVmzoBMcAFTuVKBf4j53/Ib//FAj8wA+PDXo5XnMLDSg/zLx5WrnzkhLp2Le3c4SEj oyvGD4uoRf1Yzwf13afhMBFC0syYo2U2m6Jj+bncX9SNXpTQPO+DZYK9rKhBB45Rr2eV8oIe6Wmc UWWQAL7fusl+931j3VKpWNF1CmouBfPp4kVVMjXV0RlrG8YN0DzEXFdDb+z/Z3aFI1vgKpcHFrJY tUz+lbSciF1U4LCxkH2pkH5bR7PmFBTF2NR1KrwUcZ97yq6UqTz/Cp0uYg/QbJO/cn+HC0qIOcf5 a/FOYqBsfkF7wkQ//UaPPRwUQmvdxPx5hau4USL5yF778/fpo3FupBjjpciknL1Im9ZLx0+HsRdX ugwKRy3NdkzuFJs7sHL+DaxKlpK42OK7mW3BFDAwiuZThn46L3rksJJ7lm1OsWnHPmvsuNOz5lAB aARbOLHNO/V27Zzy5dT3P3SKiiwMJAgdtIV9AZfj57x/jVa9IbmsasM6/byWHuqlJouCjCTng4/0 cAz2YuSH6eNR8quDlc17eTOF5AsR96fF5tyZ0fP5QAZERTnn3AvnNXC+RwEcK2ISevZvYRVfFASP hnQBShrSLZOKi83cXBneDjPLDym7d6krf5VCMZxaO18QmfpN7MnH1VW7bQsO4UYUCk2dRxWrFNes nvvO++6ZU6Qa3GfNhTNaHlB/lVcx9B5fqeCo3Qep7xORUqmxhAS67XZz/UaMi+xQ7Jt5+j13yyPe L1I9b1Acdftec+TwwlkzWGFoTswoNndtDR0+GNU0xko2tJAUzS8K/5t25aPkF6kuXIoohgu3xnCc Ph0+ePBSJIYRIdOkHbvsSZMvnrsA54CbxTZto7va0eD++WdOAAU4SuxkmB4dZApRVL0y/TD9wIUL bFoG2xXrRfIE0h/rUaxGeAqKYJuu6UkDh+MIWTyHY287InXrRYEUJxAI1q/qLJ5VHC5gW/1pDTW7 PtqxR2zdIY2ZTTVUWX7pHRr1WSg/anqL6rT58+irqZQXDoPYoHRORtWtu+0TPBsTg3nnFLsniylm 2B4lUlQxw6amewpHV9xQDDSNTslgS5VHTdJJVW3KCQcLcxAnoCWd/OLgljVUoCiQULxq9wjN+N45 g7CC45N86Kz10Ufu7IVOgQwGMy5JxudfFmVn06vvWcEYKxrXMX7b5ra4MVcIq1KN6CeT1AjOJkms Comp4kqsOFKwDVt+TLf9EdRVpiltx/bI008UVa4E8KXq1eR3PqYzR9F6bf1upWcns2md0KgJWq6C XWBZytJ55tAXaeEKBzrPsKyiqP7F58a0mTrkDaxKJ2nt7uiK1UbeWQ8r1zh0Wj+SA8NlKWJrlHNR zYsYiJ5wseIi63yuFQNGrmbq2oVc8DX6ZqAvx85Gdv3mFhWacPKikLRprXrshBNVOQadOk3f/aD8 tpEK5RBRpCBK38+hQX2jK5dx++B5R07RLXeE291UOHsO2oMhjuTk0GtvUuksK710rFGdgq8+pUjU q52bKsAw1D9g5bgKYpPJNOZHFRwSsUBTydq+L9r/Eal0wBDCSU+n7g+Yu0+zyjypSs8N1ioL+9mH 6fBpNkL0/UTE6veAPepN8/hFjtmg1BVr5ZEfyWu3aJ56Ae27M2ZpCxc4EZW1v+qo67ZE9x4kz3hi 4ZC7c0fszHnHchzTsU6eNPYf1kG5CAhy1Ny0iYKFbMzhKB057Pw4UT9x3MBZohFj67bQr/PpdAFC iXIx35q/SJowmo6cV8iW4Ce7T1HXW4reGEBHLukx05Bk/dsFdtMqatfO7s6LsH02wdWr6Oa2BSJA QijX1aevJlCInTji6s4VaYLjyuBbrhpw0OVcAO9ggkcv0IAnlHKJrhAwKrNpc+27GeiVjOH4bKJb o5zbpCat/40YF9tRTP2LmXRjU+WXH/ViXbcgllV6+83YxG8pL+Qr0Oi5EH0ykubNobDNCTg8YsHi 4PZtOACQjZ0/R8uWROBEoADdsbZtNdZtBFEzaYSKafo058RRCHELUvj8GZr0gb5rrwVT0XT14LHg hHeBCeKPElH0zdvNV/s6v20nDmEmFVj00tBYl7b2zIUaAhyQL5Kp2x1u6UztrdEUkWGNoaJC98Nx xanplkgkEXAbNo5OnQMCkMAK7pU+CGBszUtnWHBTDLa9by8N6E/VysrYV6RRcnK0/8DghSJ0St66 y7n9OsoQ7rARtszJRJGt0KrV1Lat0627dOZ8WHFALOaJffTY/dridRgB0zFtydHmLjIH9pV/+pmK 7SgSre2HnW+/D+3aCpZkF9220539g7RvP2MlO+bSpdZPS9xLF5hdC4L07tvuhg26woxqhEP0+bva ivVqjIGMncmLvvkMrdoBf7DBc2Dy57pL46eCcDXXcmK2unqHe8+tysBntEtqzEu0jK+mOuXLGI2v oYWLDFbaDu06GuvymMKmFbBFVlGLZkWLF2C0TUO7AitW15JXvPOUp7pjtzH0hUtlkpXEDEkkUEoS demobTwQgxPt3UxPPmJWEJHb25ubec4ZRhg8cZp6PaBWSg+On27EHIykcbaQxo/Rnn/c3XSQ5SG8 O6eQBvQNPflI8bY9TF2KStN/oMlT5SOHYVcqhnzBAmPqNGX/YcYqapug6Jlzybt6wM6P0nMDaf6P SkiDPFNAWeNGat/MDV7kBQixvLD6yjPG9HngfI4mUZleHxJ94iltw55CbG1rKuzjhYHmbS2Vbxde MLw1KSeL7Ie6UapQ7up4cdl6SdXgLbGZv1qNaoFtLJGG19DdbWjBbFe1/jjnhUF1DYW4FsyU7piz 51vXNz6VmGAmZmAvrU0ze8FCHXy+5zANepKykoxaNXO+mkwyj1EoqtDIj6lsGbnDbdEjp0GXUPju 4mXO/Z2Lpk6k03mgPhUfrVhPbRrGXnnFPcdrMQw5aA8ZbE+eakJRY3TCQRr3aWTiFBncizELGsYX XzlTvqWz59A3LVd1HnuSJnxhMMMDK8P5YpwzalzBfh4svTjmDH9LewtueIg1qWYYPyxw2twovTwy UhRiIQOzQShsd7P1eE/rLH+CiO9OmUC1yioiIbdbH2nrLm7S0XPymy8plVJtIWyRaAaE2fueSG40 /AeswJhM6JwlI+sDCSz4mW5oSsmpAEquWEEa85UGpygstD8YblapdBFe2aV3aIfnLEQX9uylls2C SWXc0eO8xA905tgjR8kNGuZv3m6DD+AXl0KxceOjddKt8VOoyJsgKzorPdhJnzTVjfAknlZ4id54 PW/8JPn4Ba4TFBn66LHOl5PoxGnYuZRrWr0ep9HvOqeOcUknalmTJtIbI4q2bGFSimo05nO9Xz9n zXqOxboV25lDjerrLW7Ut2z3LN+kA/lmlwfM+mk0d1UE6TD6uXeL26M7qNhIrBT9+PNCjmbkQn60 axFjrNJIJFs9e0iFIbqipoos3ZuUBXGBlin3HM2Zsr9GNWpQOfrJqKILuSEY8y9LqEGDKNgvLdse +anqcM0hr5ho0EuUmZTX4T4Ky1rES003baa7bnJ6dSwqzoPgQ94d23aC7riN2t9Z/NtOA2BCUP26 1KnVmKbPj4BWoJDPak7ve+nryXpRDGagK6b13DD6+BP7/FkJVhEupO6Pm0OG0M79JghLlunX1cVP P07TF7NdGba5ZiH1vN3+YJpUbLLQA0917pKXUsH5cqxfRAgiWx/+rpaRbN37IIHbLTdkGNJXY6hU WhjI3NSClm5ifZcboiHPR8slIJYZLW/O/2FxJKI6V65VY6xcr47BbG0ZdOKANXY6fbfQ3HNMjUJN baSH7jay0gpxkA5dpHVbOQVHCPh+IbW8wax7deS9r3RF4lTibIH58vN689rKqBGOpLLN2o707Wz3 2vpWv+eN4+e5LnCuIPb+e5G6jbWFv3plEMfdkSN3usn4eorKKskxIKuees4Z8a5x+gRjhUyzVx+n 96PGxq0cruFC6zdFenV1x06GJkRct/ZvhzCIPjEovP8crINzqxHvWunllEd7qTkFnpYjWvwTNW2k VblKnTqJLvAFAfrmHdHefeXUBK18tvzwo9Ke7WrUoQ37YyM/Ut59j2Yssk7lWfCUP3I7V/D87Ach DNkQRkLXYBKGTlGVtK1H5V6PqglCy0jSGtUz584zEbgxUmvXUfuOGjRq9wfpeJ7jlbiC387TapVx bqxnr9+BiKvi2AVB/dknqXzpyIQ5nIaQo+48HLyrY+j61uG17CNcF1i0RbqhQXDyNyq7tWsWhewH H9Vfelk7chQSmqSQ83h/6tBBXrKMp0HAsAeOGF1utV9+w4oSBtcoDFK3u4uuaxabsdhzOleGHqvb WK1euXjuIr9aouZeoCEDwUXG9c3U+cv9SlP419+oyTWKEIUp6aE3BilHIYypMKrF5DB51VvlCt0O 2cmFKdObJ2ObUr0Ml3kbjJdz0n6mXzglWwXJVyirDR8TkoKs0s/maP0HRgJpWlKaOXasJ2JtO2ZH +j4HA9Z7d3PzDOg8ZtL124zWtalypchavqoPOlhZ9ptUtYbZ7aEok7NrwPwmLbCurRWa9oPkVZzc C/nOnZ21gc+ZBw7xIgcpbD41gA145izIQ0jl2MV86nwTPdrbORuRYMyySwOfiZZPpRdehX6RXDsW k+jhvtCW2tP9KS+C74tgjvNnUmomPiwa+Ip57AzbW/ASDXrMzS4dgVRoWEv9dKIR5hZEED49hGEU 1h+x4sQXNsQlVq5IgI815nuI/Ah9P5auylZEEolEt1nj4l0nwT9hRZXnzDcb1JPQmBva26s3YX8J R955wGncUk9LBdVAYBjslK71wVilkqAbWseOhj38LXvyN45Ipldflc5eYPULsQpZWLeG8u28CHkX NJ/NoRtu1h7v4+47zFUkJao9/axzTT366isYLxoQDat0f3u6qz1tPw6vRTzSPhotZQfo9rusi5cL udqnE93MZGpcjzYf4FQUn+zaYl3b3IKubt7KnvsLMLHNmLHgB7dhQ1WkAEPnto7a0t+8ErcdIZXT 5DDJV2hRj955ms8AQExZNpgb1PDb2linlnIyx1A1q5z2zhvkXcJYdOgY9XrMSBSII+rQN5Q8pH+O qZv07kgSqXk33BZZv42zeGTBB08ad9yjlhJ634GxHGg4V5KKaegQNMz65hs9xMHAPniKuj9GNau6 s5aEyDPoo8epbiO1e0/acwgfWJqsDhrklK1Ao0bZXOchEyKkx/12i2tpwQoQhiUZoTkLYtXK0tVX W6t3ehVSiv26Vm/ZhJKF+8EXVMBFGPfceWvwMAnDlBowXx5hFvOcRvGlPOOB+8AkBowhJTvy3EvG yUJfN/J0Q4T+sK7PsCXfB8GZms1FRYvnMGg5CPPBC0kiioOL5ILOnc3DR0A2Rp5kQFCVrgpFIbVu LC1bAg3Oafy2DdT4OlOkF70+Spa4LiDD6z8aL5cqb9esGv3qO6lY4pnXnbv0rnc46Vnmhg0uZzcW LV9nNGqqX12NFq9HQs2V870HqGI1qdO9BGWC4TNVBUEQQ//SyzGvPI52Ov2eNutUtT8Zp3DJWld2 7FNuvNHITKX3PnZDyAVJO33WGfBMMRNUW5q3LIJULGhYq9eq19QHS8g33kg//uwVlEkf/7VWvVqM fUeo9evLH39lnSoGC+mQobp1BV+xXXEdhmWpw4m9TmdORx9+tpAtKsEFVuXLamM+JZkHPe+3be51 1xkiwUmqmDf8NQRaHsRz5+m9V2Tknlc1pZ/WeGZsxorPU9eHEZTN61vFVu4wdJVTlHmLi1rVs2vW puMn2PVdzf12XmHpUqFaNenXnYg6umHZ23Y5mWXCd3SgrfuI54V0bdhQztSeebZQdw34E9zjxVec qmX1F/6D12ADGmjabg8bCcJ56KHg6XyeWsDpvhifA/SgCoa+cTQ3bAdJKSjQevaNls6W0oTTv49x /iSXWfaftbv1Kk5JDsNnk4TRulnk+9lmzFtFSH/McZDlelM9OkcGrjHQyXx66nkjNUlGggO0ExNi T/SMHDrCnY3F9F69CZo2IYla3RA6wqmuUmRI02Y5GeWddGE9PSB69LzhaITk85vFTr1GpkiyHmxH Egw7WgTLffldNF7v0kXnnJp0WTdeHs5c0aZNZMtu3ZtHcX5cRpVKWXd0ULft4SmakOoMH8p7PdzL zPMcBG0d87lWsxRd34rOFNrQ5oDvzRfVRGFUqumuOOJ4xW9p8RK6pqqRJPRWTfQlm3WJeUGbu5Ra XQf20K+u7L73NlJEWbJo/vdGlWu0TOEEhC7SpRtvpV9+dbgKYUMV+GtbQOuaZSK42BwNCdIyBu+b OM1t3DiYnGwwVkJpUFeZOFGBjoGAmPBpUZNrudmVytvDXpcu5mJcQvtP0DMDNPh7hnA+Gh8rknEo HQY/9FUrq4whkvRnHuWYAQUes9zHn6HEgPJEH6vAS99y86X+gxmr29vL2/dZnrozZsynspnmre3V LTsgZYyQ4o4YRrDkbvcbZ87hjDHY1fjJBsRJzWvMtVt0hCsM/9gP9exUPbOsOvFHXeMFxZG1m6l1 K3CRXq18ZMz4aJR1kbHvPHW8Q0kUeoKI3nt7bPdBGIh78hjHzVKBaKKX4GRlqG+/QReDOG7Q9UI8 +fmNN6/mTboW6hRZvka/s30kQcgs9QN2QFhDhjo5hTxbvGo9NW/ADJAgpNtamRu2QDSDZSPTZ1LN miH4yDXV7WWbFN1EQ7XDF9Rb22hAO7Oc/eEoXgwGVPceM25pS1lZ8jvvULFXUtu1N9SpG7rjdO1q 7D7I9caYpH31DRS11bqNsnYjWqaHZHrvNfCVc+dt2o49GAgFWH0/x2lYw80sExr3qRrmUpK6YL7d qL6bmCL3HySf5Wt/g/uPETRtKnKNZKtHT/ngSQ6IMVJeG2ZVruwIEatc1hw5gi5Jhmq48+YhFl9K TLAFu63UrDFNgDbmEAevi3H1j/NlCZCp7H/WxgPGQ92KS6dazOfCDgTgaOayjRpE5v690lNPQWXh aZarEBr2nBlmd9CO5kT6DUIglkWq1LO3cfwMSyY5pn83U69SiXOra5vQj78gAAdtisz8Ua5ekapU U6ZOI4nDkLX013CzlhgX59GHrUNHmLiLgvqHn1F6stu8ub5yNfMrsPrgLVekIaOXl61U/Fm8pSvo xmYIu4WP9dTOS+hLdP8hur8bJSSoNzSNrd7AxedLIX3ct052JjzOql/Lmv696k3kxVatopatdJGJ 5lktmsor13M6kH+J+jympaZjfFW2E2G0axddsYwiqq9mFc4p4HoaB8EDx+iZJ9zSAagmx8PWhiO8 84GSa4J7lAmj6apysE8Z8ahZ8+BPP+ou27kyY7barFUEAGaVjXw+Qy/20ocjx9TePdTMUpIIOHff TTuPcV8ilj78fTMlgeo1klf8yuupwQLTZ0hVamjY7Om+5skTwEq/mG++/q6TlkyNGti/LIGmUUIS ffiek5Jt162u43Q8YUXGpi080SCSQi2amnvPw8NjhVEa/DKbRIVUZeK3zDAK6cu22zVrRNEXnLdf 34Jivu4tjLzvoZ6yyJTAG8kJ+jtvGkV8hVbRnHlU62rEdyWhFPNMZrry0N3Suk28tAPIe2sVeGYW Azp9ql4tEVDrIsPyHFBu1bxw234NnLZuEz14DzdDsMR1H+rOsgQ7Flv03AtOejqCndXwmsi6/brD 1qL8ssaoe5WZkMpG2L+/diEMWtVPX6QnHgft0PWttf37Yi7SdXI/GaumpLsiyRkyyDx3Gk1Rzly0 nhtqJSXRNbVo/gIQqxyK0eiRZlZFqlrKHTdB8+aMtD0HrPu7IDjKFStayzayMeu28+F4mFAkRUBH UeF5zk+P5Jh3dyxMSLPYhJoVrV7BfqSR/uFIuyySEa8Q2vYG6adVsJy8I+eoa2cpVbiBNFaAIgDz zn1xaHjfMZ6VJn/BGYUhJ6Z9o1cpU8S1wXT4slm2sv7Ou0HdtPIv0pDBVLoiy4/kNKl8GfOTcSoC guHaCFgtWrESzkyxH3kgepIr2HpMdkd+SsmJPDRZmcFPxpoxmyvsy5bZrW/Q0bz2d9oFFyUEOMi5 V15jYkxKJ3BI7nmQQeTIKePxp5noqldx58zGYDJWYz82sytTKUFvvc8ZC9jjxGm7Zw/01Ahk6V9P JSOm4Xjf/eRkZWtQDje3M9dw0qcVh4wRb0llKsPy9coVzNdeoohkgaXXrCCIQx79gFM63RzwrF50 HspT+2xicd0aDhuMiCVBzCcazZuG5i8BISoI0DaPr6S7zqYD1LGXLJK52JWaqrS6ibYcYatbMDla t2aUmaq8nCb0Nq1o1RYuZp7Piz31dCwlQ0pLonoNol9PpDAn9OFN66Kdu2B8FfS3ZdsYsldopGiR O/bj/MrlCkHR99xHOtjKMSOqMuA59EJLzaLhb9qFOWhQ8d6jSo9HmcGqlHdnfg+sYsDq09F6dkUb 0X/wK0Uxr36bk0uPPsbBUaQpI4ZT+KJs6dKSbVS1BiUk2WUr5I/9OBRzYw5E9c907XWqSJUzUuim lsU7d8VUnuGlAU9YaWWCIgG5s123mjpvLLCNHsyVOt9LKUl6chK3QSQ61SrSN7PwlbfW2o+CDvIa Z+su581Xok89pLzYhzYtAf6h9bvc66+llGTKTAsFRCSzLH0/ScqNhgsjNOZjqlwL4yKlBvKfeICK CiXbAanTi4PhUwYYLxAI9hug5IZCIMMLOdQOqgY6JKBgA5eVnLxhB7W5lURWuHy2OuoD63y+AZfb eci842YS2VJ2mjPxU6ami2Hpyy+ockVKz4p27qHlePrfNcxXX+UJpqQMrWMH2nOEFenuPfIDD8B3 TJFidnpA3nWMF28oMav/k6ZnQm5Sgt2zr3H0Ej4vXjGLalaQuayXGElLiN55W3DfUa52Tp8QbHC1 zraRTCki+uxjZ3bt5zI7mqLqEMYsXyH4IXlO5hF2OXaepAhdCtKg5/JLpcFCrIREJTM51uZ2OriN 7WTbHuO+e3SRjHGRr6oa+mgEqRJUiLJrr9Kti+FhYmekhEeNdiWTpwd3bKPraisi0UpI19947XJk WbzMadycRFq0QpYx5mM7t5irk5t2GzdfTyIjCr/+4iPGKk9Sxo+nqlUoJTV6e+fo4VzyaiL2O++Y PPTCaNnUXreF+3LyjNl/oJuYDLGnXds8OG8x13pN1Rr1LlWuYkNXJySbdetFcV6M1MkDzqO93UBp C7lJYsCqXlb7cGQ4LOmnz9KQl7Ra1xbUb57frTuSOCrmTMFwYExkOzx/6qoUUUiSyZApalCuTuac H6l2lWiATZHDbrUqwU8mkBLmqaNJU6QqZUN8/9Uk89a20sqVXlpDxsSvCxrUQlNBYnqNMrHZC3kh GKj9m+laNWyfTBWqumNHX178NmGSXPUqGKFcMcv54gu7kGegndWbjKZ1HZEcSk1wRo/gZc/Fujlh ItVg54rdcEtw434ibzrzw4/MpESYllG1vDxzgQl3DYbNDz6hjOwYeKxUOend4d7CENNavJBuvMGj a9YDsTffdEwDubE64weqWDnKc1VcC7XbtynYvY0TqL3HrUnfudNmujuPMxa6t6zLZf+TefGSt5bY ML1rSFyeCTp8TOvZS/EGzvHK9XRbu+DRC4AkeOKM2q9PDBTKMizJ6vukcaEAu9n5GqJeXlqC5WHr 3HytuXYruEE+lUP/8VIkMzWC+NKoCc34jryJNnrznWhmaVMk6FWyaNp0N2ywcPplhVm7CjoVS06g ka/D2hEa7EmT7auupoSA1rRlZPFKD2nX+WK8XipbY3YNxD7+wozKyNa0GbOoUoUItznZfvhBJz9m QPkjF+ve1WYRCKkpzI53qru3w7Si+/bTzc3BSxBv0IeEBPOTt53iIE6qRSLkXWZayKswkAo7Fi/W Q3oFgje9lV2WN+8JERGlzz+hKlUvIUzwM4HKl6fX39FjBuRc9Ifv1Cb1vBp+MqWnxcZ+xAm74lqr t8VualPMc6/4PJH6PkCHTmiQTFt2Ued7IWZi+PzmW/TlHLgtyJSn+ylJqZwd1MimOQtsiUWmO2+R WxV+kagmB2j4MBORR3bdb76xa11jJglq1FT7bpY35evY075Xa1RT/fnigS85Oeyb+uo1Zt0aMW98 oTPNDTsMdBMwvjzISk/gggzGsUrl6JfjgIBaHHZfesYtC7Ga4kC3wIM6tIT2U716l0Kawikhad4a V55eB5+C30EpNp4IHBQuiBjLlhe2bsILSEQW2M9MDFDz64rWbsUe6oUoDexrp4IqYdLCaVQ/uGwp i+FinT74KFq1osqliQS3TLL1/ptOTgGnwz8uQqDUvIhjde4a3nWAJ7nPFtD99+pcCUkwry7j/ryK F04iL/3me7dMGrjFgep4awiv8FBd57vvrdr1taQEqlPfGvcZ8So5x/jxZ+3ahmBgGIZ19wPO7n18 2EOH9BubeXI64FSrbH/6mR3THajHCZ8aNSt645voIhns11c7VwgDkRfOoaZ1NU9NsQdVyI68Pdzy Zh5VntbQ6PL6Pp639VfBuo5vTyRjizXbqF//PAQO5DgiA31Xs5LNZwfkRbyFvlPnUotGbMnoY7Kw +jwhnYRsVmnvSbrvTi0Vu7Dwc2qVk2fMkYpUE9nTmE/d1DTAwvMjjz8VvFDInUKEvamFxmow0ahd 3lq1hWfMQCOff2VlQgkkIcWmNwYbpuHItjVrtnPNtQo+qVpNf/tNx7vM11q+1mTBlhrGQeo21pYu 0UFiwULz/o4mS8REq1QWPXKfe7oAZhFbsYRubqVyTY+pyWnV1J49X0O7T52hHt0kduRE8CEaozZv pU6YSrlhZlQ3xhmNf3EFIAJQihPzVxxhEPOK6MORVCkdAU5PhMUi/kKTX03z5wHYSGFB7LFnImVS dS66JqilAs4noy0Z5hqhBcu1+uUUbkwGxJjboq6+dq+MFL74Eg17yZNn6WiJOfilmDcnaP64LNa4 jrcGIFGpXUHn6TDk4ipByacJ26u8ua8PMiDHJduYM8+t20SBj5QuG3txsB4O82Cv2Wbf2tYQ6RF4 VlZp6btpPKNgakbfxyiNU2MtKeBeX8vcdVwyKXxoP/XsTgnppsjIBzKlEs0XBoaKY0zWr78tlytl ZoG1kn15aT7wgLbjiK5Tke0V7bwViVxSlsm/vo2NCkny7J+pxW1QF1aWIPamgAWufqmPFjakAlLe /tBOKU8iuRBkghY2alK8Ym0xUD91mO7pStWzyVO8YBvrnk5F5/lK7qI1W53bWlqlM4ipVagfjnKh gYMGDXiFalY3vUK3dW2jot1bWfPnBun51ygzEIQDwor696U8PayQ8fN8Bzm4F8icO+5yL7JdRbbu Mro8rPtpfmai9vTzlMvrVmj8aKlSnVhyEhepypSxR31GxQa+iL43nBexiFQrUdgJIlSrNn00niQq WrU6dDsIJ0VLDLjJATNNULVs650PLO8a9T/MO3OdjGflkGaFLuZbb7yhlikdgvMGEqMiBRmT0rql tWiOA9feeszo2DESyEIboBZs9OWJPubR07Kq06L5VvWrpewEPYnjr5tR2u33dCS/mJOvGfOca2up oGXE8cwsG0oJUSYv4t77MJXP9sqJwm7RLHpwN0/Hn82lp1+kNBFMSKAE4T7Vhy7JSPTNJYvchlw3 s4HVzbc6xy6wQtt7yHrwMc7pYG+pQrn3PnXrPtu11NkztGsam0wgQk9Jl3s9phw7xZEd8Tc9g7UB GhMQalqW0vupolzFzblEz/ZWeJQTrAAS6iQlRdA9d8ubtllXrIG0vOXyXJlBunmJ/uNZNzNBSkhF VghGQjhTX+hv5RVYkJTjPqfKZSyfS+E7VapFZ8zkZb0nz9KA56BSwgnCTOA00K5Z0x09TpEMV5Ho 1bft0lkxzySQxdPc2VyIOHTcvLa5lIY8CNgK++Yb9ZOHeSrt4AmrV19KC2B7Fwg88aibEwFxOL8u YbEB9MA2DZuoazYxxUKK9HmWzThRuClCb36d8t1s2aHIxm1G69auFwqRfgbr1sldMJvV32bkINcx CSMN8cZIqtfwzJJfucw645vCyhWwS4w9Oo2zmzpV9EnjNTXyxxqyyUvmXDcCKy2I0pdfUqN60Cec piUJp3Vt+mUWi+cd29T7O3ABk+0tiZJTqev90ZOn2XPn/2zVbRr2cna/DdZNLe3la3S4+bG91KmL G0jQgAlMpVULd/UqngxdulSpXEVNZTthbNu3Nc/zLTDVLbuMTt0oPaD7GPbuaZ8pjCBXXbXcbdKc knhjvULVyKRpiqlSQYyGvWb79RY0tVJ5/a3hMZNiOSHq2skzwiRgFc5Iir4+kAqK1HPF+oCnIxx9 AqonwCB4Coc+z+nJuYvh7j0wRioXo7jIYNSsGpk6xYhG/zBHT8blKyPA85LL+fLAoXn1a58sXTba onHsnRe1C+d5adnnH6k1ShvcsEQoJSpTwRnzqWla0In2myNMJLCMlVefDwj9oXvV0xeRtlqzJpt1 rvGkbAph9DvdZSAJUg3ny8+07Ew3PUABzw473m7mXuQy7ap1dOMtTppXKkF3enazjp0PQ9X8ttJq 3MJirAJaerby5utyqJCijvPRKIeXWCTgpHZCgvnYozwZKpE78ClvWFNgzBKo787rae9eJ0LK1Imx MlloqspN5Rqd3rKxuXQ1i4Px06h2xSKvmKlklIn2eCy8bb+tOH+4RwrXS5i0eMGoystzjT2n6Ifp NOF7WrKSckNcJ9l7XHu8p5UOP0qykzhNsBo1iW3YBK+JnjxO3R50vUKiiQ6i76mJxQP7hiDCYy69 OcRJT7FZLacgDzWffNQ8fVEpDNGQwXZ6KmGIuTsB9967zaJiFnuLf6K6DQ3YiZcl2RDbR05GoLrW rzUbNlfYB5PMpHS37+MG7FAl9evx2F0N8KlNgHbXHXT0LDqkv/uGlJVlQvlzUpNMV2W7i3jtmbFl o1y/4SUWMAw7hl4tk0mjPrYhDKB5nu5d3LxOrFnj4meetZesRXyH6pSvvC7eyxl0jTQDqUdMJzsK sywyvAWroSJDGvOF0uAanXOBACIIr03q0cvIy+cMdOYMt0FDm82A1YUTSHArly0e/b6uknKqgHp1 Ia72p3KGmC6Ul4cREuETZ93776fkZLa0QIYcSHce6GoGIzwVOG2aVbGSzPaTADc0u3W2Dh9DfkFb NlrXtmTNIJK5vn1vB+PQHgxieO53blKaxJMvSRY0SfMmtHKFFXOU6VPkOrWNdOY3XtmYIpx337aC hpWXb3fuVZCR4QVrEeXXZHq4Jx3jyTXavZMWLuIC4/49JOnoe9EV13fwOhlOb9zf6374WvYvKPMK 8/q+g/RoL5t5j7vAoTwj03nrbeLr7yz9tWGxrAxONJJ5YRuQdJo1NBbNQceVTftiNzbXEFNEJuKd lCViUG5Aftdh6+a2BPGWgO2zo8mlnR4PWsGoLZnamNGxjIwIDwpEfoLBWB3l9djbt1rNbzLZrpLZ JG5tqe3YhFMUL1tAFapRKtsbsnitakV3xhRVtvQNazlZzhQW+3gS188ffiD/TJ5iuvTeeKpWkUuR aZmqpzeUhnWiP0zMg3OZvA4tpPEqca+07l5ExPtLa+85OOYXRmnYEMrO1DzvdrIDFrypQxt110aY enTtTrqd83fFo2jTE3LWgIcNKaxorvHWO1SlGlfevHBMGYn6D/Oi5KpLl9jlK5JXYWZmzq7sDn5O UcM20qH/eE0LJBmMFbOf0uEuY8tuV3b1g7up1U02lzUSuZvlKtjf/YIGRi/u0W+6jTKTOW5CwGdX cJ7qQeBQVZb79aekzFN+7MCzfB2aMI0ROH/QvqWtwrouXUpIVODvGalO2za0aTP5N2Pmxd2Sdz0M aX/xmjhyYgqFVq93O97OdQyPbA1k+khJ+vWkvPO8ZGj4+3K9q+GSKoc5L11NzTDefYPvpFEYcZ56 Ss2GxhC8kDKQSldXt3/9jfPzmTMNXvSb7GEVcMtWc18aomoRJyLTMy9EA8xUHlYB9c4O5qadyJ11 eNxNbV1v1QErh8wsdeIcnoG+dMC4oxN5FTYSKUpypn7/ncaFsGVa2htvUqlyF/g4vO7CTC1nv/Uu L2gxY9Srp8FYwRQTuIKNMF21ivb5F8VBzV8dJPnL0C3/1g1/6ZqOYLFKw0dSjUocyBLTHM6kEt1A ijL2fS6JHDul33hDfnKaGuDJI5amaFKNmvrMH/hUx45R+1uDCb4YE2pqttmuvb33KK/g/XSc5pVH NJ9MKtagN19XdMW9lE8P9w15+dplrNq3M9ZttqHbjxygW9r5up3tJCkpNuZrB6ZbeNLq3psnXnl7 tmqpVZPQrmPgDmPSFKpe3Vu17jUMTN7rEamIVxRo0Nvp2TqjBI8G/uC6xGj37rl7zyJbUzwKgj+a 3lUR6l/DKrZ1D93RgQLe6QLJrJEET6/oy5bCn9WZ03WeCkEzsiV/1gN9bHurunE7QoKxcik1qA3m 8YhaGBllpD795Jx8CoZp6DDdS4XsxETue6UazvvvK6bunjhFXXuEL2PFccpEurdqram41rHD1O52 N44VaPntka5kUCjXeX4o9L/p5ZXMBjWrFi5YYUGuLF9BzZp41McqjidQWraM8oJ8KvhhplK/rldz 4FJMLIEFld2koTplFhXy8jS+FoovrnX+6r1ToiHtu2+pYnmez/KyNr9WT72704mLdkGB8mS3aEqS N9Ypptd+BzTet496piAajFnjPkQXIGMMb0LHKVUh/P6HEXjZ0ZNu9x6GJ6rdhESeGaxawxw9VnJs d+8+6tBVvoyVp0VvamUsXc5XuJ48wddMXcaKN1Cff9HND5IcpQ9HU4XSXgO4MUaZ0tKHn9sh0z54 iO69x6M+CHtPmVSqHH3/fc6ADx+j++6JsdIAlyaGvR2dchnUp692OterU2mONxEv/8VrQjWNpk1y y2We8UoH3iJ5YWVnGFMnUbFNK1dR3fIRb/Q9i/KKP5nJ+sgP0DXl/Dl6sjslgdy8WSF8Vbla9Ie5 su3Qug32DS0ZIs7jkmCQRq3a1sQpvEBqwwZq28HwZI+Pldu6ubF4sQqsTp+m9ncarBmQJ6awTT7a 2zl1hhfeTZtBUOy+YYMHUtOcPv2dM3lWcdB6bhAleEEnJdXiIk+KctddSsEliqn06svRFNYMPDsc 8NINBNPOdxceO+et3pH9gpX8F69Hg6JD42+74VJyWpAjNXL5tOiddwYPn9JyIvTW20hXeYISzfBY HS5gVSkre+lebM9matPIyyPY5HgNydU11bXrTAzT3LlK5coSz1UBq8RoYsBq1JBmzuWF3IiPzdpo l7HyjtmyiTH/Rwny5ew5uqOj4VGiG0hlQu7SUdu129B5hbkDZhZcePeEfQLdcqux+5AFDfDeR4wP f87JDhtk9aukFfNN2aQp05QK5SWP+uxklhxOhbLm88MiF3iFp+ZfOcgl+b926V6YzgclGv4y1anj lekS3AYNtM++hvAK7Txqdb1f5soYYnE28laeYhOpZr1a+jq+W39kzWKqUzbEts0gc+GlTm1r504O w5O/jqalRbggz42PJCVaza+jBb9wpXHBj1r96+SSWLW41pg7B9rYPZdDHTuZvjuLVLaH9jdL6zbw V8tX2dWra97FDrrHjXa9egqXCCjy2QQKpIbQgIQE1SfbjGx93NuhoOwsW+00bMS+kCQomeuWWsMm 9rSF5F2FEgW3G6bKnEXaX8FKJjdq0OlTtHpJ5PtJJ2d/e3zrllAuL4EunDqVqlfwVHeip52QuSPr LB3qe7+Zf5yCrjVkuFmqNFOZp7RZo95yS3FekKPwy0PdAPsLL65gzZZAHe+SDuUoUIBTplLDazxb RVIJkJO0Bg2cKdM48youUu7u6HFmwE0WamaaftXVxqwfee3c7sPStXW8a0MSKYnPFSuV4Yyewneg 27gjWq+SN9kEZZvCHIIg3qaZ/fMe54JNC2brw54JPniX/ODdNOhFa+e6c8GL3nIevgkI33nJdqy/ eI8LmWsVtm7zpRBSlCc1QA66SxeLzBeHWEkcyExPZ5p+ATYxS33tBTcSpKMXzft7RcCcAY9AQO+Q 6F3vixWFKRwzn33GCnglu8BlNna6dtVOF1gaqZ9/SbWqs7NzyGAdrtev50ye6mMl39MJrMg6KlGo aUlahcrK5Okc1E6ed1s3c/ycgoOFkNIS3WHDSZOMAyftdq3M5FSebPLHRSQqV5UqmjhLKXIIaemh I7RhM/22lXZdMNSQl+rZ3k3zLt+u6q/eV83kRaOQ33yBub820vAuIlm1gdrfrvgTE0kZoBfuXWoy lcuiadN4zeDCpXLDBkFWC+meywitVCl65jkjrNCxE3qPhzD0JtJGr/rHQeqRh+18me8m8cEHZoWy 7Czsa6y+jLp1XMgkH6vOnT2sEnmZYoKQ0zLDH/Na8eiFfGrf1uaIBjtnX+MSTc+H7Zwc82whPfqQ mZ7q62HbVz6ZIjx0CJ05z4Umf+rN4LsNFPjYcMf5Yjc7fiuJv5rjuHR5Dox+nw9zadRYqnZVoadz HJFWLJJ83NxGld21O6B61eHDpewUXk2Xku05mtCrVKa3PzAUhzaut9vdxmzvVWt9JM0+fcwIrzB0 X3/VSEvjSqlfp0Kva9d0JkxkrIJBXmbAMpvXZJqcCCSFX32TE4SiYuoCbZDi6ZBELpNyoew6/bf1 8oUovTosls3JlOXbf2KqiYN3ak+rV3o3wbBDfCME7wJU29X9p0uXjYqv0v9rSY4R8erKl2+dwVi5 lmPr7uAX5MysXL++FICQY+nFHe/UUjpVRMeL5Z4PmJwvB+zkLJ59RoJc6yr7q28UxCzk1B6jauC6 hABbJuLggAFazDvVC4PshESd56QC/pyIU7Oa/fnnfE1lKCzdew+winpQeEIroD47yFZVkiR68gkT eQFjleBNDAmrckZs/MRYvkrffCtXyfLWGCf5JWhEAapWWZ082dW5U7J/Abh3Txrt91t/8O0+St7a 8S/dw9D1b2hiXrYrF0rW/HiUUadmgWcwVqJwErxsq2yW9eqAwgKDlq03WzfxmCFBDSSzTEoVTtOG xvzlCP32+E+oQkWvDM7VG04E0pNoyBBNJiNmUL8nLc82bD4mz+G61SpYY8cawCoSk7qwXUVYaQQM r5bu9OqtF+STqhiDhxhZZT2sALWn6NKE/MIL+oUQrd8q1yxT6MViLkpzdEih1IQoeqF5t4u2+A4P tmbwymWXdL4siVdlu+T+dajcy/v6dzr5/QaGAG3zZqv3w9HMDCQvNqtNoaWnR5tdp/w8Pxgy6bOx VrUsbxDRL/QokdKE07a1s34ftK36+mArkYfYShW2J9rd0un01ptISbTCsNvrAT+yc/T09WHlsubH H6mKSzFZvq8rJSRLwndP1sBup3uiyH0sXX5zhFm2opfLgMNTeH42AyGjs7n3mHvyktqqnjcTl+iV BBM5YW94jTxrOsjXu28Pu5yrcfanG6bOK1ZtbwLC4x/L+UuagVWrd1kd5L63UoKtyua6hfvlFGrS QqtSwylX0ShX0bz2erPPQDpz1ghp9GJ/jTVqKqJY0NPzLrC6qx3tO29LTmTAIzI3OwXZkJXE8tsp m0nIO0xSLuQZXTpGvVBlAqsEL65VLGWMGikBK1lVH3iAktJ8rC6vx7v1tuKd29jmP/mMqlbn2Rwv C4bHWWnCbtPcWLkuGLHdR+6hUuVJpCsJAQ18FSiV+0jfKK82J38K3oU1yK5++f5qnkWYl8nH5ps7 /Vv3CrPzi2nZcnr/PXXokMKPPri4ZnkkxLoruO8Itb3H60iyVwlJlEUqsnjjye6FaNjyZXRzawKV JSZBJkH2Q9U72VXUL8eywe/YRze25TIUz5ol24xVkoOk4M1XvTu0xMxe3V2/lOFVFHmpbZNr6fsF bBqLFlmNGmneNZLeigWudUerVIt++KUOWbl9V/5b/6E0v8ZCflqxUuSJnscWLaaI5mMlMTt5LPP3 3AcyZpGByJUTo/Nhyg+Tol5mNrShSUtW+B6lO+lwwBSeAhjyrGSRPHFC7JpanoxPjPk8BqxKV1cm fs5YbdzutrqR0/Mkzw39hVWJSfprw/jmQlHZ7vmQV/a5HBGApF67lv71t7zu/JefzeZNDS9NUP1A A4WWkUz9nwtDTjukX8qjNVto5hKavdLdtI0Ko94teXgaGekMi86/6XaDfCWpK5kU1CloUcQ7I18k JvFNBqSyZaPeRWFaeoadmUQJ8LV0+mgkNpJffimEhIh7mu4vmYPLuJVqqd98zbfOW77auq45p5DJ nht6UR7AKsOGgADMmOJ07256WoLZjPVGQKlQTh41lm8ltGKN3rxJhMNBhhRItNISmCSTUuieTsVn zvgXIkUBeGEsGpJkXubLiV4x5IZ3OzbvXjRk/D1Y/X6HUf8+rL/fv/Zs0Hj++VB6qsQFnAAyC/CV hNytann6YSZPD/XqKXs1HEDEkwIp3mrMq+trM793MLJzFuiNGrFiZBy43OQLSPmlFwxgJavU6xHL yweRqtupHmtlpKovveboFNt1lDrcAXO1RbI3s5mEkWJi7NAhdPggXxZGdoy8K7u968hkr/hZcDlH tvg2UPq/x0v/7b3pLEv3b/hmeNMXJtJLhHX1vBIZ+YlWwV8nluTNvoE6UuyWjQuXLHNORNSbWmt+ pQWJxmWsEpyG1+mLFjkY2a+nKtfUZmnKej7B+n2NnD70eUN3LKSLjzxhJXpYJfHkKfQVMmX7iaec oB06mkf3dY54tVaXRyqZktL1tMTYwBeM84X+jfvU34nbm4XhV927tRjCKGNl/j12xTdmcRFkkfIg oCIfgE/yUyF57Va6v5tcprTklz3R68ws9+UXC3bttbceUetdzRIoASTmwehj1by1sWKlq9rWx2Pk mtVZDyR64srXDJBSPlaaQb2fsrxilJ2CJ7RKEl/W0amzffRS9KJEb74UaVA1mJnuT2RbpdPV++7L mbnILuZMRma0HZ7bVSjGjG5cvtsR34vJ8Y3rb7nvLhuUe/nGX7xiyjMxjW/uoKgmLV1DzwwMN653 pl61nNvb5g8Z6uzax3n3mk1O1XIsLxMCRgb/OXQ91SvotWlrrd/gyrY14l2peiU4r4eVd3mL12vj xecMJKQ4zSP9L9dq0tm0fE93W7SQl60MgoJOHqPJn1mP9M5vdX1++5uLBvU3166LFfPN+SweU+RQ NutFJA/eXZhYWHvPyxN9f9u9l1Xvaf3njdo4T+QlrKDQkCvtP0O/LKOff6GV62NnQixVdJ1+XCBn J/M1XymJRinWTkoaI+be2s7atJWxev2NWJUK/4nV76VR7YVnNeaTy1gx2h5WUX8O7po6odk/yBIb e0zW7INn7BUbaM0GOnGWLL7AwrBsE/97t2z2SJbXUYEA8RnSIwN+AXHl36f4/x/3tQ7B6nZsoSe6 FZcX4WQ/f0nja+iShTH4ablAUy9FtcF9rewEXndRPtVXmy6jkXLpySejefz3FS88PZiy02NcjOKp PXa0ZCHd/xD/cdX4H5T88x01/1kP8m44Ck22dBUN6G81q6elJ4eyyujVaoZ69tB/+QWj7Fy8RMMG KqUzwl7ZOfL7YhUzIenSoAF2Aa95k2YuV3v0CF9dERDh6dQsS926xKbO1eN/VMKfQ/8v/9bwPwYr BGU7qlMkTLRlL40Zoz7TJzyoPzJHc8cenluCB8eCNGuWeUeH3LTkEMcyb3ooM5vad5Smz/avHQ6B e35br786JHbfncF72xX9x4DIqpW2/Mc/hfCPx4pvYcDXjyPpA7vKCkFF5xbwXa28wK2RdyObIoPm /GT17eVmJEM2RMtl5fV4RJ6znM5JvFrYpWIgqjt2fojOXKRTOXzvDr4clYz/8kaa7j/z8XtxwzYN xdQ1Tw5CCuZ63eTrPb3LEiSHCiMW7d5CX02hz75wv56obdvJ2ZpJMf/+G95lQ+D4mMKXacre53wj 5su3Yf/TjSL/mXyle0/jd61vXS6I8dSbfvl2r14gcyli8mWgfBcJvjWw6W+s8mb8dw78SOb698Dl ahrx3TKv+Jt0/r00/6l2xSv8ZcNSXH+JkmNr3q2fLJvXmpqcrOmXNTXjEfLSt9hlk/Nqbg7f7i2i OibkPasi6GCdVR3faZb0K/4wTfwP9PwjsfJv6+N4N+DlypANz4K7aexQfAWKyffE9NDzfsFGgBCg 2dDbGutdvruxB/LvBe2od3dQ6AQuQbh//As48ZuR/j/viBAi0f9ba+L/AFYd0cd6iwAA --Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: text/html; name=header.htm Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=header.htm Content-Transfer-Encoding: quoted-printable

 

 

=CE=C4=B5=B5=C3=FB=B3=C6

=CE=C4=B5=B5=C3=DC=BC=B6

 

 

2003-02-27

=C4=DA=B2=BF=D7=CA=C1=CF=A3=AC=C7=EB=CE= =F0=C0=A9=C9=A2

=B5=DA1=D2=B3, =B9=B21=D2=B3

 

 

 

--Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: application/octet-stream; name=image001.wmz Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.wmz Content-Transfer-Encoding: base64 H4sIAAAAAAACC+29B7RUVbMtvPrkSM4gAhIliCCIooKKiAiKSlBMICIiIl7EHMAABkAMCJJEUaIk lSBJcs45pwOc3HHnWG/W3tj3iPd+w3e/5/h/x7hNn6ZP9w5rzVU1a1attfc5unvLZCHa1R6duKPu aXq1gcBj88cBkS5E4k93CREQH9zJnyXjJzNhdGK72vwuK+FBe3RiEt4lBtJEcoIQGt6KABGJf+dn +WejxeEJo8S6Gd3EvHnvi+EznhRvffeOePXbb8TTXy0RL4zZId4YsV2MenmF+GzwXPH149+IWQM/ FesHfMqNFOc2LxWRzZNE4alPxaEjP4iFx8eLBcc2io05+eK7AxfEgu2m2LrVEvs2F4vcozFRtFsS RTsvivDGY6JFixbiWRxjWKYQQxsJ0b49frkBPzffjJ9+QjR5C7/Mw88Y/LwgGorXxGPiPfF03T7i eWzYsWNHMQLffFVPiHEds0Xv3vjlAfx06yZEl8FC3PIhflmHn2/xM0LcLT4Rw5qMwzv+1wHb9xYT RBXxWykhfnlYiBdfxGb88/zzQjz1vhDdp+KXU2jnr6K9mCj6ie/F+BrzxUIxFUfsIl544QWxWtQV 57HV9iE4wwjvNP6btz4Xot9i/ELo1z5xn1iAr9aJpWKNOCZ+EWtr9cNmI8QJ0RxbCHHybSEmwy7E 1/iZ8Bn+nyXEa+tEmYdIdOqeA5w24Kznse8xjPxakVPrXfH5558LqWlbQYO7CeuLCuKnn7DvEvzM xoEWrwZs+0SZ10k8PSxPfFwhV6zAmbx/nbYJqjVWfPvtt4L6vS7oq0GCFjTBOGHfPWyOC4VYjzcz L4q6k0m8/nlYzGtDYndz7Hsffh49iP9niiVLlggaP17QvDeEtb+hOHwY++YJUeHsdsB2UYjfNNFm MYmx00isfEUTl/pg3+fw8+Ix/MwR69atE8Q/y4YKCtYVl863Z7hEn/ARIcJhIXZrYuB2EjN/wrnH kMh/D/sOx8+Yk4I+Wy0OHDggaOdOQevfhi0LkV88Qoyld8SnhEbgg6fPWmLyccJ5SJxGO/S52HcR fuYVClq4S5w6dUrQORxj7xRsPlgEg3PEalotFlJYDMP+7xWRWHiOxN69JHIPklBXYd+t+FlehPMe F7m5uYKkfEFnfsL+PwhF2SXO0G5xmBQxF/vPVUlsKiBx8iSJ2AUSURyHTjuCTkUEHcsVkUjE98Po Ify/T5jmRRGhoyIf5z+Gz09YJM5FSRQXk5AjJIx8bIv/Kd/AT8jblxnhhgSmAiFaiVS8Vko6TTvq Mm8wj9xZupbYhU9fEk97/soswt81xPunvc+Zcap4320aJf70cP/38b+P/338f/qAnxuG4b/xX/03 juOU/AS/2rbtv7e9B96Ypul/hYe/i7+9/3n8ffwgOJF/WOxuWVa8AfFHyWbgFdv7n2NjvGqaFm+b /1W8Vf4bVVX9g8cPgh1LduSK05V8YC+/2fEj4PUKrEqCUPK9/9B1Pd7g+Nnj2/h9jz9wLn9jHx+8 +n3E9jiO/z7e8fh7/7A+ziUb6X8b3+CKBw7ugxAfoJIPvz0lwfGPgyP7ffR7ER/ikr32P48f+c+m VXIbfwTju8f7Eh8jv6nxUbiikf6roiiIbNjGN4aSvcORASk28A8ex+cKJH27ihtJ/HSAveTox9/g 4DgXTKvkMa8YoP/OuvBJfFjjR4t/dQVQ8Y3xiMViEEDQYJs3b/Y76H8bH+6cnJzvv//+hx9+ABr+ wf19ZVn+7bff3njjjS5durRp0+aGG2647bbbhgwZsmDBgnA47DcYBzx69OjYsWOnTp167ty5/9Iw 8AmO88UXX0DHQcrEe4fzfvPNN5999tmaNWviXYvvfvDgwQkTJkycOPH48eMlRwffHjlyZMaMGePG jfv4448//f2BX3EovI4ZM+aTTz5Bl/2hOXz4MHo3bdo0nNp3kJJYXeF3x44de+yxx6pWrfruu+8G g8E4wnGuWL58OXC48cYb0eu47wBh9A4fpqSkVKhQ4ZZbbmnfvn3jxo0hS+rVq/fWW2+hpz5cK1eu bNq0aYMGDQBF3MF9iHzjKSwsRANKly790EMP7dmzJ77BvHnzmjVrVq1atccff/z06dMlRx8WBfyv vvrqRo0aTZkyJT40fpt//vnn22+/vVSpUuXKlcvKysos8UhPT0eDExMTBwwYEI1GsT1AQy+uu+66 1atX/9murnA3INDey4ReffVVmMoVI46NFy9eXMl7ANV4UwEgPsFe99xzDwZl7969O3fuXLRoUd++ fQEd2jNy5MhQKISNd+/eDSSx5XPPPXfp0qV4A3x2wptDhw7VrVuXM64XXigqKor3GqOflpaGz4Hz 2rVrSzYMJvrEE09w0pqcPGjQIN8afSSB//Tp0/22dejQoVOnTnfffTcyt7u8x5133onOwv4/+ugj IAwE5syZAzsBsPPnz4e/X4FV/DVu6p07d05KSvKx8r0vzhuwhF9++aVOnTo1a9Y8ceKEvwuQ6dmz JxqD7A8AlhwC4AOvxFewJYwvPgQ+MLPU1FQMH7wp3qm4GcyePRvY4hQwpPg4gt8Ago8GbANuUtL9 N23ahC4HAoGMjIw77rgD7YnTGh6gixo1atx6661oMNqPr3xm819xZEmSfKvA0TC+MM5rrrkGrfUV Qsk46JN2nMPPnDkD8HHeoUOH+gx8BfPjaLVr177qqqvAAz6VzZo1Cy6DscNXJanPf2zfvr1ly5bo I0ADdNhgw4YN2B5wjR8/vmRowyuQfNHLr5955pnz58/Hoy2MrWvXrvgcPohX2Fjc5vHt5MmTq1Sp ggPisGgYjDw+sjgsgC1Tpgx4Iz8/P+4dca4rqXbwWLhwIXwZHURf4sKmJFwlo9jJkyfhR2jPyy+/ 7Ltw/FufmpYuXQrYq1evji39XTgZF6Jhw4Zbt269Ynv/gN27d8cG4ASkjWg/xvHJJ58Eemg/rBfg vP7663jFGfv163fttdfCqkH+cTbDSefOnYvPYR4+kqAscAUsxNdU8PTKlSvDtX3zxhD47oOvsAGI HTviXHl5eSV7egVR+7376aefatWqhe0B2p+5vaRR4RXOfu+998IL3nvvvbjmLClXYJz169fH8MHd fCWDUf7vsMIrLB8sHccKx4Tx4yDwMnwIcoBBZmdng9YwmjAAfAgOh1vFBR4aAOoGGjD4H3/8EYSM DRAj/FaB04ADjAENHj16NHAG0QGWuA0giOD4cPm47Cn5Gg+Xvg8CIjQDRwNoV/jgn7GCD8LaERow WFu2bNm3b9/+/fsRkfEGPABfQMBFN2FaBw4c8B3nX9gVkEEQ97GCWwErH0B0ENSKD6EuRowYAWkB l+/fvz+4Ah8OHDgQ1hhXU+gCmBB2+Pbbb1+8eLFFixaAa9KkSf5X0DaAsW3btnB2dBAtx3t8GPdr +CAGAoS5ceNGBFY0G/Fl165deI9OYVBgHvEgAqzQNWAFWsaY/muszp49e//99+OM2B4kD3/Er3iD kIH3gBHxFM2GRwAE3/AgVP6FXWEz3weBFXoaF4fg6rJlyz777LNxX0BnEZIQyhFJCwoK4k2CuzVp 0gSxCSyNjQEsAuKwYcMw7mAtjBTMBs4LdkX3y3gPKLG4boT/YnDhKeB/aL/77rvP7xfcB+MFzscw AUDfRxDlgRV8EJb/F7FC13w+RCMBDpQSoGjevDksGRjiW3wCkeMf5F/4IN7AB3v06IFgAawuXLgQ Z1E/PAFzULHuPeBEiHHwbphxnFLAmRCZQBV+t27dOnyIEa9YsSIEQHFxMfZ6+OGH4cWwdnyFcIA4 goF+/vnnfSoDVnBbaDy0EH3B6fCKpkJ4+PEOxNutW7f/GVZxHwR/Qo9BySCyo5HQ0mu9xzvvvIPj QwIhDvomAZb411jBrnysIEjiVuSfCDvCtGAh6Lg/RtgY5B9P0yB7YDMJCQn4FgaGT8BFcCj0CISA 7qD76DU0pP9Vb6/MDcuBAvcbMHPmTDQYHAvQEILRSLyiR3iFA/76668gmf+ZD/rcDqxAI3+uP+AV ZgBYMPq+bscnIN5/gZXPV8AK3A67iidrIBOkBvgcBoNojsbjDewKPgXPglX4W8Jtb7rpJq9C/7yv ZnFkxDsMPaQCLBAOCM4HMugpjBCiF40HpwGEOLeXL18eB4nn1P8zbv/vNANO98orryDjuyLlxNEw gr7pAlV/l3/BV3gA0gceeACYwH7iWPkPjDh6AfJBv6C+oI5gJBjr+BlBQdD/0FTY/f333/fZHp9D Y6BHjz76KBjeb6rmPQAyjAc9Beb4yhfSOAuiLQbCV+YlM4X/K81QssbiCz8g4OsrkKeftsdh9HfB 0Wp4D6DqSyBYAvoCALdt2xZP83EiP92GrwErP6kBn5QsAfkw4itwDsYdIQMWWLLkBWeEjAfbA0Yo Xr93aBUEQ6tWrRD+br75ZvAq8PHbhoPjmOBVMPngwYN9wYk4iC2vv/56OJrf33i9CK8A3++dXziC JSAQwGtwzD/rqyscDZQCrMAPUIlo1RV1AOwOLQqywrDG7QpYYXvw544dO64oemADhAAggNEHVrAr v3l+MwDF8OHDgRViOgBBrz/88ENfBcVlPEwIkgnd94ndPyaoEhEN2MIsQVbr16+PnxHH7MYTcgLx Drk/PkFUBVbAFlESXgzrKvYeeI9XAAjP9b3bz0qAFUwL3I5D/evcGQqzXbt2vl3FYrE/F/qQVFb2 HqBWHz2fr2BXYMuSasEvXmGgfQ7v06cPgmzJuhDerFixAt7hT5RAF8GLS+penMKXYeBqiKK4ZEIv YDb+XogFvhiLmwqI0a9vQFD5fIUMCJYP023dujVCOWIlCA2vMDa8wXmhMXwDg8NiYwwBDOzPPljS bbExsEICgpCK1Due45Q0FXALwLz99tv9qAQ3RBIBoJC/QwHGK5nxIjA2g8hEy5HC+DWrkgeE5SCI wDZwRtByyTPiAcWFw+Lgo0aN8osS8RT766+/xl6IbojChYWFJVPpKVOmIFACFgwEtoTDwlMwuGW9 B3CAAZf2HqA1yDaAA3v2E0xAhN7BCFetWvXn3PmKMiNsCZEOOGMc49/GS5S+ky7yHuiXz7SIQdOn T4cygYCMW0X8DTaD9kD7Qdq+5oknTb6hIlB+9913OALexGWVTzXwWdAU9oX+uQJk2BIMBjvC9uIU F5eI+GrixIlwVZwCXDFv3jxQPXQaQidccurvj6+9BzbGoPiHBWOAqWBd6OafazJxrOK/wnfiNdt4 p+I1c79+7tuMn4P4JeWSddq4uf53dWk/fJecfSjZ2SsK4H4KGS93lCw4X1GQ90/qNz6ePscDTfxE JSvn/sbxb/1Zg5Kl7P9OM5SsgvrmdEVgvaLqe8WbK6JqyZmUeMPi4MfZEu/jkxp/LvKXPG8cipIF 1ZKV5Hgv4iPlnzHeDN8kSkrK+EnjbSspIa6wq3h74l/9mfD/PD/lj6k/ynGQSw5HvO/xUuGfp5ni X/ni5M/niltRXIpccYR4r0tuEJ86KWkJJY38z/Mp8Tm1+DxUycb8D+cTcWDbe/VOY5uGY5n80T/k 4fGg5T8d13QJg8vPv2nuFRDxk9zfn/bfdK6/q/2e4f/ecgy8yc+/5Vyud3weFP9cePIA/cOw+k+4 /L78Pee6bLS2Y1i2/rsZ/5N8MD5RDirxnpb79/iFTab3tPB0yIUr+gT2j7ErlxsdFy0e87r09zTf IlO3NcM2fZTAWwg+YPd/EFaXn390xr/jAVQ029LhgTbFZLuwSAmFoHb+MVgZOoduGxTllATL+Xvs yg+xJCnO6dMF+/adOXc2bP1zsCouCkfCkqpolvmHJOLfOaZikU6wIhuwgLgNipqkODY7ni4bOmlr V9CrT1tLVlKhQV5EDBmOZvlESYZDsmXH0BAEACYFz2OxOwS0R3L/13GnpJz+I396s7022YZvIcgc TM/FuPm6Q4qJ80NkRi1LAVccyTeWLVUOHJE0KsQ26KFiGzL250bR5TCFz0nVbdX5a84p2QYoCadl fMjgJ96hDYatUmTBYqtPt+jYcaH9ZzkZtkhVJIpGHVXH96Sblq/xdEPjA6BHvnr9PR8CXP9GrKc/ VnV0fsujcDmf8E6Nb3SfiPCNYpiqAeNhcWBY9PMC/cvPpJ2HHYy4C280AKXORoHv/EDFR9BNW7X/ Ki/ZGCmXVT/vyAcxcBDu+7Jtwbvbad3u0dcf0qJuCIZWHNZ2rHYvnXclXcOGFs6t8R6ao1sEBzX8 oOmD5XqR59/H6nKGgpMQ0483HDi25Ydp1adxbrx27qJ65CgVFsF6ZHTl4EF66SXl2Wf1dbtsNO9y 0xjzy7m/Jx0tTzf+JbTY9bw8ldjIYTiefZO2/Yx7TzutdmVp+k8UYpdXImp05Qpn9lf5OTmmQhFu sEbRIPwQp4TVmzoBMcAFTuVKBf4j53/Ib//FAj8wA+PDXo5XnMLDSg/zLx5WrnzkhLp2Le3c4SEj oyvGD4uoRf1Yzwf13afhMBFC0syYo2U2m6Jj+bncX9SNXpTQPO+DZYK9rKhBB45Rr2eV8oIe6Wmc UWWQAL7fusl+931j3VKpWNF1CmouBfPp4kVVMjXV0RlrG8YN0DzEXFdDb+z/Z3aFI1vgKpcHFrJY tUz+lbSciF1U4LCxkH2pkH5bR7PmFBTF2NR1KrwUcZ97yq6UqTz/Cp0uYg/QbJO/cn+HC0qIOcf5 a/FOYqBsfkF7wkQ//UaPPRwUQmvdxPx5hau4USL5yF778/fpo3FupBjjpciknL1Im9ZLx0+HsRdX ugwKRy3NdkzuFJs7sHL+DaxKlpK42OK7mW3BFDAwiuZThn46L3rksJJ7lm1OsWnHPmvsuNOz5lAB aARbOLHNO/V27Zzy5dT3P3SKiiwMJAgdtIV9AZfj57x/jVa9IbmsasM6/byWHuqlJouCjCTng4/0 cAz2YuSH6eNR8quDlc17eTOF5AsR96fF5tyZ0fP5QAZERTnn3AvnNXC+RwEcK2ISevZvYRVfFASP hnQBShrSLZOKi83cXBneDjPLDym7d6krf5VCMZxaO18QmfpN7MnH1VW7bQsO4UYUCk2dRxWrFNes nvvO++6ZU6Qa3GfNhTNaHlB/lVcx9B5fqeCo3Qep7xORUqmxhAS67XZz/UaMi+xQ7Jt5+j13yyPe L1I9b1Acdftec+TwwlkzWGFoTswoNndtDR0+GNU0xko2tJAUzS8K/5t25aPkF6kuXIoohgu3xnCc Ph0+ePBSJIYRIdOkHbvsSZMvnrsA54CbxTZto7va0eD++WdOAAU4SuxkmB4dZApRVL0y/TD9wIUL bFoG2xXrRfIE0h/rUaxGeAqKYJuu6UkDh+MIWTyHY287InXrRYEUJxAI1q/qLJ5VHC5gW/1pDTW7 PtqxR2zdIY2ZTTVUWX7pHRr1WSg/anqL6rT58+irqZQXDoPYoHRORtWtu+0TPBsTg3nnFLsniylm 2B4lUlQxw6amewpHV9xQDDSNTslgS5VHTdJJVW3KCQcLcxAnoCWd/OLgljVUoCiQULxq9wjN+N45 g7CC45N86Kz10Ufu7IVOgQwGMy5JxudfFmVn06vvWcEYKxrXMX7b5ra4MVcIq1KN6CeT1AjOJkms Comp4kqsOFKwDVt+TLf9EdRVpiltx/bI008UVa4E8KXq1eR3PqYzR9F6bf1upWcns2md0KgJWq6C XWBZytJ55tAXaeEKBzrPsKyiqP7F58a0mTrkDaxKJ2nt7uiK1UbeWQ8r1zh0Wj+SA8NlKWJrlHNR zYsYiJ5wseIi63yuFQNGrmbq2oVc8DX6ZqAvx85Gdv3mFhWacPKikLRprXrshBNVOQadOk3f/aD8 tpEK5RBRpCBK38+hQX2jK5dx++B5R07RLXeE291UOHsO2oMhjuTk0GtvUuksK710rFGdgq8+pUjU q52bKsAw1D9g5bgKYpPJNOZHFRwSsUBTydq+L9r/Eal0wBDCSU+n7g+Yu0+zyjypSs8N1ioL+9mH 6fBpNkL0/UTE6veAPepN8/hFjtmg1BVr5ZEfyWu3aJ56Ae27M2ZpCxc4EZW1v+qo67ZE9x4kz3hi 4ZC7c0fszHnHchzTsU6eNPYf1kG5CAhy1Ny0iYKFbMzhKB057Pw4UT9x3MBZohFj67bQr/PpdAFC iXIx35q/SJowmo6cV8iW4Ce7T1HXW4reGEBHLukx05Bk/dsFdtMqatfO7s6LsH02wdWr6Oa2BSJA QijX1aevJlCInTji6s4VaYLjyuBbrhpw0OVcAO9ggkcv0IAnlHKJrhAwKrNpc+27GeiVjOH4bKJb o5zbpCat/40YF9tRTP2LmXRjU+WXH/ViXbcgllV6+83YxG8pL+Qr0Oi5EH0ykubNobDNCTg8YsHi 4PZtOACQjZ0/R8uWROBEoADdsbZtNdZtBFEzaYSKafo058RRCHELUvj8GZr0gb5rrwVT0XT14LHg hHeBCeKPElH0zdvNV/s6v20nDmEmFVj00tBYl7b2zIUaAhyQL5Kp2x1u6UztrdEUkWGNoaJC98Nx xanplkgkEXAbNo5OnQMCkMAK7pU+CGBszUtnWHBTDLa9by8N6E/VysrYV6RRcnK0/8DghSJ0St66 y7n9OsoQ7rARtszJRJGt0KrV1Lat0627dOZ8WHFALOaJffTY/dridRgB0zFtydHmLjIH9pV/+pmK 7SgSre2HnW+/D+3aCpZkF9220539g7RvP2MlO+bSpdZPS9xLF5hdC4L07tvuhg26woxqhEP0+bva ivVqjIGMncmLvvkMrdoBf7DBc2Dy57pL46eCcDXXcmK2unqHe8+tysBntEtqzEu0jK+mOuXLGI2v oYWLDFbaDu06GuvymMKmFbBFVlGLZkWLF2C0TUO7AitW15JXvPOUp7pjtzH0hUtlkpXEDEkkUEoS demobTwQgxPt3UxPPmJWEJHb25ubec4ZRhg8cZp6PaBWSg+On27EHIykcbaQxo/Rnn/c3XSQ5SG8 O6eQBvQNPflI8bY9TF2KStN/oMlT5SOHYVcqhnzBAmPqNGX/YcYqapug6Jlzybt6wM6P0nMDaf6P SkiDPFNAWeNGat/MDV7kBQixvLD6yjPG9HngfI4mUZleHxJ94iltw55CbG1rKuzjhYHmbS2Vbxde MLw1KSeL7Ie6UapQ7up4cdl6SdXgLbGZv1qNaoFtLJGG19DdbWjBbFe1/jjnhUF1DYW4FsyU7piz 51vXNz6VmGAmZmAvrU0ze8FCHXy+5zANepKykoxaNXO+mkwyj1EoqtDIj6lsGbnDbdEjp0GXUPju 4mXO/Z2Lpk6k03mgPhUfrVhPbRrGXnnFPcdrMQw5aA8ZbE+eakJRY3TCQRr3aWTiFBncizELGsYX XzlTvqWz59A3LVd1HnuSJnxhMMMDK8P5YpwzalzBfh4svTjmDH9LewtueIg1qWYYPyxw2twovTwy UhRiIQOzQShsd7P1eE/rLH+CiO9OmUC1yioiIbdbH2nrLm7S0XPymy8plVJtIWyRaAaE2fueSG40 /AeswJhM6JwlI+sDCSz4mW5oSsmpAEquWEEa85UGpygstD8YblapdBFe2aV3aIfnLEQX9uylls2C SWXc0eO8xA905tgjR8kNGuZv3m6DD+AXl0KxceOjddKt8VOoyJsgKzorPdhJnzTVjfAknlZ4id54 PW/8JPn4Ba4TFBn66LHOl5PoxGnYuZRrWr0ep9HvOqeOcUknalmTJtIbI4q2bGFSimo05nO9Xz9n zXqOxboV25lDjerrLW7Ut2z3LN+kA/lmlwfM+mk0d1UE6TD6uXeL26M7qNhIrBT9+PNCjmbkQn60 axFjrNJIJFs9e0iFIbqipoos3ZuUBXGBlin3HM2Zsr9GNWpQOfrJqKILuSEY8y9LqEGDKNgvLdse +anqcM0hr5ho0EuUmZTX4T4Ky1rES003baa7bnJ6dSwqzoPgQ94d23aC7riN2t9Z/NtOA2BCUP26 1KnVmKbPj4BWoJDPak7ve+nryXpRDGagK6b13DD6+BP7/FkJVhEupO6Pm0OG0M79JghLlunX1cVP P07TF7NdGba5ZiH1vN3+YJpUbLLQA0917pKXUsH5cqxfRAgiWx/+rpaRbN37IIHbLTdkGNJXY6hU WhjI3NSClm5ifZcboiHPR8slIJYZLW/O/2FxJKI6V65VY6xcr47BbG0ZdOKANXY6fbfQ3HNMjUJN baSH7jay0gpxkA5dpHVbOQVHCPh+IbW8wax7deS9r3RF4lTibIH58vN689rKqBGOpLLN2o707Wz3 2vpWv+eN4+e5LnCuIPb+e5G6jbWFv3plEMfdkSN3usn4eorKKskxIKuees4Z8a5x+gRjhUyzVx+n 96PGxq0cruFC6zdFenV1x06GJkRct/ZvhzCIPjEovP8crINzqxHvWunllEd7qTkFnpYjWvwTNW2k VblKnTqJLvAFAfrmHdHefeXUBK18tvzwo9Ke7WrUoQ37YyM/Ut59j2Yssk7lWfCUP3I7V/D87Ach DNkQRkLXYBKGTlGVtK1H5V6PqglCy0jSGtUz584zEbgxUmvXUfuOGjRq9wfpeJ7jlbiC387TapVx bqxnr9+BiKvi2AVB/dknqXzpyIQ5nIaQo+48HLyrY+j61uG17CNcF1i0RbqhQXDyNyq7tWsWhewH H9Vfelk7chQSmqSQ83h/6tBBXrKMp0HAsAeOGF1utV9+w4oSBtcoDFK3u4uuaxabsdhzOleGHqvb WK1euXjuIr9aouZeoCEDwUXG9c3U+cv9SlP419+oyTWKEIUp6aE3BilHIYypMKrF5DB51VvlCt0O 2cmFKdObJ2ObUr0Ml3kbjJdz0n6mXzglWwXJVyirDR8TkoKs0s/maP0HRgJpWlKaOXasJ2JtO2ZH +j4HA9Z7d3PzDOg8ZtL124zWtalypchavqoPOlhZ9ptUtYbZ7aEok7NrwPwmLbCurRWa9oPkVZzc C/nOnZ21gc+ZBw7xIgcpbD41gA145izIQ0jl2MV86nwTPdrbORuRYMyySwOfiZZPpRdehX6RXDsW k+jhvtCW2tP9KS+C74tgjvNnUmomPiwa+Ip57AzbW/ASDXrMzS4dgVRoWEv9dKIR5hZEED49hGEU 1h+x4sQXNsQlVq5IgI815nuI/Ah9P5auylZEEolEt1nj4l0nwT9hRZXnzDcb1JPQmBva26s3YX8J R955wGncUk9LBdVAYBjslK71wVilkqAbWseOhj38LXvyN45Ipldflc5eYPULsQpZWLeG8u28CHkX NJ/NoRtu1h7v4+47zFUkJao9/axzTT366isYLxoQDat0f3u6qz1tPw6vRTzSPhotZQfo9rusi5cL udqnE93MZGpcjzYf4FQUn+zaYl3b3IKubt7KnvsLMLHNmLHgB7dhQ1WkAEPnto7a0t+8ErcdIZXT 5DDJV2hRj955ms8AQExZNpgb1PDb2linlnIyx1A1q5z2zhvkXcJYdOgY9XrMSBSII+rQN5Q8pH+O qZv07kgSqXk33BZZv42zeGTBB08ad9yjlhJ634GxHGg4V5KKaegQNMz65hs9xMHAPniKuj9GNau6 s5aEyDPoo8epbiO1e0/acwgfWJqsDhrklK1Ao0bZXOchEyKkx/12i2tpwQoQhiUZoTkLYtXK0tVX W6t3ehVSiv26Vm/ZhJKF+8EXVMBFGPfceWvwMAnDlBowXx5hFvOcRvGlPOOB+8AkBowhJTvy3EvG yUJfN/J0Q4T+sK7PsCXfB8GZms1FRYvnMGg5CPPBC0kiioOL5ILOnc3DR0A2Rp5kQFCVrgpFIbVu LC1bAg3Oafy2DdT4OlOkF70+Spa4LiDD6z8aL5cqb9esGv3qO6lY4pnXnbv0rnc46Vnmhg0uZzcW LV9nNGqqX12NFq9HQs2V870HqGI1qdO9BGWC4TNVBUEQQ//SyzGvPI52Ov2eNutUtT8Zp3DJWld2 7FNuvNHITKX3PnZDyAVJO33WGfBMMRNUW5q3LIJULGhYq9eq19QHS8g33kg//uwVlEkf/7VWvVqM fUeo9evLH39lnSoGC+mQobp1BV+xXXEdhmWpw4m9TmdORx9+tpAtKsEFVuXLamM+JZkHPe+3be51 1xkiwUmqmDf8NQRaHsRz5+m9V2Tknlc1pZ/WeGZsxorPU9eHEZTN61vFVu4wdJVTlHmLi1rVs2vW puMn2PVdzf12XmHpUqFaNenXnYg6umHZ23Y5mWXCd3SgrfuI54V0bdhQztSeebZQdw34E9zjxVec qmX1F/6D12ADGmjabg8bCcJ56KHg6XyeWsDpvhifA/SgCoa+cTQ3bAdJKSjQevaNls6W0oTTv49x /iSXWfaftbv1Kk5JDsNnk4TRulnk+9lmzFtFSH/McZDlelM9OkcGrjHQyXx66nkjNUlGggO0ExNi T/SMHDrCnY3F9F69CZo2IYla3RA6wqmuUmRI02Y5GeWddGE9PSB69LzhaITk85vFTr1GpkiyHmxH Egw7WgTLffldNF7v0kXnnJp0WTdeHs5c0aZNZMtu3ZtHcX5cRpVKWXd0ULft4SmakOoMH8p7PdzL zPMcBG0d87lWsxRd34rOFNrQ5oDvzRfVRGFUqumuOOJ4xW9p8RK6pqqRJPRWTfQlm3WJeUGbu5Ra XQf20K+u7L73NlJEWbJo/vdGlWu0TOEEhC7SpRtvpV9+dbgKYUMV+GtbQOuaZSK42BwNCdIyBu+b OM1t3DiYnGwwVkJpUFeZOFGBjoGAmPBpUZNrudmVytvDXpcu5mJcQvtP0DMDNPh7hnA+Gh8rknEo HQY/9FUrq4whkvRnHuWYAQUes9zHn6HEgPJEH6vAS99y86X+gxmr29vL2/dZnrozZsynspnmre3V LTsgZYyQ4o4YRrDkbvcbZ87hjDHY1fjJBsRJzWvMtVt0hCsM/9gP9exUPbOsOvFHXeMFxZG1m6l1 K3CRXq18ZMz4aJR1kbHvPHW8Q0kUeoKI3nt7bPdBGIh78hjHzVKBaKKX4GRlqG+/QReDOG7Q9UI8 +fmNN6/mTboW6hRZvka/s30kQcgs9QN2QFhDhjo5hTxbvGo9NW/ADJAgpNtamRu2QDSDZSPTZ1LN miH4yDXV7WWbFN1EQ7XDF9Rb22hAO7Oc/eEoXgwGVPceM25pS1lZ8jvvULFXUtu1N9SpG7rjdO1q 7D7I9caYpH31DRS11bqNsnYjWqaHZHrvNfCVc+dt2o49GAgFWH0/x2lYw80sExr3qRrmUpK6YL7d qL6bmCL3HySf5Wt/g/uPETRtKnKNZKtHT/ngSQ6IMVJeG2ZVruwIEatc1hw5gi5Jhmq48+YhFl9K TLAFu63UrDFNgDbmEAevi3H1j/NlCZCp7H/WxgPGQ92KS6dazOfCDgTgaOayjRpE5v690lNPQWXh aZarEBr2nBlmd9CO5kT6DUIglkWq1LO3cfwMSyY5pn83U69SiXOra5vQj78gAAdtisz8Ua5ekapU U6ZOI4nDkLX013CzlhgX59GHrUNHmLiLgvqHn1F6stu8ub5yNfMrsPrgLVekIaOXl61U/Fm8pSvo xmYIu4WP9dTOS+hLdP8hur8bJSSoNzSNrd7AxedLIX3ct052JjzOql/Lmv696k3kxVatopatdJGJ 5lktmsor13M6kH+J+jympaZjfFW2E2G0axddsYwiqq9mFc4p4HoaB8EDx+iZJ9zSAagmx8PWhiO8 84GSa4J7lAmj6apysE8Z8ahZ8+BPP+ou27kyY7barFUEAGaVjXw+Qy/20ocjx9TePdTMUpIIOHff TTuPcV8ilj78fTMlgeo1klf8yuupwQLTZ0hVamjY7Om+5skTwEq/mG++/q6TlkyNGti/LIGmUUIS ffiek5Jt162u43Q8YUXGpi080SCSQi2amnvPw8NjhVEa/DKbRIVUZeK3zDAK6cu22zVrRNEXnLdf 34Jivu4tjLzvoZ6yyJTAG8kJ+jtvGkV8hVbRnHlU62rEdyWhFPNMZrry0N3Suk28tAPIe2sVeGYW Azp9ql4tEVDrIsPyHFBu1bxw234NnLZuEz14DzdDsMR1H+rOsgQ7Flv03AtOejqCndXwmsi6/brD 1qL8ssaoe5WZkMpG2L+/diEMWtVPX6QnHgft0PWttf37Yi7SdXI/GaumpLsiyRkyyDx3Gk1Rzly0 nhtqJSXRNbVo/gIQqxyK0eiRZlZFqlrKHTdB8+aMtD0HrPu7IDjKFStayzayMeu28+F4mFAkRUBH UeF5zk+P5Jh3dyxMSLPYhJoVrV7BfqSR/uFIuyySEa8Q2vYG6adVsJy8I+eoa2cpVbiBNFaAIgDz zn1xaHjfMZ6VJn/BGYUhJ6Z9o1cpU8S1wXT4slm2sv7Ou0HdtPIv0pDBVLoiy4/kNKl8GfOTcSoC guHaCFgtWrESzkyxH3kgepIr2HpMdkd+SsmJPDRZmcFPxpoxmyvsy5bZrW/Q0bz2d9oFFyUEOMi5 V15jYkxKJ3BI7nmQQeTIKePxp5noqldx58zGYDJWYz82sytTKUFvvc8ZC9jjxGm7Zw/01Ahk6V9P JSOm4Xjf/eRkZWtQDje3M9dw0qcVh4wRb0llKsPy9coVzNdeoohkgaXXrCCIQx79gFM63RzwrF50 HspT+2xicd0aDhuMiCVBzCcazZuG5i8BISoI0DaPr6S7zqYD1LGXLJK52JWaqrS6ibYcYatbMDla t2aUmaq8nCb0Nq1o1RYuZp7Piz31dCwlQ0pLonoNol9PpDAn9OFN66Kdu2B8FfS3ZdsYsldopGiR O/bj/MrlCkHR99xHOtjKMSOqMuA59EJLzaLhb9qFOWhQ8d6jSo9HmcGqlHdnfg+sYsDq09F6dkUb 0X/wK0Uxr36bk0uPPsbBUaQpI4ZT+KJs6dKSbVS1BiUk2WUr5I/9OBRzYw5E9c907XWqSJUzUuim lsU7d8VUnuGlAU9YaWWCIgG5s123mjpvLLCNHsyVOt9LKUl6chK3QSQ61SrSN7PwlbfW2o+CDvIa Z+su581Xok89pLzYhzYtAf6h9bvc66+llGTKTAsFRCSzLH0/ScqNhgsjNOZjqlwL4yKlBvKfeICK CiXbAanTi4PhUwYYLxAI9hug5IZCIMMLOdQOqgY6JKBgA5eVnLxhB7W5lURWuHy2OuoD63y+AZfb eci842YS2VJ2mjPxU6ami2Hpyy+ockVKz4p27qHlePrfNcxXX+UJpqQMrWMH2nOEFenuPfIDD8B3 TJFidnpA3nWMF28oMav/k6ZnQm5Sgt2zr3H0Ej4vXjGLalaQuayXGElLiN55W3DfUa52Tp8QbHC1 zraRTCki+uxjZ3bt5zI7mqLqEMYsXyH4IXlO5hF2OXaepAhdCtKg5/JLpcFCrIREJTM51uZ2OriN 7WTbHuO+e3SRjHGRr6oa+mgEqRJUiLJrr9Kti+FhYmekhEeNdiWTpwd3bKPraisi0UpI19947XJk WbzMadycRFq0QpYx5mM7t5irk5t2GzdfTyIjCr/+4iPGKk9Sxo+nqlUoJTV6e+fo4VzyaiL2O++Y PPTCaNnUXreF+3LyjNl/oJuYDLGnXds8OG8x13pN1Rr1LlWuYkNXJySbdetFcV6M1MkDzqO93UBp C7lJYsCqXlb7cGQ4LOmnz9KQl7Ra1xbUb57frTuSOCrmTMFwYExkOzx/6qoUUUiSyZApalCuTuac H6l2lWiATZHDbrUqwU8mkBLmqaNJU6QqZUN8/9Uk89a20sqVXlpDxsSvCxrUQlNBYnqNMrHZC3kh GKj9m+laNWyfTBWqumNHX178NmGSXPUqGKFcMcv54gu7kGegndWbjKZ1HZEcSk1wRo/gZc/Fujlh ItVg54rdcEtw434ibzrzw4/MpESYllG1vDxzgQl3DYbNDz6hjOwYeKxUOend4d7CENNavJBuvMGj a9YDsTffdEwDubE64weqWDnKc1VcC7XbtynYvY0TqL3HrUnfudNmujuPMxa6t6zLZf+TefGSt5bY ML1rSFyeCTp8TOvZS/EGzvHK9XRbu+DRC4AkeOKM2q9PDBTKMizJ6vukcaEAu9n5GqJeXlqC5WHr 3HytuXYruEE+lUP/8VIkMzWC+NKoCc34jryJNnrznWhmaVMk6FWyaNp0N2ywcPplhVm7CjoVS06g ka/D2hEa7EmT7auupoSA1rRlZPFKD2nX+WK8XipbY3YNxD7+wozKyNa0GbOoUoUItznZfvhBJz9m QPkjF+ve1WYRCKkpzI53qru3w7Si+/bTzc3BSxBv0IeEBPOTt53iIE6qRSLkXWZayKswkAo7Fi/W Q3oFgje9lV2WN+8JERGlzz+hKlUvIUzwM4HKl6fX39FjBuRc9Ifv1Cb1vBp+MqWnxcZ+xAm74lqr t8VualPMc6/4PJH6PkCHTmiQTFt2Ued7IWZi+PzmW/TlHLgtyJSn+ylJqZwd1MimOQtsiUWmO2+R WxV+kagmB2j4MBORR3bdb76xa11jJglq1FT7bpY35evY075Xa1RT/fnigS85Oeyb+uo1Zt0aMW98 oTPNDTsMdBMwvjzISk/gggzGsUrl6JfjgIBaHHZfesYtC7Ga4kC3wIM6tIT2U716l0Kawikhad4a V55eB5+C30EpNp4IHBQuiBjLlhe2bsILSEQW2M9MDFDz64rWbsUe6oUoDexrp4IqYdLCaVQ/uGwp i+FinT74KFq1osqliQS3TLL1/ptOTgGnwz8uQqDUvIhjde4a3nWAJ7nPFtD99+pcCUkwry7j/ryK F04iL/3me7dMGrjFgep4awiv8FBd57vvrdr1taQEqlPfGvcZ8So5x/jxZ+3ahmBgGIZ19wPO7n18 2EOH9BubeXI64FSrbH/6mR3THajHCZ8aNSt645voIhns11c7VwgDkRfOoaZ1NU9NsQdVyI68Pdzy Zh5VntbQ6PL6Pp639VfBuo5vTyRjizXbqF//PAQO5DgiA31Xs5LNZwfkRbyFvlPnUotGbMnoY7Kw +jwhnYRsVmnvSbrvTi0Vu7Dwc2qVk2fMkYpUE9nTmE/d1DTAwvMjjz8VvFDInUKEvamFxmow0ahd 3lq1hWfMQCOff2VlQgkkIcWmNwYbpuHItjVrtnPNtQo+qVpNf/tNx7vM11q+1mTBlhrGQeo21pYu 0UFiwULz/o4mS8REq1QWPXKfe7oAZhFbsYRubqVyTY+pyWnV1J49X0O7T52hHt0kduRE8CEaozZv pU6YSrlhZlQ3xhmNf3EFIAJQihPzVxxhEPOK6MORVCkdAU5PhMUi/kKTX03z5wHYSGFB7LFnImVS dS66JqilAs4noy0Z5hqhBcu1+uUUbkwGxJjboq6+dq+MFL74Eg17yZNn6WiJOfilmDcnaP64LNa4 jrcGIFGpXUHn6TDk4ipByacJ26u8ua8PMiDHJduYM8+t20SBj5QuG3txsB4O82Cv2Wbf2tYQ6RF4 VlZp6btpPKNgakbfxyiNU2MtKeBeX8vcdVwyKXxoP/XsTgnppsjIBzKlEs0XBoaKY0zWr78tlytl ZoG1kn15aT7wgLbjiK5Tke0V7bwViVxSlsm/vo2NCkny7J+pxW1QF1aWIPamgAWufqmPFjakAlLe /tBOKU8iuRBkghY2alK8Ym0xUD91mO7pStWzyVO8YBvrnk5F5/lK7qI1W53bWlqlM4ipVagfjnKh gYMGDXiFalY3vUK3dW2jot1bWfPnBun51ygzEIQDwor696U8PayQ8fN8Bzm4F8icO+5yL7JdRbbu Mro8rPtpfmai9vTzlMvrVmj8aKlSnVhyEhepypSxR31GxQa+iL43nBexiFQrUdgJIlSrNn00niQq WrU6dDsIJ0VLDLjJATNNULVs650PLO8a9T/MO3OdjGflkGaFLuZbb7yhlikdgvMGEqMiBRmT0rql tWiOA9feeszo2DESyEIboBZs9OWJPubR07Kq06L5VvWrpewEPYnjr5tR2u33dCS/mJOvGfOca2up oGXE8cwsG0oJUSYv4t77MJXP9sqJwm7RLHpwN0/Hn82lp1+kNBFMSKAE4T7Vhy7JSPTNJYvchlw3 s4HVzbc6xy6wQtt7yHrwMc7pYG+pQrn3PnXrPtu11NkztGsam0wgQk9Jl3s9phw7xZEd8Tc9g7UB GhMQalqW0vupolzFzblEz/ZWeJQTrAAS6iQlRdA9d8ubtllXrIG0vOXyXJlBunmJ/uNZNzNBSkhF VghGQjhTX+hv5RVYkJTjPqfKZSyfS+E7VapFZ8zkZb0nz9KA56BSwgnCTOA00K5Z0x09TpEMV5Ho 1bft0lkxzySQxdPc2VyIOHTcvLa5lIY8CNgK++Yb9ZOHeSrt4AmrV19KC2B7Fwg88aibEwFxOL8u YbEB9MA2DZuoazYxxUKK9HmWzThRuClCb36d8t1s2aHIxm1G69auFwqRfgbr1sldMJvV32bkINcx CSMN8cZIqtfwzJJfucw645vCyhWwS4w9Oo2zmzpV9EnjNTXyxxqyyUvmXDcCKy2I0pdfUqN60Cec piUJp3Vt+mUWi+cd29T7O3ABk+0tiZJTqev90ZOn2XPn/2zVbRr2cna/DdZNLe3la3S4+bG91KmL G0jQgAlMpVULd/UqngxdulSpXEVNZTthbNu3Nc/zLTDVLbuMTt0oPaD7GPbuaZ8pjCBXXbXcbdKc knhjvULVyKRpiqlSQYyGvWb79RY0tVJ5/a3hMZNiOSHq2skzwiRgFc5Iir4+kAqK1HPF+oCnIxx9 AqonwCB4Coc+z+nJuYvh7j0wRioXo7jIYNSsGpk6xYhG/zBHT8blKyPA85LL+fLAoXn1a58sXTba onHsnRe1C+d5adnnH6k1ShvcsEQoJSpTwRnzqWla0In2myNMJLCMlVefDwj9oXvV0xeRtlqzJpt1 rvGkbAph9DvdZSAJUg3ny8+07Ew3PUABzw473m7mXuQy7ap1dOMtTppXKkF3enazjp0PQ9X8ttJq 3MJirAJaerby5utyqJCijvPRKIeXWCTgpHZCgvnYozwZKpE78ClvWFNgzBKo787rae9eJ0LK1Imx MlloqspN5Rqd3rKxuXQ1i4Px06h2xSKvmKlklIn2eCy8bb+tOH+4RwrXS5i0eMGoystzjT2n6Ifp NOF7WrKSckNcJ9l7XHu8p5UOP0qykzhNsBo1iW3YBK+JnjxO3R50vUKiiQ6i76mJxQP7hiDCYy69 OcRJT7FZLacgDzWffNQ8fVEpDNGQwXZ6KmGIuTsB9967zaJiFnuLf6K6DQ3YiZcl2RDbR05GoLrW rzUbNlfYB5PMpHS37+MG7FAl9evx2F0N8KlNgHbXHXT0LDqkv/uGlJVlQvlzUpNMV2W7i3jtmbFl o1y/4SUWMAw7hl4tk0mjPrYhDKB5nu5d3LxOrFnj4meetZesRXyH6pSvvC7eyxl0jTQDqUdMJzsK sywyvAWroSJDGvOF0uAanXOBACIIr03q0cvIy+cMdOYMt0FDm82A1YUTSHArly0e/b6uknKqgHp1 Ia72p3KGmC6Ul4cREuETZ93776fkZLa0QIYcSHce6GoGIzwVOG2aVbGSzPaTADc0u3W2Dh9DfkFb NlrXtmTNIJK5vn1vB+PQHgxieO53blKaxJMvSRY0SfMmtHKFFXOU6VPkOrWNdOY3XtmYIpx337aC hpWXb3fuVZCR4QVrEeXXZHq4Jx3jyTXavZMWLuIC4/49JOnoe9EV13fwOhlOb9zf6374WvYvKPMK 8/q+g/RoL5t5j7vAoTwj03nrbeLr7yz9tWGxrAxONJJ5YRuQdJo1NBbNQceVTftiNzbXEFNEJuKd lCViUG5Aftdh6+a2BPGWgO2zo8mlnR4PWsGoLZnamNGxjIwIDwpEfoLBWB3l9djbt1rNbzLZrpLZ JG5tqe3YhFMUL1tAFapRKtsbsnitakV3xhRVtvQNazlZzhQW+3gS188ffiD/TJ5iuvTeeKpWkUuR aZmqpzeUhnWiP0zMg3OZvA4tpPEqca+07l5ExPtLa+85OOYXRmnYEMrO1DzvdrIDFrypQxt110aY enTtTrqd83fFo2jTE3LWgIcNKaxorvHWO1SlGlfevHBMGYn6D/Oi5KpLl9jlK5JXYWZmzq7sDn5O UcM20qH/eE0LJBmMFbOf0uEuY8tuV3b1g7up1U02lzUSuZvlKtjf/YIGRi/u0W+6jTKTOW5CwGdX cJ7qQeBQVZb79aekzFN+7MCzfB2aMI0ROH/QvqWtwrouXUpIVODvGalO2za0aTP5N2Pmxd2Sdz0M aX/xmjhyYgqFVq93O97OdQyPbA1k+khJ+vWkvPO8ZGj4+3K9q+GSKoc5L11NzTDefYPvpFEYcZ56 Ss2GxhC8kDKQSldXt3/9jfPzmTMNXvSb7GEVcMtWc18aomoRJyLTMy9EA8xUHlYB9c4O5qadyJ11 eNxNbV1v1QErh8wsdeIcnoG+dMC4oxN5FTYSKUpypn7/ncaFsGVa2htvUqlyF/g4vO7CTC1nv/Uu L2gxY9Srp8FYwRQTuIKNMF21ivb5F8VBzV8dJPnL0C3/1g1/6ZqOYLFKw0dSjUocyBLTHM6kEt1A ijL2fS6JHDul33hDfnKaGuDJI5amaFKNmvrMH/hUx45R+1uDCb4YE2pqttmuvb33KK/g/XSc5pVH NJ9MKtagN19XdMW9lE8P9w15+dplrNq3M9ZttqHbjxygW9r5up3tJCkpNuZrB6ZbeNLq3psnXnl7 tmqpVZPQrmPgDmPSFKpe3Vu17jUMTN7rEamIVxRo0Nvp2TqjBI8G/uC6xGj37rl7zyJbUzwKgj+a 3lUR6l/DKrZ1D93RgQLe6QLJrJEET6/oy5bCn9WZ03WeCkEzsiV/1gN9bHurunE7QoKxcik1qA3m 8YhaGBllpD795Jx8CoZp6DDdS4XsxETue6UazvvvK6bunjhFXXuEL2PFccpEurdqram41rHD1O52 N44VaPntka5kUCjXeX4o9L/p5ZXMBjWrFi5YYUGuLF9BzZp41McqjidQWraM8oJ8KvhhplK/rldz 4FJMLIEFld2koTplFhXy8jS+FoovrnX+6r1ToiHtu2+pYnmez/KyNr9WT72704mLdkGB8mS3aEqS N9Ypptd+BzTet496piAajFnjPkQXIGMMb0LHKVUh/P6HEXjZ0ZNu9x6GJ6rdhESeGaxawxw9VnJs d+8+6tBVvoyVp0VvamUsXc5XuJ48wddMXcaKN1Cff9HND5IcpQ9HU4XSXgO4MUaZ0tKHn9sh0z54 iO69x6M+CHtPmVSqHH3/fc6ADx+j++6JsdIAlyaGvR2dchnUp692OterU2mONxEv/8VrQjWNpk1y y2We8UoH3iJ5YWVnGFMnUbFNK1dR3fIRb/Q9i/KKP5nJ+sgP0DXl/Dl6sjslgdy8WSF8Vbla9Ie5 su3Qug32DS0ZIs7jkmCQRq3a1sQpvEBqwwZq28HwZI+Pldu6ubF4sQqsTp+m9ncarBmQJ6awTT7a 2zl1hhfeTZtBUOy+YYMHUtOcPv2dM3lWcdB6bhAleEEnJdXiIk+KctddSsEliqn06svRFNYMPDsc 8NINBNPOdxceO+et3pH9gpX8F69Hg6JD42+74VJyWpAjNXL5tOiddwYPn9JyIvTW20hXeYISzfBY HS5gVSkre+lebM9matPIyyPY5HgNydU11bXrTAzT3LlK5coSz1UBq8RoYsBq1JBmzuWF3IiPzdpo l7HyjtmyiTH/Rwny5ew5uqOj4VGiG0hlQu7SUdu129B5hbkDZhZcePeEfQLdcqux+5AFDfDeR4wP f87JDhtk9aukFfNN2aQp05QK5SWP+uxklhxOhbLm88MiF3iFp+ZfOcgl+b926V6YzgclGv4y1anj lekS3AYNtM++hvAK7Txqdb1f5soYYnE28laeYhOpZr1a+jq+W39kzWKqUzbEts0gc+GlTm1r504O w5O/jqalRbggz42PJCVaza+jBb9wpXHBj1r96+SSWLW41pg7B9rYPZdDHTuZvjuLVLaH9jdL6zbw V8tX2dWra97FDrrHjXa9egqXCCjy2QQKpIbQgIQE1SfbjGx93NuhoOwsW+00bMS+kCQomeuWWsMm 9rSF5F2FEgW3G6bKnEXaX8FKJjdq0OlTtHpJ5PtJJ2d/e3zrllAuL4EunDqVqlfwVHeip52QuSPr LB3qe7+Zf5yCrjVkuFmqNFOZp7RZo95yS3FekKPwy0PdAPsLL65gzZZAHe+SDuUoUIBTplLDazxb RVIJkJO0Bg2cKdM48youUu7u6HFmwE0WamaaftXVxqwfee3c7sPStXW8a0MSKYnPFSuV4Yyewneg 27gjWq+SN9kEZZvCHIIg3qaZ/fMe54JNC2brw54JPniX/ODdNOhFa+e6c8GL3nIevgkI33nJdqy/ eI8LmWsVtm7zpRBSlCc1QA66SxeLzBeHWEkcyExPZ5p+ATYxS33tBTcSpKMXzft7RcCcAY9AQO+Q 6F3vixWFKRwzn33GCnglu8BlNna6dtVOF1gaqZ9/SbWqs7NzyGAdrtev50ye6mMl39MJrMg6KlGo aUlahcrK5Okc1E6ed1s3c/ycgoOFkNIS3WHDSZOMAyftdq3M5FSebPLHRSQqV5UqmjhLKXIIaemh I7RhM/22lXZdMNSQl+rZ3k3zLt+u6q/eV83kRaOQ33yBub820vAuIlm1gdrfrvgTE0kZoBfuXWoy lcuiadN4zeDCpXLDBkFWC+meywitVCl65jkjrNCxE3qPhzD0JtJGr/rHQeqRh+18me8m8cEHZoWy 7Czsa6y+jLp1XMgkH6vOnT2sEnmZYoKQ0zLDH/Na8eiFfGrf1uaIBjtnX+MSTc+H7Zwc82whPfqQ mZ7q62HbVz6ZIjx0CJ05z4Umf+rN4LsNFPjYcMf5Yjc7fiuJv5rjuHR5Dox+nw9zadRYqnZVoadz HJFWLJJ83NxGld21O6B61eHDpewUXk2Xku05mtCrVKa3PzAUhzaut9vdxmzvVWt9JM0+fcwIrzB0 X3/VSEvjSqlfp0Kva9d0JkxkrIJBXmbAMpvXZJqcCCSFX32TE4SiYuoCbZDi6ZBELpNyoew6/bf1 8oUovTosls3JlOXbf2KqiYN3ak+rV3o3wbBDfCME7wJU29X9p0uXjYqv0v9rSY4R8erKl2+dwVi5 lmPr7uAX5MysXL++FICQY+nFHe/UUjpVRMeL5Z4PmJwvB+zkLJ59RoJc6yr7q28UxCzk1B6jauC6 hABbJuLggAFazDvVC4PshESd56QC/pyIU7Oa/fnnfE1lKCzdew+winpQeEIroD47yFZVkiR68gkT eQFjleBNDAmrckZs/MRYvkrffCtXyfLWGCf5JWhEAapWWZ082dW5U7J/Abh3Txrt91t/8O0+St7a 8S/dw9D1b2hiXrYrF0rW/HiUUadmgWcwVqJwErxsq2yW9eqAwgKDlq03WzfxmCFBDSSzTEoVTtOG xvzlCP32+E+oQkWvDM7VG04E0pNoyBBNJiNmUL8nLc82bD4mz+G61SpYY8cawCoSk7qwXUVYaQQM r5bu9OqtF+STqhiDhxhZZT2sALWn6NKE/MIL+oUQrd8q1yxT6MViLkpzdEih1IQoeqF5t4u2+A4P tmbwymWXdL4siVdlu+T+dajcy/v6dzr5/QaGAG3zZqv3w9HMDCQvNqtNoaWnR5tdp/w8Pxgy6bOx VrUsbxDRL/QokdKE07a1s34ftK36+mArkYfYShW2J9rd0un01ptISbTCsNvrAT+yc/T09WHlsubH H6mKSzFZvq8rJSRLwndP1sBup3uiyH0sXX5zhFm2opfLgMNTeH42AyGjs7n3mHvyktqqnjcTl+iV BBM5YW94jTxrOsjXu28Pu5yrcfanG6bOK1ZtbwLC4x/L+UuagVWrd1kd5L63UoKtyua6hfvlFGrS QqtSwylX0ShX0bz2erPPQDpz1ghp9GJ/jTVqKqJY0NPzLrC6qx3tO29LTmTAIzI3OwXZkJXE8tsp m0nIO0xSLuQZXTpGvVBlAqsEL65VLGWMGikBK1lVH3iAktJ8rC6vx7v1tuKd29jmP/mMqlbn2Rwv C4bHWWnCbtPcWLkuGLHdR+6hUuVJpCsJAQ18FSiV+0jfKK82J38K3oU1yK5++f5qnkWYl8nH5ps7 /Vv3CrPzi2nZcnr/PXXokMKPPri4ZnkkxLoruO8Itb3H60iyVwlJlEUqsnjjye6FaNjyZXRzawKV JSZBJkH2Q9U72VXUL8eywe/YRze25TIUz5ol24xVkoOk4M1XvTu0xMxe3V2/lOFVFHmpbZNr6fsF bBqLFlmNGmneNZLeigWudUerVIt++KUOWbl9V/5b/6E0v8ZCflqxUuSJnscWLaaI5mMlMTt5LPP3 3AcyZpGByJUTo/Nhyg+Tol5mNrShSUtW+B6lO+lwwBSeAhjyrGSRPHFC7JpanoxPjPk8BqxKV1cm fs5YbdzutrqR0/Mkzw39hVWJSfprw/jmQlHZ7vmQV/a5HBGApF67lv71t7zu/JefzeZNDS9NUP1A A4WWkUz9nwtDTjukX8qjNVto5hKavdLdtI0Ko94teXgaGekMi86/6XaDfCWpK5kU1CloUcQ7I18k JvFNBqSyZaPeRWFaeoadmUQJ8LV0+mgkNpJffimEhIh7mu4vmYPLuJVqqd98zbfOW77auq45p5DJ nht6UR7AKsOGgADMmOJ07256WoLZjPVGQKlQTh41lm8ltGKN3rxJhMNBhhRItNISmCSTUuieTsVn zvgXIkUBeGEsGpJkXubLiV4x5IZ3OzbvXjRk/D1Y/X6HUf8+rL/fv/Zs0Hj++VB6qsQFnAAyC/CV hNytann6YSZPD/XqKXs1HEDEkwIp3mrMq+trM793MLJzFuiNGrFiZBy43OQLSPmlFwxgJavU6xHL yweRqtupHmtlpKovveboFNt1lDrcAXO1RbI3s5mEkWJi7NAhdPggXxZGdoy8K7u968hkr/hZcDlH tvg2UPq/x0v/7b3pLEv3b/hmeNMXJtJLhHX1vBIZ+YlWwV8nluTNvoE6UuyWjQuXLHNORNSbWmt+ pQWJxmWsEpyG1+mLFjkY2a+nKtfUZmnKej7B+n2NnD70eUN3LKSLjzxhJXpYJfHkKfQVMmX7iaec oB06mkf3dY54tVaXRyqZktL1tMTYwBeM84X+jfvU34nbm4XhV927tRjCKGNl/j12xTdmcRFkkfIg oCIfgE/yUyF57Va6v5tcprTklz3R68ws9+UXC3bttbceUetdzRIoASTmwehj1by1sWKlq9rWx2Pk mtVZDyR64srXDJBSPlaaQb2fsrxilJ2CJ7RKEl/W0amzffRS9KJEb74UaVA1mJnuT2RbpdPV++7L mbnILuZMRma0HZ7bVSjGjG5cvtsR34vJ8Y3rb7nvLhuUe/nGX7xiyjMxjW/uoKgmLV1DzwwMN653 pl61nNvb5g8Z6uzax3n3mk1O1XIsLxMCRgb/OXQ91SvotWlrrd/gyrY14l2peiU4r4eVd3mL12vj xecMJKQ4zSP9L9dq0tm0fE93W7SQl60MgoJOHqPJn1mP9M5vdX1++5uLBvU3166LFfPN+SweU+RQ NutFJA/eXZhYWHvPyxN9f9u9l1Xvaf3njdo4T+QlrKDQkCvtP0O/LKOff6GV62NnQixVdJ1+XCBn J/M1XymJRinWTkoaI+be2s7atJWxev2NWJUK/4nV76VR7YVnNeaTy1gx2h5WUX8O7po6odk/yBIb e0zW7INn7BUbaM0GOnGWLL7AwrBsE/97t2z2SJbXUYEA8RnSIwN+AXHl36f4/x/3tQ7B6nZsoSe6 FZcX4WQ/f0nja+iShTH4ablAUy9FtcF9rewEXndRPtVXmy6jkXLpySejefz3FS88PZiy02NcjOKp PXa0ZCHd/xD/cdX4H5T88x01/1kP8m44Ck22dBUN6G81q6elJ4eyyujVaoZ69tB/+QWj7Fy8RMMG KqUzwl7ZOfL7YhUzIenSoAF2Aa95k2YuV3v0CF9dERDh6dQsS926xKbO1eN/VMKfQ/8v/9bwPwYr BGU7qlMkTLRlL40Zoz7TJzyoPzJHc8cenluCB8eCNGuWeUeH3LTkEMcyb3ooM5vad5Smz/avHQ6B e35br786JHbfncF72xX9x4DIqpW2/Mc/hfCPx4pvYcDXjyPpA7vKCkFF5xbwXa28wK2RdyObIoPm /GT17eVmJEM2RMtl5fV4RJ6znM5JvFrYpWIgqjt2fojOXKRTOXzvDr4clYz/8kaa7j/z8XtxwzYN xdQ1Tw5CCuZ63eTrPb3LEiSHCiMW7d5CX02hz75wv56obdvJ2ZpJMf/+G95lQ+D4mMKXacre53wj 5su3Yf/TjSL/mXyle0/jd61vXS6I8dSbfvl2r14gcyli8mWgfBcJvjWw6W+s8mb8dw78SOb698Dl ahrx3TKv+Jt0/r00/6l2xSv8ZcNSXH+JkmNr3q2fLJvXmpqcrOmXNTXjEfLSt9hlk/Nqbg7f7i2i OibkPasi6GCdVR3faZb0K/4wTfwP9PwjsfJv6+N4N+DlypANz4K7aexQfAWKyffE9NDzfsFGgBCg 2dDbGutdvruxB/LvBe2od3dQ6AQuQbh//As48ZuR/j/viBAi0f9ba+L/AFYd0cd6iwAA --Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: text/html; name=header.htm Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=header.htm Content-Transfer-Encoding: quoted-printable

 

 

文档名称

文档密级

 

 

2003-02-27

内部= 资料，请勿扩散

第<= /font>1页, 共1页

 

 

 

--Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: application/octet-stream; name=image001.wmz Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.wmz Content-Transfer-Encoding: base64 H4sIAAAAAAACC+29B7RUVbMtvPrkSM4gAhIliCCIooKKiAiKSlBMICIiIl7EHMAABkAMCJJEUaIk lSBJcs45pwOc3HHnWG/W3tj3iPd+w3e/5/h/x7hNn6ZP9w5rzVU1a1attfc5unvLZCHa1R6duKPu aXq1gcBj88cBkS5E4k93CREQH9zJnyXjJzNhdGK72vwuK+FBe3RiEt4lBtJEcoIQGt6KABGJf+dn +WejxeEJo8S6Gd3EvHnvi+EznhRvffeOePXbb8TTXy0RL4zZId4YsV2MenmF+GzwXPH149+IWQM/ FesHfMqNFOc2LxWRzZNE4alPxaEjP4iFx8eLBcc2io05+eK7AxfEgu2m2LrVEvs2F4vcozFRtFsS RTsvivDGY6JFixbiWRxjWKYQQxsJ0b49frkBPzffjJ9+QjR5C7/Mw88Y/LwgGorXxGPiPfF03T7i eWzYsWNHMQLffFVPiHEds0Xv3vjlAfx06yZEl8FC3PIhflmHn2/xM0LcLT4Rw5qMwzv+1wHb9xYT RBXxWykhfnlYiBdfxGb88/zzQjz1vhDdp+KXU2jnr6K9mCj6ie/F+BrzxUIxFUfsIl544QWxWtQV 57HV9iE4wwjvNP6btz4Xot9i/ELo1z5xn1iAr9aJpWKNOCZ+EWtr9cNmI8QJ0RxbCHHybSEmwy7E 1/iZ8Bn+nyXEa+tEmYdIdOqeA5w24Kznse8xjPxakVPrXfH5558LqWlbQYO7CeuLCuKnn7DvEvzM xoEWrwZs+0SZ10k8PSxPfFwhV6zAmbx/nbYJqjVWfPvtt4L6vS7oq0GCFjTBOGHfPWyOC4VYjzcz L4q6k0m8/nlYzGtDYndz7Hsffh49iP9niiVLlggaP17QvDeEtb+hOHwY++YJUeHsdsB2UYjfNNFm MYmx00isfEUTl/pg3+fw8+Ix/MwR69atE8Q/y4YKCtYVl863Z7hEn/ARIcJhIXZrYuB2EjN/wrnH kMh/D/sOx8+Yk4I+Wy0OHDggaOdOQevfhi0LkV88Qoyld8SnhEbgg6fPWmLyccJ5SJxGO/S52HcR fuYVClq4S5w6dUrQORxj7xRsPlgEg3PEalotFlJYDMP+7xWRWHiOxN69JHIPklBXYd+t+FlehPMe F7m5uYKkfEFnfsL+PwhF2SXO0G5xmBQxF/vPVUlsKiBx8iSJ2AUSURyHTjuCTkUEHcsVkUjE98Po Ify/T5jmRRGhoyIf5z+Gz09YJM5FSRQXk5AjJIx8bIv/Kd/AT8jblxnhhgSmAiFaiVS8Vko6TTvq Mm8wj9xZupbYhU9fEk97/soswt81xPunvc+Zcap4320aJf70cP/38b+P/338f/qAnxuG4b/xX/03 juOU/AS/2rbtv7e9B96Ypul/hYe/i7+9/3n8ffwgOJF/WOxuWVa8AfFHyWbgFdv7n2NjvGqaFm+b /1W8Vf4bVVX9g8cPgh1LduSK05V8YC+/2fEj4PUKrEqCUPK9/9B1Pd7g+Nnj2/h9jz9wLn9jHx+8 +n3E9jiO/z7e8fh7/7A+ziUb6X8b3+CKBw7ugxAfoJIPvz0lwfGPgyP7ffR7ER/ikr32P48f+c+m VXIbfwTju8f7Eh8jv6nxUbiikf6roiiIbNjGN4aSvcORASk28A8ex+cKJH27ihtJ/HSAveTox9/g 4DgXTKvkMa8YoP/OuvBJfFjjR4t/dQVQ8Y3xiMViEEDQYJs3b/Y76H8bH+6cnJzvv//+hx9+ABr+ wf19ZVn+7bff3njjjS5durRp0+aGG2647bbbhgwZsmDBgnA47DcYBzx69OjYsWOnTp167ty5/9Iw 8AmO88UXX0DHQcrEe4fzfvPNN5999tmaNWviXYvvfvDgwQkTJkycOPH48eMlRwffHjlyZMaMGePG jfv4448//f2BX3EovI4ZM+aTTz5Bl/2hOXz4MHo3bdo0nNp3kJJYXeF3x44de+yxx6pWrfruu+8G g8E4wnGuWL58OXC48cYb0eu47wBh9A4fpqSkVKhQ4ZZbbmnfvn3jxo0hS+rVq/fWW2+hpz5cK1eu bNq0aYMGDQBF3MF9iHzjKSwsRANKly790EMP7dmzJ77BvHnzmjVrVq1atccff/z06dMlRx8WBfyv vvrqRo0aTZkyJT40fpt//vnn22+/vVSpUuXKlcvKysos8UhPT0eDExMTBwwYEI1GsT1AQy+uu+66 1atX/9murnA3INDey4ReffVVmMoVI46NFy9eXMl7ANV4UwEgPsFe99xzDwZl7969O3fuXLRoUd++ fQEd2jNy5MhQKISNd+/eDSSx5XPPPXfp0qV4A3x2wptDhw7VrVuXM64XXigqKor3GqOflpaGz4Hz 2rVrSzYMJvrEE09w0pqcPGjQIN8afSSB//Tp0/22dejQoVOnTnfffTcyt7u8x5133onOwv4/+ugj IAwE5syZAzsBsPPnz4e/X4FV/DVu6p07d05KSvKx8r0vzhuwhF9++aVOnTo1a9Y8ceKEvwuQ6dmz JxqD7A8AlhwC4AOvxFewJYwvPgQ+MLPU1FQMH7wp3qm4GcyePRvY4hQwpPg4gt8Ago8GbANuUtL9 N23ahC4HAoGMjIw77rgD7YnTGh6gixo1atx6661oMNqPr3xm819xZEmSfKvA0TC+MM5rrrkGrfUV Qsk46JN2nMPPnDkD8HHeoUOH+gx8BfPjaLVr177qqqvAAz6VzZo1Cy6DscNXJanPf2zfvr1ly5bo I0ADdNhgw4YN2B5wjR8/vmRowyuQfNHLr5955pnz58/Hoy2MrWvXrvgcPohX2Fjc5vHt5MmTq1Sp ggPisGgYjDw+sjgsgC1Tpgx4Iz8/P+4dca4rqXbwWLhwIXwZHURf4sKmJFwlo9jJkyfhR2jPyy+/ 7Ltw/FufmpYuXQrYq1evji39XTgZF6Jhw4Zbt269Ynv/gN27d8cG4ASkjWg/xvHJJ58Eemg/rBfg vP7663jFGfv163fttdfCqkH+cTbDSefOnYvPYR4+kqAscAUsxNdU8PTKlSvDtX3zxhD47oOvsAGI HTviXHl5eSV7egVR+7376aefatWqhe0B2p+5vaRR4RXOfu+998IL3nvvvbjmLClXYJz169fH8MHd fCWDUf7vsMIrLB8sHccKx4Tx4yDwMnwIcoBBZmdng9YwmjAAfAgOh1vFBR4aAOoGGjD4H3/8EYSM DRAj/FaB04ADjAENHj16NHAG0QGWuA0giOD4cPm47Cn5Gg+Xvg8CIjQDRwNoV/jgn7GCD8LaERow WFu2bNm3b9/+/fsRkfEGPABfQMBFN2FaBw4c8B3nX9gVkEEQ97GCWwErH0B0ENSKD6EuRowYAWkB l+/fvz+4Ah8OHDgQ1hhXU+gCmBB2+Pbbb1+8eLFFixaAa9KkSf5X0DaAsW3btnB2dBAtx3t8GPdr +CAGAoS5ceNGBFY0G/Fl165deI9OYVBgHvEgAqzQNWAFWsaY/muszp49e//99+OM2B4kD3/Er3iD kIH3gBHxFM2GRwAE3/AgVP6FXWEz3weBFXoaF4fg6rJlyz777LNxX0BnEZIQyhFJCwoK4k2CuzVp 0gSxCSyNjQEsAuKwYcMw7mAtjBTMBs4LdkX3y3gPKLG4boT/YnDhKeB/aL/77rvP7xfcB+MFzscw AUDfRxDlgRV8EJb/F7FC13w+RCMBDpQSoGjevDksGRjiW3wCkeMf5F/4IN7AB3v06IFgAawuXLgQ Z1E/PAFzULHuPeBEiHHwbphxnFLAmRCZQBV+t27dOnyIEa9YsSIEQHFxMfZ6+OGH4cWwdnyFcIA4 goF+/vnnfSoDVnBbaDy0EH3B6fCKpkJ4+PEOxNutW7f/GVZxHwR/Qo9BySCyo5HQ0mu9xzvvvIPj QwIhDvomAZb411jBrnysIEjiVuSfCDvCtGAh6Lg/RtgY5B9P0yB7YDMJCQn4FgaGT8BFcCj0CISA 7qD76DU0pP9Vb6/MDcuBAvcbMHPmTDQYHAvQEILRSLyiR3iFA/76668gmf+ZD/rcDqxAI3+uP+AV ZgBYMPq+bscnIN5/gZXPV8AK3A67iidrIBOkBvgcBoNojsbjDewKPgXPglX4W8Jtb7rpJq9C/7yv ZnFkxDsMPaQCLBAOCM4HMugpjBCiF40HpwGEOLeXL18eB4nn1P8zbv/vNANO98orryDjuyLlxNEw gr7pAlV/l3/BV3gA0gceeACYwH7iWPkPjDh6AfJBv6C+oI5gJBjr+BlBQdD/0FTY/f333/fZHp9D Y6BHjz76KBjeb6rmPQAyjAc9Beb4yhfSOAuiLQbCV+YlM4X/K81QssbiCz8g4OsrkKeftsdh9HfB 0Wp4D6DqSyBYAvoCALdt2xZP83EiP92GrwErP6kBn5QsAfkw4itwDsYdIQMWWLLkBWeEjAfbA0Yo Xr93aBUEQ6tWrRD+br75ZvAq8PHbhoPjmOBVMPngwYN9wYk4iC2vv/56OJrf33i9CK8A3++dXziC JSAQwGtwzD/rqyscDZQCrMAPUIlo1RV1AOwOLQqywrDG7QpYYXvw544dO64oemADhAAggNEHVrAr v3l+MwDF8OHDgRViOgBBrz/88ENfBcVlPEwIkgnd94ndPyaoEhEN2MIsQVbr16+PnxHH7MYTcgLx Drk/PkFUBVbAFlESXgzrKvYeeI9XAAjP9b3bz0qAFUwL3I5D/evcGQqzXbt2vl3FYrE/F/qQVFb2 HqBWHz2fr2BXYMuSasEvXmGgfQ7v06cPgmzJuhDerFixAt7hT5RAF8GLS+penMKXYeBqiKK4ZEIv YDb+XogFvhiLmwqI0a9vQFD5fIUMCJYP023dujVCOWIlCA2vMDa8wXmhMXwDg8NiYwwBDOzPPljS bbExsEICgpCK1Due45Q0FXALwLz99tv9qAQ3RBIBoJC/QwHGK5nxIjA2g8hEy5HC+DWrkgeE5SCI wDZwRtByyTPiAcWFw+Lgo0aN8osS8RT766+/xl6IbojChYWFJVPpKVOmIFACFgwEtoTDwlMwuGW9 B3CAAZf2HqA1yDaAA3v2E0xAhN7BCFetWvXn3PmKMiNsCZEOOGMc49/GS5S+ky7yHuiXz7SIQdOn T4cygYCMW0X8DTaD9kD7Qdq+5oknTb6hIlB+9913OALexGWVTzXwWdAU9oX+uQJk2BIMBjvC9uIU F5eI+GrixIlwVZwCXDFv3jxQPXQaQidccurvj6+9BzbGoPiHBWOAqWBd6OafazJxrOK/wnfiNdt4 p+I1c79+7tuMn4P4JeWSddq4uf53dWk/fJecfSjZ2SsK4H4KGS93lCw4X1GQ90/qNz6ePscDTfxE JSvn/sbxb/1Zg5Kl7P9OM5SsgvrmdEVgvaLqe8WbK6JqyZmUeMPi4MfZEu/jkxp/LvKXPG8cipIF 1ZKV5Hgv4iPlnzHeDN8kSkrK+EnjbSspIa6wq3h74l/9mfD/PD/lj6k/ynGQSw5HvO/xUuGfp5ni X/ni5M/niltRXIpccYR4r0tuEJ86KWkJJY38z/Mp8Tm1+DxUycb8D+cTcWDbe/VOY5uGY5n80T/k 4fGg5T8d13QJg8vPv2nuFRDxk9zfn/bfdK6/q/2e4f/ecgy8yc+/5Vyud3weFP9cePIA/cOw+k+4 /L78Pee6bLS2Y1i2/rsZ/5N8MD5RDirxnpb79/iFTab3tPB0yIUr+gT2j7ErlxsdFy0e87r09zTf IlO3NcM2fZTAWwg+YPd/EFaXn390xr/jAVQ029LhgTbFZLuwSAmFoHb+MVgZOoduGxTllATL+Xvs yg+xJCnO6dMF+/adOXc2bP1zsCouCkfCkqpolvmHJOLfOaZikU6wIhuwgLgNipqkODY7ni4bOmlr V9CrT1tLVlKhQV5EDBmOZvlESYZDsmXH0BAEACYFz2OxOwS0R3L/13GnpJz+I396s7022YZvIcgc TM/FuPm6Q4qJ80NkRi1LAVccyTeWLVUOHJE0KsQ26KFiGzL250bR5TCFz0nVbdX5a84p2QYoCadl fMjgJ96hDYatUmTBYqtPt+jYcaH9ZzkZtkhVJIpGHVXH96Sblq/xdEPjA6BHvnr9PR8CXP9GrKc/ VnV0fsujcDmf8E6Nb3SfiPCNYpiqAeNhcWBY9PMC/cvPpJ2HHYy4C280AKXORoHv/EDFR9BNW7X/ Ki/ZGCmXVT/vyAcxcBDu+7Jtwbvbad3u0dcf0qJuCIZWHNZ2rHYvnXclXcOGFs6t8R6ao1sEBzX8 oOmD5XqR59/H6nKGgpMQ0483HDi25Ydp1adxbrx27qJ65CgVFsF6ZHTl4EF66SXl2Wf1dbtsNO9y 0xjzy7m/Jx0tTzf+JbTY9bw8ldjIYTiefZO2/Yx7TzutdmVp+k8UYpdXImp05Qpn9lf5OTmmQhFu sEbRIPwQp4TVmzoBMcAFTuVKBf4j53/Ib//FAj8wA+PDXo5XnMLDSg/zLx5WrnzkhLp2Le3c4SEj oyvGD4uoRf1Yzwf13afhMBFC0syYo2U2m6Jj+bncX9SNXpTQPO+DZYK9rKhBB45Rr2eV8oIe6Wmc UWWQAL7fusl+931j3VKpWNF1CmouBfPp4kVVMjXV0RlrG8YN0DzEXFdDb+z/Z3aFI1vgKpcHFrJY tUz+lbSciF1U4LCxkH2pkH5bR7PmFBTF2NR1KrwUcZ97yq6UqTz/Cp0uYg/QbJO/cn+HC0qIOcf5 a/FOYqBsfkF7wkQ//UaPPRwUQmvdxPx5hau4USL5yF778/fpo3FupBjjpciknL1Im9ZLx0+HsRdX ugwKRy3NdkzuFJs7sHL+DaxKlpK42OK7mW3BFDAwiuZThn46L3rksJJ7lm1OsWnHPmvsuNOz5lAB aARbOLHNO/V27Zzy5dT3P3SKiiwMJAgdtIV9AZfj57x/jVa9IbmsasM6/byWHuqlJouCjCTng4/0 cAz2YuSH6eNR8quDlc17eTOF5AsR96fF5tyZ0fP5QAZERTnn3AvnNXC+RwEcK2ISevZvYRVfFASP hnQBShrSLZOKi83cXBneDjPLDym7d6krf5VCMZxaO18QmfpN7MnH1VW7bQsO4UYUCk2dRxWrFNes nvvO++6ZU6Qa3GfNhTNaHlB/lVcx9B5fqeCo3Qep7xORUqmxhAS67XZz/UaMi+xQ7Jt5+j13yyPe L1I9b1Acdftec+TwwlkzWGFoTswoNndtDR0+GNU0xko2tJAUzS8K/5t25aPkF6kuXIoohgu3xnCc Ph0+ePBSJIYRIdOkHbvsSZMvnrsA54CbxTZto7va0eD++WdOAAU4SuxkmB4dZApRVL0y/TD9wIUL bFoG2xXrRfIE0h/rUaxGeAqKYJuu6UkDh+MIWTyHY287InXrRYEUJxAI1q/qLJ5VHC5gW/1pDTW7 PtqxR2zdIY2ZTTVUWX7pHRr1WSg/anqL6rT58+irqZQXDoPYoHRORtWtu+0TPBsTg3nnFLsniylm 2B4lUlQxw6amewpHV9xQDDSNTslgS5VHTdJJVW3KCQcLcxAnoCWd/OLgljVUoCiQULxq9wjN+N45 g7CC45N86Kz10Ufu7IVOgQwGMy5JxudfFmVn06vvWcEYKxrXMX7b5ra4MVcIq1KN6CeT1AjOJkms Comp4kqsOFKwDVt+TLf9EdRVpiltx/bI008UVa4E8KXq1eR3PqYzR9F6bf1upWcns2md0KgJWq6C XWBZytJ55tAXaeEKBzrPsKyiqP7F58a0mTrkDaxKJ2nt7uiK1UbeWQ8r1zh0Wj+SA8NlKWJrlHNR zYsYiJ5wseIi63yuFQNGrmbq2oVc8DX6ZqAvx85Gdv3mFhWacPKikLRprXrshBNVOQadOk3f/aD8 tpEK5RBRpCBK38+hQX2jK5dx++B5R07RLXeE291UOHsO2oMhjuTk0GtvUuksK710rFGdgq8+pUjU q52bKsAw1D9g5bgKYpPJNOZHFRwSsUBTydq+L9r/Eal0wBDCSU+n7g+Yu0+zyjypSs8N1ioL+9mH 6fBpNkL0/UTE6veAPepN8/hFjtmg1BVr5ZEfyWu3aJ56Ae27M2ZpCxc4EZW1v+qo67ZE9x4kz3hi 4ZC7c0fszHnHchzTsU6eNPYf1kG5CAhy1Ny0iYKFbMzhKB057Pw4UT9x3MBZohFj67bQr/PpdAFC iXIx35q/SJowmo6cV8iW4Ce7T1HXW4reGEBHLukx05Bk/dsFdtMqatfO7s6LsH02wdWr6Oa2BSJA QijX1aevJlCInTji6s4VaYLjyuBbrhpw0OVcAO9ggkcv0IAnlHKJrhAwKrNpc+27GeiVjOH4bKJb o5zbpCat/40YF9tRTP2LmXRjU+WXH/ViXbcgllV6+83YxG8pL+Qr0Oi5EH0ykubNobDNCTg8YsHi 4PZtOACQjZ0/R8uWROBEoADdsbZtNdZtBFEzaYSKafo058RRCHELUvj8GZr0gb5rrwVT0XT14LHg hHeBCeKPElH0zdvNV/s6v20nDmEmFVj00tBYl7b2zIUaAhyQL5Kp2x1u6UztrdEUkWGNoaJC98Nx xanplkgkEXAbNo5OnQMCkMAK7pU+CGBszUtnWHBTDLa9by8N6E/VysrYV6RRcnK0/8DghSJ0St66 y7n9OsoQ7rARtszJRJGt0KrV1Lat0627dOZ8WHFALOaJffTY/dridRgB0zFtydHmLjIH9pV/+pmK 7SgSre2HnW+/D+3aCpZkF9220539g7RvP2MlO+bSpdZPS9xLF5hdC4L07tvuhg26woxqhEP0+bva ivVqjIGMncmLvvkMrdoBf7DBc2Dy57pL46eCcDXXcmK2unqHe8+tysBntEtqzEu0jK+mOuXLGI2v oYWLDFbaDu06GuvymMKmFbBFVlGLZkWLF2C0TUO7AitW15JXvPOUp7pjtzH0hUtlkpXEDEkkUEoS demobTwQgxPt3UxPPmJWEJHb25ubec4ZRhg8cZp6PaBWSg+On27EHIykcbaQxo/Rnn/c3XSQ5SG8 O6eQBvQNPflI8bY9TF2KStN/oMlT5SOHYVcqhnzBAmPqNGX/YcYqapug6Jlzybt6wM6P0nMDaf6P SkiDPFNAWeNGat/MDV7kBQixvLD6yjPG9HngfI4mUZleHxJ94iltw55CbG1rKuzjhYHmbS2Vbxde MLw1KSeL7Ie6UapQ7up4cdl6SdXgLbGZv1qNaoFtLJGG19DdbWjBbFe1/jjnhUF1DYW4FsyU7piz 51vXNz6VmGAmZmAvrU0ze8FCHXy+5zANepKykoxaNXO+mkwyj1EoqtDIj6lsGbnDbdEjp0GXUPju 4mXO/Z2Lpk6k03mgPhUfrVhPbRrGXnnFPcdrMQw5aA8ZbE+eakJRY3TCQRr3aWTiFBncizELGsYX XzlTvqWz59A3LVd1HnuSJnxhMMMDK8P5YpwzalzBfh4svTjmDH9LewtueIg1qWYYPyxw2twovTwy UhRiIQOzQShsd7P1eE/rLH+CiO9OmUC1yioiIbdbH2nrLm7S0XPymy8plVJtIWyRaAaE2fueSG40 /AeswJhM6JwlI+sDCSz4mW5oSsmpAEquWEEa85UGpygstD8YblapdBFe2aV3aIfnLEQX9uylls2C SWXc0eO8xA905tgjR8kNGuZv3m6DD+AXl0KxceOjddKt8VOoyJsgKzorPdhJnzTVjfAknlZ4id54 PW/8JPn4Ba4TFBn66LHOl5PoxGnYuZRrWr0ep9HvOqeOcUknalmTJtIbI4q2bGFSimo05nO9Xz9n zXqOxboV25lDjerrLW7Ut2z3LN+kA/lmlwfM+mk0d1UE6TD6uXeL26M7qNhIrBT9+PNCjmbkQn60 axFjrNJIJFs9e0iFIbqipoos3ZuUBXGBlin3HM2Zsr9GNWpQOfrJqKILuSEY8y9LqEGDKNgvLdse +anqcM0hr5ho0EuUmZTX4T4Ky1rES003baa7bnJ6dSwqzoPgQ94d23aC7riN2t9Z/NtOA2BCUP26 1KnVmKbPj4BWoJDPak7ve+nryXpRDGagK6b13DD6+BP7/FkJVhEupO6Pm0OG0M79JghLlunX1cVP P07TF7NdGba5ZiH1vN3+YJpUbLLQA0917pKXUsH5cqxfRAgiWx/+rpaRbN37IIHbLTdkGNJXY6hU WhjI3NSClm5ifZcboiHPR8slIJYZLW/O/2FxJKI6V65VY6xcr47BbG0ZdOKANXY6fbfQ3HNMjUJN baSH7jay0gpxkA5dpHVbOQVHCPh+IbW8wax7deS9r3RF4lTibIH58vN689rKqBGOpLLN2o707Wz3 2vpWv+eN4+e5LnCuIPb+e5G6jbWFv3plEMfdkSN3usn4eorKKskxIKuees4Z8a5x+gRjhUyzVx+n 96PGxq0cruFC6zdFenV1x06GJkRct/ZvhzCIPjEovP8crINzqxHvWunllEd7qTkFnpYjWvwTNW2k VblKnTqJLvAFAfrmHdHefeXUBK18tvzwo9Ke7WrUoQ37YyM/Ut59j2Yssk7lWfCUP3I7V/D87Ach DNkQRkLXYBKGTlGVtK1H5V6PqglCy0jSGtUz584zEbgxUmvXUfuOGjRq9wfpeJ7jlbiC387TapVx bqxnr9+BiKvi2AVB/dknqXzpyIQ5nIaQo+48HLyrY+j61uG17CNcF1i0RbqhQXDyNyq7tWsWhewH H9Vfelk7chQSmqSQ83h/6tBBXrKMp0HAsAeOGF1utV9+w4oSBtcoDFK3u4uuaxabsdhzOleGHqvb WK1euXjuIr9aouZeoCEDwUXG9c3U+cv9SlP419+oyTWKEIUp6aE3BilHIYypMKrF5DB51VvlCt0O 2cmFKdObJ2ObUr0Ml3kbjJdz0n6mXzglWwXJVyirDR8TkoKs0s/maP0HRgJpWlKaOXasJ2JtO2ZH +j4HA9Z7d3PzDOg8ZtL124zWtalypchavqoPOlhZ9ptUtYbZ7aEok7NrwPwmLbCurRWa9oPkVZzc C/nOnZ21gc+ZBw7xIgcpbD41gA145izIQ0jl2MV86nwTPdrbORuRYMyySwOfiZZPpRdehX6RXDsW k+jhvtCW2tP9KS+C74tgjvNnUmomPiwa+Ip57AzbW/ASDXrMzS4dgVRoWEv9dKIR5hZEED49hGEU 1h+x4sQXNsQlVq5IgI815nuI/Ah9P5auylZEEolEt1nj4l0nwT9hRZXnzDcb1JPQmBva26s3YX8J R955wGncUk9LBdVAYBjslK71wVilkqAbWseOhj38LXvyN45Ipldflc5eYPULsQpZWLeG8u28CHkX NJ/NoRtu1h7v4+47zFUkJao9/axzTT366isYLxoQDat0f3u6qz1tPw6vRTzSPhotZQfo9rusi5cL udqnE93MZGpcjzYf4FQUn+zaYl3b3IKubt7KnvsLMLHNmLHgB7dhQ1WkAEPnto7a0t+8ErcdIZXT 5DDJV2hRj955ms8AQExZNpgb1PDb2linlnIyx1A1q5z2zhvkXcJYdOgY9XrMSBSII+rQN5Q8pH+O qZv07kgSqXk33BZZv42zeGTBB08ad9yjlhJ634GxHGg4V5KKaegQNMz65hs9xMHAPniKuj9GNau6 s5aEyDPoo8epbiO1e0/acwgfWJqsDhrklK1Ao0bZXOchEyKkx/12i2tpwQoQhiUZoTkLYtXK0tVX W6t3ehVSiv26Vm/ZhJKF+8EXVMBFGPfceWvwMAnDlBowXx5hFvOcRvGlPOOB+8AkBowhJTvy3EvG yUJfN/J0Q4T+sK7PsCXfB8GZms1FRYvnMGg5CPPBC0kiioOL5ILOnc3DR0A2Rp5kQFCVrgpFIbVu LC1bAg3Oafy2DdT4OlOkF70+Spa4LiDD6z8aL5cqb9esGv3qO6lY4pnXnbv0rnc46Vnmhg0uZzcW LV9nNGqqX12NFq9HQs2V870HqGI1qdO9BGWC4TNVBUEQQ//SyzGvPI52Ov2eNutUtT8Zp3DJWld2 7FNuvNHITKX3PnZDyAVJO33WGfBMMRNUW5q3LIJULGhYq9eq19QHS8g33kg//uwVlEkf/7VWvVqM fUeo9evLH39lnSoGC+mQobp1BV+xXXEdhmWpw4m9TmdORx9+tpAtKsEFVuXLamM+JZkHPe+3be51 1xkiwUmqmDf8NQRaHsRz5+m9V2Tknlc1pZ/WeGZsxorPU9eHEZTN61vFVu4wdJVTlHmLi1rVs2vW puMn2PVdzf12XmHpUqFaNenXnYg6umHZ23Y5mWXCd3SgrfuI54V0bdhQztSeebZQdw34E9zjxVec qmX1F/6D12ADGmjabg8bCcJ56KHg6XyeWsDpvhifA/SgCoa+cTQ3bAdJKSjQevaNls6W0oTTv49x /iSXWfaftbv1Kk5JDsNnk4TRulnk+9lmzFtFSH/McZDlelM9OkcGrjHQyXx66nkjNUlGggO0ExNi T/SMHDrCnY3F9F69CZo2IYla3RA6wqmuUmRI02Y5GeWddGE9PSB69LzhaITk85vFTr1GpkiyHmxH Egw7WgTLffldNF7v0kXnnJp0WTdeHs5c0aZNZMtu3ZtHcX5cRpVKWXd0ULft4SmakOoMH8p7PdzL zPMcBG0d87lWsxRd34rOFNrQ5oDvzRfVRGFUqumuOOJ4xW9p8RK6pqqRJPRWTfQlm3WJeUGbu5Ra XQf20K+u7L73NlJEWbJo/vdGlWu0TOEEhC7SpRtvpV9+dbgKYUMV+GtbQOuaZSK42BwNCdIyBu+b OM1t3DiYnGwwVkJpUFeZOFGBjoGAmPBpUZNrudmVytvDXpcu5mJcQvtP0DMDNPh7hnA+Gh8rknEo HQY/9FUrq4whkvRnHuWYAQUes9zHn6HEgPJEH6vAS99y86X+gxmr29vL2/dZnrozZsynspnmre3V LTsgZYyQ4o4YRrDkbvcbZ87hjDHY1fjJBsRJzWvMtVt0hCsM/9gP9exUPbOsOvFHXeMFxZG1m6l1 K3CRXq18ZMz4aJR1kbHvPHW8Q0kUeoKI3nt7bPdBGIh78hjHzVKBaKKX4GRlqG+/QReDOG7Q9UI8 +fmNN6/mTboW6hRZvka/s30kQcgs9QN2QFhDhjo5hTxbvGo9NW/ADJAgpNtamRu2QDSDZSPTZ1LN miH4yDXV7WWbFN1EQ7XDF9Rb22hAO7Oc/eEoXgwGVPceM25pS1lZ8jvvULFXUtu1N9SpG7rjdO1q 7D7I9caYpH31DRS11bqNsnYjWqaHZHrvNfCVc+dt2o49GAgFWH0/x2lYw80sExr3qRrmUpK6YL7d qL6bmCL3HySf5Wt/g/uPETRtKnKNZKtHT/ngSQ6IMVJeG2ZVruwIEatc1hw5gi5Jhmq48+YhFl9K TLAFu63UrDFNgDbmEAevi3H1j/NlCZCp7H/WxgPGQ92KS6dazOfCDgTgaOayjRpE5v690lNPQWXh aZarEBr2nBlmd9CO5kT6DUIglkWq1LO3cfwMSyY5pn83U69SiXOra5vQj78gAAdtisz8Ua5ekapU U6ZOI4nDkLX013CzlhgX59GHrUNHmLiLgvqHn1F6stu8ub5yNfMrsPrgLVekIaOXl61U/Fm8pSvo xmYIu4WP9dTOS+hLdP8hur8bJSSoNzSNrd7AxedLIX3ct052JjzOql/Lmv696k3kxVatopatdJGJ 5lktmsor13M6kH+J+jympaZjfFW2E2G0axddsYwiqq9mFc4p4HoaB8EDx+iZJ9zSAagmx8PWhiO8 84GSa4J7lAmj6apysE8Z8ahZ8+BPP+ou27kyY7barFUEAGaVjXw+Qy/20ocjx9TePdTMUpIIOHff TTuPcV8ilj78fTMlgeo1klf8yuupwQLTZ0hVamjY7Om+5skTwEq/mG++/q6TlkyNGti/LIGmUUIS ffiek5Jt162u43Q8YUXGpi080SCSQi2amnvPw8NjhVEa/DKbRIVUZeK3zDAK6cu22zVrRNEXnLdf 34Jivu4tjLzvoZ6yyJTAG8kJ+jtvGkV8hVbRnHlU62rEdyWhFPNMZrry0N3Suk28tAPIe2sVeGYW Azp9ql4tEVDrIsPyHFBu1bxw234NnLZuEz14DzdDsMR1H+rOsgQ7Flv03AtOejqCndXwmsi6/brD 1qL8ssaoe5WZkMpG2L+/diEMWtVPX6QnHgft0PWttf37Yi7SdXI/GaumpLsiyRkyyDx3Gk1Rzly0 nhtqJSXRNbVo/gIQqxyK0eiRZlZFqlrKHTdB8+aMtD0HrPu7IDjKFStayzayMeu28+F4mFAkRUBH UeF5zk+P5Jh3dyxMSLPYhJoVrV7BfqSR/uFIuyySEa8Q2vYG6adVsJy8I+eoa2cpVbiBNFaAIgDz zn1xaHjfMZ6VJn/BGYUhJ6Z9o1cpU8S1wXT4slm2sv7Ou0HdtPIv0pDBVLoiy4/kNKl8GfOTcSoC guHaCFgtWrESzkyxH3kgepIr2HpMdkd+SsmJPDRZmcFPxpoxmyvsy5bZrW/Q0bz2d9oFFyUEOMi5 V15jYkxKJ3BI7nmQQeTIKePxp5noqldx58zGYDJWYz82sytTKUFvvc8ZC9jjxGm7Zw/01Ahk6V9P JSOm4Xjf/eRkZWtQDje3M9dw0qcVh4wRb0llKsPy9coVzNdeoohkgaXXrCCIQx79gFM63RzwrF50 HspT+2xicd0aDhuMiCVBzCcazZuG5i8BISoI0DaPr6S7zqYD1LGXLJK52JWaqrS6ibYcYatbMDla t2aUmaq8nCb0Nq1o1RYuZp7Piz31dCwlQ0pLonoNol9PpDAn9OFN66Kdu2B8FfS3ZdsYsldopGiR O/bj/MrlCkHR99xHOtjKMSOqMuA59EJLzaLhb9qFOWhQ8d6jSo9HmcGqlHdnfg+sYsDq09F6dkUb 0X/wK0Uxr36bk0uPPsbBUaQpI4ZT+KJs6dKSbVS1BiUk2WUr5I/9OBRzYw5E9c907XWqSJUzUuim lsU7d8VUnuGlAU9YaWWCIgG5s123mjpvLLCNHsyVOt9LKUl6chK3QSQ61SrSN7PwlbfW2o+CDvIa Z+su581Xok89pLzYhzYtAf6h9bvc66+llGTKTAsFRCSzLH0/ScqNhgsjNOZjqlwL4yKlBvKfeICK CiXbAanTi4PhUwYYLxAI9hug5IZCIMMLOdQOqgY6JKBgA5eVnLxhB7W5lURWuHy2OuoD63y+AZfb eci842YS2VJ2mjPxU6ami2Hpyy+ockVKz4p27qHlePrfNcxXX+UJpqQMrWMH2nOEFenuPfIDD8B3 TJFidnpA3nWMF28oMav/k6ZnQm5Sgt2zr3H0Ej4vXjGLalaQuayXGElLiN55W3DfUa52Tp8QbHC1 zraRTCki+uxjZ3bt5zI7mqLqEMYsXyH4IXlO5hF2OXaepAhdCtKg5/JLpcFCrIREJTM51uZ2OriN 7WTbHuO+e3SRjHGRr6oa+mgEqRJUiLJrr9Kti+FhYmekhEeNdiWTpwd3bKPraisi0UpI19947XJk WbzMadycRFq0QpYx5mM7t5irk5t2GzdfTyIjCr/+4iPGKk9Sxo+nqlUoJTV6e+fo4VzyaiL2O++Y PPTCaNnUXreF+3LyjNl/oJuYDLGnXds8OG8x13pN1Rr1LlWuYkNXJySbdetFcV6M1MkDzqO93UBp C7lJYsCqXlb7cGQ4LOmnz9KQl7Ra1xbUb57frTuSOCrmTMFwYExkOzx/6qoUUUiSyZApalCuTuac H6l2lWiATZHDbrUqwU8mkBLmqaNJU6QqZUN8/9Uk89a20sqVXlpDxsSvCxrUQlNBYnqNMrHZC3kh GKj9m+laNWyfTBWqumNHX178NmGSXPUqGKFcMcv54gu7kGegndWbjKZ1HZEcSk1wRo/gZc/Fujlh ItVg54rdcEtw434ibzrzw4/MpESYllG1vDxzgQl3DYbNDz6hjOwYeKxUOend4d7CENNavJBuvMGj a9YDsTffdEwDubE64weqWDnKc1VcC7XbtynYvY0TqL3HrUnfudNmujuPMxa6t6zLZf+TefGSt5bY ML1rSFyeCTp8TOvZS/EGzvHK9XRbu+DRC4AkeOKM2q9PDBTKMizJ6vukcaEAu9n5GqJeXlqC5WHr 3HytuXYruEE+lUP/8VIkMzWC+NKoCc34jryJNnrznWhmaVMk6FWyaNp0N2ywcPplhVm7CjoVS06g ka/D2hEa7EmT7auupoSA1rRlZPFKD2nX+WK8XipbY3YNxD7+wozKyNa0GbOoUoUItznZfvhBJz9m QPkjF+ve1WYRCKkpzI53qru3w7Si+/bTzc3BSxBv0IeEBPOTt53iIE6qRSLkXWZayKswkAo7Fi/W Q3oFgje9lV2WN+8JERGlzz+hKlUvIUzwM4HKl6fX39FjBuRc9Ifv1Cb1vBp+MqWnxcZ+xAm74lqr t8VualPMc6/4PJH6PkCHTmiQTFt2Ued7IWZi+PzmW/TlHLgtyJSn+ylJqZwd1MimOQtsiUWmO2+R WxV+kagmB2j4MBORR3bdb76xa11jJglq1FT7bpY35evY075Xa1RT/fnigS85Oeyb+uo1Zt0aMW98 oTPNDTsMdBMwvjzISk/gggzGsUrl6JfjgIBaHHZfesYtC7Ga4kC3wIM6tIT2U716l0Kawikhad4a V55eB5+C30EpNp4IHBQuiBjLlhe2bsILSEQW2M9MDFDz64rWbsUe6oUoDexrp4IqYdLCaVQ/uGwp i+FinT74KFq1osqliQS3TLL1/ptOTgGnwz8uQqDUvIhjde4a3nWAJ7nPFtD99+pcCUkwry7j/ryK F04iL/3me7dMGrjFgep4awiv8FBd57vvrdr1taQEqlPfGvcZ8So5x/jxZ+3ahmBgGIZ19wPO7n18 2EOH9BubeXI64FSrbH/6mR3THajHCZ8aNSt645voIhns11c7VwgDkRfOoaZ1NU9NsQdVyI68Pdzy Zh5VntbQ6PL6Pp639VfBuo5vTyRjizXbqF//PAQO5DgiA31Xs5LNZwfkRbyFvlPnUotGbMnoY7Kw +jwhnYRsVmnvSbrvTi0Vu7Dwc2qVk2fMkYpUE9nTmE/d1DTAwvMjjz8VvFDInUKEvamFxmow0ahd 3lq1hWfMQCOff2VlQgkkIcWmNwYbpuHItjVrtnPNtQo+qVpNf/tNx7vM11q+1mTBlhrGQeo21pYu 0UFiwULz/o4mS8REq1QWPXKfe7oAZhFbsYRubqVyTY+pyWnV1J49X0O7T52hHt0kduRE8CEaozZv pU6YSrlhZlQ3xhmNf3EFIAJQihPzVxxhEPOK6MORVCkdAU5PhMUi/kKTX03z5wHYSGFB7LFnImVS dS66JqilAs4noy0Z5hqhBcu1+uUUbkwGxJjboq6+dq+MFL74Eg17yZNn6WiJOfilmDcnaP64LNa4 jrcGIFGpXUHn6TDk4ipByacJ26u8ua8PMiDHJduYM8+t20SBj5QuG3txsB4O82Cv2Wbf2tYQ6RF4 VlZp6btpPKNgakbfxyiNU2MtKeBeX8vcdVwyKXxoP/XsTgnppsjIBzKlEs0XBoaKY0zWr78tlytl ZoG1kn15aT7wgLbjiK5Tke0V7bwViVxSlsm/vo2NCkny7J+pxW1QF1aWIPamgAWufqmPFjakAlLe /tBOKU8iuRBkghY2alK8Ym0xUD91mO7pStWzyVO8YBvrnk5F5/lK7qI1W53bWlqlM4ipVagfjnKh gYMGDXiFalY3vUK3dW2jot1bWfPnBun51ygzEIQDwor696U8PayQ8fN8Bzm4F8icO+5yL7JdRbbu Mro8rPtpfmai9vTzlMvrVmj8aKlSnVhyEhepypSxR31GxQa+iL43nBexiFQrUdgJIlSrNn00niQq WrU6dDsIJ0VLDLjJATNNULVs650PLO8a9T/MO3OdjGflkGaFLuZbb7yhlikdgvMGEqMiBRmT0rql tWiOA9feeszo2DESyEIboBZs9OWJPubR07Kq06L5VvWrpewEPYnjr5tR2u33dCS/mJOvGfOca2up oGXE8cwsG0oJUSYv4t77MJXP9sqJwm7RLHpwN0/Hn82lp1+kNBFMSKAE4T7Vhy7JSPTNJYvchlw3 s4HVzbc6xy6wQtt7yHrwMc7pYG+pQrn3PnXrPtu11NkztGsam0wgQk9Jl3s9phw7xZEd8Tc9g7UB GhMQalqW0vupolzFzblEz/ZWeJQTrAAS6iQlRdA9d8ubtllXrIG0vOXyXJlBunmJ/uNZNzNBSkhF VghGQjhTX+hv5RVYkJTjPqfKZSyfS+E7VapFZ8zkZb0nz9KA56BSwgnCTOA00K5Z0x09TpEMV5Ho 1bft0lkxzySQxdPc2VyIOHTcvLa5lIY8CNgK++Yb9ZOHeSrt4AmrV19KC2B7Fwg88aibEwFxOL8u YbEB9MA2DZuoazYxxUKK9HmWzThRuClCb36d8t1s2aHIxm1G69auFwqRfgbr1sldMJvV32bkINcx CSMN8cZIqtfwzJJfucw645vCyhWwS4w9Oo2zmzpV9EnjNTXyxxqyyUvmXDcCKy2I0pdfUqN60Cec piUJp3Vt+mUWi+cd29T7O3ABk+0tiZJTqev90ZOn2XPn/2zVbRr2cna/DdZNLe3la3S4+bG91KmL G0jQgAlMpVULd/UqngxdulSpXEVNZTthbNu3Nc/zLTDVLbuMTt0oPaD7GPbuaZ8pjCBXXbXcbdKc knhjvULVyKRpiqlSQYyGvWb79RY0tVJ5/a3hMZNiOSHq2skzwiRgFc5Iir4+kAqK1HPF+oCnIxx9 AqonwCB4Coc+z+nJuYvh7j0wRioXo7jIYNSsGpk6xYhG/zBHT8blKyPA85LL+fLAoXn1a58sXTba onHsnRe1C+d5adnnH6k1ShvcsEQoJSpTwRnzqWla0In2myNMJLCMlVefDwj9oXvV0xeRtlqzJpt1 rvGkbAph9DvdZSAJUg3ny8+07Ew3PUABzw473m7mXuQy7ap1dOMtTppXKkF3enazjp0PQ9X8ttJq 3MJirAJaerby5utyqJCijvPRKIeXWCTgpHZCgvnYozwZKpE78ClvWFNgzBKo787rae9eJ0LK1Imx MlloqspN5Rqd3rKxuXQ1i4Px06h2xSKvmKlklIn2eCy8bb+tOH+4RwrXS5i0eMGoystzjT2n6Ifp NOF7WrKSckNcJ9l7XHu8p5UOP0qykzhNsBo1iW3YBK+JnjxO3R50vUKiiQ6i76mJxQP7hiDCYy69 OcRJT7FZLacgDzWffNQ8fVEpDNGQwXZ6KmGIuTsB9967zaJiFnuLf6K6DQ3YiZcl2RDbR05GoLrW rzUbNlfYB5PMpHS37+MG7FAl9evx2F0N8KlNgHbXHXT0LDqkv/uGlJVlQvlzUpNMV2W7i3jtmbFl o1y/4SUWMAw7hl4tk0mjPrYhDKB5nu5d3LxOrFnj4meetZesRXyH6pSvvC7eyxl0jTQDqUdMJzsK sywyvAWroSJDGvOF0uAanXOBACIIr03q0cvIy+cMdOYMt0FDm82A1YUTSHArly0e/b6uknKqgHp1 Ia72p3KGmC6Ul4cREuETZ93776fkZLa0QIYcSHce6GoGIzwVOG2aVbGSzPaTADc0u3W2Dh9DfkFb NlrXtmTNIJK5vn1vB+PQHgxieO53blKaxJMvSRY0SfMmtHKFFXOU6VPkOrWNdOY3XtmYIpx337aC hpWXb3fuVZCR4QVrEeXXZHq4Jx3jyTXavZMWLuIC4/49JOnoe9EV13fwOhlOb9zf6374WvYvKPMK 8/q+g/RoL5t5j7vAoTwj03nrbeLr7yz9tWGxrAxONJJ5YRuQdJo1NBbNQceVTftiNzbXEFNEJuKd lCViUG5Aftdh6+a2BPGWgO2zo8mlnR4PWsGoLZnamNGxjIwIDwpEfoLBWB3l9djbt1rNbzLZrpLZ JG5tqe3YhFMUL1tAFapRKtsbsnitakV3xhRVtvQNazlZzhQW+3gS188ffiD/TJ5iuvTeeKpWkUuR aZmqpzeUhnWiP0zMg3OZvA4tpPEqca+07l5ExPtLa+85OOYXRmnYEMrO1DzvdrIDFrypQxt110aY enTtTrqd83fFo2jTE3LWgIcNKaxorvHWO1SlGlfevHBMGYn6D/Oi5KpLl9jlK5JXYWZmzq7sDn5O UcM20qH/eE0LJBmMFbOf0uEuY8tuV3b1g7up1U02lzUSuZvlKtjf/YIGRi/u0W+6jTKTOW5CwGdX cJ7qQeBQVZb79aekzFN+7MCzfB2aMI0ROH/QvqWtwrouXUpIVODvGalO2za0aTP5N2Pmxd2Sdz0M aX/xmjhyYgqFVq93O97OdQyPbA1k+khJ+vWkvPO8ZGj4+3K9q+GSKoc5L11NzTDefYPvpFEYcZ56 Ss2GxhC8kDKQSldXt3/9jfPzmTMNXvSb7GEVcMtWc18aomoRJyLTMy9EA8xUHlYB9c4O5qadyJ11 eNxNbV1v1QErh8wsdeIcnoG+dMC4oxN5FTYSKUpypn7/ncaFsGVa2htvUqlyF/g4vO7CTC1nv/Uu L2gxY9Srp8FYwRQTuIKNMF21ivb5F8VBzV8dJPnL0C3/1g1/6ZqOYLFKw0dSjUocyBLTHM6kEt1A ijL2fS6JHDul33hDfnKaGuDJI5amaFKNmvrMH/hUx45R+1uDCb4YE2pqttmuvb33KK/g/XSc5pVH NJ9MKtagN19XdMW9lE8P9w15+dplrNq3M9ZttqHbjxygW9r5up3tJCkpNuZrB6ZbeNLq3psnXnl7 tmqpVZPQrmPgDmPSFKpe3Vu17jUMTN7rEamIVxRo0Nvp2TqjBI8G/uC6xGj37rl7zyJbUzwKgj+a 3lUR6l/DKrZ1D93RgQLe6QLJrJEET6/oy5bCn9WZ03WeCkEzsiV/1gN9bHurunE7QoKxcik1qA3m 8YhaGBllpD795Jx8CoZp6DDdS4XsxETue6UazvvvK6bunjhFXXuEL2PFccpEurdqram41rHD1O52 N44VaPntka5kUCjXeX4o9L/p5ZXMBjWrFi5YYUGuLF9BzZp41McqjidQWraM8oJ8KvhhplK/rldz 4FJMLIEFld2koTplFhXy8jS+FoovrnX+6r1ToiHtu2+pYnmez/KyNr9WT72704mLdkGB8mS3aEqS N9Ypptd+BzTet496piAajFnjPkQXIGMMb0LHKVUh/P6HEXjZ0ZNu9x6GJ6rdhESeGaxawxw9VnJs d+8+6tBVvoyVp0VvamUsXc5XuJ48wddMXcaKN1Cff9HND5IcpQ9HU4XSXgO4MUaZ0tKHn9sh0z54 iO69x6M+CHtPmVSqHH3/fc6ADx+j++6JsdIAlyaGvR2dchnUp692OterU2mONxEv/8VrQjWNpk1y y2We8UoH3iJ5YWVnGFMnUbFNK1dR3fIRb/Q9i/KKP5nJ+sgP0DXl/Dl6sjslgdy8WSF8Vbla9Ie5 su3Qug32DS0ZIs7jkmCQRq3a1sQpvEBqwwZq28HwZI+Pldu6ubF4sQqsTp+m9ncarBmQJ6awTT7a 2zl1hhfeTZtBUOy+YYMHUtOcPv2dM3lWcdB6bhAleEEnJdXiIk+KctddSsEliqn06svRFNYMPDsc 8NINBNPOdxceO+et3pH9gpX8F69Hg6JD42+74VJyWpAjNXL5tOiddwYPn9JyIvTW20hXeYISzfBY HS5gVSkre+lebM9matPIyyPY5HgNydU11bXrTAzT3LlK5coSz1UBq8RoYsBq1JBmzuWF3IiPzdpo l7HyjtmyiTH/Rwny5ew5uqOj4VGiG0hlQu7SUdu129B5hbkDZhZcePeEfQLdcqux+5AFDfDeR4wP f87JDhtk9aukFfNN2aQp05QK5SWP+uxklhxOhbLm88MiF3iFp+ZfOcgl+b926V6YzgclGv4y1anj lekS3AYNtM++hvAK7Txqdb1f5soYYnE28laeYhOpZr1a+jq+W39kzWKqUzbEts0gc+GlTm1r504O w5O/jqalRbggz42PJCVaza+jBb9wpXHBj1r96+SSWLW41pg7B9rYPZdDHTuZvjuLVLaH9jdL6zbw V8tX2dWra97FDrrHjXa9egqXCCjy2QQKpIbQgIQE1SfbjGx93NuhoOwsW+00bMS+kCQomeuWWsMm 9rSF5F2FEgW3G6bKnEXaX8FKJjdq0OlTtHpJ5PtJJ2d/e3zrllAuL4EunDqVqlfwVHeip52QuSPr LB3qe7+Zf5yCrjVkuFmqNFOZp7RZo95yS3FekKPwy0PdAPsLL65gzZZAHe+SDuUoUIBTplLDazxb RVIJkJO0Bg2cKdM48youUu7u6HFmwE0WamaaftXVxqwfee3c7sPStXW8a0MSKYnPFSuV4Yyewneg 27gjWq+SN9kEZZvCHIIg3qaZ/fMe54JNC2brw54JPniX/ODdNOhFa+e6c8GL3nIevgkI33nJdqy/ eI8LmWsVtm7zpRBSlCc1QA66SxeLzBeHWEkcyExPZ5p+ATYxS33tBTcSpKMXzft7RcCcAY9AQO+Q 6F3vixWFKRwzn33GCnglu8BlNna6dtVOF1gaqZ9/SbWqs7NzyGAdrtev50ye6mMl39MJrMg6KlGo aUlahcrK5Okc1E6ed1s3c/ycgoOFkNIS3WHDSZOMAyftdq3M5FSebPLHRSQqV5UqmjhLKXIIaemh I7RhM/22lXZdMNSQl+rZ3k3zLt+u6q/eV83kRaOQ33yBub820vAuIlm1gdrfrvgTE0kZoBfuXWoy lcuiadN4zeDCpXLDBkFWC+meywitVCl65jkjrNCxE3qPhzD0JtJGr/rHQeqRh+18me8m8cEHZoWy 7Czsa6y+jLp1XMgkH6vOnT2sEnmZYoKQ0zLDH/Na8eiFfGrf1uaIBjtnX+MSTc+H7Zwc82whPfqQ mZ7q62HbVz6ZIjx0CJ05z4Umf+rN4LsNFPjYcMf5Yjc7fiuJv5rjuHR5Dox+nw9zadRYqnZVoadz HJFWLJJ83NxGld21O6B61eHDpewUXk2Xku05mtCrVKa3PzAUhzaut9vdxmzvVWt9JM0+fcwIrzB0 X3/VSEvjSqlfp0Kva9d0JkxkrIJBXmbAMpvXZJqcCCSFX32TE4SiYuoCbZDi6ZBELpNyoew6/bf1 8oUovTosls3JlOXbf2KqiYN3ak+rV3o3wbBDfCME7wJU29X9p0uXjYqv0v9rSY4R8erKl2+dwVi5 lmPr7uAX5MysXL++FICQY+nFHe/UUjpVRMeL5Z4PmJwvB+zkLJ59RoJc6yr7q28UxCzk1B6jauC6 hABbJuLggAFazDvVC4PshESd56QC/pyIU7Oa/fnnfE1lKCzdew+winpQeEIroD47yFZVkiR68gkT eQFjleBNDAmrckZs/MRYvkrffCtXyfLWGCf5JWhEAapWWZ082dW5U7J/Abh3Txrt91t/8O0+St7a 8S/dw9D1b2hiXrYrF0rW/HiUUadmgWcwVqJwErxsq2yW9eqAwgKDlq03WzfxmCFBDSSzTEoVTtOG xvzlCP32+E+oQkWvDM7VG04E0pNoyBBNJiNmUL8nLc82bD4mz+G61SpYY8cawCoSk7qwXUVYaQQM r5bu9OqtF+STqhiDhxhZZT2sALWn6NKE/MIL+oUQrd8q1yxT6MViLkpzdEih1IQoeqF5t4u2+A4P tmbwymWXdL4siVdlu+T+dajcy/v6dzr5/QaGAG3zZqv3w9HMDCQvNqtNoaWnR5tdp/w8Pxgy6bOx VrUsbxDRL/QokdKE07a1s34ftK36+mArkYfYShW2J9rd0un01ptISbTCsNvrAT+yc/T09WHlsubH H6mKSzFZvq8rJSRLwndP1sBup3uiyH0sXX5zhFm2opfLgMNTeH42AyGjs7n3mHvyktqqnjcTl+iV BBM5YW94jTxrOsjXu28Pu5yrcfanG6bOK1ZtbwLC4x/L+UuagVWrd1kd5L63UoKtyua6hfvlFGrS QqtSwylX0ShX0bz2erPPQDpz1ghp9GJ/jTVqKqJY0NPzLrC6qx3tO29LTmTAIzI3OwXZkJXE8tsp m0nIO0xSLuQZXTpGvVBlAqsEL65VLGWMGikBK1lVH3iAktJ8rC6vx7v1tuKd29jmP/mMqlbn2Rwv C4bHWWnCbtPcWLkuGLHdR+6hUuVJpCsJAQ18FSiV+0jfKK82J38K3oU1yK5++f5qnkWYl8nH5ps7 /Vv3CrPzi2nZcnr/PXXokMKPPri4ZnkkxLoruO8Itb3H60iyVwlJlEUqsnjjye6FaNjyZXRzawKV JSZBJkH2Q9U72VXUL8eywe/YRze25TIUz5ol24xVkoOk4M1XvTu0xMxe3V2/lOFVFHmpbZNr6fsF bBqLFlmNGmneNZLeigWudUerVIt++KUOWbl9V/5b/6E0v8ZCflqxUuSJnscWLaaI5mMlMTt5LPP3 3AcyZpGByJUTo/Nhyg+Tol5mNrShSUtW+B6lO+lwwBSeAhjyrGSRPHFC7JpanoxPjPk8BqxKV1cm fs5YbdzutrqR0/Mkzw39hVWJSfprw/jmQlHZ7vmQV/a5HBGApF67lv71t7zu/JefzeZNDS9NUP1A A4WWkUz9nwtDTjukX8qjNVto5hKavdLdtI0Ko94teXgaGekMi86/6XaDfCWpK5kU1CloUcQ7I18k JvFNBqSyZaPeRWFaeoadmUQJ8LV0+mgkNpJffimEhIh7mu4vmYPLuJVqqd98zbfOW77auq45p5DJ nht6UR7AKsOGgADMmOJ07256WoLZjPVGQKlQTh41lm8ltGKN3rxJhMNBhhRItNISmCSTUuieTsVn zvgXIkUBeGEsGpJkXubLiV4x5IZ3OzbvXjRk/D1Y/X6HUf8+rL/fv/Zs0Hj++VB6qsQFnAAyC/CV hNytann6YSZPD/XqKXs1HEDEkwIp3mrMq+trM793MLJzFuiNGrFiZBy43OQLSPmlFwxgJavU6xHL yweRqtupHmtlpKovveboFNt1lDrcAXO1RbI3s5mEkWJi7NAhdPggXxZGdoy8K7u968hkr/hZcDlH tvg2UPq/x0v/7b3pLEv3b/hmeNMXJtJLhHX1vBIZ+YlWwV8nluTNvoE6UuyWjQuXLHNORNSbWmt+ pQWJxmWsEpyG1+mLFjkY2a+nKtfUZmnKej7B+n2NnD70eUN3LKSLjzxhJXpYJfHkKfQVMmX7iaec oB06mkf3dY54tVaXRyqZktL1tMTYwBeM84X+jfvU34nbm4XhV927tRjCKGNl/j12xTdmcRFkkfIg oCIfgE/yUyF57Va6v5tcprTklz3R68ws9+UXC3bttbceUetdzRIoASTmwehj1by1sWKlq9rWx2Pk mtVZDyR64srXDJBSPlaaQb2fsrxilJ2CJ7RKEl/W0amzffRS9KJEb74UaVA1mJnuT2RbpdPV++7L mbnILuZMRma0HZ7bVSjGjG5cvtsR34vJ8Y3rb7nvLhuUe/nGX7xiyjMxjW/uoKgmLV1DzwwMN653 pl61nNvb5g8Z6uzax3n3mk1O1XIsLxMCRgb/OXQ91SvotWlrrd/gyrY14l2peiU4r4eVd3mL12vj xecMJKQ4zSP9L9dq0tm0fE93W7SQl60MgoJOHqPJn1mP9M5vdX1++5uLBvU3166LFfPN+SweU+RQ NutFJA/eXZhYWHvPyxN9f9u9l1Xvaf3njdo4T+QlrKDQkCvtP0O/LKOff6GV62NnQixVdJ1+XCBn J/M1XymJRinWTkoaI+be2s7atJWxev2NWJUK/4nV76VR7YVnNeaTy1gx2h5WUX8O7po6odk/yBIb e0zW7INn7BUbaM0GOnGWLL7AwrBsE/97t2z2SJbXUYEA8RnSIwN+AXHl36f4/x/3tQ7B6nZsoSe6 FZcX4WQ/f0nja+iShTH4ablAUy9FtcF9rewEXndRPtVXmy6jkXLpySejefz3FS88PZiy02NcjOKp PXa0ZCHd/xD/cdX4H5T88x01/1kP8m44Ck22dBUN6G81q6elJ4eyyujVaoZ69tB/+QWj7Fy8RMMG KqUzwl7ZOfL7YhUzIenSoAF2Aa95k2YuV3v0CF9dERDh6dQsS926xKbO1eN/VMKfQ/8v/9bwPwYr BGU7qlMkTLRlL40Zoz7TJzyoPzJHc8cenluCB8eCNGuWeUeH3LTkEMcyb3ooM5vad5Smz/avHQ6B e35br786JHbfncF72xX9x4DIqpW2/Mc/hfCPx4pvYcDXjyPpA7vKCkFF5xbwXa28wK2RdyObIoPm /GT17eVmJEM2RMtl5fV4RJ6znM5JvFrYpWIgqjt2fojOXKRTOXzvDr4clYz/8kaa7j/z8XtxwzYN xdQ1Tw5CCuZ63eTrPb3LEiSHCiMW7d5CX02hz75wv56obdvJ2ZpJMf/+G95lQ+D4mMKXacre53wj 5su3Yf/TjSL/mXyle0/jd61vXS6I8dSbfvl2r14gcyli8mWgfBcJvjWw6W+s8mb8dw78SOb698Dl ahrx3TKv+Jt0/r00/6l2xSv8ZcNSXH+JkmNr3q2fLJvXmpqcrOmXNTXjEfLSt9hlk/Nqbg7f7i2i OibkPasi6GCdVR3faZb0K/4wTfwP9PwjsfJv6+N4N+DlypANz4K7aexQfAWKyffE9NDzfsFGgBCg 2dDbGutdvruxB/LvBe2od3dQ6AQuQbh//As48ZuR/j/viBAi0f9ba+L/AFYd0cd6iwAA --Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: text/html; name=header.htm Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=header.htm Content-Transfer-Encoding: quoted-printable

 

 

文档名称

文档密级

 

 

2003-02-27

内部= 资料，请勿扩散

第<= /font>1页, 共1页

 

 

 

--Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: application/octet-stream; name=image001.wmz Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.wmz Content-Transfer-Encoding: base64 H4sIAAAAAAACC+29B7RUVbMtvPrkSM4gAhIliCCIooKKiAiKSlBMICIiIl7EHMAABkAMCJJEUaIk lSBJcs45pwOc3HHnWG/W3tj3iPd+w3e/5/h/x7hNn6ZP9w5rzVU1a1attfc5unvLZCHa1R6duKPu aXq1gcBj88cBkS5E4k93CREQH9zJnyXjJzNhdGK72vwuK+FBe3RiEt4lBtJEcoIQGt6KABGJf+dn +WejxeEJo8S6Gd3EvHnvi+EznhRvffeOePXbb8TTXy0RL4zZId4YsV2MenmF+GzwXPH149+IWQM/ FesHfMqNFOc2LxWRzZNE4alPxaEjP4iFx8eLBcc2io05+eK7AxfEgu2m2LrVEvs2F4vcozFRtFsS RTsvivDGY6JFixbiWRxjWKYQQxsJ0b49frkBPzffjJ9+QjR5C7/Mw88Y/LwgGorXxGPiPfF03T7i eWzYsWNHMQLffFVPiHEds0Xv3vjlAfx06yZEl8FC3PIhflmHn2/xM0LcLT4Rw5qMwzv+1wHb9xYT RBXxWykhfnlYiBdfxGb88/zzQjz1vhDdp+KXU2jnr6K9mCj6ie/F+BrzxUIxFUfsIl544QWxWtQV 57HV9iE4wwjvNP6btz4Xot9i/ELo1z5xn1iAr9aJpWKNOCZ+EWtr9cNmI8QJ0RxbCHHybSEmwy7E 1/iZ8Bn+nyXEa+tEmYdIdOqeA5w24Kznse8xjPxakVPrXfH5558LqWlbQYO7CeuLCuKnn7DvEvzM xoEWrwZs+0SZ10k8PSxPfFwhV6zAmbx/nbYJqjVWfPvtt4L6vS7oq0GCFjTBOGHfPWyOC4VYjzcz L4q6k0m8/nlYzGtDYndz7Hsffh49iP9niiVLlggaP17QvDeEtb+hOHwY++YJUeHsdsB2UYjfNNFm MYmx00isfEUTl/pg3+fw8+Ix/MwR69atE8Q/y4YKCtYVl863Z7hEn/ARIcJhIXZrYuB2EjN/wrnH kMh/D/sOx8+Yk4I+Wy0OHDggaOdOQevfhi0LkV88Qoyld8SnhEbgg6fPWmLyccJ5SJxGO/S52HcR fuYVClq4S5w6dUrQORxj7xRsPlgEg3PEalotFlJYDMP+7xWRWHiOxN69JHIPklBXYd+t+FlehPMe F7m5uYKkfEFnfsL+PwhF2SXO0G5xmBQxF/vPVUlsKiBx8iSJ2AUSURyHTjuCTkUEHcsVkUjE98Po Ify/T5jmRRGhoyIf5z+Gz09YJM5FSRQXk5AjJIx8bIv/Kd/AT8jblxnhhgSmAiFaiVS8Vko6TTvq Mm8wj9xZupbYhU9fEk97/soswt81xPunvc+Zcap4320aJf70cP/38b+P/338f/qAnxuG4b/xX/03 juOU/AS/2rbtv7e9B96Ypul/hYe/i7+9/3n8ffwgOJF/WOxuWVa8AfFHyWbgFdv7n2NjvGqaFm+b /1W8Vf4bVVX9g8cPgh1LduSK05V8YC+/2fEj4PUKrEqCUPK9/9B1Pd7g+Nnj2/h9jz9wLn9jHx+8 +n3E9jiO/z7e8fh7/7A+ziUb6X8b3+CKBw7ugxAfoJIPvz0lwfGPgyP7ffR7ER/ikr32P48f+c+m VXIbfwTju8f7Eh8jv6nxUbiikf6roiiIbNjGN4aSvcORASk28A8ex+cKJH27ihtJ/HSAveTox9/g 4DgXTKvkMa8YoP/OuvBJfFjjR4t/dQVQ8Y3xiMViEEDQYJs3b/Y76H8bH+6cnJzvv//+hx9+ABr+ wf19ZVn+7bff3njjjS5durRp0+aGG2647bbbhgwZsmDBgnA47DcYBzx69OjYsWOnTp167ty5/9Iw 8AmO88UXX0DHQcrEe4fzfvPNN5999tmaNWviXYvvfvDgwQkTJkycOPH48eMlRwffHjlyZMaMGePG jfv4448//f2BX3EovI4ZM+aTTz5Bl/2hOXz4MHo3bdo0nNp3kJJYXeF3x44de+yxx6pWrfruu+8G g8E4wnGuWL58OXC48cYb0eu47wBh9A4fpqSkVKhQ4ZZbbmnfvn3jxo0hS+rVq/fWW2+hpz5cK1eu bNq0aYMGDQBF3MF9iHzjKSwsRANKly790EMP7dmzJ77BvHnzmjVrVq1atccff/z06dMlRx8WBfyv vvrqRo0aTZkyJT40fpt//vnn22+/vVSpUuXKlcvKysos8UhPT0eDExMTBwwYEI1GsT1AQy+uu+66 1atX/9murnA3INDey4ReffVVmMoVI46NFy9eXMl7ANV4UwEgPsFe99xzDwZl7969O3fuXLRoUd++ fQEd2jNy5MhQKISNd+/eDSSx5XPPPXfp0qV4A3x2wptDhw7VrVuXM64XXigqKor3GqOflpaGz4Hz 2rVrSzYMJvrEE09w0pqcPGjQIN8afSSB//Tp0/22dejQoVOnTnfffTcyt7u8x5133onOwv4/+ugj IAwE5syZAzsBsPPnz4e/X4FV/DVu6p07d05KSvKx8r0vzhuwhF9++aVOnTo1a9Y8ceKEvwuQ6dmz JxqD7A8AlhwC4AOvxFewJYwvPgQ+MLPU1FQMH7wp3qm4GcyePRvY4hQwpPg4gt8Ago8GbANuUtL9 N23ahC4HAoGMjIw77rgD7YnTGh6gixo1atx6661oMNqPr3xm819xZEmSfKvA0TC+MM5rrrkGrfUV Qsk46JN2nMPPnDkD8HHeoUOH+gx8BfPjaLVr177qqqvAAz6VzZo1Cy6DscNXJanPf2zfvr1ly5bo I0ADdNhgw4YN2B5wjR8/vmRowyuQfNHLr5955pnz58/Hoy2MrWvXrvgcPohX2Fjc5vHt5MmTq1Sp ggPisGgYjDw+sjgsgC1Tpgx4Iz8/P+4dca4rqXbwWLhwIXwZHURf4sKmJFwlo9jJkyfhR2jPyy+/ 7Ltw/FufmpYuXQrYq1evji39XTgZF6Jhw4Zbt269Ynv/gN27d8cG4ASkjWg/xvHJJ58Eemg/rBfg vP7663jFGfv163fttdfCqkH+cTbDSefOnYvPYR4+kqAscAUsxNdU8PTKlSvDtX3zxhD47oOvsAGI HTviXHl5eSV7egVR+7376aefatWqhe0B2p+5vaRR4RXOfu+998IL3nvvvbjmLClXYJz169fH8MHd fCWDUf7vsMIrLB8sHccKx4Tx4yDwMnwIcoBBZmdng9YwmjAAfAgOh1vFBR4aAOoGGjD4H3/8EYSM DRAj/FaB04ADjAENHj16NHAG0QGWuA0giOD4cPm47Cn5Gg+Xvg8CIjQDRwNoV/jgn7GCD8LaERow WFu2bNm3b9/+/fsRkfEGPABfQMBFN2FaBw4c8B3nX9gVkEEQ97GCWwErH0B0ENSKD6EuRowYAWkB l+/fvz+4Ah8OHDgQ1hhXU+gCmBB2+Pbbb1+8eLFFixaAa9KkSf5X0DaAsW3btnB2dBAtx3t8GPdr +CAGAoS5ceNGBFY0G/Fl165deI9OYVBgHvEgAqzQNWAFWsaY/muszp49e//99+OM2B4kD3/Er3iD kIH3gBHxFM2GRwAE3/AgVP6FXWEz3weBFXoaF4fg6rJlyz777LNxX0BnEZIQyhFJCwoK4k2CuzVp 0gSxCSyNjQEsAuKwYcMw7mAtjBTMBs4LdkX3y3gPKLG4boT/YnDhKeB/aL/77rvP7xfcB+MFzscw AUDfRxDlgRV8EJb/F7FC13w+RCMBDpQSoGjevDksGRjiW3wCkeMf5F/4IN7AB3v06IFgAawuXLgQ Z1E/PAFzULHuPeBEiHHwbphxnFLAmRCZQBV+t27dOnyIEa9YsSIEQHFxMfZ6+OGH4cWwdnyFcIA4 goF+/vnnfSoDVnBbaDy0EH3B6fCKpkJ4+PEOxNutW7f/GVZxHwR/Qo9BySCyo5HQ0mu9xzvvvIPj QwIhDvomAZb411jBrnysIEjiVuSfCDvCtGAh6Lg/RtgY5B9P0yB7YDMJCQn4FgaGT8BFcCj0CISA 7qD76DU0pP9Vb6/MDcuBAvcbMHPmTDQYHAvQEILRSLyiR3iFA/76668gmf+ZD/rcDqxAI3+uP+AV ZgBYMPq+bscnIN5/gZXPV8AK3A67iidrIBOkBvgcBoNojsbjDewKPgXPglX4W8Jtb7rpJq9C/7yv ZnFkxDsMPaQCLBAOCM4HMugpjBCiF40HpwGEOLeXL18eB4nn1P8zbv/vNANO98orryDjuyLlxNEw gr7pAlV/l3/BV3gA0gceeACYwH7iWPkPjDh6AfJBv6C+oI5gJBjr+BlBQdD/0FTY/f333/fZHp9D Y6BHjz76KBjeb6rmPQAyjAc9Beb4yhfSOAuiLQbCV+YlM4X/K81QssbiCz8g4OsrkKeftsdh9HfB 0Wp4D6DqSyBYAvoCALdt2xZP83EiP92GrwErP6kBn5QsAfkw4itwDsYdIQMWWLLkBWeEjAfbA0Yo Xr93aBUEQ6tWrRD+br75ZvAq8PHbhoPjmOBVMPngwYN9wYk4iC2vv/56OJrf33i9CK8A3++dXziC JSAQwGtwzD/rqyscDZQCrMAPUIlo1RV1AOwOLQqywrDG7QpYYXvw544dO64oemADhAAggNEHVrAr v3l+MwDF8OHDgRViOgBBrz/88ENfBcVlPEwIkgnd94ndPyaoEhEN2MIsQVbr16+PnxHH7MYTcgLx Drk/PkFUBVbAFlESXgzrKvYeeI9XAAjP9b3bz0qAFUwL3I5D/evcGQqzXbt2vl3FYrE/F/qQVFb2 HqBWHz2fr2BXYMuSasEvXmGgfQ7v06cPgmzJuhDerFixAt7hT5RAF8GLS+penMKXYeBqiKK4ZEIv YDb+XogFvhiLmwqI0a9vQFD5fIUMCJYP023dujVCOWIlCA2vMDa8wXmhMXwDg8NiYwwBDOzPPljS bbExsEICgpCK1Due45Q0FXALwLz99tv9qAQ3RBIBoJC/QwHGK5nxIjA2g8hEy5HC+DWrkgeE5SCI wDZwRtByyTPiAcWFw+Lgo0aN8osS8RT766+/xl6IbojChYWFJVPpKVOmIFACFgwEtoTDwlMwuGW9 B3CAAZf2HqA1yDaAA3v2E0xAhN7BCFetWvXn3PmKMiNsCZEOOGMc49/GS5S+ky7yHuiXz7SIQdOn T4cygYCMW0X8DTaD9kD7Qdq+5oknTb6hIlB+9913OALexGWVTzXwWdAU9oX+uQJk2BIMBjvC9uIU F5eI+GrixIlwVZwCXDFv3jxQPXQaQidccurvj6+9BzbGoPiHBWOAqWBd6OafazJxrOK/wnfiNdt4 p+I1c79+7tuMn4P4JeWSddq4uf53dWk/fJecfSjZ2SsK4H4KGS93lCw4X1GQ90/qNz6ePscDTfxE JSvn/sbxb/1Zg5Kl7P9OM5SsgvrmdEVgvaLqe8WbK6JqyZmUeMPi4MfZEu/jkxp/LvKXPG8cipIF 1ZKV5Hgv4iPlnzHeDN8kSkrK+EnjbSspIa6wq3h74l/9mfD/PD/lj6k/ynGQSw5HvO/xUuGfp5ni X/ni5M/niltRXIpccYR4r0tuEJ86KWkJJY38z/Mp8Tm1+DxUycb8D+cTcWDbe/VOY5uGY5n80T/k 4fGg5T8d13QJg8vPv2nuFRDxk9zfn/bfdK6/q/2e4f/ecgy8yc+/5Vyud3weFP9cePIA/cOw+k+4 /L78Pee6bLS2Y1i2/rsZ/5N8MD5RDirxnpb79/iFTab3tPB0yIUr+gT2j7ErlxsdFy0e87r09zTf IlO3NcM2fZTAWwg+YPd/EFaXn390xr/jAVQ029LhgTbFZLuwSAmFoHb+MVgZOoduGxTllATL+Xvs yg+xJCnO6dMF+/adOXc2bP1zsCouCkfCkqpolvmHJOLfOaZikU6wIhuwgLgNipqkODY7ni4bOmlr V9CrT1tLVlKhQV5EDBmOZvlESYZDsmXH0BAEACYFz2OxOwS0R3L/13GnpJz+I396s7022YZvIcgc TM/FuPm6Q4qJ80NkRi1LAVccyTeWLVUOHJE0KsQ26KFiGzL250bR5TCFz0nVbdX5a84p2QYoCadl fMjgJ96hDYatUmTBYqtPt+jYcaH9ZzkZtkhVJIpGHVXH96Sblq/xdEPjA6BHvnr9PR8CXP9GrKc/ VnV0fsujcDmf8E6Nb3SfiPCNYpiqAeNhcWBY9PMC/cvPpJ2HHYy4C280AKXORoHv/EDFR9BNW7X/ Ki/ZGCmXVT/vyAcxcBDu+7Jtwbvbad3u0dcf0qJuCIZWHNZ2rHYvnXclXcOGFs6t8R6ao1sEBzX8 oOmD5XqR59/H6nKGgpMQ0483HDi25Ydp1adxbrx27qJ65CgVFsF6ZHTl4EF66SXl2Wf1dbtsNO9y 0xjzy7m/Jx0tTzf+JbTY9bw8ldjIYTiefZO2/Yx7TzutdmVp+k8UYpdXImp05Qpn9lf5OTmmQhFu sEbRIPwQp4TVmzoBMcAFTuVKBf4j53/Ib//FAj8wA+PDXo5XnMLDSg/zLx5WrnzkhLp2Le3c4SEj oyvGD4uoRf1Yzwf13afhMBFC0syYo2U2m6Jj+bncX9SNXpTQPO+DZYK9rKhBB45Rr2eV8oIe6Wmc UWWQAL7fusl+931j3VKpWNF1CmouBfPp4kVVMjXV0RlrG8YN0DzEXFdDb+z/Z3aFI1vgKpcHFrJY tUz+lbSciF1U4LCxkH2pkH5bR7PmFBTF2NR1KrwUcZ97yq6UqTz/Cp0uYg/QbJO/cn+HC0qIOcf5 a/FOYqBsfkF7wkQ//UaPPRwUQmvdxPx5hau4USL5yF778/fpo3FupBjjpciknL1Im9ZLx0+HsRdX ugwKRy3NdkzuFJs7sHL+DaxKlpK42OK7mW3BFDAwiuZThn46L3rksJJ7lm1OsWnHPmvsuNOz5lAB aARbOLHNO/V27Zzy5dT3P3SKiiwMJAgdtIV9AZfj57x/jVa9IbmsasM6/byWHuqlJouCjCTng4/0 cAz2YuSH6eNR8quDlc17eTOF5AsR96fF5tyZ0fP5QAZERTnn3AvnNXC+RwEcK2ISevZvYRVfFASP hnQBShrSLZOKi83cXBneDjPLDym7d6krf5VCMZxaO18QmfpN7MnH1VW7bQsO4UYUCk2dRxWrFNes nvvO++6ZU6Qa3GfNhTNaHlB/lVcx9B5fqeCo3Qep7xORUqmxhAS67XZz/UaMi+xQ7Jt5+j13yyPe L1I9b1Acdftec+TwwlkzWGFoTswoNndtDR0+GNU0xko2tJAUzS8K/5t25aPkF6kuXIoohgu3xnCc Ph0+ePBSJIYRIdOkHbvsSZMvnrsA54CbxTZto7va0eD++WdOAAU4SuxkmB4dZApRVL0y/TD9wIUL bFoG2xXrRfIE0h/rUaxGeAqKYJuu6UkDh+MIWTyHY287InXrRYEUJxAI1q/qLJ5VHC5gW/1pDTW7 PtqxR2zdIY2ZTTVUWX7pHRr1WSg/anqL6rT58+irqZQXDoPYoHRORtWtu+0TPBsTg3nnFLsniylm 2B4lUlQxw6amewpHV9xQDDSNTslgS5VHTdJJVW3KCQcLcxAnoCWd/OLgljVUoCiQULxq9wjN+N45 g7CC45N86Kz10Ufu7IVOgQwGMy5JxudfFmVn06vvWcEYKxrXMX7b5ra4MVcIq1KN6CeT1AjOJkms Comp4kqsOFKwDVt+TLf9EdRVpiltx/bI008UVa4E8KXq1eR3PqYzR9F6bf1upWcns2md0KgJWq6C XWBZytJ55tAXaeEKBzrPsKyiqP7F58a0mTrkDaxKJ2nt7uiK1UbeWQ8r1zh0Wj+SA8NlKWJrlHNR zYsYiJ5wseIi63yuFQNGrmbq2oVc8DX6ZqAvx85Gdv3mFhWacPKikLRprXrshBNVOQadOk3f/aD8 tpEK5RBRpCBK38+hQX2jK5dx++B5R07RLXeE291UOHsO2oMhjuTk0GtvUuksK710rFGdgq8+pUjU q52bKsAw1D9g5bgKYpPJNOZHFRwSsUBTydq+L9r/Eal0wBDCSU+n7g+Yu0+zyjypSs8N1ioL+9mH 6fBpNkL0/UTE6veAPepN8/hFjtmg1BVr5ZEfyWu3aJ56Ae27M2ZpCxc4EZW1v+qo67ZE9x4kz3hi 4ZC7c0fszHnHchzTsU6eNPYf1kG5CAhy1Ny0iYKFbMzhKB057Pw4UT9x3MBZohFj67bQr/PpdAFC iXIx35q/SJowmo6cV8iW4Ce7T1HXW4reGEBHLukx05Bk/dsFdtMqatfO7s6LsH02wdWr6Oa2BSJA QijX1aevJlCInTji6s4VaYLjyuBbrhpw0OVcAO9ggkcv0IAnlHKJrhAwKrNpc+27GeiVjOH4bKJb o5zbpCat/40YF9tRTP2LmXRjU+WXH/ViXbcgllV6+83YxG8pL+Qr0Oi5EH0ykubNobDNCTg8YsHi 4PZtOACQjZ0/R8uWROBEoADdsbZtNdZtBFEzaYSKafo058RRCHELUvj8GZr0gb5rrwVT0XT14LHg hHeBCeKPElH0zdvNV/s6v20nDmEmFVj00tBYl7b2zIUaAhyQL5Kp2x1u6UztrdEUkWGNoaJC98Nx xanplkgkEXAbNo5OnQMCkMAK7pU+CGBszUtnWHBTDLa9by8N6E/VysrYV6RRcnK0/8DghSJ0St66 y7n9OsoQ7rARtszJRJGt0KrV1Lat0627dOZ8WHFALOaJffTY/dridRgB0zFtydHmLjIH9pV/+pmK 7SgSre2HnW+/D+3aCpZkF9220539g7RvP2MlO+bSpdZPS9xLF5hdC4L07tvuhg26woxqhEP0+bva ivVqjIGMncmLvvkMrdoBf7DBc2Dy57pL46eCcDXXcmK2unqHe8+tysBntEtqzEu0jK+mOuXLGI2v oYWLDFbaDu06GuvymMKmFbBFVlGLZkWLF2C0TUO7AitW15JXvPOUp7pjtzH0hUtlkpXEDEkkUEoS demobTwQgxPt3UxPPmJWEJHb25ubec4ZRhg8cZp6PaBWSg+On27EHIykcbaQxo/Rnn/c3XSQ5SG8 O6eQBvQNPflI8bY9TF2KStN/oMlT5SOHYVcqhnzBAmPqNGX/YcYqapug6Jlzybt6wM6P0nMDaf6P SkiDPFNAWeNGat/MDV7kBQixvLD6yjPG9HngfI4mUZleHxJ94iltw55CbG1rKuzjhYHmbS2Vbxde MLw1KSeL7Ie6UapQ7up4cdl6SdXgLbGZv1qNaoFtLJGG19DdbWjBbFe1/jjnhUF1DYW4FsyU7piz 51vXNz6VmGAmZmAvrU0ze8FCHXy+5zANepKykoxaNXO+mkwyj1EoqtDIj6lsGbnDbdEjp0GXUPju 4mXO/Z2Lpk6k03mgPhUfrVhPbRrGXnnFPcdrMQw5aA8ZbE+eakJRY3TCQRr3aWTiFBncizELGsYX XzlTvqWz59A3LVd1HnuSJnxhMMMDK8P5YpwzalzBfh4svTjmDH9LewtueIg1qWYYPyxw2twovTwy UhRiIQOzQShsd7P1eE/rLH+CiO9OmUC1yioiIbdbH2nrLm7S0XPymy8plVJtIWyRaAaE2fueSG40 /AeswJhM6JwlI+sDCSz4mW5oSsmpAEquWEEa85UGpygstD8YblapdBFe2aV3aIfnLEQX9uylls2C SWXc0eO8xA905tgjR8kNGuZv3m6DD+AXl0KxceOjddKt8VOoyJsgKzorPdhJnzTVjfAknlZ4id54 PW/8JPn4Ba4TFBn66LHOl5PoxGnYuZRrWr0ep9HvOqeOcUknalmTJtIbI4q2bGFSimo05nO9Xz9n zXqOxboV25lDjerrLW7Ut2z3LN+kA/lmlwfM+mk0d1UE6TD6uXeL26M7qNhIrBT9+PNCjmbkQn60 axFjrNJIJFs9e0iFIbqipoos3ZuUBXGBlin3HM2Zsr9GNWpQOfrJqKILuSEY8y9LqEGDKNgvLdse +anqcM0hr5ho0EuUmZTX4T4Ky1rES003baa7bnJ6dSwqzoPgQ94d23aC7riN2t9Z/NtOA2BCUP26 1KnVmKbPj4BWoJDPak7ve+nryXpRDGagK6b13DD6+BP7/FkJVhEupO6Pm0OG0M79JghLlunX1cVP P07TF7NdGba5ZiH1vN3+YJpUbLLQA0917pKXUsH5cqxfRAgiWx/+rpaRbN37IIHbLTdkGNJXY6hU WhjI3NSClm5ifZcboiHPR8slIJYZLW/O/2FxJKI6V65VY6xcr47BbG0ZdOKANXY6fbfQ3HNMjUJN baSH7jay0gpxkA5dpHVbOQVHCPh+IbW8wax7deS9r3RF4lTibIH58vN689rKqBGOpLLN2o707Wz3 2vpWv+eN4+e5LnCuIPb+e5G6jbWFv3plEMfdkSN3usn4eorKKskxIKuees4Z8a5x+gRjhUyzVx+n 96PGxq0cruFC6zdFenV1x06GJkRct/ZvhzCIPjEovP8crINzqxHvWunllEd7qTkFnpYjWvwTNW2k VblKnTqJLvAFAfrmHdHefeXUBK18tvzwo9Ke7WrUoQ37YyM/Ut59j2Yssk7lWfCUP3I7V/D87Ach DNkQRkLXYBKGTlGVtK1H5V6PqglCy0jSGtUz584zEbgxUmvXUfuOGjRq9wfpeJ7jlbiC387TapVx bqxnr9+BiKvi2AVB/dknqXzpyIQ5nIaQo+48HLyrY+j61uG17CNcF1i0RbqhQXDyNyq7tWsWhewH H9Vfelk7chQSmqSQ83h/6tBBXrKMp0HAsAeOGF1utV9+w4oSBtcoDFK3u4uuaxabsdhzOleGHqvb WK1euXjuIr9aouZeoCEDwUXG9c3U+cv9SlP419+oyTWKEIUp6aE3BilHIYypMKrF5DB51VvlCt0O 2cmFKdObJ2ObUr0Ml3kbjJdz0n6mXzglWwXJVyirDR8TkoKs0s/maP0HRgJpWlKaOXasJ2JtO2ZH +j4HA9Z7d3PzDOg8ZtL124zWtalypchavqoPOlhZ9ptUtYbZ7aEok7NrwPwmLbCurRWa9oPkVZzc C/nOnZ21gc+ZBw7xIgcpbD41gA145izIQ0jl2MV86nwTPdrbORuRYMyySwOfiZZPpRdehX6RXDsW k+jhvtCW2tP9KS+C74tgjvNnUmomPiwa+Ip57AzbW/ASDXrMzS4dgVRoWEv9dKIR5hZEED49hGEU 1h+x4sQXNsQlVq5IgI815nuI/Ah9P5auylZEEolEt1nj4l0nwT9hRZXnzDcb1JPQmBva26s3YX8J R955wGncUk9LBdVAYBjslK71wVilkqAbWseOhj38LXvyN45Ipldflc5eYPULsQpZWLeG8u28CHkX NJ/NoRtu1h7v4+47zFUkJao9/axzTT366isYLxoQDat0f3u6qz1tPw6vRTzSPhotZQfo9rusi5cL udqnE93MZGpcjzYf4FQUn+zaYl3b3IKubt7KnvsLMLHNmLHgB7dhQ1WkAEPnto7a0t+8ErcdIZXT 5DDJV2hRj955ms8AQExZNpgb1PDb2linlnIyx1A1q5z2zhvkXcJYdOgY9XrMSBSII+rQN5Q8pH+O qZv07kgSqXk33BZZv42zeGTBB08ad9yjlhJ634GxHGg4V5KKaegQNMz65hs9xMHAPniKuj9GNau6 s5aEyDPoo8epbiO1e0/acwgfWJqsDhrklK1Ao0bZXOchEyKkx/12i2tpwQoQhiUZoTkLYtXK0tVX W6t3ehVSiv26Vm/ZhJKF+8EXVMBFGPfceWvwMAnDlBowXx5hFvOcRvGlPOOB+8AkBowhJTvy3EvG yUJfN/J0Q4T+sK7PsCXfB8GZms1FRYvnMGg5CPPBC0kiioOL5ILOnc3DR0A2Rp5kQFCVrgpFIbVu LC1bAg3Oafy2DdT4OlOkF70+Spa4LiDD6z8aL5cqb9esGv3qO6lY4pnXnbv0rnc46Vnmhg0uZzcW LV9nNGqqX12NFq9HQs2V870HqGI1qdO9BGWC4TNVBUEQQ//SyzGvPI52Ov2eNutUtT8Zp3DJWld2 7FNuvNHITKX3PnZDyAVJO33WGfBMMRNUW5q3LIJULGhYq9eq19QHS8g33kg//uwVlEkf/7VWvVqM fUeo9evLH39lnSoGC+mQobp1BV+xXXEdhmWpw4m9TmdORx9+tpAtKsEFVuXLamM+JZkHPe+3be51 1xkiwUmqmDf8NQRaHsRz5+m9V2Tknlc1pZ/WeGZsxorPU9eHEZTN61vFVu4wdJVTlHmLi1rVs2vW puMn2PVdzf12XmHpUqFaNenXnYg6umHZ23Y5mWXCd3SgrfuI54V0bdhQztSeebZQdw34E9zjxVec qmX1F/6D12ADGmjabg8bCcJ56KHg6XyeWsDpvhifA/SgCoa+cTQ3bAdJKSjQevaNls6W0oTTv49x /iSXWfaftbv1Kk5JDsNnk4TRulnk+9lmzFtFSH/McZDlelM9OkcGrjHQyXx66nkjNUlGggO0ExNi T/SMHDrCnY3F9F69CZo2IYla3RA6wqmuUmRI02Y5GeWddGE9PSB69LzhaITk85vFTr1GpkiyHmxH Egw7WgTLffldNF7v0kXnnJp0WTdeHs5c0aZNZMtu3ZtHcX5cRpVKWXd0ULft4SmakOoMH8p7PdzL zPMcBG0d87lWsxRd34rOFNrQ5oDvzRfVRGFUqumuOOJ4xW9p8RK6pqqRJPRWTfQlm3WJeUGbu5Ra XQf20K+u7L73NlJEWbJo/vdGlWu0TOEEhC7SpRtvpV9+dbgKYUMV+GtbQOuaZSK42BwNCdIyBu+b OM1t3DiYnGwwVkJpUFeZOFGBjoGAmPBpUZNrudmVytvDXpcu5mJcQvtP0DMDNPh7hnA+Gh8rknEo HQY/9FUrq4whkvRnHuWYAQUes9zHn6HEgPJEH6vAS99y86X+gxmr29vL2/dZnrozZsynspnmre3V LTsgZYyQ4o4YRrDkbvcbZ87hjDHY1fjJBsRJzWvMtVt0hCsM/9gP9exUPbOsOvFHXeMFxZG1m6l1 K3CRXq18ZMz4aJR1kbHvPHW8Q0kUeoKI3nt7bPdBGIh78hjHzVKBaKKX4GRlqG+/QReDOG7Q9UI8 +fmNN6/mTboW6hRZvka/s30kQcgs9QN2QFhDhjo5hTxbvGo9NW/ADJAgpNtamRu2QDSDZSPTZ1LN miH4yDXV7WWbFN1EQ7XDF9Rb22hAO7Oc/eEoXgwGVPceM25pS1lZ8jvvULFXUtu1N9SpG7rjdO1q 7D7I9caYpH31DRS11bqNsnYjWqaHZHrvNfCVc+dt2o49GAgFWH0/x2lYw80sExr3qRrmUpK6YL7d qL6bmCL3HySf5Wt/g/uPETRtKnKNZKtHT/ngSQ6IMVJeG2ZVruwIEatc1hw5gi5Jhmq48+YhFl9K TLAFu63UrDFNgDbmEAevi3H1j/NlCZCp7H/WxgPGQ92KS6dazOfCDgTgaOayjRpE5v690lNPQWXh aZarEBr2nBlmd9CO5kT6DUIglkWq1LO3cfwMSyY5pn83U69SiXOra5vQj78gAAdtisz8Ua5ekapU U6ZOI4nDkLX013CzlhgX59GHrUNHmLiLgvqHn1F6stu8ub5yNfMrsPrgLVekIaOXl61U/Fm8pSvo xmYIu4WP9dTOS+hLdP8hur8bJSSoNzSNrd7AxedLIX3ct052JjzOql/Lmv696k3kxVatopatdJGJ 5lktmsor13M6kH+J+jympaZjfFW2E2G0axddsYwiqq9mFc4p4HoaB8EDx+iZJ9zSAagmx8PWhiO8 84GSa4J7lAmj6apysE8Z8ahZ8+BPP+ou27kyY7barFUEAGaVjXw+Qy/20ocjx9TePdTMUpIIOHff TTuPcV8ilj78fTMlgeo1klf8yuupwQLTZ0hVamjY7Om+5skTwEq/mG++/q6TlkyNGti/LIGmUUIS ffiek5Jt162u43Q8YUXGpi080SCSQi2amnvPw8NjhVEa/DKbRIVUZeK3zDAK6cu22zVrRNEXnLdf 34Jivu4tjLzvoZ6yyJTAG8kJ+jtvGkV8hVbRnHlU62rEdyWhFPNMZrry0N3Suk28tAPIe2sVeGYW Azp9ql4tEVDrIsPyHFBu1bxw234NnLZuEz14DzdDsMR1H+rOsgQ7Flv03AtOejqCndXwmsi6/brD 1qL8ssaoe5WZkMpG2L+/diEMWtVPX6QnHgft0PWttf37Yi7SdXI/GaumpLsiyRkyyDx3Gk1Rzly0 nhtqJSXRNbVo/gIQqxyK0eiRZlZFqlrKHTdB8+aMtD0HrPu7IDjKFStayzayMeu28+F4mFAkRUBH UeF5zk+P5Jh3dyxMSLPYhJoVrV7BfqSR/uFIuyySEa8Q2vYG6adVsJy8I+eoa2cpVbiBNFaAIgDz zn1xaHjfMZ6VJn/BGYUhJ6Z9o1cpU8S1wXT4slm2sv7Ou0HdtPIv0pDBVLoiy4/kNKl8GfOTcSoC guHaCFgtWrESzkyxH3kgepIr2HpMdkd+SsmJPDRZmcFPxpoxmyvsy5bZrW/Q0bz2d9oFFyUEOMi5 V15jYkxKJ3BI7nmQQeTIKePxp5noqldx58zGYDJWYz82sytTKUFvvc8ZC9jjxGm7Zw/01Ahk6V9P JSOm4Xjf/eRkZWtQDje3M9dw0qcVh4wRb0llKsPy9coVzNdeoohkgaXXrCCIQx79gFM63RzwrF50 HspT+2xicd0aDhuMiCVBzCcazZuG5i8BISoI0DaPr6S7zqYD1LGXLJK52JWaqrS6ibYcYatbMDla t2aUmaq8nCb0Nq1o1RYuZp7Piz31dCwlQ0pLonoNol9PpDAn9OFN66Kdu2B8FfS3ZdsYsldopGiR O/bj/MrlCkHR99xHOtjKMSOqMuA59EJLzaLhb9qFOWhQ8d6jSo9HmcGqlHdnfg+sYsDq09F6dkUb 0X/wK0Uxr36bk0uPPsbBUaQpI4ZT+KJs6dKSbVS1BiUk2WUr5I/9OBRzYw5E9c907XWqSJUzUuim lsU7d8VUnuGlAU9YaWWCIgG5s123mjpvLLCNHsyVOt9LKUl6chK3QSQ61SrSN7PwlbfW2o+CDvIa Z+su581Xok89pLzYhzYtAf6h9bvc66+llGTKTAsFRCSzLH0/ScqNhgsjNOZjqlwL4yKlBvKfeICK CiXbAanTi4PhUwYYLxAI9hug5IZCIMMLOdQOqgY6JKBgA5eVnLxhB7W5lURWuHy2OuoD63y+AZfb eci842YS2VJ2mjPxU6ami2Hpyy+ockVKz4p27qHlePrfNcxXX+UJpqQMrWMH2nOEFenuPfIDD8B3 TJFidnpA3nWMF28oMav/k6ZnQm5Sgt2zr3H0Ej4vXjGLalaQuayXGElLiN55W3DfUa52Tp8QbHC1 zraRTCki+uxjZ3bt5zI7mqLqEMYsXyH4IXlO5hF2OXaepAhdCtKg5/JLpcFCrIREJTM51uZ2OriN 7WTbHuO+e3SRjHGRr6oa+mgEqRJUiLJrr9Kti+FhYmekhEeNdiWTpwd3bKPraisi0UpI19947XJk WbzMadycRFq0QpYx5mM7t5irk5t2GzdfTyIjCr/+4iPGKk9Sxo+nqlUoJTV6e+fo4VzyaiL2O++Y PPTCaNnUXreF+3LyjNl/oJuYDLGnXds8OG8x13pN1Rr1LlWuYkNXJySbdetFcV6M1MkDzqO93UBp C7lJYsCqXlb7cGQ4LOmnz9KQl7Ra1xbUb57frTuSOCrmTMFwYExkOzx/6qoUUUiSyZApalCuTuac H6l2lWiATZHDbrUqwU8mkBLmqaNJU6QqZUN8/9Uk89a20sqVXlpDxsSvCxrUQlNBYnqNMrHZC3kh GKj9m+laNWyfTBWqumNHX178NmGSXPUqGKFcMcv54gu7kGegndWbjKZ1HZEcSk1wRo/gZc/Fujlh ItVg54rdcEtw434ibzrzw4/MpESYllG1vDxzgQl3DYbNDz6hjOwYeKxUOend4d7CENNavJBuvMGj a9YDsTffdEwDubE64weqWDnKc1VcC7XbtynYvY0TqL3HrUnfudNmujuPMxa6t6zLZf+TefGSt5bY ML1rSFyeCTp8TOvZS/EGzvHK9XRbu+DRC4AkeOKM2q9PDBTKMizJ6vukcaEAu9n5GqJeXlqC5WHr 3HytuXYruEE+lUP/8VIkMzWC+NKoCc34jryJNnrznWhmaVMk6FWyaNp0N2ywcPplhVm7CjoVS06g ka/D2hEa7EmT7auupoSA1rRlZPFKD2nX+WK8XipbY3YNxD7+wozKyNa0GbOoUoUItznZfvhBJz9m QPkjF+ve1WYRCKkpzI53qru3w7Si+/bTzc3BSxBv0IeEBPOTt53iIE6qRSLkXWZayKswkAo7Fi/W Q3oFgje9lV2WN+8JERGlzz+hKlUvIUzwM4HKl6fX39FjBuRc9Ifv1Cb1vBp+MqWnxcZ+xAm74lqr t8VualPMc6/4PJH6PkCHTmiQTFt2Ued7IWZi+PzmW/TlHLgtyJSn+ylJqZwd1MimOQtsiUWmO2+R WxV+kagmB2j4MBORR3bdb76xa11jJglq1FT7bpY35evY075Xa1RT/fnigS85Oeyb+uo1Zt0aMW98 oTPNDTsMdBMwvjzISk/gggzGsUrl6JfjgIBaHHZfesYtC7Ga4kC3wIM6tIT2U716l0Kawikhad4a V55eB5+C30EpNp4IHBQuiBjLlhe2bsILSEQW2M9MDFDz64rWbsUe6oUoDexrp4IqYdLCaVQ/uGwp i+FinT74KFq1osqliQS3TLL1/ptOTgGnwz8uQqDUvIhjde4a3nWAJ7nPFtD99+pcCUkwry7j/ryK F04iL/3me7dMGrjFgep4awiv8FBd57vvrdr1taQEqlPfGvcZ8So5x/jxZ+3ahmBgGIZ19wPO7n18 2EOH9BubeXI64FSrbH/6mR3THajHCZ8aNSt645voIhns11c7VwgDkRfOoaZ1NU9NsQdVyI68Pdzy Zh5VntbQ6PL6Pp639VfBuo5vTyRjizXbqF//PAQO5DgiA31Xs5LNZwfkRbyFvlPnUotGbMnoY7Kw +jwhnYRsVmnvSbrvTi0Vu7Dwc2qVk2fMkYpUE9nTmE/d1DTAwvMjjz8VvFDInUKEvamFxmow0ahd 3lq1hWfMQCOff2VlQgkkIcWmNwYbpuHItjVrtnPNtQo+qVpNf/tNx7vM11q+1mTBlhrGQeo21pYu 0UFiwULz/o4mS8REq1QWPXKfe7oAZhFbsYRubqVyTY+pyWnV1J49X0O7T52hHt0kduRE8CEaozZv pU6YSrlhZlQ3xhmNf3EFIAJQihPzVxxhEPOK6MORVCkdAU5PhMUi/kKTX03z5wHYSGFB7LFnImVS dS66JqilAs4noy0Z5hqhBcu1+uUUbkwGxJjboq6+dq+MFL74Eg17yZNn6WiJOfilmDcnaP64LNa4 jrcGIFGpXUHn6TDk4ipByacJ26u8ua8PMiDHJduYM8+t20SBj5QuG3txsB4O82Cv2Wbf2tYQ6RF4 VlZp6btpPKNgakbfxyiNU2MtKeBeX8vcdVwyKXxoP/XsTgnppsjIBzKlEs0XBoaKY0zWr78tlytl ZoG1kn15aT7wgLbjiK5Tke0V7bwViVxSlsm/vo2NCkny7J+pxW1QF1aWIPamgAWufqmPFjakAlLe /tBOKU8iuRBkghY2alK8Ym0xUD91mO7pStWzyVO8YBvrnk5F5/lK7qI1W53bWlqlM4ipVagfjnKh gYMGDXiFalY3vUK3dW2jot1bWfPnBun51ygzEIQDwor696U8PayQ8fN8Bzm4F8icO+5yL7JdRbbu Mro8rPtpfmai9vTzlMvrVmj8aKlSnVhyEhepypSxR31GxQa+iL43nBexiFQrUdgJIlSrNn00niQq WrU6dDsIJ0VLDLjJATNNULVs650PLO8a9T/MO3OdjGflkGaFLuZbb7yhlikdgvMGEqMiBRmT0rql tWiOA9feeszo2DESyEIboBZs9OWJPubR07Kq06L5VvWrpewEPYnjr5tR2u33dCS/mJOvGfOca2up oGXE8cwsG0oJUSYv4t77MJXP9sqJwm7RLHpwN0/Hn82lp1+kNBFMSKAE4T7Vhy7JSPTNJYvchlw3 s4HVzbc6xy6wQtt7yHrwMc7pYG+pQrn3PnXrPtu11NkztGsam0wgQk9Jl3s9phw7xZEd8Tc9g7UB GhMQalqW0vupolzFzblEz/ZWeJQTrAAS6iQlRdA9d8ubtllXrIG0vOXyXJlBunmJ/uNZNzNBSkhF VghGQjhTX+hv5RVYkJTjPqfKZSyfS+E7VapFZ8zkZb0nz9KA56BSwgnCTOA00K5Z0x09TpEMV5Ho 1bft0lkxzySQxdPc2VyIOHTcvLa5lIY8CNgK++Yb9ZOHeSrt4AmrV19KC2B7Fwg88aibEwFxOL8u YbEB9MA2DZuoazYxxUKK9HmWzThRuClCb36d8t1s2aHIxm1G69auFwqRfgbr1sldMJvV32bkINcx CSMN8cZIqtfwzJJfucw645vCyhWwS4w9Oo2zmzpV9EnjNTXyxxqyyUvmXDcCKy2I0pdfUqN60Cec piUJp3Vt+mUWi+cd29T7O3ABk+0tiZJTqev90ZOn2XPn/2zVbRr2cna/DdZNLe3la3S4+bG91KmL G0jQgAlMpVULd/UqngxdulSpXEVNZTthbNu3Nc/zLTDVLbuMTt0oPaD7GPbuaZ8pjCBXXbXcbdKc knhjvULVyKRpiqlSQYyGvWb79RY0tVJ5/a3hMZNiOSHq2skzwiRgFc5Iir4+kAqK1HPF+oCnIxx9 AqonwCB4Coc+z+nJuYvh7j0wRioXo7jIYNSsGpk6xYhG/zBHT8blKyPA85LL+fLAoXn1a58sXTba onHsnRe1C+d5adnnH6k1ShvcsEQoJSpTwRnzqWla0In2myNMJLCMlVefDwj9oXvV0xeRtlqzJpt1 rvGkbAph9DvdZSAJUg3ny8+07Ew3PUABzw473m7mXuQy7ap1dOMtTppXKkF3enazjp0PQ9X8ttJq 3MJirAJaerby5utyqJCijvPRKIeXWCTgpHZCgvnYozwZKpE78ClvWFNgzBKo787rae9eJ0LK1Imx MlloqspN5Rqd3rKxuXQ1i4Px06h2xSKvmKlklIn2eCy8bb+tOH+4RwrXS5i0eMGoystzjT2n6Ifp NOF7WrKSckNcJ9l7XHu8p5UOP0qykzhNsBo1iW3YBK+JnjxO3R50vUKiiQ6i76mJxQP7hiDCYy69 OcRJT7FZLacgDzWffNQ8fVEpDNGQwXZ6KmGIuTsB9967zaJiFnuLf6K6DQ3YiZcl2RDbR05GoLrW rzUbNlfYB5PMpHS37+MG7FAl9evx2F0N8KlNgHbXHXT0LDqkv/uGlJVlQvlzUpNMV2W7i3jtmbFl o1y/4SUWMAw7hl4tk0mjPrYhDKB5nu5d3LxOrFnj4meetZesRXyH6pSvvC7eyxl0jTQDqUdMJzsK sywyvAWroSJDGvOF0uAanXOBACIIr03q0cvIy+cMdOYMt0FDm82A1YUTSHArly0e/b6uknKqgHp1 Ia72p3KGmC6Ul4cREuETZ93776fkZLa0QIYcSHce6GoGIzwVOG2aVbGSzPaTADc0u3W2Dh9DfkFb NlrXtmTNIJK5vn1vB+PQHgxieO53blKaxJMvSRY0SfMmtHKFFXOU6VPkOrWNdOY3XtmYIpx337aC hpWXb3fuVZCR4QVrEeXXZHq4Jx3jyTXavZMWLuIC4/49JOnoe9EV13fwOhlOb9zf6374WvYvKPMK 8/q+g/RoL5t5j7vAoTwj03nrbeLr7yz9tWGxrAxONJJ5YRuQdJo1NBbNQceVTftiNzbXEFNEJuKd lCViUG5Aftdh6+a2BPGWgO2zo8mlnR4PWsGoLZnamNGxjIwIDwpEfoLBWB3l9djbt1rNbzLZrpLZ JG5tqe3YhFMUL1tAFapRKtsbsnitakV3xhRVtvQNazlZzhQW+3gS188ffiD/TJ5iuvTeeKpWkUuR aZmqpzeUhnWiP0zMg3OZvA4tpPEqca+07l5ExPtLa+85OOYXRmnYEMrO1DzvdrIDFrypQxt110aY enTtTrqd83fFo2jTE3LWgIcNKaxorvHWO1SlGlfevHBMGYn6D/Oi5KpLl9jlK5JXYWZmzq7sDn5O UcM20qH/eE0LJBmMFbOf0uEuY8tuV3b1g7up1U02lzUSuZvlKtjf/YIGRi/u0W+6jTKTOW5CwGdX cJ7qQeBQVZb79aekzFN+7MCzfB2aMI0ROH/QvqWtwrouXUpIVODvGalO2za0aTP5N2Pmxd2Sdz0M aX/xmjhyYgqFVq93O97OdQyPbA1k+khJ+vWkvPO8ZGj4+3K9q+GSKoc5L11NzTDefYPvpFEYcZ56 Ss2GxhC8kDKQSldXt3/9jfPzmTMNXvSb7GEVcMtWc18aomoRJyLTMy9EA8xUHlYB9c4O5qadyJ11 eNxNbV1v1QErh8wsdeIcnoG+dMC4oxN5FTYSKUpypn7/ncaFsGVa2htvUqlyF/g4vO7CTC1nv/Uu L2gxY9Srp8FYwRQTuIKNMF21ivb5F8VBzV8dJPnL0C3/1g1/6ZqOYLFKw0dSjUocyBLTHM6kEt1A ijL2fS6JHDul33hDfnKaGuDJI5amaFKNmvrMH/hUx45R+1uDCb4YE2pqttmuvb33KK/g/XSc5pVH NJ9MKtagN19XdMW9lE8P9w15+dplrNq3M9ZttqHbjxygW9r5up3tJCkpNuZrB6ZbeNLq3psnXnl7 tmqpVZPQrmPgDmPSFKpe3Vu17jUMTN7rEamIVxRo0Nvp2TqjBI8G/uC6xGj37rl7zyJbUzwKgj+a 3lUR6l/DKrZ1D93RgQLe6QLJrJEET6/oy5bCn9WZ03WeCkEzsiV/1gN9bHurunE7QoKxcik1qA3m 8YhaGBllpD795Jx8CoZp6DDdS4XsxETue6UazvvvK6bunjhFXXuEL2PFccpEurdqram41rHD1O52 N44VaPntka5kUCjXeX4o9L/p5ZXMBjWrFi5YYUGuLF9BzZp41McqjidQWraM8oJ8KvhhplK/rldz 4FJMLIEFld2koTplFhXy8jS+FoovrnX+6r1ToiHtu2+pYnmez/KyNr9WT72704mLdkGB8mS3aEqS N9Ypptd+BzTet496piAajFnjPkQXIGMMb0LHKVUh/P6HEXjZ0ZNu9x6GJ6rdhESeGaxawxw9VnJs d+8+6tBVvoyVp0VvamUsXc5XuJ48wddMXcaKN1Cff9HND5IcpQ9HU4XSXgO4MUaZ0tKHn9sh0z54 iO69x6M+CHtPmVSqHH3/fc6ADx+j++6JsdIAlyaGvR2dchnUp692OterU2mONxEv/8VrQjWNpk1y y2We8UoH3iJ5YWVnGFMnUbFNK1dR3fIRb/Q9i/KKP5nJ+sgP0DXl/Dl6sjslgdy8WSF8Vbla9Ie5 su3Qug32DS0ZIs7jkmCQRq3a1sQpvEBqwwZq28HwZI+Pldu6ubF4sQqsTp+m9ncarBmQJ6awTT7a 2zl1hhfeTZtBUOy+YYMHUtOcPv2dM3lWcdB6bhAleEEnJdXiIk+KctddSsEliqn06svRFNYMPDsc 8NINBNPOdxceO+et3pH9gpX8F69Hg6JD42+74VJyWpAjNXL5tOiddwYPn9JyIvTW20hXeYISzfBY HS5gVSkre+lebM9matPIyyPY5HgNydU11bXrTAzT3LlK5coSz1UBq8RoYsBq1JBmzuWF3IiPzdpo l7HyjtmyiTH/Rwny5ew5uqOj4VGiG0hlQu7SUdu129B5hbkDZhZcePeEfQLdcqux+5AFDfDeR4wP f87JDhtk9aukFfNN2aQp05QK5SWP+uxklhxOhbLm88MiF3iFp+ZfOcgl+b926V6YzgclGv4y1anj lekS3AYNtM++hvAK7Txqdb1f5soYYnE28laeYhOpZr1a+jq+W39kzWKqUzbEts0gc+GlTm1r504O w5O/jqalRbggz42PJCVaza+jBb9wpXHBj1r96+SSWLW41pg7B9rYPZdDHTuZvjuLVLaH9jdL6zbw V8tX2dWra97FDrrHjXa9egqXCCjy2QQKpIbQgIQE1SfbjGx93NuhoOwsW+00bMS+kCQomeuWWsMm 9rSF5F2FEgW3G6bKnEXaX8FKJjdq0OlTtHpJ5PtJJ2d/e3zrllAuL4EunDqVqlfwVHeip52QuSPr LB3qe7+Zf5yCrjVkuFmqNFOZp7RZo95yS3FekKPwy0PdAPsLL65gzZZAHe+SDuUoUIBTplLDazxb RVIJkJO0Bg2cKdM48youUu7u6HFmwE0WamaaftXVxqwfee3c7sPStXW8a0MSKYnPFSuV4Yyewneg 27gjWq+SN9kEZZvCHIIg3qaZ/fMe54JNC2brw54JPniX/ODdNOhFa+e6c8GL3nIevgkI33nJdqy/ eI8LmWsVtm7zpRBSlCc1QA66SxeLzBeHWEkcyExPZ5p+ATYxS33tBTcSpKMXzft7RcCcAY9AQO+Q 6F3vixWFKRwzn33GCnglu8BlNna6dtVOF1gaqZ9/SbWqs7NzyGAdrtev50ye6mMl39MJrMg6KlGo aUlahcrK5Okc1E6ed1s3c/ycgoOFkNIS3WHDSZOMAyftdq3M5FSebPLHRSQqV5UqmjhLKXIIaemh I7RhM/22lXZdMNSQl+rZ3k3zLt+u6q/eV83kRaOQ33yBub820vAuIlm1gdrfrvgTE0kZoBfuXWoy lcuiadN4zeDCpXLDBkFWC+meywitVCl65jkjrNCxE3qPhzD0JtJGr/rHQeqRh+18me8m8cEHZoWy 7Czsa6y+jLp1XMgkH6vOnT2sEnmZYoKQ0zLDH/Na8eiFfGrf1uaIBjtnX+MSTc+H7Zwc82whPfqQ mZ7q62HbVz6ZIjx0CJ05z4Umf+rN4LsNFPjYcMf5Yjc7fiuJv5rjuHR5Dox+nw9zadRYqnZVoadz HJFWLJJ83NxGld21O6B61eHDpewUXk2Xku05mtCrVKa3PzAUhzaut9vdxmzvVWt9JM0+fcwIrzB0 X3/VSEvjSqlfp0Kva9d0JkxkrIJBXmbAMpvXZJqcCCSFX32TE4SiYuoCbZDi6ZBELpNyoew6/bf1 8oUovTosls3JlOXbf2KqiYN3ak+rV3o3wbBDfCME7wJU29X9p0uXjYqv0v9rSY4R8erKl2+dwVi5 lmPr7uAX5MysXL++FICQY+nFHe/UUjpVRMeL5Z4PmJwvB+zkLJ59RoJc6yr7q28UxCzk1B6jauC6 hABbJuLggAFazDvVC4PshESd56QC/pyIU7Oa/fnnfE1lKCzdew+winpQeEIroD47yFZVkiR68gkT eQFjleBNDAmrckZs/MRYvkrffCtXyfLWGCf5JWhEAapWWZ082dW5U7J/Abh3Txrt91t/8O0+St7a 8S/dw9D1b2hiXrYrF0rW/HiUUadmgWcwVqJwErxsq2yW9eqAwgKDlq03WzfxmCFBDSSzTEoVTtOG xvzlCP32+E+oQkWvDM7VG04E0pNoyBBNJiNmUL8nLc82bD4mz+G61SpYY8cawCoSk7qwXUVYaQQM r5bu9OqtF+STqhiDhxhZZT2sALWn6NKE/MIL+oUQrd8q1yxT6MViLkpzdEih1IQoeqF5t4u2+A4P tmbwymWXdL4siVdlu+T+dajcy/v6dzr5/QaGAG3zZqv3w9HMDCQvNqtNoaWnR5tdp/w8Pxgy6bOx VrUsbxDRL/QokdKE07a1s34ftK36+mArkYfYShW2J9rd0un01ptISbTCsNvrAT+yc/T09WHlsubH H6mKSzFZvq8rJSRLwndP1sBup3uiyH0sXX5zhFm2opfLgMNTeH42AyGjs7n3mHvyktqqnjcTl+iV BBM5YW94jTxrOsjXu28Pu5yrcfanG6bOK1ZtbwLC4x/L+UuagVWrd1kd5L63UoKtyua6hfvlFGrS QqtSwylX0ShX0bz2erPPQDpz1ghp9GJ/jTVqKqJY0NPzLrC6qx3tO29LTmTAIzI3OwXZkJXE8tsp m0nIO0xSLuQZXTpGvVBlAqsEL65VLGWMGikBK1lVH3iAktJ8rC6vx7v1tuKd29jmP/mMqlbn2Rwv C4bHWWnCbtPcWLkuGLHdR+6hUuVJpCsJAQ18FSiV+0jfKK82J38K3oU1yK5++f5qnkWYl8nH5ps7 /Vv3CrPzi2nZcnr/PXXokMKPPri4ZnkkxLoruO8Itb3H60iyVwlJlEUqsnjjye6FaNjyZXRzawKV JSZBJkH2Q9U72VXUL8eywe/YRze25TIUz5ol24xVkoOk4M1XvTu0xMxe3V2/lOFVFHmpbZNr6fsF bBqLFlmNGmneNZLeigWudUerVIt++KUOWbl9V/5b/6E0v8ZCflqxUuSJnscWLaaI5mMlMTt5LPP3 3AcyZpGByJUTo/Nhyg+Tol5mNrShSUtW+B6lO+lwwBSeAhjyrGSRPHFC7JpanoxPjPk8BqxKV1cm fs5YbdzutrqR0/Mkzw39hVWJSfprw/jmQlHZ7vmQV/a5HBGApF67lv71t7zu/JefzeZNDS9NUP1A A4WWkUz9nwtDTjukX8qjNVto5hKavdLdtI0Ko94teXgaGekMi86/6XaDfCWpK5kU1CloUcQ7I18k JvFNBqSyZaPeRWFaeoadmUQJ8LV0+mgkNpJffimEhIh7mu4vmYPLuJVqqd98zbfOW77auq45p5DJ nht6UR7AKsOGgADMmOJ07256WoLZjPVGQKlQTh41lm8ltGKN3rxJhMNBhhRItNISmCSTUuieTsVn zvgXIkUBeGEsGpJkXubLiV4x5IZ3OzbvXjRk/D1Y/X6HUf8+rL/fv/Zs0Hj++VB6qsQFnAAyC/CV hNytann6YSZPD/XqKXs1HEDEkwIp3mrMq+trM793MLJzFuiNGrFiZBy43OQLSPmlFwxgJavU6xHL yweRqtupHmtlpKovveboFNt1lDrcAXO1RbI3s5mEkWJi7NAhdPggXxZGdoy8K7u968hkr/hZcDlH tvg2UPq/x0v/7b3pLEv3b/hmeNMXJtJLhHX1vBIZ+YlWwV8nluTNvoE6UuyWjQuXLHNORNSbWmt+ pQWJxmWsEpyG1+mLFjkY2a+nKtfUZmnKej7B+n2NnD70eUN3LKSLjzxhJXpYJfHkKfQVMmX7iaec oB06mkf3dY54tVaXRyqZktL1tMTYwBeM84X+jfvU34nbm4XhV927tRjCKGNl/j12xTdmcRFkkfIg oCIfgE/yUyF57Va6v5tcprTklz3R68ws9+UXC3bttbceUetdzRIoASTmwehj1by1sWKlq9rWx2Pk mtVZDyR64srXDJBSPlaaQb2fsrxilJ2CJ7RKEl/W0amzffRS9KJEb74UaVA1mJnuT2RbpdPV++7L mbnILuZMRma0HZ7bVSjGjG5cvtsR34vJ8Y3rb7nvLhuUe/nGX7xiyjMxjW/uoKgmLV1DzwwMN653 pl61nNvb5g8Z6uzax3n3mk1O1XIsLxMCRgb/OXQ91SvotWlrrd/gyrY14l2peiU4r4eVd3mL12vj xecMJKQ4zSP9L9dq0tm0fE93W7SQl60MgoJOHqPJn1mP9M5vdX1++5uLBvU3166LFfPN+SweU+RQ NutFJA/eXZhYWHvPyxN9f9u9l1Xvaf3njdo4T+QlrKDQkCvtP0O/LKOff6GV62NnQixVdJ1+XCBn J/M1XymJRinWTkoaI+be2s7atJWxev2NWJUK/4nV76VR7YVnNeaTy1gx2h5WUX8O7po6odk/yBIb e0zW7INn7BUbaM0GOnGWLL7AwrBsE/97t2z2SJbXUYEA8RnSIwN+AXHl36f4/x/3tQ7B6nZsoSe6 FZcX4WQ/f0nja+iShTH4ablAUy9FtcF9rewEXndRPtVXmy6jkXLpySejefz3FS88PZiy02NcjOKp PXa0ZCHd/xD/cdX4H5T88x01/1kP8m44Ck22dBUN6G81q6elJ4eyyujVaoZ69tB/+QWj7Fy8RMMG KqUzwl7ZOfL7YhUzIenSoAF2Aa95k2YuV3v0CF9dERDh6dQsS926xKbO1eN/VMKfQ/8v/9bwPwYr BGU7qlMkTLRlL40Zoz7TJzyoPzJHc8cenluCB8eCNGuWeUeH3LTkEMcyb3ooM5vad5Smz/avHQ6B e35br786JHbfncF72xX9x4DIqpW2/Mc/hfCPx4pvYcDXjyPpA7vKCkFF5xbwXa28wK2RdyObIoPm /GT17eVmJEM2RMtl5fV4RJ6znM5JvFrYpWIgqjt2fojOXKRTOXzvDr4clYz/8kaa7j/z8XtxwzYN xdQ1Tw5CCuZ63eTrPb3LEiSHCiMW7d5CX02hz75wv56obdvJ2ZpJMf/+G95lQ+D4mMKXacre53wj 5su3Yf/TjSL/mXyle0/jd61vXS6I8dSbfvl2r14gcyli8mWgfBcJvjWw6W+s8mb8dw78SOb698Dl ahrx3TKv+Jt0/r00/6l2xSv8ZcNSXH+JkmNr3q2fLJvXmpqcrOmXNTXjEfLSt9hlk/Nqbg7f7i2i OibkPasi6GCdVR3faZb0K/4wTfwP9PwjsfJv6+N4N+DlypANz4K7aexQfAWKyffE9NDzfsFGgBCg 2dDbGutdvruxB/LvBe2od3dQ6AQuQbh//As48ZuR/j/viBAi0f9ba+L/AFYd0cd6iwAA --Boundary_(ID_rz4AkEEyGJQNAhijwa78SA) Content-id: Content-type: text/html; name=header.htm Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=header.htm Content-Transfer-Encoding: quoted-printable

 

 

文档名称

文档密级

 

 

2003-02-27

内部= 资料，请勿扩散

第<= /font>1页, 共1页

 

 

 

--Boundary_(ID_rz4AkEEyGJQNAhijwa78SA)-- From owner-mpls@UU.NET Mon Jul 14 15:40:14 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19612 for ; Mon, 14 Jul 2003 15:40:12 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxis08389 for ; Mon, 14 Jul 2003 19:40:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxis07904; Mon, 14 Jul 2003 19:39:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxig07393 for mpls-outgoing; Mon, 14 Jul 2003 16:32:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxig07384 for ; Mon, 14 Jul 2003 16:32:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxig17450 for ; Mon, 14 Jul 2003 16:31:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxig21755 for ; Mon, 14 Jul 2003 16:31:24 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQoxig21633 for ; Mon, 14 Jul 2003 16:31:19 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 14 Jul 2003 22:12:37 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.8.7.36]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6EGOu0r013756; Mon, 14 Jul 2003 21:54:56 +0530 Reply-To: From: "Prabakaran T Sampath" To: "'Terry Lee'" , Cc: "'prabakarts'" Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Date: Mon, 14 Jul 2003 22:02:46 +0530 Message-Id: <000201c34a25$8fdbd4e0$2407080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <000001c349ce$fa5b8ba0$d9226e0a@HUAWEI.COM> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C34A53.A99410E0" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C34A53.A99410E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Terry Lee, Please find my in lined comments [PrabakarTS]. Thanks and regards, Prabakaran T.S. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. email : prabakarts@future.futsoft.com Off Phone: +91-44-24330550 - Extn: 319 ----------------------------------------------------------- -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Terry Lee Sent: Monday, 14 July 2003 11:43 AM To: 'mpls@uu.net' Cc: Terry Lee Subject: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 1. DETOUR object’s Class is TBD, Why? [PrabakarTS] In section 4.2 of the draft, the class value is specified to be of Class = TBD (to conform 0bbbbbbb format for compatibility) It meant that the Class value is not yet assigned and time being we can use the "0bbbbbbb" format as specified in RFC 2205 section 3.10 for backward compatibility. So that, The high-order bit of the C-Class is zero; LSRs that do not support the DETOUR objects MUST reject any Path message containing a DETOUR object and send a PathErr to notify the PLR. This PathErr SHOULD be generated as specified in [RSVP] for unknown objects with a class-num of the form "0bbbbbbb". So, time being(until draft finalizes the Class value) it is upto the implementation specific to assign some unique Class value of the form "0bbbbbbb" for this DETOUR Object Class. The similar answer is applicable for FAST_REROUTE Object of its Class = TBD (use form 11bbbbbb for compatibility) 2. should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes. [PrabakarTS] Yes, you are correct. 3. in facility technique, a backup tunnel can protected many LSP. Say LSP1and LSP2 in different SESSION. What the FRR backup tunnel’s SESSION should be? In draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt: Thus, the only field in the SESSION and SENDER_TEMPLATE objects which could be varied between a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE. [PrabakarTS] IPv4 tunnel Sender address in SENDER_TEMPLATE will be used to identify the Backup path in the Sender-Template-Specific Backup path Identification approach at the PLR. The PLR should put its IPv4 tunnel Sender address in SENDER_TEMPLATE. Whereas in Path-Specific - Backup path Identification approach the DETOUR object, is used to distinguish between PATH messages for a backup path and the protected LSP. ------=_NextPart_000_0003_01C34A53.A99410E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Terry Lee,
 
Please=20 find my in lined comments [PrabakarTS].
 
Thanks=20 and regards,
Prabakaran T.S.
Future=20 Software Limited,
480-481, Anna Salai,
Chennai - 600035, India.
email : prabakarts@future.futsoft.c= om
Off Phone: +91-44-24330550 - Extn: = 319
-----------------------------------------------------------
-----Original Message-----
From: owner-mpls@uu.net=20 [mailto:owner-mpls@uu.net]On Behalf Of Terry = Lee
Sent:=20 Monday, 14 July 2003 11:43 AM
To: = 'mpls@uu.net'
Cc: Terry=20 Lee
Subject: questions about=20 draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

1.      =20 DETOUR = object’s=20 Class is TBD, Why?

[PrabakarTS]  In=20 section 4.2 of the draft, the class value is specified to be of=20

Class =3D = TBD  (to=20 conform 0bbbbbbb format for compatibility)  It meant that the = Class=20 value

is not yet = assigned and=20 time being we can use the "0bbbbbbb" format as specified in=20

RFC 2205 = section 3.10 for=20 backward compatibility.  So that,

 

The = high-order bit of the=20 C-Class is zero; LSRs that do not = support

the DETOUR = objects MUST=20 reject any Path message containing a = DETOUR

object and = send a PathErr=20 to notify the PLR.  This PathErr = SHOULD

be generated = as specified=20 in [RSVP] for unknown objects with a

class-num of = the form=20 "0bbbbbbb". 

 

So, time = being(until draft=20 finalizes the Class value) it is upto the implementation = specific to=20

assign some = unique Class=20 value of the form "0bbbbbbb" for this DETOUR Object=20 Class.

 

The=20 similar answer is applicable for FAST_REROUTE Object=20

of its Class = =3D TBD =20 (use form 11bbbbbb for = compatibility)

 

2.      =20 should = DETOUR=20 object be contained in the head-end LSR in one-by-one technique? I = think the=20 answer is yes.
[PrabakarTS]  Yes, you are=20 correct.

3.      =20 in = facility=20 technique, a backup tunnel can protected many LSP. Say LSP1and LSP2 in = different SESSION. What

the = FRR backup=20 tunnel’s SESSION should be?

In=20 draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt:

Thus, = the only=20 field in the SESSION and SENDER_TEMPLATE objects which could be varied = between=20

a = backup path=20 and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in = the=20 SENDER_TEMPLATE.
[PrabakarTS] IPv4 tunnel Sender address in=20 SENDER_TEMPLATE will be used to identify the Backup=20 path

in the=20 Sender-Template-Specific Backup path Identification approach at the = PLR. =20 The PLR should put its

IPv4 tunnel = Sender address=20 in SENDER_TEMPLATE. Whereas in Path-Specific - Backup path = Identification=20

approach the = DETOUR=20 object, is used to distinguish between PATH messages for a backup path = and=20 the
protected LSP.

 

 

------=_NextPart_000_0003_01C34A53.A99410E0-- From owner-mpls@UU.NET Mon Jul 14 15:42:20 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19782 for ; Mon, 14 Jul 2003 15:42:19 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxis10028 for ; Mon, 14 Jul 2003 19:42:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxis09672; Mon, 14 Jul 2003 19:42:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxif06762 for mpls-outgoing; Mon, 14 Jul 2003 16:21:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxif06751 for ; Mon, 14 Jul 2003 16:21:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxif16790 for ; Mon, 14 Jul 2003 16:20:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxif14865 for ; Mon, 14 Jul 2003 16:20:58 GMT Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxif14839 for ; Mon, 14 Jul 2003 16:20:57 GMT Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2003 09:19:57 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6EGKouG029082 for ; Mon, 14 Jul 2003 09:20:51 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAQ28316; Mon, 14 Jul 2003 12:20:49 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6EGKnE00194 for mpls@uu.net; Mon, 14 Jul 2003 12:20:49 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQowyl11030 for ; Sat, 12 Jul 2003 00:52: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 QQowyl18365 for ; Sat, 12 Jul 2003 00:52:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQowyl18568 for ; Sat, 12 Jul 2003 00:52:50 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sea2-f7.sea2.hotmail.com [207.68.165.7]) id QQowyl18564 for ; Sat, 12 Jul 2003 00:52:50 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Jul 2003 17:52:50 -0700 Received: from 64.47.48.10 by sea2fd.sea2.hotmail.msn.com with HTTP; Sat, 12 Jul 2003 00:52:49 GMT X-Originating-IP: [64.47.48.10] X-Originating-Email: [san_101@hotmail.com] From: "Sandeep B" To: mpls@UU.NET Subject: LSP hierarchy draft Date: Sat, 12 Jul 2003 00:52:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2003 00:52:50.0077 (UTC) FILETIME=[EAFE9CD0:01C3480F] Sender: owner-mpls@UU.NET Precedence: bulk To the authors - Kireeti and Yakov, This draft has been expired for over an year now. Is there any plan to release a new version? http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-08.txt Thanks, Sandeep _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-mpls@UU.NET Mon Jul 14 19:19:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04547 for ; Mon, 14 Jul 2003 19:19:50 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjh05704 for ; Mon, 14 Jul 2003 23:19:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjh05318; Mon, 14 Jul 2003 23:19:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxik01071 for mpls-outgoing; Mon, 14 Jul 2003 17:40:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxik01063 for ; Mon, 14 Jul 2003 17:40: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 QQoxik04929 for ; Mon, 14 Jul 2003 17:39:12 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxik12287 for ; Mon, 14 Jul 2003 17:39:11 GMT Received: from auemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQoxik12275 for ; Mon, 14 Jul 2003 17:39:11 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EHd7517881 for ; Mon, 14 Jul 2003 12:39:08 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 19:39:03 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502017554@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: draft-ietf-mpls-lsr-mib-11.txt Date: Mon, 14 Jul 2003 19:38:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I get these problems pointed out: $ /bin/checkpage.awk < draft-ietf-mpls-lsr-mib-11.txt Long line at 4 with 73 chars, only spaces extra Long page at 59 Long line at 2591 with 108 chars Long line at 2624 with 106 chars Long line at 3048 with 73 chars Long page at 3303 -: 4 lines longer than 72 characters, max 108 -: 2 pages longer than 58 lines, max 60 lines The long line at lines 2591 and 2624 cause SMICng compile error: E: f(mplslsr.mi2), (1737,4) Syntax error After I fix the above I get: W: f(mplslsr.mi2), (1569,1) Row "mplsInSegmentMapEntry" has indexing that may create variables with more than 128 sub-ids For that you need to add some text to warn implementers that they should make sure such does not happen. You can take a look at draft-ietf-sigtran-sctp-mib-10.txt and search for string "128" to see an example of what type of text needs to be added. Thanks, Bert From owner-mpls@UU.NET Mon Jul 14 19:20:15 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04583 for ; Mon, 14 Jul 2003 19:20:14 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjh06564 for ; Mon, 14 Jul 2003 23:20:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjh06434; Mon, 14 Jul 2003 23:20:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxik01096 for mpls-outgoing; Mon, 14 Jul 2003 17:40:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxik01088 for ; Mon, 14 Jul 2003 17:40: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 QQoxik01031 for ; Mon, 14 Jul 2003 17:39:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxik27882 for ; Mon, 14 Jul 2003 17:39:08 GMT Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQoxik27870 for ; Mon, 14 Jul 2003 17:39:08 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EHd4517857 for ; Mon, 14 Jul 2003 12:39:05 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 19:39:03 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502017555@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: draft-ietf-mpls-ldp-mib-12.txt Date: Mon, 14 Jul 2003 19:38:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I find the below. RFC-Editor can (and probably will) fix that. But since it is in MIB module itself, there is the risk of causing later syntax errors that we then have to fix. So best to try and not exceed col 72 if another rev is done. $ /bin/checkpage.awk < draft-ietf-mpls-ldp-mib-12.txt Long line at 875 with 73 chars Long line at 2639 with 73 chars Long line at 2817 with 73 chars Long line at 3683 with 75 chars Long line at 3703 with 76 chars Long line at 3704 with 73 chars Long line at 3712 with 76 chars Long line at 3718 with 78 chars Long line at 3733 with 75 chars Long line at 3745 with 78 chars Long line at 3778 with 77 chars Long line at 3779 with 76 chars Long line at 3780 with 75 chars Long line at 3781 with 77 chars Long line at 3783 with 75 chars Long line at 3785 with 73 chars Long line at 3786 with 74 chars Long line at 3787 with 73 chars Long line at 3788 with 76 chars Long line at 3789 with 75 chars Long line at 3795 with 78 chars Long line at 4604 with 76 chars Long line at 4620 with 76 chars Long line at 4625 with 78 chars Long line at 4638 with 73 chars Long line at 4639 with 75 chars Long line at 4646 with 73 chars Long line at 4652 with 78 chars Long line at 4677 with 73 chars Long line at 4678 with 78 chars Long line at 4684 with 77 chars Long line at 4685 with 73 chars Long line at 4687 with 75 chars Long line at 4688 with 74 chars Long line at 4690 with 74 chars Long line at 4692 with 76 chars Long line at 4693 with 75 chars Long line at 4694 with 76 chars Long line at 4700 with 78 chars Long line at 4860 with 78 chars -: 40 lines longer than 72 characters, max 78 Thanks, Bert From owner-mpls@UU.NET Mon Jul 14 22:50:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22564 for ; Mon, 14 Jul 2003 22:50:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjv05300 for ; Tue, 15 Jul 2003 02:50:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjv05024; Tue, 15 Jul 2003 02:50:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxio24023 for mpls-outgoing; Mon, 14 Jul 2003 18:41:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxio24018 for ; Mon, 14 Jul 2003 18:41: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 QQoxio06711 for ; Mon, 14 Jul 2003 18:40:53 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxio07737 for ; Mon, 14 Jul 2003 18:40:53 GMT Received: from maildev.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxio07732 for ; Mon, 14 Jul 2003 18:40:52 GMT Received: from aatlas-lt2.avici.com ([10.2.103.26]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6EIee324900; Mon, 14 Jul 2003 14:40:41 -0400 (EDT) Message-Id: <5.1.0.14.2.20030714143606.01ba18f8@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Jul 2003 14:42:59 -0400 To: Terry Lee From: Alia Atlas Subject: Re: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Cc: "'mpls@uu.net'" In-Reply-To: <000001c349ce$fa5b8ba0$d9226e0a@HUAWEI.COM> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 02:12 AM 7/14/2003, Terry Lee wrote:

1.       DETOUR object s Class is TBD, Why?

I believe that we're awaiting a number to be assigned by IANA.

2.       should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes.

No, it's not necessary.

3.       in facility technique, a backup tunnel can protected many LSP. Say LSP1and LSP2 in different SESSION. What

the FRR backup tunnel s SESSION should be?

The bypass tunnel used in the facility method can have whatever SESSION, SENDER_TEMPLATE, etc., objects.  The bypass tunnel's LSP is set up exactly the same as any other primary LSP; the only difference is how the ingress chooses to use it.

In draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt:

Thus, the only field in the SESSION and SENDER_TEMPLATE objects which could be varied between

a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE.

That is for the path messages for the detours.

Alia
From owner-mpls@UU.NET Mon Jul 14 22:55:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22803 for ; Mon, 14 Jul 2003 22:55:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjv14628 for ; Tue, 15 Jul 2003 02:55:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjv14219; Tue, 15 Jul 2003 02:54:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxis16533 for mpls-outgoing; Mon, 14 Jul 2003 19:33:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxis16513 for ; Mon, 14 Jul 2003 19:33: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 QQoxis21387 for ; Mon, 14 Jul 2003 19:31:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxis18374 for ; Mon, 14 Jul 2003 19:31:33 GMT Received: from maildev.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxis18367 for ; Mon, 14 Jul 2003 19:31:32 GMT Received: from aatlas-lt2.avici.com ([10.2.103.26]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6EJVD300436; Mon, 14 Jul 2003 15:31:14 -0400 (EDT) Message-Id: <5.1.0.14.2.20030714153201.01c593c8@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Jul 2003 15:33:33 -0400 To: From: Alia Atlas Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Cc: "'Terry Lee'" , , "'prabakarts'" In-Reply-To: <000201c34a25$8fdbd4e0$2407080a@future.futsoft.com> References: <000001c349ce$fa5b8ba0$d9226e0a@HUAWEI.COM> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk
2.       should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes.
[PrabakarTS]  Yes, you are correct.

I may have misunderstood your question earlier.  If you mean should the DETOUR object be included in the Path message sent from the head-end LSP for the detour LSP (as opposed to the primary LSP), then yes, absolutely.

Alia
From owner-mpls@UU.NET Mon Jul 14 23:29:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25207 for ; Mon, 14 Jul 2003 23:29:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjx24478 for ; Tue, 15 Jul 2003 03:29:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjx24283; Tue, 15 Jul 2003 03:29:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxjp02948 for mpls-outgoing; Tue, 15 Jul 2003 01:25:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxjp02943 for ; Tue, 15 Jul 2003 01:25: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 QQoxjp00674 for ; Tue, 15 Jul 2003 01:25:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjp06559 for ; Tue, 15 Jul 2003 01:25:12 GMT Received: from mta0.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQoxjp06483 for ; Tue, 15 Jul 2003 01:25:08 GMT Received: from l20711 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HI100F16L75OW@mta0.huawei.com> for mpls@UU.NET; Tue, 15 Jul 2003 09:23:33 +0800 (CST) Date: Tue, 15 Jul 2003 09:25:10 +0800 From: Terry Lee Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt In-reply-to: <5.1.0.14.2.20030714143606.01ba18f8@mailhost.avici.com> To: "'Alia Atlas'" , Prabakaran T Sampath Cc: "'mpls@uu.net'" , Terry Lee Message-id: <000001c34a6f$efe51960$d9226e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_9y4G4SdRVIZh+LYccDAp3w)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_9y4G4SdRVIZh+LYccDAp3w) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Thanks a lot. I have another question. In section 6.4, it states as following : 6.4 Signaling for Facility Protection A PLR may use one or more bypass tunnels to protect against the failure of a link and/or a node. These bypass tunnels may be setup in advance or may be dynamically created as new protected LSPs are signaled. My question is how to create the bypass tunnels dynamically? how do the LSRs in the protected path know to be PLR and to create bypass tunnel with what attributes like destionation etc. --Boundary_(ID_9y4G4SdRVIZh+LYccDAp3w) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT 邮件
Thanks a lot.
 
I have another question. In section 6.4, it states as following :
 
   6.4 Signaling for Facility Protection
  
      A PLR may use one or more bypass tunnels to protect against the
      failure of a link and/or a node.  These bypass tunnels may be
      setup in advance or may be dynamically created as new protected
      LSPs are signaled.
 
My question is how to create the bypass tunnels dynamically?
how do the LSRs in the protected path know to be PLR and to create bypass tunnel with what attributes like destionation etc.
--Boundary_(ID_9y4G4SdRVIZh+LYccDAp3w)-- From owner-mpls@UU.NET Mon Jul 14 23:29:52 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25340 for ; Mon, 14 Jul 2003 23:29:52 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjx27642 for ; Tue, 15 Jul 2003 03:29:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjx27455; Tue, 15 Jul 2003 03:29:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxju26383 for mpls-outgoing; Tue, 15 Jul 2003 02:31:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxju26248 for ; Tue, 15 Jul 2003 02:31: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 QQoxju19344 for ; Tue, 15 Jul 2003 02:30:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxju03828 for ; Tue, 15 Jul 2003 02:30:43 GMT Received: from mailsrv01.vasw by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.lopsys.com [209.183.201.132]) id QQoxju03810 for ; Tue, 15 Jul 2003 02:30:42 GMT Received: by mailsrv01.vasw with Internet Mail Service (5.5.2653.19) id <3QX20XYK>; Mon, 14 Jul 2003 22:28:56 -0400 Message-ID: <35800AB26A91D711A75D00B0D07935F30389D3@mailsrv01.vasw> From: Michael Mandelberg To: mpls@UU.NET Subject: RSVP_HOP Question Date: Mon, 14 Jul 2003 22:28:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34A78.D46E3870" 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_01C34A78.D46E3870 Content-Type: text/plain; charset="iso-8859-1" This question has some overlap with GMPLS, but I'm hoping this is still an appropriate place to ask it (if not, I'll redirect it). I am a bit confused about the usage of the Logical Interface Handle in the RSVP_HOP object. My understanding of the LIH is that it helps the sender of the PATH message to attach the RESERVE message to the correct "Logical Interface". Now in GMPLS there is defined an IF_ID RSVP_HOP object. In addition to the LIH, it includes TLVs which contain an IP address, and an Interface ID. My question is, what relationship, if any, exists between the LIH in the RSVP_HOP and the Interface ID in the TLV contained within the RSVP_HOP? My references are rfc 2205 top of page 50, and rfc 3471 page 26. Thanks Michael Mandelberg ------_=_NextPart_001_01C34A78.D46E3870 Content-Type: text/html; charset="iso-8859-1"
This question has some overlap with GMPLS, but I'm hoping this is still an appropriate place to ask it (if not, I'll redirect it).
 
I am a bit confused about the usage of the Logical Interface Handle in the RSVP_HOP object. My understanding of the LIH is that it helps the sender of the PATH message to attach the RESERVE message to the correct "Logical Interface". Now in GMPLS there is defined an IF_ID RSVP_HOP object. In addition to the LIH, it includes TLVs which contain an IP address, and an Interface ID.
 
My question is, what relationship, if any, exists between the LIH in the RSVP_HOP and the Interface ID in the TLV contained within the RSVP_HOP?
 
My references are rfc 2205 top of page 50, and rfc 3471 page 26.
 
 
Thanks
 
Michael Mandelberg
 
 
 
------_=_NextPart_001_01C34A78.D46E3870-- From owner-mpls@UU.NET Tue Jul 15 00:29:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00461 for ; Tue, 15 Jul 2003 00:29:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkb20227 for ; Tue, 15 Jul 2003 04:29:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxkb19907; Tue, 15 Jul 2003 04:29:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxju26383 for mpls-outgoing; Tue, 15 Jul 2003 02:31:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxju26248 for ; Tue, 15 Jul 2003 02:31: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 QQoxju19344 for ; Tue, 15 Jul 2003 02:30:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxju03828 for ; Tue, 15 Jul 2003 02:30:43 GMT Received: from mailsrv01.vasw by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.lopsys.com [209.183.201.132]) id QQoxju03810 for ; Tue, 15 Jul 2003 02:30:42 GMT Received: by mailsrv01.vasw with Internet Mail Service (5.5.2653.19) id <3QX20XYK>; Mon, 14 Jul 2003 22:28:56 -0400 Message-ID: <35800AB26A91D711A75D00B0D07935F30389D3@mailsrv01.vasw> From: Michael Mandelberg To: mpls@UU.NET Subject: RSVP_HOP Question Date: Mon, 14 Jul 2003 22:28:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34A78.D46E3870" 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_01C34A78.D46E3870 Content-Type: text/plain; charset="iso-8859-1" This question has some overlap with GMPLS, but I'm hoping this is still an appropriate place to ask it (if not, I'll redirect it). I am a bit confused about the usage of the Logical Interface Handle in the RSVP_HOP object. My understanding of the LIH is that it helps the sender of the PATH message to attach the RESERVE message to the correct "Logical Interface". Now in GMPLS there is defined an IF_ID RSVP_HOP object. In addition to the LIH, it includes TLVs which contain an IP address, and an Interface ID. My question is, what relationship, if any, exists between the LIH in the RSVP_HOP and the Interface ID in the TLV contained within the RSVP_HOP? My references are rfc 2205 top of page 50, and rfc 3471 page 26. Thanks Michael Mandelberg ------_=_NextPart_001_01C34A78.D46E3870 Content-Type: text/html; charset="iso-8859-1"
This question has some overlap with GMPLS, but I'm hoping this is still an appropriate place to ask it (if not, I'll redirect it).
 
I am a bit confused about the usage of the Logical Interface Handle in the RSVP_HOP object. My understanding of the LIH is that it helps the sender of the PATH message to attach the RESERVE message to the correct "Logical Interface". Now in GMPLS there is defined an IF_ID RSVP_HOP object. In addition to the LIH, it includes TLVs which contain an IP address, and an Interface ID.
 
My question is, what relationship, if any, exists between the LIH in the RSVP_HOP and the Interface ID in the TLV contained within the RSVP_HOP?
 
My references are rfc 2205 top of page 50, and rfc 3471 page 26.
 
 
Thanks
 
Michael Mandelberg
 
 
 
------_=_NextPart_001_01C34A78.D46E3870-- From owner-mpls@UU.NET Tue Jul 15 01:07:39 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03787 for ; Tue, 15 Jul 2003 01:07:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjw18977; Tue, 15 Jul 2003 03:13:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxit18157 for mpls-outgoing; Mon, 14 Jul 2003 19:54:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxit18145 for ; Mon, 14 Jul 2003 19:54: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 QQoxit06036 for ; Mon, 14 Jul 2003 19:53:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxit24341 for ; Mon, 14 Jul 2003 19:53:49 GMT Received: from sj-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-4.cisco.com [171.68.223.138]) id QQoxit24325 for ; Mon, 14 Jul 2003 19:53:48 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6EJrhpr006886 for ; Mon, 14 Jul 2003 12:53:46 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAQ51873; Mon, 14 Jul 2003 15:53:42 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6EJrga06186 for mpls@uu.net; Mon, 14 Jul 2003 15:53:42 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxit18113 for ; Mon, 14 Jul 2003 19:53:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxit27243 for ; Mon, 14 Jul 2003 19:51:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxit25833 for ; Mon, 14 Jul 2003 19:51:33 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQoxit25809 for ; Mon, 14 Jul 2003 19:51:32 GMT Received: from juniper.net (lookout.juniper.net [172.17.20.54]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6EJoqu98650; Mon, 14 Jul 2003 12:50:52 -0700 (PDT) (envelope-from dhg@juniper.net) Message-Id: <200307141950.h6EJoqu98650@merlot.juniper.net> To: Ping Pan cc: Nic Neate , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" , "'mpls@uu.net'" Subject: Re: Suggested improvements to the Path-Specific merge rules in draft- ietf-mpls-rsvp-lsp-fastreroute-03 In-reply-to: Your message of Sun, 13 Jul 2003 14:46:13 -0700. <3F11D325.8070508@cs.columbia.edu> Date: Mon, 14 Jul 2003 12:50:52 -0700 From: Der-Hwa Gan Sender: owner-mpls@UU.NET Precedence: bulk Hi Ping, > Nic, > > Very sorry about the repeated delay, for I have been overwhelmed by > other projects lately. > > > Der-Hwa, > > Please see below: > > Der-Hwa Gan wrote: > >>A. I believe LSRs will never want to merge multiple Path messages for the > >>protected LSP. > >> > >>The merge rules 3 and 5 in section 7.1.2 ("If only one Path message contains > >>a FAST_REROUTE object ..." and "If several candidates still remain ... > >>prefer ones with FAST_REROUTE object") imply that we may be merging multiple > >>Paths for the protected LSP. Certainly if an upstream node is changing the > >>route (doing a slow reroute), or just behaving badly, then we may receive > >>multiple Paths for the protected LSP, but in both these cases we should > >>reject all but one before we merge with any other detour Paths. > >> > >>Does anyone know of a reason why an LSR may ever want to merge multiple > >>protected Path messages? > > > > > > It is possible that an implementation may want to keep all versions of > > the protected Path message when LSP rerouting itself. It should be a transient > > situation, and the situation will resolve itself when some of the Path > > messages times out, leaving just one Path message as the only viable one. > > > > Exactly. I thought all copies were needed to handle some corner cases. This is probably an implementation decision, not mandated by the spec. > > > > >> - Modifying the final merge rule as suggested at the top: > > > > > > I think the simplified merging rule should work fine, and is easier to > > read and understand. I don't know what is the opinion of other authors > > of the draft. Can this change be incorporated, or will this cause > > any problems? I have to ask because I am not the editor of the draft. > > > > I have no problem of changing the rule as long as it will work with the > existing implementations. My fear is that the changes due to the > simplification may cause inter-op problems in the future. If you don't > think there is any, please send us the new wording. If we take a look at rule 2 - 6, all they try to do is to identify the protected LSP from a set of Path messages that contain all possible mutations of FAST_REROUTE and/or DETOUR objects. And the rules look confusing because they assume the worst possible case situations. 2. If one LSP is originated from this node, this must be the final LSP. Quit. 3. If only one Path message contains FAST_REROUTE object, this becomes the chosen Path message. Quit. 4. If there are several LSPs, and not all of them have a DETOUR object, then eliminate those with DETOUR from consideration. 5. If several candidates remain (that is, there are both detour and protected LSPs), prefer the ones with FAST_REROUTE object. 6. If none found, prefer the ones without DETOUR object. If none found, prefer the ones with DETOUR object. I think some simplification is possible, if we simply suggest the guidelines (but not the details) of finding the protected LSP. As long as protected LSP(s) are preferred over detours, there should not be inter-op problems. 1. If only one of the Path messages is for the protected LSP (a protected LSP is one originated from this node, or with the FAST_REROUTE object, or without the DETOUR object) then this becomes the chosen Path message. Quit. 2. If more than one protected LSPs found, eliminate detours (those with the DETOUR object) from consideration. 3. From the remaining set of Path messages, eliminate from consideration any that traverse nodes that others want to avoid. 4. If several still remain, it is a local decision to choose which one to forward. This way, 1 & 2 replace the original rule 2-6. The original rule 1 becomes 3, and the original rule 7 becomes 4. The benefits are (a) it is more readable, (b) implementations for rule 1&2 can be quite simple if the worst case situations (suggested in original 2-6) won't exist in that implementation. Will this look ok to all? Thanks, Der-Hwa > > Thanks! > > - Ping > > > Thanks, > > Der-Hwa Gan > > > From owner-mpls@UU.NET Tue Jul 15 03:08:30 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27627 for ; Tue, 15 Jul 2003 03:08:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkm00817 for ; Tue, 15 Jul 2003 07:08:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxkm00623; Tue, 15 Jul 2003 07:08:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkk28669 for mpls-outgoing; Tue, 15 Jul 2003 06:41:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxkk28664 for ; Tue, 15 Jul 2003 06:41:30 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 QQoxkk24211 for ; Tue, 15 Jul 2003 06:41:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkk26485 for ; Tue, 15 Jul 2003 06:41:19 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 QQoxkk26471 for ; Tue, 15 Jul 2003 06:41:18 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6F6fNP07010 for ; Tue, 15 Jul 2003 01:41:24 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 08:41:14 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502017584@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: draft-ietf-mpls-tc-mib-08.txt Date: Tue, 15 Jul 2003 08:41:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Whne I SYNTAX check (with SMICNG strict checking) I get: E: f(mplste.mi2), (217,7) Index item "mplsTunnelInstance" must be defined with syntax that includes a range E: f(mplste.mi2), (218,7) Index item "mplsTunnelIngressLSRId" must be defined with syntax that includes a range E: f(mplste.mi2), (219,7) Index item "mplsTunnelEgressLSRId" must be defined with syntax that includes a range This is causes by the TCs used as SYNTAX for these index objects The TCs are in the MPLS-TC mib module. It would be best to add a range to those TCs in the TC MIB. See bottom of page 12 and top of page 13 in draft-ietf-ops-mib-review-guidelines-01.txt Bert From owner-mpls@UU.NET Tue Jul 15 03:37:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29506 for ; Tue, 15 Jul 2003 03:37:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxjm19155 for ; Tue, 15 Jul 2003 00:44:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxjm18846; Tue, 15 Jul 2003 00:43:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxil01741 for mpls-outgoing; Mon, 14 Jul 2003 17:52:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxil01732 for ; Mon, 14 Jul 2003 17:52:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxil18957 for ; Mon, 14 Jul 2003 17:51:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxil08988 for ; Mon, 14 Jul 2003 17:51:16 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQoxil08977 for ; Mon, 14 Jul 2003 17:51:16 GMT Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3C88QWCA; Mon, 14 Jul 2003 13:51:15 -0400 Message-Id: <5.2.0.9.0.20030714125815.01e3a468@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 14 Jul 2003 13:49:58 -0400 To: Kireeti Kompella , mpls@UU.NET From: Mark Duffy Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-mtu-extensions-01.txt In-Reply-To: <20030709081340.C75891@kummer.juniper.net> References: <5.2.0.9.0.20030707174919.01e619b0@email> <5.2.0.9.0.20030707174919.01e619b0@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > > This information is sufficient for a set of LSRs > > > along the path followed by an LSP to discover either the exact MTU > > > for that LSP, or an approximation which is no worse than could be > > > generated with local information on the ingress LSR. > > > > [md] How do we define "no worse"? I'd suggest that it should mean the > > procedure is not more likely to discover an LSP MTU value that is higher > > than the actual value. > >Basically, the path MTU discovery problem is to take the min of a set >of values (those values being the MTUs of the involved links). If some >of those values are missing, the best you can do ("no worse") is to >take the min of the values you *do* have. As you point out, this can >be too large. (See below also.) [snip] Hi Kireeti, and thanks for responding. Sorry about the delay in getting back to you. I think the basic question is, what is the right thing to do when some of the Hop MTUs are missing (e.g. because the LSR upstream of the hop does not support the MTU signalling extensions). Just to summarize the lengthy section I snipped... As written, (as you point out above) the scheme calculates and uses the min of the values it does have. This is per the [U=1, F=1] mode of LDP. The alternative would be to use a [U=1, F=0] LDP behavior. The benefit here of F=1 is that you can get some use out of the scheme even though not all LSRs in the path are supporting it. This is especially important for a feature such as this that is being added late in the game. The benefit of F=0 is that when the scheme is missing necessary information, it tells the affected upstream LSRs that it failed, rather than telling them a possiblly incorrect value. This would alert the upstream LSRs to use a different strategy; perhaps using a known-conservative MTU value. I suppose I agree with you that given a choice between the two, the first way (F=1) is better. I think is is possible to get the best of BOTH by using another, separate TLV that is originated by the egress LSR only, and passed with U=1, F=0, that tests the continuity of support for the MTU discovery. Then LSRs would learn an MTU for the downstream portion of the LSP, as well as learning whether that MTU was based on all Hop MTUs or just a subset of them. What do you think? Worthwhile or not worth the extra complexity? Mark From owner-mpls@UU.NET Tue Jul 15 14:00:57 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28083 for ; Tue, 15 Jul 2003 14:00:57 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxme10597 for ; Tue, 15 Jul 2003 18:00:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxme10043; Tue, 15 Jul 2003 18:00:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxks14710 for mpls-outgoing; Tue, 15 Jul 2003 08:37:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxks14699 for ; Tue, 15 Jul 2003 08:37:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxks09311 for ; Tue, 15 Jul 2003 08:36:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxks01578 for ; Tue, 15 Jul 2003 08:36:48 GMT Received: from maildev.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxks00329 for ; Tue, 15 Jul 2003 08:36:20 GMT Received: from aatlas-lt2.avici.com ([10.2.103.23]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6F8Zm329641; Tue, 15 Jul 2003 04:35:48 -0400 (EDT) Message-Id: <5.1.0.14.2.20030715040736.01ba24c0@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Jul 2003 04:38:11 -0400 To: Terry Lee From: Alia Atlas Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Cc: Prabakaran T Sampath , "'mpls@uu.net'" In-Reply-To: <000001c34a6f$efe51960$d9226e0a@HUAWEI.COM> References: <5.1.0.14.2.20030714143606.01ba18f8@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 09:25 PM 7/14/2003, Terry Lee wrote:
Thanks a lot.
 
I have another question. In section 6.4, it states as following :
 
   6.4 Signaling for Facility Protection
 
      A PLR may use one or more bypass tunnels to protect against the
      failure of a link and/or a node.  These bypass tunnels may be
      setup in advance or may be dynamically created as new protected
      LSPs are signaled.
 
My question is how to create the bypass tunnels dynamically?
how do the LSRs in the protected path know to be PLR and to create bypass tunnel with what attributes like destionation etc.

An LSR knows that it needs to determine a backup because it is a PLR based upon the signaling of the FAST_REROUTE object or SESSION flags.

In the same way that a PLR can dynamically create a detour which meets its needs, a PLR could create a bypass tunnel to use instead.  This, naturally, complicates the decision of whether to select an existing bypass tunnel or create a new one.

Alia
From owner-mpls@UU.NET Tue Jul 15 14:20:22 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28470 for ; Tue, 15 Jul 2003 14:20:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmf02759 for ; Tue, 15 Jul 2003 18:20:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxmf02582; Tue, 15 Jul 2003 18:20:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkv06947 for mpls-outgoing; Tue, 15 Jul 2003 09:22:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxkv06936 for ; Tue, 15 Jul 2003 09:21: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 QQoxkv14689 for ; Tue, 15 Jul 2003 09:20:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkv18658 for ; Tue, 15 Jul 2003 09:20:55 GMT Received: from maildev.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxkv18654 for ; Tue, 15 Jul 2003 09:20:54 GMT Received: from aatlas-lt2.avici.com ([10.2.103.23]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6F9Ka302879; Tue, 15 Jul 2003 05:20:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20030715050153.02f75008@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Jul 2003 05:22:58 -0400 To: Terry Lee From: Alia Atlas Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Cc: "'Prabakaran T Sampath'" , "'mpls@uu.net'" In-Reply-To: <000501c34aad$8d01aa00$d9226e0a@HUAWEI.COM> References: <5.1.0.14.2.20030715040736.01ba24c0@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 04:46 AM 7/15/2003, Terry Lee wrote:
An LSR knows that it needs to determine a backup because it is a PLR based upon the signaling of the FAST_REROUTE object or SESSION flags.
[Terry Lee] Then every LSR along the path will attempt to create a backup tunnel with the destionation that is possible. Am I right?

That is the essence of local protection.  There needs to be a backup path available at every PLR in case of a failure so that no signaling need occur in order to repair the traffic to provide very fast rerouting.

Alia


From owner-mpls@UU.NET Tue Jul 15 14:21:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28504 for ; Tue, 15 Jul 2003 14:21:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmf04949 for ; Tue, 15 Jul 2003 18:21:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxmf04419; Tue, 15 Jul 2003 18:20:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkr14216 for mpls-outgoing; Tue, 15 Jul 2003 08:28:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxkr14204 for ; Tue, 15 Jul 2003 08:28: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 QQoxkr13864 for ; Tue, 15 Jul 2003 08:27:34 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkr11315 for ; Tue, 15 Jul 2003 08:27:34 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoxkr11303 for ; Tue, 15 Jul 2003 08:27:33 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6F8RTuD008249 for ; Tue, 15 Jul 2003 01:27:30 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAQ94114; Tue, 15 Jul 2003 04:27:29 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6F8RTY15316 for mpls@uu.net; Tue, 15 Jul 2003 04:27:29 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxkr13686 for ; Tue, 15 Jul 2003 08:17:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoxkq14324 for ; Tue, 15 Jul 2003 08:14:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkq18300 for ; Tue, 15 Jul 2003 08:14:24 GMT Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxkq18285 for ; Tue, 15 Jul 2003 08:14:23 GMT Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 01:13:38 -0700 Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6F8EJAi020066; Tue, 15 Jul 2003 04:14:20 -0400 (EDT) Received: from tnadeauw2k (ams-clip-vpn-dhcp4359.cisco.com [10.61.81.6]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h6F8Dh224158; Tue, 15 Jul 2003 04:13:43 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'Mpls \(E-mail\)'" Subject: RE: draft-ietf-mpls-tc-mib-08.txt Date: Tue, 15 Jul 2003 04:13:12 -0400 Organization: Cisco Systems Message-ID: <009601c34aa8$ff360f80$44d9a051@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502017584@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Will fix, and will re-publish a draft as soon as the I-D repository opens. --Tom > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Wijnen, Bert (Bert) > Sent: Tuesday, July 15, 2003 2:41 AM > To: Mpls (E-mail) > Subject: draft-ietf-mpls-tc-mib-08.txt > > > Whne I SYNTAX check (with SMICNG strict checking) I get: > > E: f(mplste.mi2), (217,7) Index item "mplsTunnelInstance" > must be defined with syntax that includes a range > E: f(mplste.mi2), (218,7) Index item "mplsTunnelIngressLSRId" > must be defined with syntax that includes a range > E: f(mplste.mi2), (219,7) Index item "mplsTunnelEgressLSRId" > must be defined with syntax that includes a range > > This is causes by the TCs used as SYNTAX for these index > objects The TCs are in the MPLS-TC mib module. It would be > best to add a range to those TCs in the TC MIB. > > See bottom of page 12 and top of page 13 in > draft-ietf-ops-mib-review-guidelines-01.txt > > Bert > From owner-mpls@UU.NET Tue Jul 15 14:24:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28586 for ; Tue, 15 Jul 2003 14:24:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmf11250 for ; Tue, 15 Jul 2003 18:24:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxmf10824; Tue, 15 Jul 2003 18:23:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxku27061 for mpls-outgoing; Tue, 15 Jul 2003 09:02:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxku27049 for ; Tue, 15 Jul 2003 09:02:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxku09021 for ; Tue, 15 Jul 2003 09:00:54 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxku16278 for ; Tue, 15 Jul 2003 09:00:54 GMT Received: from sj-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-4.cisco.com [171.68.223.138]) id QQoxku16267 for ; Tue, 15 Jul 2003 09:00:53 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6F90opp010156 for ; Tue, 15 Jul 2003 02:00:50 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAQ95025; Tue, 15 Jul 2003 05:00:49 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6F90mQ15521 for mpls@uu.net; Tue, 15 Jul 2003 05:00:48 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxkr13977 for ; Tue, 15 Jul 2003 08:25: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 QQoxkr00233 for ; Tue, 15 Jul 2003 08:25:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkr07305 for ; Tue, 15 Jul 2003 08:25:42 GMT Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoxkr07282 for ; Tue, 15 Jul 2003 08:25:41 GMT Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6F8PcMK012642; Tue, 15 Jul 2003 04:25:38 -0400 (EDT) Received: from tnadeauw2k (ams-clip-vpn-dhcp4359.cisco.com [10.61.81.6]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h6F8Pb224408; Tue, 15 Jul 2003 04:25:37 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'Mpls \(E-mail\)'" Subject: RE: draft-ietf-mpls-lsr-mib-11.txt Date: Tue, 15 Jul 2003 04:25:32 -0400 Organization: Cisco Systems Message-ID: <00a501c34aaa$ac3e0fb0$44d9a051@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502017554@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Wijnen, Bert (Bert) > Sent: Monday, July 14, 2003 1:39 PM > To: Mpls (E-mail) > Subject: draft-ietf-mpls-lsr-mib-11.txt > > > I get these problems pointed out: > > $ /bin/checkpage.awk < draft-ietf-mpls-lsr-mib-11.txt > Long line at 4 with 73 chars, only spaces extra > Long page at 59 > Long line at 2591 with 108 chars > Long line at 2624 with 106 chars > Long line at 3048 with 73 chars > Long page at 3303 > -: 4 lines longer than 72 characters, max 108 > -: 2 pages longer than 58 lines, max 60 lines > > The long line at lines 2591 and 2624 cause SMICng compile error: > E: f(mplslsr.mi2), (1737,4) Syntax error > > After I fix the above I get: > W: f(mplslsr.mi2), (1569,1) Row "mplsInSegmentMapEntry" has > indexing that may create variables with more than 128 sub-ids > > For that you need to add some text to warn implementers that > they should make sure such does not happen. You can take a look at > draft-ietf-sigtran-sctp-mib-10.txt > and search for string "128" to see an example of what type of > text needs to be added. Will change and re-post with the TC MIB right after the meeting. --Tom > > Thanks, > Bert > From owner-mpls@UU.NET Tue Jul 15 15:07:43 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29935 for ; Tue, 15 Jul 2003 15:07:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmi25728 for ; Tue, 15 Jul 2003 19:07:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxmi25213; Tue, 15 Jul 2003 19:07:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkt15807 for mpls-outgoing; Tue, 15 Jul 2003 08:49:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxkt15802 for ; Tue, 15 Jul 2003 08:49: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 QQoxkt22220 for ; Tue, 15 Jul 2003 08:48:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkt29367 for ; Tue, 15 Jul 2003 08:48:54 GMT Received: from maildev.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxkt29321 for ; Tue, 15 Jul 2003 08:48:53 GMT Received: from aatlas-lt2.avici.com ([10.2.103.23]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6F8ma300231; Tue, 15 Jul 2003 04:48:37 -0400 (EDT) Message-Id: <5.1.0.14.2.20030715044703.01ba28b0@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Jul 2003 04:50:59 -0400 To: Terry Lee From: Alia Atlas Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Cc: prabakarts@future.futsoft.com, mpls@UU.NET In-Reply-To: <000001c34aab$d7a84ca0$d9226e0a@HUAWEI.COM> References: <5.1.0.14.2.20030714153201.01c593c8@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 04:34 AM 7/15/2003, Terry Lee wrote:
But in section "6.1.2. Backup Path Identification: Path-Specific", it states :
     Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
     objects as the ones used in the protected LSP. The presence of
     DETOUR object in Path messages signifies a backup path; the
     presence of FAST_REROUTE object and/or the "local protection
     requested" flag in the SESSION_ATTRIBUTE object indicates a
     protected LSP.
It seems that the protected LSP's PATH message doesn't include DETOUR object.
On the other hand, if the head-end LSR of the protected LSP doesn't include DETOUR object,
how do it control the establish the backup tunnels?

It uses the FAST_REROUTE object and/or the SESSION ATTRIBUTES flags to indicate that the LSP requires local protection.  If present, then the FAST_REROUTE object contains constraints which are applied to the backup path selection.

Alia
-----Original Message-----
From: Alia Atlas [mailto:aatlas@avici.com]
Sent: Tuesday, July 15, 2003 3:34 AM
To: prabakarts@future.futsoft.com
Cc: 'Terry Lee'; mpls@UU.NET; 'prabakarts'
Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
2.       should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes.
[PrabakarTS]  Yes, you are correct.

I may have misunderstood your question earlier.  If you mean should the DETOUR object be included in the Path message sent from the head-end LSP for the detour LSP (as opposed to the primary LSP), then yes, absolutely.

Alia

From owner-mpls@UU.NET Tue Jul 15 16:27:34 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03617 for ; Tue, 15 Jul 2003 16:27:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmn16974 for ; Tue, 15 Jul 2003 20:27:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxmn16363; Tue, 15 Jul 2003 20:27:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkt15764 for mpls-outgoing; Tue, 15 Jul 2003 08:46:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxkt15748 for ; Tue, 15 Jul 2003 08:46:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxkt15355 for ; Tue, 15 Jul 2003 08:46:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkt20410 for ; Tue, 15 Jul 2003 08:46:10 GMT Received: from mta0.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQoxkt20322 for ; Tue, 15 Jul 2003 08:46:07 GMT Received: from l20711 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HI2002255M8KX@mta0.huawei.com> for mpls@UU.NET; Tue, 15 Jul 2003 16:44:33 +0800 (CST) Date: Tue, 15 Jul 2003 16:46:14 +0800 From: Terry Lee Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt In-reply-to: <5.1.0.14.2.20030715040736.01ba24c0@mailhost.avici.com> To: "'Alia Atlas'" Cc: "'Prabakaran T Sampath'" , "'mpls@uu.net'" Message-id: <000501c34aad$8d01aa00$d9226e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_6r/ws8Et1qJXZfKl8KX4PQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_6r/ws8Et1qJXZfKl8KX4PQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Please find my comments in paragraphs [Terry Lee]. -----Original Message----- From: Alia Atlas [mailto:aatlas@avici.com] Sent: Tuesday, July 15, 2003 4:38 PM To: Terry Lee Cc: Prabakaran T Sampath; 'mpls@uu.net' Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt At 09:25 PM 7/14/2003, Terry Lee wrote: Thanks a lot. I have another question. In section 6.4, it states as following : 6.4 Signaling for Facility Protection A PLR may use one or more bypass tunnels to protect against the failure of a link and/or a node. These bypass tunnels may be setup in advance or may be dynamically created as new protected LSPs are signaled. My question is how to create the bypass tunnels dynamically? how do the LSRs in the protected path know to be PLR and to create bypass tunnel with what attributes like destionation etc. An LSR knows that it needs to determine a backup because it is a PLR based upon the signaling of the FAST_REROUTE object or SESSION flags. [Terry Lee] Then every LSR along the path will attempt to create a backup tunnel with the destionation that is possible. Am I right? In the same way that a PLR can dynamically create a detour which meets its needs, a PLR could create a bypass tunnel to use instead. This, naturally, complicates the decision of whether to select an existing bypass tunnel or create a new one. Alia --Boundary_(ID_6r/ws8Et1qJXZfKl8KX4PQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT 邮件
Hi,
Please find my comments in paragraphs [Terry Lee].
 
-----Original Message-----
From: Alia Atlas [mailto:aatlas@avici.com]
Sent: Tuesday, July 15, 2003 4:38 PM
To: Terry Lee
Cc: Prabakaran T Sampath; 'mpls@uu.net'
Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

At 09:25 PM 7/14/2003, Terry Lee wrote:
Thanks a lot.
 
I have another question. In section 6.4, it states as following :
 
   6.4 Signaling for Facility Protection
 
      A PLR may use one or more bypass tunnels to protect against the
      failure of a link and/or a node.  These bypass tunnels may be
      setup in advance or may be dynamically created as new protected
      LSPs are signaled.
 
My question is how to create the bypass tunnels dynamically?
how do the LSRs in the protected path know to be PLR and to create bypass tunnel with what attributes like destionation etc.

An LSR knows that it needs to determine a backup because it is a PLR based upon the signaling of the FAST_REROUTE object or SESSION flags.

[Terry Lee] Then every LSR along the path will attempt to create a backup tunnel with the destionation that is possible. Am I right?
In the same way that a PLR can dynamically create a detour which meets its needs, a PLR could create a bypass tunnel to use instead.  This, naturally, complicates the decision of whether to select an existing bypass tunnel or create a new one.

Alia
--Boundary_(ID_6r/ws8Et1qJXZfKl8KX4PQ)-- From owner-mpls@UU.NET Tue Jul 15 16:53:36 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04521 for ; Tue, 15 Jul 2003 16:53:36 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmp23145 for ; Tue, 15 Jul 2003 20:53:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxmp22994; Tue, 15 Jul 2003 20:53:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxks14465 for mpls-outgoing; Tue, 15 Jul 2003 08:34:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxks14460 for ; Tue, 15 Jul 2003 08:34: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 QQoxks20538 for ; Tue, 15 Jul 2003 08:34:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxks18374 for ; Tue, 15 Jul 2003 08:34:14 GMT Received: from mta0.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQoxks18300 for ; Tue, 15 Jul 2003 08:34:10 GMT Received: from l20711 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HI200MG351VB5@mta0.huawei.com> for mpls@UU.NET; Tue, 15 Jul 2003 16:32:23 +0800 (CST) Date: Tue, 15 Jul 2003 16:34:00 +0800 From: Terry Lee Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt In-reply-to: <5.1.0.14.2.20030714153201.01c593c8@mailhost.avici.com> To: "'Alia Atlas'" , prabakarts@future.futsoft.com Cc: mpls@UU.NET, "'prabakarts'" , Terry Lee Message-id: <000001c34aab$d7a84ca0$d9226e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_AJBtgJpFty0gWE/RfVLwiA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_AJBtgJpFty0gWE/RfVLwiA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT But in section "6.1.2. Backup Path Identification: Path-Specific", it states : Thus, the backup paths use the same SESSION and SENDER_TEMPLATE objects as the ones used in the protected LSP. The presence of DETOUR object in Path messages signifies a backup path; the presence of FAST_REROUTE object and/or the "local protection requested" flag in the SESSION_ATTRIBUTE object indicates a protected LSP. It seems that the protected LSP's PATH message doesn't include DETOUR object. On the other hand, if the head-end LSR of the protected LSP doesn't include DETOUR object, how do it control the establish the backup tunnels? -----Original Message----- From: Alia Atlas [mailto:aatlas@avici.com] Sent: Tuesday, July 15, 2003 3:34 AM To: prabakarts@future.futsoft.com Cc: 'Terry Lee'; mpls@UU.NET; 'prabakarts' Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 2. should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes. [PrabakarTS] Yes, you are correct. I may have misunderstood your question earlier. If you mean should the DETOUR object be included in the Path message sent from the head-end LSP for the detour LSP (as opposed to the primary LSP), then yes, absolutely. Alia --Boundary_(ID_AJBtgJpFty0gWE/RfVLwiA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT 邮件
But in section "6.1.2. Backup Path Identification: Path-Specific", it states :
     Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
     objects as the ones used in the protected LSP. The presence of
     DETOUR object in Path messages signifies a backup path; the
     presence of FAST_REROUTE object and/or the "local protection
     requested" flag in the SESSION_ATTRIBUTE object indicates a
     protected LSP.
It seems that the protected LSP's PATH message doesn't include DETOUR object.
On the other hand, if the head-end LSR of the protected LSP doesn't include DETOUR object,
how do it control the establish the backup tunnels?
-----Original Message-----
From: Alia Atlas [mailto:aatlas@avici.com]
Sent: Tuesday, July 15, 2003 3:34 AM
To: prabakarts@future.futsoft.com
Cc: 'Terry Lee'; mpls@UU.NET; 'prabakarts'
Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

2.       should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes.
[PrabakarTS]  Yes, you are correct.

I may have misunderstood your question earlier.  If you mean should the DETOUR object be included in the Path message sent from the head-end LSP for the detour LSP (as opposed to the primary LSP), then yes, absolutely.

Alia
--Boundary_(ID_AJBtgJpFty0gWE/RfVLwiA)-- From owner-mpls@UU.NET Tue Jul 15 20:12:48 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11887 for ; Tue, 15 Jul 2003 20:12:48 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxnc21527 for ; Wed, 16 Jul 2003 00:12:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxnc21368; Wed, 16 Jul 2003 00:12:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkv06706 for mpls-outgoing; Tue, 15 Jul 2003 09:18:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxkv06695 for ; Tue, 15 Jul 2003 09:18: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 QQoxkv10652 for ; Tue, 15 Jul 2003 09:17:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkv14698 for ; Tue, 15 Jul 2003 09:17:43 GMT Received: from mta1.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQoxkv14553 for ; Tue, 15 Jul 2003 09:17:36 GMT Received: from l20711 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0HI20052S6VD3U@mta1.huawei.com> for mpls@UU.NET; Tue, 15 Jul 2003 17:11:39 +0800 (CST) Date: Tue, 15 Jul 2003 17:17:40 +0800 From: Terry Lee Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt In-reply-to: <5.1.0.14.2.20030715044703.01ba28b0@mailhost.avici.com> To: "'Alia Atlas'" Cc: prabakarts@future.futsoft.com, mpls@UU.NET Message-id: <000f01c34ab1$f0f8a640$d9226e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_XXKvaWuZjW5STs1lqs5R+w)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_XXKvaWuZjW5STs1lqs5R+w) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Please find my comments in paragraphs [Terry Lee]. Terry Lee -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Alia Atlas Sent: Tuesday, July 15, 2003 4:51 PM To: Terry Lee Cc: prabakarts@future.futsoft.com; mpls@UU.NET Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt At 04:34 AM 7/15/2003, Terry Lee wrote: But in section "6.1.2. Backup Path Identification: Path-Specific", it states : Thus, the backup paths use the same SESSION and SENDER_TEMPLATE objects as the ones used in the protected LSP. The presence of DETOUR object in Path messages signifies a backup path; the presence of FAST_REROUTE object and/or the "local protection requested" flag in the SESSION_ATTRIBUTE object indicates a protected LSP. It seems that the protected LSP's PATH message doesn't include DETOUR object. On the other hand, if the head-end LSR of the protected LSP doesn't include DETOUR object, how do it control the establish the backup tunnels? It uses the FAST_REROUTE object and/or the SESSION ATTRIBUTES flags to indicate that the LSP requires local protection. If present, then the FAST_REROUTE object contains constraints which are applied to the backup path selection. [Terry Lee] Correct. My questions focus the usage of DETOUR object. does the PATH message of the head-end LSR of the protected LSP contain DETOUR object in one-to-one technique? If it does, it doesn't seem to be contrary with the statements in "The presence of DETOUR object in Path messages signifies a backup path; the presence of FAST_REROUTE object and/or the "local protection requested" flag in the SESSION_ATTRIBUTE object indicates a protected LSP." in section 6.1.2. If it doesn't, the DETOUR object seems to be paradox. Alia -----Original Message----- From: Alia Atlas [mailto:aatlas@avici.com] Sent: Tuesday, July 15, 2003 3:34 AM To: prabakarts@future.futsoft.com Cc: 'Terry Lee'; mpls@UU.NET; 'prabakarts' Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 2. should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes. [PrabakarTS] Yes, you are correct. I may have misunderstood your question earlier. If you mean should the DETOUR object be included in the Path message sent from the head-end LSP for the detour LSP (as opposed to the primary LSP), then yes, absolutely. Alia --Boundary_(ID_XXKvaWuZjW5STs1lqs5R+w) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT 邮件
 
Hi,
Please find my comments in paragraphs [Terry Lee].
 
 
 

Terry Lee

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Alia Atlas
Sent: Tuesday, July 15, 2003 4:51 PM
To: Terry Lee
Cc: prabakarts@future.futsoft.com; mpls@UU.NET
Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

At 04:34 AM 7/15/2003, Terry Lee wrote:
But in section "6.1.2. Backup Path Identification: Path-Specific", it states :
     Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
     objects as the ones used in the protected LSP. The presence of
     DETOUR object in Path messages signifies a backup path; the
     presence of FAST_REROUTE object and/or the "local protection
     requested" flag in the SESSION_ATTRIBUTE object indicates a
     protected LSP.
It seems that the protected LSP's PATH message doesn't include DETOUR object.
On the other hand, if the head-end LSR of the protected LSP doesn't include DETOUR object,
how do it control the establish the backup tunnels?

It uses the FAST_REROUTE object and/or the SESSION ATTRIBUTES flags to indicate that the LSP requires local protection.  If present, then the FAST_REROUTE object contains constraints which are applied to the backup path selection.

[Terry Lee] Correct. My questions focus the usage of DETOUR object. 
does the PATH message of the head-end LSR of the protected LSP contain DETOUR object in one-to-one technique?
If it does, it doesn't seem to be contrary with the statements in "The presence of    DETOUR object in Path messages signifies a backup path; the    presence of FAST_REROUTE object and/or the "local protection    requested" flag in the SESSION_ATTRIBUTE object indicates a    protected LSP." in section 6.1.2. 
If it doesn't,  the DETOUR object seems to be paradox.
 
Alia
-----Original Message-----
From: Alia Atlas [mailto:aatlas@avici.com]
Sent: Tuesday, July 15, 2003 3:34 AM
To: prabakarts@future.futsoft.com
Cc: 'Terry Lee'; mpls@UU.NET; 'prabakarts'
Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
2.       should DETOUR object be contained in the head-end LSR in one-by-one technique? I think the answer is yes.
[PrabakarTS]  Yes, you are correct.

I may have misunderstood your question earlier.  If you mean should the DETOUR object be included in the Path message sent from the head-end LSP for the detour LSP (as opposed to the primary LSP), then yes, absolutely.

Alia

--Boundary_(ID_XXKvaWuZjW5STs1lqs5R+w)-- From owner-mpls@UU.NET Tue Jul 15 20:56:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12787 for ; Tue, 15 Jul 2003 20:56:07 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxll12191; Tue, 15 Jul 2003 13:27:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkp22758 for mpls-outgoing; Tue, 15 Jul 2003 07:50:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxkp22753 for ; Tue, 15 Jul 2003 07:50: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 QQoxkp28673 for ; Tue, 15 Jul 2003 07:49:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkp24193 for ; Tue, 15 Jul 2003 07:49:08 GMT Received: from auemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQoxkp24173 for ; Tue, 15 Jul 2003 07:49:08 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6F7n4508471 for ; Tue, 15 Jul 2003 02:49:05 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 09:49:03 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155020175AA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: fastreoute-mib Date: Tue, 15 Jul 2003 09:48:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Since this was brought up as another WG MIB work item this morning, here is what a very quick check reveals: Need to import from MPLS-TC-STD-MIB instead of MPLS-TC-MIB SMICng syntax checks: C:\bwijnen\smicng\work>smicng fastreroute.inc E: f(fastreroute.mi2), (1,1) SMI item "Gauge32" used in MPLS-FRR-MIB, but not defined or imported E: f(fastreroute.mi2), (1,1) SMI item "TimeTicks" used in MPLS-FRR-MIB, but not defined or imported * E: f(fastreroute.mi2), (324,15) Index item "mplsFrrConstTunnelInstance" must be defined with syntax that includes a range E: f(fastreroute.mi2), (507,16) Index item "mplsFrrLogIndex" must be defined with syntax that includes a range * E: f(fastreroute.mi2), (605,15) Index item "mplsFrrOne2OnePlrTunInst" must be defined with syntax that includes a range * E: f(fastreroute.mi2), (609,15) Index item "mplsFrrOne2OnePlrDetourInstance" must be defined with syntax that includes a range * E: f(fastreroute.mi2), (763,15) Index item "mplsFrrOne2OnePlrTunInst" must be defined with syntax that includes a range * E: f(fastreroute.mi2), (887,16) Index item "mplsFrrFacRouteBkupTunInst" must be defined with syntax that includes a range Easy to fix I think. The 5 errors marked with an * are similar to the ones I posted this morning after my cjecking of LSR MIB. That is, they need a range to be added to the TCs in the MPLS-TC-STD-MIB. SO they will go away when that TC MIB is fixed. There are quite a few other concerns I think that you can easily identify if you check the document against draft-ietf-ops-mib-review-guidelines-01.txt Hope this helps as a start Bert From owner-mpls@UU.NET Tue Jul 15 21:31:25 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13346 for ; Tue, 15 Jul 2003 21:31:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxni19300 for ; Wed, 16 Jul 2003 01:31:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxni18976; Wed, 16 Jul 2003 01:31:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkv06956 for mpls-outgoing; Tue, 15 Jul 2003 09:22:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxkv06940 for ; Tue, 15 Jul 2003 09:21: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 QQoxkv15617 for ; Tue, 15 Jul 2003 09:21:27 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkv03831 for ; Tue, 15 Jul 2003 09:21:26 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQoxkv03745 for ; Tue, 15 Jul 2003 09:21:23 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 15 Jul 2003 15:00:40 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.8.7.36]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6F9Cw0r001494; Tue, 15 Jul 2003 14:42:58 +0530 Reply-To: From: "Prabakaran T Sampath" To: "'Terry Lee'" , "'Alia Atlas'" Cc: , "'Terry Lee'" Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Date: Tue, 15 Jul 2003 14:50:55 +0530 Message-Id: <001f01c34ab2$656ecc20$2407080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <000001c34a6f$efe51960$d9226e0a@HUAWEI.COM> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C34AE0.7F270820" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C34AE0.7F270820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ??Hi Terry Lee, Creating a bypass tunnel in advance and associating with the interface is a explicit thing. If we want to create a bypass tunnel dynamically during LSPs signaling means, In my understanding, it is an implementation specific, one possible way could be each PLR can create a bypass tunnels dynamically based on the RRO objects, where in we could find the exact path the LSPs traversed, using this we can make a decision for the node/link which we need to protect, using CSPF we can exclude certain link or node for establishing the bypass tunnel from PLR to MP and then associating with the Protected LSP at the PLR for FRR operation, but we also need to take care of Bandwidth protection needed flag operation while establishing bypass tunnel if it is enabled. The complexity, scalability and other issues involved in this approach need to be explored. Thanks and regards, Prabakaran T.S. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. email : prabakarts@future.futsoft.com Off Phone: +91-44-24330550 - Extn: 319 ----------------------------------------------------------- -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Terry Lee Sent: Tuesday, 15 July 2003 6:55 AM To: 'Alia Atlas'; Prabakaran T Sampath Cc: 'mpls@uu.net'; Terry Lee Subject: RE: questions about draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Thanks a lot. I have another question. In section 6.4, it states as following : 6.4 Signaling for Facility Protection A PLR may use one or more bypass tunnels to protect against the failure of a link and/or a node. These bypass tunnels may be setup in advance or may be dynamically created as new protected LSPs are signaled. My question is how to create the bypass tunnels dynamically? how do the LSRs in the protected path know to be PLR and to create bypass tunnel with what attributes like destionation etc. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0020_01C34AE0.7F270820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 邮件
Hi=20 Terry Lee,
 
Creating a bypass tunnel in advance and = associating=20 with the interface is a explicit
thing.  If we want to create a bypass = tunnel=20 dynamically during LSPs signaling means,
In my=20 understanding, it is an implementation  = specific, =20
one=20 possible way could be each PLR can create a=20 bypass tunnels dynamically
based on the  RRO = objects, where=20 in we could find the exact path the LSPs
traversed, using this we can make a decision = for the=20 node/link which we need to protect,
using=20 CSPF we can exclude certain link or node for establishing the=20 bypass
tunnel=20 from PLR to MP and then associating with the Protected LSP at the PLR = for FRR=20 operation,
but we=20 also need to take care of Bandwidth protection needed flag = operation=20
while=20 establishing bypass tunnel if it is=20 enabled. 
The complexity, = scalability and=20 other issues involved in this approach need to be = explored.
 
Thanks=20 and regards,
Prabakaran T.S.
Future=20 Software Limited,
480-481, Anna Salai,
Chennai - 600035, India.
email : prabakarts@future.futsoft.c= om
Off Phone: +91-44-24330550 - Extn: = 319
-----------------------------------------------------------  
 -----Original = Message-----
From:=20 owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Terry=20 Lee
Sent: Tuesday, 15 July 2003 6:55 AM
To: 'Alia = Atlas';=20 Prabakaran T Sampath
Cc: 'mpls@uu.net'; Terry = Lee
Subject:=20 RE: questions about=20 draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

Thanks=20 a lot.
 
I have=20 another question. In section 6.4, it states as following :=20
 
   6.4 Signaling for Facility=20 Protection
  
      A PLR may = use one=20 or more bypass tunnels to protect against=20 the
      failure of a link and/or a = node. =20 These bypass tunnels may be
      setup in = advance=20 or may be dynamically created as new=20 protected
      LSPs are=20 signaled.
 
My=20 question is how to create the bypass tunnels dynamically? =
how do=20 the LSRs in the protected path know to be PLR and to create bypass = tunnel with=20 what attributes like destionation=20 etc.
------=_NextPart_000_0020_01C34AE0.7F270820-- From owner-mpls@UU.NET Tue Jul 15 22:49:29 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14753 for ; Tue, 15 Jul 2003 22:49:28 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxnn08009 for ; Wed, 16 Jul 2003 02:49:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxnn07749; Wed, 16 Jul 2003 02:49:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxkw07378 for mpls-outgoing; Tue, 15 Jul 2003 09:30:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxkw07367 for ; Tue, 15 Jul 2003 09:30: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 QQoxkv21509 for ; Tue, 15 Jul 2003 09:28:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxkv12942 for ; Tue, 15 Jul 2003 09:28:53 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQoxkv12927 for ; Tue, 15 Jul 2003 09:28:53 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6F9SaK18830 for ; Tue, 15 Jul 2003 05:28:37 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 05:28:37 -0400 Message-ID: From: "David Allan" To: "'mpls@UU.NET'" Subject: 'A' bit problem statement Date: Tue, 15 Jul 2003 05:28:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34AB3.75991456" 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_01C34AB3.75991456 Content-Type: text/plain; charset="iso-8859-1" During today's MPLS session it was clear that more discussion/clarification was required on the problem space addressed by the I-D. There is two aspects to the problem discussed in the draft. 1) Mixing e2e path testing with adjacency fault detection has coorindation problems when failures occur. If I have an LSP hierarchy that I am pinging at some low level, and a failure occurs, some number of the pings will be affected, and a response/alarm management will be hard to synchronize as ping sources are not local to the fault (and the fault may also be detected locally, e.g. link failure). IMHO this is an artifact of the delta between using ping to reactively to check routing policy vs. using ping proactively to detect data plane failures. 2) Reserved labels define functions instead of forwarding. Fate sharing between functions and LSPs is useful. Currently ECMP breaks fate sharing between LSPs and LSP functions defined by reserved labels. The answer to #1 is to try to localize detection of data plane problems, the ability to do the equivalent of the router alert label that fate shares with the LSP is one potential mechanism that could be used to increase locality in detecting data plane problems. Specific data plane flows could be inspected for consistency by intermediate LSRs as they were forwarded down the path. The answer to #2 is to provide an alternative to reserved labels for LSP functions, the MPLS/PW PID is a candidate for doing this. The 'A' bit was one example of providing such functionality by defining a replacement for router alert. A side note is that there is a much higher liklihood of commonality of forwarding of a solution that had the label of interest as the top label vs. prepending with the router alert label. Comments? cheers Dave ------_=_NextPart_001_01C34AB3.75991456 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 'A' bit problem statement

During today's MPLS session it was clear that more = discussion/clarification was required on the problem space addressed by = the I-D.

There is two aspects to the problem discussed in the = draft.

1) Mixing e2e path testing with adjacency fault = detection has coorindation problems when failures occur. If I have an = LSP hierarchy that I am pinging at some low level, and a failure = occurs, some number of the pings will be affected, and a response/alarm = management will be hard to synchronize as ping sources are not local to = the fault (and the fault may also be detected locally, e.g. link = failure). IMHO this is an artifact of the delta between using ping to = reactively to check routing policy vs. using ping proactively to detect = data plane failures.

2) Reserved labels define functions instead of = forwarding. Fate sharing between functions and LSPs is useful. = Currently ECMP breaks fate sharing between LSPs and LSP functions = defined by reserved labels.

The answer to #1 is to try to localize detection of = data plane problems, the ability to do the equivalent of the router = alert label that fate shares with the LSP is one potential mechanism = that could be used to increase locality in detecting data plane = problems. Specific data plane flows could be inspected for consistency = by intermediate LSRs as they were forwarded down the path.

The answer to #2 is to provide an alternative to = reserved labels for LSP functions, the MPLS/PW PID is a candidate for = doing this. The 'A' bit was one example of providing such functionality = by defining a replacement for router alert. A side note is that there = is a much higher liklihood of commonality of forwarding of a solution = that had the label of interest as the top label vs. prepending = with  the router alert label.

Comments?

cheers
Dave

------_=_NextPart_001_01C34AB3.75991456-- From owner-mpls@UU.NET Wed Jul 16 01:15:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17869 for ; Wed, 16 Jul 2003 01:15:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxnx26450 for ; Wed, 16 Jul 2003 05:15:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxnw25674; Wed, 16 Jul 2003 05:14:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxlk22211 for mpls-outgoing; Tue, 15 Jul 2003 13:00:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxlk21608 for ; Tue, 15 Jul 2003 13:00:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxlk14017 for ; Tue, 15 Jul 2003 13:00:22 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxlk01223 for ; Tue, 15 Jul 2003 13:00:21 GMT Received: from sj-iport-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoxlk01208 for ; Tue, 15 Jul 2003 13:00:20 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6FD0HuG018830 for ; Tue, 15 Jul 2003 06:00:18 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR05441; Tue, 15 Jul 2003 09:00:16 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6FD0GR20057 for mpls@uu.net; Tue, 15 Jul 2003 09:00:16 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxlh15978 for ; Tue, 15 Jul 2003 12:27:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxlh03694 for ; Tue, 15 Jul 2003 12:27:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxlh14619 for ; Tue, 15 Jul 2003 12:27:07 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQoxlh14599 for ; Tue, 15 Jul 2003 12:27:06 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id <3XHLXNBM>; Tue, 15 Jul 2003 13:27:01 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80287059F@baker.datcon.co.uk> From: Nic Neate To: "'Der-Hwa Gan'" , Ping Pan Cc: "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" , "'mpls@uu.net'" Subject: RE: Suggested improvements to the Path-Specific merge rules in dr aft- ietf-mpls-rsvp-lsp-fastreroute-03 Date: Tue, 15 Jul 2003 13:26:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Ping and Der-Hwa, Thanks for your responses. You've raised the following points which I'll give you my input on below. - Der-Hwa's suggested merge rules. - Concern over interop with existing implementations. - Doubt whether failing to merge is possible. - Possibility of merging multiple protected Paths during LSP rerouting. A. Der-Hwa's suggested merge rules. My understanding of the draft is that every Path we are merging is either a protected Path (has a FAST_REROUTE object, or the "Local protection desired" bit set in SESSION_ATTRIBUTE object) or a detour Path (has a DETOUR object). This is stated by paragraph 3 of section 7.1.2 (although note that this misses out the "Local protection desired" flag option): For all Path messages that do not have either a FAST_REROUTE or a DETOUR object, or the MP is the egress of the LSP, no merging is required. The messages are processed according to [RSVP-TE]. Because that statement is there up front, I think we should just to refer to "protected Paths" and "detour Paths" in the merge rules. I've suggested some new text at the bottom. B. Will there be interop problems with existing implementations? I don't think so. The Path message forwarded by the new merge rules may have a different ERO, or be a protected Path instead of a detour. That will not matter to the downstream LSR though - it can process it in just the same way as before. Existing implementations will only need to be changed if they wish to avoid the risk of forwarding a detour Path in preference to a protected one. C. Is it possible that no received Path message is suitable for forwarding? Only in very strained network topologies (but we do have it in system test!). Merging can fail either because each detour traverses a node that another wants to avoid, or because the protected LSP traverses a node that some detours want to avoid. I think that these possibilities should be covered by the draft. D. During LSP rerouting, we may need to merge multiple protected Paths. I agree that this is a possibility. It's covered by my new suggested text below. Taking all that into account, here's my suggested text for the merge rules. For all the Path messages that share the same outgoing interface and next-hop LSR, the MP runs the following procedure to identify a Path message to forward downstream. 1. If one or more of the Path messages is for the protected LSP, one of these must become the chosen Path message. There should only be more than one in the case that the protected LSP is being rerouted. In that case it is a local decision to choose which one to forward. Quit. 2. From the remaining set of detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid. 3. If several still remain, it is a local decision to choose which one to forward. If none remain, then the MP may try and find a new route that does avoid all nodes that all merging detour Paths want to avoid and forward a Path message with that ERO. Once the final Path message has been identified, the MP MUST start to refresh it downstream periodically. Other LSPs are considered merged at this node. For bandwidth reservation on the outgoing link, any merging should be considered to have occured before bandwidth is reserved. Thus, even though Fixed Filter is specified, multiple detours and/or their protected LSP which are to be merged due to sharing an outgoing interface and next-hop LSR will reserve only the bandwidth of the final Path message on that outgoing interface. If no merged Path message can be constructed then the MP SHOULD send a PathErr in response to the most recently received detour Path message. If a protected Path is chosen to be forwarded, but it traverses nodes that some detours want to avoid, PathErrs should be sent in response to those detour Paths which cannot merge. Thanks, Nic From owner-mpls@UU.NET Wed Jul 16 01:20:10 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18014 for ; Wed, 16 Jul 2003 01:20:09 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxnx07257 for ; Wed, 16 Jul 2003 05:20:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxnx06997; Wed, 16 Jul 2003 05:20:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxll09627 for mpls-outgoing; Tue, 15 Jul 2003 13:24:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxll09617 for ; Tue, 15 Jul 2003 13:24: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 QQoxll28936 for ; Tue, 15 Jul 2003 13:24:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxll04586 for ; Tue, 15 Jul 2003 13:24:04 GMT Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxll04348 for ; Tue, 15 Jul 2003 13:23:58 GMT Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 06:23:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6FDNsuD010607 for ; Tue, 15 Jul 2003 06:23:55 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR07185; Tue, 15 Jul 2003 09:23:53 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6FDNr421010 for mpls@uu.net; Tue, 15 Jul 2003 09:23:53 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxlk07850 for ; Tue, 15 Jul 2003 13:09: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 QQoxlk17149 for ; Tue, 15 Jul 2003 13:08:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxlk12732 for ; Tue, 15 Jul 2003 13:08:57 GMT Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxlk12726 for ; Tue, 15 Jul 2003 13:08:57 GMT Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 06:08:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6FD8q8B016319; Tue, 15 Jul 2003 06:08:55 -0700 (PDT) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR06054; Tue, 15 Jul 2003 09:08:51 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA27797; Tue, 15 Jul 2003 09:08:51 -0400 (EDT) Message-Id: <200307151308.JAA27797@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Adrian Farrel" cc: mpls@UU.NET, "George Swallow" , swallow@cisco.com Subject: Re: draft-swallow-mpls-lsr-self-test-01.txt Was: MPLS WG Agenda In-reply-to: Your message of "Mon, 14 Jul 2003 07:36:43 BST." <001001c349d3$5bbbd770$78c2a051@Puppy> Date: Tue, 15 Jul 2003 09:08:51 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Sorry - the -00 version is the current version. Somehow my NROFF macros decided to put -01 in the footer which I cut and pasted in the the agenda without noticing. ...george ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-mpls@UU.NET Wed Jul 16 01:20:37 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18030 for ; Wed, 16 Jul 2003 01:20:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxnx08152 for ; Wed, 16 Jul 2003 05:20:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxnx07810; Wed, 16 Jul 2003 05:20:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxly19106 for mpls-outgoing; Tue, 15 Jul 2003 16:38:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxly19088 for ; Tue, 15 Jul 2003 16:37: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 QQoxly08646 for ; Tue, 15 Jul 2003 16:37:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxly16620 for ; Tue, 15 Jul 2003 16:37:41 GMT Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m0.netfirms.com [209.171.43.51]) id QQoxly16602 for ; Tue, 15 Jul 2003 16:37:40 GMT Received: (qmail 84681 invoked from network); 15 Jul 2003 16:37:38 -0000 Received: from puppy.ietf57.telekom.at (HELO Puppy) (81.160.194.120) by 0 with SMTP; 15 Jul 2003 16:37:38 -0000 Message-ID: <003601c34aef$67d5f460$78c2a051@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "'mpls@uu.net'" , Subject: Running out of RSVP-TE bits? Date: Tue, 15 Jul 2003 17:37:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [cross-posted to ccamp and mpls lists] Hi, After a couple of conversations today I wonder if we should worry about the way we allocate bits from the flags fields in the Session Attribute object and the RRO subobject. These flags are very rare and we need to assign them with the greatest care. Is there currently any policy for managing this resource to ensure that there will still be bits available when they are needed? Or can we simply use them on a first-come, first-served basis? Note that draft-ietf-mpls-nodeid-subobject-01.txt takes the use of the RRO subobject flag up to all but two bits used. draft-iwata-mpls-crankback-06.txt uses all of the remaining Session Attribute bits. Thanks, Adrian From owner-mpls@UU.NET Wed Jul 16 01:26:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18271 for ; Wed, 16 Jul 2003 01:26:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxnx19673 for ; Wed, 16 Jul 2003 05:26:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxnx19337; Wed, 16 Jul 2003 05:26:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxlu26265 for mpls-outgoing; Tue, 15 Jul 2003 15:35:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxlt25705 for ; Tue, 15 Jul 2003 15:23: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 QQoxlt08862 for ; Tue, 15 Jul 2003 15:21:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxlt11696 for ; Tue, 15 Jul 2003 15:21:06 GMT Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxlt11683 for ; Tue, 15 Jul 2003 15:21:05 GMT Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 08:20:24 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6FFL1uG018583 for ; Tue, 15 Jul 2003 08:21:02 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR19010; Tue, 15 Jul 2003 11:21:00 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6FFL0o07286 for mpls@uu.net; Tue, 15 Jul 2003 11:21:00 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxlq03819 for ; Tue, 15 Jul 2003 14:40: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 QQoxlq01224 for ; Tue, 15 Jul 2003 14:39:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxlq18243 for ; Tue, 15 Jul 2003 14:39:34 GMT Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxlq18226 for ; Tue, 15 Jul 2003 14:39:33 GMT Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 07:38:51 -0700 Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6FEdUAi027742; Tue, 15 Jul 2003 10:39:30 -0400 (EDT) Received: from tnadeauw2k (ams-clip-vpn-dhcp4303.cisco.com [10.61.80.206]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h6FEdT210190; Tue, 15 Jul 2003 10:39:29 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'Mpls \(E-mail\)'" Subject: RE: fastreoute-mib Date: Tue, 15 Jul 2003 10:39:22 -0400 Organization: Cisco Systems Message-ID: <000501c34ade$e5a50c20$44d9a051@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155020175AA@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the quick review. As I mentioned, I need to look over the document to align it based on the extensive comments on the base MIBs. I will look at the reference too. --Tom > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Wijnen, Bert (Bert) > Sent: Tuesday, July 15, 2003 3:49 AM > To: Mpls (E-mail) > Subject: fastreoute-mib > > > Since this was brought up as another WG MIB work item this > morning, here is what a very quick check reveals: > > Need to import from MPLS-TC-STD-MIB instead of MPLS-TC-MIB > > SMICng syntax checks: > > C:\bwijnen\smicng\work>smicng fastreroute.inc > E: f(fastreroute.mi2), (1,1) SMI item "Gauge32" used > in MPLS-FRR-MIB, but not defined or imported > E: f(fastreroute.mi2), (1,1) SMI item "TimeTicks" used > in MPLS-FRR-MIB, but not defined or imported > * E: f(fastreroute.mi2), (324,15) Index item > "mplsFrrConstTunnelInstance" must be defined with > syntax that includes a range > E: f(fastreroute.mi2), (507,16) Index item "mplsFrrLogIndex" > must be defined with syntax that includes a range > * E: f(fastreroute.mi2), (605,15) Index item > "mplsFrrOne2OnePlrTunInst" must be defined with syntax > that includes a range > * E: f(fastreroute.mi2), (609,15) Index item > "mplsFrrOne2OnePlrDetourInstance" must be defined with > syntax that includes a range > * E: f(fastreroute.mi2), (763,15) Index item > "mplsFrrOne2OnePlrTunInst" must be defined with syntax > that includes a range > * E: f(fastreroute.mi2), (887,16) Index item > "mplsFrrFacRouteBkupTunInst" must be defined with syntax > that includes a range > > Easy to fix I think. > The 5 errors marked with an * are similar to the ones I > posted this morning after my cjecking of LSR MIB. That is, > they need a range to be added to the TCs in the > MPLS-TC-STD-MIB. SO they will go away when that TC MIB is fixed. > > There are quite a few other concerns I think that you can > easily identify if you check the document against > draft-ietf-ops-mib-review-guidelines-01.txt > > Hope this helps as a start > > Bert > From owner-mpls@UU.NET Wed Jul 16 04:30:00 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20878 for ; Wed, 16 Jul 2003 04:30:00 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxok08032 for ; Wed, 16 Jul 2003 08:30:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxoj07872; Wed, 16 Jul 2003 08:29:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxmy27439 for mpls-outgoing; Tue, 15 Jul 2003 23:10:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxmy27384 for ; Tue, 15 Jul 2003 23:10: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 QQoxmy03709 for ; Tue, 15 Jul 2003 23:08:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmy22439 for ; Tue, 15 Jul 2003 23:08:53 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 QQoxmy22417 for ; Tue, 15 Jul 2003 23:08:51 GMT Received: (qmail 15607 invoked from network); 15 Jul 2003 23:08:46 -0000 Received: from newsmtp.iitb.ac.in (144.16.108.201) by mailhost.iitb.ac.in with SMTP; 15 Jul 2003 23:08:46 -0000 Received: (qmail 26866 invoked by uid 512); 15 Jul 2003 23:08:46 -0000 Received: from sivak@cse.iitb.ac.in by newsmtp by uid 509 with qmail-scanner-1.15 (clamscan: 0.54. Clear:. Processed in 0.231782 secs); 15 Jul 2003 23:08:46 -0000 Received: from jeeves.cse.iitb.ac.in ([10.105.1.1]) (envelope-sender ) by smtp.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 15 Jul 2003 23:08:45 -0000 Received: from chandra.cse.iitb.ac.in (chandra.cse.iitb.ac.in [10.105.1.7]) by jeeves.cse.iitb.ac.in (8.11.0/8.11.0) with ESMTP id h6FN8jD27537 for ; Wed, 16 Jul 2003 04:38:45 +0530 Received: (from sivak@localhost) by chandra.cse.iitb.ac.in (8.8.8/8.8.8) id EAA16221; Wed, 16 Jul 2003 04:25:00 +0530 (IST) Date: Wed, 16 Jul 2003 04:24:59 +0530 (IST) From: D Siva Kumar To: mpls@UU.NET Subject: doubt reg draft-kawakami-mpls-lsp-vlan-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a doubt regarding encapsulation mentioned in above draft in section 4. Encapsulation header is shown in the draft as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ethernet source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPID 0x8100 | Pri | | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-Type 0x0800 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Network Layer Packet (IP packet) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But, in this where is the pseudowire label? directly, payload is added after the tunnel header. Correct me if I am wrong and please point some references if any, regarding this. I am a beginner in this field. expecting a reply, thanks in advance. Siva. From owner-mpls@UU.NET Wed Jul 16 05:30:42 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23075 for ; Wed, 16 Jul 2003 05:30:42 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxoo08992 for ; Wed, 16 Jul 2003 09:30:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxoo08828; Wed, 16 Jul 2003 09:30:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxmy27439 for mpls-outgoing; Tue, 15 Jul 2003 23:10:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxmy27384 for ; Tue, 15 Jul 2003 23:10: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 QQoxmy03709 for ; Tue, 15 Jul 2003 23:08:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxmy22439 for ; Tue, 15 Jul 2003 23:08:53 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 QQoxmy22417 for ; Tue, 15 Jul 2003 23:08:51 GMT Received: (qmail 15607 invoked from network); 15 Jul 2003 23:08:46 -0000 Received: from newsmtp.iitb.ac.in (144.16.108.201) by mailhost.iitb.ac.in with SMTP; 15 Jul 2003 23:08:46 -0000 Received: (qmail 26866 invoked by uid 512); 15 Jul 2003 23:08:46 -0000 Received: from sivak@cse.iitb.ac.in by newsmtp by uid 509 with qmail-scanner-1.15 (clamscan: 0.54. Clear:. Processed in 0.231782 secs); 15 Jul 2003 23:08:46 -0000 Received: from jeeves.cse.iitb.ac.in ([10.105.1.1]) (envelope-sender ) by smtp.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 15 Jul 2003 23:08:45 -0000 Received: from chandra.cse.iitb.ac.in (chandra.cse.iitb.ac.in [10.105.1.7]) by jeeves.cse.iitb.ac.in (8.11.0/8.11.0) with ESMTP id h6FN8jD27537 for ; Wed, 16 Jul 2003 04:38:45 +0530 Received: (from sivak@localhost) by chandra.cse.iitb.ac.in (8.8.8/8.8.8) id EAA16221; Wed, 16 Jul 2003 04:25:00 +0530 (IST) Date: Wed, 16 Jul 2003 04:24:59 +0530 (IST) From: D Siva Kumar To: mpls@UU.NET Subject: doubt reg draft-kawakami-mpls-lsp-vlan-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a doubt regarding encapsulation mentioned in above draft in section 4. Encapsulation header is shown in the draft as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ethernet source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPID 0x8100 | Pri | | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-Type 0x0800 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Network Layer Packet (IP packet) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But, in this where is the pseudowire label? directly, payload is added after the tunnel header. Correct me if I am wrong and please point some references if any, regarding this. I am a beginner in this field. expecting a reply, thanks in advance. Siva. From owner-mpls@UU.NET Wed Jul 16 06:13:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23907 for ; Wed, 16 Jul 2003 06:12:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxoq27141 for ; Wed, 16 Jul 2003 10:13:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxoq27030; Wed, 16 Jul 2003 10:12:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxms14070 for mpls-outgoing; Tue, 15 Jul 2003 21:43:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxms14065 for ; Tue, 15 Jul 2003 21:43: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 QQoxms09078 for ; Tue, 15 Jul 2003 21:42:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxms08525 for ; Tue, 15 Jul 2003 21:42:25 GMT Received: from cs.columbia.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cs.columbia.edu [128.59.16.20]) id QQoxms08515 for ; Tue, 15 Jul 2003 21:42:25 GMT Received: from muni.cs.columbia.edu (muni.cs.columbia.edu [128.59.19.192]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FLg2kN008976 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 15 Jul 2003 17:42:03 -0400 (EDT) Received: from muni.cs.columbia.edu (localhost [127.0.0.1]) by muni.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FLfucq026550; Tue, 15 Jul 2003 17:41:57 -0400 (EDT) Received: from localhost (pingpan@localhost) by muni.cs.columbia.edu (8.12.9/8.12.9/Submit) with ESMTP id h6FLfjZi026546; Tue, 15 Jul 2003 17:41:45 -0400 (EDT) X-Authentication-Warning: muni.cs.columbia.edu: pingpan owned process doing -bs Date: Tue, 15 Jul 2003 17:41:44 -0400 (EDT) From: Ping Pan To: Der-Hwa Gan cc: Nic Neate , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" , "'mpls@uu.net'" Subject: Re: Suggested improvements to the Path-Specific merge rules in draft- ietf-mpls-rsvp-lsp-fastreroute-03 In-Reply-To: <200307141950.h6EJoqu98650@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 14 Jul 2003, Der-Hwa Gan wrote: > If we take a look at rule 2 - 6, all they try to do is to identify the > protected LSP from a set of Path messages that contain all possible mutations > of FAST_REROUTE and/or DETOUR objects. And the rules look confusing > because they assume the worst possible case situations. > > 2. If one LSP is originated from this node, this must be > the final LSP. Quit. > > 3. If only one Path message contains FAST_REROUTE object, this > becomes the chosen Path message. Quit. > > 4. If there are several LSPs, and not all of them have a DETOUR > object, then eliminate those with DETOUR from consideration. > > 5. If several candidates remain (that is, there are both detour > and protected LSPs), prefer the ones with FAST_REROUTE object. > > 6. If none found, prefer the ones without DETOUR object. If none > found, prefer the ones with DETOUR object. > > I think some simplification is possible, if we simply suggest the guidelines > (but not the details) of finding the protected LSP. As long as protected LSP(s) > are preferred over detours, there should not be inter-op problems. > > 1. If only one of the Path messages is for the protected LSP > (a protected LSP is one originated from this node, or with > the FAST_REROUTE object, or without the DETOUR object) then this > becomes the chosen Path message. Quit. > > 2. If more than one protected LSPs found, eliminate detours (those > with the DETOUR object) from consideration. > > 3. From the remaining set of Path messages, eliminate from consideration > any that traverse nodes that others want to avoid. > > 4. If several still remain, it is a local decision to > choose which one to forward. > Der-Hwa, I think this is a whole lot better. If Nic and Alia have no problem, let's fold the new rules into the next version. Thanks! - Ping > > This way, 1 & 2 replace the original rule 2-6. The original rule 1 becomes > 3, and the original rule 7 becomes 4. > > The benefits are (a) it is more readable, (b) implementations for rule 1&2 can > be quite simple if the worst case situations (suggested in original 2-6) won't > exist in that implementation. > > Will this look ok to all? > > Thanks, > Der-Hwa > > > > > > Thanks! > > > > - Ping > > > > > Thanks, > > > Der-Hwa Gan > > > > > > From owner-mpls@UU.NET Wed Jul 16 06:17:45 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24020 for ; Wed, 16 Jul 2003 06:17:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxor06240 for ; Wed, 16 Jul 2003 10:17:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxor06132; Wed, 16 Jul 2003 10:17:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxlo12107 for mpls-outgoing; Tue, 15 Jul 2003 14:00:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxln11850 for ; Tue, 15 Jul 2003 13:57:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxln18847 for ; Tue, 15 Jul 2003 13:57:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxln08050 for ; Tue, 15 Jul 2003 13:57:00 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQoxln08042 for ; Tue, 15 Jul 2003 13:56:59 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06514 for ; Tue, 15 Jul 2003 09:56:58 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14527 for ; Tue, 15 Jul 2003 09:56:58 -0400 (EDT) Message-ID: <3F1405A0.9040902@marconi.com> Date: Tue, 15 Jul 2003 09:46:08 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF MPLS List Subject: Re: RSVP_HOP Question References: <35800AB26A91D711A75D00B0D07935F30389D3@mailsrv01.vasw> In-Reply-To: <35800AB26A91D711A75D00B0D07935F30389D3@mailsrv01.vasw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Michael Mandelberg wrote: > > I am a bit confused about the usage of the Logical Interface Handle in > the RSVP_HOP object. My understanding of the LIH is that it helps the > sender of the PATH message to attach the RESERVE message to the correct > "Logical Interface". Now in GMPLS there is defined an IF_ID RSVP_HOP > object. In addition to the LIH, it includes TLVs which contain an IP > address, and an Interface ID. The LIH is used because in classical RSVP (and possibly also in RSVP-TE) a Resv message does not necessarily arrive on the same interface that its corresponding Path message went out on. If our session is unicast, this is no big deal. If it is multicast, however, we need a way to determine which interface the arriving Resv should apply to, since there may be multiple next-hop interfaces for the flow (session/sender combination). The LIH does that. In each outgoing PATH message, there's an LIH that uniquely identifies the interface. When the Resv comes back, it contains the LIH of the corresponding Path message (not the LIH of the interface sending the Resv) - this allows the node receiving the Resv to make it all work. GMPLS, however, does not use this. The LIH mechanism is too simplistic to accommodate all of the scenarios that GMPLS needs to suppot (for instance, a separated control/data plane.) So the IF_ID HOP object was invented to provide enough data to make it all work. > My question is, what relationship, if any, exists between the LIH in the > RSVP_HOP and the Interface ID in the TLV contained within the RSVP_HOP? As far as I know, none. The IF_ID TLV is used to perform a similar function, but I wouldn't use anything from RFC 2205 to define its behavior. -- David From owner-mpls@UU.NET Wed Jul 16 06:45:33 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24848 for ; Wed, 16 Jul 2003 06:45:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxot27103 for ; Wed, 16 Jul 2003 10:45:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxot26856; Wed, 16 Jul 2003 10:45:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxoh05016 for mpls-outgoing; Wed, 16 Jul 2003 07:55:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxoh05004 for ; Wed, 16 Jul 2003 07:54:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxoh13814 for ; Wed, 16 Jul 2003 07:54:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxoh18159 for ; Wed, 16 Jul 2003 07:54:23 GMT Received: from smtp.ietf57.telekom.at by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.ietf57.telekom.at [81.160.16.8]) id QQoxoh18139 for ; Wed, 16 Jul 2003 07:54:22 GMT Received: from pi.se ([81.160.245.12]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6G7s9k26026; Wed, 16 Jul 2003 09:54:11 +0200 (MEST) Message-ID: <3F150323.4090709@pi.se> Date: Wed, 16 Jul 2003 09:47:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Allan CC: "'mpls@UU.NET'" Subject: Invitation to discussion on 'A' bit problem statement 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 Dave, thanks for do this quick. Working Group, I would like comments on this over the next 4 weeks (this "long" period because it falls into the vacation period in Northern Europe (July) and the vacation period in the rest of Europe and the US (August), ending Friday August 15th. This discussion is initiated as a result of the discussion at the wg meeting in Vienna. Dave was asked to send a shart problem statement to the list, as a basis for this discussion. We want to find out whether there is a wg consensus to take this up as a work item. The related draft is "". I would like to see the pros, cons and don't care opininons. Add "pro", "con" or "don't care" to the response to the subject line, e.g.: Invitation to discussion on 'A' bit problem statement - don't care /Loa David Allan wrote: > During today's MPLS session it was clear that more > discussion/clarification was required on the problem space addressed by > the I-D. > > There is two aspects to the problem discussed in the draft. > > 1) Mixing e2e path testing with adjacency fault detection has > coorindation problems when failures occur. If I have an LSP hierarchy > that I am pinging at some low level, and a failure occurs, some number > of the pings will be affected, and a response/alarm management will be > hard to synchronize as ping sources are not local to the fault (and the > fault may also be detected locally, e.g. link failure). IMHO this is an > artifact of the delta between using ping to reactively to check routing > policy vs. using ping proactively to detect data plane failures. > > 2) Reserved labels define functions instead of forwarding. Fate sharing > between functions and LSPs is useful. Currently ECMP breaks fate sharing > between LSPs and LSP functions defined by reserved labels. > > The answer to #1 is to try to localize detection of data plane problems, > the ability to do the equivalent of the router alert label that fate > shares with the LSP is one potential mechanism that could be used to > increase locality in detecting data plane problems. Specific data plane > flows could be inspected for consistency by intermediate LSRs as they > were forwarded down the path. > > The answer to #2 is to provide an alternative to reserved labels for LSP > functions, the MPLS/PW PID is a candidate for doing this. The 'A' bit > was one example of providing such functionality by defining a > replacement for router alert. A side note is that there is a much higher > liklihood of commonality of forwarding of a solution that had the label > of interest as the top label vs. prepending with the router alert label. > > Comments? > > cheers > Dave > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Wed Jul 16 06:52:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25069 for ; Wed, 16 Jul 2003 06:52:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxot10775 for ; Wed, 16 Jul 2003 10:52:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxot10596; Wed, 16 Jul 2003 10:52:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxoe02044 for mpls-outgoing; Wed, 16 Jul 2003 07:11:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxoe01879 for ; Wed, 16 Jul 2003 07:10: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 QQoxoe04500 for ; Wed, 16 Jul 2003 07:09:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxoe12192 for ; Wed, 16 Jul 2003 07:09:27 GMT Received: from maildev.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxoe12185 for ; Wed, 16 Jul 2003 07:09:27 GMT Received: from aatlas-lt2.avici.com ([10.2.103.18]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6G791321052; Wed, 16 Jul 2003 03:09:01 -0400 (EDT) Message-Id: <5.1.0.14.2.20030716030947.01b93238@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Jul 2003 03:11:22 -0400 To: Ping Pan From: Alia Atlas Subject: Re: Suggested improvements to the Path-Specific merge rules in draft- ietf-mpls-rsvp-lsp-fastreroute-03 Cc: Der-Hwa Gan , Nic Neate , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'mjork@avici.com'" , "'mpls@uu.net'" In-Reply-To: References: <200307141950.h6EJoqu98650@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:41 PM 7/15/2003, Ping Pan wrote: > > 1. If only one of the Path messages is for the protected LSP > > (a protected LSP is one originated from this node, or with > > the FAST_REROUTE object, or without the DETOUR object) then this > > becomes the chosen Path message. Quit. > > > > 2. If more than one protected LSPs found, eliminate detours (those > > with the DETOUR object) from consideration. > > > > 3. From the remaining set of Path messages, eliminate from > consideration > > any that traverse nodes that others want to avoid. > > > > 4. If several still remain, it is a local decision to > > choose which one to forward. > > > >Der-Hwa, > >I think this is a whole lot better. If Nic and Alia have no problem, >let's fold the new rules into the next version. Ping & Der-Hwa, I certainly agree with simplifying the rules to what is logically necessary. This sounds good to me. Alia >Thanks! > >- Ping From owner-mpls@UU.NET Wed Jul 16 10:19:25 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02791 for ; Wed, 16 Jul 2003 10:19:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxph23268 for ; Wed, 16 Jul 2003 14:19:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxph22910; Wed, 16 Jul 2003 14:19:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxos13395 for mpls-outgoing; Wed, 16 Jul 2003 10:31:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxos13289 for ; Wed, 16 Jul 2003 10:31: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 QQoxos12290 for ; Wed, 16 Jul 2003 10:30:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxos17370 for ; Wed, 16 Jul 2003 10:30:32 GMT Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxos17343 for ; Wed, 16 Jul 2003 10:30:31 GMT Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2003 03:29:59 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6GAUSuJ008016 for ; Wed, 16 Jul 2003 03:30:28 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR94413; Wed, 16 Jul 2003 06:30:28 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6GAUST29176 for mpls@uu.net; Wed, 16 Jul 2003 06:30:28 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxor13192 for ; Wed, 16 Jul 2003 10:28:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxor04274 for ; Wed, 16 Jul 2003 10:28:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxor27500 for ; Wed, 16 Jul 2003 10:28:34 GMT Received: from penguin.al.sw.ericsson.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: penguin-ext.wise.edt.ericsson.se [193.180.251.47]) id QQoxor27431 for ; Wed, 16 Jul 2003 10:28:32 GMT Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6GASVGJ012162 for ; Wed, 16 Jul 2003 12:28:31 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6JJMAB; Wed, 16 Jul 2003 12:31:23 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jul 2003 12:28:03 +0200 Message-ID: <8C1856C372A7574291A56C3B7000A7AE02D3D9F2@eestqnt104> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Alberto Fernandez Bravo (EE/EEM)" To: mpls@UU.NET Subject: unsubscribe Date: Wed, 16 Jul 2003 12:27:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Wed Jul 16 13:45:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09979 for ; Wed, 16 Jul 2003 13:45:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxpv28383 for ; Wed, 16 Jul 2003 17:45:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxpu27899; Wed, 16 Jul 2003 17:44:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxom17892 for mpls-outgoing; Wed, 16 Jul 2003 09:12:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxom17886 for ; Wed, 16 Jul 2003 09:12:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoxom20079 for ; Wed, 16 Jul 2003 09:10:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxom22051 for ; Wed, 16 Jul 2003 09:10:17 GMT Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQoxom22015 for ; Wed, 16 Jul 2003 09:10:06 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6G99qZ19619; Wed, 16 Jul 2003 05:09:52 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jul 2003 05:09:53 -0400 Message-ID: From: "David Allan" To: "'Loa Andersson'" Cc: "'mpls@UU.NET'" Subject: RE: Invitation to discussion on 'A' bit problem statement Date: Wed, 16 Jul 2003 05:09:51 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk To elaborate slightly on yesterday's email, attached are the powerpoint slides I'll be using in PWE3 today. Dave > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Wednesday, July 16, 2003 3:48 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: 'mpls@UU.NET' > Subject: Invitation to discussion on 'A' bit problem statement > > > Dave, > > thanks for do this quick. > > Working Group, > > I would like comments on this over the next 4 weeks (this > "long" period because it falls into the vacation period in > Northern Europe (July) and the vacation period in the rest of > Europe and the US (August), ending Friday August 15th. This > discussion is initiated as a result of the discussion at the > wg meeting in Vienna. Dave was asked to send a shart problem > statement to the list, as a basis for this discussion. We > want to find out whether there is a wg consensus to take this > up as a work item. > > The related draft is "". > > I would like to see the pros, cons and don't care opininons. > > Add "pro", "con" or "don't care" to the response to the > subject line, e.g.: > > Invitation to discussion on 'A' bit problem statement - don't care > > /Loa > > David Allan wrote: > > During today's MPLS session it was clear that more > > discussion/clarification was required on the problem space > addressed by > > the I-D. > > > > There is two aspects to the problem discussed in the draft. > > > > 1) Mixing e2e path testing with adjacency fault detection has > > coorindation problems when failures occur. If I have an LSP > hierarchy > > that I am pinging at some low level, and a failure occurs, > some number > > of the pings will be affected, and a response/alarm > management will be > > hard to synchronize as ping sources are not local to the > fault (and the > > fault may also be detected locally, e.g. link failure). > IMHO this is an > > artifact of the delta between using ping to reactively to > check routing > > policy vs. using ping proactively to detect data plane failures. > > > > 2) Reserved labels define functions instead of forwarding. Fate > > sharing > > between functions and LSPs is useful. Currently ECMP breaks > fate sharing > > between LSPs and LSP functions defined by reserved labels. > > > > The answer to #1 is to try to localize detection of data plane > > problems, > > the ability to do the equivalent of the router alert label > that fate > > shares with the LSP is one potential mechanism that could > be used to > > increase locality in detecting data plane problems. > Specific data plane > > flows could be inspected for consistency by intermediate > LSRs as they > > were forwarded down the path. > > > > The answer to #2 is to provide an alternative to reserved > labels for > > LSP > > functions, the MPLS/PW PID is a candidate for doing this. > The 'A' bit > > was one example of providing such functionality by defining a > > replacement for router alert. A side note is that there is > a much higher > > liklihood of commonality of forwarding of a solution that > had the label > > of interest as the top label vs. prepending with the > router alert label. > > > > Comments? > > > > cheers > > Dave > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > > begin 600 slides for A bit (PWE3 redux).ppt MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````! M````/@``````````$```0`````$```#^____`````#\```#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________\/`.@#XAD```$`Z0,H````@!8``.`0``#@$``` M@!8```4````*````"P`````````!`````````0\`\@-@`0``+P#(#PP````P M`-(/!`````$````/`-4'F```````MP]$````5`!I`&T`90!S`"``3@!E`'<` M(`!2`&\`;0!A`&X```"DN!(`C+@2`*'0!S`(`````````*2X$@`Z00DPG+@2 M````!A(0`+\1`````$```( M`0``"`(```CW```0'P#P#QP``````/,#%`````(``````````````````(`` M````#P#0![L!```?`!0$'```````%004````1ZE/"0#*FCL^_6$X`,J:.P$! M```/`/H#9P``````_@,#``````$```#]`S0```!(````9````$@```!D```` M"`````````"\N!(`.D$),```````````IO___X+___\!`!(`<`#[`P@````` M````<`@``'``^P,(`````0```$`+```?``<$/```````_0,T````(0```&0` M```A````9````.BX$@#J)`DP)+H2`*`LC0D```````````````````````$2 M`!\`$P0\``````#]`S0```!D````9````&0```!D````Z+@2`.HD"3`DNA(` MH"R-"0```````````````````````1(`'P#_`Q0````"```$#``````````` M`````@```!\`"`0\``````#]`S0```!"````9````$(```!D`````@```.BX M$@`)(PDP)+H2`````````````````````````!(`#P"($S@````/`(H3,``` M````N@\0````7P!?`%\`4`!0`%0`,0`P````BQ,0```````-!`@`````P``` M`,```#\`V0\,``````#:#P0````-`"4`3P#9#PP``````-H/!`````T`/0`/ M`/`/'Q0`````\P,4`````P````0```````````$``````````/,#%````"H` M`````````@```"8!``````````"?#P0```````````"H#PL```!-;W1I=F%T M:6]N2!N M;W0@:&%V92!I;7!L96UE;G1A=&EO;B!C;VUM;VYA;&ET>2!W:71H(&9O0`@`&@`80!S`"``=0!T`&D`;`!I`'0`>0`-`$T`=0!L`'0` M:0`M`&@`;P!P`"``;P!R`"``'"!S`'``;`!I`&,`90!D`!T@(`!0`%<`0`@`'(`90!Q`'4`:0!R`&4` M(`!M`&\`<@!E`"``8P!O`&T`;0!O`&X`(`!F`'4`;@!C`'0`:0!O`&X`80!L M`&D`=`!Y`"``=P!I`'0`:``@`$P`4P!0`',`+``@`&(`=0!T`"``8P!U`'(` M<@!E`&X`=`!L`'D`(`!W`&\`=0!L`&0`(`!H`&$`=@!E`"``=`!O`"``=0!S M`&4`(`!D`&D`9@!F`&4`<@!E`&X`=``@`&T`90!C`&@`80!N`&D`2!O;FQY(&AA@`````$0P`` M!`$``0`.````J@\:````80$````````$`````0````,`<0```````````/,# M%````#```````````@```"P!``````````"?#P0```````````"H#PP```!/ M8G-E&%M<&QE(')A:7-E9"!Y97-T97)D87DL('=H870@:68@<&%Y M;&]A9"!A;&EA0`@`&$`;`!T M`&4`<@!N`&$`=`!I`'8`90`@`&8`;P!R`"``30!0`$P`4P`@`&$`;@!D`"`` M4`!7`',`#0!%`&$`P```````````&(````! M``````![`````````&(`````!`````0``*H/+````#T``````````P````$` M```#`#<``````````P````$````#`&,```````````#S`Q0````@```````` M``(````<`0``````````GP\$````````````J`\*````475E6QE``"B#P8````A```````` M`*H/"@```"$````!```````/``3P%@$``!(`"O`(`````P0````*``"#``OP M,````'\``0`%`(``0&Z-"8$!!```"(,!````"+\!`0`1`,`!`0``"/\!`0`) M``$"`@``"```$/`(````X`2P`=`4``\/`!'P$```````PPL(`````0````(` MC0D/``WPG@``````GP\$`````0``````J`]2````0VQI8VL@=&\@961I="!- M87-T97(@=&5X="!S='EL97,-4V5C;VYD(&QE=F5L#51H:7)D(&QE=F5L#49O M=7)T:"!L979E;`U&:69T:"!L979E;```H@\>````(0``````#0````$`#``` M``(`#0````,`#`````0```"J#PH```!3`````0``````#P`$\+8````2``KP M"`````0$````"@``@P`+\#````!_``$`!0"``-QTC0F!`00```B#`0````B_ M`0$`$0#``0$```C_`0$`"0`!`@(```@``!#P"````&`/L`%@!H`0#P`1\!`` M`````,,+"`````(````'`8T)#P`-\#X``````)\/!`````0``````*`/`@`` M`"H```"A#Q0````"`````````````@```````@`.````^`\$``````````\` M!/#6````$@`*\`@````%!`````H``(,`"_`P````?P`!``4`@``D>8T)@0$$ M```(@P$````(OP$!`!$`P`$!```(_P$!``D``0("```(```0\`@```#`#Y`& M(!#@$`\`$?`0``````##"P@````#````"0*-"0\`#?!>``````"?#P0````$ M``````"H#QX```!DO6@`OP$2`!(`_P$```@`!`,)````/P,!``$`$`#P M!R````#___\``````("`@````````,R9`#,SS`#,S/\`LK*R`"``N@\<```` M1`!E`&8`80!U`&P`=``@`$0`90!S`&D`9P!N``\`\`/Z!0```0#Q`P@````` M``"````*,`\`#`1Z!0``#P`"\'(%``"@``CP"`````<````'*```#P`#\`H% M```/``3P*`````$`"?`0``````````````````````````(`"O`(`````"@` M``4````/``3PR````!(`"O`(`````B@````*``"#``OP,````'\``0`%`(`` M?.Z'"H$!!```"(,!````"+\!`0`1`,`!`0``"/\!`0`)``$"`@``"```$/`( M`````````%`'(`$/`!'P$```````PPL(``````````H"APH/``WP4``````` MGP\$````!```````H`\"````*@```*$/%`````(````````````"```````" M``P```#Y#P0```````````"J#PH````"`````0``````#P`$\,H````2``KP M"`````,H````"@``@P`+\#````!_``$`!0"``-CSAPJ!`00```B#`0````B_ M`0$`$0#``0$```C_`0$`"0`!`@(```@``!#P"```````CPG?$"`!#P`1\!`` M`````,,+"`````$````'`(<*#P`-\%(``````)\/!`````0``````*`/`@`` M`"H```"A#Q8````"````````"````@`"```````"``P```#X#P0````````` M``"J#PH````"`````0``````#P`$\&0````2``KP"`````0H````"@``8P`+ M\"0```!_``0!!`&'``$```!_`0```0"_`1$`$0#_`0@`"0`_`@$``0```!#P M"````+`!T`(0#B`*#P`1\!```````,,+"`````(````%`(<*#P`$\!8!```2 M``KP"`````4H````"@``@P`+\#````!_``$`!0"``/CNAPJ!`00```B#`0`` M``B_`0$`$0#``0$```C_`0$`"0`!`@(```@``!#P"````+`*L`$P#]`4#P`1 M\!```````,,+"`````,````&`H<*#P`-\)X``````)\/!`````(``````*@/ M4@```$-L:6-K('1O(&5D:70@36%S=&5R('1E>'0@````?P````0`@`"<'X<*OP$```$`_P$```$``0,"!``` M```0\`@```"``;`!T!10!`\`$?`0``````##"P@`````````#0"["@\`#?`, M``````">#P0`````````#P`$\'(````2``KP"`````.H```@`@``4P`+\!X` M``!_````!`"``%@DC0F_`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0 M%``/#P`1\!```````,,+"`````$````.`(T)#P`-\`P``````)X/!`````$` M```/``3P2````!(`"O`(`````:@````,``"#``OP,````($!````"(,!!0`` M"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@```` M____``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`(@3.`````\`BA,P M``````"Z#Q````!?`%\`7P!0`%``5``Q`#````"+$Q```````.LN"````&]+ MPP$`@````?P````0`@`"XL[L*OP$```$`_P$```$``0,# M!``````0\`@```#@!+`!T!0`#P\`$?`0``````##"P@````!````#@"["@\` M#?`,``````">#P0````!````#P`$\$@````2``KP"`````&L````#```@P`+ M\#````"!`0````B#`04```B3`8Z?BP"4`=Z]:`"_`1(`$@#_`0``"``$`PD` M```_`P$``0`0`/`'(````/___P``````@("`````````S)D`,S/,`,S,_P"R MLK(`#P"($S@````/`(H3,```````N@\0````7P!?`%\`4`!0`%0`,0`P```` MBQ,0``````#K+@@```!O2\,!D*C\_@\`[@,D`@```@#O`Q@````!````#0X` M``````````"```````<`$@`/``P$E`$```\``O",`0``P`((\`@````#```` M`[````\``_`D`0``#P`$\"@````!``GP$``````````````````````````" M``KP"`````"P```%````#P`$\'(````2``KP"`````*P```@`@``4P`+\!X` M``!_````!`"``(A)NPJ_`0```0#_`0```0`!`P($`````!#P"````(`!L`'0 M%%`$#P`1\!```````,,+"``````````-`+L*#P`-\`P``````)X/!``````` M```/``3P<@```!(`"O`(`````[```"`"``!3``OP'@```'\````$`(``.+Z[ M"K\!```!`/\!```!``$#`P0`````$/`(````X`2P`=`4``\/`!'P$``````` MPPL(`````0````X`NPH/``WP#```````G@\$`````0````\`!/!(````$@`* M\`@````!L`````P``(,`"_`P````@0$````(@P$%```(DP&.GXL`E`'>O6@` MOP$2`!(`_P$```@`!`,)````/P,!``$`$`#P!R````#___\``````("`@``` M`````,R9`#,SS`#,S/\`LK*R``\`B!,X````#P"*$S```````+H/$````%\` M7P!?`%``4`!4`#$`,````(L3$```````ZRX(````<$O#`2"A?`4/`.X#)`(` M``(`[P,8`````0````T.````````````@``````'`!(`#P`,!)0!```/``+P MC`$``-`""/`(`````P````.T```/``/P)`$```\`!/`H`````0`)\!`````` M`````````````````````@`*\`@`````M```!0````\`!/!R````$@`*\`@` M```"M```(`(``%,`"_`>````?P````0`@`#<@+L*OP$```$`_P$```$``0," M!``````0\`@```"``;`!T!10!`\`$?`0``````##"P@`````````#0"["@\` M#?`,``````">#P0`````````#P`$\'(````2``KP"`````.T```@`@``4P`+ M\!X```!_````!`"``/";NPJ_`0```0#_`0```0`!`P,$`````!#P"````.`$ ML`'0%``/#P`1\!```````,,+"`````$````.`+L*#P`-\`P``````)X/!``` M``$````/``3P2````!(`"O`(`````;0````,``"#``OP,````($!````"(,! M!0``"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@ M````____``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`(@3.`````\` MBA,P``````"Z#Q````!?`%\`7P!0`%``5``Q`#````"+$Q```````.LN"``` M`'!+PP$@T[4(#P#N`R0"```"`.\#&`````$````-#@```````````(`````` M!P`2``\`#`24`0``#P`"\(P!``#@`@CP"`````,````#N```#P`#\"0!```/ M``3P*`````$`"?`0``````````````````````````(`"O`(`````+@```4` M```/``3P<@```!(`"O`(`````K@``"`"``!3``OP'@```'\````$`(``0)Z[ M"K\!```!`/\!```!``$#`@0`````$/`(````@`&P`=`44`0/`!'P$``````` MPPL(``````````T`NPH/``WP#```````G@\$``````````\`!/!R````$@`* M\`@````#N```(`(``%,`"_`>````?P````0`@``4T;L*OP$```$`_P$```$` M`0,#!``````0\`@```#@!+`!T!0`#P\`$?`0``````##"P@````!````#@"[ M"@\`#?`,``````">#P0````!````#P`$\$@````2``KP"`````&X````#``` M@P`+\#````"!`0````B#`04```B3`8Z?BP"4`=Z]:`"_`1(`$@#_`0``"``$ M`PD````_`P$``0`0`/`'(````/___P``````@("`````````S)D`,S/,`,S, M_P"RLK(`#P"($S@````/`(H3,```````N@\0````7P!?`%\`4`!0`%0`,0`P M````BQ,0``````#K+@@```!P2\,!L!UJ"P\`[@,D`@```@#O`Q@````!```` M#0X```````````"```````<`$@`/``P$E`$```\``O",`0``D`((\`@````# M`````Z0```\``_`D`0``#P`$\"@````!``GP$``````````````````````` M```"``KP"`````"D```%````#P`$\'(````2``KP"`````*D```@`@``4P`+ M\!X```!_````!`"``*#8X`"_`0```0#_`0```0`!`P($`````!#P"````(`! ML`'0%%`$#P`1\!```````,,+"``````````-`(<*#P`-\`P``````)X/!``` M```````/``3P<@```!(`"O`(`````Z0``"`"``!3``OP'@```'\````$`(`` MB//@`+\!```!`/\!```!``$#`P0`````$/`(````X`2P`=`4``\/`!'P$``` M````PPL(`````0````X`X``/``WP#```````G@\$`````0````\`!/!(```` M$@`*\`@````!I`````P``(,`"_`P````@0$````(@P$%```(DP&.GXL`E`'> MO6@`OP$2`!(`_P$```@`!`,)````/P,!``$`$`#P!R````#___\``````("` M@````````,R9`#,SS`#,S/\`LK*R``\`B!,X````#P"*$S```````+H/$``` M`%\`7P!?`%``4`!4`#$`,````(L3$```````ZRX(````X4K#`7`Y2P$/`.X# MD@(```(`[P,8`````0````T.````````````@``````'`!(`#P`,!`("```/ M``+P^@$``/`""/`(````!`````2\```/``/PD@$```\`!/`H`````0`)\!`` M`````````````````````````@`*\`@`````O```!0````\`!/!R````$@`* M\`@````"O```(`(``%,`"_`>````?P````0`@`#<*BT+OP$```$`_P$```$` M`0,"!``````0\`@```"``;`!T!10!`\`$?`0``````##"P@`````````#0`M M"P\`#?`,``````">#P0`````````#P`$\'(````2``KP"`````.\```@`@`` M4P`+\!X```!_````!`"``&"*+0N_`0```0#_`0```0`!`P,$`````!#P"``` M`.`$L`'0%``/#P`1\!```````,,+"`````$````.`"T+#P`-\`P``````)X/ M!`````$````/``3P9@```$($"O`(````!+P````*``"#``OP,````(4``@`` M`(<``0```(@``0```($!_P```+\!$``0`,`!_P```/\!"``(``$"`@``"!,` M(O$&````OP$``&`````0\`@```"P#7`%T`5@#P\`!/!(````$@`*\`@````! MO`````P``(,`"_`P````@0$````(@P$%```(DP&.GXL`E`'>O6@`OP$2`!(` M_P$```@`!`,)````/P,!``$`$`#P!R````#___\``````("`@````````,R9 M`#,SS`#,S/\`LK*R``\`B!,X````#P"*$S```````+H/$````%\`7P!?`%`` M4`!4`#$`,````(L3$```````ZRX(````````?P````0`@``@S0T/OP$```$`_P$```$``0,"!``````0 M\`@```"``;`!T!10!`\`$?`0``````##"P@`````````#0`-#P\`#?`,```` M``">#P0`````````#P`$\'(````2``KP"`````/````@`@``4P`+\!X```!_ M````!`"``&2.#0^_`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0%``/ M#P`1\!```````,,+"`````$````.``T/#P`-\`P``````)X/!`````$````/ M``3P2````!(`"O`(`````<`````,``"#``OP,````($!````"(,!!0``"),! MCI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@````____ M``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`(@3.`````\`BA,P```` M``"Z#Q````!?`%\`7P!0`%``5``Q`#````"+$Q```````.LN"````'1+PP'@ M_*H6#P#N`S`"```"`.\#&`````$````-#@```````````(``````!P`2``\` M#`2@`0``#P`"\)@!```0`PCP"`````,````#Q```#P`#\#`!```/``3P*``` M``$`"?`0``````````````````````````(`"O`(`````,0```4````/``3P M>````!(`"O`(`````L0``"`"``!C``OP)````'\````$`(``<*X-#[\!```! M`/\!```!``$#`@0``(@#````````$/`(````@`&P`=`44`0/`!'P$``````` MPPL(``````````T`#0\/``WP#```````G@\$``````````\`!/!X````$@`* M\`@````#Q```(`(``&,`"_`D````?P````0`@``0:PT/OP$```$`_P$```$` M`0,#!```B`,````````0\`@````@!+`!T!0`#P\`$?`0``````##"P@````! M````#@`-#P\`#?`,``````">#P0````!````#P`$\$@````2``KP"`````'$ M````#```@P`+\#````"!`0````B#`04```B3`8Z?BP"4`=Z]:`"_`1(`$@#_ M`0``"``$`PD````_`P$``0`0`/`'(````/___P``````@("`````````S)D` M,S/,`,S,_P"RLK(`#P"($S@````/`(H3,```````N@\0````7P!?`%\`4`!0 M`%0`,0`P````BQ,0``````#K+@@```"[0,,!\#@6ZP\`[@.J`0```@#O`Q@` M```!````#0X```````````"```````<`$@`/``P$&@$```\``O`2`0````(( M\`@````"`````X````\``_"J````#P`$\"@````!``GP$``````````````` M```````````"``KP"`````"````%````#P`$\'(````2``KP"`````*````@ M`@``4P`+\!X```!_````!`"``!#HAPJ_`0```0#_`0```0`!`P($`````!#P M"````(`!L`'0%%`$#P`1\!```````,,+"``````````-`(<*#P`-\`P````` M`)X/!``````````/``3P2````!(`"O`(`````8`````,``"#``OP,````($! M````"(,!!0``"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`! M`!``\`<@````____``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`(@3 M.`````\`BA,P``````"Z#Q````!?`%\`7P!0`%``5``Q`#````"+$Q`````` M`.LN"````+]`PP%0I\^'``!R%T@````!`#```````.H9``"N*```"P`0`*PB M```@`!``"D```"D`D`#@-@``!"P``#`N``!<,```B#(``+0T```,.0``ICL` M`-(]`````/4/'``````!``!M$``#`````+Q!```!````,0````$`7PX````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````/[_```%``(```````````````````````$```#@A9_R^4]H M$*N1"``K)[/9,````*01```+`````0```&`````"````:`````0```"(```` M"````)P````)````K````!(```"X````"@```-@````,````Y`````T```#P M````#P```/P````1````!`$```(```#D!```'@```!@```!0;W=E````"P```$1A=F4@06QL86X`4!X````'````1$%, M3$%.`&P>`````P```#(X`$P>````%0```$UI8W)O``<```#\`@``____ M````!````"T!```(````^@(%``````#___\`!````"T!`0`,````0`DA`/`` M````````[P+I`_____\(````^@(`````````````!````"T!`@`$````+0$` M``0````G`?__'````/L"[_\```````"0`0``````0``Q0V]U$!!````&UP;',4``X`"``+``0````N`0``!````"T!!``$```` M\`$#`!P```#[`N3_````````D`$``````$``$E1I;65S($YE=R!2;VUA;@`` M````````````````````!````"T!`P`$````+@$8``0````"`0$`!0````D" M`````@D````R"GL!%@(!````+0`)``0````N`0``!````"T!!``$````\`$# M`!P```#[`N3_````````D`$``````$``$E1I;65S($YE=R!2;VUA;@`````` M````````````````!````"T!`P`$````+@$8``0````"`0$`!0````D"```` M`@D````R"GL!'P(!````80`,``0````N`0``!````"T!!``$````\`$#`!P` M``#[`N3_````````D`$``````$``$E1I;65S($YE=R!2;VUA;@`````````` M````````````!````"T!`P`$````+@$8``0````"`0$`!0````D"`````@D` M```R"GL!*P(!````+0`)``0````N`0``!````"T!!``$````\`$#`!P```#[ M`N3_````````D`$``````$``$E1I;65S($YE=R!2;VUA;@`````````````` M````````!````"T!`P`$````+@$8``0````"`0$`!0````D"`````@P````R M"GL!-`(#````8FET``X`"``(``0````N`0``!````"T!!``$````\`$#`!P` M``#[`N3_````````D`$``````$``$E1I;65S($YE=R!2;VUA;@`````````` M````````````!````"T!`P`$````+@$8``0````"`0$`!0````D"`````@D` M```R"GL!4@(!````+0`)``0````N`0``!````"T!!``$````\`$#`!P```#[ M`N3_````````D`$``````$``$E1I;65S($YE=R!2;VUA;@`````````````` M````````!````"T!`P`$````+@$8``0````"`0$`!0````D"`````A`````R M"GL!6P(&````,#`N='AT#@`.``<`"``.``@`!````"X!```$````+0$$``0` M``#P`0,`'````/L"U/\```````"0`0``````0``25&EM97,@3F5W(%)O;6%N M```````````````````````$````+0$#``0````N`1@`!`````(!`0`%```` M"0(````"%@```#(*#0)@`@H```!$879E($%L;&%N(``4`!8`$P`,`!\`#0`, M`!4`%0`$````+@$```0````M`00`!````/`!`P`<````^P+9_P```````)`! M``````!``!)4:6UE````,@H]`F`"#P```$YO M$``` M#@```!````!4:6UE````#0```%-L:61E(%1I M=&QE````'P```"`````A````_O___R,````D````)0```"8` M```G````*````"D````J````_O___RP````M````+@```"\````P````,0`` M`#(```#^____-````#4````V````-P```#@````Y````.@```/[____]____ M/0```/[_____________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M__]2`&\`;P!T`"``10!N`'0`<@!Y```````````````````````````````` M````````````````````````````%@`%`?__________`P```!"-@62;3\\1 MANH`J@"Y*>@``````````````````````````/[___\``````````$,`=0!R M`'(`90!N`'0`(`!5`',`90!R```````````````````````````````````` M```````````````````:``(!________________```````````````````` M````````````````````````````,P`````0````````!0!3`'4`;0!M`&$` M<@!Y`$D`;@!F`&\`<@!M`&$`=`!I`&\`;@`````````````````````````` M`````````"@``@$!````__________\````````````````````````````` M```````````````````B````U!$```````!0`&\`=P!E`'(`4`!O`&D`;@!T M`"``1`!O`&,`=0!M`&4`;@!T```````````````````````````````````` M*``"`0(````$````_____P`````````````````````````````````````` M```````````````P0@````````4`1`!O`&,`=0!M`&4`;@!T`%,`=0!M`&T` M80!R`'D`20!N`&8`;P!R`&T`80!T`&D`;P!N```````````````X``(!____ M____________```````````````````````````````````````````````` M*P`````0```````````````````````````````````````````````````` M``````````````````````````````````````````````#_____________ M__\````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````/_______________P`````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````________________```````````````` M````````````````````````````````````````````````4@!O`&\`=``@ M`$4`;@!T`'(`>0`````````````````````````````````````````````` M`````````````!8`!0'__________P,````0C8%DFT_/$8;J`*H`N2GH```` M````````````,-7GW7E+PP%!````P`0```````!#`'4`<@!R`&4`;@!T`"`` M50!S`&4`<@`````````````````````````````````````````````````` M````&@`"`?_______________P`````````````````````````````````` M`````````````#,`````$`````````4`4P!U`&T`;0!A`'(`>0!)`&X`9@!O M`'(`;0!A`'0`:0!O`&X````````````````````````````````````H``(! M`0```/__________```````````````````````````````````````````` M````(@```-01````````4`!O`'<`90!R`%``;P!I`&X`=``@`$0`;P!C`'4` M;0!E`&X`=````````````````````````````````````"@``@$"````!``` M`/____\````````````````````````````````````````````````````` M,$(````````!`````@````,````$````!0````8````'````"`````D````* M````"P````P````-````#@````\````0````$0```!(````3````%````!4` M```6````%P```!@````9````&@```!L````<````'0```!X````?````(``` M`"$```#^____(P```"0````E````)@```"<````H````*0```"H```#^____ M__________________________________________\T````-0```#8````W M````.````#D````Z````_O___________________T0```#]_____O___T(` M``!#````_O____[_____________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_________________________________P$````"`````P````0````%```` M!@````<````(````"0````H````+````#`````T````.````#P```!`````1 M````$@```/[_________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_________________________________________________________O\` M``4``@```````````````````````@````+5S=6<+AL0DY<(`"LL^:Y$```` M!=7-U9PN&Q"3EP@`*RSYKJ@"``!D`@``$`````$```"(`````P```)`````/ M````J`````0```#`````!@```,@````'````T`````@```#8````"0```.`` M```*````Z````!<```#P````"P```/@````0``````$``!,````(`0``%@`` M`!`!```-````&`$```P````$`@```@```.0$```>````#P```$]N+7-C````$````$YOQ`*``L` M````````"P`````````+``````````L`````````'A````X````0````5&EM M97,@3F5W(%)O;6%N``@```!#;W5R:65R``\```!$969A=6QT($1E0`+````475E0!.`&$`;0!E`````@```+`$```3````"00```,```!Z?#:, M'P```#8```!)`&X`=@!I`'0`80!T`&D`;P!N`"``=`!O`"``9`!I`',`8P!U M`',`0!)`&X`9@!O`'(` M;0!A`'0`:0!O`&X``````````````#@``@'_______________\````````` M````````````````````````````````````````````J`0````````````` M```````````````````````````````````````````````````````````` M`````````````````````````/_______________P`````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````________________```````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````#_______________\````````````````````````````````````` 4```````````````````````````= ` end From owner-mpls@UU.NET Wed Jul 16 16:41:58 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16733 for ; Wed, 16 Jul 2003 16:41:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxqg26433 for ; Wed, 16 Jul 2003 20:42:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxqg26119; Wed, 16 Jul 2003 20:41:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxpr03521 for mpls-outgoing; Wed, 16 Jul 2003 16:51:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxpr03516 for ; Wed, 16 Jul 2003 16:51: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 QQoxpr25954 for ; Wed, 16 Jul 2003 16:50:47 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxpr10525 for ; Wed, 16 Jul 2003 16:50:47 GMT Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQoxpr10497 for ; Wed, 16 Jul 2003 16:50:45 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWA96ZJ>; Wed, 16 Jul 2003 17:50:26 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6B2D@i2km07-ukbr.domain1.systemhost.net> To: dallan@nortelnetworks.com, mpls@UU.NET Subject: RE: 'A' bit problem statement Date: Wed, 16 Jul 2003 17:50:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34BBA.50860675" 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_01C34BBA.50860675 Content-Type: text/plain; charset="ISO-8859-1" Hi Dave....I see you are still battling away against the real the underlying problems.....for which you have my admiration, but I could only agree to such a position on the basis that it is recognised that we providing a temporary fix to a fundamentally broken architectural problem.....ultimately we have to get rid of the stuff that is broken and then we don't need the fixes. Please see some further remarks below. regards, Neil -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: 15 July 2003 10:29 To: 'mpls@UU.NET' Subject: 'A' bit problem statement During today's MPLS session it was clear that more discussion/clarification was required on the problem space addressed by the I-D. There is two aspects to the problem discussed in the draft. 1) Mixing e2e path testing with adjacency fault detection has coorindation problems when failures occur. If I have an LSP hierarchy that I am pinging at some low level, and a failure occurs, some number of the pings will be affected, and a response/alarm management will be hard to synchronize as ping sources are not local to the fault (and the fault may also be detected locally, e.g. link failure). IMHO this is an artifact of the delta between using ping to reactively to check routing policy vs. using ping proactively to detect data plane failures. NH=> The simple short-term fix to the problems mp2p creates I believe is as follows: - mp2p merging in any co pkt-sw technology forwarding means we lose sight of the source, and architrecturally this should tell us this is a deprecated topology in such a mode......BTW, IP *never* uses merging it is always muxing because it belongs to the cnls mode where each/every pkt has a SA/DA and so is fully resolvable. So unless the *immediate* client is IP (but then there is little value-add from MPLS LDP variety here IMO) there are always p2p LSPs (in one form or another) above the mp2p LSPs......this is a forced consequence of the mp2p merging to effect demerging. - so run some decent fault management continuously on the p2p LSPs (like Y.1711) and if this shows a problem then: * check the L1 trails.....if these show a correlated fault then done....but if these show 'clear', then * wheel-out more complex ad hoc tools like LSP-Ping to go hunting through the mp2p LSPs. Note - I am actually happy to live with LSP-Ping, and the fact its virtually impossible to define any meaningful defect states (entry/exit criteria and consequent actions) or QoS behaviour for a mp2p entity, in the *short-term*....we have it and have to live with it. But that does not mean I have to keep building on it and pretending its all fine for the future too.....long-term this (and other architectural errors like PHP) simply have to go. So I won't accept kludge on kludge from here on it, like the latest PID fix and the further PW OAM proposals.....this last one is an elastoplast too far. MPLS could/should have an important future which adds value to services providers......if all one does is try and replicate the IP layer (which you can't anyway as MPLS uses co pkt-sw forwarding mode) we are never going to realise the protential on MPLS. Maybe that is what some people want? 2) Reserved labels define functions instead of forwarding. NH=> Agreed. This is not a good solution IMO......however, what do you do when the header is functionally deficient?....also see later remark. Fate sharing between functions and LSPs is useful. Currently ECMP breaks fate sharing between LSPs and LSP functions defined by reserved labels. NH=> Agreed. And when one considers the ethernet VPLS stuff over this there will be a request to *turn-off* the ECMP since one cannot tolerlate uni-directional failings here....and ECMP creates a richer environment for this. Bottom line is load-sharing is OKish within a *single* layer network (like IP) but it will lead to problems if done over >1 layer network (ie MPLS). And of course it has, ergo the PID kludge. Right answer of course is to introduce proper p2p TE capabilities to bypass the SPF/IGP routes in a known/consistent manner. The answer to #1 is to try to localize detection of data plane problems, the ability to do the equivalent of the router alert label that fate shares with the LSP is one potential mechanism that could be used to increase locality in detecting data plane problems. Specific data plane flows could be inspected for consistency by intermediate LSRs as they were forwarded down the path. The answer to #2 is to provide an alternative to reserved labels for LSP functions, the MPLS/PW PID is a candidate for doing this. The 'A' bit was one example of providing such functionality by defining a replacement for router alert. A side note is that there is a much higher liklihood of commonality of forwarding of a solution that had the label of interest as the top label vs. prepending with the router alert label. NH=> Dave I agree.....however, if we can one-day recognise mp2p merging as 'bad' then maybe we could properly set the OAM indicator where it really should functionally reside....as part of the header.....say using the TTL field which would now be effectively redundant (8 bits is way overkill anyway). In the meantime, I could live with your proposal if (i) it was recognised as a fix to a problem lying elsewhere, with the ultimate goal of removing the real problem at some stage and (ii) we simply use the PID without the other CW stuff (which I regard as largely irrelevant for a properly engineered/architecturally-valid MPLS network.....but if the Seq. No. stuff stays then it *must* have entry/exit defect states and consequent actions associated with it fully specified, it is unacceptable to leave this open-ended IMO speaking as an operator). Comments? cheers Dave ------_=_NextPart_001_01C34BBA.50860675 Content-Type: text/html; charset="ISO-8859-1" 'A' bit problem statement
Hi Dave....I see you are still battling away against the real the underlying problems.....for which you have my admiration, but I could only agree to such a position on the basis that it is recognised that we providing a temporary fix to a fundamentally broken architectural problem.....ultimately we have to get rid of the stuff that is broken and then we don't need the fixes.
 
Please see some further remarks below.  regards, Neil
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: 15 July 2003 10:29
To: 'mpls@UU.NET'
Subject: 'A' bit problem statement

During today's MPLS session it was clear that more discussion/clarification was required on the problem space addressed by the I-D.

There is two aspects to the problem discussed in the draft.

1) Mixing e2e path testing with adjacency fault detection has coorindation problems when failures occur. If I have an LSP hierarchy that I am pinging at some low level, and a failure occurs, some number of the pings will be affected, and a response/alarm management will be hard to synchronize as ping sources are not local to the fault (and the fault may also be detected locally, e.g. link failure). IMHO this is an artifact of the delta between using ping to reactively to check routing policy vs. using ping proactively to detect data plane failures. 

NH=> The simple short-term fix to the problems mp2p creates I believe is as follows:
-    mp2p merging in any co pkt-sw technology forwarding means we lose sight of the source, and architrecturally this should tell us this is a deprecated topology in such a mode......BTW, IP *never* uses merging it is always muxing because it belongs to the cnls mode where each/every pkt has a SA/DA and so is fully resolvable.  So unless the *immediate* client is IP (but then there is little value-add from MPLS LDP variety here IMO) there are always p2p LSPs (in one form or another) above the mp2p LSPs......this is a forced consequence of the mp2p merging to effect demerging. 
-    so run some decent fault management continuously on the p2p LSPs (like Y.1711) and if this shows a problem then:
    * check the L1 trails.....if these show a correlated fault then done....but if these show 'clear', then
    * wheel-out more complex ad hoc tools like LSP-Ping to go hunting through the mp2p LSPs.

Note - I am actually happy to live with LSP-Ping, and the fact its virtually impossible to define any meaningful defect states (entry/exit criteria and consequent actions) or QoS behaviour for a mp2p entity, in the *short-term*....we have it and have to live with it.  But that does not mean I have to keep building on it and pretending its all fine for the future too.....long-term this (and other architectural errors like PHP) simply have to go.  So I won't accept kludge on kludge from here on it, like the latest PID fix and the further PW OAM proposals.....this last one is an elastoplast too far.  MPLS could/should have an important future which adds value to services providers......if all one does is try and replicate the IP layer (which you can't anyway as MPLS uses co pkt-sw forwarding mode) we are never going to realise the protential on MPLS.  Maybe that is what some people want?

 

2) Reserved labels define functions instead of forwarding.  

NH=> Agreed.  This is not a good solution IMO......however, what do you do when the header is functionally deficient?....also see later remark.
 Fate sharing between functions and LSPs is useful. Currently ECMP breaks fate sharing between LSPs and LSP functions defined by reserved labels.  

NH=> Agreed.  And when one considers the ethernet VPLS stuff over this there will be a request to *turn-off* the ECMP since one cannot tolerlate uni-directional failings here....and ECMP creates a richer environment for this.  Bottom line is load-sharing is OKish within a *single* layer network (like IP) but it will lead to problems if done over >1 layer network (ie MPLS).  And of course it has, ergo the PID kludge.  Right answer of course is to introduce proper p2p TE capabilities to bypass the SPF/IGP routes in a known/consistent manner.

The answer to #1 is to try to localize detection of data plane problems, the ability to do the equivalent of the router alert label that fate shares with the LSP is one potential mechanism that could be used to increase locality in detecting data plane problems. Specific data plane flows could be inspected for consistency by intermediate LSRs as they were forwarded down the path.

The answer to #2 is to provide an alternative to reserved labels for LSP functions, the MPLS/PW PID is a candidate for doing this. The 'A' bit was one example of providing such functionality by defining a replacement for router alert. A side note is that there is a much higher liklihood of commonality of forwarding of a solution that had the label of interest as the top label vs. prepending with  the router alert label. 

NH=> Dave I agree.....however, if we can one-day recognise mp2p merging as 'bad' then maybe we could properly set the OAM indicator where it really should functionally reside....as part of the header.....say using the TTL field which would now be effectively redundant (8 bits is way overkill anyway).  In the meantime, I could live with your proposal if (i) it was recognised as a fix to a problem lying elsewhere, with the ultimate goal of removing the real problem at some stage and (ii) we simply use the PID without the other CW stuff (which I regard as largely irrelevant for a properly engineered/architecturally-valid MPLS network.....but if the Seq. No. stuff stays then it *must* have entry/exit defect states and consequent actions associated with it fully specified, it is unacceptable to leave this open-ended IMO speaking as an operator).

Comments?

cheers
Dave

------_=_NextPart_001_01C34BBA.50860675-- From owner-mpls@UU.NET Thu Jul 17 12:36:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13283 for ; Thu, 17 Jul 2003 12:36:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxti02125 for ; Thu, 17 Jul 2003 16:36:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxti01985; Thu, 17 Jul 2003 16:36:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxsf28478 for mpls-outgoing; Thu, 17 Jul 2003 09:21:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxsf28470 for ; Thu, 17 Jul 2003 09:21: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 QQoxsf24382 for ; Thu, 17 Jul 2003 09:21:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxsf09650 for ; Thu, 17 Jul 2003 09:21:09 GMT Received: from smtp.ietf57.telekom.at by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.ietf57.telekom.at [81.160.16.8]) id QQoxsf09635 for ; Thu, 17 Jul 2003 09:21:08 GMT Received: from pi.se ([81.160.245.12]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H9L6k20123; Thu, 17 Jul 2003 11:21:07 +0200 (MEST) Message-ID: <3F166906.4050703@pi.se> Date: Thu, 17 Jul 2003 11:14:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG , George Swallow , Alex Zinin Subject: draft-swallow-mpls-lsr-self-test-01.txt, to wg draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Working Group, at the Vienna MPLS WG meeting the Label Switched Router Self-Test was discussed. There were support for making it a wg draft. We will go ahead and do so shortly, this is a chance you who were not in the meeting (or did not speak up) to comment on this. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Thu Jul 17 12:39:49 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13367 for ; Thu, 17 Jul 2003 12:39:49 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxti06928 for ; Thu, 17 Jul 2003 16:39:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxti06837; Thu, 17 Jul 2003 16:39:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxsi14013 for mpls-outgoing; Thu, 17 Jul 2003 10:03:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxsi11839 for ; Thu, 17 Jul 2003 10:02:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxsi02400 for ; Thu, 17 Jul 2003 10:01:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxsi26762 for ; Thu, 17 Jul 2003 10:01:12 GMT Received: from mta0.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQoxsi26745 for ; Thu, 17 Jul 2003 10:01:10 GMT Received: from l20711 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HI5007RLYFCP0@mta0.huawei.com> for mpls@UU.NET; Thu, 17 Jul 2003 17:59:38 +0800 (CST) Date: Thu, 17 Jul 2003 18:01:16 +0800 From: Terry Lee Subject: question about draft-ietf-mpls-nodeid-subobject-01.txt To: mpls@UU.NET Message-id: <000201c34c4a$5d142cc0$d9226e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook, Build 10.0.4024 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 Hi In draft-ietf-mpls-nodeid-subobject-01.txt, it states there exist following flag in RRO. But I can't find in RFC2205,RFC3209 and draft-ietf-mpls-rsvp-lsp-fastreroute-03. Where can I find it ? Preemption pending: 0x10 The preempting node sets this flag if a pending preemption is in progress for the TE LSP. This indicates to the HE of this LSP that it must be re-routed as soon as possible using a make before break. Thanks and Regards, Terry Lee From owner-mpls@UU.NET Thu Jul 17 13:45:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15001 for ; Thu, 17 Jul 2003 13:45:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxtn02308 for ; Thu, 17 Jul 2003 17:45:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxtn02142; Thu, 17 Jul 2003 17:45:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxsh00096 for mpls-outgoing; Thu, 17 Jul 2003 09:49:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxsh00091 for ; Thu, 17 Jul 2003 09:48: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 QQoxsh05636 for ; Thu, 17 Jul 2003 09:48:22 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxsh12895 for ; Thu, 17 Jul 2003 09:48:22 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQoxsh12867 for ; Thu, 17 Jul 2003 09:48:19 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 17 Jul 2003 15:20:46 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.8.7.36]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6H9g50r024403; Thu, 17 Jul 2003 15:12:06 +0530 Reply-To: From: "Prabakaran T Sampath" To: "'D Siva Kumar'" , Cc: "'prabakarts'" Subject: RE: doubt reg draft-kawakami-mpls-lsp-vlan-00.txt (fwd) Date: Thu, 17 Jul 2003 15:20:14 +0530 Message-ID: <000701c34c48$d3160da0$2407080a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, For Pseudo wire emulation Edge to Edge, please refer the following links. http://www.ietf.org/html.charters/pwe3-charter.html http://www.ietf.org/internet-drafts/draft-martini-l2circuit-trans-mpls-11.tx t http://www.ietf.org/internet-drafts/draft-martini-l2circuit-encap-mpls-05.tx t http://www.ietf.org/internet-drafts/draft-martini-ethernet-encap-mpls-02.txt http://www.ietf.org/internet-drafts/draft-martini-ppp-hdlc-encap-mpls-01.txt http://www.ietf.org/internet-drafts/draft-martini-atm-encap-mpls-02.txt Thanks and regards, Prabakaran T.S. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. email : prabakarts@future.futsoft.com Off Phone: +91-44-24330550 - Extn: 319 -------------------------------------- -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of D Siva Kumar Sent: Wednesday, 16 July 2003 4:25 AM To: mpls@uu.net Subject: doubt reg draft-kawakami-mpls-lsp-vlan-00.txt (fwd) Hi, I have a doubt regarding encapsulation mentioned in above draft in section 4. Encapsulation header is shown in the draft as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ethernet source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPID 0x8100 | Pri | | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-Type 0x0800 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Network Layer Packet (IP packet) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But, in this where is the pseudowire label? directly, payload is added after the tunnel header. Correct me if I am wrong and please point some references if any, regarding this. I am a beginner in this field. expecting a reply, thanks in advance. Siva. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** From owner-mpls@UU.NET Thu Jul 17 13:51:48 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15213 for ; Thu, 17 Jul 2003 13:51:48 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxtn15021 for ; Thu, 17 Jul 2003 17:51:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxtn14802; Thu, 17 Jul 2003 17:51:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxsm11230 for mpls-outgoing; Thu, 17 Jul 2003 11:04:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxsm11194 for ; Thu, 17 Jul 2003 11:04:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxsm00964 for ; Thu, 17 Jul 2003 11:03:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxsm06783 for ; Thu, 17 Jul 2003 11:03:23 GMT Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m0.netfirms.com [209.171.43.51]) id QQoxsm06773 for ; Thu, 17 Jul 2003 11:03:23 GMT Received: (qmail 71098 invoked from network); 17 Jul 2003 11:03:22 -0000 Received: from puppy.ietf57.telekom.at (HELO Puppy) (81.160.194.120) by 0 with SMTP; 17 Jul 2003 11:03:22 -0000 Message-ID: <005701c34c53$0ac16970$78c2a051@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "'mpls@uu.net'" Cc: "Wijnen, Bert \(Bert\)" , "Thomas D. Nadeau" Subject: MPLS MIBs Date: Wed, 16 Jul 2003 22:48:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, Tom and I spend a happy hour in a brewery this evening going through MIB issues (sorry Monique and Catherine!). We have reached agreement on all remaining issues. There are no changes to LSR, LDP or TC MIBs. The only changes are to the TE MIB, and these changes are to the textual parts and the descriptions. We have agreed the textual changes that need to be made and I will do edits in the next two days. The authors will then review my changes and republish in short order. Adrian From owner-mpls@UU.NET Thu Jul 17 19:37:49 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27072 for ; Thu, 17 Jul 2003 19:37:48 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxuk17669 for ; Thu, 17 Jul 2003 23:37:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxuk17065; Thu, 17 Jul 2003 23:37:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxtc05740 for mpls-outgoing; Thu, 17 Jul 2003 15:02:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxtc05733 for ; Thu, 17 Jul 2003 15:02: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 QQoxtc17476 for ; Thu, 17 Jul 2003 15:00:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxtc18617 for ; Thu, 17 Jul 2003 15:00:48 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQoxtc18569 for ; Thu, 17 Jul 2003 15:00:45 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 17 Jul 2003 20:13:02 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.8.7.36]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6HEYJ0r030010; Thu, 17 Jul 2003 20:04:19 +0530 Reply-To: From: "Prabakaran T Sampath" To: "'Terry Lee'" , Cc: "'prabakarts'" Subject: RE: question about draft-ietf-mpls-nodeid-subobject-01.txt Date: Thu, 17 Jul 2003 20:12:29 +0530 Message-ID: <000801c34c71$a6ceec20$2407080a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000201c34c4a$5d142cc0$d9226e0a@HUAWEI.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Terry Lee, Please refer draft-ietf-mpls-soft-preemption-00.txt - Section 4.2 for this "Preemption pending" New flag defined in RRO IPv4/IPv6 Sub-Object. Thanks and regards, Prabakaran T.S. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. email : prabakarts@future.futsoft.com Off Phone: +91-44-24330550 - Extn: 319 -------------------------------------- -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Terry Lee Sent: Thursday, 17 July 2003 3:31 PM To: mpls@uu.net Subject: question about draft-ietf-mpls-nodeid-subobject-01.txt Hi In draft-ietf-mpls-nodeid-subobject-01.txt, it states there exist following flag in RRO. But I can't find in RFC2205,RFC3209 and draft-ietf-mpls-rsvp-lsp-fastreroute-03. Where can I find it ? Preemption pending: 0x10 The preempting node sets this flag if a pending preemption is in progress for the TE LSP. This indicates to the HE of this LSP that it must be re-routed as soon as possible using a make before break. Thanks and Regards, Terry Lee ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** From owner-mpls@UU.NET Thu Jul 17 19:59:56 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27656 for ; Thu, 17 Jul 2003 19:59:56 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxul02516 for ; Thu, 17 Jul 2003 23:59:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxul01313; Thu, 17 Jul 2003 23:59:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxtd15667 for mpls-outgoing; Thu, 17 Jul 2003 15:24:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxtd15659 for ; Thu, 17 Jul 2003 15:24: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 QQoxtd19251 for ; Thu, 17 Jul 2003 15:23:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxtd08273 for ; Thu, 17 Jul 2003 15:23:40 GMT Received: from sj-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-4.cisco.com [171.68.223.138]) id QQoxtd08254 for ; Thu, 17 Jul 2003 15:23:39 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6HFNWpr022614 for ; Thu, 17 Jul 2003 08:23:36 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAT10211; Thu, 17 Jul 2003 11:23:31 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6HFNV414702 for mpls@uu.net; Thu, 17 Jul 2003 11:23:31 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxtd15560 for ; Thu, 17 Jul 2003 15:21:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxtd05896 for ; Thu, 17 Jul 2003 15:19:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxtd00483 for ; Thu, 17 Jul 2003 15:19:22 GMT Received: from maildev.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxtd00423 for ; Thu, 17 Jul 2003 15:19:21 GMT Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6HFJB324149; Thu, 17 Jul 2003 11:19:11 -0400 (EDT) Message-Id: <200307171519.h6HFJB324149@maildev.avici.com> To: "David Allan" cc: "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: 'A' bit problem statement In-reply-to: Your message of "Tue, 15 Jul 2003 05:28:33 EDT." Date: Thu, 17 Jul 2003 11:19:49 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , " David Allan" writes: > > During today's MPLS session it was clear that more discussion/clarification > was required on the problem space addressed by the I-D. > > There is two aspects to the problem discussed in the draft. > > 1) Mixing e2e path testing with adjacency fault detection has coorindation > problems when failures occur. If I have an LSP hierarchy that I am pinging > at some low level, and a failure occurs, some number of the pings will be > affected, and a response/alarm management will be hard to synchronize as > ping sources are not local to the fault (and the fault may also be detected > locally, e.g. link failure). IMHO this is an artifact of the delta between > using ping to reactively to check routing policy vs. using ping proactively > to detect data plane failures. Prioritize alarms and there is no problem. There will be one link failure detected that indicates a problem for the NOC to investigate. LSPs will reroute and all ping errors should promptly go away. The pings serve a different purpose. In theory they should not be needed, but if there is no link fault and a ping stops working, there is a forwarding plane failure somewhere that needs attention. If this is not an extremely rare situation, get new routers. > 2) Reserved labels define functions instead of forwarding. Fate sharing > between functions and LSPs is useful. Currently ECMP breaks fate sharing > between LSPs and LSP functions defined by reserved labels. Give up already. ECMP is deployed and the providers that use it have no plans to stop using it. > The answer to #1 is to try to localize detection of data plane problems, the > ability to do the equivalent of the router alert label that fate shares with > the LSP is one potential mechanism that could be used to increase locality > in detecting data plane problems. Specific data plane flows could be > inspected for consistency by intermediate LSRs as they were forwarded down > the path. > > The answer to #2 is to provide an alternative to reserved labels for LSP > functions, the MPLS/PW PID is a candidate for doing this. The 'A' bit was > one example of providing such functionality by defining a replacement for > router alert. A side note is that there is a much higher liklihood of > commonality of forwarding of a solution that had the label of interest as > the top label vs. prepending with the router alert label. > > Comments? > > cheers > Dave #1 is a non-problem. I'm not sure what you perceive to be the problem in #2. Could you be more specific. Router-alert for MPLS defeats the fast forwarding and also does not test forwarding because it does not take the same path. Curtis From owner-mpls@UU.NET Thu Jul 17 20:13:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28000 for ; Thu, 17 Jul 2003 20:13:54 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxum12293 for ; Fri, 18 Jul 2003 00:13:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxum12129; Fri, 18 Jul 2003 00:13:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxte16525 for mpls-outgoing; Thu, 17 Jul 2003 15:37:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxte16520 for ; Thu, 17 Jul 2003 15:37: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 QQoxte07978 for ; Thu, 17 Jul 2003 15:36:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxte03968 for ; Thu, 17 Jul 2003 15:36:56 GMT Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m0.netfirms.com [209.171.43.51]) id QQoxte03963 for ; Thu, 17 Jul 2003 15:36:56 GMT Received: (qmail 7259 invoked from network); 17 Jul 2003 15:36:54 -0000 Received: from puppy.ietf57.telekom.at (HELO Puppy) (81.160.194.120) by 0 with SMTP; 17 Jul 2003 15:36:54 -0000 Message-ID: <004401c34c79$40fad500$78c2a051@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'mpls@uu.net'" , References: <200307171529.h6HFTG325057@maildev.avici.com> Subject: Re: Running out of RSVP-TE bits? Date: Thu, 17 Jul 2003 16:36:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Curtis, Thanks for your opinion. > > draft-iwata-mpls-crankback-06.txt uses all of the remaining > > Session Attribute bits. > > Get rid of draft-iwata-mpls-crankback-06.txt. It will cause more > problems than it will solve, not just due to the use of RRO bits. It doesn't use any RRO bits. Perhpas you could summarize some of the problems crankback will cause. It would be good to get comments on these problems from the ITU-T members who have made this an ASON requirement. > Soft preempt is a ISP requested feature (Global Crossing) and clearly > the most useful of the features requesting this bit space. That is not at issue. The question is how to manage the remaining bits and how to handle future needs for bits. > There may be other ways to accommodate the needs of > draft-ietf-mpls-nodeid-subobject-01.txt, namely a new sub-object type > for a IPv4 or IPv6 address that happens to be a router-ID. Indeed. Adrian From owner-mpls@UU.NET Thu Jul 17 20:16:44 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28069 for ; Thu, 17 Jul 2003 20:16:43 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxun18450 for ; Fri, 18 Jul 2003 00:16:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxun18251; Fri, 18 Jul 2003 00:16:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxte16237 for mpls-outgoing; Thu, 17 Jul 2003 15:32:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxte16229 for ; Thu, 17 Jul 2003 15:32:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxte05991 for ; Thu, 17 Jul 2003 15:31:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxte21545 for ; Thu, 17 Jul 2003 15:31:40 GMT Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQoxte21534 for ; Thu, 17 Jul 2003 15:31:40 GMT Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2003 08:36:26 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6HFVbuJ006685 for ; Thu, 17 Jul 2003 08:31:38 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAT11243; Thu, 17 Jul 2003 11:31:36 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6HFVaK15149 for mpls@uu.net; Thu, 17 Jul 2003 11:31:36 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxtd16001 for ; Thu, 17 Jul 2003 15:29:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxtd25333 for ; Thu, 17 Jul 2003 15:29:30 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxtd17882 for ; Thu, 17 Jul 2003 15:29:30 GMT Received: from maildev.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxtd17864 for ; Thu, 17 Jul 2003 15:29:29 GMT Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6HFTG325057; Thu, 17 Jul 2003 11:29:17 -0400 (EDT) Message-Id: <200307171529.h6HFTG325057@maildev.avici.com> To: "Adrian Farrel" cc: "'mpls@uu.net'" , ccamp@ops.ietf.org Reply-To: curtis@fictitious.org Subject: Re: Running out of RSVP-TE bits? In-reply-to: Your message of "Tue, 15 Jul 2003 17:37:02 BST." <003601c34aef$67d5f460$78c2a051@Puppy> Date: Thu, 17 Jul 2003 11:29:50 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <003601c34aef$67d5f460$78c2a051@Puppy>, "Adrian Farrel" writes: > [cross-posted to ccamp and mpls lists] > > draft-iwata-mpls-crankback-06.txt uses all of the remaining > Session Attribute bits. Get rid of draft-iwata-mpls-crankback-06.txt. It will cause more problems than it will solve, not just due to the use of RRO bits. Soft preempt is a ISP requested feature (Global Crossing) and clearly the most useful of the features requesting this bit space. There may be other ways to accommodate the needs of draft-ietf-mpls-nodeid-subobject-01.txt, namely a new sub-object type for a IPv4 or IPv6 address that happens to be a router-ID. Curtis From owner-mpls@UU.NET Thu Jul 17 22:26:55 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00589 for ; Thu, 17 Jul 2003 22:26:54 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxuv22813 for ; Fri, 18 Jul 2003 02:26:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxuv22603; Fri, 18 Jul 2003 02:26:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxtm02155 for mpls-outgoing; Thu, 17 Jul 2003 17:39:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxtm02146 for ; Thu, 17 Jul 2003 17:39: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 QQoxtm01138 for ; Thu, 17 Jul 2003 17:37:43 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxtm20682 for ; Thu, 17 Jul 2003 17:37:43 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQoxtm20673 for ; Thu, 17 Jul 2003 17:37:42 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6HHbHw11239; Thu, 17 Jul 2003 13:37:17 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jul 2003 13:37:18 -0400 Message-ID: From: "David Allan" To: "'curtis@fictitious.org'" Cc: "'mpls@UU.NET'" Subject: RE: 'A' bit problem statement Date: Thu, 17 Jul 2003 13:37:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34C8A.0FDDDF24" 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_01C34C8A.0FDDDF24 Content-Type: text/plain; charset="iso-8859-1" Curtis: 1) Alarm prioritization is a good suggestion, I'll think about it. Although it is still hard to delegate anything if the reporting NE is not local to the problem. 2) no-one is suggesting not using ECMP. 3) I agree with the statement RA does not follow the same path. cheers Dave > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@laptoy770.fictitious.org] > Sent: Thursday, July 17, 2003 11:20 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: 'mpls@UU.NET' > Subject: Re: 'A' bit problem statement > > > > In message > om>, " David Allan" writes: > > > > During today's MPLS session it was clear that more > > discussion/clarification was required on the problem space > addressed > > by the I-D. > > > > There is two aspects to the problem discussed in the draft. > > > > 1) Mixing e2e path testing with adjacency fault detection has > > coorindation problems when failures occur. If I have an LSP > hierarchy > > that I am pinging at some low level, and a failure occurs, > some number > > of the pings will be affected, and a response/alarm > management will be > > hard to synchronize as ping sources are not local to the fault (and > > the fault may also be detected locally, e.g. link failure). > IMHO this > > is an artifact of the delta between using ping to > reactively to check > > routing policy vs. using ping proactively to detect data plane > > failures. > > Prioritize alarms and there is no problem. There will be one > link failure detected that indicates a problem for the NOC to > investigate. LSPs will reroute and all ping errors should > promptly go away. > > The pings serve a different purpose. In theory they should > not be needed, but if there is no link fault and a ping stops > working, there is a forwarding plane failure somewhere that > needs attention. If this is not an extremely rare situation, > get new routers. > > > 2) Reserved labels define functions instead of forwarding. Fate > > sharing between functions and LSPs is useful. Currently ECMP breaks > > fate sharing between LSPs and LSP functions defined by reserved > > labels. > > Give up already. ECMP is deployed and the providers that use > it have no plans to stop using it. > > > The answer to #1 is to try to localize detection of data plane > > problems, the ability to do the equivalent of the router > alert label > > that fate shares with the LSP is one potential mechanism > that could be > > used to increase locality in detecting data plane problems. > Specific > > data plane flows could be inspected for consistency by intermediate > > LSRs as they were forwarded down the path. > > > > The answer to #2 is to provide an alternative to reserved > labels for > > LSP functions, the MPLS/PW PID is a candidate for doing > this. The 'A' > > bit was one example of providing such functionality by defining a > > replacement for router alert. A side note is that there is a much > > higher liklihood of commonality of forwarding of a solution > that had > > the label of interest as the top label vs. prepending with > the router > > alert label. > > > > Comments? > > > > cheers > > Dave > > #1 is a non-problem. > > I'm not sure what you perceive to be the problem in #2. > Could you be more specific. Router-alert for MPLS defeats > the fast forwarding and also does not test forwarding because > it does not take the same path. > > Curtis > ------_=_NextPart_001_01C34C8A.0FDDDF24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: 'A' bit problem statement

Curtis:

1) Alarm prioritization is a good suggestion, I'll = think about it. Although it is still hard to delegate anything if the = reporting NE is not local to the problem.

2) no-one is suggesting not using ECMP.

3) I agree with the statement RA does not follow the = same path.

cheers
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@laptoy770.= fictitious.org]
> Sent: Thursday, July 17, 2003 11:20 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'mpls@UU.NET'
> Subject: Re: 'A' bit problem statement
>
>
>
> In message
> = <FFFC48AEAA5F7447929F4F0D93FCC12D02B922F6@zcard031.ca.nortel.c=
> om>, " David Allan" writes:
> >
> > During today's MPLS session it was clear = that more
> > discussion/clarification was required on = the problem space
> addressed
> > by the I-D.
> >
> > There is two aspects to the problem = discussed in the draft.
> >
> > 1) Mixing e2e path testing with adjacency = fault detection has
> > coorindation problems when failures occur. = If I have an LSP
> hierarchy
> > that I am pinging at some low level, and a = failure occurs,
> some number
> > of the pings will be affected, and a = response/alarm
> management will be
> > hard to synchronize as ping sources are = not local to the fault (and
> > the fault may also be detected locally, = e.g. link failure).
> IMHO this
> > is an artifact of the delta between using = ping to
> reactively to check
> > routing policy vs. using ping proactively = to detect data plane
> > failures.
>
> Prioritize alarms and there is no = problem.  There will be one
> link failure detected that indicates a problem = for the NOC to
> investigate. LSPs will reroute and all ping = errors should
> promptly go away.
>
> The pings serve a different purpose.  In = theory they should
> not be needed, but if there is no link fault = and a ping stops
> working, there is a forwarding plane failure = somewhere that
> needs attention.  If this is not an = extremely rare situation,
> get new routers.
>
> > 2) Reserved labels define functions = instead of forwarding. Fate
> > sharing between functions and LSPs is = useful. Currently ECMP breaks
> > fate sharing between LSPs and LSP = functions defined by reserved
> > labels.
>
> Give up already.  ECMP is deployed and the = providers that use
> it have no plans to stop using it.
>
> > The answer to #1 is to try to localize = detection of data plane
> > problems, the ability to do the equivalent = of the router
> alert label
> > that fate shares with the LSP is one = potential mechanism
> that could be
> > used to increase locality in detecting = data plane problems.
> Specific
> > data plane flows could be inspected for = consistency by intermediate
> > LSRs as they were forwarded down the = path.
> >
> > The answer to #2 is to provide an = alternative to reserved
> labels for
> > LSP functions, the MPLS/PW PID is a = candidate for doing
> this. The 'A'
> > bit was one example of providing such = functionality by defining a
> > replacement for router alert. A side note = is that there is a much
> > higher liklihood of commonality of = forwarding of a solution
> that had
> > the label of interest as the top label vs. = prepending with 
> the router
> > alert label.
> >
> > Comments?
> >
> > cheers
> > Dave
>
> #1 is a non-problem.
>
> I'm not sure what you perceive to be the = problem in #2. 
> Could you be more specific.  Router-alert = for MPLS defeats
> the fast forwarding and also does not test = forwarding because
> it does not take the same path.
>
> Curtis
>

------_=_NextPart_001_01C34C8A.0FDDDF24-- From owner-mpls@UU.NET Thu Jul 17 22:31:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00673 for ; Thu, 17 Jul 2003 22:31:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxuw10076 for ; Fri, 18 Jul 2003 02:31:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxuw09505; Fri, 18 Jul 2003 02:30:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxtt16579 for mpls-outgoing; Thu, 17 Jul 2003 19:15:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoxtt16387 for ; Thu, 17 Jul 2003 19:15:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxts18701 for ; Thu, 17 Jul 2003 19:13:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxts10393 for ; Thu, 17 Jul 2003 19:13:43 GMT Received: from smtp018.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp018.mail.yahoo.com [216.136.174.115]) id QQoxts10382 for ; Thu, 17 Jul 2003 19:13:43 GMT Received: from 12-234-100-254.client.attbi.com (HELO METANOIA) (vsharma87@12.234.100.254 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jul 2003 19:13:42 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" , "MPLS" , "PPVPN" , "PEW3" Cc: "Tom Nadeau" , "Monique J. Morrow" Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers Date: Thu, 17 Jul 2003 12:13:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Thanks to those who responded to our earlier announcement of this Feature Topic issue, with an intent to contribute. For those who may have missed the earlier email, or for those who've been working in this area and thinking of contributing, we'd very much encourage you to consider sending in your contributions. It is your high-quality papers, thoughts, and insights that will make this issue a valuable one for our industry. So, if you'd like to submit a paper or if you have a question or clarification, please do drop one of the Guest Editors a note, as that is very useful in helping us plan the issue. We look forward to your participation! Thanks, -Vishal PS: The submission process is automated and very easy. Pl. check instructions below. ************************************* Vishal Sharma Metanoia, Inc. http://www.metanoia-inc.com ************************************* ==================================================================== CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "OAM in MPLS-Based Networks" ********************************************** As carriers and service providers converge multiple services and associated networks on to an MPLS-based infrastructure, OAM functionality becomes pivotal for enabling them to provide service level agreement (SLA) guarantees, service assurance, quality of service (QoS) assurance and overall interworking service management. The advent of new applications of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs) also means the emergence of added OAM requirements from operators deploying those networks. As a result, providers today require more efficient means of monitoring network health, performance, and robustness, and of quickly identifying and resolving performance problems. This is leading to the emergence of improved or novel tools and techniques, whose goal is to improve security and billing/accounting, aid in verifying QoS commitments, and reduce operating costs. Standards organizations such as the IETF and the ITU have in the recent past done significant work in this area, and this subject is also being investigated by the IEEE and the Metro Ethernet Forum. This feature topic issue of the IEEE Communications Magazine has a dual focus: to highlight operator requirements and deployment experiences with OAM in MPLS-based networks, and to present a survey of the current engineering and research developments in this area. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but not limited to) the following: * Operational consequences of inadequate OAM capabilities * Service provider requirements for efficient OAM - current operational needs and future demands * Deployment experiences with OAM over MPLS-based networks * Overview or comparative analysis of different approaches/philosophies for OAM * Standards activities o Emerging architectures o New mechanisms for OAM in development (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit connection verification (VCCV)) * Platform support for OAM * OAM impact on edge services (such as metro Ethernet) using MPLS transport * Interoperability issues, interworking with other technologies (e.g. ATM) * Review of current research in the area - E.g. setting parameters for connectivity verification and their impact on LSP recovery, trade-offs between bandwidth usage by OAM traffic and efficiency of failure/anomaly detection, and results from testbed deployments or simulations On-line CFP with submission instructions can be found at: http://www.comsoc.org/pubs/commag/cfpcommag1004.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at: http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no later than November 30, 2003. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Schedule: Manuscript Due: November 30, 2003 Acceptance Notification: February 28, 2004 Final Manuscript Due: April 15, 2004 Publication Date: October 2004 Guest Editors: Monique J. Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Tom Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824, USA. Email: tnadeau@cisco.com Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA. Email: v.sharma@ieee.org About the IEEE Communications Magazine: The IEEE Comm. Mag. is the official technical publication of conferences such as Supercomm, and has the unique distinction of being the most widely read IEEE journal, with its over 50,000 paid subscribers representing key communications engineers and technical managers in our industry. More information on the IEEE Comm. Mag., may be found here: www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt From owner-mpls@UU.NET Thu Jul 17 23:52:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02868 for ; Thu, 17 Jul 2003 23:52:16 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxvb11270 for ; Fri, 18 Jul 2003 03:52:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxvb10711; Fri, 18 Jul 2003 03:52:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxts15058 for mpls-outgoing; Thu, 17 Jul 2003 19:06:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxts15015 for ; Thu, 17 Jul 2003 19:06: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 QQoxts14819 for ; Thu, 17 Jul 2003 19:06:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxts28455 for ; Thu, 17 Jul 2003 19:06:09 GMT Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQoxts28441 for ; Thu, 17 Jul 2003 19:06:09 GMT Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2003 12:10:57 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6HJ65uJ024305 for ; Thu, 17 Jul 2003 12:06:05 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAT36623; Thu, 17 Jul 2003 15:06:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6HJ64o19425 for mpls@uu.net; Thu, 17 Jul 2003 15:06:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxts07172 for ; Thu, 17 Jul 2003 19:02: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 QQoxts00327 for ; Thu, 17 Jul 2003 19:01:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxts21716 for ; Thu, 17 Jul 2003 19:01:58 GMT Received: from ams-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQoxts21701 for ; Thu, 17 Jul 2003 19:01:57 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6HIxYHM001261; Thu, 17 Jul 2003 20:59:34 +0200 (MET DST) Received: from jvasseur-w2k01.cisco.com ([10.49.250.168]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA13347; Thu, 17 Jul 2003 21:01:26 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030717205658.06333a70@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 21:01:17 +0200 To: Terry Lee From: Jean Philippe Vasseur Subject: Re: question about draft-ietf-mpls-nodeid-subobject-01.txt Cc: mpls@UU.NET In-Reply-To: <000201c34c4a$5d142cc0$d9226e0a@HUAWEI.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 06:01 PM 7/17/2003 +0800, Terry Lee wrote: >Hi > In draft-ietf-mpls-nodeid-subobject-01.txt, it states there exist >following flag in RRO. But I can't find in RFC2205,RFC3209 and >draft-ietf-mpls-rsvp-lsp-fastreroute-03. Where can I find it ? > > Preemption pending: 0x10 > The preempting node sets this flag if a pending preemption is > in progress for the TE LSP. This indicates to the HE of this > LSP that it must be re-routed as soon as possible using a make > before break. The preemption pending flag is defined in draft-ietf-mpls-soft-preemption-00.txt JP. >Thanks and Regards, >Terry Lee From owner-mpls@UU.NET Fri Jul 18 01:01:43 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04436 for ; Fri, 18 Jul 2003 01:01:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxvg23671 for ; Fri, 18 Jul 2003 05:01:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxvg23521; Fri, 18 Jul 2003 05:01:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxvc04000 for mpls-outgoing; Fri, 18 Jul 2003 04:01:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxvc03920 for ; Fri, 18 Jul 2003 04:01: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 QQoxvc10294 for ; Fri, 18 Jul 2003 04:01:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxvc13237 for ; Fri, 18 Jul 2003 04:01:00 GMT Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoxvc13220 for ; Fri, 18 Jul 2003 04:01:00 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6I40vuD010213 for ; Thu, 17 Jul 2003 21:00:57 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAT74791; Fri, 18 Jul 2003 00:00:56 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6I40up29344 for mpls@uu.net; Fri, 18 Jul 2003 00:00:56 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxvb23179 for ; Fri, 18 Jul 2003 03: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 QQoxvb01270 for ; Fri, 18 Jul 2003 03:58:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxvb11373 for ; Fri, 18 Jul 2003 03:58:08 GMT Received: from maildev.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoxvb11351 for ; Fri, 18 Jul 2003 03:58:07 GMT Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6I3vK301020; Thu, 17 Jul 2003 23:57:21 -0400 (EDT) Message-Id: <200307180357.h6I3vK301020@maildev.avici.com> To: "Adrian Farrel" cc: curtis@fictitious.org, "'mpls@uu.net'" , ccamp@ops.ietf.org Reply-To: curtis@fictitious.org Subject: Re: Running out of RSVP-TE bits? In-reply-to: Your message of "Thu, 17 Jul 2003 16:36:48 BST." <004401c34c79$40fad500$78c2a051@Puppy> Date: Thu, 17 Jul 2003 23:57:59 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <004401c34c79$40fad500$78c2a051@Puppy>, "Adrian Farrel" writes: > > Perhpas you could summarize some of the problems crankback will cause. > It would be good to get comments on these problems from the ITU-T members who > have made > this an ASON requirement. After a link fails zero to a large number of admission failures may occur on a few links that are considered desireable alternates (by multiple LSP ingress, each acting independently). Crankback will provide individual signals to each ingress, probably for each LSP that failed. Just using the IGP flooding is far more efficient and proactively tells ingress that haven't sent LSP paths over the now overloaded link. Of course if you write specs before trying things you often get things wrong, particularly where the dynamics of a protocol are concerned. That's where the running code thing comes in. I think testing in an environment where lots of LSP from many ingress traverse a link that fails and all route to one or two links that become overloaded should be a prerequisite for crankback, with improvement demonstrated. Curtis ps - who cares about ASON? or ITU for that matter? :-) From owner-mpls@UU.NET Fri Jul 18 11:40:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04036 for ; Fri, 18 Jul 2003 11:40:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxww04137 for ; Fri, 18 Jul 2003 15:40:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxww03890; Fri, 18 Jul 2003 15:40:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxwp13466 for mpls-outgoing; Fri, 18 Jul 2003 13:49:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoxwp13461 for ; Fri, 18 Jul 2003 13:49:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoxwp21612 for ; Fri, 18 Jul 2003 13:49:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxwp20307 for ; Fri, 18 Jul 2003 13:49:14 GMT Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoxwp20281 for ; Fri, 18 Jul 2003 13:49:14 GMT Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 18 Jul 2003 06:49:05 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6IDn9uI006730 for ; Fri, 18 Jul 2003 06:49:11 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAT97078; Fri, 18 Jul 2003 09:49:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6IDn8803489 for mpls@uu.net; Fri, 18 Jul 2003 09:49:08 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoxuq03217 for ; Fri, 18 Jul 2003 01:10:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxuq27220 for ; Fri, 18 Jul 2003 01:10:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxuq19203 for ; Fri, 18 Jul 2003 01:10:38 GMT Received: from web9506.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web9506.mail.yahoo.com [216.136.129.20]) id QQoxuq19157 for ; Fri, 18 Jul 2003 01:10:36 GMT Message-ID: <20030718011035.70579.qmail@web9506.mail.yahoo.com> Received: from [65.241.132.112] by web9506.mail.yahoo.com via HTTP; Thu, 17 Jul 2003 18:10:35 PDT Date: Thu, 17 Jul 2003 18:10:35 -0700 (PDT) From: Gopalkrishna Panicker Subject: RSVP Fastreroute To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk All, I have a few questions on RSVP fastreroute (draft-ietf -mpls-rsvp-lsp-fastreroute-03.txt) Consider the following network, A---B---C---D---E---G | | | |---F-------| Assume the following The protected LSP has a ERO (ABCDEG) 1-to-1 backup is being employed. All nodes are using Sender Template Method of backup identification Also, B creats a backup LSP with ERO (BFEG) C creats a backup LSP with ERO (CFEG). If I understand section 7.1.1 (Merging Backup Paths using the sender template specific method) correctly, one (and only one) path message will be sent/refreshed from nodes F to E. The sender template in this path message will belong to the winner of this merge. Is this correct ? If so shouldn't the traffic spec of this final path message reflect the traffic requirements of the messages that have been merged. Is this what the authors mean when they say in paragraph 2 (line # 2)of section 7.1.1, "Similar to that specified in [RSVP-TE] for merging of RESV messages,". So, if fastreroute is not being used, merging will still occur the way I have described above (assuming ofcourse that I am correct in the first place). If not, at a detour merge point how can I tell the difference between a detour LSP ( no DETOUR object ) and a regular non-fastrerouteable LSP i.e one should be merged and one should not. Thanks in advance, Cheers, Gopal __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From owner-mpls@UU.NET Fri Jul 18 17:52:19 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14483 for ; Fri, 18 Jul 2003 17:52:19 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxxv11953 for ; Fri, 18 Jul 2003 21:52:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxxv11903; Fri, 18 Jul 2003 21:52:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxxn03454 for mpls-outgoing; Fri, 18 Jul 2003 19:57:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxxn03445 for ; Fri, 18 Jul 2003 19:57: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 QQoxxn27174 for ; Fri, 18 Jul 2003 19:57:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxxn04608 for ; Fri, 18 Jul 2003 19:57:13 GMT Received: from sj-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-4.cisco.com [171.68.223.138]) id QQoxxn04569 for ; Fri, 18 Jul 2003 19:57:10 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6IJv7pp025824 for ; Fri, 18 Jul 2003 12:57:07 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAU35358; Fri, 18 Jul 2003 15:57:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6IJv5E08945 for mpls@uu.net; Fri, 18 Jul 2003 15:57:05 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxxn03411 for ; Fri, 18 Jul 2003 19:56: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 QQoxxn22957 for ; Fri, 18 Jul 2003 19:56:00 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxxn28668 for ; Fri, 18 Jul 2003 19:56:00 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQoxxn28655 for ; Fri, 18 Jul 2003 19:55:59 GMT Received: from juniper.net (lookout.juniper.net [172.17.20.54]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6IJtXu51969; Fri, 18 Jul 2003 12:55:33 -0700 (PDT) (envelope-from dhg@juniper.net) Message-Id: <200307181955.h6IJtXu51969@merlot.juniper.net> To: Nic Neate cc: Ping Pan , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" , "'mpls@uu.net'" Subject: Re: Suggested improvements to the Path-Specific merge rules in dr aft- ietf-mpls-rsvp-lsp-fastreroute-03 In-reply-to: Your message of Tue, 15 Jul 2003 13:26:48 +0100. <53F74F5A7B94D511841C00B0D0AB16F80287059F@baker.datcon.co.uk> Date: Fri, 18 Jul 2003 12:55:33 -0700 From: Der-Hwa Gan Sender: owner-mpls@UU.NET Precedence: bulk What do you guys think of the following text from Nic? I made a small adjustment to part of the sentence (marked by ^^^), but didn't change anything else. I think the merging rules are identical in semantics to what I last proposed, even though the number of rules further reduce by 1. It is possible to see detours conflict with each other that MP cannot find a final Path message that satisfy all of them. In that case, the additional text in rule 3 is necessary, as well as the last paragraph. In the last paragraph, is it better to send patherr messages and fail the merging, or simply pick one of the detours and continue the merge? If we pick continue, some of the detours will provide link protections but not node protection. Is that acceptable? Thanks to Nic for pointing out the potential merging problem. Der-Hwa For all the Path messages that share the same outgoing interface and next-hop LSR, the MP runs the following procedure to identify a Path message to forward downstream. 1. If one or more of the Path messages is for the protected LSP (a protected LSP is one originated from this node, or with ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the FAST_REROUTE object, or without the DETOUR object), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ one of these must become the chosen Path message. There could ^^^^^^^^^^^ be more than one in the case that the protected LSP is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ being rerouted. In that case it is a local decision to choose which one to forward. Quit. 2. From the remaining set of detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid. 3. If several still remain, it is a local decision to choose which one to forward. If none remain, then the MP may try and find a new route that does avoid all nodes that all merging detour Paths want to avoid and forward a Path message with that ERO. Once the final Path message has been identified, the MP MUST start to refresh it downstream periodically. Other LSPs are considered merged at this node. For bandwidth reservation on the outgoing link, any merging should be considered to have occured before bandwidth is reserved. Thus, even though Fixed Filter is specified, multiple detours and/or their protected LSP which are to be merged due to sharing an outgoing interface and next-hop LSR will reserve only the bandwidth of the final Path message on that outgoing interface. If no merged Path message can be constructed then the MP SHOULD send a PathErr in response to the most recently received detour Path message. If a protected Path is chosen to be forwarded, but it traverses nodes that some detours want to avoid, PathErrs should be sent in response to those detour Paths which cannot merge. From owner-mpls@UU.NET Sat Jul 19 07:46:42 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11888 for ; Sat, 19 Jul 2003 07:46:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxzz09130 for ; Sat, 19 Jul 2003 11:46:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoxzz08961; Sat, 19 Jul 2003 11:46:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQoxzj10663 for mpls-outgoing; Sat, 19 Jul 2003 07:59:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoxzj10656 for ; Sat, 19 Jul 2003 07:59:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoxzj14009 for ; Sat, 19 Jul 2003 07:59:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoxzj18087 for ; Sat, 19 Jul 2003 07:59:12 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQoxzj18027 for ; Sat, 19 Jul 2003 07:59:05 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sat, 19 Jul 2003 13:41:02 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.8.7.36]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6J7qa0r005251; Sat, 19 Jul 2003 13:22:37 +0530 Reply-To: From: "Prabakaran T Sampath" To: Cc: "'prabakarts'" Subject: Typo error in draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt Date: Sat, 19 Jul 2003 13:30:54 +0530 Message-Id: <003901c34dcb$e189a520$2407080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200307181955.h6IJtXu51969@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Authors/Editors, Please correct the following Typo error in draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. In Section 14. Normative References, [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC3029, December 2001. ^^^^^^^ The RFC3029 specified is a Typo error, it should be RFC3209. Thanks and regards, Prabakaran T.S. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. email : prabakarts@future.futsoft.com Off Phone: +91-44-24330550 - Extn: 319 -------------------------------------- *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Sat Jul 19 15:14:33 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21148 for ; Sat, 19 Jul 2003 15:14:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoybc16090 for ; Sat, 19 Jul 2003 19:14:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoybc15768; Sat, 19 Jul 2003 19:14:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQoyah27229 for mpls-outgoing; Sat, 19 Jul 2003 13:52:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoyah27215 for ; Sat, 19 Jul 2003 13:52:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoyah21350 for ; Sat, 19 Jul 2003 13:51:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyah13221 for ; Sat, 19 Jul 2003 13:51:48 GMT Received: from moutng.kundenserver.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: moutng.kundenserver.de [212.227.126.185]) id QQoyah13201 for ; Sat, 19 Jul 2003 13:51:46 GMT Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19ds7m-0001lP-00 for mpls@uu.net; Sat, 19 Jul 2003 15:51:46 +0200 Received: from [217.228.176.167] (helo=philipp) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19ds7m-0002ua-00 for mpls@uu.net; Sat, 19 Jul 2003 15:51:46 +0200 Message-ID: <001901c34dfc$f201afc0$2202a8c0@WorkGroup> From: "Stefan Winter" To: Subject: MIB structure error in MPLS-FTN-STD-MIB (draft 07)? Date: Sat, 19 Jul 2003 15:52:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hello, in draft-ietf-mpls-ftn-mib-07.txt there seems to be an error in the MIB definition of the mplsFTNMapTable. The table consists of five columns, which are indexed 1,2,3,5,6. There doesn´t seem to be a real reason for ordering that way; I suggest a 1,2,3,4,5 ordering. Greetings, Stefan Winter From owner-mpls@UU.NET Sat Jul 19 16:50:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22324 for ; Sat, 19 Jul 2003 16:50:41 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyau11356; Sat, 19 Jul 2003 17:00:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQoyad04264 for mpls-outgoing; Sat, 19 Jul 2003 12:46:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoyad04255 for ; Sat, 19 Jul 2003 12:46: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 QQoyad18860 for ; Sat, 19 Jul 2003 12:45:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyad22614 for ; Sat, 19 Jul 2003 12:45:20 GMT Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoyad22600 for ; Sat, 19 Jul 2003 12:45:20 GMT Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Jul 2003 05:45:24 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6JCjFuJ020964 for ; Sat, 19 Jul 2003 05:45:16 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAU71850; Sat, 19 Jul 2003 08:45:14 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6JCjEH16644 for mpls@uu.net; Sat, 19 Jul 2003 08:45:14 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoyac03623 for ; Sat, 19 Jul 2003 12:44: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 QQoyac23433 for ; Sat, 19 Jul 2003 12:43:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyac00545 for ; Sat, 19 Jul 2003 12:43:58 GMT Received: from ams-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQoyac00514 for ; Sat, 19 Jul 2003 12:43:57 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6JCfiVR002937; Sat, 19 Jul 2003 14:41:44 +0200 (MET DST) Received: from jvasseur-w2k01.cisco.com ([10.49.250.233]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA22627; Sat, 19 Jul 2003 14:43:49 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030719144334.05ba7e50@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 19 Jul 2003 14:43:48 +0200 To: From: Jean Philippe Vasseur Subject: Re: Typo error in draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt Cc: , "'prabakarts'" In-Reply-To: <003901c34dcb$e189a520$2407080a@future.futsoft.com> References: <200307181955.h6IJtXu51969@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk thanks for having noticed it JP At 01:30 PM 7/19/2003 +0530, Prabakaran T Sampath wrote: >Authors/Editors, > >Please correct the following Typo error in >draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. > >In Section 14. Normative References, > > > [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP > tunnels", RFC3029, December 2001. > ^^^^^^^ > >The RFC3029 specified is a Typo error, it should be RFC3209. > > >Thanks and regards, >Prabakaran T.S. >Future Software Limited, >480-481, Anna Salai, >Chennai - 600035, India. >email : prabakarts@future.futsoft.com >Off Phone: +91-44-24330550 - Extn: 319 >-------------------------------------- > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** From owner-mpls@UU.NET Sun Jul 20 08:55:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18052 for ; Sun, 20 Jul 2003 08:55:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoydv18130 for ; Sun, 20 Jul 2003 12:55:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoydv18051; Sun, 20 Jul 2003 12:55:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQoycx27745 for mpls-outgoing; Sun, 20 Jul 2003 06:46:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoycx27720 for ; Sun, 20 Jul 2003 06:46:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoycw05681 for ; Sun, 20 Jul 2003 06:44:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoycw04787 for ; Sun, 20 Jul 2003 06:44:06 GMT Received: from tiger.seabridge.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bzq-25-127-226.cust.bezeqint.net [212.25.127.226]) id QQoycw04552 for ; Sun, 20 Jul 2003 06:43:54 GMT Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jul 2003 09:43:12 +0200 Message-ID: From: Nurit Sprecher To: "'prabakarts@future.futsoft.com'" , mpls@UU.NET Subject: RE: Typo error in draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt Date: Sun, 20 Jul 2003 09:43:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk What is the delta between version 02 and 03? -----Original Message----- From: Prabakaran T Sampath [mailto:prabakarts@future.futsoft.com] Sent: Saturday, July 19, 2003 10:01 AM To: mpls@UU.NET Cc: 'prabakarts' Subject: Typo error in draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt Authors/Editors, Please correct the following Typo error in draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. In Section 14. Normative References, [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC3029, December 2001. ^^^^^^^ The RFC3029 specified is a Typo error, it should be RFC3209. Thanks and regards, Prabakaran T.S. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. email : prabakarts@future.futsoft.com Off Phone: +91-44-24330550 - Extn: 319 -------------------------------------- *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Mon Jul 21 10:06:19 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27837 for ; Mon, 21 Jul 2003 10:06:19 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyhs04303 for ; Mon, 21 Jul 2003 14:06:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyhs04069; Mon, 21 Jul 2003 14:06:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQoygx26075 for mpls-outgoing; Mon, 21 Jul 2003 08:56:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoygx26022 for ; Mon, 21 Jul 2003 08:56: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 QQoygx24782 for ; Mon, 21 Jul 2003 08:54:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoygx12061 for ; Mon, 21 Jul 2003 08:54:40 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoygx12049 for ; Mon, 21 Jul 2003 08:54:40 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6L8sauG005931 for ; Mon, 21 Jul 2003 01:54:37 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAV24851; Mon, 21 Jul 2003 04:54:36 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6L8saY02099 for mpls@uu.net; Mon, 21 Jul 2003 04:54:36 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoygx25856 for ; Mon, 21 Jul 2003 08:53: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 QQoygx18472 for ; Mon, 21 Jul 2003 08:48:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoygx01566 for ; Mon, 21 Jul 2003 08:48:55 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQoygx01472 for ; Mon, 21 Jul 2003 08:48:51 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 21 Jul 2003 09:48:40 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8028705C0@baker.datcon.co.uk> From: Nic Neate To: "'Der-Hwa Gan'" Cc: Ping Pan , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" , "'mpls@uu.net'" Subject: RE: Suggested improvements to the Path-Specific merge rules in dr aft- ietf-mpls-rsvp-lsp-fastreroute-03 Date: Mon, 21 Jul 2003 09:48:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk That sounds fine to me. Thanks, Nic. -----Original Message----- From: Der-Hwa Gan [mailto:dhg@juniper.net] Sent: Friday, July 18, 2003 8:56 PM To: Nic Neate Cc: Ping Pan; 'swallow@cisco.com'; 'jpv@cisco.com'; 'dcooper@gblx.net'; 'aatlas@avici.com'; 'mjork@avici.com'; 'mpls@uu.net' Subject: Re: Suggested improvements to the Path-Specific merge rules in dr aft- ietf-mpls-rsvp-lsp-fastreroute-03 What do you guys think of the following text from Nic? I made a small adjustment to part of the sentence (marked by ^^^), but didn't change anything else. I think the merging rules are identical in semantics to what I last proposed, even though the number of rules further reduce by 1. It is possible to see detours conflict with each other that MP cannot find a final Path message that satisfy all of them. In that case, the additional text in rule 3 is necessary, as well as the last paragraph. In the last paragraph, is it better to send patherr messages and fail the merging, or simply pick one of the detours and continue the merge? If we pick continue, some of the detours will provide link protections but not node protection. Is that acceptable? Thanks to Nic for pointing out the potential merging problem. Der-Hwa For all the Path messages that share the same outgoing interface and next-hop LSR, the MP runs the following procedure to identify a Path message to forward downstream. 1. If one or more of the Path messages is for the protected LSP (a protected LSP is one originated from this node, or with ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the FAST_REROUTE object, or without the DETOUR object), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ one of these must become the chosen Path message. There could ^^^^^^^^^^^ be more than one in the case that the protected LSP is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ being rerouted. In that case it is a local decision to choose which one to forward. Quit. 2. From the remaining set of detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid. 3. If several still remain, it is a local decision to choose which one to forward. If none remain, then the MP may try and find a new route that does avoid all nodes that all merging detour Paths want to avoid and forward a Path message with that ERO. Once the final Path message has been identified, the MP MUST start to refresh it downstream periodically. Other LSPs are considered merged at this node. For bandwidth reservation on the outgoing link, any merging should be considered to have occured before bandwidth is reserved. Thus, even though Fixed Filter is specified, multiple detours and/or their protected LSP which are to be merged due to sharing an outgoing interface and next-hop LSR will reserve only the bandwidth of the final Path message on that outgoing interface. If no merged Path message can be constructed then the MP SHOULD send a PathErr in response to the most recently received detour Path message. If a protected Path is chosen to be forwarded, but it traverses nodes that some detours want to avoid, PathErrs should be sent in response to those detour Paths which cannot merge. From owner-mpls@UU.NET Mon Jul 21 10:29:39 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29188 for ; Mon, 21 Jul 2003 10:29:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyht20938 for ; Mon, 21 Jul 2003 14:29:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyht20822; Mon, 21 Jul 2003 14:29:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQoyhh02319 for mpls-outgoing; Mon, 21 Jul 2003 11:23:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoyhh02312 for ; Mon, 21 Jul 2003 11:23: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 QQoyhh12066 for ; Mon, 21 Jul 2003 11:23:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyhh25074 for ; Mon, 21 Jul 2003 11:23:40 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQoyhh25018 for ; Mon, 21 Jul 2003 11:23:38 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 21 Jul 2003 13:57:57 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.8.7.36]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6L89S0r012443; Mon, 21 Jul 2003 13:39:28 +0530 Reply-To: From: "Prabakaran T Sampath" To: Cc: "'prabakarts'" Subject: RE: RSVP Fastreroute Date: Mon, 21 Jul 2003 13:48:00 +0530 Message-Id: <000001c34f60$9a362400$2407080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20030718011035.70579.qmail@web9506.mail.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Please find my in lined comments [PrabakarTS]. Thanks and regards, Prabakaran T.S. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. email : prabakarts@future.futsoft.com Off Phone: +91-44-24330550 - Extn: 319 -------------------------------------- -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Gopalkrishna Panicker Sent: Friday, 18 July 2003 6:41 AM To: mpls@uu.net Subject: RSVP Fastreroute All, I have a few questions on RSVP fastreroute (draft-ietf -mpls-rsvp-lsp-fastreroute-03.txt) Consider the following network, A---B---C---D---E---G | | | |---F-------| Assume the following The protected LSP has a ERO (ABCDEG) 1-to-1 backup is being employed. All nodes are using Sender Template Method of backup identification Also, B creats a backup LSP with ERO (BFEG) C creats a backup LSP with ERO (CFEG). If I understand section 7.1.1 (Merging Backup Paths using the sender template specific method) correctly, one (and only one) path message will be sent/refreshed from nodes F to E. The sender template in this path message will belong to the winner of this merge. Is this correct ? If so shouldn't the traffic spec of this final path message reflect the traffic requirements of the messages that have been merged. >>[PrabakarTS] IMHO, as per the draft it was more clear the merging rules >>at the point E in the above picture, for both Sender Template approach and >>Path Specific approach. >> >>In section 7.1.1, the 3rd paragraph is bit ambiguous and it is not >> addressing the issues at merge point at F, >> >> "If merging occurs and all the Path messages were for backup LSPs, >> then the DETOUR object, if any, should be altered as specified in >> Section 8.1" >> >>In the above paragraph, it was stated with reference to Path-specific >>approach(which basically uses DETOUR Object) merging rules >>in the Sender-Template specific method. >> >>Authors/some experts, please clearly clarify this may be with some >>example. >> >>For traffic spec of the merged final path message, since we are going to >>use SE style for the reservation, the final traffic spec will be the >>union of the traffic parameters of the merged LSPs. Is this what the authors mean when they say in paragraph 2 (line # 2)of section 7.1.1, "Similar to that specified in [RSVP-TE] for merging of RESV messages,". >>[PrabakarTS] Based on RFC 3209, section 2.4.3 explanation and in the >>draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, Section 7.1.1 the merging >>rule is "Outgoing interface and NHOP LSR are same and only those >>Path messages whose ERO from that LSR to the >>egress is the same can be merged." So, if fastreroute is not being used, merging will still occur the way I have described above (assuming ofcourse that I am correct in the first place). >>[PrabakarTS] The merging will occur based on section 2.4.3 in RFC3209. If not, at a detour merge point how can I tell the difference between a detour LSP ( no DETOUR object ) and a regular non-fastrerouteable LSP i.e one should be merged and one should not. >>[PrabakarTS] We can distinguish this, based on either FAST-REROUTE Object or >>Local protection desired flag set in the SESSION-ATTRIBUTE Object. Thanks in advance, Cheers, Gopal __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 22 07:40:29 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10186 for ; Tue, 22 Jul 2003 07:40:29 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyla06839 for ; Tue, 22 Jul 2003 11:40:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyla06665; Tue, 22 Jul 2003 11:40:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQoykt03064 for mpls-outgoing; Tue, 22 Jul 2003 09:49:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoykt03057 for ; Tue, 22 Jul 2003 09:49: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 QQoykt09208 for ; Tue, 22 Jul 2003 09:49:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoykt29911 for ; Tue, 22 Jul 2003 09:49:17 GMT Received: from tiger.seabridge.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bzq-25-127-226.cust.bezeqint.net [212.25.127.226]) id QQoykt29860 for ; Tue, 22 Jul 2003 09:49:13 GMT Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 12:48:29 +0200 Message-ID: From: Nurit Sprecher To: mpls@UU.NET Cc: Nurit Sprecher Subject: Multiple Instances in the mplsTunnelTable of the TE MIB Date: Tue, 22 Jul 2003 12:48:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3503E.C558A020" 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_01C3503E.C558A020 Content-Type: text/plain; charset="iso-8859-1" Hi all, If multiple instances (for example two instances) are defined in the mplsTunnelTable for the same Tunnel, and both instances are provisioned, is it possible to administratively control operations like switch over (to a backup tunnel) or switch back (for example when a primary preferred tunnel is restored)? Note that I am talking about a case where both tunnels are pre-provisioned, but the backup tunnel is idle when the primary is active. Is the mplsTunnelInstancePriority column of the mplsTunnelTable defined for this purpose? Thanks in advance, Nurit. ------_=_NextPart_001_01C3503E.C558A020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<= ![if = !supportEmptyParas]> 

=

Hi all,<= /p>

I= f multiple instances  (for = example two instances) are defined in the mplsTunnelTable for the same Tunnel, = and both instances are provisioned, is it possible to administratively control = operations like switch over (to a backup tunnel) or switch back (for example when = a primary preferred tunnel is restored)? Note that I am talking about a = case where both tunnels are pre-provisioned, but the backup tunnel is idle = when the primary is active.

I= s the mplsTunnelInstancePriority column of the mplsTunnelTable defined for this = purpose?

T= hanks in advance, Nurit.

------_=_NextPart_001_01C3503E.C558A020-- From owner-mpls@UU.NET Tue Jul 22 21:17:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02799 for ; Tue, 22 Jul 2003 21:17:02 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoynd21174 for ; Wed, 23 Jul 2003 01:17:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoynd21010; Wed, 23 Jul 2003 01:17:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQoymm07502 for mpls-outgoing; Tue, 22 Jul 2003 21:13:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoymm07495 for ; Tue, 22 Jul 2003 21:13:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoymm28576 for ; Tue, 22 Jul 2003 21:13:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoymm08669 for ; Tue, 22 Jul 2003 21:13:01 GMT Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m0.netfirms.com [209.171.43.51]) id QQoymm08648 for ; Tue, 22 Jul 2003 21:13:00 GMT Received: (qmail 93399 invoked from network); 22 Jul 2003 21:12:56 -0000 Received: from du-069-0391.access.clara.net (HELO Puppy) (217.158.145.137) by 0 with SMTP; 22 Jul 2003 21:12:56 -0000 Message-ID: <00a501c35096$06001110$0e9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'mpls@uu.net'" , References: <200307180357.h6I3vK301020@maildev.avici.com> Subject: Crankback [Was: Running out of RSVP-TE bits?] Date: Tue, 22 Jul 2003 12:43:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, I think you have possibly missed the chief use of crankback and focused on a side use. The principal use is to handle LSP setup failures. When these happen they tend to happen one at a time (that is not a whole bunch of impacted LSPs that were using a link that has failed). Crankback allows nodes on the LSP to attempt to re-direct the LSP setup attempt without failing it back to the ingress, and allows the collection of more detailed failure information to aid the re-direction process. In a nutshell, crankback targets rapid re-direction of LSP setup attempts without waiting for IGP convergence. That crankback can also be used for handling failed LSPs is an 'interesting' additional feature. Note that in no case does crankback increase the error reporting message flow. It simply adds a little information to error messages already used in RSVP-TE or GMPLS. In fact, if crankback is in use and intermediate nodes are enabled as crankback repair points, crankback can reduce the error reporting message flows since they don't have to go all the way to the ingress nodes. > > Perhaps you could summarize some of the problems crankback will cause. > > It would be good to get comments on these problems from the ITU-T members who > > have made this an ASON requirement. > > After a link fails zero to a large number of admission failures may > occur on a few links that are considered desireable alternates (by > multiple LSP ingress, each acting independently). Crankback will > provide individual signals to each ingress, probably for each LSP that > failed. Well now: the number of signals is not a function of crankback. It is an existing function of RSVP-TE error reporting. Crankback simply adds information to the error reporting so that the error may be repaired. It also recognizes that non-ingress nodes may wish to repair errors. > Just using the IGP flooding is far more efficient and > proactively tells ingress that haven't sent LSP paths over the now > overloaded link. Efficiency is in the eye of the beholder on this issue. The debate over flooding or signaling errors will probably go on for a while (see Richard Rabbat's work in ccamp on the need for a flooding mechanism for fail-over to a protection LSP that may be carrying extra traffic). The efficiency surely depends on the number of LSPs and the number of nodes/links in the network. To repeat: the crankback draft doesn't make any assumptions about the efficiency, it simply uses existing mechanisms. In fact, there is a significant issue with the use of a flooding mechanism. Viz. the ingress may not be able to tell from a description of the faulted resource which LSPs were impacted - suppose a component link fails, or even an individual laser. (You might as well say that soft pre-emption should be reported through flooding!) > Of course if you write specs before trying things you often get things > wrong, particularly where the dynamics of a protocol are concerned. > That's where the running code thing comes in. I agree with you whole-heartedly. It is so important to have running code. Not sure why you bring it up in this context. Are you trying to imply something? > I think testing in an > environment where lots of LSP from many ingress traverse a link that > fails and all route to one or two links that become overloaded should > be a prerequisite for crankback, with improvement demonstrated. As in my preamble, this is not what crankback is about. > > Curtis > > ps - who cares about ASON? or ITU for that matter? :-) Cheers, Adrian From owner-mpls@UU.NET Wed Jul 23 12:13:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18478 for ; Wed, 23 Jul 2003 12:13:40 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypk21062 for ; Wed, 23 Jul 2003 16:13:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoypk20898; Wed, 23 Jul 2003 16:13:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQoypa18453 for mpls-outgoing; Wed, 23 Jul 2003 13:37:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoypa18448 for ; Wed, 23 Jul 2003 13:37:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoypa14840 for ; Wed, 23 Jul 2003 13:37:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypa06317 for ; Wed, 23 Jul 2003 13:37:27 GMT Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQoypa06298 for ; Wed, 23 Jul 2003 13:37:27 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6NDb5g04015; Wed, 23 Jul 2003 09:37:06 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 09:37:06 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E607178852@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Adrian Farrel , curtis@fictitious.org Cc: "'mpls@uu.net'" , ccamp@ops.ietf.org Subject: RE: Crankback [Was: Running out of RSVP-TE bits?] Date: Wed, 23 Jul 2003 09:37:05 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Adrian Two points in support of your arguments: Crankback and our related draft feedback have proven with running code in many systems to improve the response to failures. Historically both systems started by relying on the solely on IGP and then improving the situation where the IGP cannot/should not keep up with the rapid changes in bandwidth (not connectivity) that happen with a redistribution of paths. Cheers, Don > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, July 22, 2003 7:44 AM > To: curtis@fictitious.org > Cc: 'mpls@uu.net'; ccamp@ops.ietf.org > Subject: Crankback [Was: Running out of RSVP-TE bits?] > > > Curtis, > > I think you have possibly missed the chief use of crankback > and focused on a side use. > > The principal use is to handle LSP setup failures. When these > happen they tend to happen one at a time (that is not a whole > bunch of impacted LSPs that were using a link that has > failed). Crankback allows nodes on the LSP to attempt to > re-direct the LSP setup attempt without failing it back to > the ingress, and allows the collection of more detailed > failure information to aid the re-direction process. > > In a nutshell, crankback targets rapid re-direction of LSP > setup attempts without waiting for IGP convergence. That > crankback can also be used for handling failed LSPs is an > 'interesting' additional feature. > > Note that in no case does crankback increase the error > reporting message flow. It simply adds a little information > to error messages already used in RSVP-TE or GMPLS. In fact, > if crankback is in use and intermediate nodes are enabled as > crankback repair points, crankback can reduce the error > reporting message flows since they don't have to go all the > way to the ingress nodes. > > > > Perhaps you could summarize some of the problems crankback will > > > cause. It would be good to get comments on these problems > from the > > > ITU-T members who have made this an ASON requirement. > > > > After a link fails zero to a large number of admission failures may > > occur on a few links that are considered desireable alternates (by > > multiple LSP ingress, each acting independently). Crankback will > > provide individual signals to each ingress, probably for > each LSP that > > failed. > > Well now: the number of signals is not a function of > crankback. It is an existing function of RSVP-TE error > reporting. Crankback simply adds information to the error > reporting so that the error may be repaired. It also > recognizes that non-ingress nodes may wish to repair errors. > > > Just using the IGP flooding is far more efficient and proactively > > tells ingress that haven't sent LSP paths over the now overloaded > > link. > > Efficiency is in the eye of the beholder on this issue. The > debate over flooding or signaling errors will probably go on > for a while (see Richard Rabbat's work in ccamp on the need > for a flooding mechanism for fail-over to a protection LSP > that may be carrying extra traffic). The efficiency surely > depends on the number of LSPs and the number of nodes/links > in the network. > > To repeat: the crankback draft doesn't make any assumptions > about the efficiency, it simply uses existing mechanisms. In > fact, there is a significant issue with the use of a flooding > mechanism. Viz. the ingress may not be able to tell from a > description of the faulted resource which LSPs were impacted > - suppose a component link fails, or even an individual > laser. (You might as well say that soft pre-emption should be > reported through > flooding!) > > > Of course if you write specs before trying things you often > get things > > wrong, particularly where the dynamics of a protocol are concerned. > > That's where the running code thing comes in. > > I agree with you whole-heartedly. It is so important to have > running code. Not sure why you bring it up in this context. > Are you trying to imply something? > > > I think testing in an > > environment where lots of LSP from many ingress traverse a > link that > > fails and all route to one or two links that become > overloaded should > > be a prerequisite for crankback, with improvement demonstrated. > > As in my preamble, this is not what crankback is about. > > > > > Curtis > > > > ps - who cares about ASON? or ITU for that matter? :-) > > Cheers, > Adrian > > > From owner-mpls@UU.NET Wed Jul 23 12:30:28 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18985 for ; Wed, 23 Jul 2003 12:30:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypm17980 for ; Wed, 23 Jul 2003 16:30:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoypm17511; Wed, 23 Jul 2003 16:30:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQoypd10547 for mpls-outgoing; Wed, 23 Jul 2003 14:25:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoypd10533 for ; Wed, 23 Jul 2003 14:24:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoypd28765 for ; Wed, 23 Jul 2003 14:23:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypd14284 for ; Wed, 23 Jul 2003 14:23:52 GMT Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQoypd14224 for ; Wed, 23 Jul 2003 14:23:51 GMT Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2003 07:24:54 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6NENl89026067 for ; Wed, 23 Jul 2003 07:23:48 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX33279; Wed, 23 Jul 2003 10:23:46 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6NENkP27063 for mpls@uu.net; Wed, 23 Jul 2003 10:23:46 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoypc08609 for ; Wed, 23 Jul 2003 14:07: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 QQoypc06393 for ; Wed, 23 Jul 2003 14:04:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypc17498 for ; Wed, 23 Jul 2003 14:04:23 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoypc17483 for ; Wed, 23 Jul 2003 14:04:22 GMT Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h6NE3keV003082; Wed, 23 Jul 2003 10:03:47 -0400 Message-Id: <200307231403.h6NE3keV003082@mailhost.avici.com> To: "Adrian Farrel" cc: curtis@fictitious.org, "'mpls@uu.net'" , ccamp@ops.ietf.org Reply-To: curtis@fictitious.org Subject: Re: Crankback [Was: Running out of RSVP-TE bits?] In-reply-to: Your message of "Tue, 22 Jul 2003 12:43:39 BST." <00a501c35096$06001110$0e9c9ed9@Puppy> Date: Wed, 23 Jul 2003 10:04:06 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Adrian, For brevity I'll use the word "broken" to mean a flaw in the implementation. An isolated setup failure can only occur 1) if correct information has not been made available through flooding or 2) if the ingress implementation is broken. Correct information will not be available if 1) an implementation in the path serving as midpoint is broken and hasn't flooded correct information, 2) more than one router is broken and didn't flood the information, 3) the setup isn't really isolated and the reflooding has yet to occur or has not completely propogated. Careful reading of the above paragraph yields the following conclusion: either something is broken, or the the setup is not truly isolated. The one case where there is no implementation flaw and a setup fails is when the setup follows a previous setup that took resources that have not yet been reported by IGP flooding. The minimum case therefore involves two LSP setups, one that got the resources and one that didn't. In the minimum case without crankback reflooding is needed to indicate that the resource is not available anymore plus an error must be returned to the ingress. With crankback the IGP reflooding becomes redundant for that LSP setup. Rarely is the minimal case of much interest compared to cases where a feature is exercised heavily. This is no exception. Links occasionally fail, sometimes even routers fail. ISPs have reported (publicly I think, but at least privately) to have more than 1,000 RSVP/TE LSPs through a single node with close to 1,000 on a single link. The ingress for those failures would be many 10s of routers in either direction. Topologies are meshed but not densely meshed. This means that these many 10s of ingress are all going to go for the same resource which is now the best after the failure. Setups occur very fast. Often a large percentage of the LSPs will fail admission. This is an interesting case. It is not mearly hypothetical, it is a common real world case. The argument that only the case of an isolated failure is of interest does not hold up. I've already In message <00a501c35096$06001110$0e9c9ed9@Puppy>, "Adrian Farrel" writes: > Curtis, > > I think you have possibly missed the chief use of crankback and focused on a > side use. > > The principal use is to handle LSP setup failures. When these happen they ten > d to happen > one at a time (that is not a whole bunch of impacted LSPs that were using a l > ink that has > failed). Crankback allows nodes on the LSP to attempt to re-direct the LSP se > tup attempt > without failing it back to the ingress, and allows the collection of more det > ailed failure > information to aid the re-direction process. > > In a nutshell, crankback targets rapid re-direction of LSP setup attempts wit > hout waiting > for IGP convergence. That crankback can also be used for handling failed LSPs > is an > 'interesting' additional feature. > > Note that in no case does crankback increase the error reporting message flow > . It simply > adds a little information to error messages already used in RSVP-TE or GMPLS. > In fact, if > crankback is in use and intermediate nodes are enabled as crankback repair po > ints, > crankback can reduce the error reporting message flows since they don't have > to go all the > way to the ingress nodes. > > > > Perhaps you could summarize some of the problems crankback will cause. > > > It would be good to get comments on these problems from the ITU-T members > who > > > have made this an ASON requirement. > > > > After a link fails zero to a large number of admission failures may > > occur on a few links that are considered desireable alternates (by > > multiple LSP ingress, each acting independently). Crankback will > > provide individual signals to each ingress, probably for each LSP that > > failed. > > Well now: the number of signals is not a function of crankback. It is an exis > ting function > of RSVP-TE error reporting. > Crankback simply adds information to the error reporting so that the error ma > y be > repaired. It also recognizes that non-ingress nodes may wish to repair errors > . > > > Just using the IGP flooding is far more efficient and > > proactively tells ingress that haven't sent LSP paths over the now > > overloaded link. > > Efficiency is in the eye of the beholder on this issue. The debate over flood > ing or > signaling errors will probably go on for a while (see Richard Rabbat's work i > n ccamp on > the need for a flooding mechanism for fail-over to a protection LSP that may > be carrying > extra traffic). The efficiency surely depends on the number of LSPs and the n > umber of > nodes/links in the network. > > To repeat: the crankback draft doesn't make any assumptions about the efficie > ncy, it > simply uses existing mechanisms. In fact, there is a significant issue with t > he use of a > flooding mechanism. Viz. the ingress may not be able to tell from a descripti > on of the > faulted resource which LSPs were impacted - suppose a component link fails, o > r even an > individual laser. (You might as well say that soft pre-emption should be repo > rted through > flooding!) Soft preempt applies to a single LSP, not to the state of the link. There is only one ingress to that single LSP and that is the only router that needs to know that that particular LSP has been preempted. All other routers just need to know that reservable bandwidth has just hit zero (or a small number) and that would be flooded. > > Of course if you write specs before trying things you often get things > > wrong, particularly where the dynamics of a protocol are concerned. > > That's where the running code thing comes in. > > I agree with you whole-heartedly. It is so important to have running code. > Not sure why you bring it up in this context. Are you trying to imply somethi > ng? Only that some experience with crankback should be required for it to move forward and if possible its effectiveness in more than the minimal case should be considered before moving it forward. > > I think testing in an > > environment where lots of LSP from many ingress traverse a link that > > fails and all route to one or two links that become overloaded should > > be a prerequisite for crankback, with improvement demonstrated. > > As in my preamble, this is not what crankback is about. This is part of what successfully running an MPLS network is all about, so maybe crankback is not about successfully running an MPLS network. :-) > > Curtis > > > > ps - who cares about ASON? or ITU for that matter? :-) > > Cheers, > Adrian I think the reason that we differ in opinion on what is more efficient is that we are looking at two related but different problems. Crankback may make sense in a call routing situation, where ingress routinely setup short lived connections. In such a case the reservable bandwidth is in a constant state of flux and it is not at all practical to immediately flood any change. When a resource contention occurs, if the number of affected calls is low, crankback may be efficient. I am looking at MPLS as a means to setup very long lived connections for the purpose of traffic engineering an ISP network. These connections are intended to never go down if that were possible. When the network is quiescent there are few if any setups. Any setups during quiescent periods would be due to residual optimizations as a result of prior change to the network or change to reservable bandwidth of tunnels that routinely occur (often weekly) as a result of evaluation of prior traffic patterns. These occasional setups during quiescent periods are spaced far enough appart that it is very rare not to have exact information. It is only when a major event, such as a link down, occurs that resource contention occurs and then quite massive resource contention occurs over a brief period. In this case flooding the fact that the resource is exhausted makes good sense. Again, flooding every change immediately is not at all practical, but amount of change and time based triggers, combined with immediate trigger on resource allocation failure makes sense. I personally believe that MPLS using RSVP/TE was not intended for call routing of short lived connections and I have very strong basis in past IETF meetings and mailing list correspondence to support that. I also think that useless or not, we may end up implementing crankback simply because people either think we're solving call routing of short connections, or people mistakenly think crankback to be a good solution for the ISP situation. Hopefully no implementor will think that crankback is a viable substitute for reflooding when a resource allocation fails. Curtis From owner-mpls@UU.NET Wed Jul 23 17:14:38 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03107 for ; Wed, 23 Jul 2003 17:14:38 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyqe25467 for ; Wed, 23 Jul 2003 21:14:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyqe25295; Wed, 23 Jul 2003 21:14:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQoypx05449 for mpls-outgoing; Wed, 23 Jul 2003 19:23:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoypx05444 for ; Wed, 23 Jul 2003 19:23: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 QQoypx17902 for ; Wed, 23 Jul 2003 19:21:00 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypx10193 for ; Wed, 23 Jul 2003 19:20:59 GMT Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQoypx10185 for ; Wed, 23 Jul 2003 19:20:59 GMT Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2003 12:27:32 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6NJKsuI026744 for ; Wed, 23 Jul 2003 12:20:56 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX67198; Wed, 23 Jul 2003 15:20:53 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6NJKrE01949 for mpls@uu.net; Wed, 23 Jul 2003 15:20:53 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoypx05168 for ; Wed, 23 Jul 2003 19:16: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 QQoypx11404 for ; Wed, 23 Jul 2003 19:15:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypx07410 for ; Wed, 23 Jul 2003 19:15:40 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 QQoypx07269 for ; Wed, 23 Jul 2003 19:15:34 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25407; Wed, 23 Jul 2003 15:15:32 -0400 (EDT) Message-Id: <200307231915.PAA25407@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-07.txt Date: Wed, 23 Jul 2003 15:15:31 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Management Overview Author(s) : T. Nadeau, C. Srinivasan, A. Farrel Filename : draft-ietf-mpls-mgmt-overview-07.txt Pages : 29 Date : 2003-7-23 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This memo describes the management architecture for MPLS and indicates the inter-relationships between the different MIB modules used for MPLS network management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-mgmt-overview-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-23151203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-mgmt-overview-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23151203.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 23 22:29:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10621 for ; Wed, 23 Jul 2003 22:29:31 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyqz21578 for ; Thu, 24 Jul 2003 02:29:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyqz21525; Thu, 24 Jul 2003 02:29:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQoyqy15491 for mpls-outgoing; Thu, 24 Jul 2003 02:04:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoyqy13620 for ; Thu, 24 Jul 2003 02:04: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 QQoyqy14168 for ; Thu, 24 Jul 2003 02:02:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyqy05884 for ; Thu, 24 Jul 2003 02:02:11 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQoyqy05868 for ; Thu, 24 Jul 2003 02:02:11 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6O21em16893; Wed, 23 Jul 2003 22:01:40 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 22:01:41 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6071D2EC9@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: curtis@fictitious.org, Adrian Farrel Cc: "'mpls@uu.net'" , ccamp@ops.ietf.org Subject: RE: Crankback [Was: Running out of RSVP-TE bits?] Date: Wed, 23 Jul 2003 22:01:40 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Curtis Comments inline: > -----Original Message----- > From: Curtis Villamizar > Rarely is the minimal case of much interest compared to cases > where a feature is exercised heavily. This is no exception. > > Links occasionally fail, sometimes even routers fail. ISPs > have reported (publicly I think, but at least privately) to > have more than 1,000 RSVP/TE LSPs through a single node with > close to 1,000 on a single link. The ingress for those > failures would be many 10s of routers in either direction. > Topologies are meshed but not densely meshed. This means > that these many 10s of ingress are all going to go for the > same resource which is now the best after the failure. > Setups occur very fast. Often a large percentage of the LSPs > will fail admission. > > This is an interesting case. It is not mearly hypothetical, > it is a common real world case. I agree here. The value of crankback or feedback at the moment these LSPs fail admission and signal back to the source is the key point. There is a race condition for the LSA (or other mechanisms when you get to multiarea). The value of crankback avoids wasted control cycles either waiting for the LSAs or (worse) retrying the same failed path. It is not a replacement for the LSA nor is its scope as wide. It piggybacks on existing signaling. > > I am looking at MPLS as a means to setup very long lived > connections for the purpose of traffic engineering an ISP > network. These connections are intended to never go down if > that were possible. When the network is quiescent there are > few if any setups. Any setups during quiescent periods would > be due to residual optimizations as a result of prior change > to the network or change to reservable bandwidth of tunnels > that routinely occur (often weekly) as a result of evaluation > of prior traffic patterns. These occasional setups during > quiescent periods are spaced far enough appart that it is > very rare not to have exact information. It is only when a > major event, such as a link down, occurs that resource > contention occurs and then quite massive resource contention > occurs over a brief period. In this case flooding the fact > that the resource is exhausted makes good sense. Again, > flooding every change immediately is not at all practical, > but amount of change and time based triggers, combined with > immediate trigger on resource allocation failure makes sense. The value of crankback here depends on the impact of the loss of the LSP. If the LSP going down only means you don't have TE path and shortest path routing kicks in, in the meantime, crankback only provides a minimal improvement. > > I personally believe that MPLS using RSVP/TE was not intended > for call routing of short lived connections and I have very > strong basis in past IETF meetings and mailing list > correspondence to support that. Even long term connections that have no alternative routing when the connection is down benefit from crankback or feedback. This is the case with GMPLS. > > I also think that useless or not, we may end up implementing > crankback simply because people either think we're solving > call routing of short connections, or people mistakenly think > crankback to be a good solution for the ISP situation. > Hopefully no implementor will think that crankback is a > viable substitute for reflooding when a resource allocation fails. This is not a short lived LSP problem in my view. This is about making the best call routing decisions without wasting or burning control plane cycles during the interesting case you mentioned. You should reflood at an appropriate rate but pushing flooding to a maximum rate _still_ leaves race conditions between Signaling and LSAs. Crankback or feedback a good way to address the race conditions for a low cost and allowing flooding at an optimal interval. > Curtis > > Cheers, Don From owner-mpls@UU.NET Wed Jul 23 23:16:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11319 for ; Wed, 23 Jul 2003 23:16:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyrd28965 for ; Thu, 24 Jul 2003 03:17:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyrd28863; Thu, 24 Jul 2003 03:16:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQoypw23410 for mpls-outgoing; Wed, 23 Jul 2003 19:02:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoypw22756 for ; Wed, 23 Jul 2003 19:01:56 GMT Received: from imr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoypw25205 for ; Wed, 23 Jul 2003 19:00:57 GMT Received: from pmismtp06.wcomnet.com by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp06.mcilink.com [166.38.62.54]) id QQoypw25194 for ; Wed, 23 Jul 2003 19:00:57 GMT Received: from CONVERSION-DAEMON.pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) id <0HIH00901RGGFM@pmismtp06.wcomnet.com> for mpls@UU.NET; Wed, 23 Jul 2003 19:00:57 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIH00801R8EC0@pmismtp06.wcomnet.com> for mpls@UU.NET; Wed, 23 Jul 2003 19:00:57 +0000 (GMT) Received: from dmcdysan ([166.32.199.64]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIH007JURGLO7@pmismtp06.wcomnet.com>; Wed, 23 Jul 2003 19:00:22 +0000 (GMT) Date: Wed, 23 Jul 2003 15:00:27 -0400 From: Dave McDysan Subject: MPLS 2003 International Conference To: Mpls , Ccamp , l2vpn@ietf.org, l3vpn@ietf.org, pwe3@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS 2003 International Conference Omni Shoreham Hotel, Washington D.C. October 26-28, 2003 ================================================================== http://www.mpls2003.com ================================================================== You are cordially invited to attend the MPLS 2003 International Conference to be held in Washington D.C. October 26-28, 2003 hosted by ISOCORE. The 3-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. Registration for the conference is now open. Early registration discounts are extremely lucrative and are valid for a limited time only. To register, go to: http://www.mpls2003.com/registration.htm Important Dates: --------------------- - Early Registration Rates Cut-Off Date: July 30 - Tutorials: October 26, 9:00am - 5:30 pm - Conference sessions: October 27-28, 8:45am-6:30pm - Exhibits: October 27-28, 8:45am-6:30pm Program: -------- (visit http://mpls2003.com/sessions.htm for details) Sunday October 26 Tutorial 1 Tutorial 2: VPNs Tutorial 3: Layer 2 VPNs/VPLS Tutorial 4: MPLS Security Monday, October 27 Opening remarks - Peter Hill (BellSouth Telecommunications) & Dr. Hamid Ahmadi (AT&T Labs) Introduction - Luca Martini (Level3 Communications) Keynote Session: Convergence (Service Provider's Perspective) - What is the Role of MPLS in Network Convergence? - MPLS: The Catalyst of Convergence? Session: OAM - New Developments in MPLS and IP OAM - Network Management of MPLS-based VPNs - MPLS Convergence, Control and OAM Implications - Service OA&M for MPLS VPNs Session: Reliability - High Availability for MPLS LSRs - Next Generation Core Routers: Defining IP Reliability and Resiliency - High Resiliency MPLS Network Design - Hardening MPLS-based Networks Session: L2/L3 VPNs - BGP-VPN Services: Lessons Learned - Design and Deploy Scalable Inter-AS MPLS VPNs - L2-MPLS Networks - MPLS in Multi-AS Networks Panel: MPLS as a Fusing Technology - Chair: P. Hill, VP Technology Planning & Deployment, BellSouth Telecommunications - Members: D. McDysan (MCI), C. Kalmanek (ATT), P. Delavenne (LambdaNet), R. Wilder (Masergy), R. Doukov (Flag Telecom), McManus (Verizon), C. Liljenstolpe (Cable & Wireless), Y. Sato (NTT) Tuesday, October 28 Keynote Lessons Learned - Yakov Rekhter Critical Considerations for Network Consolidation - Daniel Awduche (MCI) Session: Layer 2 Transport & Interworking over MPLS - VPLS - Remember LANE? - Transitioning a Profitable Service Portfolio to an MPLS Core Network - VPLS Provisioning, Performance and Scalability: Problems and Solutions Session: IP Optical Integration - Optical Market Forces on GMPLS - Multiservice Metro Networks in Sweden and Their Plans to Go GMPLS - Photonic Internet Laboratory: New Challenges for Future Photonic Network - Generalized VPNs (GVPNs) Session: New MPLS Features - Scalable Multicast MPLS Technology for Next Generation Broadband Services Network - Multicast Traffic Engineering with MPLS - LDP Fast Convergence - How to secure an MPLS/VPN network - Integration of IPv6 and IPv6 VPN Services over MPLS Session: Traffic Engineering - Inter-area and Inter-AS MPLS Traffic Engineering - Traffic Engineering in Hierarchical Multiprovider Networks - Multi-Region (multiarea/multiAS) Traffic Engineering - Advanced MPLS Application Testing Session: Service & Provisioning Issues - MPLS Network Management: Enterprise Deployment Management - Attracting New Enterprise Customers with MPLS VPN Services - MPLS Beyond Service Provider Cores - Critical Quality of Service Issues in MPLS Networks - Practical Implementation of Tools Allied to the Network Management of IP/MPLS-based Networks We look forward to seeing you at the Conference. Regards, Dave McDysan, Luca Martini, Bijan Jabbari From owner-mpls@UU.NET Thu Jul 24 05:19:50 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00100 for ; Thu, 24 Jul 2003 05:19:50 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyoi20392 for ; Wed, 23 Jul 2003 09:03:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyoi20231; Wed, 23 Jul 2003 09:03:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoyog22278 for mpls-outgoing; Wed, 23 Jul 2003 08:30:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoyof22236 for ; Wed, 23 Jul 2003 08:29:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoyof05197 for ; Wed, 23 Jul 2003 08:27:34 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyof23583 for ; Wed, 23 Jul 2003 08:27:33 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoyof23179 for ; Wed, 23 Jul 2003 08:27:24 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6N8RCQk025587 for ; Wed, 23 Jul 2003 01:27:12 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX11417; Wed, 23 Jul 2003 04:27:11 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6N8RB222058 for mpls@uu.net; Wed, 23 Jul 2003 04:27:11 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoyof21988 for ; Wed, 23 Jul 2003 08:25: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 QQoyof01278 for ; Wed, 23 Jul 2003 08:24:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyof16858 for ; Wed, 23 Jul 2003 08:24:44 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.com [216.241.224.12]) id QQoyof16641 for ; Wed, 23 Jul 2003 08:24:33 GMT Received: (qmail 9212 invoked by uid 104); 23 Jul 2003 08:24:32 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4278. Clear:. Processed in 0.524842 secs); 23 Jul 2003 08:24:32 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.com with SMTP; 23 Jul 2003 08:24:31 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h6N8OVj26426 for ; Wed, 23 Jul 2003 01:24:31 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id <3862ARZN>; Wed, 23 Jul 2003 01:24:30 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115CADB@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: mpls@UU.NET Subject: RSVP Fastreroute comment Date: Wed, 23 Jul 2003 01:24:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, During the previous last call I raised the following issue: 1) Which one of the Backup Path Identification mechanisms are mandatory and which one is optional. I don't think it is reasonable to require people to implement both. 2) I also have a new comment regarding which one of the detour and facility backup are mandatory and which one is optional. The text says: "While the two methods could in principle be used in a single network, it is expected that operators will continue to choose to deploy either one or the other. The goal of this draft is to standardize the RSVP signaling such that either a network with LSRs that implement both methods or an network composed of some LSRs that support one method and others that support both, can properly signal among those LSRs to achieve fast restoration through the chosen method." But without having a mandatory mode, LSRs that implement one method can't interwork with LSRs that implement the other. And I don't think it is reasonable to force people to implement both. Yours, -Shahram From owner-mpls@UU.NET Thu Jul 24 10:27:11 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08851 for ; Thu, 24 Jul 2003 10:27:11 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoysv11544 for ; Thu, 24 Jul 2003 14:27:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoysv11482; Thu, 24 Jul 2003 14:27:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQoyst22337 for mpls-outgoing; Thu, 24 Jul 2003 13:55:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoyst22332 for ; Thu, 24 Jul 2003 13:55: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 QQoyst13721 for ; Thu, 24 Jul 2003 13:52:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyst19624 for ; Thu, 24 Jul 2003 13:52:13 GMT Received: from dirty.research.bell-labs.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6]) id QQoyst19451 for ; Thu, 24 Jul 2003 13:52:11 GMT Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6ODq7Ha046383 for ; Thu, 24 Jul 2003 09:52:07 -0400 (EDT) Received: from zydeco.research.bell-labs.com (zydeco.research.bell-labs.com [135.104.120.150]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6ODq11u089770 for ; Thu, 24 Jul 2003 09:52:01 -0400 (EDT) Received: from zydeco.research.bell-labs.com (localhost [127.0.0.1]) by zydeco.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6ODq0Fh027487 for ; Thu, 24 Jul 2003 09:52:00 -0400 (EDT) Received: from localhost (anurag@localhost) by zydeco.research.bell-labs.com (8.12.9/8.12.9/Submit) with ESMTP id h6ODq03G027482 for ; Thu, 24 Jul 2003 09:52:00 -0400 (EDT) X-Authentication-Warning: zydeco.research.bell-labs.com: anurag owned process doing -bs Date: Thu, 24 Jul 2003 09:52:00 -0400 (EDT) From: Anurag Srivastava To: Subject: MPLS traffic-eng tunnel query! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello, I have a query regarding MPLS traffic-engg tunnel implementation in Cisco IOS. Here are the tunnel details: -------------------------------------------------------------------- ! interface Tunnel1 ip unnumbered Loopback0 no ip directed-broadcast no ip route-cache distributed tunnel destination x.x.x.x tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 1000 tunnel mpls traffic-eng path-option 1 explicit name path1 tunnel mpls traffic-eng path-option 2 explicit name path2 -------------------------------------------------------------------- This MPLS tunnel is currently using path1 and I am interested in moving it on to path2. Is there any method to achieve this in a hitless (make-before-break or bridge-and-roll) or disruption free manner without affecting the traffic for a long period of time? One simple way to move traffic is to remove path-option 1 which would force router to move the traffic to path-option 2 (or path2). However, for the period path2 is signalled and setup, traffic will be disrupted. Looking forward for a reply... Thanks, - Anurag -- Anurag Srivastava Network Software Research Center, Bell Labs. Research. (908)-582-0469 From owner-mpls@UU.NET Thu Jul 24 12:25:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12595 for ; Thu, 24 Jul 2003 12:25:19 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoytd24843 for ; Thu, 24 Jul 2003 16:25:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoytd24759; Thu, 24 Jul 2003 16:25:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQoytb12055 for mpls-outgoing; Thu, 24 Jul 2003 15:59:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoytb12048 for ; Thu, 24 Jul 2003 15:59: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 QQoytb03559 for ; Thu, 24 Jul 2003 15:58:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoytb23852 for ; Thu, 24 Jul 2003 15:58:56 GMT Received: from zrtps0kn.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zrtps0kn.nortelnetworks.com [47.140.192.55]) id QQoytb23846 for ; Thu, 24 Jul 2003 15:58:55 GMT Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6OFwVp23692; Thu, 24 Jul 2003 11:58:31 -0400 (EDT) Received: from zrtpd0jd.us.nortel.com ([47.140.203.31]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PRJBFBWY; Thu, 24 Jul 2003 11:58:32 -0400 Received: from [47.142.158.45] (LOCALHOST [47.142.158.45]) by zrtpd0jd.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3VZQ1ALQ; Thu, 24 Jul 2003 11:58:32 -0400 Subject: Re: MPLS traffic-eng tunnel query! X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kellermann,Rurick" To: Anurag Srivastava Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Message-Id: <1059062963.1972.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 24 Jul 2003 12:09:23 -0400 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Arunag, Try sending the question to mpls-ops@mplsrc.com, as this distribution list is not for deployment / vendor-specific issues. On Thu, 2003-07-24 at 09:52, Anurag Srivastava wrote: > Hello, > > I have a query regarding MPLS traffic-engg tunnel implementation in Cisco IOS. > > Here are the tunnel details: > -------------------------------------------------------------------- > ! > interface Tunnel1 > ip unnumbered Loopback0 > no ip directed-broadcast > no ip route-cache distributed > tunnel destination x.x.x.x > tunnel mode mpls traffic-eng > tunnel mpls traffic-eng priority 7 7 > tunnel mpls traffic-eng bandwidth 1000 > tunnel mpls traffic-eng path-option 1 explicit name path1 > tunnel mpls traffic-eng path-option 2 explicit name path2 > -------------------------------------------------------------------- > > This MPLS tunnel is currently using path1 and I am interested in moving it on > to path2. Is there any method to achieve this in a hitless > (make-before-break or bridge-and-roll) or disruption free manner without > affecting the traffic for a long period of time? > > One simple way to move traffic is to remove path-option 1 which would force > router to move the traffic to path-option 2 (or path2). However, for the period > path2 is signalled and setup, traffic will be disrupted. > > Looking forward for a reply... > > Thanks, > - Anurag > > -- > Anurag Srivastava > Network Software Research Center, > Bell Labs. Research. > (908)-582-0469 > > From owner-mpls@UU.NET Fri Jul 25 19:00:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00585 for ; Fri, 25 Jul 2003 19:00:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyxw18815 for ; Fri, 25 Jul 2003 23:00:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoyxw18616; Fri, 25 Jul 2003 23:00:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQoyxi01822 for mpls-outgoing; Fri, 25 Jul 2003 19:35:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoyxi01817 for ; Fri, 25 Jul 2003 19:35: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 QQoyxi08815 for ; Fri, 25 Jul 2003 19:32:48 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyxi05939 for ; Fri, 25 Jul 2003 19:32:47 GMT Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQoyxi05928 for ; Fri, 25 Jul 2003 19:32:47 GMT Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2003 12:32:46 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6PJWhuG018745 for ; Fri, 25 Jul 2003 12:32:44 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAZ48855; Fri, 25 Jul 2003 15:32:42 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6PJWgR23677 for mpls@uu.net; Fri, 25 Jul 2003 15:32:42 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoyxi01691 for ; Fri, 25 Jul 2003 19:31:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoyxh01388 for ; Fri, 25 Jul 2003 19:28:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoyxh17171 for ; Fri, 25 Jul 2003 19:28:28 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 QQoyxh17148 for ; Fri, 25 Jul 2003 19:28:27 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17827; Fri, 25 Jul 2003 15:28:22 -0400 (EDT) Message-Id: <200307251928.PAA17827@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-in-ip-or-gre-01.txt Date: Fri, 25 Jul 2003 15:28:21 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in IP or GRE Author(s) : T. Worster, Y. Rekhter, E. Rosen Filename : draft-ietf-mpls-in-ip-or-gre-01.txt Pages : 7 Date : 2003-7-25 In various applications of MPLS, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is applicable in some circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-in-ip-or-gre-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-in-ip-or-gre-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: <2003-7-25152133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-in-ip-or-gre-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-in-ip-or-gre-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152133.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Sun Jul 27 08:18:42 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14319 for ; Sun, 27 Jul 2003 08:18:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozdp05284 for ; Sun, 27 Jul 2003 12:18:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozdp05042; Sun, 27 Jul 2003 12:18:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQozde25639 for mpls-outgoing; Sun, 27 Jul 2003 09:43:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQozde25624 for ; Sun, 27 Jul 2003 09: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 QQozde25590 for ; Sun, 27 Jul 2003 09:41:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozde06764 for ; Sun, 27 Jul 2003 09:41:03 GMT Received: from tiger.seabridge.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bzq-25-127-226.cust.bezeqint.net [212.25.127.226]) id QQozde06386 for ; Sun, 27 Jul 2003 09:40:53 GMT Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Jul 2003 12:05:05 +0200 Message-ID: From: Nurit Sprecher To: "'mpls@UU.NET'" Subject: Multiple Instances in the mplsTunnelTable of the TE MIB Date: Sun, 27 Jul 2003 12:04:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35426.87382540" 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_01C35426.87382540 Content-Type: text/plain; charset="iso-8859-1" Hi all, If multiple instances (for example two instances) are defined in the mplsTunnelTable for the same Tunnel, and both instances are provisioned, is it possible to administratively control operations like switch over (to a backup tunnel) or switch back (for example when a primary preferred tunnel is restored)? Note that I am talking about a case where both tunnels are pre-provisioned, but the backup tunnel is idle when the primary is active. Is the mplsTunnelInstancePriority column of the mplsTunnelTable defined for this purpose? Thanks in advance, Nurit. ------_=_NextPart_001_01C35426.87382540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<= ![if = !supportEmptyParas]> 

=

Hi all,<= /p>

I= f multiple instances  (for = example two instances) are defined in the mplsTunnelTable for the same Tunnel, = and both instances are provisioned, is it possible to administratively control operations like switch over (to a backup tunnel) or switch back (for = example when a primary preferred tunnel is restored)? Note that I am talking = about a case where both tunnels are pre-provisioned, but the backup tunnel is = idle when the primary is active.

I= s the mplsTunnelInstancePriority column of the mplsTunnelTable defined for = this purpose?

T= hanks in advance, Nurit.

------_=_NextPart_001_01C35426.87382540-- From owner-mpls@UU.NET Sun Jul 27 08:20:06 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14351 for ; Sun, 27 Jul 2003 08:20:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozdp09010 for ; Sun, 27 Jul 2003 12:20:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozdp08628; Sun, 27 Jul 2003 12:20:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQozde25589 for mpls-outgoing; Sun, 27 Jul 2003 09:41:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQozde25584 for ; Sun, 27 Jul 2003 09:41: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 QQozde12263 for ; Sun, 27 Jul 2003 09:41:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozde06915 for ; Sun, 27 Jul 2003 09:41:06 GMT Received: from tiger.seabridge.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bzq-25-127-226.cust.bezeqint.net [212.25.127.226]) id QQozde06770 for ; Sun, 27 Jul 2003 09:41:03 GMT Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Jul 2003 12:12:35 +0200 Message-ID: From: Nurit Sprecher To: mpls@UU.NET Subject: draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt Date: Sun, 27 Jul 2003 12:12:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35427.9396D7E0" 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_01C35427.9396D7E0 Content-Type: text/plain; charset="windows-1255" What is the delta between version 02 and 03 of the fast reroute drafts? ------_=_NextPart_001_01C35427.9396D7E0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

What is the delta between = version 02 and 03 of the fast reroute drafts?

------_=_NextPart_001_01C35427.9396D7E0-- From owner-mpls@UU.NET Mon Jul 28 14:06:14 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14474 for ; Mon, 28 Jul 2003 14:06:14 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozie05188 for ; Mon, 28 Jul 2003 18:06:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozie04950; Mon, 28 Jul 2003 18:06:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQozhg16373 for mpls-outgoing; Mon, 28 Jul 2003 12:04:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQozhg16364 for ; Mon, 28 Jul 2003 12:04:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQozhg18569 for ; Mon, 28 Jul 2003 12:03:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozhg24685 for ; Mon, 28 Jul 2003 12:03:42 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQozhg24673 for ; Mon, 28 Jul 2003 12:03:41 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 28 Jul 2003 13:03:36 +0100 Message-ID: From: Andy Baker To: Seabridge - Nurit Sprecher Cc: mpls@UU.NET Subject: RE: draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt Date: Mon, 28 Jul 2003 13:02:27 +0100 Deferred-Delivery: Mon, 28 Jul 2003 13:03:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="windows-1255" Sender: owner-mpls@UU.NET Precedence: bulk Hi Nurit, The only difference between version 2 and 3 is the addition of section 0 "Background". This basically just states that the drafts purpose is to rationalise existing implementations (by Cisco and Juniper), and provide interoperability between them. Regards, Andy. -----Original Message----- From: Seabridge - Nurit Sprecher Sent: 27 July 2003 11:12 To: mpls@UU.NET Subject: draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt What is the delta between version 02 and 03 of the fast reroute drafts? From owner-mpls@UU.NET Tue Jul 29 02:13:45 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12988 for ; Tue, 29 Jul 2003 02:13:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozka11283 for ; Tue, 29 Jul 2003 06:13:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozka11198; Tue, 29 Jul 2003 06:13:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQozju09571 for mpls-outgoing; Tue, 29 Jul 2003 04:36:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQozju09556 for ; Tue, 29 Jul 2003 04:36: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 QQozju07546 for ; Tue, 29 Jul 2003 04:36:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozju16213 for ; Tue, 29 Jul 2003 04:36:30 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQozju16167 for ; Tue, 29 Jul 2003 04:36:28 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 29 Jul 2003 10:16:07 +0530 Received: from arumugamv (arumugamv.future.futsoft.com [10.20.6.91]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h6T4RN0r018657 for ; Tue, 29 Jul 2003 09:57:24 +0530 Reply-To: From: "Arumugam V" To: Subject: Question on BGP/MPLS VPN rfc2547bis Date: Tue, 29 Jul 2003 10:01:49 +0530 Message-Id: <001001c3558a$54258a20$5b06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a question. Can someone help me to get the clarification? Can IP address of CE routers, over which they establish BGP session with PE, overlap? Means two CEs, say CE1 (in VPN A) and CE2 (in VPN B), having same IP addresses, can have BGP session to same PE. Here I am not talking about VPN routes, I am only talking about CE router's IP address. Having same IP addresses may lead to lots of complication in the implementation. I would appreciate if you give justification with the answer. Thanks and Regards, Arumugam *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 29 12:37:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29227 for ; Tue, 29 Jul 2003 12:37:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozlq16881 for ; Tue, 29 Jul 2003 16:37:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozlq16807; Tue, 29 Jul 2003 16:37:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQozld15408 for mpls-outgoing; Tue, 29 Jul 2003 13:28:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQozld15403 for ; Tue, 29 Jul 2003 13:28:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQozld03426 for ; Tue, 29 Jul 2003 13:27:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozld06550 for ; Tue, 29 Jul 2003 13:27:13 GMT Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQozld06538 for ; Tue, 29 Jul 2003 13:27:12 GMT Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 06:29:49 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6TDR6mp016780 for ; Tue, 29 Jul 2003 06:27:08 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABB36262; Tue, 29 Jul 2003 09:27:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6TDR5x18334 for mpls@uu.net; Tue, 29 Jul 2003 09:27:05 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQozld15336 for ; Tue, 29 Jul 2003 13:26: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 QQozld27918 for ; Tue, 29 Jul 2003 13:25:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozld04111 for ; Tue, 29 Jul 2003 13:25:33 GMT Received: from ams-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-iport-1.cisco.com [144.254.74.5]) id QQozld04094 for ; Tue, 29 Jul 2003 13:25:33 GMT Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2003 15:25:17 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6TDNLu1016952; Tue, 29 Jul 2003 15:23:21 +0200 (MET DST) Received: from JGUICHARW2K (dhcp-10-86-162-205.cisco.com [10.86.162.205]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA06476; Tue, 29 Jul 2003 15:25:27 +0200 (MET DST) From: "Jim Guichard" To: , Subject: RE: Question on BGP/MPLS VPN rfc2547bis Date: Tue, 29 Jul 2003 09:20:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <001001c3558a$54258a20$5b06140a@future.futsoft.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit yes, although you would need to check your specific vendor implementation to make sure it covers such a configuration. Jim > >-----Original Message----- > >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Arumugam > >V > >Sent: Tuesday, July 29, 2003 12:32 AM > >To: mpls@UU.NET > >Subject: Question on BGP/MPLS VPN rfc2547bis > > > > > >Hello, > >I have a question. Can someone help me to get the clarification? > >Can IP address of CE routers, over which they establish BGP > >session with PE, > >overlap? > >Means two CEs, say CE1 (in VPN A) and CE2 (in VPN B), having same IP > >addresses, can have BGP session to same PE. > >Here I am not talking about VPN routes, I am only talking about > >CE router's > >IP address. Having same IP addresses may lead to lots of > >complication in the > >implementation. > >I would appreciate if you give justification with the answer. > >Thanks and Regards, > >Arumugam > > > >***************************************************************** > >********** > >This message is proprietary to Future Software Limited (FSL) > >and is intended solely for the use of the individual to whom it > >is addressed. It may contain privileged or confidential information > >and should not be circulated or used for any purpose other than for > >what it is intended. > > > >If you have received this message in error, please notify the > >originator immediately. If you are not the intended recipient, > >you are notified that you are strictly prohibited from using, > >copying, altering, or disclosing the contents of this message. > >FSL accepts no responsibility for loss or damage arising from > >the use of the information transmitted by this email including > >damage from virus. > >***************************************************************** > >********** From owner-mpls@UU.NET Tue Jul 29 14:56:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04568 for ; Tue, 29 Jul 2003 14:56:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozlz10625 for ; Tue, 29 Jul 2003 18:56:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozlz10490; Tue, 29 Jul 2003 18:56:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQozlo23819 for mpls-outgoing; Tue, 29 Jul 2003 16:12:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQozlo23814 for ; Tue, 29 Jul 2003 16:12: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 QQozlo29736 for ; Tue, 29 Jul 2003 16:10:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozlo22482 for ; Tue, 29 Jul 2003 16:10:08 GMT Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQozlo22426 for ; Tue, 29 Jul 2003 16:10:06 GMT Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2003 09:10:04 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6TG9x89023495 for ; Tue, 29 Jul 2003 09:10:00 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABB53428; Tue, 29 Jul 2003 12:09:58 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6TG9wU20367 for mpls@uu.net; Tue, 29 Jul 2003 12:09:58 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQozlo23156 for ; Tue, 29 Jul 2003 16:08: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 QQozlo05410 for ; Tue, 29 Jul 2003 16:06:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozlo08368 for ; Tue, 29 Jul 2003 16:06:56 GMT Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71]) id QQozlo08334 for ; Tue, 29 Jul 2003 16:06:54 GMT Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 09:09:34 -0700 Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6TG6pAi009266; Tue, 29 Jul 2003 12:06:51 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-48.cisco.com [10.86.240.48]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h6TG6o801814; Tue, 29 Jul 2003 12:06:50 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'ramasamy ramanathan'" , Subject: RE: doubt in draft-ietf-mpls-ftn-mib-07.txt Date: Tue, 29 Jul 2003 12:06:37 -0400 Organization: Cisco Systems Message-ID: <013601c355eb$6849ac00$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The advantage of specifying the TE tunnel head interface is that for static routes, this is permanent whereas the XCindex can change. Bear in mind that you can auto-route your IGP traffic over a TE tunnel if that is the preferred route, so you may also have dynamic entries pointing at a tunnel head as well. --Tom > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of ramasamy ramanathan > Sent: Monday, July 28, 2003 10:16 PM > To: mpls@UU.NET > Subject: doubt in draft-ietf-mpls-ftn-mib-07.txt > > > hi all, > > I have a doubt in mpls ftn mib draft( > draft-ietf-mpls-ftn-mib-07.txt), could u please explain me? > > * mplsFTNActionType can take either redirectLSP or > redirectTunnel. If redirecTunnel is specified, then actionptr > will point to mplsTunnelEntry. So while forwarding the > packets, mplsXCPtr which is there inside mplsTunnelEntry is > taken and then packet will be switched accordingly. If the > Action type is redirectLSP then ActionPtr points to > mplsXCEntry directly. so while forwarding this will be > directly referred. > > If my above assumption is correct, what is the use of > specifying type as redirectTunnel? In either case mplsXCptr > will be used for switching right, so why can't it point to > mplsXCEntry always, what is the use of it pointing to redirectTunnel? > > If my assumption is not correct, what is the difference > between redirectLSP and redirectTunnel, and in what scenario > each of these types will be used? > > thanks > rams. > > > > From owner-mpls@UU.NET Tue Jul 29 15:54:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07158 for ; Tue, 29 Jul 2003 15:54:54 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozmd01249 for ; Tue, 29 Jul 2003 19:54:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozmd01151; Tue, 29 Jul 2003 19:54:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQozlw03445 for mpls-outgoing; Tue, 29 Jul 2003 18:02:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQozlw03434 for ; Tue, 29 Jul 2003 18:02:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQozlw00473 for ; Tue, 29 Jul 2003 18:01:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozlw27637 for ; Tue, 29 Jul 2003 18:01:33 GMT Received: from moutng.kundenserver.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: moutng.kundenserver.de [212.227.126.183]) id QQozlw27608 for ; Tue, 29 Jul 2003 18:01:32 GMT Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19hYmx-0000p1-00 for mpls@uu.net; Tue, 29 Jul 2003 20:01:31 +0200 Received: from [217.88.230.252] (helo=192.168.2.35) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 19hYmx-000447-00 for mpls@uu.net; Tue, 29 Jul 2003 20:01:31 +0200 From: Stefan Winter To: mpls@UU.NET Subject: error in draft-ietf-mpls-ftn-mib-07.txt Date: Tue, 29 Jul 2003 20:00:16 +0200 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200307292000.17047.mail@stefan-winter.de> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, (posted this one earlier but got no response) in draft-ietf-mpls-ftn-mib-07.txt there seems to be an error in the MIB definition of the mplsFTNMapTable. The table consists of five columns, which are indexed 1,2,3,5,6. There doesn=B4t seem to be a real reason for ordering that way; I suggest a 1,2,3,4,5 ordering. Greetings, Stefan Winter From owner-mpls@UU.NET Tue Jul 29 17:58:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11330 for ; Tue, 29 Jul 2003 17:58:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozml04928 for ; Tue, 29 Jul 2003 21:58:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozml04772; Tue, 29 Jul 2003 21:58:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQozmb07869 for mpls-outgoing; Tue, 29 Jul 2003 19:17:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQozmb07858 for ; Tue, 29 Jul 2003 19:17: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 QQozmb26798 for ; Tue, 29 Jul 2003 19:16:00 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozmb12213 for ; Tue, 29 Jul 2003 19:15:59 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 QQozmb12201 for ; Tue, 29 Jul 2003 19:15:59 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6TJFts22401 for ; Tue, 29 Jul 2003 14:15:56 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 21:15:54 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213BDD4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: Take a look at: http://www.ibr.cs.tu-bs.de/projects/nmrg/infomode l/concrete/MPLS-LDP-STD-MIB.pdf Date: Tue, 29 Jul 2003 21:15:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Thanks to the help of Juergen Schoenwaelder and Fransk Straus I have been able to create a UML idagram for the MPLS-LDP-STD-MIB. See http://www.ibr.cs.tu-bs.de/projects/nmrg/infomodel/concrete/MPLS-LDP-STD-MIB.pdf Not 100% sure it is correct yet. If you see errors, pls let me know. Do people find this usefull? Do we see that there are MANY relationships between the various tables? Is that goodness? Thanks, Bert From owner-mpls@UU.NET Wed Jul 30 01:23:14 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23120 for ; Wed, 30 Jul 2003 01:23:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoznp22971 for ; Wed, 30 Jul 2003 05:23:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoznp22865; Wed, 30 Jul 2003 05:23:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQoznd26697 for mpls-outgoing; Wed, 30 Jul 2003 02:15:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoznd26692 for ; Wed, 30 Jul 2003 02:15: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 QQoznd00467 for ; Wed, 30 Jul 2003 02:15:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoznd19431 for ; Wed, 30 Jul 2003 02:15:15 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQoznd19422 for ; Wed, 30 Jul 2003 02:15:14 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6U2FALH001243 for ; Tue, 29 Jul 2003 19:15:11 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABC05773; Tue, 29 Jul 2003 22:15:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h6U2F9R29232 for mpls@uu.net; Tue, 29 Jul 2003 22:15:09 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoznc26163 for ; Wed, 30 Jul 2003 02:14:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoznc24291 for ; Wed, 30 Jul 2003 02:13:19 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoznc13869 for ; Wed, 30 Jul 2003 02:13:19 GMT Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQoznc13860 for ; Wed, 30 Jul 2003 02:13:18 GMT Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2003 19:13:18 -0700 Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6U2DFxc028309; Tue, 29 Jul 2003 22:13:15 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-48.cisco.com [10.86.240.48]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h6U2DE824810; Tue, 29 Jul 2003 22:13:14 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Stefan Winter'" , Subject: RE: error in draft-ietf-mpls-ftn-mib-07.txt Date: Tue, 29 Jul 2003 22:13:03 -0400 Organization: Cisco Systems Message-ID: <01d201c35640$1fe876d0$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200307292000.17047.mail@stefan-winter.de> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable We are correcting this in the version that will be sent to the IESG. Thanks. --Tom > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf=20 > Of Stefan Winter > Sent: Tuesday, July 29, 2003 2:00 PM > To: mpls@UU.NET > Subject: error in draft-ietf-mpls-ftn-mib-07.txt >=20 >=20 > Hello, >=20 > (posted this one earlier but got no response) >=20 > in draft-ietf-mpls-ftn-mib-07.txt there seems to be an error=20 > in the MIB definition of the mplsFTNMapTable. The table=20 > consists of five columns, which are indexed 1,2,3,5,6. There=20 > doesn=B4t seem to be a real reason for ordering that way; I=20 > suggest a 1,2,3,4,5 ordering. >=20 > Greetings, >=20 > Stefan Winter >=20 From owner-mpls@UU.NET Wed Jul 30 12:34:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07374 for ; Wed, 30 Jul 2003 12:34:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozjz29203 for ; Tue, 29 Jul 2003 05:49:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozjz29040; Tue, 29 Jul 2003 05:49:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQozjk20800 for mpls-outgoing; Tue, 29 Jul 2003 02:04:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQozjk20789 for ; Tue, 29 Jul 2003 02:04: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 QQozjk06192 for ; Tue, 29 Jul 2003 02:03:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozjk29001 for ; Tue, 29 Jul 2003 02:03:23 GMT Received: from mail4.nec.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dns4.nec.com [131.241.15.4]) id QQozjk28987 for ; Tue, 29 Jul 2003 02:03:23 GMT Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h6T23L2i028979 for ; Mon, 28 Jul 2003 19:03:21 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h6T23EjP005438 for ; Mon, 28 Jul 2003 19:03:14 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.9/8.12.9) with ESMTP id h6T21tDp019418 for ; Mon, 28 Jul 2003 19:01:56 -0700 (PDT) Received: from ems11 (ems11 [131.241.5.62]) by bunny.tdd.sj.nec.com (8.12.9/8.12.9) with SMTP id h6T21r8C010405 for ; Mon, 28 Jul 2003 19:01:53 -0700 (PDT) From: "ramasamy ramanathan" To: Subject: doubt in draft-ietf-mpls-ftn-mib-07.txt Date: Mon, 28 Jul 2003 19:16:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi all, I have a doubt in mpls ftn mib draft( draft-ietf-mpls-ftn-mib-07.txt), could u please explain me? * mplsFTNActionType can take either redirectLSP or redirectTunnel. If redirecTunnel is specified, then actionptr will point to mplsTunnelEntry. So while forwarding the packets, mplsXCPtr which is there inside mplsTunnelEntry is taken and then packet will be switched accordingly. If the Action type is redirectLSP then ActionPtr points to mplsXCEntry directly. so while forwarding this will be directly referred. If my above assumption is correct, what is the use of specifying type as redirectTunnel? In either case mplsXCptr will be used for switching right, so why can't it point to mplsXCEntry always, what is the use of it pointing to redirectTunnel? If my assumption is not correct, what is the difference between redirectLSP and redirectTunnel, and in what scenario each of these types will be used? thanks rams. From owner-mpls@UU.NET Wed Jul 30 19:14:44 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22879 for ; Wed, 30 Jul 2003 19:14:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozqi27976 for ; Wed, 30 Jul 2003 23:14:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozqi27428; Wed, 30 Jul 2003 23:14:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQozqc10647 for mpls-outgoing; Wed, 30 Jul 2003 21:37:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQozqc10640 for ; Wed, 30 Jul 2003 21:37: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 QQozqc13775 for ; Wed, 30 Jul 2003 21:36:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozqc05519 for ; Wed, 30 Jul 2003 21:36:36 GMT Received: from auemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQozqc05509 for ; Wed, 30 Jul 2003 21:36:35 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6ULaVU12602 for ; Wed, 30 Jul 2003 16:36:31 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 23:36:29 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213BFB5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: FW: MIB Doctor review of: draft-ietf-mpls-ftn-mib-08.txt Date: Wed, 30 Jul 2003 23:36:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This review was on a prerelease revision 8 that I did send to the authors/editors. However, I think most (if not all of it) equally applies to rev 07. So the WG members should be able to evaluate my comments as well. Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) Sent: woensdag 30 juli 2003 23:33 To: Wijnen, Bert (Bert); 'Joan Cucchiara x302'; 'jcucchiara@mindspring.com' Cc: 'bwijnen@lucent.com'; 'zinin@psg.com'; 'loa@pi.se'; 'swallow@cisco.com'; 'mrm@riverstonenet.com'; 'hans@ipunplugged.com'; 'james_luciani@mindspring.com'; 'cheenu@alumni.princeton.edu'; 'arunv@force10networks.com'; 'kireeti@juniper.net'; 'adrian@olddog.co.uk'; 'dubuc.consulting@rogers.com'; 'jplang@ieee.org'; 'sudheer@avici.com'; 'tnadeau@cisco.com' Subject: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-08.txt Ok, here is a more complete review. I am sorry to say, that this one is not in very good shape yet. And a lot of the stuff I will be listing should (in my eyes) have been found by the WG members themselves. Oh well. Here we go: 1. When you use IP addresses in examples (you do so at several places), then you are supposed to use addresses that are set aside (reserved) for samples. See https://www1.ietf.org/ID-nits.html Where it states: - Addresses used in examples should prefer use of fully qualified domain names to literal IP addresses, and prefer use of example fqdn's such as foo.example.com to real-world fqdn's. See RFC 2606 for example domain names that can be used. There is also a range of IP addresses set aside for this purpose. These are 192.0.2.0/24 (see RFC 3330). Private addressess that would be used in the real world should be avoided in examples. 2. In your list of prefixes in sect 5.1.1 you have a few dots too many in 192.168..254.0/24, 192.168..255.0/25 But as I said under 1. above, these addresses may need to be changed anyway? 3. Section 6.1 I see: The use of address 1.4.0.1 as an example address. See point 1 above. Further I see: In mplsXCTable: { mplsXCIndex = "2", mplsInSegmentIndex = NULL, mplsOutSegmentIndex = "3", mplsXCLabelStackIndex = 0 } Note that the mplsInSegmentIfIndex value used to index this entry is the NULL string as required for an originating LSP [LSRMIB]. The "Note that... talks about "mplsInSegmentIfIndex" while the real name is "mplsInSegmentIndex" (with the "If"). Also, "NULL" and "NULL string" may be confusing cause according to the MPLS-LSR-STD_MIB, there needs to be one octet with a valu of hexadecimal 00. I also see use of addresses 1.3.0.0 and 1.5.0.0, see point 1 above. 4. In section 6.2 I see { mplsFTNIndex = 1, mplsFTNDescr = "Rule #1 for destination address 1.4.0.1", -- source address only mplsFTNMask = 0x80, mplsFTNAddrType = ipv4, mplsFTNDestAddrMin = 1.4.0.1, mplsFTNDestAddrMax = 1.4.0.1, mplsFTNActionType = redirectLsp(1), mplsFTNActionPointer = mplsXCLspId.1.2.0.1.3 } So the Descr field says it is a destination address, while the Mask says that it is a source address (as does the comment line) Yet the DestAddrMin and DestAddrMax fields are set ??? Section 6.1 also mentioned this as a source address by the way. That seems to be all pretty incosistent here!! 5. In section 6.3 on page 10 I see: { mplsFTNIndex = 3, mplsFTNDescr = "Rule #3 for destination prefix 1.4.0.0/16", -- destination address only mplsFTNMask = 0x40, mplsFTNAddrType = ipv4, -- address range equivalent to CIDR prefix 1.4.0.0/16 mplsFTNDestAddrMin = 1.4.0.0, mplsFTNDestAddrMax = 1.4.255.255, mplsFTNActionType = redirectTunnel, mplsFTNActionPointer = mplsTunnelName.3.0.3.3.3.3.4.4.4.4 } Now, I understand that you may want to express LSRIDs as 3.3.3.3 and 4.4.4.4 (although there is no DISPLAY-HINT in the textual convention MplsExtendedTunnelId, which is the syntax for the index objects in the mplsTunnelTable, so the default is to display as an unsigned number I think), but the underlying type is a Unsigned32, and so when you represent them as a rowpointer as follows: mplsFTNActionPointer = mplsTunnelName.3.0.3.3.3.3.4.4.4.4 then that is completely bogus, cause I think that the proper pointer (assuming the 3.3.3.3 (0x03030303), and 4.4.4.4 (0x04040404) as mplsTunnelIngressLSRId and mplsTunnelEgressLSRId, and assuming 3 and 0 for mplsTunnelIndex and mplsTunnelInstance) would be: mplsFTNActionPointer = mplsTunnelName.3.0.50529027.67372036 I understand tha this makes reading the example not easier, but the way you present it, I can see people get confused when they compare it with actual implementations (unless such implementations are broken and compose pointers according to your example). 6. In sect 6.4 I also think there are confusing things. For example, mplsFTNMapEntry.1.0.1 is confusing, because that OID will (or should) never exist. In fact a valid OID would be, mplsFTNMapIndex.1.0.1, although this one is not-accessible. One that is accessible would be mplsFTNMapRowStatus.1.0.1 Now I understand what you are trying to express here... but I cannot say that it is helpfull for people who try to understand the exact OIDs and indexing. Maybe better would be a notation aka: | | mplsFTNMapTable: | mplsFTNMapEntry (1.0.1): <--------------------+ +<---(mplsFTNMapIndex = 1, | | mplsFTNMapPrevIndex = 0, ---> (NULL) | | mplsFTNMapCurrIndex = 1) ------------+ | | | | By the way, the same is true for IfEntry.1 (it does not exist, it would be IfIndex.1 = 1. 7. Note that all of this may become moot after you (we) find a proper solution for the linked-list issue that I have described as a SERIOUS problem in my other email (attached at the bottom). 8. If you specify a DEFVAL of {ipv4} for the mplsFTNAddrType, then it seems to me that you MUST also specify a DEFVAL with an IPv4 Address for all the mplsFTNXxxxAddrXxx objects. Maybe a defval of { '00000000'h } -- 0.0.0.0 If you do not do that, then potentially people could create rows that have AddrType and Address not consistent. 9. I wonder if good DEFVAL values for xxxMinPort and xxxMaxPort would be 0 and 65535 respectively ?? 10. I wonder if a good DEFVAL for mplsFTNActionPointer would be 0.0 11. I see in the DESCRIPTION clause of mplsFTNActionPointer DESCRIPTION "If mplsFTNActionType is redirectLsp(2), then this object MUST contain zeroDotZero or point to a instance of mplsXCEntry indicating the LSP to redirect matching packets to. If mplsFTNActionType is redirectTunnel(3), then this object MUST contain zeroDotZero or point to a instance of mplsTunnelEntry indicating the MPLS TE tunnel to redirect matching packets to. But the mplsFTNActionType enumerates the two types as SYNTAX INTEGER { redirectLsp(1), -- redirect into LSP redirectTunnel(2) -- redirect into tunnel So that seems inconsistent 12. I wonder why mplsFTNProtocol OBJECT-TYPE SYNTAX Integer32 (0..65535) has such a large range, The protocol field is only 1 octet long, and in all other places I have seen it, it has: SYNTAX Integer32 (0..255) 13. In the various DESCRIPTION clauses in mplsFTNMaptable I see you talk about "FNT entry". Probably it would be better to speak of "mplsFTNEntry" That is it. Oh well... Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: woensdag 30 juli 2003 19:54 > To: 'Joan Cucchiara x302'; 'jcucchiara@mindspring.com' > Cc: 'bwijnen@lucent.com'; 'zinin@psg.com'; 'loa@pi.se'; > 'swallow@cisco.com'; 'mrm@riverstonenet.com'; 'hans@ipunplugged.com'; > 'james_luciani@mindspring.com'; 'cheenu@alumni.princeton.edu'; > 'arunv@force10networks.com'; 'kireeti@juniper.net'; > 'adrian@olddog.co.uk'; 'dubuc.consulting@rogers.com'; > 'jplang@ieee.org'; > 'sudheer@avici.com'; 'tnadeau@cisco.com' > Subject: MIB Doctor review of: draft-ietf-mpls-ftn-mib-08.txt > > > I am not done with review of this doc yet. > But I see one SERIOUS issue that I rather point out > now than later. > > Back with revision 6 or so I wrote: > > > > The mplsFTNMapEntry DESCRIPTION clause says: > > > > > > entry. This linked-list indexing style structure allows > > > FTN entries to be inserted at arbitrary positions in > > > the list. > > > Maybe it is me, but I still fail to see how this can be true. > > > Can you explain that for me? > > > And Cheenu (I believe) answered: > > > I have included all relevant explanation about this table's indexing > > (essentially material from section 5.2 but making the MIB > module self > > contained) in the DESCRIPTION clause of mplsFTNMapTable. Please take > > a look at that and tell me if this is clear now. > > > > Well, I look at the new MIB and the new descriptions in section 5. > And all I can conclude is that according to the SNMP protocol > this is completely unacceptable. > If I understand it correctly, then to insert a row, you issue > (in your example in sect 6.3) a SNMP SET command as follows: > (I know this is not the exact format, but you get the idea) > > SNMP SET ( mplsFTNMapIndex = 1, > mplsFTNPrevIndex = 1, > mplsFTNMapCurrIndex = 3 > -- it also has a rowStatus and a StorageType > ) -- so you create mplsFTNMapEntry 1.1.3 > > Before you do so, the table had these entries (the number are the > indices for the entries) > > 1.0.1 > 1.1.2 > > The normal SNMP SET result is these 3 entries: > > 1.0.1 > 1.1.2 > 1.1.3 > > But you seem to describe that the side effects of you creating row > 1.1.3, the other entry 1.1.2 gets changed, and that the resulting > table will have these entries: > > 1.0.1 > 1.1.3 > 1.3.2 > > That to me seems a TOTALLY UNACCEPTABLE behaviour for the SNMP > SET operation that was received. > > Similar, once you have that set of 3 tables entries that you describe, > you suggest that a SNMP SET to destroy entry 1.1.3 > > The normal SNMP SET result would be a table of these 2 entries, > > 1.0.1 > 1.3.2 > > but you describe that the SNMP agent should have some side effect > which results in a table with these entries: > > 1.0.1 > 1.1.2 > > First, did I understand the descriptions correctly? > If not pls tell me where I am wrong. > > If I did understand it correctly, how do you think that a normal > SNMP agent or manager can deal with the side-effects you are > describing. It seems totally against the normal behaviour of > SNMP SET operation and SNMP agent and manager behaviour. > > Once you tell me that my reading of section 5.2 and the examples > in section 6 is correct, I will check with the rest of the MIB > doctors, but I suspect that they will unanimously agree with me. > > Thanks, > Bert > From owner-mpls@UU.NET Wed Jul 30 20:21:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24758 for ; Wed, 30 Jul 2003 20:21:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozqn02069 for ; Thu, 31 Jul 2003 00:21:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozqn01984; Thu, 31 Jul 2003 00:21:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQozpy16330 for mpls-outgoing; Wed, 30 Jul 2003 20:33:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQozpy16321 for ; Wed, 30 Jul 2003 20:33: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 QQozpx10235 for ; Wed, 30 Jul 2003 20:29:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozpx13952 for ; Wed, 30 Jul 2003 20:29:34 GMT Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQozpx13941 for ; Wed, 30 Jul 2003 20:29:34 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6UKBTU29877 for ; Wed, 30 Jul 2003 15:11:30 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 22:11:28 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213BFB1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: SERIOUS issue in: draft-ietf-mpls-ftn-mib-07.txt Date: Wed, 30 Jul 2003 22:11:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I was reviewing a pre-release of revision 8 and ran into a serious issue, which I have reported to the authors/editors. The same issue exists in revision 07, so for the record I want to alert the WG about it. Here we go. I am not done with review of this doc yet. But I see one SERIOUS issue that I rather point out now than later. Back with revision 6 or so I wrote: > > The mplsFTNMapEntry DESCRIPTION clause says: > > > > entry. This linked-list indexing style structure allows > > FTN entries to be inserted at arbitrary positions in > > the list. > > Maybe it is me, but I still fail to see how this can be true. > > Can you explain that for me? > And Cheenu (I believe) answered: > I have included all relevant explanation about this table's indexing > (essentially material from section 5.2 but making the MIB module self > contained) in the DESCRIPTION clause of mplsFTNMapTable. Please take > a look at that and tell me if this is clear now. > Well, I look at the new MIB and the new descriptions in section 5. And all I can conclude is that according to the SNMP protocol this is completely unacceptable. If I understand it correctly, then to insert a row, you issue (in your example in sect 6.3) a SNMP SET command as follows: (I know this is not the exact format, but you get the idea) SNMP SET ( mplsFTNMapIndex = 1, mplsFTNPrevIndex = 1, mplsFTNMapCurrIndex = 3 -- it also has a rowStatus and a StorageType ) -- so you create mplsFTNMapEntry 1.1.3 Before you do so, the table had these entries (the number are the indices for the entries) 1.0.1 1.1.2 The normal SNMP SET result is these 3 entries: 1.0.1 1.1.2 1.1.3 But you seem to describe that the side effects of you creating row 1.1.3, the other entry 1.1.2 gets changed, and that the resulting table will have these entries: 1.0.1 1.1.3 1.3.2 That to me seems a TOTALLY UNACCEPTABLE behaviour for the SNMP SET operation that was received. Similar, once you have that set of 3 tables entries that you describe, you suggest that a SNMP SET to destroy entry 1.1.3 The normal SNMP SET result would be a table of these 2 entries, 1.0.1 1.3.2 but you describe that the SNMP agent should have some side effect which results in a table with these entries: 1.0.1 1.1.2 First, did I understand the descriptions correctly? If not pls tell me where I am wrong. If I did understand it correctly, how do you think that a normal SNMP agent or manager can deal with the side-effects you are describing. It seems totally against the normal behaviour of SNMP SET operation and SNMP agent and manager behaviour. Once you tell me that my reading of section 5.2 and the examples in section 6 is correct, I will check with the rest of the MIB doctors, but I suspect that they will unanimously agree with me. Thanks, Bert From owner-mpls@UU.NET Thu Jul 31 05:26:12 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17803 for ; Thu, 31 Jul 2003 05:26:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozrx06943 for ; Thu, 31 Jul 2003 09:26:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozrx06785; Thu, 31 Jul 2003 09:26:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQozrw25071 for mpls-outgoing; Thu, 31 Jul 2003 09:03:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQozrw24956 for ; Thu, 31 Jul 2003 09:03:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQozrw29741 for ; Thu, 31 Jul 2003 09:00:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozrw19186 for ; Thu, 31 Jul 2003 09:00:58 GMT Received: from mailf.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailf.telia.com [194.22.194.25]) id QQozrw19140 for ; Thu, 31 Jul 2003 09:00:56 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailf.telia.com (8.12.9/8.12.9) with ESMTP id h6V90oc0021874; Thu, 31 Jul 2003 11:00:50 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h6V90oc24703; Thu, 31 Jul 2003 11:00:50 +0200 (CEST) Message-ID: <3F28D91D.3010608@pi.se> Date: Thu, 31 Jul 2003 10:53:49 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG , George Swallow , Alex Zinin Subject: preliminary mpls wg minutes Content-Type: multipart/mixed; boundary="------------060109060108030003090100" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------060109060108030003090100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, the preliminary minutes form the MPLS WG in Vienna included. Thanks to Dave and Tove who took notes! -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se --------------060109060108030003090100 Content-Type: text/plain; name="mpls-minutes.txt" Content-Disposition: inline; filename="mpls-minutes.txt" Content-Transfer-Encoding: 7bit Preliminary Minutes MPLS WG meeting in Vienna. MPLS WG, Tuesday July 15 9am -------------------- Scribes / Dave Allan and Tove Madsen Agenda bashing -------------- - no comments Administrivia ------------- - blue sheets - note takers ITU Liaison/Jun Kyun Choi ------------------------- Mobile IP over MPLS 11/13 (see slides) - overview of features - scope and "out of scope" - reference architecture - service scenarios (tunneling, route optimization, binding update, hierarchical tunneling) - overview of other aspects - status in SG13 (consent in Geneva next week) Comment from George Swallow : on the status of progressing RSVP over CR-LDP. Clarification from George: on binding, we will have one solution. Monique Morrow: What considerations to OAM have you thought about? A: No inclusion of diagnostics in the document at this time. Rahual Aggarwal: Not clear to me what kind of feedback you are looking for. Not clear what has to be done here. A: Work to be done to bind mobile IP network to the MPLS network. George: Is there a specific item of work you are looking for, what kind of response? Is this informational? A: Mainly informational, this work is kept in the ITU. Would like to collaborate. Alex: If you want collaboration, you should publish as one or more drafts and solicit feedback from the list. MIB Discussion -------------- Loa : Since Atlanta we've been driving the MIB authors quite hard. I'd like to thank those working hard on this. The work is late and this has been a source of frustration. We are not finished but are pretty close. Send for IESG review before end of summer. Bert: The most important thing is the discussion between the authors and the AD (acting as MIB doctor). Things needed fixing and there were items where the approach was questioned. Over the last few weeks we've had good discussion. Meeting all AD/doctor requirements are not completely necessary, WG consensus is key due to implementation experience etc. (see Tom Nadeau's slides). - general updates applied to all MIBs - overview of changes to individual MIBs Bert: Adrian had a list of some 65 nits on the TE MIB and hasn't been able to check if all of these have been addressed. I've posted compile comments last night and this morning. Is the plan to recycle a few MIBs? Tom: I think we'll have to in a few cases. Some comments were too nitty. Most of the comments are adressed. Bert: Would like to see that signed off, chairs need to establish consensus. Loa: Consensus is problematic. There is a huge consensus in the room, on the list etc. to get this done now. Not ready to take the MIBs and send to the IESG. When Adrian/etc. etc satisfied that we've addressed the comments then I'd like to go. We're 99% ready, lets do the last little bit. Adrian: Looking to do a point by point review of the emails and finish them off this week. Tom: On setting a final deadline, a week, two weeks. Loa: Don't want shorter than required, what about two weeks? Lets set Aug 1 as the deadline. Loa: FRR MIB not complete. Pretty much stable. Would like to do a last call coming out of this meeting. Tom: There are three implementations of the existing MIB. Have a look on those before last call. Loa: You want to do a pass before last call. Tom: Probably a good idea. Adrian: Hold up the overview until the new MIBs done? Loa: Need a respin. Tom: Purpose was the base 5 MIBs. LDP Requirements/ Wai Sum Lai draft-lai-mpls-mib-rqmts-00 ---------------------------------------------------------------- (see slides) focus on LDP MIBs, - pm requirements - fm requirements Information that would help them engineer resource usage etc. Help with trouble shooting. Get good linkages with I/F MIB. Propose meeting requirements be delegated to the MIB authors. Tom Nadeau: Bunch of points (already discussed on the list). Want to hear from other operators. IMHO requires protocol changes so needs consensus. Some points were added to current MIB. Vast majority not addressed in the absence of other operator feedback. Loa: These are going into mailing list and has no effect on current MIBs. we have to see imapct on future MIBs. Draft-allan-mpls-a-bit-00 ------------------------- Lots of impedance. (Mainly Kireeti, Rahul and Yakov). Centered around MPLS PID in general. Discussion points: - Is reserved labels and ECMP an issue (to be taken to the list)? - Is the PW PID applicable to MPLS? - Effect on whats out there now? (George Swallow) - Backward copatability? (Thomas Nadeau) - What processing power do I need? (G.Swallow) - Where are the changes suggested? In PWE3 or MPLS? (Loa) - Is IP ok? (G.Swallow) Yes (D. Allan) - Will rename the MPLS PID to PWE3 PID (Stewart Bryant) Dave to post a problem statement to the list for discussion. Draft-swallow-lsr-self-test-00/George Swallow --------------------------------------------- George walked through the ECMP example of how it gets combinatorial. Outlined LSR self test as a means of an LSR instigating tests of its own forwarding table. An extension of LSP Ping. Adrian: Applicability to RSVP-TE (draft focuses on LDP)? G.Swallow: yes. Dave Allan: Concern with requirement to generate a ping transaction per ILM entry in each LSR. George: You're making assumptions as to the frequency. Dave: no. Jun Kyun Choi: end to end but no hierarchy? G.Swallow: Hop by Hop. Tom Nadeau: Recycles existing forwarding behavior. Already optimized on my cards. Loa: Need to go on. Show of hands for making this a WG document. Sufficient interest to take this to the list. Multicast Seisho Yasukawa & Rahul Aggarwal ------------------------------------------ Outline of deltas between IP multicast and expectations that can only be met with addition of QoS. Overview of joint requirements draft. A short history of this multicast work was presented. Establishing P2MP MPLS TE LSPs draft-raggarwa-mpls-p2mp-te-00 Overview of the proposed mechanisms for setup of P2MP LSPs. - P2MP session object - Rpe discovery (application dependent) - Make before break... - Some FRR applicability Alex: IPR notification in the draft needs to be sent on to IETF secretary. "Other proposal" (Allan Kullberg) -------------- Draft summary presented Goal is to reconcile approaches, provide a common requirements and problem statement draft. Targeted for next IETF. Need WG to confirm inclusion in charter and determine next steps. Loa: Like the time schedule. Need a short problem statement and milestones to take to the IESG. Rahul: I'll send a mail to the mailing list. Loa: I'll add milestone to charter. Dimitri: Do you want to see the spectrum of solutions discussed? George: only want crisp requirements, not a framework document. RRO Node-ID Subobject; draft ietf mpls nodeid subobject/ JP Vasseur ------------------------------------------------------------------- Quick overview. Ongoing implementations and several planned deployments, proposal to move the I-D to last call. George: take it to the list. Dimitri: (needs clarification, essence sounded like "is this really necessary?"). Draft vasseur-mpls-loose-path-reopt-02/JP Vasseur ------------------------------------------------- Conclusion, draft proposes mechanisms that are identified as required in the TEWG inter-AS requirements document. George: How to proceed simply needs a discussion between Alex, Kireeti and charis. LDP MTU Discovery/Kireeti ------------------------- - provided some new definitions (hop MTU) - egress MTU is broken - transit node decides what downstream MTU is. - Handling U/F when not supported. - Revise according to last round of comments, post to last call. Luca: Please make sure you agree on what MTU is. DO not want more arguments between Cisco and Juniper. Kireeti: Definition is in the draft. Needs to be compatible with RSVP. Please read the definition. LSP-PING -------- I've also posted a new version of LSP PING, please comment, if we get no comments I'll go to last call. (George indicated some comments, short issues list). Draft-ietf-mpls-LSP-query-09/Dave Allan --------------------------------------- Overview of changes as a result of IESG review, including changes (query payload TLV) that necessitate a WG last call. George: We'll post it to the list. Alex: Implementation status? Dave: We've done some prototyping, but not of the new TLV. WG Status:/Loa -------------- We did a start of re-chartering the working group after Atlanta. Coincided with the discussion/decission on splitting the Sub-IP Area. Since the charter criteria are (marginally) different between areas it had to wait. Will restart the process now. Meeting concluded. --------------060109060108030003090100-- From owner-mpls@UU.NET Thu Jul 31 19:25:03 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18809 for ; Thu, 31 Jul 2003 19:25:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozub26970 for ; Thu, 31 Jul 2003 23:25:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQozub22978; Thu, 31 Jul 2003 23:23:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQozsr02219 for mpls-outgoing; Thu, 31 Jul 2003 14:21:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQozsr02212 for ; Thu, 31 Jul 2003 14:21: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 QQozsq27495 for ; Thu, 31 Jul 2003 14:12:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQozsq16543 for ; Thu, 31 Jul 2003 14:12:06 GMT Received: from tiger.seabridge.co.il by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bzq-25-127-226.cust.bezeqint.net [212.25.127.226]) id QQozsq16491 for ; Thu, 31 Jul 2003 14:12:03 GMT Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 17:11:16 +0200 Message-ID: From: Nurit Sprecher To: "'ppan@ciena.net'" , "'dhg@juniper.net'" , "'swallow@cisco.com'" , "'jpv@cisco.com'" , "'dcooper@gblx.net'" , "'aatlas@avici.com'" , "'mjork@avici.com'" Cc: "'mpls@uu.net'" Subject: Detour Backup Date: Thu, 31 Jul 2003 17:11:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35775.FC678A20" 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_01C35775.FC678A20 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi all, I have a question regarding the one-to-one (detour) backup that is = described in the draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. I would like to support the one-to-one backup method, using the path-specific method.=20 I would like to protect the LSP R1-R2-R3-R4-R5-R6 in the figure below. = At each PLR a detour is created and merged to the protected LSP as soon as possible. All over the way I would like to protect against the next = hops (I.e. R2, R3, R4 and R5), but in R5 I would like to protect against the = next link. How can I do it if the link between R5 and R6 is an unnumbered = link? In the DETOUR Object I should put the Ipv4 address of the node (link?) = to be avoided. =20 R1---R2---R3---R4---R5---R6 =20 I=92ll appreciate your response. Thanks in advance, Nurit. =20 =20 ------_=_NextPart_001_01C35775.FC678A20 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi = all,

I have a =
question regarding the one-to-one (detour) backup that is described in =
the draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt.<=
/font>
I would like to support the =
one-to-one backup method, using the path-specific method. =

I would like to protect the =
LSP R1-R2-R3-R4-R5-R6 in the figure below. At each PLR a detour is =
created and merged to the protected LSP as soon as possible. All over =
the way I would like to protect against the next hops (I.e. R2, R3, R4 =
and R5), but in R5 I would like to protect against the next link. =
How can I do it if the link between R5 and =
R6 is an unnumbered link? In the DETOUR Object I should put =
the Ipv4 address of the node (link?) to be avoided.
 =

                  <=
/span>R1---R2---R3---R4---R5---R6=

 
I=92ll appreciate your =
response.
Thanks in advance, =
Nurit.


 
=



 
=
------_=_NextPart_001_01C35775.FC678A20--