From mpls-bounces@lists.ietf.org Mon Jul 03 05:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKlz-0007iE-9T; Mon, 03 Jul 2006 05:31:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKly-0007ha-57 for mpls@lists.ietf.org; Mon, 03 Jul 2006 05:31:18 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxKi9-0007eX-DL for mpls@lists.ietf.org; Mon, 03 Jul 2006 05:27:22 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k639R2D22758; Mon, 3 Jul 2006 11:27:02 +0200 (CEST) Received: from [10.61.255.122] (ams-stealth-iwijnand-2.cisco.com [10.61.255.122]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k639R0C12047; Mon, 3 Jul 2006 11:27:00 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <97ec7ae1c452573b3ffb0182231f04b8@cisco.com> Content-Transfer-Encoding: quoted-printable From: IJsbrand Wijnands Date: Mon, 3 Jul 2006 11:27:00 +0200 To: jin.lizhong@zte.com.cn X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: rhthomas@cisco.com, mpls@lists.ietf.org Subject: [mpls] Re: Some questions about draft-ietf-mpls-ldp-p2mp-01, thank you! X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, > > 2.3.1.1. =A0Determining one's 'upstream LSR' > > =A0 =A0A node Z that is part of P2MP LSP determines the LDP = peer U > =A0 =A0which lies on the best path from Z to the root node X. If there = are > =A0 =A0more than one such LDP peers, only one of them is picked. =A0U = is Z's > =A0 =A0"Upstream LSR" for . > > Which is the "best path" for Z. Two ways can determine the best path. > 1. Z can look up the normal "route table", and get the best path =20 > according the route.(The route table may be generated by OSPF, ISIS, =20= > RIP, or even OSPF-TE) > > 2. Z can get the best path according the multicast table (this table =20= > may be generated by various multicast routing protocols), and the P2MP = =20 > LSP or MP2MP LSP will only work on the routers that support =20 > corresponding multicast routing protocols. Can you give an example of a multicast routing protocol that populates =20= such a table? > > The two ways are not compatiable, and the two P2MP LSPs or MP2MP LSPs =20= > are defferent. Maybe this draft should describe the two ways, and =20 > specify one way or both the two ways. The best path selection problem =20= > should be solved. Are you suggesting we should set priority to one table over the other? It looks to me that the table selection is a local policy and does not =20= necessarily need to be the same on each LSR. You may want to use a =20 MuRIB between 2 LSRs just to make Multicast divert from Unicast for a =20= specific link. How these two tables are used is up to the operator to =20= define. It does not seems to be something the draft must spell out. So =20= I think this is out side the scope of the document. Thx, Ice. > > > > > > > -------------------------------------------------------- > = ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0i= n=A0this=A0mail=20 > = =A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organization.=A0This=A0m= ail=A0communicati=20 > = on=A0is=A0confidential.=A0Recipients=A0named=A0above=A0are=A0obligated=A0t= o=A0maintain=A0se=20 > = crecy=A0and=A0are=A0not=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0= this=A0communicat=20 > ion=A0to=A0others. > = This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confide= ntial=A0and=A0inten=20 > = ded=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0or=A0entity=A0to=A0= whom=A0they=A0are=A0add=20 > = ressed.=A0If=A0you=A0have=A0received=A0this=A0email=A0in=A0error=A0please=A0= notify=A0the=A0orig=20 > = inator=A0of=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0messa= ge=A0are=A0those=A0of=20 > =A0the=A0individual=A0sender. > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0= ZTE=A0Anti-=20 > Spam=A0system. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jul 03 07:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxMqN-0002Fy-IO; Mon, 03 Jul 2006 07:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxEvh-00020X-2w for mpls@lists.ietf.org; Sun, 02 Jul 2006 23:16:57 -0400 Received: from mail.zte.com.cn ([202.103.147.144] helo=Riskfilter2.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxEvf-0004oo-58 for mpls@lists.ietf.org; Sun, 02 Jul 2006 23:16:57 -0400 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 75590.4966168723; Mon, 3 Jul 2006 11:33:18 +0800 (CST) To: ina@juniper.net, kireeti@juniper.net, ice@cisco.com, rhthomas@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: jin.lizhong@zte.com.cn Date: Mon, 3 Jul 2006 11:16:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-07-03 11:16:56, Serialize complete at 2006-07-03 11:16:56 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Mon, 03 Jul 2006 07:43:58 -0400 Cc: mpls@lists.ietf.org Subject: [mpls] Some questions about draft-ietf-mpls-ldp-p2mp-01, thank you! X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1326454147==" Errors-To: mpls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1326454147== Content-Type: multipart/alternative; boundary="=_alternative 00121C78482571A0_=" This is a multipart message in MIME format. --=_alternative 00121C78482571A0_= Content-Type: text/plain; charset="US-ASCII" 2.3.1.1. Determining one's 'upstream LSR' A node Z that is part of P2MP LSP determines the LDP peer U which lies on the best path from Z to the root node X. If there are more than one such LDP peers, only one of them is picked. U is Z's "Upstream LSR" for . Which is the "best path" for Z. Two ways can determine the best path. 1. Z can look up the normal "route table", and get the best path according the route.(The route table may be generated by OSPF, ISIS, RIP, or even OSPF-TE) 2. Z can get the best path according the multicast table (this table may be generated by various multicast routing protocols), and the P2MP LSP or MP2MP LSP will only work on the routers that support corresponding multicast routing protocols. The two ways are not compatiable, and the two P2MP LSPs or MP2MP LSPs are defferent. Maybe this draft should describe the two ways, and specify one way or both the two ways. The best path selection problem should be solved. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00121C78482571A0_= Content-Type: text/html; charset="US-ASCII"
2.3.1.1.  Determining one's 'upstream LSR'

   A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U
   which lies on the best path from Z to the root node X. If there are
   more than one such LDP peers, only one of them is picked.  U is Z's
   "Upstream LSR" for <X, Y>.

Which is the "best path" for Z. Two ways can determine the best path.
1. Z can look up the normal "route table", and get the best path according the route.(The route table may be generated by OSPF, ISIS, RIP, or even OSPF-TE)

2. Z can get the best path according the multicast table (this table may be generated by various multicast routing protocols), and the P2MP LSP or MP2MP LSP will only work on the routers that support corresponding multicast routing protocols.

The two ways are not compatiable, and the two P2MP LSPs or MP2MP LSPs are defferent. Maybe this draft should describe the two ways, and specify one way or both the two ways. The best path selection problem should be solved. 




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00121C78482571A0_=-- --===============1326454147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1326454147==-- From mpls-bounces@lists.ietf.org Mon Jul 03 10:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPo5-0000Yc-Tl; Mon, 03 Jul 2006 10:53:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPo4-0000YW-56 for mpls@lists.ietf.org; Mon, 03 Jul 2006 10:53:48 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPo1-0002qE-N1 for mpls@lists.ietf.org; Mon, 03 Jul 2006 10:53:48 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 16:53:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-01.txt Date: Mon, 3 Jul 2006 16:53:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-01.txt Thread-Index: AcaWTlSfjLptYTu8RxmtAyBkACh1HAIXs3Qg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 03 Jul 2006 14:53:43.0674 (UTC) FILETIME=[7AB4CDA0:01C69EB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi folks Here are the majors changes in this new revision: -One mandatory requirement added in section 5.4: Leaf Addition/Removal = MUST not impact data transfer towards other leaves; -Section 5.8.2 and 5.8.3 have been reformulated to account for the = tension between packet loss and packet duplication during rerouting;=20 -Section 6.1: Detailed requirements for MP2MP LSPs have been added; -Section 7.1: The controversial text (the solution SHOULD not require = deploying an additional routing protocol...) has been removed and = replaced by "the P2MP LDP mechanism SHOULD be designed with as key = objective to minimize the additional amount of state and additional = processing required in the network..." -Edits suggested by Ben have been included; -And also minor edits for the sake of clarity. We are waiting for your comments on this new version, particularly on = the above points. Regards, JL > -----Message d'origine----- > De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Envoy=E9 : vendredi 23 juin 2006 00:50 > =C0 : i-d-announce@ietf.org > Cc : mpls@lists.ietf.org > Objet : [mpls] I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label=20 > Switching Working Group of the IETF. >=20 > Title : Requirements for point-to-multipoint=20 > extensions to the Label=20 > Distribution Protocol > Author(s) : J. Le Roux, et al. > Filename : draft-ietf-mpls-mp-ldp-reqs-01.txt > Pages : 17 > Date : 2006-6-22 > =09 > This document lists a set of functional requirements for Label=20 > Distribution Protocol (LDP) extensions for setting up point-to- > multipoint (P2MP) Label Switched Paths (LSP), in order to deliver=20 > point-to-multipoint applications over a Multi Protocol Label=20 > Switching (MPLS) infrastructure. It is intended that=20 > solutions that=20 > specify LDP procedures for setting up P2MP LSP satisfy these=20 > requirements. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-mpls-mp-ldp-reqs-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jul 04 14:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxpP3-0003MH-PQ; Tue, 04 Jul 2006 14:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxXxD-0004BM-0R for mpls@lists.ietf.org; Mon, 03 Jul 2006 19:35:47 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxXxC-0001Sp-Mm for mpls@lists.ietf.org; Mon, 03 Jul 2006 19:35:46 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k63NZA1u014783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jul 2006 23:35:11 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FxXwc-0006us-SF; Mon, 03 Jul 2006 19:35:10 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg jones From: Adrian Farrel(IETF CCAMP WG) Message-Id: Date: Mon, 03 Jul 2006 19:35:10 -0400 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oak.neustar.com id k63NZA1u014783 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-Mailman-Approved-At: Tue, 04 Jul 2006 14:13:40 -0400 Cc: Yoichi Maeda , Jari Arkko , IESG , Mark Townsley , Ross Callon , Stewart Bryant , MPLS mailing list , Danny McPherson , Houlin Zhao , IAB , Ghani Abbas , Scott Brim , PWE3 mailing list , Bill Fenner , CCAMP mailing list , Malcolm Betts Subject: [mpls] New Liaison Statement, "Continued IETF / SG15 Cooperation on T-MPLS and other MPLS Issues" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Title: Continued IETF / SG15 Cooperation on T-MPLS and other MPLS Issues Submission Date: 2006-07-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D241=20 Please reply by 2006-09-25 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T SG15(Greg jones ) Cc: Loa Andersson George Swallow Deborah Brungard Ross Callon Bill Fenner Stewart Bryant Danny McPherson < danny@arbor.net> Mark Townsley IESG IAB Steve Trowbridge Malcolm Betts Ghani Abbas Houlin Zhao Yoichi Maeda Jari Arkko Scott Bradner Scott Brim CCAMP mailing list MPLS mailing list PWE3 mailing list Reponse Contact: Adrian Farrel Ross Callon Technical Contact: Stewart Bryant Loa Andersson Purpose: For action=20 Body: From: Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, adrian@o= lddog.co.uk) Loa Andersson (IETF MPLS WG Chair; loa@pi.se) George Swallow (IETF MPLS WG Chair; swallow@cisco.com) Deborah Brungard (IETF CCAMP WG Chair, dbrungard@att.com) Ross Callon (IETF Routing Area Director; rcallon@juniper.net) Bill Fenner (IETF Routing Area Director; fenner@rearch.att.com) Stewart Bryant (IETF PWE3 WG Chair; stbryant@cisco.com) Danny McPherson (IETF PWE3 WG Chair, danny@arbor.net) Mark Townsley (IETF Internet Area Director, townsley@cisco.com) =09 To: ITU-T Study Group 15; Greg Jones (greg.jones@itu.int) CC: IESG (iesg@ietf.org) IAB (iab@ietf.org) Steve Trowbridge (sjtrowbridge@lucent.com) Malcolm Betts (betts01@nortel.com) Ghani Abbas (ghani.abbas@marconi.com) Houlin Zhao (houlin.zhao@itu.int) Yoichi Maeda (maeda@ansl.ntt.co.jp) Jari Arkko (jari.arkko@piuha.net) Scott Bradner (sob@harvard.edu) Scott Brim (sbrim@cisco.com) CCAMP mailing list (ccamp@ops.ietf.org) MPLS mailing list (mpls@lists.ietf.org) PWE3 mailing list (pwe3@ietf.org) Subject: Continued IETF / SG15 Cooperation on T-MPLS and other MPLS Issue= s We would like to thank you for the invitation to allow IETF experts to at= tend the recent SG15 Rapporteur=E2=80=99s meeting in Ottawa. We were part= icularly interested in contributing to the SG15, Question 12 meeting cons= idering T-MPLS specifications. We note that multiple IETF experts attende= d, including Ross Callon (Routing AD), Loa Andersson (MPLS WG Chair), and= Stewart Bryant (PWE3 WG Chair). We also note that this meeting resulted = in a very cooperative and productive discussion, which resulted in signif= icantly improved mutual understanding of issues as well as substantial de= tailed discussion. This included detailed technical discussion as well as= detailed text editing.=20 During the Rapporteur=E2=80=99s meeting, extensive technical updates were= proposed and agreed to for G.8110.1 (Architecture of Transport MPLS (T-M= PLS) Layer Network ). These discussions identified issues, errors, and om= issions in G.8110.1, and also came up with a significant amount of new te= xt which allows very substantial improvements to this document. These dis= cussions also identified areas for further consideration and where additi= onal improvements, clarifications and/or discussions are warranted, such = as the need for specification of the requirements for T-MPLS, as well as = for specification of the scope of applicability. We would like to strongly recommend that G.8110.1 not be published in the= form that was consented prior to the Ottawa meeting, and that the substa= ntial improvements that were agreed in the Ottawa meeting be incorporated= in the text prior to publication. Furthermore, due to the extensive natu= re of these important improvements, and due to the existence of some furt= her issues that warrant additional consideration, we also strongly recomm= end that time be allowed for review of the updated document by SG15 and I= ETF experts, including an additional round of liaison of this document to= the IETF, and particularly to the MPLS, CCAMP, and PWE3 working groups f= or further review and comment.=20 We are aware that a further Rapporteur's meeting is planned for Sophia An= tipolis in the week commencing 18th September 2006, and we hope that it w= ill be possible to facilitate attendance by non-ITU IETF experts in order= to continue the excellent cooperative progress made in Ottawa. We reques= t that any updates made to, or proposed for, the text of G.8110.1 be liai= sed to the IETF after the September meeting to allow us to make comments = in advance of the SG15 Plenary in October/November this year. We would like to thank you and SG15 participants for the very positive in= teraction at the Ottawa Rapporteur=E2=80=99s meeting, and we look forward= to continued positive interaction between ITU and IETF experts.=20 Sincerely, Adrian Farrel Loa Andersson George Swallow Deborah Brungard Ross Callon Bill Fenner Steward Bryant Danny McPherson Mark Townsley Attachment(s): No document has been attached _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 05 11:00:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8qC-000277-Pq; Wed, 05 Jul 2006 10:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8qA-00026f-8L for mpls@ietf.org; Wed, 05 Jul 2006 10:58:58 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8q8-0001vQ-Uh for mpls@ietf.org; Wed, 05 Jul 2006 10:58:58 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k65Ewu1Z095983; Wed, 5 Jul 2006 07:58:56 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k65Ewu527140; Wed, 5 Jul 2006 07:58:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200607051458.k65Ewu527140@merlot.juniper.net> To: George Swallow In-Reply-To: Your message of "Wed, 28 Jun 2006 16:07:09 EDT." <20060628200709.A711E219BE1@SwallowPB.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53555.1152111536.1@juniper.net> Date: Wed, 05 Jul 2006 07:58:56 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org George, > > A combination of this address and P2MP ID > > provides a globally unique identifier for the P2MP tunnel. > > I want this to be the full tuple: > > That would be fine, *as long as* you provide *technical* justification(s) on why is not sufficient. > Further we should only be calling this a globally unique identifier of a > tunnel since the set of endpoint can change over the lifetime of the > tunnel. On that I certainly agree with you. Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 05 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy90q-00083D-DS; Wed, 05 Jul 2006 11:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy90p-000838-9A for mpls@ietf.org; Wed, 05 Jul 2006 11:09:59 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy90o-000321-3C for mpls@ietf.org; Wed, 05 Jul 2006 11:09:59 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1Fy90Z-0000Wp-0T; Wed, 05 Jul 2006 11:09:43 -0400 Message-Id: <7.0.1.0.2.20060705110255.05d5bd48@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 05 Jul 2006 11:09:44 -0400 To: Yakov Rekhter From: Lou Berger In-Reply-To: <200607051439.k65Edi519749@merlot.juniper.net> References: <200607051439.k65Edi519749@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org At 10:39 AM 7/5/2006, Yakov Rekhter wrote: >Could you please provide *technical* reason(s) that would explain why >a combination of P2MP ID and Extended Tunnel ID is not sufficient ? > >Yakov. Yakov, Simply, because that's the way MPLS and GMPLS is specified today and works in running code. If you want to change something from the way it works today, i.e, in RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to justify why what's there needs to be changed. The case has been made for why the session object must use a P2MP ID rather than a destination IP address. The case has not been made for changing the definition or semantics of Tunnel ID. Can provide the justification of why we need to deviate from current specs on definition of Tunnel ID? Lou _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 05 12:09:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9ue-0006jH-4b; Wed, 05 Jul 2006 12:07:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9uc-0006jC-6W for mpls@ietf.org; Wed, 05 Jul 2006 12:07:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9uZ-0007gu-Qf for mpls@ietf.org; Wed, 05 Jul 2006 12:07:38 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2006 12:07:36 -0400 X-IronPort-AV: i="4.06,210,1149480000"; d="scan'208"; a="91699793:sNHT31509740" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k65G7Zno027734; Wed, 5 Jul 2006 12:07:35 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 12:07:35 -0400 Received: from SwallowPB.local ([161.44.74.167]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 12:07:35 -0400 Received: from cisco.com (localhost [127.0.0.1]) by SwallowPB.local (Postfix) with ESMTP id 43C1921D67D; Wed, 5 Jul 2006 12:08:40 -0400 (EDT) To: Lou Berger In-reply-to: Your message of "Wed, 05 Jul 2006 11:09:44 EDT." <7.0.1.0.2.20060705110255.05d5bd48@labn.net> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Wed, 05 Jul 2006 12:08:40 -0400 Message-Id: <20060705160840.43C1921D67D@SwallowPB.local> X-OriginalArrivalTime: 05 Jul 2006 16:07:35.0034 (UTC) FILETIME=[20D42DA0:01C6A04D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mpls@ietf.org, ccamp@ops.ietf.org, p2mp@labn.net Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > Simply, because that's the way MPLS and GMPLS is specified > today and works in running code. > > If you want to change something from the way it works today, i.e, in > RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to > justify why what's there needs to be changed. The case has been made > for why the session object must use a P2MP ID rather than a > destination IP address. The case has not been made for changing the > definition or semantics of Tunnel ID. > > Can provide the justification of why we need to deviate from current > specs on definition of Tunnel ID? Absolutely. We didn't start with a blank piece of paper. We're building on existing things. So the onus for argument, should you choose to pursue it, is in your court. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 05 13:05:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAme-00054P-C7; Wed, 05 Jul 2006 13:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAmc-00052g-Sl for mpls@ietf.org; Wed, 05 Jul 2006 13:03:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8y2-0002nj-RT for mpls@ietf.org; Wed, 05 Jul 2006 11:07:06 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy8Xf-0002KW-3K for mpls@ietf.org; Wed, 05 Jul 2006 10:39:51 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k65Edo1Z094419; Wed, 5 Jul 2006 07:39:50 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k65Edi519749; Wed, 5 Jul 2006 07:39:44 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200607051439.k65Edi519749@merlot.juniper.net> To: Lou Berger In-Reply-To: Your message of "Tue, 27 Jun 2006 22:01:37 EDT." <7.0.1.0.2.20060627215027.050aaf60@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52992.1152110384.1@juniper.net> Date: Wed, 05 Jul 2006 07:39:44 -0700 From: Yakov Rekhter X-Spam-Score: -2.5 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Lou, > >[clipped...] > > > > > > > > > > The P2MP ID provides an identifier for the set of > > > > > > > > destinations of the P2MP TE Tunnel. > > > > > > > > > > > > > > > >The last sentence above has to be deleted. > > > > > > > > > > > > > > why, what's incorrect about it? > > > > > > > > > > > >To begin with, the last sentence states that the P2MP ID, *by itself* > > > > > >"provides an identifier for the set of destinations of a given P2MP > > > > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not > > > > > >be unique, how could it unambiguously identify the set of > > > > > >destinations of such tunnel ? > > > > > > > > > > You are 100% correct, how about fixing it by saying: > > > > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an > > > > > identifier for the set of destinations of the P2MP TE Tunnel." > > > > > > > >Given that P2MP ID is unique within the scope of the root, why a > > > >tuple is not sufficient to identify > > > >the set of destinations of a P2MP tunnel ? After all, you agreed > > > >further down that such a tuple identifies a P2MP tunnel. > > > > > > Because this would preclude the use of tunnel ID to further partition > > > the session space (as is done today for P2P-TE.) The tuple I > > > mentioned included all three. > > > >You, yourself agreed that "A combination of this address and P2MP > >ID provides a globally unique identifier for the P2MP tunnel." > > Well actually my point was: "... the uniqueness of the tuple ID, Tunnel ID, Extended Tunnel ID>. " > > >Since the set of destinations of a P2MP tunnel is just a part of > >the tunnel, identifying the tunnel should be sufficient in order > >to identify the set of destinations. > > right, and all three fields are needed. Could you please provide *technical* reason(s) that would explain why a combination of P2MP ID and Extended Tunnel ID is not sufficient ? Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 05 15:20:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCtD-0008Eb-Bq; Wed, 05 Jul 2006 15:18:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCtB-0008D2-B1 for mpls@ietf.org; Wed, 05 Jul 2006 15:18:21 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyCtA-0000pJ-0P for mpls@ietf.org; Wed, 05 Jul 2006 15:18:21 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k65JIIX56384; Wed, 5 Jul 2006 12:18:18 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k65JID504310; Wed, 5 Jul 2006 12:18:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200607051918.k65JID504310@merlot.juniper.net> To: Lou Berger In-Reply-To: Your message of "Wed, 05 Jul 2006 11:09:44 EDT." <7.0.1.0.2.20060705110255.05d5bd48@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71340.1152127093.1@juniper.net> Date: Wed, 05 Jul 2006 12:18:13 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Lou, > At 10:39 AM 7/5/2006, Yakov Rekhter wrote: > >Could you please provide *technical* reason(s) that would explain why > >a combination of P2MP ID and Extended Tunnel ID is not sufficient ? > > > >Yakov. > > Yakov, > Simply, because that's the way MPLS and GMPLS is specified > today and works in running code. > > If you want to change something from the way it works today, i.e, in > RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to > justify why what's there needs to be changed. The case has been made > for why the session object must use a P2MP ID rather than a > destination IP address. The case has not been made for changing the > definition or semantics of Tunnel ID. > > Can provide the justification of why we need to deviate from current > specs on definition of Tunnel ID? Are you saying that the only reason we have to use Tunnel ID as part of a p2mp tunnel identifier is because Tunnel ID is used as part of a p2p tunnel identifier ? Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 05 17:54:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFI6-0001TA-Px; Wed, 05 Jul 2006 17:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyEhG-0003iE-BJ for mpls@lists.ietf.org; Wed, 05 Jul 2006 17:14:10 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyEhF-0006pG-4k for mpls@lists.ietf.org; Wed, 05 Jul 2006 17:14:10 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k65LDd1u014388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2006 21:13:39 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FyEgl-0003SR-PZ; Wed, 05 Jul 2006 17:13:39 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: George Swallow , Loa Andersson , Stewart Bryant , Danny McPherson From: Greg Jones(ITU-T SG 15) Message-Id: Date: Wed, 05 Jul 2006 17:13:39 -0400 X-Spam-Score: 0.6 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Wed, 05 Jul 2006 17:52:12 -0400 Cc: mpls@lists.ietf.org, Greg Jones , Mark Jones , Bill Fenner , Ghani Abbas , pwe3@ietf.org, Yoichi Maeda , Jari Arkko , ITU-T SG15 , Ross Callon , Mark Townsley , Malcolm Betts Subject: [mpls] New Liaison Statement, "Response to IETF mpls WG liaison statement on T-MPLS" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ITU-T SG15 , Greg Jones List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Title: Response to IETF mpls WG liaison statement on T-MPLS Submission Date: 2006-07-05 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=242 Please reply by 2006-08-16 From: Greg Jones(ITU-T SG 15) To: IETF mpls WG, CC: IETF pwe3 WG(George Swallow , Loa Andersson , Stewart Bryant , Danny McPherson ) Cc: Scott Bradner Ross Callon Bill Fenner mpls@lists.ietf.org Jari Arkko Mark Townsley Yoichi Maeda Steve Trowbridge Reponse Contact: ITU-T SG15 Greg Jones Technical Contact: Malcolm Betts Ghani Abbas Mark Jones Purpose: For comment Body: Attachment(s): Response to IETF mpls WG liaison statement on T-MPLS - body text (https://datatracker.ietf.org/documents/LIAISON/file334.doc) _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 05 20:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIAC-0002Gj-Oh; Wed, 05 Jul 2006 20:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIAB-0002Gb-QD; Wed, 05 Jul 2006 20:56:15 -0400 Received: from coconut.sycamorenet.com ([12.146.0.143] helo=bristol.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyIAA-0003RT-JA; Wed, 05 Jul 2006 20:56:15 -0400 Received: by bristol.sycamorenet.com with Internet Mail Service (5.5.2658.3) id ; Wed, 5 Jul 2006 20:56:14 -0400 Message-ID: <0679BA70A2F59E49B186858B47F4595C4E0014@viper.sycamorenet.com> From: "Pandian, Vijay" To: ospf@ietf.org Date: Wed, 5 Jul 2006 20:56:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ccamp@ops.ietf.org, mpls@ietf.org Subject: [mpls] RFC3630 - Local and Remote Interface IP address X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1588753233==" Errors-To: mpls-bounces@lists.ietf.org 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. --===============1588753233== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A096.F699C238" 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_01C6A096.F699C238 Content-Type: text/plain; charset="iso-8859-1" Section 2.5.3 indicates that there can be more than one Local Interface IP address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates that there can be more than one Remote Interface IP Address assigned to a (numbered) TE-Link. Is there any requirement that the number of Local Interface IP address assigned to a given TE-link match the number of Remote Interface IP address. Specifically, can a TE-Link have just one Local Interface IP address but multiple Remote Interface IP Address or vice-versa? Best regards, Vijay ------_=_NextPart_001_01C6A096.F699C238 Content-Type: text/html; charset="iso-8859-1"
Section 2.5.3 indicates that there can be more than one Local Interface IP address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates that there can be more than one Remote Interface IP Address assigned to a (numbered) TE-Link.
 
Is there any requirement that the number of Local Interface IP address assigned to a given TE-link match the number of Remote Interface IP address.
 
Specifically, can a TE-Link have just one Local Interface IP address but multiple Remote Interface IP Address or vice-versa?
 
Best regards,
 
Vijay
------_=_NextPart_001_01C6A096.F699C238-- --===============1588753233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1588753233==-- From mpls-bounces@lists.ietf.org Thu Jul 06 09:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTV5-0007jq-06; Thu, 06 Jul 2006 09:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTV3-0007jl-9p for mpls@ietf.org; Thu, 06 Jul 2006 09:02:33 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTV2-0002Uw-QN for mpls@ietf.org; Thu, 06 Jul 2006 09:02:33 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k66D22S04089; Thu, 6 Jul 2006 15:02:02 +0200 (CEST) Received: from [161.44.71.220] ([161.44.71.220]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k66D21C28796; Thu, 6 Jul 2006 15:02:01 +0200 (CEST) In-Reply-To: <003b01c68458$55dd6900$74726e0a@china.huawei.com> References: <003b01c68458$55dd6900$74726e0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4a2c37b904fa19df89b0f3d010e0f53e@cisco.com> Content-Transfer-Encoding: quoted-printable From: IJsbrand Wijnands Date: Thu, 6 Jul 2006 15:02:00 +0200 To: liushuying X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: jeanlouis.leroux@francetelecom.com, mpls@ietf.org Subject: [mpls] Re: about upstream LSR change and load-balance in P2MP LSP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Shuying, > Hi all, > =A0=A0=A0At=A0IETF 65 in dallas, we all made presentations. I proposed = a=20 > mechanism to minimize packet loss during upstream LSR change in P2MP.=20= > In case of network failure,=A0I=A0would simplify the process=A0of=20 > reconnecting the P2MP LSP to minimize packet loss. In case of route=20 > changing, the main idea of the mechanism=A0is 'make before break'.=A0In=20= > your presentation, you=A0mentioned that you would do some work=20 > to=A0minimize packet loss during upstream LSR change. > =A0=A0=A0In my opinion, in case of route changing, 'make befor break' = may=20 > be=A0a preferable mechanism, but it=A0should be simple. In case of = network=20 > failure, there may be two ways to minimize packet loss. One way is=20 > to=A0do some work=A0before the=A0network failure, like=A0'frr', so = we=A0could=20 > learn some methods from IPfrr and rfc4090. the other way is to do some=20= > work after failure, like the methods in our drafts, but it should be=20= > simple and minimize the time of taffic disruption. > =A0=A0 I expect some comments=A0on my=20 > draft(draft-liu-mpls-ldp-p2mp-reroute-00.txt) from you. I also expect=20= > to discuss this work with you.=A0 I've went through the draft in some more detail and compiled the=20 following higher level commands. 1. Simplicity and scalability. In the draft you mention that you are solving a scalability problem=20 that exists while converging from an old to a new upstream LSR. And in=20= the email above you mention that this is done in a simple way. I think=20= both of those goals are not met. In your draft you propose to decouple=20= the convergence of an LSP from unicast routing changes. Instead you=20 propose to converge based on link failure and re-optimize the LSP based=20= on new LDP messages, the 'Path Modify message' and 'Path Check=20 messages'. At the end of the day you want to converge the tree to=20 follow the best path, so you are not sending any less label mappings=20 then compared to what is documented in draft-ietf-mpls-ldp-p2mp-01. So=20= I don't see why this is more scalable. 2. Convergence based on link failure. You propose to converge the P2MP LSP based on link failure in stead of=20= routing changes. In the draft you mention that convergence over=20 ethernet interfaces is out of the scope. I don't think you can propose=20= a solution that does not include a solution for ethernet type=20 interfaces. It is obvious that the solution you propose does not work=20 over ethernet interfaces, saying that it is out of scope is a little=20 bit too easy to get away with ;-) I've more concerns on converging based on link failure, see below. ---------- < C >-------- | | < root > ---- < A > ---- < B > ---- Receiver. The initial LSP path is root - A - B - receiver. Now the link fails between the root and A. LSR A will detect the=20 failure and send out a label mapping to B to converge to the newly=20 learned path. LSR B does not converge based on unicast routing changes=20= so the upstream LSR remains A. LSR B now receives a label mapping from=20= its upstream LSR A. What is LSR B supposed to do here? According to=20 your draft is must wait for the Path Check message before it=20 re-evaluates if it is on the shortest path. But until that time the LSP=20= is broken. 3. Forwarding state in the LFIB. This section is one of the most controversial in the draft. In your=20 proposal you end up with 2 upstream LSRs for a single P2MP FEC entry.=20 You don't want to accept labeled packets from both since that would=20 cause duplication. You propose to solve this problem by listening to=20 unknown (multicast?) packets. These packets are punted from the=20 forwarding path to the process level and used to influence the protocol=20= logic. This is a major scalability concern since you don't want to punt=20= every unknown multicast packet to the protocol level. Also, how do you=20= know its a multicast packet? It looks like you propose the LFIB will=20 inspect the L3 header to know if this is a multicast packet or not. I=20 think is bad practice. Thx, Ice. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jul 06 10:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV5i-0002WY-Kw; Thu, 06 Jul 2006 10:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV5h-0002WM-Hh; Thu, 06 Jul 2006 10:44:29 -0400 Received: from coconut.sycamorenet.com ([12.146.0.143] helo=bristol.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyV5g-0007v8-97; Thu, 06 Jul 2006 10:44:29 -0400 Received: by bristol.sycamorenet.com with Internet Mail Service (5.5.2658.3) id ; Thu, 6 Jul 2006 10:44:27 -0400 Message-ID: <0679BA70A2F59E49B186858B47F4595C4E001D@viper.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" Date: Thu, 6 Jul 2006 10:44:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "'ccamp@ops.ietf.org'" , "'ospf@ietf.org'" , "'mpls@ietf.org'" Subject: [mpls] RE: RFC3630 - Local and Remote Interface IP address X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Dimitri, Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link." Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link." Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link." Doesn't this mean the Local and Remote Interface IP Address sub-TLV corresponds to just ONE TE-Link? There is no mention of "components" anywhere in this document. Even in rfc4201, it is not clear that when multiple (component) TE-Links are aggregated as a single numbered bundled link, there can be more than one Interface IP address used for Local and Remote Interface IP Address. Could you please provide a reference where this is clarified as the mean for advertising multiple components at once. Thanks and best regards, Vijay -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, July 06, 2006 1:57 AM To: Pandian, Vijay Subject: Re: RFC3630 - Local and Remote Interface IP address hi vijay - this was meant for advertizing multiple components at once "Pandian, Vijay" Sent by: owner-ccamp@ops.ietf.org 06/07/2006 02:56 To: ospf@ietf.org cc: mpls@ietf.org, ccamp@ops.ietf.org Subject: RFC3630 - Local and Remote Interface IP address Section 2.5.3 indicates that there can be more than one Local Interface IP address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates that there can be more than one Remote Interface IP Address assigned to a (numbered) TE-Link. Is there any requirement that the number of Local Interface IP address assigned to a given TE-link match the number of Remote Interface IP address. Specifically, can a TE-Link have just one Local Interface IP address but multiple Remote Interface IP Address or vice-versa? Best regards, Vijay _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jul 06 10:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyVIC-00005N-8r; Thu, 06 Jul 2006 10:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyVIA-00005E-LL for mpls@ietf.org; Thu, 06 Jul 2006 10:57:22 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyVI8-0008WM-EK for mpls@ietf.org; Thu, 06 Jul 2006 10:57:22 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FyVHq-0006lN-TT; Thu, 06 Jul 2006 10:57:04 -0400 Message-Id: <7.0.1.0.2.20060706105207.06501858@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 06 Jul 2006 10:57:04 -0400 To: Yakov Rekhter From: Lou Berger In-Reply-To: <200607051918.k65JID504310@merlot.juniper.net> References: <200607051918.k65JID504310@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, At 03:18 PM 7/5/2006, Yakov Rekhter wrote: >Lou, > > > At 10:39 AM 7/5/2006, Yakov Rekhter wrote: > > >Could you please provide *technical* reason(s) that would explain why > > >a combination of P2MP ID and Extended Tunnel ID is not sufficient ? > > > > > >Yakov. > > > > Yakov, > > Simply, because that's the way MPLS and GMPLS is specified > > today and works in running code. > > > > If you want to change something from the way it works today, i.e, in > > RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to > > justify why what's there needs to be changed. The case has been made > > for why the session object must use a P2MP ID rather than a > > destination IP address. The case has not been made for changing the > > definition or semantics of Tunnel ID. > > > > Can provide the justification of why we need to deviate from current > > specs on definition of Tunnel ID? > >Are you saying that the only reason we have to use Tunnel ID as >part of a p2mp tunnel identifier is because Tunnel ID is used as >part of a p2p tunnel identifier ? I didn't say that. What I said is the same thing that George said: That the onus is on you to state why we should deviate from current spec and practice. If you care to, can you articulate any reason to justify this change? If not, we should leave the definition unchanged and move on. Lou >Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jul 06 17:13:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb8S-0005Aw-KV; Thu, 06 Jul 2006 17:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb8S-0005AK-00 for mpls@ietf.org; Thu, 06 Jul 2006 17:11:44 -0400 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyb8Q-0002fv-NE for mpls@ietf.org; Thu, 06 Jul 2006 17:11:43 -0400 Received: from ib (unknown [172.16.24.125]) by jera.movaz.com (Postfix) with SMTP id E899ED36; Thu, 6 Jul 2006 17:11:37 -0400 (EDT) Message-ID: <002e01c6a140$bb2fd1d0$7d1810ac@movaz.com> From: "Igor Bryskin" To: "Lou Berger" , "Yakov Rekhter" References: <200607051918.k65JID504310@merlot.juniper.net> Date: Thu, 6 Jul 2006 17:11:21 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, Let's discuss some practical issues. Suppose, I (as a operator or a management application) decided to change a root of an existing P2MP tunnel (perhaps, because it has crashed) while maintaining the same set of receivers. Rather than re-signaling entire tunnel, I'd rather issue a P2MP Path message from a new root that will modify the head of the tunnel- the rest of the tunnel will see this operation as a MBB procedure with no modifications in the data plane. Note that this would be possible with the P2MP tunnel identification suggested by the draft and won't be possible with your scheme. Furthermore, a P2MP tunnel could be built of multiple P2MP LSPs originated not necessarily on the tunnel root. Once we discussed with Kireeti a hierarchical P2MP tunnel. Suppose a tunnel needs to support 10000 leaves. The root of the tunnel can originate a P2MP LSP to 100 (intermediate) leaves, each of which could originate a P2MP LSP of it's own to 100 leaves. It should be a very scalable approach because the root does not need to know about all 10000 leaves (neither a leaf needs to know about the identity of the tunnel root). In order to make this work we need to identify the tunnel independently from the root. So, I vote to keep the tunnel identification as it is described in the draft. Igor ----- Original Message ----- From: "Yakov Rekhter" To: "Lou Berger" Cc: "Rahul Aggarwal" ; ; ; Sent: Wednesday, July 05, 2006 3:18 PM Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] > Lou, > > > At 10:39 AM 7/5/2006, Yakov Rekhter wrote: > > >Could you please provide *technical* reason(s) that would explain why > > >a combination of P2MP ID and Extended Tunnel ID is not sufficient ? > > > > > >Yakov. > > > > Yakov, > > Simply, because that's the way MPLS and GMPLS is specified > > today and works in running code. > > > > If you want to change something from the way it works today, i.e, in > > RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to > > justify why what's there needs to be changed. The case has been made > > for why the session object must use a P2MP ID rather than a > > destination IP address. The case has not been made for changing the > > definition or semantics of Tunnel ID. > > > > Can provide the justification of why we need to deviate from current > > specs on definition of Tunnel ID? > > Are you saying that the only reason we have to use Tunnel ID as > part of a p2mp tunnel identifier is because Tunnel ID is used as > part of a p2p tunnel identifier ? > > Yakov. > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jul 07 16:15:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FywhB-0002YR-NT; Fri, 07 Jul 2006 16:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FywhA-0002Y3-6F; Fri, 07 Jul 2006 16:13:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fywh7-0000b2-Md; Fri, 07 Jul 2006 16:13:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2006 16:12:58 -0400 X-IronPort-AV: i="4.06,218,1149480000"; d="scan'208"; a="92021185:sNHT29005020" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k67KCvfg029527; Fri, 7 Jul 2006 16:12:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k67KCvVM004484; Fri, 7 Jul 2006 16:12:57 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 16:12:57 -0400 Received: from swallow-mini-mac.cisco.com ([10.86.116.2]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 16:12:56 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.cisco.com (Postfix) with ESMTP id C37E62A0428; Fri, 7 Jul 2006 16:12:55 -0400 (EDT) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Fri, 07 Jul 2006 16:12:55 -0400 Message-Id: <20060707201255.C37E62A0428@swallow-mini-mac.cisco.com> X-OriginalArrivalTime: 07 Jul 2006 20:12:57.0018 (UTC) FILETIME=[BCA429A0:01C6A201] DKIM-Signature: a=rsa-sha1; q=dns; l=1448; t=1152303177; x=1153167177; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Draft=20MPLS=20Agenda |To:mpls@ietf.org; X=v=3Dcisco.com=3B=20h=3DGTYw/R/4JBlkW1IcgNnmaNFFTGg=3D; b=S8laG32NntyxAhl2kDR+lMDirTEHWlRpBXZPLQsMnLfU4h9JKuh4gVBCcplyVOBLvA5oamZi UNKUNzBijEWkobe0AfZYUW2Os3J/qJschAN2lPGFPPbxY2IbM9W4SM7v; Authentication-Results: rtp-dkim-1.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: agenda@ietf.org Subject: [mpls] Draft MPLS Agenda X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Montreal MPLS WG July 12, 2006 9:00 ===================================================================== 1. Workgroup Status George & Loa 10 min 2. T-MPLS Liaison Loa 10 min 3. P2MP TE draft-ietf-mpls-rsvp-te-p2mp-05 Rahul 10 min 4. P2MP TE MIB draft-farrel-mpls-p2mp-te-mib-00 Adrian 10 min 5. LDP Capabilities Bob & Rahul 15 min draft-shivani-mpls-ldp-capabilities-00 draft-thomas-mpls-ldp-capabilities-00 6. TE Signaling draft-farrel-mpls-iana-rsvp-session-flags-00 Adrian 2 min 7. Upstream Labels draft-ietf-mpls-upstream-label-00 Eric 10 min 8. P2MP LDP Requirements draft-ietf-mp-ldp-reqs-01 Jean-Louis 5 min 9. mLDP draft-ietf-mpls-ldp-p2mp-01 Bob & Ina 15 min 10. Multicast Upstream Load Balacing draft-liu-mpls-upstream-load-balance-00 Shuying 10 min 11. P2MP discovery draft-zheng-mpls-p2mp-topology-agent-reqs-00 Yang 10 min 12. P2MP OAM draft-swallow-mpls-mcast-cv-00 George 10 min 13. Explicit Congestion Notification draft-davie-ecn-mpls-00 Bruce 10 min _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jul 10 10:40:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwuK-0006xR-QJ; Mon, 10 Jul 2006 10:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwuJ-0006us-Ce for mpls@lists.ietf.org; Mon, 10 Jul 2006 10:38:43 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwuH-0002Gq-Sz for mpls@lists.ietf.org; Mon, 10 Jul 2006 10:38:43 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6AEcJs27477; Mon, 10 Jul 2006 16:38:19 +0200 (CEST) Received: from [10.61.255.124] (ams-stealth-iwijnand-4.cisco.com [10.61.255.124]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6AEcGC28228; Mon, 10 Jul 2006 16:38:16 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <56d60922685c231c6b39769b3656261f@cisco.com> Content-Transfer-Encoding: quoted-printable From: IJsbrand Wijnands Date: Mon, 10 Jul 2006 16:38:18 +0200 To: jin.lizhong@zte.com.cn X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: mpls@lists.ietf.org, Shane.Amante@Level3.com, rhthomas@cisco.com Subject: [mpls] Re: Some questions about draft-ietf-mpls-ldp-p2mp-01, thank you! X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Jin, > > Can you give an example of a multicast routing protocol that =20 > populates =A0 > such a table? > > jin.lizhong:Different multicast routing protocols may generate =20 > different trees > (the tree may be generated by DVMRP or PIM-DM protocol). Z can =20 > determine the > upstream LSR by following the multicast routing protocol messages. = Then > the P2MP or MP2MP LSP is identical to the L3 multicast tree. Which is > the best path for Z is hard to say, the path determined by unicast =20 > routing > protocols or multicast routing protocols. The only multicast routing protocol that creates its own unicast path =20= is DVMRP. It is very unrealistic that customers will use DVMRP to =20 create a unicast table that LDP will use to build the P2MP or MP2MP =20 LSP. > > > > > > The two ways are not compatiable, and the two P2MP LSPs or MP2MP =20= > LSPs =A0 > > are defferent. Maybe this draft should describe the two ways, and =A0= > > specify one way or both the two ways. The best path selection =20 > problem =A0 > > should be solved. > > Are you suggesting we should set priority to one table over the = other? > > It looks to me that the table selection is a local policy and does =20= > not =A0 > necessarily need to be the same on each LSR. You may want to use a =A0 > MuRIB between 2 LSRs just to make Multicast divert from Unicast for a = =20 > =A0 > specific link. How these two tables are used is up to the operator to = =20 > =A0 > define. It does not seems to be something the draft must spell out. =20= > So =A0 > I think this is out side the scope of the document. > > jin.lizhong:Firstly, we should describe the "best path" in more = detail. The best path is what unicast gives us if you do a lookup for the root =20= address. > The two selection methods are not compatiable and P2MP or MP2MP LSP =20= > will > not be setup sucessfully if different methods are used in Root Node, =20= > Transit > Node, and Leaf Node. What's more, if Root Node does not support =20 > multicast > routing protocols and Leaf Node only support multicast routing lookup > method. Then the Leaf Node will not find the Root Node, for the Root =20= > Node > is out of the sight of Multicast domains. I don't see what the problem is you are trying to solve. Why would you =20= want to run a multicast routing protocol in the MPLS network to provide =20= path to the root? Do you really consider DVMRP here? That is going =20 backwards in time, just like proposing to use RIP. Normal best path procedures apply to unicast routing tables, like admin =20= distance and metric. If you have different unicast tables it is up to =20= the administrator to set which table has preference. Thx, Ice. > Secondly, we should specify the concept of "best path". Then we can =20= > set a > priority to one table over the other, or we can only select one =20 > selection > method. > > Thx, > > Ice. > > > > > > > > > > > > > > > -------------------------------------------------------- > > =20 > = ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0i= n=A0this=A0mail > > =20 > = =A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organization.=A0This=A0m= ail=A0communicati > > =20 > = on=A0is=A0confidential.=A0Recipients=A0named=A0above=A0are=A0obligated=A0t= o=A0maintain=A0se > > =20 > = crecy=A0and=A0are=A0not=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0= this=A0communicat > > ion=A0to=A0others. > > =20 > = This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confide= ntial=A0and=A0inten > > =20 > = ded=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0or=A0entity=A0to=A0= whom=A0they=A0are=A0add > > =20 > = ressed.=A0If=A0you=A0have=A0received=A0this=A0email=A0in=A0error=A0please=A0= notify=A0the=A0orig > > =20 > = inator=A0of=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0messa= ge=A0are=A0those=A0of > > =A0the=A0individual=A0sender. > > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0= by=A0ZTE=A0Anti- > > Spam=A0system. > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this =20= > mail is solely property of the sender's organization. This mail =20 > communication is confidential. Recipients named above are obligated to = =20 > maintain secrecy and are not permitted to disclose the contents of =20 > this communication to others. > This email and any files transmitted with it are confidential and =20 > intended solely for the use of the individual or entity to whom they =20= > are addressed. If you have received this email in error please notify =20= > the originator of the message. Any views expressed in this message are = =20 > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam =20= > system. > > > > -------------------------------------------------------- > = ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0i= n=A0this=A0mail=20 > = =A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organization.=A0This=A0m= ail=A0communicati=20 > = on=A0is=A0confidential.=A0Recipients=A0named=A0above=A0are=A0obligated=A0t= o=A0maintain=A0se=20 > = crecy=A0and=A0are=A0not=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0= this=A0communicat=20 > ion=A0to=A0others. > = This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confide= ntial=A0and=A0inten=20 > = ded=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0or=A0entity=A0to=A0= whom=A0they=A0are=A0add=20 > = ressed.=A0If=A0you=A0have=A0received=A0this=A0email=A0in=A0error=A0please=A0= notify=A0the=A0orig=20 > = inator=A0of=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0messa= ge=A0are=A0those=A0of=20 > =A0the=A0individual=A0sender. > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0= ZTE=A0Anti-=20 > Spam=A0system. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jul 11 08:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0H5S-0003ha-Ul; Tue, 11 Jul 2006 08:11:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0GtG-00020z-DK for mpls@lists.ietf.org; Tue, 11 Jul 2006 07:58:58 -0400 Received: from mail.zte.com.cn ([202.103.147.144] helo=Riskfilter2.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0GtA-0007KL-Fx for mpls@lists.ietf.org; Tue, 11 Jul 2006 07:58:58 -0400 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 4627.356981843; Tue, 11 Jul 2006 20:16:48 +0800 (CST) To: mpls@lists.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: jin.lizhong@zte.com.cn Date: Tue, 11 Jul 2006 19:58:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-07-11 19:58:22, Serialize complete at 2006-07-11 19:58:22 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 X-Mailman-Approved-At: Tue, 11 Jul 2006 08:11:33 -0400 Subject: [mpls] Re: Re: Some questions about draft-ietf-mpls-ldp-p2mp-01, thank you! X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0020725017==" Errors-To: mpls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0020725017== Content-Type: multipart/alternative; boundary="=_alternative 0041E37B482571A8_=" This is a multipart message in MIME format. --=_alternative 0041E37B482571A8_= Content-Type: text/plain; charset="US-ASCII" Hi, Ice pls. see the following lines began with jin.lizhong ========================================================== From:IJsbrand Wijnands To:jin.lizhong@zte.com.cn Hi, > > 2.3.1.1. Determining one's 'upstream LSR' > > A node Z that is part of P2MP LSP determines the LDP peer U > which lies on the best path from Z to the root node X. If there are > more than one such LDP peers, only one of them is picked. U is Z's > "Upstream LSR" for . > > Which is the "best path" for Z. Two ways can determine the best path. > 1. Z can look up the normal "route table", and get the best path > according the route.(The route table may be generated by OSPF, ISIS, > RIP, or even OSPF-TE) > > 2. Z can get the best path according the multicast table (this table > may be generated by various multicast routing protocols), and the P2MP > LSP or MP2MP LSP will only work on the routers that support > corresponding multicast routing protocols. Can you give an example of a multicast routing protocol that populates such a table? jin.lizhong:Different multicast routing protocols may generate different trees (the tree may be generated by DVMRP or PIM-DM protocol). Z can determine the upstream LSR by following the multicast routing protocol messages. Then the P2MP or MP2MP LSP is identical to the L3 multicast tree. Which is the best path for Z is hard to say, the path determined by unicast routing protocols or multicast routing protocols. > > The two ways are not compatiable, and the two P2MP LSPs or MP2MP LSPs > are defferent. Maybe this draft should describe the two ways, and > specify one way or both the two ways. The best path selection problem > should be solved. Are you suggesting we should set priority to one table over the other? It looks to me that the table selection is a local policy and does not necessarily need to be the same on each LSR. You may want to use a MuRIB between 2 LSRs just to make Multicast divert from Unicast for a specific link. How these two tables are used is up to the operator to define. It does not seems to be something the draft must spell out. So I think this is out side the scope of the document. jin.lizhong:Firstly, we should describe the "best path" in more detail. The two selection methods are not compatiable and P2MP or MP2MP LSP will not be setup sucessfully if different methods are used in Root Node, Transit Node, and Leaf Node. What's more, if Root Node does not support multicast routing protocols and Leaf Node only support multicast routing lookup method. Then the Leaf Node will not find the Root Node, for the Root Node is out of the sight of Multicast domains. Secondly, we should specify the concept of "best path". Then we can set a priority to one table over the other, or we can only select one selection method.THX Thx, Ice. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0041E37B482571A8_= Content-Type: text/html; charset="US-ASCII"
Hi, Ice
  pls. see the following lines began with jin.lizhong

==========================================================
From:IJsbrand Wijnands <ice@cisco.com>
To:jin.lizhong@zte.com.cn

Hi,


>
> 2.3.1.1.  Determining one's 'upstream LSR'
>
>    A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U
>    which lies on the best path from Z to the root node X. If there are
>    more than one such LDP peers, only one of them is picked.  U is Z's
>    "Upstream LSR" for <X, Y>.
>
> Which is the "best path" for Z. Two ways can determine the best path.
> 1. Z can look up the normal "route table", and get the best path  
> according the route.(The route table may be generated by OSPF, ISIS,  
> RIP, or even OSPF-TE)
>
> 2. Z can get the best path according the multicast table (this table  
> may be generated by various multicast routing protocols), and the P2MP  
> LSP or MP2MP LSP will only work on the routers that support  
> corresponding multicast routing protocols.

Can you give an example of a multicast routing protocol that populates  
such a table?
jin.lizhong:Different multicast routing protocols may generate different trees
(the tree may be generated by DVMRP or PIM-DM protocol). Z can determine the
upstream LSR by following the multicast routing protocol messages. Then
the P2MP or MP2MP LSP is identical to the L3 multicast tree. Which is
the best path for Z is hard to say, the path determined by unicast routing
protocols or multicast routing protocols.


>
> The two ways are not compatiable, and the two P2MP LSPs or MP2MP LSPs  
> are defferent. Maybe this draft should describe the two ways, and  
> specify one way or both the two ways. The best path selection problem  
> should be solved.

Are you suggesting we should set priority to one table over the other?

It looks to me that the table selection is a local policy and does not  
necessarily need to be the same on each LSR. You may want to use a  
MuRIB between 2 LSRs just to make Multicast divert from Unicast for a  
specific link. How these two tables are used is up to the operator to  
define. It does not seems to be something the draft must spell out. So  
I think this is out side the scope of the document.
jin.lizhong:Firstly, we should describe the "best path" in more detail.
The two selection methods are not compatiable and P2MP or MP2MP LSP will
not be setup sucessfully if different methods are used in Root Node, Transit
Node, and Leaf Node. What's more, if Root Node does not support multicast
routing protocols and Leaf Node only support multicast routing lookup
method. Then the Leaf Node will not find the Root Node, for the Root Node
is out of the sight of Multicast domains.
Secondly, we should specify the concept of "best path". Then we can set a
priority to one table over the other, or we can only select one selection
method.THX

Thx,

Ice. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0041E37B482571A8_=-- --===============0020725017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0020725017==-- From mpls-bounces@lists.ietf.org Tue Jul 11 10:02:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Imb-0005Eg-LQ; Tue, 11 Jul 2006 10:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ima-0005Eb-9R for mpls@lists.ietf.org; Tue, 11 Jul 2006 10:00:12 -0400 Received: from smtp2.orange.fr ([193.252.22.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ImZ-0001Ck-0g for mpls@lists.ietf.org; Tue, 11 Jul 2006 10:00:12 -0400 Received: from home.treizh.net (ARennes-356-1-130-70.w86-220.abo.wanadoo.fr [86.220.209.70]) by mwinf0206.orange.fr (SMTP Server) with ESMTP id 7C59A1C001A8; Tue, 11 Jul 2006 16:00:10 +0200 (CEST) X-ME-UUID: 20060711140010509.7C59A1C001A8@mwinf0206.orange.fr Received: from wintermute (localhost [127.0.0.1]) by home.treizh.net (Postfix) with ESMTP id A6C101ECD85; Tue, 11 Jul 2006 16:00:09 +0200 (CEST) Subject: Re: [mpls] Re: Some questions about draft-ietf-mpls-ldp-p2mp-01,thank you! From: Thomas Morin To: IJsbrand Wijnands In-Reply-To: <97ec7ae1c452573b3ffb0182231f04b8@cisco.com> References: <97ec7ae1c452573b3ffb0182231f04b8@cisco.com> Content-Type: text/plain Organization: France Telecom R&D Date: Tue, 11 Jul 2006 10:00:08 -0400 Message-Id: <1152626408.12381.30.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mpls@lists.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Ice, IJsbrand Wijnands : > > It looks to me that the table selection is a local policy and does not > necessarily need to be the same on each LSR. You may want to use a > MuRIB between 2 LSRs just to make Multicast divert from Unicast for a > specific link. How these two tables are used is up to the operator to > define. It does not seems to be something the draft must spell out. I don't think that the above is exact: to ensure no routing loop is created, consistency between SPF calculated by different routers is needed. If, for instance, a multi-topology IGP is used, then we may want to say that all routers should use the same topology to lookup upstream interface to LSP root. We could say for instance that multicast topology MUST be used if multi-topology ISIS is used (or an alternate new multi-topology topology ID, if we don't like reusing the one dedicated to IP multicast). Cheers, -Thomas _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jul 11 10:58:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Jf8-000101-T6; Tue, 11 Jul 2006 10:56:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Jf7-0000zq-K0 for mpls@lists.ietf.org; Tue, 11 Jul 2006 10:56:33 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Jf6-0006Kz-63 for mpls@lists.ietf.org; Tue, 11 Jul 2006 10:56:33 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6BEuUU28391; Tue, 11 Jul 2006 16:56:30 +0200 (CEST) Received: from [10.61.255.124] (ams-stealth-iwijnand-4.cisco.com [10.61.255.124]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k6BEuTC19391; Tue, 11 Jul 2006 16:56:30 +0200 (CEST) In-Reply-To: <1152626408.12381.30.camel@wintermute> References: <97ec7ae1c452573b3ffb0182231f04b8@cisco.com> <1152626408.12381.30.camel@wintermute> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: IJsbrand Wijnands Subject: Re: [mpls] Re: Some questions about draft-ietf-mpls-ldp-p2mp-01, thank you! Date: Tue, 11 Jul 2006 16:56:29 +0200 To: Thomas Morin X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mpls@lists.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Thomas, >> It looks to me that the table selection is a local policy and does not >> necessarily need to be the same on each LSR. You may want to use a >> MuRIB between 2 LSRs just to make Multicast divert from Unicast for a >> specific link. How these two tables are used is up to the operator to >> define. It does not seems to be something the draft must spell out. > > I don't think that the above is exact: to ensure no routing loop is > created, consistency between SPF calculated by different routers is > needed. > > If, for instance, a multi-topology IGP is used, then we may want to say > that all routers should use the same topology to lookup upstream > interface to LSP root. I agree that with a multi-topology IGP it is the most obvious way to build your tree. But it is still possible to only run a multi-topology in a sub section of the network where you have specific needs to do so. I don't think it is up the mLDP draft to limit the scope. > > We could say for instance that multicast topology MUST be used if > multi-topology ISIS is used (or an alternate new multi-topology > topology > ID, if we don't like reusing the one dedicated to IP multicast). > I see multi-topology IGP as different unicast tables. These tables represent different topologies where you may want to pick one for mLDP build trees. If we don't want to call one the multicast IGP, how do you want to define this in the draft? Thx, Ice. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jul 11 11:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JpX-0003Xp-N0; Tue, 11 Jul 2006 11:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JpV-0003Xj-RU for mpls@lists.ietf.org; Tue, 11 Jul 2006 11:07:17 -0400 Received: from smtp6.orange.fr ([193.252.22.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0JpU-0006k8-Ee for mpls@lists.ietf.org; Tue, 11 Jul 2006 11:07:17 -0400 Received: from home.treizh.net (ARennes-356-1-130-70.w86-220.abo.wanadoo.fr [86.220.209.70]) by mwinf0604.orange.fr (SMTP Server) with ESMTP id 91B8C1C001DD; Tue, 11 Jul 2006 17:07:15 +0200 (CEST) X-ME-UUID: 20060711150715596.91B8C1C001DD@mwinf0604.orange.fr Received: from wintermute (localhost [127.0.0.1]) by home.treizh.net (Postfix) with ESMTP id 565181ECD85; Tue, 11 Jul 2006 17:07:14 +0200 (CEST) Subject: Re: [mpls] Re: Some questions about draft-ietf-mpls-ldp-p2mp-01,thank you! From: Thomas Morin To: IJsbrand Wijnands In-Reply-To: References: <97ec7ae1c452573b3ffb0182231f04b8@cisco.com> <1152626408.12381.30.camel@wintermute> Content-Type: text/plain Organization: France Telecom R&D Date: Tue, 11 Jul 2006 11:07:13 -0400 Message-Id: <1152630433.12381.46.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mpls@lists.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org IJsbrand Wijnands : > > >> It looks to me that the table selection is a local policy and does not > >> necessarily need to be the same on each LSR. You may want to use a > >> MuRIB between 2 LSRs just to make Multicast divert from Unicast for a > >> specific link. How these two tables are used is up to the operator to > >> define. It does not seems to be something the draft must spell out. > > > > I don't think that the above is exact: to ensure no routing loop is > > created, consistency between SPF calculated by different routers is > > needed. > > > > If, for instance, a multi-topology IGP is used, then we may want to say > > that all routers should use the same topology to lookup upstream > > interface to LSP root. > > I agree that with a multi-topology IGP it is the most obvious way to > build your tree. But it is still possible to only run a multi-topology > in a sub section of the network where you have specific needs to do so. True, there are topologies that will be loop free guaranteed even if MT is not run everywhere. > I don't think it is up the mLDP draft to limit the scope. I agree. > > We could say for instance that multicast topology MUST be used if > > multi-topology ISIS is used (or an alternate new multi-topology > > topology > > ID, if we don't like reusing the one dedicated to IP multicast). > > I see multi-topology IGP as different unicast tables. These tables > represent different topologies where you may want to pick one for mLDP > build trees. If we don't want to call one the multicast IGP, how do you > want to define this in the draft? The draft might include some "warning" statement against misconfiguration, but probably the one included in draft-ietf-isis-wg-multi-topology, Section 6, is enough ("The nexthops derived from the MT SPF MUST belong to the adjacencies conforming to the same MT for correct forwarding. It is recommended for the administrators to ensure consistent configuration of all routers in the domain to prevent undesirable forwarding behavior.") Cheers, -Thomas _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jul 11 16:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OkC-0005vV-7u; Tue, 11 Jul 2006 16:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OkA-0005vP-B4 for mpls@ietf.org; Tue, 11 Jul 2006 16:22:06 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Ok9-0007x1-1R for mpls@ietf.org; Tue, 11 Jul 2006 16:22:06 -0400 Received: from [132.219.30.209] (helo=[132.219.30.209]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1G0Ok6-0002FB-9H; Tue, 11 Jul 2006 22:22:03 +0200 Message-ID: <44B40866.4010403@pi.se> Date: Tue, 11 Jul 2006 22:21:58 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Loa Andersson Subject: Re: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc References: <448D8644.2040307@pi.se> In-Reply-To: <448D8644.2040307@pi.se> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, the draft-farrel-mpls-iana-rsvp-session-flags-00.txt has been accepted as a working group document. Could the authors republish the document as draft-ietf-mpls-iana-rsvp-session-flags-00.txt /Loa and George Loa Andersson wrote: > Working group, > > the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt > has requested that it is made a MPLS WG document. > > Please send comments on this to the mailing list or the working > group co-chairs before Jun 26. > > Loa and George > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From aspitur@0net.com Tue Jul 11 22:07:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0U8a-0002Nj-97; Tue, 11 Jul 2006 22:07:40 -0400 Received: from [200.121.202.133] (helo=client-200.121.202.133.speedy.net.pe) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0U8Y-0006hX-V7; Tue, 11 Jul 2006 22:07:40 -0400 Date: Wed, 12 Jul 2006 02:07:39 +0300 From: "Perry Kemp" X-Mailer: The Bat! (v2.01) Business Reply-To: "Perry Kemp" X-Priority: 3 (Normal) Message-ID: <6019094377.20060712020739@0net.com> To: mpls-archive@lists.ietf.org Subject: 7QM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 us. His eyes were full of despair. It was time to go. this morning; they saw the Breakthrough! But I want no honors. I have no because I was starving and my throat was parched. with the easy telepathy that these gulls used instead of screes and From mpls-bounces@lists.ietf.org Wed Jul 12 10:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fZE-0005iT-Ep; Wed, 12 Jul 2006 10:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fZD-0005iO-Ng for mpls@ietf.org; Wed, 12 Jul 2006 10:19:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fZC-0007WH-3z for mpls@ietf.org; Wed, 12 Jul 2006 10:19:55 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0fZA-0009xw-Tl for mpls@ietf.org; Wed, 12 Jul 2006 14:19:53 +0000 Message-ID: <44B50510.5060101@psg.com> Date: Wed, 12 Jul 2006 16:20:00 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: multipart/mixed; boundary="------------060601010200040608080300" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ea98b4531a0f62d9b5bec3f8f731859 Cc: Subject: [mpls] mp reqs X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------060601010200040608080300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit in this doc there is clear problem statement for p2mp case but is no real problem statement for mp2mp beside soem words in the introductory paragraph of section 6 thanks, - dimitri. --------------060601010200040608080300 Content-Type: text/plain; charset=UTF-8; name="www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt" Network Working Group J.-L. Le Roux (Editor) Internet Draft France Telecom Category: Informational Expires: January 2007 T. Morin France Telecom Vincent Parfait Equant Luyuan Fang AT&T Lei Wang Telenor Yuji Kamite NTT Communications Shane Amante Level 3 Communications July 2006 Requirements for point-to-multipoint extensions to the Label Distribution Protocol draft-ietf-mpls-mp-ldp-reqs-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Le Roux et al. Reqs for P2MP extensions to LDP [Page 1] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 Abstract This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Terminology.................................................3 2. Introduction................................................4 3. Problem Statement and Requirements Overview.................5 3.1. Problem Statement...........................................5 3.2. Requirements overview.......................................5 4. Application scenario........................................6 5. Detailed Requirements.......................................7 5.1. P2MP LSPs...................................................7 5.2. P2MP LSP FEC................................................7 5.3. P2MP LDP routing............................................8 5.4. Setting up, tearing down and modifying P2MP LSPs............8 5.5. Label Advertisement.........................................8 5.6. Data Duplication............................................8 5.7. Avoiding loops..............................................9 5.8. P2MP LSP Re-routing.........................................9 5.8.1. Rerouting upon Network Failure..............................9 5.8.2. Rerouting on a Better Path..................................9 5.8.3. Rerouting upon Planned Maintenance.........................10 5.9. Support for LAN interfaces.................................10 5.10. Support for encapsulation in P2P and P2MP TE tunnels.......10 5.11. Label spaces...............................................10 5.12. IPv4/IPv6 support..........................................11 5.13. Multi-Area LSPs............................................11 5.14. OAM........................................................11 5.15. Graceful Restart and Fault Recovery........................11 5.16. Robustness.................................................11 5.17. Scalability................................................11 5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs in operational networks.............................12 5.18. Backward Compatibility.....................................12 6. Shared Trees...............................................12 6.1. Requirements for MP2MP LSPs................................13 7. Evaluation criteria........................................14 Le Roux et al. Reqs for P2MP extensions to LDP [Page 2] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 7.1. Performances...............................................14 7.2. Complexity and Risks.......................................14 8. Security Considerations....................................14 9. Acknowledgments............................................14 10. References.................................................14 10.1. Normative references.......................................14 10.2. Informative references.....................................15 11. Editor Address.............................................15 12. Contributors Addresses.....................................16 13. Intellectual Property Statement............................17 1. Terminology LSR: Label Switching Router LSP: MPLS Label Switched Path Ingress LSR: Router acting as a sender of an LSP Egress LSR: Router acting as a receiver of an LSP P2P LSP: A LSP that has one unique Ingress LSR and one unique Egress LSR MP2P LSP: A LSP that has one or more Ingress LSRs and one unique Egress LSR P2MP LSP: A LSP that has one unique Ingress LSR and one or more Egress LSRs MP2MP LSP: A LSP that as one or more Leaf LSRs acting indifferently as Ingress or Egress LSR Leaf LSR: Egress LSR of a P2MP LSP or Ingress/Egress LSR of a MP2MP LSP Transit LSR: A LSR of a P2MP LSP that has one or more downstream LSRs Branch LSR: A LSR of a P2MP LSP that has more than one downstream LSR Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or more directly connected downstream LSRs Le Roux et al. Reqs for P2MP extensions to LDP [Page 3] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 2. Introduction Many operators have deployed LDP [LDP] for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to -point services in MPLS backbones. There are emerging requirements for supporting delivery of point-to- multipoint applications in MPLS backbones, such as those defined in [L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]. This requires mechanisms for setting up point-to-multipoint LSPs (P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, and with MPLS traffic replication at some Branch LSRs. RSVP-TE extensions for setting up Point-To-Multipoint Traffic Engineered LSPs (P2MP TE LSPs), have been defined in [P2MP-TE-RSVP]. They meet requirements expressed in [P2MP-TE-REQ]. This approach is useful, in network environments where P2MP Traffic Engineering capabilities are needed (Optimization, QoS, Fast recovery). However for operators who want to support point-to-multipoint traffic delivery on an MPLS backbone, without Traffic Engineering needs, and have already deployed LDP for P2P traffic, an interesting and useful approach would be to rely on LDP extensions in order to setup point- to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS applications and would ease the delivery of point-to-multipoint services in an MPLS backbone. This document focuses on the LDP approach for setting up P2MP LSPs. It lists a detailed set of requirements for P2MP extensions to LDP, so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. These requirements should be used as guidelines when specifying LDP extensions. It is intended that solutions that specify LDP procedures for P2MP LSP setup, satisfy these requirements. Note that generic requirements for P2MP extensions to MPLS are out of the scope of this document. Rather this document describes solution specific requirements related to LDP extensions in order to set up P2MP LSPs. Note also that other mechanisms could be used for setting up P2MP LSPs, such as for instance PIM extensions, but these are out of the scope of this document. The objective is not to compare these mechanisms but rather to focus on the requirements for an LDP extension approach. The document is structured as follows: - Section 3 points out the problem statement; - Section 4 illustrates an application scenario; - Section 5 addresses detailed requirements for P2MP LSPs; - Section 6 finally discusses group communication, and requirements for MP2MP LSPs. Le Roux et al. Reqs for P2MP extensions to LDP [Page 4] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 3. Problem Statement and Requirements Overview 3.1. Problem Statement Many operators have deployed LDP [LDP] for setting up P2P and MP2P MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic essentially in Layer 3 and Layer 2 VPN networks. There are emerging requirements for supporting multicast traffic delivery within these VPN infrastructures ([L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]). For various reasons, including consistency with P2P applications, and taking full advantages of MPLS network infrastructure, it would be highly desirable to use MPLS LSPs for the delivery of multicast traffic. This could be implemented by setting up a group of P2P or MP2P LSPs, but such an approach may be sub-optimal since it would result in data replication at the ingress LSR, and bandwidth inefficiency (duplicate data traffic within the network). Hence new mechanisms are required that would allow traffic from an Ingress LSR to be efficiently delivered to a number of Egress LSRs in an MPLS backbone, avoiding duplicate copies of a packet on a given link. Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP LSP is an LSP starting at an Ingress LSR, and ending on a set of one or more Egress LSRs. Traffic sent by the Ingress LSR is replicated on one or more Branch LSRs down to Egress LSRs. RSVP-TE extensions for setting up P2MP TE LSPs, which meet requirements expressed in [P2MP-TE-REQ], have been defined in [P2MP- TE-RSVP]. This approach is useful, in network environments where Traffic Engineering capabilities are required. However, for operators that deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and without the need for traffic engineering, an interesting approach would be using LDP extensions for setting up P2MP LSPs. The following gives a set of guidelines that a specification of LDP extensions for setting up P2MP LSPs should follow. 3.2. Requirements overview The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs with one Ingress LSR and one or more Egress LSRs, with traffic replication at some Branch LSRs. The P2MP LDP mechanism MUST allow the addition or removal of leaves associated with a P2MP LSP. The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and inherit its capability sets from [LDP]. It is of paramount importance that the P2MP LDP mechanism MUST NOT impede the operation of existing P2P/MP2P LSPs. Le Roux et al. Reqs for P2MP extensions to LDP [Page 5] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 The P2MP LDP mechanism MAY also allow setting up multipoint-to- multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting indifferently as Ingress LSR or Egress LSR. This may allow a reduction in the amount of LDP state that needs to be maintained by a LSR. 4. Application scenario Figure 1 below illustrates an LDP enabled MPLS provider network, used to carry both unicast and multicast traffic of VPN customers following for instance the architecture defined in [2547-MCAST] for BGP/MPLS VPNs, or the one defined in [VPLS-MCAST]. A set of MP2P LDP LSPs are setup between PE routers to carry unicast VPN traffic within the MPLS backbone. A set of P2MP LDP LSPs are setup between PE routers acting as Ingress LSRs and PE routers acting as Egress LSRs, so as to support multicast VPN traffic delivery within the MPLS backbone. For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and Egress LSRs PE2, PE3, and PE4. It is used to transport multicast traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 and PE4 respectively. PE1 *| *** P2MP LDP LSP *| **** P1-----PE2 */ \* */ \* *****/ \* **** PE3----P2 P3----PE4 | | | | | | PE5 PE6 Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4. If later there are new receivers attached to PE5 and PE6, then PE5 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and replicate traffic received from P1, to PE3 and PE5, and to PE4 and PE6 respectively (see figure 2 below). Le Roux et al. Reqs for P2MP extensions to LDP [Page 6] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 PE1 *| *** P2MP LDP LSP *| **** P1-----PE2 */ \* */ \* *****/ \* *** PE3----P2 P3----PE4 *| |* *| |* *| |* PE5 PE6 Figure 2: Attachment of PE5 and PE6. 5. Detailed Requirements 5.1. P2MP LSPs The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane aspects related to P2MP LSPs are those already defined in [P2MP-TE-REQ]. That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. Traffic sent by the Ingress LSR is received by all Egress LSRs. The specific aspects related to P2MP LSPs is the action required at a Branch LSR, where data replication occurs. Incoming labelled data is appropriately replicated to several outgoing interfaces which may use different labels. Only one copy of a packet MUST be sent on a given link of a P2MP LSP. A P2MP LSP MUST be identified by a constant and unique identifier within the whole LDP domain, whatever the number of leaves, which may vary dynamically. This identifier will be used so as to add/remove leaves to/from the P2MP tree. 5.2. P2MP LSP FEC As with P2P MPLS technology [LDP], traffic MUST be classified into a FEC in this P2MP extension. All packets which belong to a particular P2MP FEC and which travel from a particular node MUST use the same P2MP LSP. As such, a solution MUST specify a FEC that is suitable for P2MP forwarding. Such P2MP FEC MUST be distinguished clearly from the existing P2P FEC. Le Roux et al. Reqs for P2MP extensions to LDP [Page 7] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 5.3. P2MP LDP routing As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the information maintained in LSR Routing Information Bases (RIB). It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path to the Ingress LSR so as to setup an MPLS shortest path tree. 5.4. Setting up, tearing down and modifying P2MP LSPs The P2MP LDP mechanism MUST support the establishment, maintenance and teardown of P2MP LSPs in a scalable manner. This MUST include both the existence of a large amount of P2MP LSPs within a single network and a large amount of leaf LSRs for a single P2MP LSP. In order to scale well with a large number of leaves it is RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For that purpose, leaves will have to be aware of the P2MP LSP identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely on the applications that will use P2MP LSPs, and are out of the scope of this document. The P2MP LDP mechanism MUST allow the dynamic addition and removal of leaves to and from a P2MP LSP, without any restriction (provided there is network connectivity). It is RECOMMENDED that these operations be leaf-initiated. These operations MUST not impact the data transfer (packet loss, duplication, delay) towards other leaves. It is RECOMMENDED that these operations do not cause any additional processing except on the path from the added/removed Leaf LSR to the Branch LSR. 5.5. Label Advertisement The P2MP LDP mechanism SHOULD support downstream unsolicited label advertisement mode. This is well suited to a leaf-initiated approach and is consistent with P2P/MP2P LDP operations. 5.6. Data Duplication Data duplication refers to the receipt of multiple copies of a packet by any leaf. Although this may be a marginal situation, it may also be detrimental for certain applications. Hence, data duplication SHOULD be avoided as much as possible, and limited to (hopefully rare) transitory conditions. Note, in particular, that data duplication might occur if P2MP LSP rerouting is being performed (See also section 5.8). Le Roux et al. Reqs for P2MP extensions to LDP [Page 8] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 5.7. Avoiding loops The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops even during transient events. Furthermore, the P2MP LDP mechanism MUST avoid routing loops that may trigger unexpected non-localized exponential growth of traffic. Note that any loop-avoidance mechanism MUST respect scalability requirements. 5.8. P2MP LSP Re-routing The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in the following cases: - Network failure (link or node); - A better path exists (e.g. new link, metric change); - Planned maintenance. Given that P2MP LDP routing should rely on the RIB, the achievement of the following requirements also implies the underlying routing protocols (IGP, etc.). 5.8.1. Rerouting upon Network Failure The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case of link or node failure(s). The rerouting time SHOULD be minimized as much as possible so as to reduce traffic disruption. A mechanism MUST be defined to prevent constant P2MP LSP teardown and rebuild which may be caused by the instability of a specific link/node in the network. 5.8.2. Rerouting on a Better Path The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case a better path is created in the network, for instance as a result of a metric change, a link repair, or the addition of links or nodes. Traffic disruption and data duplication SHOULD be minimized as much as possible during such rerouting. There is actually a tension between packet loss minimization and packet duplication minimization objectives. It SHOULD be feasible to avoid either data duplication or packet loss during such rerouting. A solution MAY provide the operator with means to choose between favoring avoiding packet loss at the expense of potential packet duplication, and favoring avoiding duplication against packet loss. Le Roux et al. Reqs for P2MP extensions to LDP [Page 9] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 5.8.3. Rerouting upon Planned Maintenance The P2MP LDP mechanism MUST support planned maintenance operations. It MUST be possible to reroute a P2MP LSP before a link/node is deactivated for maintenance purposes. Traffic disruption and data duplication SHOULD be minimized as much as possible during such planned maintenance. There is actually a tension between packet loss minimization and packet duplication minimization objectives. It SHOULD be feasible to avoid either data duplication or packet loss during such rerouting. A solution MAY provide the operator with means to choose between favoring avoiding packet loss at the expense of packet duplication, and favoring avoiding duplication against packet loss. 5.9. Support for LAN interfaces The P2MP LDP mechanism MUST provide a way for a Branch LSR to send a single copy of the data onto an Ethernet LAN interface and reach multiple adjacent downstream nodes. This requires that the same label be negotiated with all downstream LSRs for the LSP. When there are several candidate upstream LSRs on a LAN interface, the P2MP LDP mechanism MUST provide a way for all downstream LSRs of a given P2MP LSP to select the same upstream LSR, so as to avoid traffic replication. In addition, the P2MP LDP mechanism SHOULD allow for an efficient balancing of a set of P2MP LSPs among a set of candidate upstream LSRs on a LAN interface. 5.10. Support for encapsulation in P2P and P2MP TE tunnels The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and P2MP TE tunnels. The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a single copy of the data onto the tunnel and reach all downstream LSRs on the P2MP LSP, which are also Egress LSRs of the tunnel. As with LAN interfaces, this requires that the same LDP label be negotiated with all downstream LSRs for the P2MP LDP LSP. 5.11. Label spaces Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or dedicated label spaces. Note that dedicated label spaces will require the establishment of separate P2P and P2MP LDP sessions. Le Roux et al. Reqs for P2MP extensions to LDP [Page 10] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 5.12. IPv4/IPv6 support The P2MP LDP mechanism MUST be equally applicable to IPv4 and IPv6 traffic. Likewise, it SHOULD be possible to convey both kinds of traffic in a given P2MP LSP facility. Also the P2MP LDP mechanism MUST support the establishment of LDP sessions over both IPv4 and IPv6 control planes. 5.13. Multi-Area LSPs The P2MP LDP mechanism MUST support the establishment of multi-area P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP area as the Ingress LSR. This SHOULD be possible without requiring the advertisement of Ingress LSRs' addresses across IGP areas. 5.14. OAM LDP management tools ([LDP-MIB], etc.) MUST be enhanced to support P2MP LDP extensions. This may yield a new MIB module, which may possibly be inherited from the LDP MIB. In order to facilitate correct management, P2MP LDP LSPs MUST have unique identifiers, otherwise it is impossible to determine which LSP is being managed. Built-in diagnostic tools MUST be defined to check the connectivity, trace the path and ensure fast detection of data plane failures on P2MP LDP LSPs. Further and precise requirements and mechanisms for P2MP MPLS OAM purpose are out of the scope of this document and are addressed in [P2MP-OAM-REQ]. 5.15. Graceful Restart and Fault Recovery LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT] mechanisms SHOULD be enhanced to support P2MP LDP LSPs. 5.16. Robustness A solution MUST avoid single points of failures provided there is enough network connectivity. 5.17. Scalability Scalability is a key requirement for the P2MP LDP mechanism. It MUST be designed to scale well with an increase in the number of any of the following: - number of Leaf LSRs per P2MP LSP; - number of Downstream LSRs per Branch LSR; - number of P2MP LSPs per LSR. Le Roux et al. Reqs for P2MP extensions to LDP [Page 11] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 In order to scale well with an increase in the number of leaves, it is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one particular LSP, depend only on the number of adjacent LSRs on the LSP. 5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs in operational networks Typical orders of magnitude that we expect should be supported are: - tens of thousands of P2MP trees spread out across core network routers; - hundreds, or a few thousands, of leaves per tree; See also section 4.2 of [L3VPN-MCAST-REQ]. 5.18. Backward Compatibility In order to allow for a smooth migration, the P2MP LDP mechanism SHOULD offer as much backward compatibility as possible. In particular, the solution SHOULD allow the setup of a P2MP LSP along non-Branch Transit LSRs that do not support P2MP LDP extensions. Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms and inherit its capability sets from [LDP]. The P2MP LDP solution MUST not impede the operation of P2P/MP2P LSPs. A P2MP LDP solution MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs to be signalled on the same interface. 6. Shared Trees For traffic delivery between a group of N Leaf LSRs which are acting indifferently as Ingress or Egress LSRs, it may be useful to setup a shared tree connecting all these LSRs, instead of having N P2MP LSPs. This would reduce the amount of control and forwarding state that has to be maintained on a given LSR. There are actually two main options for supporting such shared trees: - This could rely on the applications protocols that use LDP LSPs. A shared tree could consist of the combination of a MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP LSP from this root to all Leaf LSRs. For instance with Multicast L3 VPN applications, it would be possible to build a shared tree by combining: - a MP2P unicast LDP LSP, from each PE of the group to a particular root PE acting as tree root, - with a P2MP LDP LSP from this root PE to each PEs of the Group. - Or this could rely on a specific LDP mechanism allowing to setup multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). Le Roux et al. Reqs for P2MP extensions to LDP [Page 12] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 The former approach (Combination of MP2P and P2MP LSPs at the application level) is out of the scope of this document while the latter (MP2MP LSPs) belong to the scope of this document. Requirements for the set up of MP2MP LSPs are listed below. 6.1. Requirements for MP2MP LSPs A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf LSRs is received by all other Leaf LSRs of the group. Procedures for setting up MP2MP LSPs SHOULD be specified. An implementation that support P2MP LDP LSPs MAY also support MP2MP LDP LSP. The MP2MP LDP procedures MUST not impede the operations of P2MP LSP. Requirements for P2MP LSPs set forth in section 5 apply equally to MP2MP LSPs. Particular attention should be given on the below requirements: - The solution MUST support recovery upon link and transit node failure and there MUST be no single point of failure (provided network connectivity is redundant). Note that transit node failure recovery is likely to be more complex to handle with MP2MP LSPs than with P2MP LSPs; - The size of MP2MP state on a LSR, for one particular MP2MP LSP, SHOULD only depend on the number of adjacent LSRs on the LSP; - Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that may trigger exponential growth of traffic. Note that this requirement is more challenging with MP2MP LSPs as a LSR can receive traffic for a given LSP on multiple interfaces. There are additional requirements specific to MP2MP LSPs: - It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a specific LSR called root LSR; - It is RECOMMENDED to define several root LSRs (e.g. a primary and a backup) to ensure redundancy upon root LSR failure; - The receiver SHOULD not receive back a packet it has sent on the MP2MP LSP; - The solution SHOULD avoid that all traffic between any pair of leaves is traversing a root LSR, and SHOULD as much as possible minimize the distance between two leaves (similarly to PIM-Bidir trees); - It MUST be possible to check connectivity of a MP2MP LSP in both directions. Le Roux et al. Reqs for P2MP extensions to LDP [Page 13] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 7. Evaluation criteria 7.1. Performances The solution will be evaluated with respect to the following criteria: (1) Time to add or remove a Leaf LSR; (2) Time to repair a P2MP LSP in case of link or node failure; (3) Scalability (state size, number of messages, message size). Particularly the P2MP LDP mechanism SHOULD be designed with as key objective to minimize the additional amount of state and additional processing required in the network when deploying P2MP LDP. Also, the P2MP LDP mechanism SHOULD be designed so that convergence times in case of link or node failure are minimized, in order to limit traffic disruption. 7.2. Complexity and Risks The proposed solution SHOULD not introduce complexity to the current LDP operations to such a degree that it would affect the stability and diminish the benefits of deploying such P2MP LDP solution. 8. Security Considerations This document does not introduce any new security issue beyond those inherent to LDP, and a P2MP LDP solution may rely on the security mechanisms defined in [LDP] (e.g. TCP MD5 Signature). 9. Acknowledgments We would like to thank Christian Jacquenet (France Telecom), Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper), Dean Cheng (Cisco Systems), and Benjamin Niven-Jenkins (British Telecom), for their highly useful comments and suggestions. We would also like to thank authors of [P2MP-TE-REQ] from which some text of this document has been inspired. 10. References 10.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP Specification", RFC 3036, January 2001 Le Roux et al. Reqs for P2MP extensions to LDP [Page 14] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 [LDP-MIB] J. Cuchiarra et al. "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC3815, June 2004. [LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart Mechanism for Label Distribution Protocol" RFC3478, February 2003. [LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution Protocol (LDP)", RFC3479, February 2003. 10.2. Informative references [L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3 Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work in progress. [L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- mcast-reqts, work in progress. [2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress. [VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, “VPLS Multicast” draft- ietf-l2vpn-vpls-mcast, work in progress. [P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM Requirements for Point-To-Multipoint MPLS Networks", draft-ietf-mpls- p2mp-oam-reqs, work in progress. [P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- Multipoint capability extension to MPLS", RFC4461, April 2006. [P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- mpls-rsvp-te-p2mp, work in progress. 11. Editor Address Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@orange-ft.com Le Roux et al. Reqs for P2MP extensions to LDP [Page 15] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 12. Contributors Addresses Thomas Morin France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: thomas.morin@orange-ft.com Vincent Parfait EQUANT 1041 Route des Dolines Sophia Antipolis 06560 Valbonne FRANCE Email: vincent.parfait@orange-ft.com Luyuan Fang AT&T 200 Laurel Avenue Middletown, NJ 07748 USA Email: luyuanfang@att.com Lei Wang Telenor Snaroyveien 30 Fornebu 1331 NORWAY Email: lei.wang@telenor.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, JAPAN Email: y.kamite@ntt.com Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 USA Email: shane@level3.net Le Roux et al. Reqs for P2MP extensions to LDP [Page 16] Internet Draft draft-ietf-mpls-mp-ldp-reqs-01.txt June 2006 13. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Le Roux et al. Reqs for P2MP extensions to LDP [Page 17] --------------060601010200040608080300 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --------------060601010200040608080300-- From mpls-bounces@lists.ietf.org Wed Jul 12 10:37:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0foM-0008TO-Gy; Wed, 12 Jul 2006 10:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0foL-0008TE-68 for mpls@ietf.org; Wed, 12 Jul 2006 10:35:33 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0foJ-00087A-QX for mpls@ietf.org; Wed, 12 Jul 2006 10:35:33 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 16:35:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] mp reqs Date: Wed, 12 Jul 2006 16:35:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] mp reqs Thread-Index: AcalvkqqslCNXuLTSSStVGwYsdfO8gAADYfg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , X-OriginalArrivalTime: 12 Jul 2006 14:35:30.0837 (UTC) FILETIME=[6D0ADC50:01C6A5C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Dimitri, The problem statement for shared trees is quite clear (state reduction). = That being said there are various approaches for setting up shared trees = (MP2MP LSP, shared tree at the mVPN level...). This is why MP2MP is considered as optional. Regards, JL=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : mercredi 12 juillet 2006 16:20 > =C0 : mpls@ietf.org > Objet : [mpls] mp reqs >=20 > in this doc there is clear problem statement for p2mp case >=20 > but is no real problem statement for mp2mp beside soem words=20 > in the introductory paragraph of section 6 >=20 > qs-01.txt> >=20 > thanks, > - dimitri. >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 12 11:07:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0gHP-0006Zl-HN; Wed, 12 Jul 2006 11:05:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0gHO-0006Zg-EW for mpls@ietf.org; Wed, 12 Jul 2006 11:05:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0gHN-0001FP-5m for mpls@ietf.org; Wed, 12 Jul 2006 11:05:34 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0gHL-000F07-DO; Wed, 12 Jul 2006 15:05:31 +0000 Message-ID: <44B50FC3.8080400@psg.com> Date: Wed, 12 Jul 2006 17:05:39 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [mpls] mp reqs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: dimitri.papadimitriou@alcatel.be, mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org hi j-l understood the approach you are putting requirements on optimizing the implementation - my question is do we have any real feedback that this is really an issue ? i am asking this because the reason for mLDP was de-facto the simplification of introducing leaf initiated trees thanks, - dimitri. LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, > > The problem statement for shared trees is quite clear (state > reduction). That being said there are various approaches for setting > up shared trees (MP2MP LSP, shared tree at the mVPN level...). This > is why MP2MP is considered as optional. > > Regards, > > JL > > >> -----Message d'origine----- De : dimitri papadimitriou >> [mailto:dpapadimitriou@psg.com] Envoyé : mercredi 12 juillet 2006 >> 16:20 À : mpls@ietf.org Objet : [mpls] mp reqs >> >> in this doc there is clear problem statement for p2mp case >> >> but is no real problem statement for mp2mp beside soem words in the >> introductory paragraph of section 6 >> >> > qs-01.txt> >> >> thanks, - dimitri. >> >> > > > . > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From add@1-800-cruise.com Wed Jul 12 12:12:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hKD-0001BB-5r; Wed, 12 Jul 2006 12:12:33 -0400 Received: from cm218-254-203-31.hkcable.com.hk ([218.254.203.31] helo=cheng) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hKB-0004HX-O2; Wed, 12 Jul 2006 12:12:33 -0400 Message-ID: <662161c806040fnr5t3j84hg0gfao4ioyvdvub56qo4u@mx2.emailsrvr.com> Date: Wed, 12 Jul 2006 16:12:31 -0480 From: "Gonzalo Blanchard" To: mpls-archive@lists.ietf.org Subject: OW3 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 4.4 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Austin isn't a bad guy, he's got the right mix of courage and like the other gulls; he really tried, screeching and fighting with the "Well, shall we get on with it?" had a blazing drive to learn to fly. From mpls-bounces@lists.ietf.org Wed Jul 12 14:37:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jXr-0007qH-Um; Wed, 12 Jul 2006 14:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jX4-00079d-Qy for mpls@ietf.org; Wed, 12 Jul 2006 14:33:58 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jIs-0000iP-1G for mpls@ietf.org; Wed, 12 Jul 2006 14:19:19 -0400 Received: from [132.219.30.209] (helo=[132.219.30.209]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1G0jIo-0000mS-4b; Wed, 12 Jul 2006 20:19:15 +0200 Message-ID: <44B53D1F.7060103@pi.se> Date: Wed, 12 Jul 2006 20:19:11 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Eric Rescorla , mpls@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [mpls] context labels X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Eric, a question on the context label, where would it go? +------------------------+------+--------+-------+ | ip payload | ip |context | ua | | |header| label | label | +------------------------+------+--------+-------+ or +------------------------+------+--------+-------+ | ip payload | ip | ua |context| | |header| label | label | +------------------------+------+--------+-------+ Regardless where it goes the semantics is similar, the context label gives you a context in which you may handle the push/swap/pop the ua label. This strikes me as being different from the normal behavior of an LSR. Normally when a label is propped you can forget it, because the next label in the stack is unique. This is not true in this case. When taking the decision on the ua label this is not necessarily true. Do you intend do this in some type of VRF? In any case wouldn't this affect hw? /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 12 15:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kin-0005pt-M6; Wed, 12 Jul 2006 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kii-0005Xc-0o; Wed, 12 Jul 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kig-0007dS-Of; Wed, 12 Jul 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6CJo21u016974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G0kig-0000vP-8p; Wed, 12 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Jul 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-iana-rsvp-session-flags-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 : Codepoint Registry for The Flags Field in the Resource Reservation Protocol Traffic Engineering (RSVP-TE) Session Attribute Object Author(s) : A. Farrel Filename : draft-ietf-mpls-iana-rsvp-session-flags-00.txt Pages : 5 Date : 2006-7-12 This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineeging (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-iana-rsvp-session-flags-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iana-rsvp-session-flags-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-iana-rsvp-session-flags-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-12112956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-iana-rsvp-session-flags-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-iana-rsvp-session-flags-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-12112956.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed Jul 12 17:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mDQ-0003vd-9a; Wed, 12 Jul 2006 17:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mDO-0003vY-Qk for mpls@lists.ietf.org; Wed, 12 Jul 2006 17:25:50 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mDM-00059Z-Gi for mpls@lists.ietf.org; Wed, 12 Jul 2006 17:25:50 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G0mDH-0000Qo-00 for mpls@lists.ietf.org; Wed, 12 Jul 2006 22:25:43 +0100 Received: from your029b8cecfe ([132.219.13.233] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 22:25:45 +0100 Message-ID: <063f01c6a5f9$b8103ef0$e90ddb84@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 12 Jul 2006 20:57:27 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Jul 2006 21:25:46.0844 (UTC) FILETIME=[BD5371C0:01C6A5F9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [mpls] Use of reserved bits in Session object X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, Just a heads up that draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt makes use of the reserved bits in the Session object in order to convey a Call ID. We believe that this does not cause a backward compatiblity problem since the bits were formerly reserved. Note that RFC3209 says that these bits MUST be set to zero on transmission. Any questions or opinions would be welcomed. Adrian and Dimitri _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jul 12 20:30:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0p4G-0000ta-Mh; Wed, 12 Jul 2006 20:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0p4F-0000tQ-Ms for mpls@lists.ietf.org; Wed, 12 Jul 2006 20:28:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mWC-0006K3-3Q for mpls@lists.ietf.org; Wed, 12 Jul 2006 17:45:16 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0mIu-0005rg-MW for mpls@lists.ietf.org; Wed, 12 Jul 2006 17:31:34 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G0mIi-0000yi-00 for mpls@lists.ietf.org; Wed, 12 Jul 2006 22:31:20 +0100 Received: from your029b8cecfe ([132.219.13.233] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 22:31:25 +0100 Message-ID: <065f01c6a5fa$83092720$e90ddb84@your029b8cecfe> From: "Adrian Farrel" To: "Loa Andersson" , "George Swallow" References: Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-iana-rsvp-session-flags-00.txt Date: Wed, 12 Jul 2006 22:28:37 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Jul 2006 21:31:25.0284 (UTC) FILETIME=[870D4A40:01C6A5FA] X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mpls@lists.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org George, Loa, As discussed today, I believe this I-D is ready for WG last call. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, July 12, 2006 8:50 PM Subject: [mpls] I-D ACTION:draft-ietf-mpls-iana-rsvp-session-flags-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > Title : Codepoint Registry for The Flags Field in the Resource Reservation > Protocol Traffic Engineering (RSVP-TE) Session Attribute Object > Author(s) : A. Farrel > Filename : draft-ietf-mpls-iana-rsvp-session-flags-00.txt > Pages : 5 > Date : 2006-7-12 > > This document provides instructions to IANA for the creation of a new > codepoint registry for the flags field in the Session Attribute > object of the Resource Reservation Protocol Traffic Engineeging > (RSVP-TE) signaling messages used in Multiprotocol Label Switching > (MPLS) and Generalized MPLS (GMPLS) signaling. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-iana-rsvp-session-flags-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-iana-rsvp-session-flags-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-iana-rsvp-session-flags-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jul 13 09:17:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G112G-0004Zd-6s; Thu, 13 Jul 2006 09:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G112E-0004ZY-Er for mpls@lists.ietf.org; Thu, 13 Jul 2006 09:15:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G112C-0003Mu-5Y for mpls@lists.ietf.org; Thu, 13 Jul 2006 09:15:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2006 06:15:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,237,1149490800"; d="scan'208"; a="32099583:sNHT27153744" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDFDTh023531 for ; Thu, 13 Jul 2006 09:15:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DDFD7v023018 for ; Thu, 13 Jul 2006 09:15:13 -0400 (EDT) Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 09:15:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jul 2006 09:14:34 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-thomas-mpls-ldp-capabilities-00 Thread-Index: AcamOccM+ER7TQ0TQbyUY4G/tDEn+g== From: "Aamer Akhter \(aakhter\)" To: "Bob Thomas \(rhthomas\)" X-OriginalArrivalTime: 13 Jul 2006 13:15:13.0319 (UTC) FILETIME=[5FFDB370:01C6A67E] DKIM-Signature: a=rsa-sha1; q=dns; l=2217; t=1152796513; x=1153660513; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aakhter@cisco.com; z=From:=22Aamer=20Akhter=20\(aakhter\)=22=20 |Subject:comments=20on=20draft-thomas-mpls-ldp-capabilities-00 |To:=22Bob=20Thomas=20\(rhthomas\)=22=20; X=v=3Dcisco.com=3B=20h=3DUBphAHH2/ZklmNq5gM7vJdFJH+k=3D; b=hN417+k0sBeQBNgaTasgJcT/6Sc7pwijwZHSh0WeU4QbpciGjm39Lu9PHce5t90TtVa9z019 mkPKlysWXSr2kyYkd24Ho6JDDQr28Ce85UI3WFNW/Dem21HIK4tamiHE; Authentication-Results: rtp-dkim-1.cisco.com; header.From=aakhter@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mpls@lists.ietf.org Subject: [mpls] comments on draft-thomas-mpls-ldp-capabilities-00 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Bob, Thank-you for writing draft-thomas-mpls-ldp-capabilities draft. Couple of comments: 1)=20 RFC3031 has a MUST statement that says label distribution protocols must negotiate exp-null capabilities. It would be good to get this into LDP ;-). However, I would agree I don't know anybody that doesn't support exp-null in frame-mode. To be backward compatible, it might be preferable to have a default behavior of supporting exp-null (like the ipv4 fec support mentioned in the draft), and non support would have to be explicitly disabled by signaling. RFC3031 3.16 " Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so." 2)=20 Not sure how this is usually done, but perhaps a vendor specific range (or high order bit) for capability codes? or is this usually done after the IANA engagement ? 3)=20 >From reading the draft it is unclear: At session establishment, if a capability ack is requested, is an explicit cap-ack is sent for each cap? Or will a single keepalive will suffice. 4) section 5. Let's say CAP-enabled LDP peer sends CAP-LIST-TLV with INIT message.=20 * In the case the peer sends back a keepalive, this is seen as an 'implicit acknowledgement for any announced capabilities that may require acknowledgement'. However, a peer that does not support CAP would also send back a keepalive (when the U bit =3D=3D 1 ). The above condition is resolved by setting the U bit to 0, but the draft leaves open the above confusing possibility where it is not really known if the peer even supports CAP-TLV at all. Is there any benefit in this openness, and should we have a recommendation? 5)=20 It is unclear (from a quick read of RFC3036) what kind of notification (fatal or otherwise) is sent in the case U bit =3D=3D 0 and peer is not = CAP enabled. If it _is_ a fatal error, should the session reestablishment backoff timer be ignored? Regards, --=20 Aamer Akhter / aakhter@cisco.com NSITE, cisco Systems _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jul 13 15:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17CJ-0004vu-LF; Thu, 13 Jul 2006 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17CG-0004uC-Lu; Thu, 13 Jul 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17CE-0003kA-CL; Thu, 13 Jul 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6DJo21u016987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G17CE-0003Z2-3P; Thu, 13 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 13 Jul 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-fastreroute-mib-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 for Fast Reroute Author(s) : R. Cetin, T. Nadeau Filename : draft-ietf-mpls-fastreroute-mib-05.txt Pages : 34 Date : 2006-7-13 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching fast rerouting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-fastreroute-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-fastreroute-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-13133208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-fastreroute-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-fastreroute-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-13133208.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Tue Jul 18 12:18:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sEr-0000I1-Fp; Tue, 18 Jul 2006 12:16:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sEq-0000Hw-04 for mpls@ietf.org; Tue, 18 Jul 2006 12:16:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2sEo-00032e-P1 for mpls@ietf.org; Tue, 18 Jul 2006 12:15:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jul 2006 12:15:58 -0400 X-IronPort-AV: i="4.06,255,1149480000"; d="scan'208"; a="93081856:sNHT23488376" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6IGFwvT011549; Tue, 18 Jul 2006 12:15:58 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6IGFv7t017700; Tue, 18 Jul 2006 12:15:57 -0400 (EDT) Message-Id: <200607181615.k6IGFv7t017700@rtp-core-1.cisco.com> To: Loa Andersson Subject: Re: [mpls] context labels In-reply-to: Your message of Wed, 12 Jul 2006 20:19:11 +0200. <44B53D1F.7060103@pi.se> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Jul 2006 12:15:57 -0400 From: Eric Rosen DKIM-Signature: a=rsa-sha1; q=dns; l=1798; t=1153239358; x=1154103358; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:Eric=20Rosen=20 |Subject:Re=3A=20[mpls]=20context=20labels=20 |To:Loa=20Andersson=20; X=v=3Dcisco.com=3B=20h=3DvyjaOPLBszCWPYTG7sU6jWK15cQ=3D; b=0R18H3t68ICj3DSbWwdGIWFLGGEKpW+QvDgTl0EQQ2iQRiGPhz4Zjn6FIBkDnv5Azh8XMrto BepYlMx0YqUooDgFzBhQRFOTzBQ+iz7negXVHlBkT+RnFO0QY3VVKgRU; Authentication-Results: rtp-dkim-2.cisco.com; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > a question on the context label, where would it go? It has to be above (i.e., closer to the top of the stack) the UA label for which it provides the context. On an ethernet, if the ethertype indicates "UA label", the context label would be expected to be at the top of the stack, with the UA label beneath it. On a MP2MP LSP, the downstream-assigned label assigned by mLDP would be at the top, and beneath it would be the context label and then the UA label. > Normally when a label is propped you can forget it, because the next label > in the stack is unique Well, not necessarily. If it is known, for example, that when a packet is received from interface X its top label is looked up in an interface- specific label space determined by X, then the label is not "unique", it's only unique relative to X. We've always allowed the scope of uniqueness to be determined by the incoming interface. If we allow the "incoming interface" to be the context in which a label is interpreted, why not generalize and allow an LSP egress to use "incoming LSP" as the context? When using UA labels over a P2MP LSP, we don't use PHP on that LSP, so at an LSP egress of the P2MP LSP, the top label identifies the LSP (implicitly identifying the transmitter), and hence provides the context in which to interpret the next label, which is the UA label. It's just a short step to the generalized notion of context label that I proposed in Montreal. > This strikes me as being different from the normal behavior of an LSR Think of it as a way of providing a 40 or 60 bit label space ;-) This is a change to the forwarding path and existing LSRs may not necessarily be able to handle it. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jul 20 11:19:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aGt-0001mF-Ax; Thu, 20 Jul 2006 11:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aGq-0001gk-D9 for mpls@lists.ietf.org; Thu, 20 Jul 2006 11:17:00 -0400 Received: from hicks.ciena.com ([63.118.34.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3a3B-0007vw-77 for mpls@lists.ietf.org; Thu, 20 Jul 2006 11:02:54 -0400 Received: from mdmail4.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by hicks.ciena.com with ESMTP; 20 Jul 2006 11:21:06 -0400 X-IronPort-AV: i="4.07,163,1151899200"; d="scan'208"; a="59973258:sNHT72253026" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Use of reserved bits in Session object Date: Thu, 20 Jul 2006 11:02:34 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F1A010@mdmxm02.ciena.com> In-Reply-To: <063f01c6a5f9$b8103ef0$e90ddb84@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Use of reserved bits in Session object Thread-Index: Acal+c/Ftwt3w2nnQ7m1l+hsE7EZawGEw9rA From: "Ong, Lyndon" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Folks, Just to further bring this to people's attention - RFC 3209 says that the bits in this subfield of the Session object "MUST be set to zero", rather=20 than simply saying that the subfield is "Reserved". Not being familiar with how this text originated, I'd like to understand if this was done for a specific reason (e.g., to maintain some kind of compatibility with RFC 2205) or whether it was stated that way ("MUST be set=20 to zero" vs. "Reserved") with nothing further implied. Thanks, Lyndon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, July 12, 2006 12:57 PM To: mpls@lists.ietf.org Subject: [mpls] Use of reserved bits in Session object Hi, Just a heads up that draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt makes use of the reserved bits in the Session object in order to convey a Call ID. We believe that this does not cause a backward compatiblity problem since the bits were formerly reserved. Note that RFC3209 says that these bits MUST be set to zero on transmission. Any questions or opinions would be welcomed. Adrian and Dimitri=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jul 20 11:37:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aYX-0007WO-ES; Thu, 20 Jul 2006 11:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aYO-0007AR-Ln for mpls@lists.ietf.org; Thu, 20 Jul 2006 11:35:08 -0400 Received: from hicks.ciena.com ([63.118.34.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3aLT-0002SF-TD for mpls@lists.ietf.org; Thu, 20 Jul 2006 11:21:49 -0400 Received: from mdmail4.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by hicks.ciena.com with ESMTP; 20 Jul 2006 11:40:17 -0400 X-IronPort-AV: i="4.07,163,1151899200"; d="scan'208"; a="59974208:sNHT54750016" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Use of reserved bits in Session object Date: Thu, 20 Jul 2006 11:21:46 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F1A01E@mdmxm02.ciena.com> In-Reply-To: <0901D1988E815341A0103206A834DA07F1A010@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Use of reserved bits in Session object Thread-Index: Acal+c/Ftwt3w2nnQ7m1l+hsE7EZawGEw9rAAADOPMA= From: "Ong, Lyndon" To: "Ong, Lyndon" , "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org One correction, RFC 3209 (p. 39) actually says "MUST be zero" for that subfield, not "MUST be set to zero". Lyndon=20 -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Thursday, July 20, 2006 8:03 AM To: Adrian Farrel; mpls@lists.ietf.org Subject: RE: [mpls] Use of reserved bits in Session object Hi Folks, Just to further bring this to people's attention - RFC 3209 says that the bits in this subfield of the Session object "MUST be set to zero", rather than simply saying that the subfield is "Reserved". Not being familiar with how this text originated, I'd like to understand if this was done for a specific reason (e.g., to maintain some kind of compatibility with RFC 2205) or whether it was stated that way ("MUST be set to zero" vs. "Reserved") with nothing further implied. Thanks, Lyndon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, July 12, 2006 12:57 PM To: mpls@lists.ietf.org Subject: [mpls] Use of reserved bits in Session object Hi, Just a heads up that draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt makes use of the reserved bits in the Session object in order to convey a Call ID. We believe that this does not cause a backward compatiblity problem since the bits were formerly reserved. Note that RFC3209 says that these bits MUST be set to zero on transmission. Any questions or opinions would be welcomed. Adrian and Dimitri=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From characteristicbidirectional@yours.com Sun Jul 23 10:10:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4efF-0007sb-8x; Sun, 23 Jul 2006 10:10:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4efF-0004p7-5z; Sun, 23 Jul 2006 10:10:37 -0400 Received: from alille-257-1-168-28.w86-215.abo.wanadoo.fr ([86.215.251.28] helo=ejaj.1ebwiq.comcast.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G4eep-0001Va-L9; Sun, 23 Jul 2006 10:10:36 -0400 Message-ID: <43191300031503.430AD36BFD@F8VKOU> From: "characteristic" To: Subject: Come out with great gains – use this stock recommended by professionals., Just published Date: Sun, 23 Jul 2006 16:09:17 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: alFAMA8mKNE1iIel3V1KpQfwfFl2MUeLgs6r Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Did not gain much on your previous trading day? Don’t worry, it’ll be better tomorrow! Feel the buzz of these stocks about to boom, and you’ll succeed. You’ll come out of the day with a handsome profit with this stock. Every analysis predicts the boom for this. The alert is ON! Get QEGY First Thing Today! This Is Going To Explode! Check out for HOT NEWS! QUANTUM ENERGY INC (QEGY) CURRENT_PRICE: $2.34 GET IT N0W! About the company Quantum Energy is a publicly traded growth orientated oil and gas exploration company. The objective is to seek out and define opportunities that represent a low risk 0pp0rtunity to develop positive cash flow. As well, the company aims to define larger projects that can be developed with Joint Venture partners or be entered into by a Joint Venture. Red Hot News QUANTUM ENERGY INC. PURCHASES NEW FACILITY CORSICANA TEXAS. July 20, 2006 Quantum Energy, Inc. (QEGY) announced that its joint venture partner, JMT Resources, Ltd. has entered into a contract to purchase a ten acre facility yard in Corsicana, Texas. The acquisition was formerly the facilities yard for Mobile Oil, and is adjacent to the Corsicana Field, which it operates. The site contains an assortment of oil field equipment that the joint venture partnership will utilize in its field operations. The acquisition also gives the JV partnership surface ownership of its water injection disposal well, which is in the permitting process with the Texas Railroad Commission. Ownership of this parcel will reduce operating costs; it will also give the JV partnership the option to add more injection disposal wells on this site, while housing its own redevelopment operations. Due to the substantially increased Barnett Shale drilling activities in Johnson and surrounding counties, there is an enormous need for disposal options of high chloride (salt) water, which is used in the stimulation of Barnett Shale wells. Operators in the area are required to dispose of this treated water in sanctioned disposal zones. In this area, the zone most prevalently used is the Woodbine, which is the depth of the well the partnership is currently permitting. Demand for disposal facilities is substantial. Operators have resorted to trucking their treated water several hours from location for disposal. Current disposal rates are $2 per barrel and trucks will carry 150 to 200 barrel capacities. It is estimated that the JV partnership will be able to dispose of approximately 5,000 barrels of treated water per day. This operation will allow the JV partnership to attain substantial cash flow from this ancillary oil field operation reducing its reliance on outside capital. It is expected that the water disposal well will be operational during the fourth quarter of 2006. This facility would also be available for disposal of waste water recovered from the Nacatoch wells in the JV Polymer project as well. Ultimately, the disposal fluid from the polymer will be quite significant once the project passes from the pilot phase into full development. Correspondingly, the availability of the water disposal well that is owned by the JV partnership will lead to reduced costs and higher efficiencies. Enter the opportunity with this stock, and you’ll leave with totally handsome gains. You don’t need money luck spells. All you need is trade like a pro, and you’ll see gold flowing to you! From alleywaycorvette@registerednurses.com Mon Jul 24 16:08:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56il-0003AK-0W; Mon, 24 Jul 2006 16:08:07 -0400 Received: from cmodem-240-146.tricom.net ([200.42.240.146] helo=CRUZ) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56ij-0001md-LB; Mon, 24 Jul 2006 16:08:06 -0400 Message-ID: <66287402783913.C2041EA988@QANI> From: "alleyway" To: Subject: The earning opportunities of this stock are not to be missed out on., Recent stuff Date: Mon, 24 Jul 2006 16:08:02 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: SKsG7yg5N91o0JOF4gmBWy2yYL2UAyeSNjfE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 You certainly dreamed about enhancing your trading strategy with stock gems that few people know about. Now you can make full use of that with our expert advice and insider information! Make a move that will put you ahead. I know for sure this stock will make it big very soon. The alert is ON! Get QEGY First Thing Today! This Is Going To Explode! Check out for HOT NEWS! QUANTUM ENERGY INC (QEGY) CURRENT_PRICE: $2.34 GET IT N0W! About the company Quantum Energy is a publicly traded growth orientated oil and gas exploration company. The objective is to seek out and define opportunities that represent a low risk 0pp0rtunity to develop positive cash flow. As well, the company aims to define larger projects that can be developed with Joint Venture partners or be entered into by a Joint Venture. Red Hot News QUANTUM ENERGY INC. PURCHASES NEW FACILITY CORSICANA TEXAS. July 20, 2006 Quantum Energy, Inc. (QEGY) announced that its joint venture partner, JMT Resources, Ltd. has entered into a contract to purchase a ten acre facility yard in Corsicana, Texas. The acquisition was formerly the facilities yard for Mobile Oil, and is adjacent to the Corsicana Field, which it operates. The site contains an assortment of oil field equipment that the joint venture partnership will utilize in its field operations. The acquisition also gives the JV partnership surface ownership of its water injection disposal well, which is in the permitting process with the Texas Railroad Commission. Ownership of this parcel will reduce operating costs; it will also give the JV partnership the option to add more injection disposal wells on this site, while housing its own redevelopment operations. Due to the substantially increased Barnett Shale drilling activities in Johnson and surrounding counties, there is an enormous need for disposal options of high chloride (salt) water, which is used in the stimulation of Barnett Shale wells. Operators in the area are required to dispose of this treated water in sanctioned disposal zones. In this area, the zone most prevalently used is the Woodbine, which is the depth of the well the partnership is currently permitting. Demand for disposal facilities is substantial. Operators have resorted to trucking their treated water several hours from location for disposal. Current disposal rates are $2 per barrel and trucks will carry 150 to 200 barrel capacities. It is estimated that the JV partnership will be able to dispose of approximately 5,000 barrels of treated water per day. This operation will allow the JV partnership to attain substantial cash flow from this ancillary oil field operation reducing its reliance on outside capital. It is expected that the water disposal well will be operational during the fourth quarter of 2006. This facility would also be available for disposal of waste water recovered from the Nacatoch wells in the JV Polymer project as well. Ultimately, the disposal fluid from the polymer will be quite significant once the project passes from the pilot phase into full development. Correspondingly, the availability of the water disposal well that is owned by the JV partnership will lead to reduced costs and higher efficiencies. Seasoned traders recommend you to take a close look at this stock. I sincerely hope you get your slice of the trading pie. And I wish it’s really thick and sweet! From biaxialcrypt@umpire.com Tue Jul 25 04:27:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5IGc-0002Gq-PR for mpls-archive@lists.ietf.org; Tue, 25 Jul 2006 04:27:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Glq-0001uJ-LZ for mpls-archive@lists.ietf.org; Tue, 25 Jul 2006 02:51:58 -0400 Received: from qj26.internetdsl.tpnet.pl ([80.55.35.26] helo=WOW) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5Ghb-0003no-Kh for mpls-archive@lists.ietf.org; Tue, 25 Jul 2006 02:47:36 -0400 Message-ID: <18911925366363.E2E378FB04@FCQQ7> From: "biaxial" To: Subject: Diversify your stock strategy and benefit from this one offering great opportunities., Never seen stuff Date: Tue, 25 Jul 2006 08:51:01 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: m7q9w6VpoydrTrUfakwbB0t5t4Ap0b2mKpAR Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 If you know what switching from one trade strategy to another feels like, this is for you. What you need is market winners pointed out before they make it big! You will be kicking yourself if you miss this opportunity. You’ll make a huge gain with this stock in days! The alert is ON! Get QEGY First Thing Today! This Is Going To Explode! Check out for HOT NEWS! QUANTUM ENERGY INC (QEGY) CURRENT_PRICE: $2.34 GET IT N0W! About the company Quantum Energy is a publicly traded growth orientated oil and gas exploration company. The objective is to seek out and define opportunities that represent a low risk 0pp0rtunity to develop positive cash flow. As well, the company aims to define larger projects that can be developed with Joint Venture partners or be entered into by a Joint Venture. Red Hot News QUANTUM ENERGY INC. PURCHASES NEW FACILITY CORSICANA TEXAS. July 20, 2006 Quantum Energy, Inc. (QEGY) announced that its joint venture partner, JMT Resources, Ltd. has entered into a contract to purchase a ten acre facility yard in Corsicana, Texas. The acquisition was formerly the facilities yard for Mobile Oil, and is adjacent to the Corsicana Field, which it operates. The site contains an assortment of oil field equipment that the joint venture partnership will utilize in its field operations. The acquisition also gives the JV partnership surface ownership of its water injection disposal well, which is in the permitting process with the Texas Railroad Commission. Ownership of this parcel will reduce operating costs; it will also give the JV partnership the option to add more injection disposal wells on this site, while housing its own redevelopment operations. Due to the substantially increased Barnett Shale drilling activities in Johnson and surrounding counties, there is an enormous need for disposal options of high chloride (salt) water, which is used in the stimulation of Barnett Shale wells. Operators in the area are required to dispose of this treated water in sanctioned disposal zones. In this area, the zone most prevalently used is the Woodbine, which is the depth of the well the partnership is currently permitting. Demand for disposal facilities is substantial. Operators have resorted to trucking their treated water several hours from location for disposal. Current disposal rates are $2 per barrel and trucks will carry 150 to 200 barrel capacities. It is estimated that the JV partnership will be able to dispose of approximately 5,000 barrels of treated water per day. This operation will allow the JV partnership to attain substantial cash flow from this ancillary oil field operation reducing its reliance on outside capital. It is expected that the water disposal well will be operational during the fourth quarter of 2006. This facility would also be available for disposal of waste water recovered from the Nacatoch wells in the JV Polymer project as well. Ultimately, the disposal fluid from the polymer will be quite significant once the project passes from the pilot phase into full development. Correspondingly, the availability of the water disposal well that is owned by the JV partnership will lead to reduced costs and higher efficiencies. This stock combines a no-hype situation with serious promises of a good rise. You don’t need money luck spells. All you need is trade like a pro, and you’ll see gold flowing to you! From mpls-bounces@lists.ietf.org Wed Jul 26 07:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hqI-000290-77; Wed, 26 Jul 2006 07:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hk5-0007dM-0i for mpls@lists.ietf.org; Wed, 26 Jul 2006 07:39:57 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5hk3-0001DL-C6 for mpls@lists.ietf.org; Wed, 26 Jul 2006 07:39:56 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:39:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Jul 2006 13:39:46 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603AF5448@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: MPLS 2006 International Conference program Thread-Index: AcawqDGfaBwckss6T+GrytZqznUARA== From: "MOIGNARD Renaud RD-CORE-LAN" Bcc: X-OriginalArrivalTime: 26 Jul 2006 11:39:47.0956 (UTC) FILETIME=[32C76340:01C6B0A8] X-Spam-Score: 0.5 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac X-Mailman-Approved-At: Wed, 26 Jul 2006 07:46:21 -0400 Subject: [mpls] MPLS 2006 International Conference program X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1217113841==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1217113841== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C6B0A8.321FF680" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B0A8.321FF680 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6B0A8.321FF680" ------_=_NextPart_002_01C6B0A8.321FF680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS 2006 International Conference Omni Shoreham Hotel, Washington DC, October 15-18, 2006,=20 http://www.mpls2006.com/ =20 You are cordially invited to attend the MPLS 2006 International Conference to be held in Washington, DC from October 15-18, 2006. The 4-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. Program details are available at: =20 http://www.mpls2006.com/program.htm =20 Registration for the conference is now open. Early registration discounts are highly attractive and are valid for a limited time only. To register, go to: http://www.mpls2006.com/onlineregis.htm =20 To make reservations at the Omni Shoreham Hotel, please call the Hotel Reservation Desk directly. You must identify yourself as MPLS 2006 conference attendees for discounted rates. Or, go to=20 www.omnishorehamhotle.com and at the bottom of the page enter 12400606975 for the group code. By phone, please call the Hotel Reservation Desk directly (1-800-843-6664 or 202-265-7972). You must identify yourself as MPLS 2006 conference attendee for discounted rates. Please note Reservation may be accepted only subject to space availability. Important Dates: ------------------------ - Early Registration Rates Cut-Off Date: August 1, 2006 - Tutorials: Sunday, October 15, 10:30 am - 6:00 pm - Technical Sessions: Monday-Wednesday, October 16-18, 8:30 am - 6:00 pm - Breaks & Exhibits: Monday, October 16th - Wednesday, October 18th=20 - 7th Public Interoperability Demonstration: October 19th, 11:00 am =20 =20 Renaud Moignard France Telecom R&D Division=20 renaud.moignard@orange-ft.com =20 =20 ------_=_NextPart_002_01C6B0A8.321FF680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MPLS=20 2006 International Conference

Omni Shoreham Hotel, Washington DC, October 15-18, 2006,=20 http://www.mpls2006.com/=

You are cordially invited to = attend the=20 MPLS 2006 International Conference to be held in Washington, DC=20 from October 15-18, 2006. The 4-day event consists of highly technical = sessions,=20 tutorials, panel discussions, and exhibits.  Program details are = available=20 at:  http://www.mpls2006.com/p= rogram.htm

 Registration for the=20 conference is now open. Early registration discounts are highly = attractive and=20 are valid for a limited time only. To register, go to:  http://www.mpls2006.c= om/onlineregis.htm

To make reservations at the Omni = Shoreham Hotel,=20 please call the Hotel Reservation Desk directly. You=20 must identify yourself as MPLS 2006 conference attendees for discounted=20 rates.  Or, go = to www.omnishorehamhotle.com=20 and at the bottom of the page enter 12400606975 = for the=20 group code.  By phone, please call the Hotel Reservation Desk=20 directly (1-800-843-6664 or 202-265-7972). You = must=20 identify yourself as MPLS 2006 conference attendee for discounted rates. = Please=20 note Reservation may be accepted only subject to space=20 availability.

Important Dates:

------------------------

- Early Registration Rates Cut-Off Date: = August 1,=20 2006

- Tutorials: Sunday, October 15, 10:30 am - = 6:00=20 pm

- Technical Sessions: Monday-Wednesday, October 16-18, 8:30 am = - 6:00=20 pm   

-=20 Breaks & Exhibits: = Monday, October 16th – = Wednesday, October=20 18th

-=20 7th Public Interoperability Demonstration: October=20 19th, 11:00 am

 

Renaud=20 Moignard
France Telecom R&D Division
renaud.moignard@orange-ft.c= om

 
------_=_NextPart_002_01C6B0A8.321FF680-- ------_=_NextPart_001_01C6B0A8.321FF680 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-Description: orange_logo.gif Content-Location: http://www.francetelecom.com/sirius/logos_mail/orange_logo.gif R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9ZAP/6 9v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/UuP9xF/+/ lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9lAv+cXf/IpP/8 +v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+ALf9zGv+1h//w5v/u 4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9vEv+zhf9aAP91JP/07P/D nf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9iCv+ocv+QSv/Zwv/AmP+8j/+d Xv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9nA/9eBP/bw//aw//k1P+STf/r3f/n 1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/XvP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/h zv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9lAf9yFv+pcf94KP+xe//Yv/94If9pCv+COf+Z Vf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9oA//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+ K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+XVf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8 kQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQ AQYQCEBAZABOUnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAU INBpABIPqmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBn yQIMClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0WUCUE lMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCHAMEwIcAO OQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhhCQO8THCJDsIU NRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7GFEQhR6yCSQc1HeUR XKSMEKdCAQEAOw== ------_=_NextPart_001_01C6B0A8.321FF680 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-Description: ampersand.gif Content-Location: http://www.francetelecom.com/sirius/logos_mail/ampersand.gif R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91AO51 APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x9/7x9vnG k/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P769falofzjyvjB ivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnNnuo0MeszN/e7gP3r 2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxNQ+onK/zm0egaGe5rCvKX OukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvjyvFzdPKQLfCADOgUFPjHkvKN Jv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOklGuszK/rbue9ZW/739uoyMv3w4/jH ju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rKy//8/PKZPO9nZ+5OUf759O9xAPjCi+5R SPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucL C/B/DPrNzvnEu/a2dffBffOEhvaipv738O1RTvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQA AAj/AAEIHDgwlYgsTaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYC R06iMgVLIKUdD7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQc IEJlYSFSpQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUB VAyBUQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAAOw== ------_=_NextPart_001_01C6B0A8.321FF680-- --===============1217113841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1217113841==-- From discriminatebread@hot-shot.com Thu Jul 27 02:10:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5z4r-0005UX-Bk; Thu, 27 Jul 2006 02:10:33 -0400 Received: from 220-142-104-91.dynamic.hinet.net ([220.142.104.91] helo=USER-JW9M3Y13M4.cumgq3.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5z4n-0007UO-Pg; Thu, 27 Jul 2006 02:10:33 -0400 Message-ID: <96313170370713.E0CDCC6954@UA47K7S> From: "Letha" To: Subject: Brand new How much more would you earn? Date: Thu, 27 Jul 2006 14:10:06 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: GutzyOrxVkpi83hCpBuexIS6qVLsU7eiZPm7 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 No Exam or Classes Required A Genuin e Universi ty Degr ee in 4-6 weeks! Have you ever thought that the only thing stopping you from a great job and better pay was a few letters behind y ou name? Well now you can get them! BA BSc MA MSc MBA PhD Within 4-6 weeks! No Study Required! 100% Verifiable! These are r eal, genu ine degre es that include B achelors, Masters, MBA and D octorate Degrees. They are fully verifiable and certified transcripts are also available. Just call the number below. You thank me later Please call: 1-928-3 95-7489 Calls returned promptly If anything can go wrong, it will Faith will move mountains. Why bark when you can get a dog to do it A Growing Youth Has a Wolf in His Belly. One good turn deserves another The squeaky wheel gets the grease. Christmas comes but once a year From cadrecope@cliffhanger.com Thu Jul 27 02:20:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zEV-0006U2-V7; Thu, 27 Jul 2006 02:20:31 -0400 Received: from pool-71-251-142-48.cmdnnj.east.verizon.net ([71.251.142.48] helo=ixegsu.aawzpg.optonline.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5zEU-0000Hj-9E; Thu, 27 Jul 2006 02:20:31 -0400 Message-ID: <00187154813887.0E216EE8D5@XESE84YL> From: "Elinor" To: Subject: The newest Passed up for the promotion..again? Date: Thu, 27 Jul 2006 02:19:57 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: XfN0CwDFklGyeafiKWH5epXookS4WZuzrNaP Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 You Will Love This Fas t Tr ack Degr ee Progr am Obtain the degr ee you deserve, based on your present knowledge and life experience. A prosperous future, money earning power, and the Admiration of all. De grees from an Established, Pre stigious, Leading Institution. Your degre e will show exactly what you really can do. Get the Job, Promotion, Business Opportunity and Social Advancement you Desire! Eliminates classrooms and traveling. Achieve your Bachelo rs, Master s, MB A, or P hD in the field of your expertise. Professional and affordable! Call now - your Gradua tion is a phone call away. Please call: 1-206-600-682 5 Calls returned promptly Men are from earth Women are from earth Deal with it Keep your chin up One mans meat is another mans poison! A fool and his money are soon parted. Know which side your bread is buttered From mpls-bounces@lists.ietf.org Fri Jul 28 10:44:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TXw-0003vp-CC; Fri, 28 Jul 2006 10:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TXu-0003vk-25 for mpls@ietf.org; Fri, 28 Jul 2006 10:42:34 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6TXr-0006XN-CD for mpls@ietf.org; Fri, 28 Jul 2006 10:42:34 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 15:42:30 +0100 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Jul 2006 15:42:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jul 2006 15:42:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-swallow-mpls-mcast-cv-00 Thread-Index: AcayVAtWAob1zwlWSf6EikoU/DmiPw== From: To: X-OriginalArrivalTime: 28 Jul 2006 14:42:29.0527 (UTC) FILETIME=[0D35E270:01C6B254] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: tnadeau@cisco.com Subject: [mpls] Comments on draft-swallow-mpls-mcast-cv-00 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Colleagues, draft-swallow-mpls-mcast-cv is a good start towards addressing P2MP OAM in a scalable manner. Following on from my comments at IETF 66, I have discussed the draft with a few colleagues and below are some general comments on draft-swallow-mpls-mcast-cv-00 and some editorial comments. Ben --=20 Ben Niven-Jenkins Network Architect, BT Exact =20 General comments ---------------- 1) Section 3 states: "3. Connectivity Verification Bootstrapping Bootstrapping is accomplished by sending an MPLS Echo Request message containing a Connectivity Verification Session object and a FEC stack which specifies the LSP for which connectivity verification is desired. The next section describes the Connectivity Verification Session object. Subsequent sections describe the procedures for the root and leaves." Which essentially means that Connectivity Verification is boot strapped by LSP-Ping. I would like to see an option whereby CV is bootstrapped by the signalling protocol. Architecturally, the activation/deactivation of any proactive defect detection/handling (i.e. CV) should be synchronised to whatever process is responsible for the setup/tear down of that connection. So CV activation/deactivation should be synchronised to either NMS/OSS provisioning or the signalling protocol used. This also ensures that OAM activation/deactivation is tied-in to connection setup/tear down wrt time, so as soon as the connection is created the OAM is also initiated and the OAM is stopped before the connection is torn down therefore avoids raising false alarms. The draft describes how to use LSP-Ping to bootstrap CV OAM once an LSP is activated, but doesn't describe how to deactivate CV OAM prior to an LSP being deactivated. This needs clarification IMO. A more subtle observation on the current approach is if we setup a P2MP LSP and then use LSP-Ping which operates in-band wrt the data plane of that P2MP LSP to bootstrap CV for that LSP, how do we know the LSP has been correctly setup in the first place as the LSP-Ping bootstrap message is being carried in the same data plane entity (i.e. LSP) that the CV will monitor? Can mpls-mcast-cv be initiated by an out of band process wrt the data plane entity (i.e. LSP) that it will monitor?=20 2) Section 3.1 states: "Discriminator A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems." I would like to see a recommendation that this discriminator field contain a network unique identifier (e.g. source address) of the LSP to help with better identification under fault conditions than a possibly arbitrarily generated number. Also, is the reference to BFD a copy & paste error? If not, then further discussion of how this field is used and how it relates to BFD is required. 3) Section 3.2 states "The Refresh Interval is set to a relatively long value. The root MUST refresh the session within this interval. The root MAY jitter refresh messages but the Refresh Interval serves as a hard upper bound on the jittering. MPLS Echo Requests which refresh the CV Session SHOULD be sent on average at approximately one third of the Refresh Interval." However Section 3.1 defines the Refresh Interval as "the minimum period before a refresh message is sent in milliseconds." There seems to a conflict in the two defintions, where Section 3.1 states it is a mininum period and Section 3.2 states that it is a upper bound. Which is it? 4) Section 3.3.1 states "If the Forward Defect Flag is set, an up call to any registered applications is made." Is this up call supposed to cause any action by the application or imply any consequences? It would be good to clarify this here. Also, the term 'up call' is not familiar to me and is not defined. I assume by up call you mean that FDI is propagated upwards to the application (assuming the application support some form of FDI). 5) Section 4 states: "Forward Defect (F) This flag indicates a defect upstream of the LSP. It MAY be set in order to suppress alarms downstream of the LSP." This sounds like it is an FDI/AIS type function and IMO the description/use of this field should be further clarified in the next revision of the draft. 6) Section 4.3 It may be worthwhile to include an expiration mechanism. When the root node stops transmitting traffic and before the multicast states expires, either the root node would need notify the leaves with a "A" flag or the leaf would need to expire its probe state as well upon expiration of its own multicast state. Editorial comments ------------------ 1) Section 3: Replace "Bootstrapping is accomplished by sending an MPLS Echo Request Message containing a Connectivity Verification Session object and a FEC stack which specifies the LSP for which connectivity verification is desired." With "Bootstrapping is accomplished by sending an MPLS Echo Request Message containing a Connectivity Verification Session object, defined in this section, and a FEC stack, defined in section 5, which specifies the LSP for which connectivity verification is desired." 2) Section 3.2, paragraph 5: Replace "It this is not possible" with "If this is not possible". _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From alumnus.alumnus@cutey.com Fri Jul 28 16:09:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YeS-0001PW-8R; Fri, 28 Jul 2006 16:09:40 -0400 Received: from [213.200.102.242] (helo=p33i.oouo4.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6YeH-00009B-Ae; Fri, 28 Jul 2006 16:09:40 -0400 Message-ID: <99956583289799.5EAE57A67D@Y1U85S> From: "Karla" To: Subject: up-grade barbarian Date: Fri, 28 Jul 2006 22:09:08 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: mBlBZuYJ5igu3ebsvV8ao1YIvr1ma58Jliht Content-type: multipart/related; boundary="{BOUNDARY_RELATED}" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f --{BOUNDARY_RELATED} Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit
Know what to expect before you connect. A sly rabbit will have three openings to its den. Curiosity killed the cat.
Nah mind how pumpkin vine run, he must dry up one day.
If you lie down with dogs you will come up with fleas Finders keepers, losers weepers
When alone, we have our thoughts to watch, in our families, our tempers and in society our tongues
Adversity Makes Strange Bedfellows Least said soonest mended
So long as you do your best in life, whatever happens will be for the best
A chain is no stronger than its weakest link. Stir With a Knife, Stir Up Strife
Love laughs at the locksmiths
Teachers open the door, but you must enter by yourself In April,a youg mans thoughts turn to fancy!
--{BOUNDARY_RELATED} Content-Type: image/gif; name="gw2br0x0p.gif" Content-Transfer-Encoding: base64 Content-ID: <04I5ELHJPLSATC5W5TZ5> R0lGODlhwgGkA8QAAP//////zP/MzP8AAMzMzMwzM8wzAMwAAJmZmZkzM5kAAGZmZmYzM2YAADMz MzMzADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAADCAaQDAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2y+16v+CwWBwpm8/otHrNbrvf8Lh8Tq/b7/i8fs/v++9Uf4KDhIWGh4iJiouIgRFjkJGS k1FljpSYmZqbOJZTnpyhoqOhoJWPpKmqq1+mUK6ssbKzS7BOtrS5urs5uEy+vMHCwyfASsbEycq0 yEjNy9DRpahSz9LX2JDWRdvZ3t9Z3UPi4OXmt9Sn5y8EDg5lD2XvDggO8RHv+PgL7foR9/MIkKiX DyA+AgThyfvHb95CdwIBJPQHEUW7gg8dRLToTqE+jRI7QqC4YN0KckFQ/2YjMDLCyJcuz8Bsic/B zJgt+QEQuKDMzZfvfsoLitMMvXpFaTrYaSLfzZguW7pDIAKp0JpPpW40aULlD6/X3C1gMHYs2XwO yDJYaxYt27cMAjLFp7buArdmzcaVB/dszQh9xx5kutGd3bWIx7rLh48g3LZGAzOwREDgVq5ge2SO 5qDBgQGgQw8oUCbBZ9EDDiR416AAatCkNVYWgO816AQQICSwPcBmbdsLC5wGfSB25cokfvN+XaAB PggOeOMu4/o1A+jHmXIdsXlH92URElQXfeBA6eGhVbts/bp4GQTHlaO+DoEB73nR2zMen/798Y2A LddeAgl8JJ0Z6IU22f8CCMCH3HYifNdLOhCWEIFntpEWXoKpFXghh6m91yBL+b2GWwP22YaWdC2V R56GDToYkXyogTjAdCWihlt9tnkYo4wVStgJhRWOUB9/xJkXgQIcHqAAPuzVaICI8NGoYG4pvtbS AyxS1x6VlQUQYZY12uhhjqLRRyZxTzrA4IiWQSjkDXMOUx+IGiqAZIdlYFhmGQu8aSVoat730nJK KvBnBIHCGSGaoeH4mgHOQcDbdUyaCGijjspJJDpFFsNAk09uOGmpUaJW6psIPAApoVjyZhSi77go moesPhigbfRBesBIrw6A6Z7Oucnpg55eEmoJEKRKXp9NNsAaiEpyOqj/sLHaBp1LAjYAgaLkVfum rsGWailqzXHLawMZyhPouJeZVGcN8wZjqqZL7ulkn/oWCAGn0F3a7JqhrbjcdRw++S+8Y3bpa7HS sVtjm+/GiOx29c6Q8S6d7Zkkb+p9aJu4DV5bqLYxCVgAk+gZQLKDjwrcLHPORQByj8C+y2B2QX7a xMa6AGZjcbyl29lui3LqjswEg2YwyOUhuSrDAOxqXbaiKQDxzapummu88vr8i9gQNuuxgKmhCiLF ggZ78mu+nYv2l4xSfa2A08k99wDxGNsozz0ruyx3pu09Mb89btpgwLxijdqshqfHdqeMRz6AAsBa /s4DnMIcKtAwgE5L/8dQFy2tyEm3fam3TfeWcntov/zg0ntHPZkZlv9aN9VFiu6C77IIDTW1qHo8 dYO0X80jyu+0ZyNxGh4bUfJzK4C5gZEnUDPvvZN9jPdcmW1bqZmiq/bIDKne+PJwy0Pz8+UpDh9T leu4hljqvqYA0jXuAyfYYRPc4KpWuEU5izinO2Da5Fe/NDlONDHhko4887zjee5apTqDWAKFQXD1 r26e+xz4nDHCdZBOf2Uon2hWBi30gRABJmPdfV63wgY0gH9/MhblgjUdnfkwf/Pxk/2OEsLAfaKE 5xAevhS4rwvpS0MfMdkDQyMVE9mwdZe7HwzL5TUfblFgIOphp7onwP/B5ct5KeQQpaY1MhvaMDfX 2pEHH+eT9mytXRdyow2f47aR+JBVUmRiqf4nwjIu607jS6G+ijcyAjkyc427oaz0QbMyEM8ljnRk R3jox87FqIFXEuKtAFXEZB1xgCM44QdFCZvzoS1d9ypTI7FHnpqxkjhlgBsk8dUoeBFAiuxDDbAI acRqINEcSiTPlM5YowSerZYthN3IgAVE2NjSY/5qn6t4MzVfXkRmeksTKS+GsWMSAXixEB8Kl8Qh FqJOZcXCB4Gedxt/uekf+jud1dKjpPbFsZPEjCOC2ugmYpbTkJ8rYLj6ZAA7Ii52zrmLS1Q4susZ y0pGqyZoFKYl9zX/7oXIwuBAK8k9zJhzHCf9xh4YAwc3dcQo0LGJO+4xlECxFA0vpcNN1aBDIAGA JvdzQ0HHaFKEFgmG98tpGqDTkzhsMFA0jQocjeI3DvLUWDv1RxoW04YNjhGpV1UqTntKADGZ0pio LAFCGvTHtrYVAQxyq1vhStfFkEWuP2LrW3sp1z/CNa5zLeVOYtTXvvr0oKdMqwiOQ1e/xvWvfwUs ZPkaWU8StrKOzSthvfgmvj7Ws5KtmM5+FKcRVGaznG0sYFkl2CSmNCWv/QZjNUtbttb2R529rW5v O9vd2ta2udUtay12Mcus1be/9WYx1RGNi8QELfRwiFbdtNjjSJSn/8O9bh340Vvc3pQx9FirdjW4 kDUwIK/j1WBrT5tV/9UWLRoEyUTAWxJloPMksSUFUu6wFIHs9w38KFke/vOf/woVeXggolixexkD d3VE8AFrUrsKwKDl1wf35YJYGttYeXA4ru/wL1q4SwKEXDe6u/PsZFfbE9kQGKxvUisBrKoP0bJY tJEtA0KMQmLTwhUtVPGvURokYxqH9yKh/euQPwtXypSWFxlOQZS14A6LAAoFd5kxoCo8AqTkg8tS jgCBd8woFzQ1AlSRwT7kAead5IMqSAUJC5oqG3xY+T0n+KWLtQPlC2vGz6VYygmQWl8T9KSpaTaz GdpcDDTL6Jdohv8BUhndFTMkugUtRsqlWQDpKgnaBGBFwTt8KYwpN5ozn1brlU+wgG0V+gVv1pij HTRqNUfa1mWOgUNe7QI9X+TOvF4slQ5rYaPaK9UDWbWhzcARZHdZx7Im7Ts2vdiKVJraLWB2nqs8 aG2fYCqiZpSduy3mb7sXZpQWhakrjWoUEBrL8oD3rStdVWxL5Icghfayc12CeYzW3fh2tggQjYJ4 s9rgy56Hu8et6t0R116A9k7EN8HwErz74BUnAcHNDdRgD3yrx8JFUz1+ZjN4HAAlN4q87a1wjAtc IkNZOLb9Lb1ST3xC7c6zsksw8pWHW2f85nkXH1sln13c4l4Lusb/u6j0EWy8KU3/eMafjXBVb3sf NYe4saH88qML/V8+NzfQTz5yL44oxAvv6ruijnKmkx3PYpd311U+aJJ77eFaT+wyuD3o+WH87fPu t8PZXvaKwanWKZBwfNcO+LGHHeqAn3vVB1LwFO+MnLlYt4VunompK5rw+oY84+Vt+P9tEcz7fero /94o0Jc77i5Pu+dTUHi85x2t0OB7DHqOcZa/0PWl51nLV5B6v8Gw8a0HvO8BX5PFOP8jMKD53zCf ec7TyfqUmP2cd770wJNg1IJqPGmRtd+TC11+wI+R65cv965qn/W2vz1z9/7yOfvx8YKvGHVZf/kG j5jT8rN/+6Z//8r3c+1nBh3XYjAAaYZHfdW3dbugfSNCevIGQOBXMshHVAmhFOb3cUQEfOFXgQaI cW6ggNFHSq1VbHqnDLqXbMCHf9/3QgL4ddJTGG3QgVQyg0vXUzrodHAHeXJnMRB2Zl0HNls0femW CpqXHNg3CbPndd1XgGIXgvBXRNOGEMfVZPTwcxhIelS4b+wXe902fBZ3cijogA+4gsnQglTXeDCY SjKYgUUUei74coeGPHLYg1IXhvsmeU9odGCShKSwhNzRhJLwh6AHHSI4hV34d/GHdqDmbUJXUCDY iPtmgbNHZ2mniN0GNgxIVH0GgbrAhlXBfT6YiT+4eUojh082bf86J3L+o4dtB0J69oYRgoq4+Icv Nw8GFYpqSAyIGHlpF2aAxIpbcXzktosgVIlbNIyVB4iz5xBz93KfiIazQIi3mHORSHixNmgA1GKr 6IUTuBWzhxApAH53kYevB2rfaGkWYW9VA33khomOBjgRaIiyFg3BCG9y8QJxZi3GKHjwmHbJJ44l I2cuEGfi4G+IaIdgMgzYGI/aiHSgd12U9o/heHALA4pI0YEUqUOgR1ZflpDQRYcq0A9r5ofnyCig mIa4Bx6S93Z3AWQqUHyGF5Jfs41uwmUnBpLiB2H5wCA1yRhrx2YnSZQc5If2dofE5pLzx4J6oDPg VVVKVW/w0V7/PDYufNZlQFVV46V6iqcGDcheVCWVLOWVZ0mVaVmU7qd2veiUr4CPkJBeVIWVWNdL dlkTZqdlS6WXWadWXsYGMWV2Kbd4NVgZdDlWjpWXfgl0SbVgZamV8heX13BaelVYqUVXehWUeOUo lolZneOAn2lTQ2d2j4Zao+WZo3ldhkVbpGl5fqVZmJlZTXmNchkDEUkFjHVjTBabsrlipumZg3WZ wfdkprUTx2Vjmfk/yVlZxGVcWaicqXlbo7VXpLVZmPVhLNaSzHCboeOdkPCZyEVbjJWFmkmeBCAA cSKemmWPJtBdRFdbY9ac7cln3XWe8llg6LVb+vlbwtWe1rgK/xGZm1PQn+P5nC/mW/ZooONnnO95 n/mJLBDKnMdZYOYJoMiRoPw5nweKoTYnisEwnyI6ouv5Ylj4aBkqYyRKaWMWYVhIYItFGCuaAi16 omNmnzXqojAaESvaow4Kl09AoFUAnT6aHZdBpPO5lSWGnDfKotVFokpaoU26Aj1Ko0w6olvJoyJ6 pVMKkeD5O18aCYL4nhZBGE6wni0wpnlmplFqpT+aA2qqbmHKAkKKBVzGo2mKA3GqVjewpzWwp1sR L346CgM6p4p1qOBhqCpQp4jaqIOoqGHmqJI6qRL5i5R6qctSqJi6qQOkqZz6qctFmTYgia6QBvF4 BoWIqhKnqv+meouq6qpMmI2n+gjehgpoUGnpQKqm0KqV6gmmyquwGiGz+qqV2qvE6qq1equ8eqvI CgrASgO7SqsU4qzSSg3TyqzUSi+QWnnXl6vXunmFGKt/Jqu+aq2fQqyWEK3Bmq7munnmSq3qWqzs Gq7shqvZGK+yKpHZKq77Sq/l6q+2+q04F66l2q61Cq73GrCjuq2npq3yKrD0WqwSO7D62q4Tm7AE 663C6qsXmxzGmq39+q/9Kq4W0qsTC68YG6nkCrHzmrER27HQqrEFS7AmS7LzChaeGrMPi7ARi686 ALIKm6+xCq8CK60bSzZGWzU7u69ES7JOyx0mO7OzaqyLGrT/J2uwMmu1Qnt9Q8uytFqzPVutfpaz tgaw7lqux2oLynqsuKptzNqsZhus/FqxH1uy6bqy+fq2p3q2GtsVdIutRtuyzzqsTOi2Qauueru1 a8tsibsGV0uz+sqz7ApoZIubrSq1LsuzFCu4Flu4rPq1cxu5I6u0e/uxn5u3oLu1qku6dwsLdzu1 9Rq3V3u6mYu5FEu3Ngu6r5uqhpsZlfudsqu4WguzOpuyoxuvLUuu97qzHru0ffuvKduxaru8rtu7 3Mqvnau6iDu8ErK9kpu6knixyVu8L2m54Gq7zLu6Dku16Su0Ivu8qdq+pHu+z2u1yau25xq/1fuu UKu99gux/2GLt0/LtZkbwPyLu9i7sCDasBmLqr/at8SLa4bbtQ78rUC7uw8bvueatAWMwJObrMVA wSD8sokrsR88vp6rtaM7JCKMthxrttX7suZrqaBawyrFsLFrwzp8wwu8wz7si+X7w0JsXzisuUN8 xB9Kw0i8xMFTxAPMxFDMCr8bxVT8qD1cxVisDU4sw1ncxZ23xerrxWI8BlM8xmYMBmV8xmq8BWm8 xm5sBW38xnL8lKI6x3ZcBXF8x3pMQle8x378FWAcwX88yLDVx4R8yAqsxIi8yD8byMDAtj+TqyjV wt4Kwc3KwRVbwQ0MtZrcwIyrt4Cbtp9srXArxGksyU8pl//e22iWHMAd7LykzL7Ri7ruG8Foy8mo 7MNl7DOvmrQcm6y//MLzu7H928uyjK45jMLRi78kjMlLW7PQO8vMu6u2bKtRm8s7vMshXMyHK69+ 66zzO63h7Lfsm7rjrLnK7MEb3MyPS73WPM3ca7ExrLK+LMg1rM3kLKznrLTYTMzFPMz6/M7NG8v8 3LzPuLghO7yo+8ATvLyRC8+lDKyhzMys+7WMOplBysvbHND9W9DczLgDDdDjHLBu29Fi+8hZ27YN /b1dy9IKq8Ij/MotTc/uzMT4XLL/rM8e7c88zboiTcrmLNBA/QKrnLurO7IoDLLxa8IxLcDDnM7+ qr/9bMP/p+yxqEzQQR3OWa3TBv3QYDvUJp3MzjyzFM3U7ezVK+2+XsvVUK28sErNP9zGvXywOn3S +vvUHd3VtyzUHz3V29vJnpzQlBzRIuy0D4y9vavBIA2w4avDeTyqkM3IVPzY9FLZkj3ZjoyPsRXI l62Pmd3ZoH27dRzapF22ilzaqM3AdEwnqf3HNx06PFDUtEzXvBvNF93a3PDZGw3bEjfTBgzORh3N uH2PRkUkcy3MWV2tXa3WZ926Aj3bzjzcQAoqu43XkvzO143VYt3cFv3csMzZ0v09xY3TPW3Reb3V Bw3Ys+3Qvw3e4Z0Er23dVo3N6K3aSW2w7H3JyPreQLza/1wt35y8zzst0oY91vgtt/5rz/wtp+Ot 1wAu1Oht3Ckd3EutzMK94FKs2yq93xweyyANytt9uayawPOs4Bj+xYbM2idu0xpuBO694l6a4pEN 40dM2TROyDZ+467d4joO2jleCj3e36PdtkIg4Y3939B6Ep4b5NnH4w4OBMa93Ku6v+fN5Ifo5Egu 387d4aWLzAH+wp8L11at5NVt5WiM5QSe3T073znt4NQszmFtt2Sez2YeBvHN1nhd5Ve94QBtznmu slJW5nXuBXcO4GytrCFN3nk94MMKPkf+37c96IDu32k+5lWu6N7903Iu5WSu0Ysu6WdubNcNuXge 4G3+6f/iDOd1XXAcbdAvDurZhuYcvrf1Dbu5LOaLTtK6LuVv+64n/OqwnsNDzgzBrgo/zgnAXuws fNrKvsbH3uxZ/OzQXsXSPu1RXO3npGbDneyhTsODO+NzzsoOLOgY9rNJjsfcQOe/cw2Fbu7Z9u6f Hjxw/AvaLg13PtTA7OtTe9zAvdvKHdD4G8z6Ts5HPtFfTrTX+sHi3t1cvupnO+sQf7RcTteNa7r7 DcnTHcms/s15a+inHuGBvuY7rer8DNZIDr6YnuccXOs+netsjufaHfLeA8Av79P9jAvYzendWdzY 2vLlrekeP0L03dMpP+qoTuAwH9JGf/KlrudPbt4zn+X/yy02W13rVN/qUm+bDZ7P2T3uOP2rOp/y Od3YS1/ybEvSdF71QU/wU2/ppQ71C5/lFZ/CKv/nkD7ijR7j3h7Cz+3nQB/l8Z72ie7ypk706k7y al/2gH/zbl/35i32gA/pbq70bX/pmZ7EQRzvutv4ft/3Wh34dm/NBJ30ha/po//5e770rtv0dV3f MU/ewmzSiE/qNi/Dt57zp77z3o7oR5vvvOvJd531Q1/RGxz7u07wAU/8Jk/8aS62rMzoXo70iz27 fe6uZg/c03/34Ov8WS+gsk6ncqLi4k/on1rt3B4O42/ZrVD+3x/u4IDxdProYBrp6k6p2G7tS3z/ +F/j/+2//14MAlEEkKV5oqm6piL7wrE807V947m+873/A4MmlzBHLCKTyiWz6XxCm8eoakq9YrPa Lbfrs27B3jG5bD6ja+LsOu1+w+PyYPtan+Pz+v37HvXzBQoOEiIBPh0WKi4yNp4kSo04TlJWLkIy YVpucnbaSXppeo6Sln6BdomarrK2rqgaorrO0tZWyYbh2u7yrsIW/fYKD+sF0+kSJysTGgM1L0NH syFjPUtfYy9Z92xne3/zdO+I3z5Sc4qJk4NriZybk625u4fLwtKTvB8P6cMDHKnrZyiPQBjUCsYQ iDDfQm3IADb0dwpURCOoMBGB2Kgim0zOZDRch0Mexf8RLjLO44eS4T+TLkumHNIyH0N8K2e21Pjq oqR5PFf6nIkv502hL1nqDGq0Jkx5/0ocfTo05kWpEFFerfKUps2cUKda7UnPJUumXLHaszk0IUdg D0sSJVsW7kmxXpeWhYpTLl6gFPO24Ilz79e9MJHSTWy3bmGNQQEOTrc1MuWqlv/ak/kXhcnCZ/VW tap38s3OoDfjCh2yrRCSVAUDRuw4sefRJyMvlruWrU++YBjjbkwbsfDgs1Xyqz16q2XNzkE/Xy6V Bero021PZr4cs/WenGVmB8l6X+DiX5X2vkt8/WCaQuP6xZ1oSl30j+3mrZ/y+HrgvfmaBV9q2EFX IFf/3YWXnnrgaWfgde6ZBuF2p+0H3oAE0iDSDSSZF5txU/kW4iPntUfigifulNxvw+mEV3Ls+adb arqM9Q56CDbnYITuaWVOVzpm551qEx44IobSeafGeM681WF7Isb4YU1GekWfZ5DNdQ59AEKJn5Sn TcmfelZayV6CI+ZYpJq3ORgkaVSq+aCcQlpI5JxuhofnavG89ZqPV9VIXFLAISnWWkURpRxnsCkF n3zBxUUioZNuqdaf5/2GJoKJhqmnWlnBGRZaTQGJFJFUMWhFTHkatOQPGr7qKjutXNgJrEqiAdus 4NSKjqzc/HrMbrtm0+smt2YYLLHLMuthO8o2Gy07/8jOQK201yZjLVu5ejJshraEFM400CqaSznS fUHdty0s6m2KLxrxHbo9hqpqWu4ySF1GrUqkLqv0xvvnQes2+C+wfJ7L46v+jiOvwi/Y2zCVCm0L r8I2gjTvov2+YsN4meUbcMixIMwuaiDui7KhL50MaJKfhgZdGxF21pzKAUqIKaY1J2ngjmfeoh+7 iQ5LM3MqvwzzvKgiHarOR6eMlqhQy6otvyYDednSOUuYpnbV1Vvid9xp/XDBbeIY85pAa3xkrT1n RvamPxupZWUh0zi2ZmAXTPfBYzj1NY4jv1yn13Q6HbdBRe7YuLwzqus10KaB3DbXefL9uOCl+n2k 3v+lqrSvppxj2Pk45I70kMyPzY2qnm4OOabDcfZIOewWum5dpJKDbDve/qrN42F1f806djP+GLrj wX++d4WlC2+wDlZDrPqBvS5f5+uHP9wzuqbbmT3pxF98++/Rn1874VunivaQlZ9tfpwYD4g9+ty1 hvqG1puadXSiv+9/iIvf69YXPboI0Gx8Y9N70ge2mOUNT+170wTvBBc5kcZ7GZSfqkY3OOi9CVrU 0xfApBYg1TBQaBBCWYMO9RMssa9ut0Gh7/JlKKhhEH4EatS/VIgc2czONixMGlYIOBZP0a1Rrsvd BuGGs3qUjA/6wxYVlTDCd0mxilrEwxUTNodVbTH/jG7oYnnEaMZrkXFjZ1wjs9LIMTbC0RtutJga AjHFOFJxjuVyWtuCBUaJ4TGQ+4siwPgIDMvVUZCKTBYhm7e7HQLqM5sJ381EE6lFYvJqobDbJB80 wOVNsnLeq18n75hJYunRWfczXJt4hzkm1s+Gp5xlGTfZsct9ckryo90uV+Y4RNJSkakU287K50kP 5hBzH5zfyIKZyWEGzmelDKHuWMU9BG7HlM6UozbFU8gbTnNMydOYEoeYIAZu85TQ7GZC0ulOK7JT k1yI5zufSU8ShqKe+iSPLffpT0as858CLURAB2pQKd4TiwddqBwKytCH9iGhXoQoRcvg0IpitJ8a /80oR5/VyI6CFAoXDSlJI/HRkqLULSdNKUtPsdKWwtQiL40pTRkJOInW1KAjzSlPvXnTngK1WjhV Y1CLqtB5DtWo7typUpXK1KYW9alQBapUo4G8RPpiqUml49McFbf7gCV9Zzoi4f4YmDoUzmOcmtxr uOSoS8IVSc6Dq4L6EbGRhK56kXwivpSH06dmrnvK9BwFv3c5tplNlt9UKwUVpz0yBfFn8Itd7IJY S1XqVa4l7GVisdhFwBLWsYp9W9jip0OGXaprfdXcYTuXS2N1dkIP1J5lm0e55PGPeVq5Jq6KQy3Q HnaVcNIgL3sn2GYWcmhprdapkMnK4g7tlsc8G/9xgWm0WHY2nIu7plkvqx9tAratuGXKd/t41iUm rrvAbKECayS6S/ZuVWll2aiKqTkn0pWHLCMa4+4r3bVCrHzcLe+WiAnPlUrOZ6zNbnRzdlpD9hC9 0ouuK1krtwBb9ro7RO6EEedLXtqpw9PkXvVUFE/ggni6FeTf+TSIseQWsLoMqzD5LozareGvb5Z7 MTWPJ13dGtZ/6y2w1VCMQcWOFsbGRezkGkyz+a63sDpucpCS6FzsTreytV3xBmMrZeLaj8T4NMwb mYRg8ZaJvJKNawQptDs099Gc7PUy7lz4QnCaGM7kXWynnBfWG6/QaOdd2dLss1cA70S+aTnwT13/ MdStzvOQInM0pDFrq1TMQoTTA1elDczGTv9hIKjs9DCnismqmrqmqE51TFfd2zLnaiGlNnPFYpW/ T3j6sk4I7x51jdk/q3TMPvW1sHtNa2PDWiIzUxaiMmsifkGCerzOdbITHWWZFvt0Nq22S1NX688W xM7D3jYiSN0ke7mMLIQaGxFdBsSnGbo0it4PoeMK7z+uCGZReWJsGIM0Uilb3fHJkqVMSOALgsmS 5aQ3Xy31B3MHTZRdCtRuhTQco+Dngi3y98U5LkR6NbvfLMq4oiJWcI2XXDGC6jh9K+OlFn1GNGLy ONfWvWuIn5WEYvL0Yr7kohXlhzYzF/iiS0zM/7v2xUsph8fQiRp0KTW9Ui/aeHxz0yGal0PaOG/X vSjuIp6b6j8+H9XLhc5yw8Dcr85CepTQvhuTn/2ttaEUmckOIE4hyuY4xDjDV851vWdi60xHON0L DHK9R13jhBf41bkUckilo+hJh5HkKT92yRfe6mKLvIxM7LCLz53x8AK8Q86cJfN4ncypWneXGv90 v/fH31eikeJ1zZ+BlwjuqKf76FuvyycBP/Y+orCTZCR6S3795qYn+Ke+3mxGzbsoZDeRffYcJuP/ 5O/D29mHVT99tfOe4gpS3tNBZX10l337zazv9d3OfWoHe6MmvQSo21h/Krj62FlE9kFnjetGF/+L ej2U/+Gf4LEaVRngAfJU/ilgSTFgRJXeRHHR/UmaqDXYFyWgfb3a6SwbBx4VVzGJAHobhHFdPqkP XsFYcNEVUi0fnREbtsXCQUhU2mkbCSIZtwDSlhkR+XgUAPZL99XH+fmJH7AfxwHcxlSK18WIuy1F 2g2KnWne+JmFWfUJZryc6uGd+1HN8YjXbpHf+xzKea1V5/FTKjRJwN2F9CkGEbbeyZGTiFjepHyI EmIeHK4hHNIWkxlTaZyeBXWSArWWBP3P3ACicuHOXJQhC/pa00FK8umc2QmHDM6e6wVh6D0JwqnZ 63meJfKgHhZQY8nWphjQKBnTBJFYdSnRHob/2N/IX7mI3aBw3909om8pHuf5yenJmxrmniwyYnoY 3uaVYmJV1gJRCFkV4o0UlhQKFzMRkIUho5Sxohl6ES/WnofMRxtiYtFUY90pHR3u4uad3c7RICmu H20RI3Th2GMF46AJmDpiGCquIhT5oMW4FSwCxt1xyHE4xtJtIgv1z89RI+1RIugVUSeGmTmCkAWt D8olU5BJU5eBWY0hpAtuoCKyoxCGHhBW3hgOYS1CztRRikfaV74NWlOYJD4Cng+l1hg21/2MUxZW iWopTWmRVU2mnAuxJPrY2jyaC6U1oEhl4DT45E+W20zBEQEuYFASJUs94FJmVFM6ZUVB5YIB/1pU HqVSIlonCsiEbZpVQoNUAVkzCqJXXiWCRRxhCdheYd9ZtIz6kaUvBGWbzdnsQEbZsJuPKdhbsoKR aZaMqY34YA1epphekgJfZqJY/qVXCcz2GBph7mVcXqAKCqKVyVUA/ZdjdotSniKDVaYootMAqRhm ZuZMRR9aTuYJDV/LBZpbiqavGCUOtqYyTGWkxaZsYmUaUGBttmIP6iZGzWZvbtNvAmcwCedwzlJx Gqc9vWZy1hNyMqcw3eZzvpNzSiceUWd1liVPYqc+Xed2nlF3eqcYgWd4btF4kmcVmed5Ykt6qqe0 sGd7Nst7wueyyOd87kp92ue0RGd+Wqdmsv+lL8ImHKDfakUmV/KRXKYXD8XDZS6OgRZoV2Ybb1Kl J8YB6iAEgjpoDDHXuLmiDl6b/vGfh7bTRxjdbgYih/VBElxoga4oijLoBwKjiNJT5GEVCi5MiUrj CRrW26EVWIShNkJQGh5R8/0QW/Lb7+Gb+szM+vGo7aBTKw2WDs6bviQm8tFO45Cki6FfnNUlunEl VGJePO5hKGkXmZYO4VGSaYbSgyod8dFlNuVHYLpPCpZibvVl3ohWmZLjlwnjIeokGy5naZ1oi2ml i+nklKliHsJjHprXl1pjoa5jzRWih/6hsZCj9cwWo+IXTUZWog7ZfgqqaVHpcS1ZQiLqJ+L/Up8y KmfqQ82MKpWpamD10IwljkGy6oZp6qHmnPSMk6HiqEVu6J0qqC75aqlKqqnSECypKlpiqiZdlaiO 5QFpKIpWaqeiavu05Utu6vA1449o2ZeCqljJGKHmKqwOY5I52bKqYLNimGZ5zp5i67QiUrVyqprm JYudapBZqqe6IJgO13GR67uSal+6K7R+68DW1h9eYPAUazmuzYG262kZq1/eK6RCI8IGLLRGqFDW qAQpbJXFacj+KcEG45ryK5dlmItGqa4wpLoyD2y9KWcmI8W6q57W6cVE5JWsWKuGq0NWmQyyyb6F RbtUEA5V6e8h0a4KozJKLIUZY0xG62mu/2bREC3SVq2kyOxkZmn3JGG32mShgI+lFaAZ4Ct/WgJ+ duyHmu0goC3B2ODaKkLbwq1V9ezclmfd2i163uawiuiI/qPb0ukd/Qe5yJpphlq6MFbfIhRpvq2N qmzktKsdKO6GBExuOm6wNi5FaifHsmgFPm7H8JjkTm7abqjlUm7iZm6G5qiJgmulkonUENq9QC7R rtkLcauRihXYlmDMQW3BChop2SWwZZCdamtXwat8LUj27S6KFClj7iTr8qrbwOmx8qnMStxY1ez0 6pD9lOw9lpwsySoMpVnDLmtd2ip13Wn4kFPRouwKJWJPWhvEYiyimmzEBuy26mvBqhnDzv9v014H fu3rWAJwrXoq+X6rAROwHk6s5pIbsL6qNeVvQtYvrUZwvvavvNLrD/Ev8SxXzkrvRPrvJz4rvBKr RBqQAp8vs9Xtom6lCKuvXiFvvOIsDKXqpJZrGq4jltWQB9dwKO7v58lwCaOvEC+Z2E1MAtewCgcq szYq9U4wn7GNoE2ooWKowZ5vOvZXcC1wELdq9tLrpVrsuK5iAB+sPLJuBLXZFtfvxwqqKF3siYqW wxrrEGPx/4bWFUsrwIZYjhVxufbxCYdwEt/a5upx5kzwppZpwk7vzb4w9qZsIxPG6i1sS46eQ27v +nZvodTcKF3hyMbsrP6pGI8g9Nqb7DT/Lw0l4+06bJ+VbJOesMCQZF6B2ZMCbPgm79UWmp3q7/Mc BqlY3F+6xrMpbZ8pMSHHJyWYLn3irRwhc0rJrSkgpbig1DPnLTFQczULwzVjMy8gp91wUb/e6CQk c+Tq6OWu7jmb86q+KCKAM+LSJomeLYSeQTcDD+biXztzgwnCcyW0heWiGr4FreEAab3dMpEO8y1H GJZmcBgKs9BGhSu7WVaypCv3iSo/dJfe0Ck/CtdiiS+p5dMWNLJUVZAiIq7+q8dyIgR7crfOncCm cigvsvjGdNZ2cpcdMUyH7MalKSXHmJtS78yq7Sijc8YOMQuz7/EqsjsS9QArNRyj6wcj/ygYv3IF o+oBRyo0LtcYr3QPq+h+Fm9PJzWsRmtUa3EYuzT5frBTG64QDyompzUdW7Fba7ANU59WR+37SmjV ovVcruRJIvWB1hVdezQfB7ZYw/Vgn2xdXyvMbjFXI3bUKm9Wn1MHU7Xg+qcfN7WOstjLsqlgx5YU m7WiqvO1XjAKW2uVovZmAXFTX/JLvzXJEPIcS3UXY3Umr7KDnfYRf/H8HnZpk/Vih7VjZ3JjHzVX m2tlB95LsazOlrRc7ql2qbRrs7BMO1AjUzcjV69zP/cerbHv2vYTn2Nza+h7kfRdgyj8imH29XKg La8/2rYqI3RFK29ZAfNlHO3Pjla+1f8Qfle0RpNsK78sDfPy1MIuKyNtWD7vUDvTOIOUNhfLeTo4 NjB4R0X4NtNChVv4UJJyhuvtEoOkpP2V9lHMhNpzC+dggooglabZ4w5oiodzrHm4rjboiI54VZJz lFYla8DWxwgkEmcM+5a46rqzgOItG6+zIfrtkTNoFVurPKvrIDndk9+4WM745+4zBBqzOI3fj8Yb kqdWaXLkVcFs8TS5Faa2Ic33Jcdx1tp4RE92V332xMQy7HxtNiXUSEOymR5qiwo3Si9yo0YTTmf3 lpmsmjsXKFd5LW23lLcvSZ/rcY9tbPPgbovpj9+0qWosoFOwrko1cqH1hdjyg8roRDL/qxE/LBNL sEsDpXJPOnIzcHArtmGPuRgnsmjjOGYf4x2Lug0+OqqDLlX/d6GnboI7sF8hMh67eHvP9fAy0a2v da1DNaH/MIjxsbQneboy+0vicws7955nu9axuk8Tt5UvWKni66zT2Zr5trUPTBpfbNnSaQErWYCx cbfzqZEXpaST+rgHNan/dKaXL71fuiDLbxRHN2gz+ot2+hyne21H96ki/IxiZXfnuf5G7ra+V/XG 6A0mF5oKDw/XMppzvLMnejiVN5OvtKMzN5Phe1cbJUO/ue4CmF35Iy+bH9bC8oMlsNBCLfJ0F9Vi u0sOq5Hrl6aueCw+KWuKG57RdzUs/7MVZVopTDhcxrhHOJrUa1XVl6fZYjiHU32We/16Pn3Y6+dr UmHPKd9tA66QB/k9Uw2BJrzC73qAjna/W/k/I9mMdu7ptjzblnWis/3Uvy28z/2US2Be77zdn3jc v6PiN9S6lvzp7gFtT24/C1W4sxuANm9IK22S0qV+F+PQ+rdMqjqX8xuBSjYXnvRKEnMDDRe+IC/s b2mYm7mi+qiXpubl63u5Z6+gX3oVH7JSX7fJZ6oEQ3vhKpe7f/I2Kr/Limz79jZl/HRN2yyHorfI S/ckI/q6Di5vU/ZZ27qw23qoAr5ktqmsX3XL8zvDO/wfP/xeZyhYaraYsr9hx2qCTv//uqe6WP+2 pWslCABiBJCkiKbROqZli56uLLt2yb6xXes9PMv1TsQdTwWEDW/MHPMJjUqdx1sRSLOutteq8aeb jbjOrRKLxJGTXR+SRm6r4WupsQrG3WPCpHu/x9XUF1Y4VjcXSLj0d5j1FeeXp2VXaQlFJWaFxqnp 5Xn2+dWk2VUjF8im+iiaNmmXhyqZNupKe4tr2PbzWqs721hqu5n7lHmJXHmcy9pM7AsaDBgK/ccq vataaAIoS+0XBXaNeyo8DG44zVgeLd75bU26DcwI25uMr9LL3snvjN7vGa1/Y6j5uwNHW72Aqd7B +hTLy6lm2SQy06fN0zVTGPVw2pj/EWRBZffy5VsWJBPBQymL8eFXbOIQM1do3jKjj9u8Xy274XwZ TQsigO4cbWNREZQgoTph5kxJx2iRn8GW7mTZsuRIk1wpdf0KNqzYsWTLmj2LNq3aSyjXDnILN67c uXTr2r0Ltm1dvXj7+v0LOLDguXwJax2MOLHixYz7Fpb7uLHkyZQrW55y2G3ky5w7e/58d7PmSUX9 7ktbGh/pcIozp9v71TVj0WvbHpOtekpX3M9468bUGpnv2KBRDy9rm6fae8ePIzx7OrFr5yapF38b OPlCqlhbcF9qlarMqjitKn0jVQ1E9E/H71j4osxtpDmzyNfZHWisMmJMzC8XiUwz/0XkHW2AGWic MSE1FAZ/Cg303EgivQITfgkBs8pABOEnyUEITejPShdqFKGD/WwIITojWgcZi3mt9pE50MjB0TDr TPOaLTVFCM5UBsl4hlNXwUNjRkRi2M17SfLk4WvwNejSbC7GBiOUTALJCyFXbukka/H9aGSQYFaz Y4/kIImVU0Uqt+SX9GDJ45kk4tgYgmglV0sca4ZY5pY3vjTOEfYxZOagVkJSR403RaJceWESweiT et5USqQpGuUId4fmKKVgeCqZ459HbhrPOUBuYqiIgoI6jjeGnicQNo8SFdRqrdIap6nyDEmZndBV 6d2bpu65JLHEnJZqnLxAqeior/9SqquxwpIpyquifhPoqJdyupivZn3Kh7LiHrXgie94I+ehQjaq IY/PthkiG2t6tOmIlz5iorr37msRnZ1mB6wiWVYIqA/3LdpUfUB1eS99ONYz4FEEx6peVgWjYtPC 7Q1yq38DIyxxxL1F2e2Uu5nsWG7XAXRSZSivfLKnL8e17kMwD1dzcDDLzHNx5u3MlnM/SzYz0Ml4 i1zRRi/NdNN4IU0W1E5PTXXVLfZsddZab/200sJ5HVZqsHmZV8t1Es31Vn9JrZl0v5UNdLZrpx0E 1mcjxpxYYEPmb8p0hwuwggcr/BRU70VVoDPfOczDTx5bLJTE8FLhXuIQLs6h5YX/DylgfCpRTm94 FW8+jyAiO8122KQ1yTq0oCuBL+Dqpgapu6WZKC2KW1Fke+PuGgmx7vTulK+q9fZ9XeovKlhsrNIy PKas7Tx4UbQx2nhqs/M29GfCczor57VVEVq18lQyP226C6/LzoRBFd5+rdlfn+f8x7NJff0Yc3/q +vbH75CpmS9mu5qD4w6ICEfxKn8AfNgirDc9A/KHDuBJXyMaaCZEVfBd95uULh7oCkv5Qm5MGyBX wFUSV8FpPR2U37DQxKVV4Up82oMhBtnjpm2psHm64l8AUbc3kqAPf+B7IQvdV70Z2dB+Oeze/3yo DghaKB1IVKIUV7gSqpmwOgEz/56+AAcxBjYMIkmx14dyFUZC4Y5BZryKSB7GxnFJ6I28ux+3khdE ewwxP4kgXSIwVrxzbaxxDqsQ4yDHRyq+Lj+Pk6N6liWwCCJScj4p5Og0xhJIZU5TRtviSfJoGgGG bWWgbJonVVNKviEveWZj2WVSubRTHg2WNONkJ7koS1X+TW+09MoufwnMYAoxcMIspjGNmcugHXOZ zKRbMi0xwMPQUmzAeVszXakMjPTyhHYzTcCgORlq7rFXOxPnK7vpmG9mE22tGGc4y0kxzmyzbsQk JOI210jPtcqSkSScOyvXH9AxLp+ZLBjH9iMEmwxOc/phSk8+CKCEFjJjmDxcRf9/pinRLZSgdnnm MAVCx92J1I1ldGQ7szjS0MmujuxL4gVZtyFIMgSmI5RjlvhFvvZ5KF97mWdHRtZD4p3jWs8Lh562 l74qwqNaJ2UQtpbY1KSqEXlqUtET4bjK5fhUdv2qRv4uiMX+/ROqVhRqUDkWVV5VRFLxvJVZv3jH qkKvR1qa6zY9qsddeZB2YjSiB/s4VgnK9KlfbZAtFWg4Qfr1faKTiAjHhFKlMAqwf1VgS7OaoHp2 lbGLleodXVmUvBnxrVaVpDzeSNgniVVuDRReAVOIq7JCKzRbVdv3lkraZo2PiNwKrQvLekNqqnao 4YMg824X1qlWE4bSIypI04n/zjiWqLNYMIVrKQRUJ3mRpgucyBHhJd3hlWu3LcxpFHEKV++ya4GG iW53MhpI0j6yoRcVT1ov+YZF2nG+mLKndg/2MadS1J/vfSjxBlpJimHudOlRJGp76t5Qpq22bLkm KSmM1wqXj2Se4rCFe4VhCnv4ZrZsTYk/bJkMGxXFLG4xaFSMCRG7eMY0xs6BZFzjHNcYxsZQ59E6 PBYc661tnBLHy6SZWdpGmDoYjho51/lZuC0Xs60s4J3WFmJ3/jg7Tn4nlMEm2hFXh2yowfKS8QvY AmsoYQsVKuZC5Tj8DtifhmSzRA3cSPDAlz5vPiieO7RJBLpOzofU8yEvyVF8/3LSvqPwFY9t7Dvg Tbd3wzPeGm2rkJg+141gXBGlwXpelf6wdYQVL6cz/enWjrG0pPodJAh44z0WlXzkTa1xeagtXDd3 0NSNjnwHy0O3bmu3wZ2WW4UkPs8KLctWDrBvde3cX8d4re/zH7U4p2yqQjGDEdStTKNd7J5kMSm6 hjY28xrrZlvbHfqtNbFvvW54p6mw5NZkBWe0aO5Nls7mEDYavzovy/67u6tN7gmZ7TwLSsjc1JVe ca/98CIWdttJvOFvnEhWcF+RuJ6NuMfRBU2EMzWGrpbtuyHOcLY2vNbP26EOmbtxfzuE2tcW1bFd Ko1sw9rMNt7IP7ibRsOO9/82HeHuoqp7Rmybd7+KbfWprRQvWM1u6LuoYdPRi9O6fvLMC6Zko/jp x4zV+b/ek1fmGszfgiqdkSG0d+TG7mfS0ejQEIXc2ClosEBPjJBRejPIP8pzvwVTyDomcYTLTOVY irnwhX+0Lw3jeCxHnvFaFDnlL4/5O1k+85zv/M696fnQix6VhwcnlMds5YtXWcpQCTPqC4Ib11c7 yH/t8llBr9kr8/LxNnv9KEeOnHiC09djW7xw8GDi0v9edby3psqGzNngt3P4ZKaLOXeDfOls/qFL 6NwfDxexZXXfj/xlMGXjrs9JnjvOcq+Y6dCeSBxubPwGxSRHVQvQ/vqHvrf/h27uvxc7fSVqQtcf Bdh0dWVpm3ZpptZbwLVSyvVDpJIQ9Pd0FwIfg4VatZN0KbZ9GDJFrKZUVHQ9NDRq/aNxLpFR2WVr ELhcchWAcwVqdDUUJKhW8tSB7BJZCVg9AUiDJDRvPUZzVMVTMyeAkbVZNleCowVsEsh3NfhKN1h7 dXZdGQd1jxU98KMiIJRr1XQ7VqgoRlgf7PccPsdTJRV9wdMnvFUnUCg4dPKF8mYtsXWFCneCmCUL rMVxcCVr4IWHJHd2DNOD6gNiZ3Y5brh0KtdEFqRbdGhw3BZUN1dTtJZwHuh0uyZ/WBWIbeIyN5he irVdXCVpB2iG6oWBZsiA/9vhgEUYXlhFgOPViZfoiCIScITXY6UnhsFSfxR1dyxkdnw3d51zh2IH Mgj1Hwmmbx9Yd/c1YFL4Z9VWe3z0fg5WiXjDiXMzehOmY5P3UwdifNcITzmmjaDojeM4juGIaeSI jqFnjgyYju2Ieeu4ju4ojz5TjfNojywGj7R4j/tYMsrHj/+ITPUIkAMJTPlIkAfZTAaJkAtZTArJ kA+5Sw4JkRO5NRJJkRdZef6IkRv5YgLJkR9pgxq5jSBJkv/XNUalXlz0eEgxE+FyixK0O/pYkvRo i5TTHEamTS0Je2U4gRo4k9dokXUjH6OTKD25ODlJT3qwfx/kkkv5k0DJif8suT5OKZVztJJOGZOe 0yFNGY9P2UlQaIE92ZSdxhSmo5NKCXtJyZIy6ZUduWSRIpY7SZaRJpc/NVEQVR4n1paUF5Qr5ZNV qZRheZXiNZT3hGmAuZed15eESZWN6RF5OZif45JTaWoJlZiet5iSOVkJBJhHyZV5iViPiZVZeZmZ t5iliZpKZpKpyZrW55GtCZvf8pqxSZvMt5q1iZtRM5u5yZtfI5IalnikpHvPB32rR1v6mEqZOXvH cm7AiXjGWWSmR5zLN521oYIddVyptzyrOVyn1Zxxc3ynF55Bxk261I2hAWHcWSn3YR9miXelQ5RV 2Ad31l9t51ABhS+g6TH/eJdnRMl+4RGNDiZRNdJYGzRBf+ko+qkw3DCfPomFCPSebhckG+SfekmX gTc9yBYKEyR/VImLOaSVaKChPniWPlI/oPKAHNpoHcqEKJqI8RNRr/aYpfOCl0OKAadSANIKaegG Kvqd4niSZVlo2ZcNOuqiO1Kk6iN+4gmj2OOi8HmkHwqiJkopTepmLKovRopb7zJu56Gl51VSXzod Hdh9RSlwNBqgUyomMCky+wY7RvYdOmIja4CKYiqlHEKlqWAp9jafWKo4dPqIT4pSobmfdMen0YOn 7BVj7kWBPpSkXoo9+4Mq1YeKgwZAwGanVnqnUpohMsRufjqG32URQWcr/7C4pCfaqImqTOrJohb4 VFo6pHqoqmpqgF8HK6r6qHoKqrCaLROIXnmKq6EapdCzSQOnpl/6oQ90qsk6poy6nlFhXToFYG/l faczNHn3dq2nQTnJnlD6pvk5rUQxUfpVoPqpO/eGdIWIde4HoN2KrUhKoYgSZSPpf73Ze7DEltXH ZauabvaqetjpMzoTcr9Jm41VfJ8RYgZymv7KsPyKoQ0Lsb55mxFLsZCGe8The1t2Tp5RWxZKM19J iF6CM+X5sRjbLdn5ZcWpseKpZQi7m9kHndIJF0yGsCursuPJstrplrfJoP+xlvUXhpgCrkPLUEvp rnnWdemXKf51fpZZIP8x2aBCq3+JM6ANZqBwKqFFq6BXKxUQmq8Dy7MDKKO0qqsoGqwxCjsLh7Y5 F1DDqokauAhwS6OhdqJgGqVl2ENDmIYeOj45w7FsqKHeyiZn+yB2mqWgChyG+7YzJayb6kLkVlOK O3GBm6ul4rjlBLg7mF8YtbkJminASq3gt4xZOLpyBUUv2J5pCkmJci7omqimm3PSGreq+62xirlc p7lPCqmeOqnDqjiiWqVYurhf9LtS57ulBlaSK1+Cy6NmhYEgG7aUK7xIR2pr6rjFe72O5a0qcauT xizTy6zWm67PMquTi0NaSKu52pWfV68yRLptB6d5x4zfurQzRaigqFD/9jkwWftzJRKafaRJ8WCm QiehyPaSBsR/a1lG+8l/hjexAcuwXzuID/xiDSvB4fSyLmPB6pjBFRvBHezB9rqwIRzCI5yxrIR9 AOucrGeao8GojNZ7eENlQpNYP6phSEaeOTtEfovC54kZzmrDwWmeMrt6PsjCMXzELbtpQbyxWgXE 8jkVDRqhM+q0lKWgaNoUVyygWhunHxFnVdyus8u/+Pm0Vjy6f0QTehGHaWZQRrtoCcqe/GtoFLSk HrtirPq9FlXGImiTC1ernfoj2NWAPrpe6Su3hvuHZNKeZbupq+svcei3fIskHjqirXoRQyix/aqt jQy+IKqHnIrIutt//69LDhqVh6S8oijLyMwruLjFnHubuLMFyGR7t51cvqSHxz1qyRpUrF48ZwFC XPsLSKWrpNkrooCaykE7uNiWqY6FLKwyFEsrIJ9Du7L7ushcKD5Mr0H6Xc1cy/uCrM+bxxTnzZNs zOPMP5Vap8H7zThXq2X3XJG8HuXsyQTHwz+cy6BbzoeGvfx8vhwRPB6IyoQpp5F4rGBkq8tMML6a ljJyh3lsurar0P9MwJNptss6r7XIneU6oGvFZwCodnOcwFl8Z8NsyHrnIAZLtCEttGBXvwMCrSF9 QPE5ifXZUDB9n9L6rjIdrp2cyQ8bs6l5wQI7Ze17sSRbsC3sfNwM1P/V2ZpDDTBqbMczC8IknJsm bNURi9VZbcFVbXvUOX06LHnMpDRQjc+aLHhgvZxLvRxizY1MnMIEsmUzM01encM3u9b62tZILMMq 3GVmfcdorcftmotwnB5vLMWAIsxSS7+NnU9u3MbsSs1ZG6JhXMAVGsUt/dGN3bah47WOrbRsjMAQ WsZcy9lTPUsvzMi3HKJMCVo5WsyweqV6bDBqm19eZXGBlKnky44A7bZzOdC63Nm0nLaNHBEpvb2/ 8sStXMnDSwrKG8rUFsoiiri8JsvBjd3RCXXudrjHi9GsXbmJnL6tLJvLDZd8eqiwu9jQ3bl9CpMH bdCFGqzdK1nVjM3/+vTLrouLbpql952nxj00RXrfo60jA6zc+RzLu2vO7Hy5s8wqvXvOHJTbeetS Z4esShc7f4e96ey+9Qwn4py9gpw05n2+23vLET3Q3NvQh8jK3X3OFMfMFs3JbqslXvQ7vMqp8J1B 9MzQ4ouMurncZlzYDGo4Bkzk8voxlO198lu/xHu/tmWwlRTTAAy/gFbRZodcp81P8crZzYiuBZVA +udJW+1igA3XmDkYZN5iZp7RQJnmdn1MUH2t8yhias7VvWnnd37VcK7nqJnnHEvUeT02KbS+Yf1L fy7E6PktKcycbL3on5WcQb1ZJcTn7NTXja7Xjy57d8PXQETi8fnY/5xL2qFdw5CttPu30o9t02Yc qwwMP2l8oOco0hvqs1Su4m8KtEqSgv8paN8n2jSJ4BnO23Y5t7Fola0tydeczKwx3d+WWnJbzMIt gsWu4OAttqK2rL5tSmRqqi2+ytfc6o3ryfBMuA/R7DuqitH+3x/+Wsv8x+rc4dS97Z/+xeDL4/ZU 4+2837s6bUN6qZFTu29YyvcWwDDr4QeG3h0O7whM0wd/YZ++7Ce+y45445dI7rMdz4gryA9NhDEB VRc+K888vBKPztAr2NQb8a04y9Ye3+QNEpqqvT2OviN4yqaFpHYryldO3MStqQhW8m3+LyfP077r z9vKXiotupLK2P+0XowB7PTpan+u/skA/J/xN8VoVfC/fuIcja0W/eU7K/R3bem16TVsDqSq+Zyc jptlfbsU/EmFLnxPPWOI3uewSfd1z5p3j/d+XulWc2T7OrNiz3l6b7Iay/ZAb3rzlEcu8nc0RviM brOI9/dvHfh4/Y7cXrWaHcWIQ6e4CutHzuT9/rSdP8WjzvCUPSeEDX81YdhAuPmKzbQG+tJiXozw 2dFS6/MYrNoOvrYf+JfdnqyKSu21bdz6vu7X+aL0fdvDN+x9I8mxq93H+vLLP43UCPHjPvGyZeGp nDPhvPKsDPMJ/sfujtHmbu/iv7zivc7f/gsSrJyK3cvXi9yrHCP/Cd/uzrXbtOvw72xoC57eIACI IzlG5wlE5LqapcuiLVur4kyXshvfPlCVu9V8uyMyqVwmU8wnlOncBWHWV/VFzP6oWp2xWbwGy+Mr Lh1Ggm1Y9Jaolp7n2nv6je/Ju3TzXl+eXlShIdTUoaLUWh9g4COfo4mOW8ylTdhj3maln50QKJ4l pZynKd/lqWZppNFrq2VqLBthStZtXeAi72FiL3Dp0SsKpdPM4FZiMY/yVG4ycrKxZPMX8xAOs1Ab dzVccc8zNrQ4DSxVblV4+rE6TLk22LZx/Wo5ttdoMH96f/+vfwIHNhJYkNfBgVESKmz4j+E+hw8h SvRX8aIvjIKC/1HUGNEjyEIUO4ZcErAkPJQqS5Jc6fKlQmlPWsLUVlPGzZw6d/Ls6TMmzYonfxIt avQoUoxDVy5N6vQp1KhQm6Kkugid1J1BpyGymvUqv61AD3oFORTrTE4GVTYS60YJzW+IPsKhW7Sg 3Lkb2c50C7TWWzpxvnJdK1hkYZOG1vjt6TYvX0Za25LZJrMFMsv53lg2JS+VOWrD3IWbxUmzptIB MatanXmc63ekP/NgzZjcs1C6f4gTzZu2M0y8cadW7fttaODwSCcs6/GsFS5qlRH69FstpjLCrWOV tMxzJH3Sc0unLoqVmu2Qv6GdpPuYzfeTctcdDKt87/PgwAde1/93Mhs5eIKed7oM6J5pnewX2GBf NGideP0ZGGF16HGnDxkSIjeIcOrNxyCB0YiYYYX7oXViYinpBF0R2bg4XXqZTRiHOexYI2A7DmYS 3GwUTqOdTDrGSA+HgnTmo5ELeujZkNBwVWOBHGazIxZTjkjcL/5JtiJlulwJI4Qf6tgNg6LABSaN KW7EnomKiSmGmUJS+aOSd1STHYZrIghmcyKSJeGfcjbRmEFdlqjKdAoiqiWT+jlqJ5pLghLiKAqS +CikuBTGpoYwdpjpjHXAByF+fnbq5IEb7mVRTixeA1uD9NRoz57RbFaPctbIgwYQqAXoTTuwtfUd sBje06s/Qfr/dhmkjc5q5GY2gkZcgOsQuWtyxS63HVyETkQYuOGKO65Q3gJkLrnpqrsuUs5p5C67 8co770/wXmQvvfnqu+9z6HLkL78BCzywSQD3gi/BCSu8sIqtGpzuwwi1yvBRhCLs0MUhcftuYlt5 vJBdYEWmyMbsWrhQxCSn/JBLK2ekF8ZMSczvyV0BOMx7qDEX47I571zJs9Hlp+2LxZ4jLM6seXHk ZT/nCpzSn90XtDRVc4PrEE4GByzQT+/6IXPPYtZozzoTc8u1Dd90FrcHandol3hiGh98lp5y3YVC V/ppdELeXQt5/bWdZJW2nAaJsfxVCjfihRcpRuD7cPorl4CZ/3rohHg9TqaeRdqtp6Whftk3r6su Lbp7ZiqK5CabP9he6Bfep1jsfHZ7c544Amljk8eOmqY3q2Wa9Y6s7C78eFS6SF+YtbndafCrzMj0 hhYmaOXXsdumdfPEl3ip6butbWjncbaeeqx29Ol57ua/CTj0ptGpOM6YLy55m/dPHuankCUt+t1m l7+5ve52lavf5UKxuu/J53Hoc+Dz6AY61OVtF0DrGv2MFUHxoU969rOPLMonKcJ9QmuL8tJeTmgL SqkpY39BoHKkdautQeuCZFMWBGMYD6MhKG2pokaH8IGsoNHKWh48TtVmmK2rNYNqGPQaE692LBrW rIiZ4J5NcP+otpq4UE0Um9kXw9URl4mEjCgLSxgJkkYxwsxhuPNF2tYIRjk6RYuWc+MB6ajHPdKr i4XiIyADCTEz2kyQhjxkVPz4rcOQDBiEZONX4lif8CVyfG+Ek8he9kgEbpKSaOIYGj8ZkU5yBJMv UeS50jJHxHjyXhXzYkO8VcVRQsySeQyW2F4VxLrFBm2tAQ3Uomi1KgkRRcL01emulTWkLW1oTSNi 1MZmNHa8hpe7vM3O0hOf6zBTmsNkFhdJOag7bjBVbiuZM+dDmcg5Sm4w7Fp49Pakbf5QGHUT1ZOy MzgmMWY38iPhlfIj0H9Ks3yCYoo4Kdc+/3Bqg51b4P8+mD7/zVXnfafD3/usJ9F5MjB9KdxT8lS1 JA/V7qG2xONCXwQlgj6wgLrb1jll5DfTGVFqS+yo7XBUunYyr3Gji5VMsYM9Y450eEF96DBhgsqw kO9vnJMoC/lXPRQy6m8jqmh96plTN2UQHSer55226qBAWbBZJG0f6URZlYSOxnImbBZ2KMim0L3V FexzKzzxmVaT4tRZb8qL9lyHCpBCr1b8BFVfbdhKpbCVVTmCZm10KbVqXfF32AoeElE1j9g4I7P9 LE8UabhT0cqqVzMkmp2Utj3JBiuGZjXrab+5Q6U2dosauy0iHZlboyz1Xy3D7W4zGVzH1BYnMjPL cIWb3FuG/3O5zn2uxoorDOhSt7oEke42ravd7arskqHkLngF2VtHAsx/nAwvevuIXQ5+F2Tpfe+8 xnswvOSjvvQRG7VyiUz48pe43k2aPscUvrC+bVL9PTBzaZuWzzVvphBFMISbm2AgZjSuML0rT9cb 4ffKFyFNrTDwyqqfkG64xGZZr6vqqjwS/s6hGNSwia3b4avQ92hYGhNuBpvLV4Usxj728H/vCMsf E5kwM+5uG4dc5CVPBcVjzBOTo2xkJ0u5ygo7MhytrGWBYXkxMN4ymGNJ5TCTOV5dLmOZ06yuM59R zW4W45jfLGepsLmQc75zHeOM5z3fRc98/jNP6vwfQBM6yP8ILTSiT6roRDOaJX5uNKQZa+hIU/qP E640plN56UxzGsib7jSo0fzpUCdBAAMxNQkEgOpDrFoEAVBYqzWN0nFJkihfHgEDFJLrESQgAbzY Na4VBmxZLxqIKDalGpW8GOTWLwwJiDUAni0CaUdBAL4ewQEOsAhrT1vV1+7HsI3CbUvPukyvjJlQ VrQDapOA2ux+ArufrW1FjPvZ4/4HtH/ybqYGGZvAlGc3ffZZJlbz3978JW3025SokXa/OORbZ4J0 AGv32tQJyHavs12Aifc63q2mtrVD3nERULzi0x45ALh98QNsvOQk77i9vx1tAXDc5DN3t7c77m1r 59rlKYf/eaxL7muhv5ziOf94vufb75RS7p6Oa2lBo6RNewIWw3ij71hB1NWdvpgrLFc1twVQALCP neb2vve7Qf7siquaASEH+7XBLgC3hxwAEzc72N1+dpG3m+Zlr3fdby73tUv77XM3/L27DXYA0L3t Rzd64vft20u/FKtwdbHWtdS6EXoKxO8k4BEn6L6NqL3bipe55CPv7b7fXdXzHnwAAK/61tNc9aWf Od/tLneO913VIqD9vF+eatSv/ufCN/4Ly43ROF0+o9jL21xHCyWra1Wk0ZsswZ//4vuuG9WAP33f d6B61W884wU4uc5lT/zyX3zsxL99zMfNcvMn3ufzb//w//PPawEEIO7+P/51Ld0AJc6Imdv3RB8p tBNUmdI/XRXz6ZWAlQD8oVrMhV/K7d/x2d6qFd/PFV8F7h+7xd63iZz3XZu06Z3pjUDivVq3sVur 1R/xjZsMmmDSkZcATpVbLSD+aJ6XnJUEFeBBMZSo5BUtGc6DpOD3zVz/WSCw3Z4GgiCvfeCzLSEI rtraRWHgJSHOQSGuUWDgMZ4I0J3Mjd//IZ/k8RvljYZlSV8wRdZFeUpswZYN7dgnTYkTbdZxKAnz JMKwNaHbRRvGoVwYXiCw3VsfWlyvNWEC5NquNaECyNwfdpwiMiIYBhvjseCwSaKphZsgwpwlRhvK eeIgjv8i4/FfuC2S8m3XLB3FBpJcqtXe4qVaKWLgBR4B2LFgypmaLtbiBeab3KngLu6iKw4jL8Yi tMViLvqeCpKcMSJjK7piz4nZpEFXPyEFzHXcI15jAmQj+2njNWajN8IcOPYaOI5jOH7jOYajOZKj OqajO76jN66jNgbgqIHXrYmf3Kla7OVjPtIeP/4jQAakQA4kQRakQR4kQvLjPgokPaYiqT3kljgk RE5kW9UjRVKkoEXkRW6kY0kYR37kdBUbSF5kRhbMSI5kSRrQSXJkSo7TSrLko73kQ7akQsnkRNJk RdrkTcakTnYaTnZkT4LaT9pWUHLaUBpXUYbaUYZkUhr/JU82ZaQtZXbxhNGJwAAMwMuBXAFcZbtt 5QAcwLUFYsypXdp5ZcXZnNGxXLb9HljaHAmI5SZq3AH0XFtmHKrBZVWKXfBhW13eZVt+XQlw5Qhw JQNcJV0CHQAIplUOgLVp3CIm5gDQXxJc5diRnFcW3crZ5Q4oJmQynmGmXF1KG2deZWPOX65dpWTy 1lPWhLVVZmf+nFZypqqRZsoxAO2tnWtWJTCS5tFlpetNHOPdpgTe5qvRHHD63e6NnW0OXlUu53Ay JwP8ndkFJlYOJlYKAFciZ9695mI25uJhJ2O6nsxRpwGgWgAcgGCKXOsZwF4uJglkZ3Z+3XaOJmNe 3Hfy/+Z0quY0vgTkvaYAGAC1kaZb+mcBeBxaFii0pSeAeh+CQh6CfiJsrtqu6SZ9ip3HtdxaloBu 3hxZthp9uid3lmKFPqh1+qb4VVx6Et7OoeWAfuhrcqbbVWiLVueG1stqwkRzGmZvQmaNpqgL6maN giiQVlz/lZ1bvmACuGYttiaqyagLAoACqOUxHmn/AefPKWmICqaWVud7cimPzqiJaiiK0qiKilxu gmmJvqiXgmh3JqmHkimW+oRUshdPkGZbjl16ttxseqmPvuDG/SVgUqdlBiLG7SjMWWm7dZyVUiif 1ue7id1V4mKqPWhhOmoJvhtqdtyWgih7Plum9pqAOv/mYqple1on2IFl8QkokJLoYsLcpr5moX5q AoTqAQDoYm4ce7bLjdbEVcpntgnmebKfi1pbeZJAsCZnglbnsYLdggLpqZ6fhj5rmMponKJnZNri NuqigHZol8rdq6YnquIneHqnMtppsR5Bps5fqtbnkGJqeO4piOapp77ruNpnuTJmttXgfkaXUZDq 7/0pyYEltp2rf7JouyZrmFqoqjWozMlmw9LogrLpl6pdWiLqtDImieJdl26smlrmvHYrq8JqnLIl r91d3Hnlf4KcwHJsvFYnuH6sqaJpoPbZvvJnrXpfoM5sfhYsxbKo5PWpb0Lew+qfkNqck5agg44n k7b/KbemacsWLcwy7ZsG7HgC4ga23LWd57beJcFK7LeSadR+KZa+bMXsak08Jq8pYgkwgNpGYSJa XCaeIiimbbvl2jb2Gvrh7bqJ4rRl4jW67SLCbRTurSjOowSinq9pIihK4twO7jXaLeKuLSf6mt8u riAmKuYq7uM27skxHswxQP9FLs1aJI4W45IG3em+ojL24jIeYyu+ri5633fiIzKyLjPObjK+LjPS bjP+YrSqbi4C43eubvDmYzK+oizy4vEir/G67isupPD6Xu1K7y9Or76KZMvcI1SG15zO6fbCV/dq 7/eqotmO75+Fr/liGvqmL6WtL/tCmvu+L6PFr/wi/xr91i+h3S/+nm/57q+a6a//4hkAB/CcDTAB v5kBH/D/9q8Cb1kCNzCZPTAEg5kET7CWVbAFV1kFW8ycLJthQFkpuZd5JVvIjPAkmZEJq9XIrFJO Yu9eNVIHsxLLwFB7ifBzTFIMI1uPAYQMq5tumaRFXlBYGZevlJYafs0PmofzhAY5GBtS5hj1dIFx qAisGHErwAoHTfFUSosUHQ57aUZ23UoVaxauhJY/nU1IRkuW9AgSu6REvlaIJQqJSN0cyzEdh1SU 5LEcS9U5gBDhsJQfNyAdB/L86DEhr9gh3/EeF0g1yoUhZx2cPLIbuzCFgZBXFfJpcFYii1YSq/Go eP9HtHjxHPSxH7PWJ7chJv9xJl/yJmvLIofyEcKyIWdJpOwxwU3lLZfyJHskJukxK/9yxyyyhf3J LNexKqdOH3eDI2+KLsdxM0syIhdzs9UyIUuzIkdgBEoyDzZzC/MyDZPJbewNUJ3NEhFLGzdxEmUP HOaxskDcU7VG9pkW1RFxaowzr7iDOrexMJWxGOPXYAlVPecTogQTkXxTGe+ygtWwBscXuKQwv5Iu VzkwQze0hmFwBkeZRV/0kmW0RhMZR3e0j320cs1wUpBFrXnwDu9CTHhwe7yMS8eyDsMwuog0DK90 HZ0JCSvbYv2wDX8wYvANIx2MNEJ0J9PTbJRWkPD/jjwzZfY98UnkmFO7E37MMj6bcUD/IB4edPYs wxojixTdF1dfdXIs3GFV1lZfcVL70j+bsUZ6s5skiDA3MiYDcwcJ86o4lV1PUVyRsl3rz17nNWBA szUD9jGbUw7CdCsLNmGThEVbzY6BsjHf8i8XNH6d8nJsMWDDzij7gSzXhS9b9iDn8iAPdmJvixfb UdHQNWnDc2m32RtD2TvbTjZbGDZHlF938DYzsmdvNikrdjRzdl8vtjGvNjX71GEvc2sT9yHbGSUf sa2wc0EnypHoSmg5nGWLhjJB3PJN1zVJCTkPTQMps1YbtD7fiQo9cnZPC9YASiqb92xP01o7NFOf /5L4gnAk0ZpO41Z9+xdRcxG57LdryymABxoDg/SP0bSBRxiCJziCLTiD99cAM0RLg89O9/RLm1tL iJOEv/BIK1k1upIB5ndQ47R7dXNC8zBOE9LHpNsKfzMojTizlXBOR7QqmTh9R3IV8zMaM80aO/F6 11BU90i2lHNY43I8O1BTYx/VwTORE7l3CzStTMpAUzdXU3lVWzmFIDV3bw94F3lNurWA5XZ7M580 13Zrv3eZ2/Jw1/UzU/NoxzWFz7Yvj3krm7lvK7dh1zlQ3nhgn7Z003Igk7MtwzKOXXdn6zk3dzYx BHebl/KhP/magLYut/MqtyFdF7pq/zlkJzdC8//5NItJaAc3HhO2nQs3or95NUcUqiM3nquPm9sx rH+6Zhd2ZK95o7s6oiOlCzNyi2ExLaj3ZQf6dZ/zJ9uGqVs1eFv63kx5svdUIhN6sa/hM10ea/uN r1M2Lmt5sJs3a0dTly+1jWcvl7GEiMO4/zr4VKyVTUMwuj84hxW4uys4vMd7g887vUO4vdv3bguZ yDxMhgMXjZd7yYSwCuNwhUcyT7+2o8V4wHe4T9f4izc8jZU7iRc8xAu1Qp94c2MNsYByUm+1M3F5 E5GxPoM8dVf3TUF123w7YOW4lM93J1c7nbKxFn+xyZ/x9dkDybP1kdvTNeQkVLe1xv+BrD9QqyP/ Nmln+atzM5wj8kE1vW7fNXCf+tKvuqmzOqnbOlwfs5p3urj3RbNLN50rt2gzetkjfdefvQdNe6TP +evEkUC9MqBjPSdzuqNLeqLj/fUA+o9DhATvjyJnut2T/bFn/SazcqmnuiW/ddLX+nJr/dUXPqf7 z9Y79N/XPCp4+2/Tk9z3BrP/CLTP/Za74RDLAh3qkKRgcXdwN6Q/cUpwu637U+dnEevXkJPvgWso u9B7esLLmLuj+4A/RfA3WrvfO3cVv/FrF/Inf3UtP/NTY77z+4xLfEpHvJBZFUob/AnTGGMDVIr3 OSVNt/bXNCpufPbHUg/T8CnROBmNBEm7v/pL/39hcZ38s/DkKbyXeXXDXPsyAVWSgwAARKRojiUa napIrqMJu2mq2jQ9v3Er17jaDzYbGnc91I91Ki510J1tClxJia6brMnitbzUVzEMZZrPZhx6zW4z 1W42tufEzu1celZ/3zu3f3l9Y4J+XYaFeomDh0mNjIpWe2+UkYh9lopbmZJdU4+XoZxxpEqlp6hw qKBaeaJEmJh+YJNGpk1CfJ6vrHWiPrJJtJ6xmTqBjryjrcVlxciaw2Kv0rWradDX2jnblXPey1nN eMnfiLXjyeK/7MvpMc2bz6HZwsrv8vf0je7W8e3duAUceIuglzK4nvABIowKt4MHj/kYIquOw/9Z u/xRyyVlVi6KtuwJHIZrDBJjEDnmgKXSVKCUzFj+qlZwoCqCq27i3MmzpyufQIMKHUqqHlGiOo++ Maq0KVKnUKNKPcV0Ks6kUbFa3cq1q9evYLlqdTo2rNmzaNOqPVtWadu1cOPKnUu31FukVevq3cu3 79e7QwH7HUy4sGFtgoMmPsy4sePCi31Gfky5smW2eY9Ovsy5s2fNmfF+Hk269NTNO8WoXs26tevX sGPLnk27tu3buHPr3s27t+/fwH+HDU68uPHjyJMrX868uXLT0KNLn069uvXr2LNr3869u/fv4MOL H0++vPnz6NOrX8++vfv38OPLn0+/vv37+PP/69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo 4YQUVmjhhRhmqOGGHHbo4YcghijiiCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOP QAYp5JBEFmnkkUgmqeSSTDbp5JNQRinllFRWaeWVWALJQAMNUJDBAgMUEAECBViQQQcXLFABBgAE AMADDnCwAQUbCKCAAg8cwMEFBRygwAYSbOAmAQYMEMEBECgAgQMVPDDAAx7gCQEEGyAQwAAJIKCA BQl4cEAAASAQwZYEeODBpQxgAMEHGgzQwAMXIJrBBx1wcMAACNCawAcZJECBAwBwUIAHAmAg/4AE DSxgAQUMbIDBAxMIEIEHHXSAAQETfBCABxAoa8EAl2awJgYLMODAAhnEyUGiDnTQZQQSUPBAAxUQ AEEFkQYLgAUCLJCmBREEsEEHGiggAbENjJmqB+k+oMEHEFBAQQcVFLAuBgZoEKibH3CwQAec+ipA BRIwoIG/CRQKwAYDTCAuAgg0EIACJEvQgQIFaMBBAhd0oGYCOTMwAQYNpHnAwwQgIMHIBhC65wcN PGqBAgFQ4CsBARPtwAYTcACAAm+C/EABE/CMQAZbKmAAvcAS8CUGFxBdgQbBOvBwABxwYEEB4zkQ AAQdfOBABAQUkIAEByxgAAMGCNByBhRAYP+ABJATIEADDABwKgUYDNCtABdYIAECXVdwgQcXOBCo BIsb0KkFGsh9gQQKXCCABQwg4ADEAOi8AasfAEBwBgRsAIABAXQgQQEIcEBu7QNgkIECDtwpANYe OAru7xBIoEECGBQgrbA3T0BtAwxDsK2vGhBwQAMfJAB5BB9gMLqoDQBQAAMCUFCy1RD4lqMqcKlq BQADGnhABDDQLpxxYGyGs1f2OCAAD1jAAgvwwL7yRAAFUMACHzCZsBSwgAR0gGzUm10EOPcAzgng ARj4AAUO8ID+7Y5hFlicnubEAdT5zAETQMABsEWsax3AAhAQQAcIYIEOCKxdDLCV+x4ogfj/MQBa EEgA9pIVgAKM7gMjY2AHEpCABZAAbObKmbgU4AFhOaBnF5hA2S5APdFZ4AEGgMAExoMsAlzAAPzC gLEi4ABoBUADvfKAAQyAsxYeMQAfW4CdMqA0EVBgBQ44wAuXCCwEJIB/ECBA/T6AAACUMQC8WiIB MDCBBSByAABwAPIu4D9YXnEAHRjA9SLAgaFpIIugooDpIKCBBihgAANLQNUyIABzTc12s8rAujIX vAb4SYYKaBW6iLmBBVCAAwyYWwfi5D4MHABmDmAlzMbpgQgI4FIOSEAFDhAsYkkyXRcgwQQsQIAE 4IpezSth7D5wgbn1EmwMqxgHJDAvACxv/wB8SgAACMAAGmpAABt4gAIIEIAMZCACDbhdnAawAGPm 0wEFMFzjSPkmgwlgV2ZUYO0usChRNkB0BghhnApQtQvATwMHmBsEGpDFPnmzkIsaACMLQMIFSK9b CLCA6gJ2gQvMqQEJwKoE/Ba4DLqMox0gDwHQpIAPFCByFUBAB44Gsnh5YAD8RFs8x9omCUTgARKw 1+gCkMP4gZBQZuVTGycwgAEQQAILQMAAyroqDlQgYQ8onAUw4IG0ngp3G9hVA5hXwgacSQEHyBoD CtoAx2oKAQ8IVcQMRToIPAAA3SoARHH5ppC2FgI9O+cFLGcp1GqAqRjYUjODxT+LCeC3Gf+AAD0V 68oGcJRSHOVlDBUwAQNUQAAiEACZJEC7A1wgAN6lVGgjirXkRasBXTOAAyjQMwaozwBoSuDiyvUB 3BngAhkoE58mgFgHZLJjmbpVBhpXgQyg0qce+EAEDPBZA4BzAva6VLwigMtmqSmzXCLZ2BwgSu8G 4IUK0J0DBiBUxErggYTkQAN++wHaeWADBUgrp0h4gARMCwOXHM8vwwmn5E52AJ6qAAAY4K8FzAlk ARhtACJQrgWomJLX4trX8MiBDFwgARUEwAF8JoD3WTMDD+iAaz8wp62lyXAuFhZeswVGEo/YAhVg 1QTcVco7HWByZRImvA4gAaVGlQMkzuz/BAqQScUx+QPHXJkAFvoAtS7gmHpawAEY8IGuDeBhAPhA UGvISwH4LQIVIFjq3PmADTjgpUAlZn0XoDrJERQDKZPABPyngBP6VJq+ahcZA/gB+L70aw3Ia5WR Z7wCFGoDCBZA/R5QgQn8cgPZ9AACaAlhIVNgoxcwlxwzAOQcckADDvhoOjdruTAFoAIUmEAEJrDR LUtulQc4wCU1hko64SoCFJtcAM513REXAFbFXJUHJhA18X1sTB6NViPHU4EBHOAD9XM2A2xmgS4R 2QDcAmoE7tgBL9kJdthqtiA9sKsEWOCQ+LWapQoAZuoOttbKhdqcN0DyPbFsscHeVZu+/6bFjiFg AQCowJ8yli33aWADGrDuOwNwAU2xVwPgLRkC0/3hCVSAax3wwMGsrrkKjFsEFjPTiDvAS6EHLoaE liMDbWzBpj0At+7cFvMaYIAIaADdE6ghQSegSYptEgB+JmrdLaBYLjFYqhK1AH8//L4hdjwDxFKu ey+lRQBYvc8EMB2oNoBbXJFxATB8FTjFJGRlAcB/FYsUo4TlgZKqKmCZp+GajkfCzebQA7JcXvg0 ZzGoUQD3Buic6kh3MYxvwE8ea9+0snlAHQ/1kxEg9CU9oAEGEI6OhqLh7tRHJ6t6jwEOV24HID+t ClQ08wh034pJimMT4nfWEwiVpCB1wP/6opLwHxjA1o6O1d1xQHeuRF0jEACtBFpmt0QMMHECkFwP J2uJQjdrtSYXlScUAC5N5DnHAjLNggCHtTy5ggDM8gEEsAAf8FjykyhnUykSEDEgA0vZ1AAdYAAQ FjdzZlbH8iUQQGLGJCjdMjEx1gEPIFHIdjgolQAPMDUHYHWlhTr551r41nAEQAH9ojl8tVFGGEoH k4TjpSccIEwVtHEDNimApDx9wgHakj9c1U77sy/e03pGiDMiKElAwyVwZjsEqDx6wilIdFcHQDxp UwCLYjHwAgAYYCaW4j8GMB6wQjXc1kWUokshtSalhFeSlgCSg19a1EYQ4AGHlTo0dCj/m9QyYFMt NgYATvU7FmCG5xR8S6NYtYIAbbQAEzBUIHgnKBU1BDCCTmYw3pMBSQg5cCKLXrIvZJMAD/NZTuYs pDMqJZU3mIJvduI8+fUpuLREdac+6IZAZ7IzELAvhag8C+BH39V0CcA1E7A1RwMB8OJOrIM45ZJ3 FIAADQeLb2V11FNaHdBlCiAsiwVoPOMsu+UAEDArxWRlmiJN5qNIugRD9dVrpxJUHiBIC7hvMQZr 3pcBrQQA+HVTzlNSW3JCfPdvBMcB+9hMDOApAVA8xxVWb2VdQaRHtxI6FbA3BGd5TlaKnSQqsFg3 3LaJCDAw4wFCTScorQcmSnSOOCYA/8xjQqU0J/gUajc1UZq2AaUlSziHLKe2WdISAAYwRCEkZsOU auJ0hNQHbchiNR/Aau1khqZydUbkLhJQAVhWRhFDAOilLA4wcYQVaxdQfZiEABqwQAwgJmI0WmuV AFyXN+KnQc7SO4sUTjqzQizDNx2gOwnUcA8wK3n5Tugml8mFNb2WMA0QJxPwXYgDKAWAAVTzgXlZ UIozVM0WMwSgAVW1ZODTOWMikBywQvUyZ9aEAKmyWyeWLVc2kyc3mum0NZIIW1H1XeFGAQ6VUrJ0 JoVSAbypSQrgi+tSAKJEkm0EV9cVZh1FOQQQbpBCONniWDU0T4RIQAJgJ6x2aeWRVv8F0AEbUGVr 4gGbxYknFzN/k4DBl1jENQCABpiUsjYNRIjsxle2I2nS5kHXlZabwkg11JfgxlgJ5lxRRDCTNQKc s0dFs0cKIDQ0Bn4ZsAEVcHUCAKLKk2LWSVlUM1kpGQG/k5YpBgHTJpdyBC0naS9QA1+6dCm1NgKO xW6eUmoMlE84pgE6yQEGICq94k4H4AG/0oVNNCkWMFEk5jgepWmzlgEaCQCiQmiBAixZR4DCgzxt glJQBzaCcp+CpCh60ypOOicR0I0Ddix5JDnTUn2XZExbhVVad1cY8wAMgJEZgAEbp1aw8lFMl1Y7 M09vVQCAYjVqQlnKogArOgAZgEQSFbSAKtY+M9M7sJhYU5OI4hECADs= --{BOUNDARY_RELATED}--