From mpls-bounces@lists.ietf.org Wed Mar 01 10:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETaW-0002bF-3o; Wed, 01 Mar 2006 10:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETaT-0002WQ-VY; Wed, 01 Mar 2006 10:50:01 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETaT-0002pS-K6; Wed, 01 Mar 2006 10:50:01 -0500 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 k21Fo1BX018147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 15:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FETaT-0006qq-D5; Wed, 01 Mar 2006 10:50:01 -0500 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, 01 Mar 2006 10:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-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 : Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-p2mp-00.txt Pages : 20 Date : 2006-3-1 This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP without requiring a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-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-ldp-p2mp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-p2mp-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-3-1095201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-p2mp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-p2mp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-1095201.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 Mar 01 14:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWlQ-0008Mx-9n; Wed, 01 Mar 2006 14:13:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWlO-0008Ld-UX for mpls@lists.ietf.org; Wed, 01 Mar 2006 14:13:30 -0500 Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEWlN-0003V7-LH for mpls@lists.ietf.org; Wed, 01 Mar 2006 14:13:30 -0500 Received: from du-069-0074.access.clara.net ([217.158.132.74] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1FEWlM-000LZt-Gm for mpls@lists.ietf.org; Wed, 01 Mar 2006 19:13:29 +0000 Message-ID: <035b01c63d64$d157e460$10849ed9@Puppy> From: "Adrian Farrel" To: References: Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-oam-reqs-01.txt Date: Wed, 1 Mar 2006 19:17:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 all, Updates are relatively minor and cover the recent discussions and comments from Ben as well as some issues he raised back in December. Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, February 28, 2006 8:50 PM Subject: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-oam-reqs-01.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 : OAM Requirements for Point-to-Multipoint MPLS > Networks > Author(s) : A. Farrel, et al. > Filename : draft-ietf-mpls-p2mp-oam-reqs-01.txt > Pages : 12 > Date : 2006-2-28 > > Multi-Protocol Label Switching (MPLS) has been extended to encompass > point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with > point-to-point MPLS LSPs the requirement to detect, handle and > diagnose control and data plane defects is critical. > > For operators deploying services based on P2MP MPLS LSPs the > detection and specification of how to handle those defects is > important because such defects may not only affect the fundamentals > of an MPLS network, but also because they may impact service level > specification commitments for customers of their network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-oam-reqs-01.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Mar 01 14:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX3D-0000qY-97; Wed, 01 Mar 2006 14:31:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX3B-0000oa-SY; Wed, 01 Mar 2006 14:31:53 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEX3A-0004Pg-I2; Wed, 01 Mar 2006 14:31:53 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k21JVqgL002632; Wed, 1 Mar 2006 14:31:52 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11731; Wed, 1 Mar 2006 14:31:46 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 14:31:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0DAC175B@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'mpls@lists.ietf.org'" , "'mpls@ietf.org'" Date: Wed, 1 Mar 2006 14:31:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [mpls] TEST Message 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 Please ignore this message... test de mpls . _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Mar 01 14:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX3D-0000qe-S5; Wed, 01 Mar 2006 14:31:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX3B-0000oa-SY; Wed, 01 Mar 2006 14:31:53 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEX3A-0004Pg-I2; Wed, 01 Mar 2006 14:31:53 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k21JVqgL002632; Wed, 1 Mar 2006 14:31:52 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11731; Wed, 1 Mar 2006 14:31:46 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 14:31:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0DAC175B@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'mpls@lists.ietf.org'" , "'mpls@ietf.org'" Date: Wed, 1 Mar 2006 14:31:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [mpls] TEST Message 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 Please ignore this message... test de mpls . _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Mar 02 06:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FElX1-0003FK-9G; Thu, 02 Mar 2006 05:59:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FElWz-0003EO-IN for mpls@lists.ietf.org; Thu, 02 Mar 2006 05:59:37 -0500 Received: from imo-m22.mx.aol.com ([64.12.137.3] helo=imo-m22.mail.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FElWy-0000hm-BU for mpls@lists.ietf.org; Thu, 02 Mar 2006 05:59:37 -0500 Received: from HeinerHummel@aol.com by imo-m22.mx.aol.com (mail_out_v38_r7.3.) id n.1a9.483dc381 (18403) for ; Thu, 2 Mar 2006 05:59:26 -0500 (EST) From: HeinerHummel@aol.com Message-ID: <1a9.483dc381.31382a0d@aol.com> Date: Thu, 2 Mar 2006 05:59:25 EST Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt To: mpls@lists.ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5004 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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="===============0461557291==" Errors-To: mpls-bounces@lists.ietf.org --===============0461557291== Content-Type: multipart/alternative; boundary="-----------------------------1141297165" -------------------------------1141297165 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en =20 Some critical notes wrt mp2mp LSP:=20 The terms upstream and downstream relate to the terms ingress and egress,=20 but not to root (and three times not to root while keeping open whether the= =20 root is an ingress(+egress) at all).=20 The mp2mp LSP is supposed to be a mesh-less delivery channel which=20 interconnects a specific set of leaf nodes such that at any junction traffi= c is=20 forwarded to all other directions except the one from where it is received.= This is=20 my understanding about the mp2mp stream direction. The presented design wit= h=20 its upstreams and downstreams all over the place is fairly a sign of=20 ossification, isn=E2=80=99t it ?=20 Heiner Hummel -------------------------------1141297165 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en

Some=20 critical notes wrt mp2mp LSP:

 

The terms=20 upstream and downstream relate to the terms ingress and egress, but not to r= oot=20 <= FONT=20 size=3D3>(and three times not to root while keepi= ng open=20 whether the root is an ingress(+egress) at=20 all).

 

The mp2mp=20 LSP is supposed to be a mesh-less delivery channel which interconnects a=20 specific set of leaf nodes such that at any junction traffic is forwarded to= all=20 other directions except the one from where it is received. This is my=20 understanding about the mp2mp stream direction. The presented design with it= s=20 upstreams and downstreams all over the place is fairly a sign of ossificatio= n,=20 isn=E2=80=99t it ?

 

Heiner=20 Hummel

-------------------------------1141297165-- --===============0461557291== 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 --===============0461557291==-- From mpls-bounces@lists.ietf.org Fri Mar 03 07:24:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF9IH-0000Oc-AY; Fri, 03 Mar 2006 07:22:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF9IG-0000LA-HE for mpls@lists.ietf.org; Fri, 03 Mar 2006 07:22:00 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF9IF-0002Nz-T7 for mpls@lists.ietf.org; Fri, 03 Mar 2006 07:22:00 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 12:21:58 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 12:21:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt Date: Fri, 3 Mar 2006 12:21:57 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538914A549B4@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt Thread-Index: AcY96H4aF+jlniyXQnil4JElVRokaQA0xACA From: To: , X-OriginalArrivalTime: 03 Mar 2006 12:21:57.0858 (UTC) FILETIME=[10D20C20:01C63EBD] X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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: , Content-Type: multipart/mixed; boundary="===============1232255629==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1232255629== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63EBD.1061B7FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63EBD.1061B7FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An observation. There is no such construct as a mp2mp *connection*.....one can have any-any in a cl-ps mode network (precisely because there are no connections) but it is NOT possible to have mp2mp connections in either a co-ps or co-cs mode network. This can be proved by an appeal to (Shannon) information theory.....but it would require a very lengthy explanation, especially wrt how labelling works (its not as simple as some folks might assume). =20 However, let me simply state here what the bottom-line conclusions/rules are: A connection must: - only have a single source - only have connectivity of 1=20 ....so only p2p and p2mp connection constructions are allowed. Further, and consequential from the above: - ordering of traffic units is preserved in a connection - once created there is no routing choice available in a connection A trail is 'the source to a specific-sink' relationship in these connection constructs. regards, Neil -----Original Message----- From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: 02 March 2006 10:59 To: mpls@lists.ietf.org Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt=20 Some critical notes wrt mp2mp LSP: =20 The terms upstream and downstream relate to the terms ingress and egress, but not to root (and three times not to root while keeping open whether the root is an ingress(+egress) at all). =20 The mp2mp LSP is supposed to be a mesh-less delivery channel which interconnects a specific set of leaf nodes such that at any junction traffic is forwarded to all other directions except the one from where it is received. This is my understanding about the mp2mp stream direction. The presented design with its upstreams and downstreams all over the place is fairly a sign of ossification, isn't it ? =20 Heiner Hummel ------_=_NextPart_001_01C63EBD.1061B7FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
An=20 observation.  There is no such construct as a mp2mp = *connection*.....one=20 can have any-any in a cl-ps mode network (precisely because there are no = connections) but it is NOT possible to have mp2mp connections in either = a co-ps=20 or co-cs mode network.  This can be proved by an appeal to = (Shannon)=20 information theory.....but it would require a very lengthy explanation,=20 especially wrt how labelling works (its not as simple as some folks = might=20 assume).
 
However, let me simply state here what the bottom-line=20 conclusions/rules are:
A connection must:
-=20 only have a single source
- only have connectivity of 1

....so only p2p and p2mp connection = constructions=20 are allowed.

Further, and consequential from the = above:
-=20 ordering of traffic units is preserved in a connection
- once created there is no routing choice = available in a=20 connection

A trail is 'the source to a = specific-sink'=20 relationship in these connection=20 constructs.

regards, = Neil
-----Original Message-----
From: = HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]
Sent: 02 March 2006=20 10:59
To: mpls@lists.ietf.org
Subject: Re: [mpls] = I-D=20 ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

Some=20 critical notes wrt mp2mp LSP:

 

The=20 terms upstream and downstream relate to the terms ingress and egress, = but not=20 to root (and=20 three times not to root while keeping open whether the root is an=20 ingress(+egress) at all).

 

The=20 mp2mp LSP is supposed to be a mesh-less delivery channel which = interconnects a=20 specific set of leaf nodes such that at any junction traffic is = forwarded to=20 all other directions except the one from where it is received. This is = my=20 understanding about the mp2mp stream direction. The presented design = with its=20 upstreams and downstreams all over the place is fairly a sign of = ossification,=20 isn’t it ?

 

Heiner=20 = Hummel

------_=_NextPart_001_01C63EBD.1061B7FA-- --===============1232255629== 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 --===============1232255629==-- From mpls-bounces@lists.ietf.org Fri Mar 03 09:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAtT-0005Vq-4z; Fri, 03 Mar 2006 09:04:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAtR-0005O8-Uu for mpls@lists.ietf.org; Fri, 03 Mar 2006 09:04:29 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFAtR-0006EI-GM for mpls@lists.ietf.org; Fri, 03 Mar 2006 09:04:29 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k23E4TgL017884 for ; Fri, 3 Mar 2006 09:04:29 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13399 for ; Fri, 3 Mar 2006 09:04:28 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Mar 2006 09:04:27 -0500 Message-ID: <2B3D0F99A26BD611977000204840E2820AD5CE19@whq-msgusr-01.pit.comms.marconi.com> From: "Rutemiller, John" To: mpls@lists.ietf.org Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt Date: Fri, 3 Mar 2006 09:04:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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="===============0866237581==" 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. --===============0866237581== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63ECB.60F66DE6" 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_01C63ECB.60F66DE6 Content-Type: text/plain A construct that has not been mentioned, but is useful in this discussion is mp2p. Based on Neil's definition, mp2p is not a connection. This makes sense when you think about it. At the reciever, additional information is needed to identify the sender of each packet in order to recover the individual streams. So, mp2p is a multiplexing action which requires demultiplexing at the receiver. This is useful to keep in mind when talking about mp2mp. A mp2mp construct is actually a combination of p2mp and mp2p. >From the point of view of the sender, mp2mp looks like a p2mp connection. In the MPLS world, any packet entering the network will take a fixed and known path to the recievers. Looking at only this behavior, mp2mp looks like a connection. >From the point of view of the receiver, mp2mp looks like mp2p. The receiver requires additional information in order to identify and recover the different traffic streams. John _____ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Friday, March 03, 2006 7:22 AM To: HeinerHummel@aol.com; mpls@lists.ietf.org Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt An observation. There is no such construct as a mp2mp *connection*.....one can have any-any in a cl-ps mode network (precisely because there are no connections) but it is NOT possible to have mp2mp connections in either a co-ps or co-cs mode network. This can be proved by an appeal to (Shannon) information theory.....but it would require a very lengthy explanation, especially wrt how labelling works (its not as simple as some folks might assume). However, let me simply state here what the bottom-line conclusions/rules are: A connection must: - only have a single source - only have connectivity of 1 ....so only p2p and p2mp connection constructions are allowed. Further, and consequential from the above: - ordering of traffic units is preserved in a connection - once created there is no routing choice available in a connection A trail is 'the source to a specific-sink' relationship in these connection constructs. regards, Neil -----Original Message----- From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com] Sent: 02 March 2006 10:59 To: mpls@lists.ietf.org Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt Some critical notes wrt mp2mp LSP: The terms upstream and downstream relate to the terms ingress and egress, but not to root (and three times not to root while keeping open whether the root is an ingress(+egress) at all). The mp2mp LSP is supposed to be a mesh-less delivery channel which interconnects a specific set of leaf nodes such that at any junction traffic is forwarded to all other directions except the one from where it is received. This is my understanding about the mp2mp stream direction. The presented design with its upstreams and downstreams all over the place is fairly a sign of ossification, isn't it ? Heiner Hummel ------_=_NextPart_001_01C63ECB.60F66DE6 Content-Type: text/html Message
 
A construct that has not been mentioned, but is useful in this discussion is mp2p.
 
Based on Neil's definition, mp2p is not a connection. This makes sense when you think about it. At the reciever, additional information is needed to identify the sender of each packet in order to recover the individual streams. So, mp2p is a multiplexing action which requires demultiplexing at the receiver.
 
This is useful to keep in mind when talking about mp2mp. A mp2mp construct is actually a combination of p2mp and mp2p.
 
From the point of view of the sender, mp2mp looks like a p2mp connection. In the MPLS world, any packet entering the network will take a fixed and known path to the recievers. Looking at only this behavior, mp2mp looks like a connection.
 
From the point of view of the receiver, mp2mp looks like mp2p. The receiver requires additional information in order to identify and recover the different traffic streams.
 
 
John
 
 

From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Friday, March 03, 2006 7:22 AM
To: HeinerHummel@aol.com; mpls@lists.ietf.org
Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

An observation.  There is no such construct as a mp2mp *connection*.....one can have any-any in a cl-ps mode network (precisely because there are no connections) but it is NOT possible to have mp2mp connections in either a co-ps or co-cs mode network.  This can be proved by an appeal to (Shannon) information theory.....but it would require a very lengthy explanation, especially wrt how labelling works (its not as simple as some folks might assume).
 
However, let me simply state here what the bottom-line conclusions/rules are:
A connection must:
- only have a single source
- only have connectivity of 1

....so only p2p and p2mp connection constructions are allowed.

Further, and consequential from the above:
- ordering of traffic units is preserved in a connection
- once created there is no routing choice available in a connection

A trail is 'the source to a specific-sink' relationship in these connection constructs.

regards, Neil
-----Original Message-----
From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]
Sent: 02 March 2006 10:59
To: mpls@lists.ietf.org
Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

Some critical notes wrt mp2mp LSP:

 

The terms upstream and downstream relate to the terms ingress and egress, but not to root (and three times not to root while keeping open whether the root is an ingress(+egress) at all).

 

The mp2mp LSP is supposed to be a mesh-less delivery channel which interconnects a specific set of leaf nodes such that at any junction traffic is forwarded to all other directions except the one from where it is received. This is my understanding about the mp2mp stream direction. The presented design with its upstreams and downstreams all over the place is fairly a sign of ossification, isn't it ?

 

Heiner Hummel

------_=_NextPart_001_01C63ECB.60F66DE6-- --===============0866237581== 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 --===============0866237581==-- From mpls-bounces@lists.ietf.org Fri Mar 03 10:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBrl-00013l-CW; Fri, 03 Mar 2006 10:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBrj-00013g-71 for mpls@lists.ietf.org; Fri, 03 Mar 2006 10:06:47 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBri-000086-D0 for mpls@lists.ietf.org; Fri, 03 Mar 2006 10:06:47 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 15:06:44 +0000 Received: from i2km31-ukdy.domain1.systemhost.net ([193.113.30.24]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 15:06:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt Date: Fri, 3 Mar 2006 15:06:43 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt Thread-Index: AcY+y24Q52WZRaRtSnSQbwtKJ7s+8gACPdwA From: To: , X-OriginalArrivalTime: 03 Mar 2006 15:06:44.0271 (UTC) FILETIME=[1594F3F0:01C63ED4] X-Spam-Score: 0.2 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d 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: , Content-Type: multipart/mixed; boundary="===============1095875651==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1095875651== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63ED4.15456098" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63ED4.15456098 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable John, =20 I think you've put in a nushell. =20 Regards, =20 Andy =20 Andy Reid=20 Chief Network Services Architect=20 =20 _____ =20 From: Rutemiller, John [mailto:John.Rutemiller@marconi.com]=20 Sent: 03 March 2006 14:04 To: mpls@lists.ietf.org Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt=20 =09 =09 =20 A construct that has not been mentioned, but is useful in this discussion is mp2p. =20 Based on Neil's definition, mp2p is not a connection. This makes sense when you think about it. At the reciever, additional information is needed to identify the sender of each packet in order to recover the individual streams. So, mp2p is a multiplexing action which requires demultiplexing at the receiver. =20 This is useful to keep in mind when talking about mp2mp. A mp2mp construct is actually a combination of p2mp and mp2p. =20 From the point of view of the sender, mp2mp looks like a p2mp connection. In the MPLS world, any packet entering the network will take a fixed and known path to the recievers. Looking at only this behavior, mp2mp looks like a connection. =20 From the point of view of the receiver, mp2mp looks like mp2p. The receiver requires additional information in order to identify and recover the different traffic streams. =20 =20 John =20 =20 _____ =20 From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Friday, March 03, 2006 7:22 AM To: HeinerHummel@aol.com; mpls@lists.ietf.org Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt=20 =09 =09 An observation. There is no such construct as a mp2mp *connection*.....one can have any-any in a cl-ps mode network (precisely because there are no connections) but it is NOT possible to have mp2mp connections in either a co-ps or co-cs mode network. This can be proved by an appeal to (Shannon) information theory.....but it would require a very lengthy explanation, especially wrt how labelling works (its not as simple as some folks might assume). =20 However, let me simply state here what the bottom-line conclusions/rules are: =09 A connection must: - only have a single source - only have connectivity of 1=20 ....so only p2p and p2mp connection constructions are allowed. Further, and consequential from the above: - ordering of traffic units is preserved in a connection - once created there is no routing choice available in a connection A trail is 'the source to a specific-sink' relationship in these connection constructs. regards, Neil -----Original Message----- From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com] Sent: 02 March 2006 10:59 To: mpls@lists.ietf.org Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt=20 =09 =09 =09 Some critical notes wrt mp2mp LSP: =20 The terms upstream and downstream relate to the terms ingress and egress, but not to root (and three times not to root while keeping open whether the root is an ingress(+egress) at all). =20 The mp2mp LSP is supposed to be a mesh-less delivery channel which interconnects a specific set of leaf nodes such that at any junction traffic is forwarded to all other directions except the one from where it is received. This is my understanding about the mp2mp stream direction. The presented design with its upstreams and downstreams all over the place is fairly a sign of ossification, isn't it ? =20 Heiner Hummel ------_=_NextPart_001_01C63ED4.15456098 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
John,
 
I=20 think you've put in a nushell.
 
Regards,
 
Andy
 

Andy = Reid
Chief Network Services Architect

 

From: Rutemiller, John=20 [mailto:John.Rutemiller@marconi.com]
Sent: 03 March 2006=20 14:04
To: mpls@lists.ietf.org
Subject: RE: [mpls] = I-D=20 ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

 
A = construct that has=20 not been mentioned, but is useful in this discussion is = mp2p.
 
Based on = Neil's=20 definition, mp2p is not a connection. This makes sense when you think = about=20 it. At the reciever, additional information is needed to identify the = sender=20 of each packet in order to recover the individual streams. So, = mp2p is a=20 multiplexing action which requires demultiplexing at the=20 receiver.
 
This is = useful to keep=20 in mind when talking about mp2mp. A mp2mp construct is actually a = combination=20 of p2mp and mp2p.
 
From the = point of view=20 of the sender, mp2mp looks like a p2mp connection. In the MPLS world, = any=20 packet entering the network will take a fixed and known path to the = recievers.=20 Looking at only this behavior, mp2mp looks like a = connection.
 
From the = point of view=20 of the receiver, mp2mp looks like mp2p. The receiver requires = additional=20 information in order to identify and recover the different = traffic=20 streams.
 
 
John
 
 

From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: Friday, March 03, = 2006 7:22=20 AM
To: HeinerHummel@aol.com; = mpls@lists.ietf.org
Subject:=20 RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt =

An observation.  There is no such construct as a = mp2mp=20 *connection*.....one can have any-any in a cl-ps mode network = (precisely=20 because there are no connections) but it is NOT possible to have mp2mp = connections in either a co-ps or co-cs mode network.  This can be = proved=20 by an appeal to (Shannon) information theory.....but it would require = a very=20 lengthy explanation, especially wrt how labelling works (its not as = simple as=20 some folks might assume).
 
However, let me simply state here what the bottom-line = conclusions/rules are:
A connection must:
-=20 only have a single source
- only have connectivity of 1=20

....so only p2p and p2mp connection=20 constructions are allowed.

Further, and consequential from the = above:
-=20 ordering of traffic units is preserved in a connection
- once created there is no routing choice = available in a=20 connection

A trail is 'the source to a = specific-sink'=20 relationship in these connection=20 constructs.

regards, = Neil
-----Original Message-----
From: = HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]
Sent: 02 March 2006=20 10:59
To: mpls@lists.ietf.org
Subject: Re: = [mpls] I-D=20 ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

Some=20 critical notes wrt mp2mp LSP:

 

The=20 terms upstream and downstream relate to the terms ingress and = egress, but=20 not to root (and=20 three times not to root while keeping open whether the root is an=20 ingress(+egress) at all).

 

The=20 mp2mp LSP is supposed to be a mesh-less delivery channel which = interconnects=20 a specific set of leaf nodes such that at any junction traffic is = forwarded=20 to all other directions except the one from where it is received. = This is my=20 understanding about the mp2mp stream direction. The presented design = with=20 its upstreams and downstreams all over the place is fairly a sign of = ossification, isn't it ?

 

Heiner=20 = Hummel

------_=_NextPart_001_01C63ED4.15456098-- --===============1095875651== 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 --===============1095875651==-- From mpls-bounces@lists.ietf.org Fri Mar 03 13:15:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEmC-0003mV-MS; Fri, 03 Mar 2006 13:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEmB-0003hS-GS for mpls@lists.ietf.org; Fri, 03 Mar 2006 13:13:15 -0500 Received: from imo-m20.mx.aol.com ([64.12.137.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFEmB-0007Mi-2P for mpls@lists.ietf.org; Fri, 03 Mar 2006 13:13:15 -0500 Received: from HeinerHummel@aol.com by imo-m20.mx.aol.com (mail_out_v38_r7.3.) id e.1d8.4fab9acf (26116); Fri, 3 Mar 2006 13:12:48 -0500 (EST) From: HeinerHummel@aol.com Message-ID: <1d8.4fab9acf.3139e11d@aol.com> Date: Fri, 3 Mar 2006 13:12:45 EST Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt To: John.Rutemiller@marconi.com, mpls@lists.ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5004 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c 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: , Content-Type: multipart/mixed; boundary="===============0203416979==" Errors-To: mpls-bounces@lists.ietf.org --===============0203416979== Content-Type: multipart/alternative; boundary="-----------------------------1141409565" -------------------------------1141409565 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 John, =20 I guess, it is not the task of the LSP to de-multiplex the received data at= =20 any particular leaf node of the mp2mp-LSP, although this needs to be done,=20 too, however by some entity elsewhere. I think there are two alternatives w= rt=20 the mp2mp-LSP: (1) n p2mp-LSPs (2) n mp2p-LSPs. =20 Whereas mp2mp-LSP is a third and different solution and should be handled=20 accordingly. It is NOT a special p2mp-LSP, but I am afraid this is the view of the =20 designers - for 2 reasons: 1: because all is designed in the light of upstream/downstream 2: it is not worth a separate draft, instead is like an appendix to section= =20 2 which deals with the p2mp-LSP. =20 Heiner =20 =20 In einer eMail vom 03.03.2006 15:05:03 Westeurop=E4ische Normalzeit schreibt= =20 John.Rutemiller@marconi.com: A construct that has not been mentioned, but is useful in this discussion i= s=20 mp2p. =20 Based on Neil's definition, mp2p is not a connection. This makes sense when= =20 you think about it. At the reciever, additional information is needed to=20 identify the sender of each packet in order to recover the individual strea= ms.=20 So, mp2p is a multiplexing action which requires demultiplexing at the =20 receiver. =20 This is useful to keep in mind when talking about mp2mp. A mp2mp construct=20 is actually a combination of p2mp and mp2p. =20 >From the point of view of the sender, mp2mp looks like a p2mp connection. I= n=20 the MPLS world, any packet entering the network will take a fixed and known= =20 path to the recievers. Looking at only this behavior, mp2mp looks like a=20 connection. =20 >From the point of view of the receiver, mp2mp looks like mp2p. The receiver= =20 requires additional information in order to identify and recover the=20 different traffic streams. =20 =20 John =20 =20 =20 ____________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Friday, March 03, 2006 7:22 AM To: HeinerHummel@aol.com; mpls@lists.ietf.org Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt=20 An observation. There is no such construct as a mp2mp *connection*.....one= =20 can have any-any in a cl-ps mode network (precisely because there are no=20 connections) but it is NOT possible to have mp2mp connections in either a c= o-ps=20 or co-cs mode network. This can be proved by an appeal to (Shannon)=20 information theory.....but it would require a very lengthy explanation, esp= ecially wrt=20 how labelling works (its not as simple as some folks might assume). =20 However, let me simply state here what the bottom-line conclusions/rules ar= e: A connection must: - only have a single source - only have connectivity of 1 =20 ....so only p2p and p2mp connection constructions are allowed.=20 Further, and consequential from the above: - ordering of traffic units is preserved in a connection - once created there is no routing choice available in a connection=20 A trail is 'the source to a specific-sink' relationship in these connection= =20 constructs. regards, Neil -----Original Message----- From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: 02 March 2006 10:59 To: mpls@lists.ietf.org Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt=20 Some critical notes wrt mp2mp LSP:=20 The terms upstream and downstream relate to the terms ingress and egress,=20 but not to root (and three times not to root while keeping open whether th= e=20 root is an ingress(+egress) at all).=20 The mp2mp LSP is supposed to be a mesh-less delivery channel which=20 interconnects a specific set of leaf nodes such that at any junction traffi= c is=20 forwarded to all other directions except the one from where it is received.= This is=20 my understanding about the mp2mp stream direction. The presented design wit= h=20 its upstreams and downstreams all over the place is fairly a sign of =20 ossification, isn't it ?=20 Heiner Hummel _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls -------------------------------1141409565 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
John,
 
I guess, it is not the task of the LSP to de-multiplex the receive= d=20 data at any particular leaf node of the mp2mp-LSP, although this n= eeds=20 to be done, too, however by some entity elsewhere. I think there are tw= o=20 alternatives wrt the mp2mp-LSP:
(1) n p2mp-LSPs
(2) n mp2p-LSPs.
 
Whereas mp2mp-LSP is a third and different solution and should be=20 handled accordingly.
It is NOT a special p2mp-LSP, but I am afraid this is the view of=20= the=20 designers - for 2 reasons:
1: because all is designed in the light of upstream/downstream
2: it is not worth a separate draft, instead is like an appendix t= o=20 section 2 which deals with the p2mp-LSP.
 
Heiner
 
 
In einer eMail vom 03.03.2006 15:05:03 Westeurop=E4ische Normalzeit sch= reibt=20 John.Rutemiller@marconi.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
A construct t= hat has=20 not been mentioned, but is useful in this discussion is mp2p.
 =
Based on Neil= 's=20 definition, mp2p is not a connection. This makes sense when you think abou= t=20 it. At the reciever, additional information is needed to identify the send= er=20 of each packet in order to recover the individual streams. So, mp2p i= s a=20 multiplexing action which requires demultiplexing at the=20 receiver.
 =
This is usefu= l to keep=20 in mind when talking about mp2mp. A mp2mp construct is actually a combinat= ion=20 of p2mp and mp2p.
 =
From the poin= t of view=20 of the sender, mp2mp looks like a p2mp connection. In the MPLS world, any=20 packet entering the network will take a fixed and known path to the reciev= ers.=20 Looking at only this behavior, mp2mp looks like a connection.
 =
From the poin= t of view=20 of the receiver, mp2mp looks like mp2p. The receiver requires additional=20 information in order to identify and recover the different traffic=20 streams.
 =
 =
John
 =
 =

From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: Friday, March 03, 2006 7:= 22=20 AM
To: HeinerHummel@aol.com; mpls@lists.ietf.org
Subject:<= /B>=20 RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

An observation.  There is no such construct as a mp2m= p=20 *connection*.....one can have any-any in a cl-ps mode network (precisely=20 because there are no connections) but it is NOT possible to have mp2mp=20 connections in either a co-ps or co-cs mode network.  This can be pro= ved=20 by an appeal to (Shannon) information theory.....but it would require a ve= ry=20 lengthy explanation, especially wrt how labelling works (its not as simple= as=20 some folks might assume).
 
However, let me simply state here what the bottom-line=20 conclusions/rules are:
A connection must:
-=20 only have a single source
- only have connectivity of 1=20

....so only p2p and p2mp connection=20 constructions are allowed.

Further, and consequential from the above<= SPAN=20 class=3D095091112-03032006>:
-=20 ordering of traffic units is preserved in a connection
- once created there is no routing choice available= in a=20 connection

A trail is 'the source to a specific-sink'= =20 relationship in these connection=20 constructs.

regards, Neil
-----Original Message-----
From: HeinerHummel@ao= l.com=20 [mailto:HeinerHummel@aol.com]
Sent: 02 March 2006=20 10:59
To: mpls@lists.ietf.org
Subject: Re: [mpls] I-= D=20 ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

Some=20 critical notes wrt mp2mp LSP:

 

The=20 terms upstream and downstream relate to the terms ingress and egress, bu= t=20 not to root (and=20 three times not to root while keeping open whether the root is an=20 ingress(+egress) at all).

 

The=20 mp2mp LSP is supposed to be a mesh-less delivery channel which interconn= ects=20 a specific set of leaf nodes such that at any junction traffic is forwar= ded=20 to all other directions except the one from where it is received. This i= s my=20 understanding about the mp2mp stream direction. The presented design wit= h=20 its upstreams and downstreams all over the place is fairly a sign of=20 ossification, isn't it ?

 

Heiner=20 Hummel


_______________________________________________
mpls=20 mailing=20 list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls=
 
-------------------------------1141409565-- --===============0203416979== 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 --===============0203416979==-- From mpls-bounces@lists.ietf.org Fri Mar 03 15:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGTl-00032E-74; Fri, 03 Mar 2006 15:02:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGTj-00030G-NP for mpls@lists.ietf.org; Fri, 03 Mar 2006 15:02:19 -0500 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 1FFGTi-0002jh-7u for mpls@lists.ietf.org; Fri, 03 Mar 2006 15:02:19 -0500 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 k23K2C828804; Fri, 3 Mar 2006 21:02:12 +0100 (CET) Received: from [192.168.0.9] (ams-clip-vpn-dhcp4628.cisco.com [10.61.82.19]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k23K2AC05138; Fri, 3 Mar 2006 21:02:11 +0100 (CET) In-Reply-To: <1d8.4fab9acf.3139e11d@aol.com> References: <1d8.4fab9acf.3139e11d@aol.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5886bcccc367a4f53d511151288d9fe6@cisco.com> Content-Transfer-Encoding: quoted-printable From: IJsbrand Wijnands Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt Date: Fri, 3 Mar 2006 21:02:11 +0100 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 > I guess, it=A0is not the task of the LSP to de-multiplex the received=20= > data at any particular leaf=A0node of the mp2mp-LSP, although = this=A0needs=20 > to be done, too, however by some=A0entity elsewhere. I Just to make a clarification. A true leaf of a MP2MP LSP does not need=20= to do any de-multiplexing. Packets are received on one label, and are=20 send using one label. > think there are two alternatives wrt the mp2mp-LSP: > (1) n p2mp-LSPs > (2) n mp2p-LSPs. > =A0 > Whereas=A0mp2mp-LSP is a third and different solution and should be=20 > handled accordingly. > It is=A0NOT a special p2mp-LSP, but I am afraid this is the view of = the=20 > designers=A0- for 2 reasons: It is a MP2MP LSP from the point of view of the leafs, there is an=20 upstream path to send to and a downstream path to receive from. If you=20= look at the internals, it is a P2MP LSP from the root to all the leafs.=20= There is a P2P LSP from the leaf to the next upstream LSR until you=20 reach the root. While MPLS packets are forwarded upstream, they are=20 allowed to go down the P2MP LSP if there are receivers. Thx, Ice. > 1: because all is designed in the light of upstream/downstream > 2: it is not worth a separate draft, instead is like=A0an appendix to=20= > section 2 which deals with the p2mp-LSP. > =A0 > Heiner > =A0 > =A0 > In einer eMail vom 03.03.2006 15:05:03 Westeurop=E4ische Normalzeit=20 > schreibt John.Rutemiller@marconi.com: >> >> A construct that has not been mentioned, but is useful in this=20 >> discussion is mp2p. >> =A0 >> Based on Neil's definition, mp2p is not a connection. This makes=20 >> sense when you think about it. At the reciever, additional=20 >> information is needed to identify the sender of each packet in order=20= >> to recover the individual streams.=A0So, mp2p is a multiplexing = action=20 >> which requires demultiplexing at the receiver. >> =A0 >> This is useful to keep in mind when talking about mp2mp. A mp2mp=20 >> construct is actually a combination of p2mp and mp2p. >> =A0 >> =46rom the point of view of the sender, mp2mp looks like a p2mp=20 >> connection. In the MPLS world, any packet entering the network will=20= >> take a fixed and known path to the recievers. Looking at only this=20 >> behavior, mp2mp looks like a connection. >> =A0 >> =46rom the point of view of the receiver, mp2mp looks like mp2p. The=20= >> receiver requires additional information in order to identify and=20 >> recover=A0the different traffic streams. >> =A0 >> =A0 >> John >> =A0 >> =A0 >> >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: Friday, March 03, 2006 7:22 AM >> To: HeinerHummel@aol.com; mpls@lists.ietf.org >> Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt >> >> An observation.=A0 There is no such construct as a mp2mp=20 >> *connection*.....one can have any-any in a cl-ps mode network=20 >> (precisely because there are no connections) but it is NOT possible=20= >> to have mp2mp connections in either a co-ps or co-cs mode network.=A0=20= >> This can be proved by an appeal to (Shannon) information=20 >> theory.....but it would require a very lengthy explanation,=20 >> especially wrt how labelling works (its not as simple as some folks=20= >> might assume). >> =A0 >> However, let me simply state here what the bottom-line=20 >> conclusions/rules are: >> A connection must: >> - only have a single source >> - only have connectivity of 1 >> >> ....so only p2p and p2mp connection constructions are allowed. >> >> Further, and consequential from the above: >> - ordering of traffic units is preserved in a connection >> - once created there is no routing choice available in a connection >> >> A trail is 'the source to a specific-sink' relationship in these=20 >> connection constructs. >> regards, Neil >>> -----Original Message----- >>> From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com] >>> Sent: 02 March 2006 10:59 >>> To: mpls@lists.ietf.org >>> Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt >>> >>> >>> Some critical notes wrt mp2mp LSP: >>> =A0 >>> The terms upstream and downstream relate to the terms ingress and=20 >>> egress, but not to root (and three times not to root while keeping=20= >>> open whether the root is an ingress(+egress) at all). >>> =A0 >>> The mp2mp LSP is supposed to be a mesh-less delivery channel which=20= >>> interconnects a specific set of leaf nodes such that at any junction=20= >>> traffic is forwarded to all other directions except the one from=20 >>> where it is received. This is my understanding about the mp2mp=20 >>> stream direction. The presented design with its upstreams and=20 >>> downstreams all over the place is fairly a sign of ossification,=20 >>> isn't it ? >>> =A0 >>> Heiner Hummel >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls > =A0_______________________________________________ > 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 Sat Mar 04 05:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFU3U-0003wb-Fb; Sat, 04 Mar 2006 05:32:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFU3S-0003tz-Kt for mpls@lists.ietf.org; Sat, 04 Mar 2006 05:32:06 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFU3S-0003Hn-DG for mpls@lists.ietf.org; Sat, 04 Mar 2006 05:32:06 -0500 Received: from HeinerHummel@aol.com by imo-d22.mx.aol.com (mail_out_v38_r7.3.) id c.55.3d7d390 (3924); Sat, 4 Mar 2006 05:31:56 -0500 (EST) From: HeinerHummel@aol.com Message-ID: <55.3d7d390.313ac69c@aol.com> Date: Sat, 4 Mar 2006 05:31:56 EST Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt To: ice@cisco.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5004 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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: , Content-Type: multipart/mixed; boundary="===============1694653717==" Errors-To: mpls-bounces@lists.ietf.org --===============1694653717== Content-Type: multipart/alternative; boundary="-----------------------------1141468316" -------------------------------1141468316 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Ice, It is a MP2MP LSP from the point of view of the leafs, there is an upstream path to send to and a downstream path to receive from. HH>:I guess, you wanted to say: there is an upstream path to receive from and a downstream path to send to. If you look at the internals, it is a P2MP LSP from the root to all the leafs. There is a P2P LSP from the leaf to the next upstream LSR until you reach the root. While MPLS packets are forwarded upstream, they are allowed to go down the P2MP LSP if there are receivers. HH>: Look at the mp2mp-LSP as a whole. Data is sent from any particular leaf node to all other leaf nodes inside the LSP by forwarding the data at any junction to all adjacent neighbor nodes (and nodes of the LSP) except the one from where it is received. Depending on which leaf is the data originator, any link or trail inside the LSP is once upstream and once downstream. It is this basic understanding I am after. Accordingly the label mapping process could be organized. But I have my doubts that it will. Let's see what the respective draft will look like. Heiner Thx, Ice. -------------------------------1141468316 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Ice,
 
 It is a MP2MP LSP from the point of view of the leafs, there=20= is an=20
upstream path to send to and a downstream path to receive from.=20
 
HH>:I guess, you wanted to say: there is an upstream path to rec= eive=20 from and a downstream path to send to.
 
If you
look at the internals, it is a P2MP LSP from the root to= all=20 the leafs.
There is a P2P LSP from the leaf to the next upstream LSR unt= il=20 you
reach the root. While MPLS packets are forwarded upstream, they are=20
allowed to go down the P2MP LSP if there are receivers.
 
HH>: Look at the mp2mp-LSP as a whole. Data is sent from any=20 particular leaf node to all other leaf nodes inside the LSP by forwarding th= e=20 data at any junction to all adjacent neighbor nodes (and nodes of the LSP)=20 except the one from where it is received. Depending on which leaf is the dat= a=20 originator, any link or trail inside the LSP is once upstream and once=20 downstream. It is this basic understanding I am after. Accordingly the label= =20 mapping process could be organized. But I have my doubts that it will. Let's= see=20 what the respective draft will look like.
 
Heiner
 
 


Thx,

Ice.
 
-------------------------------1141468316-- --===============1694653717== 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 --===============1694653717==-- From mpls-bounces@lists.ietf.org Tue Mar 07 05:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZEf-00025w-LF; Tue, 07 Mar 2006 05:16:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZEd-0001ya-3t for mpls@ietf.org; Tue, 07 Mar 2006 05:16:08 -0500 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZEb-00059V-Pk for mpls@ietf.org; Tue, 07 Mar 2006 05:16:07 -0500 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.193]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FGZEW-0001wY-9g for mpls@ietf.org; Tue, 07 Mar 2006 11:16:04 +0100 Message-ID: <440D5CD5.9040901@pi.se> Date: Tue, 07 Mar 2006 11:13:41 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 93238566e09e6e262849b4f805833007 Cc: Subject: [mpls] preliminary mpls wg agensa for the Dallas meeting 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 Working Group, we have uploaded an extremely preliminary agenda for the MPLS working group meeting. Given all misspellings, ordering, unfinished scheduling and outstanding issues with authors/editors, could you please check if I captured your request for an agenda slot. Or hurry up and send it in if you missed doing that. Have a look at http://www3.ietf.org/proceedings/06mar/agenda/mpls.txt /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 Tue Mar 07 18:08:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGlFr-0001NR-Od; Tue, 07 Mar 2006 18:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGlFq-0001Mh-PH for mpls@ietf.org; Tue, 07 Mar 2006 18:06:10 -0500 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGlFq-0000zM-Bn for mpls@ietf.org; Tue, 07 Mar 2006 18:06:10 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-124.messagelabs.com!1141772741!7760893!12 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 21310 invoked from network); 7 Mar 2006 23:06:09 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-124.messagelabs.com with SMTP; 7 Mar 2006 23:06:09 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4401E00700144C23 for mpls@ietf.org; Tue, 7 Mar 2006 18:06:09 -0500 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: Tue, 7 Mar 2006 17:06:09 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9C36@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9C34@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-avt-hc-over-mpls-protocol-04.txt Thread-Index: AcZCN5K6/ZSUhrcVR5uNCIwGGJARzwAAE+fwAADXWlAAABmJwA== From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [mpls] RE: I-D ACTION:draft-ietf-avt-hc-over-mpls-protocol-04.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 Hi All, Please review and comment on the updated draft "Protocol Extensions for Header Compression over MPLS" (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls-protoco l-04.txt). The updates are based on comments from Colin Perkins, see http://www1.ietf.org/mail-archive/web/avt/current/msg06407.html. The main changes include the following: 1. Added detail to worked example in Section 5 to illustrate how the actual header compressed data is encapsulated. 2. Clarified Section 4 (2nd paragraph), updated security considerations Section 6, and updated IANA considerations Section 8. Once again, please review and comment on the updated draft. =20 Thanks, Jerry=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, March 07, 2006 3:50 PM To: i-d-announce@ietf.org Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-hc-over-mpls-protocol-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Protocol Extensions for Header Compression over MPLS Author(s) : J. Ash, et al. Filename : draft-ietf-avt-hc-over-mpls-protocol-04.txt Pages : 29 Date : 2006-3-7 =09 VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms. MPLS is used to route header-compressed (HC) packets over an MPLS LSP without compression/decompression cycles at each router. Such an HC over MPLS capability increases the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. MPLS pseudowires are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR). Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. Each HC scheme operates over a single pseudowire instance very much like it would over a single point-to-point link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls-protocol -04.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Mar 07 22:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGpIv-0006ZK-E2; Tue, 07 Mar 2006 22:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGpIt-0006XH-I0 for mpls@ietf.org; Tue, 07 Mar 2006 22:25:35 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGpIo-0002Gs-On for mpls@ietf.org; Tue, 07 Mar 2006 22:25:35 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVS00MY2HSD1T@szxga02-in.huawei.com> for mpls@ietf.org; Wed, 08 Mar 2006 11:31:25 +0800 (CST) Received: from x41208b ([10.110.100.66]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVS00D65HSCZB@szxga02-in.huawei.com> for mpls@ietf.org; Wed, 08 Mar 2006 11:31:25 +0800 (CST) Date: Wed, 08 Mar 2006 11:18:26 +0800 From: Xiaohu Xu To: Adrian Farrel Message-id: <005301c6425e$f76a84b0$42646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <032f01c6423c$9c6dcb70$bf09253b@Puppy> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: mpls@ietf.org Subject: [mpls] Re: I-D ACTION:draft-xu-mpls-rsvp-te-bidirection-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 Hi, Adrian, Thanks for your comments firstly. In contrast with the procedure of establishing a bidirectional TE tunnel defined in GMPLS draft [RFC 3473], there is no additional requirement on middle-hop LSRs here. The middle-hop LSRs only need to transit the unknown binding object. In addition, the modification of RSVP-TE is small relatively and the path of two opposite tunnel can be different, and there is no need for Path message to assign label. Bidirectional TE tunnel can support many purposes as follows: 1, be used as tunnel for VR-based VPN; 2, achieve LDP over TE easily; 3, interconnect two seperated routing domains via bidiretional TE tunnel, it is more flexible than IGP shortcut and adjacency as different routing protocols can be run in MPLS core domain and the seperated routing domains; 4, BFD can be deployed between the bidirectional TE interfaces to achieve fast switchover of hot standby LSP in case that the primary LSP is down. Best regards, Xiaohu Xu Email: xuxh@huawei.com ----- Original Message ----- From: "Adrian Farrel" To: ; Sent: Wednesday, March 08, 2006 7:11 AM Subject: Fw: I-D ACTION:draft-xu-mpls-rsvp-te-bidirection-00.txt > Hi, > > Interesting draft, but can you tell me what is wrong with using the > existing extensions to RSVP-TE for bidirectional LSPs? See RFC3473. > > On the other hand, if you must associate to unidirectional LSPs with each > other, can you tell me what is wrong with using the existing Association > object? It was invented specifically to allow multiple LSPs to be > associated with each other. > > Thanks, > Adrian > ----- Original Message ----- > From: > To: > Sent: Tuesday, March 07, 2006 8:50 PM > Subject: I-D ACTION:draft-xu-mpls-rsvp-te-bidirection-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Bidirectional RSVP-TE Tunnel > > Author(s) : X. Xu, L. Zhang > > Filename : draft-xu-mpls-rsvp-te-bidirection-00.txt > > Pages : 8 > > Date : 2006-3-7 > > > > Through the binding of two unidirectional RSVP-TE tunnels established > > between a pair of LSRs destined to each other, a bidirectional RSVP- > > TE tunnel is formed. The bidirectional RSVP-TE tunnel can be used to > > establish L3VPN with virtual router technology. > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-xu-mpls-rsvp-te-bidirection-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-xu-mpls-rsvp-te-bidirection-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-xu-mpls-rsvp-te-bidirection-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. > > > > > -------------------------------------------------------------------------- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Mar 10 15:53:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHoZC-0003nf-4l; Fri, 10 Mar 2006 15:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHoYl-00034c-6X; Fri, 10 Mar 2006 15:50:03 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHoYk-0003RU-KH; Fri, 10 Mar 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2AKo2vP008308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHoYk-0006qp-6S; Fri, 10 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 10 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-upstream-label-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 : MPLS Upstream Label Assignment and Context Specific Label Space Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-upstream-label-00.txt Pages : 9 Date : 2006-3-10 RFC 3031 limits the MPLS architecture to downstream assigned MPLS labels. This document introduces the notion of upstream assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-upstream-label-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-upstream-label-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-upstream-label-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-3-10134305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-upstream-label-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-upstream-label-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-10134305.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 Thu Mar 16 15:20:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyvn-00048Z-4q; Thu, 16 Mar 2006 15:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyvl-00048O-Jj; Thu, 16 Mar 2006 15:18:45 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJyvl-0007E7-Cr; Thu, 16 Mar 2006 15:18:45 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2GKIi9W029698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Mar 2006 20:18:44 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FJyvk-0007sj-Aj; Thu, 16 Mar 2006 15:18:44 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 16 Mar 2006 15:18:44 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Definition of an RRO node-id subobject' to Proposed Standard 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 The IESG has approved the following document: - 'Definition of an RRO node-id subobject ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-nodeid-subobject-07.txt Technical Summary In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an IGP area or an Autonomous System. Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id subobject in order to solve this issue. The MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. Working Group Summary There was consensus within the WG to progress this document. Protocol Quality Alex Zinin reviewed this document for the IESG. There is at least one implementation of this specification. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From xdfzwjhtfx@optodiode.com Sun Mar 19 17:05:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL61v-0001te-Kc for mpls-archive@lists.ietf.org; Sun, 19 Mar 2006 17:05:43 -0500 Received: from catv-139-125.tbwil.ch ([213.196.139.125] helo=acer-5xp63ppjt3) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FL61t-0004QP-MZ for mpls-archive@lists.ietf.org; Sun, 19 Mar 2006 17:05:43 -0500 Message-ID: <000f01c64ba1$48f1c5a0$7d8bc4d5@acer5xp63ppjt3> From: "xdfzwjhtfx" To: mpls-archive@lists.ietf.org Subject: Fw: Date: Sun, 19 Mar 2006 23:05:51 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C64BA9.AAB62DA0" 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-Spam-Score: 3.5 (+++) X-Scan-Signature: c2e58d9873012c90703822e287241385 ------=_NextPart_000_000B_01C64BA9.AAB62DA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C64BA9.AAB62DA0" ------=_NextPart_001_000C_01C64BA9.AAB62DA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Staley Pat=20 To: ppvkjrryik@printrak.com=20 Sent: Monday, March 13, 2006 11:50 PM Subject: mpls-archive ------=_NextPart_001_000C_01C64BA9.AAB62DA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Staley Pat=20
Sent: Monday, March 13, 2006 11:50 PM
Subject: mpls-archive

 
3D""
------=_NextPart_001_000C_01C64BA9.AAB62DA0-- ------=_NextPart_000_000B_01C64BA9.AAB62DA0 Content-Type: image/gif; name="hvgxrrdkssnjin.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c64ba1$48f1c5a0$7d8bc4d5@acer5xp63ppjt3> R0lGODdhwAGVAYcAAP///wS1ERiNNM4AZwAA/wgAAAAAgACAgIAAAACAAIzGxny9ven09MFN JPD3902mpuHw8L3e3tDn55rNzcfj42i0tKfT0+x9eSrJzNns7KZTzTyXku6nyuV8sfrp8umM uvCy0fTH3ffZ6OBvHuuaw/zw9txNlfnh7fK91/bQ4+JopU79V7LZ2XchOp+l0IrEmTS0wTsQ ET/fngOLOg9BAAHQZmA4DSaxX9cywHKodTvNcMQfRo7V1lKP9eEVsFZz9hT9nw/2YG9vogma L8yQMHHioaT8y1pjM3lhkfHW/zkLcm2OqeBZEnxzRtsYZHAUm5vFkBq202bW/1RvRZNjnq69 4HlyrgBuAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA5PokAgEAAADMAAAAhQEAAOT6JAIFAAAABQAAALT6JAJ28NF3xQYBazAAAACF AQAApPokAgAAAADIBZJ8eGUVAHD7JAJRBZJ8OAgHAG0Fknz+////HwAAAAAAAAAAAAAAYPsk Agvw0XfFBgFrAAAAAAUAAAD+////HwAAAAAAAAAFAAAAhQEAACADAABYAgAAMAAAAAEAAAAB AAAADQAAABsDAAC1AAAAAAAAAEgAAAAAAAAAAQAAAMwAAAAAAAAAhQEAACADAABYAgAAGO6R fAAAAAAAAAcAAAAAAAAAAAC+ZRUAHwAAAAAAAAABAAEACQAAALT6JAK+ZRUAZHYACAAAAABw BZJ8/////20Fknykx9N3AAAHAAAAAACAZRUAWC5HAnb8JAKU/CQC4wQAAIBlFQDM+yQCCMfT d8UGAWtYLkcCO7YAAPz7JALvsvF3vPskAviy8Xf1////AAAAAAAAAAAAAAAAAAAAAAAAAMwA AAABVmVyZGFuYQDiNxkBdvwkAlguRwLAiBkByIgZAXb8JAI7tgAAuLXvd4a173fFBgFrywAA AF0BAAA/354AdvwkAgsAAAAAAAAAP9+eACwAAAAAwAGVAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat36csGBAxNuTvi6gGvJKD2/HiBIQa0F tgrUKqBgUC1bt3Dl0l2oVu0DCw4I9h0MYLDhgYYPKMhwkELcr3PrfkWYeLJAu4ItX/66dyAE zArHHiiLWDOAtl/fFjaN+oBqw38Dr668VqBXsGZRSsEJWgJegQxuD17AIHNtAL5TDwyemLjC yg+Kb048u3LpxBIIMjfs/Dpl69ML/oKeXaHg4+MIPx94IF5zctfeBb5XXb1v9PqHBz74CiG3 f8wM7IfbQLdNEJgDopEWHgABfhUWgQ4emOBzljnw2IOz8WVafACw8FV5EIIlIVnGfYdeeyeO 1xdjwPW1UAVfZVcigwJimCGNDs5oYY4zGpQciP5xZZcDAip4GmTmceYdkSQOhJoCSR7QmWTH OQDaeAdhueCWT0bZmZZbUomicYoNZIGLCTHwoZhMjjZmm0beCICVG4IpEIwHSBekVnbdFudj LA6UAZLh+RlloAINWqaJPdrJYY+rsScQoAUpCmWYkI4JqVowHngAnicW5OEBLIhp6Jinblrn hgSNWuqe/3xC9pWkmW4p16xi5pqlZnQCCV6tNzpwJqmPcmjnr3KGqVYE8J3JLKsEPdYfio/R aly1u1a5JrACqXcprFhxp2ujw41brI63RXAdYZqiWO65ch5LXbEqfmXlA0zSGSqw4lKpVpwL OpBuu9mCm9W/NRJsLFkJ8wvtdO9iai7EfckmcbwPO4plvWuNBWNYjiZ73QING0cyj2T2BXDI IRvslFoMqHeAugNRSpCl18W8bLRfIQoAzib+SzO8Dtf22LcA2CwooSITLTLHAMjcH8vQwizz 0NPp/BXW+C3A9cVOu/yyZc8eMO2Ri9as5IJln90lz1ImRPW+RQvU5tBvqx032P6O4mlxrzPC COLcBQPQ9oyHhw324mI3BZpo+IZo4JwTcgi5xQWO6KbcDzPetJyt6Zk55U3y3fmzCxz4GNZg hiytrpdbPqvFLX/eLdONSzUengpuN5yeyfK+nHAqAz9xymjCO95jQPpePPKY0UYQ8f8qzLir 4wofpva2c9vhV6/mrrtpairn5HmREVw+fOfrxdDc+Sm/oYD0nYb+lBSjKX1ekOH/ecjlA9Kj 1vca8v2mdn37ivHEx8AG5gRPMvpIDTLyIwda8II2UY+1biKgs2HwgyBcSeVuUqAQmvCEJymh TUaIwha68IUwjKEMZ0jDGtrwhjjMoQ4vWIUd+vCHQP4MohCHSMQiGvGISEyiEpfIxIcM4IlQ jOIABgLFglRRIFJ8YkFC8AEodoADIlgIF70IRixmMYpb7OITPxAChKRAjQPoAAg8QEUtDiQE UOTAQc6YRjKGMSFn1CIHnmgCOg7EA3kM5BUBcMYP/LGOfDTjANpIkBMskpGBhKRBSPDEDhSk A08kAUIuickpQnIAJdDkKZ+oAhKkwCCKXOUaHwnKAajAILX05CGjaEiCkFKVwCxlFmXZylda 0Y6jVKQpS3nMZUZSILUcZkKiKUVJZlIgHqCmF3sJzWsyUyApyGMyqzkQbf7Sl9fMJUFU0Elh PlORxrQmOUt5S4LAEZ3vRP/mQEpggifGM5wDMEEq96jPb1pTlJLEZxY/0ExpujOKxgToAB4J AET6kyCDFGczx7lRWS5SkQzFp0POScqSFjSjegRACVDQz4SgVCArbWlHPxnKVJaAk3EkSC0/ YMgQyPSbHujnABAKyJM+MaUxXSZBlUoQfh5VIDgV6ExFKhAQsJKqS53oLi95zoQaBAWEHIhQ KbnUqUrxBF5NawrYOYCQphWWyLSqLSGZ0qqSsp8mwCtcmRpMg/p1pmtdI1YXQtKCmpSpv9Rl WT+5V4Pgsa0FUSMlAapYmCq2ik7NKWENW1AAVLaxCBEBFFPwWK1ONZhc7ewp3ZpRfXb1r+V8 Igj+AABWzXJ0sFIMaWqZWst4vna3A8moCdb51IEAlAMZjScWocDXt/r1twXtrVgDOlLVHva0 UCSBCAa62aFuVyG/VCNFASBayAJAvODVojoZcljtcre7CpGrUAeAgsWalbp9xSc7bWpL4N7W IJZ84gmEyk3QonaNF/XvQMrrVugqNawCCfAAjFneAaB1IOINsFud21cFG1ggDMawedlrXWWe trWEdKVCUBxQFX+Yw998rSTVONyGkJLFJnBxUR0qYihueLCqLEFGZ+vRBz8RrHocZG2NzOPX spjIO76vha/q4bR685tCli1xhyqQjNYTplcFAFvf29XrFhnIBu3ij6P+vNcrwxaOUVRBge15 RjmfFrYxVq1C22njzsIZinYe5zy3+sQ5wziQn70yFEsQUKcy2rXPxPN0w5xexEJ6ijhdMpo/ GmlEF2TJqRRqfQdSWyLLddQw/utuB/3LRaq5us01c37JywFtrpkgIqh1bu9cWFPKuJQdECpR K32QXNuazdOM4mdnHcj3SpqZnGSnKKuMZoJI9MLExq0WHz3fTSPTwVJ09qMnKdH3stWQj/6y pGX97FYj89V9jjVnLd3cSuK03gC+953Ri2vBnveJ422mBySMamQj5AT6/u9B5CtUKFf7imr8 sYMBIGG0UnvW1X6xf1kM5PISdeL/HvFAcNr/AZwOu8JnfGSZ553xv3pcxLe2L5DZ7dk5QxiX Nsdvfh/7Y8kKhOe4VOWSsa3wmsO1xjIvSIVFUGHlHtqOmS04yNlZz4unGuMFGfM+KW3Q+TKZ pqZtN9RFXRCJjhajyqxrV7UO5rlinZS1fCS8SSxvemN3AGVU6ZCTmfcsD8DheK4lCWxK8i3z FJw/XWRUnX33vu+96IdsuF0DWuBe3xGKvQS5lA2edITUtgM2VaPUkbnkr4NY8C1fZGkL7HWk S/K948b450N/5NQjUwSop4jlsZrPRu54oS/GpjnjyE0PsNWhl2TrsuX57UDGnPlXXG83bft0 parxy7Gs/p7RCH2W/jdk+InWZ7eLLPKHctr6XAeAXLV8+fKHnJLZ9+wZw9974Lf8zqpu/jw9 AAI45tjpBcF//qdjLTdGa0RWfdRJIMBdl2RReJdViySAUPR/3TVMwlV8QlVXeHZXxRV/u9d9 zuRmv0YQBthWCPhWErV9rRRwHlhQGUgQDjgA3CRdZcdn8QcAJchGbTZPWbSCwddEQBiEQjiE RFiERniESJiESriETNiETviEUBiFUjiFVFiFVniFWJiFWriFXNiFXviFYBiGYjiGZFiGZniG aJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiIgjiIhFiIgkgDhpiI/4q4 iIzIFAZgAEv4iAYhiQxBiU9hiTVkiZSoiZAIAI/4iZ0IiqD4EJg4EqUYiqIoEJzoiaJ4ip2o iq/Iip84EK3oiqMIi5h4i6xIi7FYELUIiaW4iwxxA71oisVYEcFIEMGYjCG0ia/ojLwYjdKY E7NIi7A4ic8Yi8yYi9k4jdd4EKv4jeKIiuKoENz4E8w4EekojMp4jM0IjNoIj+3ojeuIEJwY jCugi9C4i6fIjuSIjexYjvMoja44kAA5jt0IkPVIj/qYjcvokMUoifsojPcIj9VIkP8oi6hY jbeYigJ5QrqIi70Yjh9ZiRl5kPvojBepiv5YkrJ4kDBJkSMZj//2mJD+eIwhuRDnKJMuyZM1 aZE+OZElmZIRmZGaGJTuCEIriYswuZPY+JA9SZTfuI1TKZLcWJQ/6ZEF6Y0GSZLJuJQ6SZNI mRBC6Yv/KJUBmZZTaZQdaZNr2ZMflJNy6ZFc2RD3CI5nmZf2GI0n2Y5YiZcDuZUu2YpdiZNg SZZiOZGHeZcoqZc36ZZ8yZJoSZJvqZYmJJE06ZQx6RCCiZGVSZXX2JehOZM1GZikWZeDCZmj yZmJ2ZdQaZCeOZam+ZNM+ZmQWZYvpJhsiZgS0Zm2WZmT6JcfSZnbKJY3aZalCZjT6JiWGZBo WZe+KZtliZvlGI66aY3P2ULWmZDpuJD/jVmcV0mdnoicGnmdqOmc8QiWxYmX4bmcolmdjpmT a/mVzKmVK6mexlmevLiR8ZmUJ9QAaeidjciH/jmgBnqgCJqgCrqgDNqgDvqgEBqhEjqhFFqh FnqhGJqhGrqhHNqhHvqhINpEQRCiJFqiJtoQrLIqybMZkuEunYMfprE/tFEbyII87RE07FI1 NEo3tXOiKJoi6AE1LJoZqsKjQFoaP9qiRFqkSLornOOk//OiPuoQMXqkNzqkWJqlWtqkSyql W5qiQRoqmpExdLMaUKolK7qGTFAVY2qlStqmV6qkcdqkXmqmc4qlZLqleqqnlrEWdWKnU1oR fSqmRjqkYPod/1DapWW6pIzKpXkKqHfaqHQKqZNRp4H6pDqKqGaaqYkqqXZao1/qppCqqDh6 JfvSp3i6p5f6o61TqPXRqZ46qnD6PoQaP3s6qJoKq4ZqqDu6qhRhF4d6ppVKqLkKPWGapHEa rG/qqrr6qUh6HJbqq8kqqqSqpY8aqbEqp1wqq656rdo6qRCzrdJKpcfqqbNqrcTarOJarOga qeeKrXxKo40areParo9iqnMqpN8Kr+6arsryrtlqr4Uxr4tar/uqohvjr/lDIRQyL+Z6qkCa puCxP/kTpAxrsBibsRq7sRzbsR77sSAbsiI7siRbsiZ7siibsh5RABvBsipbFAUQs/8uOxIz WxAyG7MkUbMEobMC0QIAcLMDcbM4+7I5u7NFexA1y7McIbRBO7QGkbQCobRIyANOKLVQ+7M/ y7Ja67JAG7VZy7VdG7RGi7U4O7My27ROi7VPq7Zri7RjK7VECxJW+7Zma7Z0K7Zsa7N367Vs q7Vjm7diO7cMAbZnG7ciIbh8e7V8m7hvixBX+7h6i7cKkbZ/mxCIa7gr67iNK7lfW7iQi7Rh +7loW7gLQbqc+7RwC7eYexGXy7WVq7SiG7myq7Y6q7qaC7ipW7qrK7ebm7WLm7ex67pu27aM 67WKm7u4G7mwW7m7u7Sme7bC+7udy7l1W7vDu7ikG7aAG7X/2su0ieu909u8MWS7IKoEYki+ 4pu+6ru+7Nu+7osT6AsU8asT8+uxoUsRsCu09dsQ4JsR+ru//PsQyIu6Tqu/Jxq7EKG6AOwQ ituyIRG//eu7xEu7q7q8z5u9nWu6p3u/ZQu9lPu7rlu2aDu6lmuzGDy04Nu13mvBbru8eLvA F5q/L7y32/u6NGy30gu83DvDxsu8p3vDvUvBPky2bUu+hPvBIXq/PFy8OWzDS9y3Pxy80tvA Q8zEOnzFEGy9TVzFMGyh0SvEVqzAO7vCf4vDY4zBT5zBl5vBIEy3KizABWzAqFvCl/rFdtzG dNzExxvF1wvGWzy7UpzGf1zEE1zF/z/8oYEcyLeLx3ucwy7MxH57yFccxk3LyLOrvBP8xdSb Oz5AhEqMvWg8woX8yVDsyH1cvSS8yNzruSYcyeG7ynqsvZusxqn8vlbRxZdsyw4kyxaBy7r8 y8AczMI8zMR8EwjwEMecsgiwzMkMAM0sEsz8zBMRzdL8E9VMENdMsgIgEM+czNncEc38zQ3R zUMhzuJMstVMzc7szN7MzANxzO78ztFsEOH8ztjMzfZcEOTMzfHMz+Hcz/MM0O7cz+y8zPZM 0Orsz+080PJs0PhM0PV6zd1cz/ns0Ot80fisz/mM0RdN0fdc0R9dz/vs0d680SVd0RS9zxrN 0Sed0RZ9zv9TOs8ZPdMsTdMtzdEK7dEYDc8HkdA1jdMjbdIzndIhXdQbbdQujdQ4nbE3rdId rdTpDNUH3dM2ndDSHNRDndUubdVSndM2/dU/zbFN/dFJDdJHDdYqzdP0LNRrTdZPrdUkTdNH PdY/jdVlLdfSatdh/dZ3bdFzPdRO7dZ0LdJITdRw3dX/jNaI7dYRjdAGfdUATdYMrc8y7c97 zdgLPdH//NJsHdcK/deWvdkv/dgNrdMwnb6nvRCpXcxmUdkVsdqsHdtEUQSyXdu23aEw4LEJ 0BQJsNu7TRO/jRDBrRDD/RQ5QIe+DQDD3du9TRDMvdzM3RDNPRDFnRHVXd0Sgd3/0v0Q2l0Q 3b0Q2v3dGhrd1O3cArHc523exJ3eyv0R140R4p0Q8V3eDDHfBxHeJZrc+N3e9I3e6t3f7C3c yj3d7T3dz33e0e3bB27e5I3gBr7gC17gD57g1N3g2A3hAw7dBK7gz63hEx7cCp7hHM6g3/3b /u3f9A3g4r3hCJ7i/A3iAe7dMM7f7I3iLz7jNg7g3m0QLE7jN+7i/+3jJj7jNG7fA2rh6p3j 123iLc7jSR7kTF7jAq7jUu7iUV7lMU7lQC7kMX7lPg7lT57iRD6hXl7mDh7hDJ7lXL7mWO7l YL7mHm7gYR7gHa7mGW7lXZ7n9+3cdc7mYy6hZs7mdl7l/++t5Seu5W9+6FsO53P+4uvN6IY+ 5XaO4n9O4o0e6ItO6E4e6VTu5ngO6Xqu6Fju6PId6pcu6aBe5JmuoGje6g2e6dB93xFe3LMu 5gR+5h7O50Pe43Te3CCO4TLO60WO5LrO4x/+6aquskZeEct+27xNEs3u7AhhBdJe7dZ+7die 7WdIBNre7d7+7UtEBeA+7uRe7uZ+7uie7uq+7uze7u7+7vAe70JIACZB7xlLAPiO7wOR7/lO EPy+7/xu7/q+7wAQ8ANP8P7u7/0uEAZv7wCf8AUf8AwP8RPP8AsvEQ4/Ehlv8Qpf8Qgf8QPf 8AUh8Rb/7w8P8Bd/EAeP8gJv8P8jn/Ewn/IwT/EbPxJLYBUzX/AIkfM1H/EUr/MqP/IfD/RD 3/EI3/M5X/FJDxE9/xE1v/IhL/REP/VNz/MJAfU///JS7/FTb/Qen/RL7/BN70JWbxBVH/Ri n/VFL/Bmr/YTn/Zd//VEz/YKQe8hf/FiL/N6f/AmX/Ir//aA3/V0H/SEr/Q7L/duP/hjH/eB D/RPL/dwz/gvVPZbX/kEH/mSv/GDP/RnD/dIf/lHvxB8D/Gb//lxT/mn7/iqT/pXf/ihT/iY z/iKX/eH7/ltP/e4z/UyRPIgv/BVT/J0v/QKD/y3r/uv3/J9z/aln/Kcz/pUD/vFv/rGb/eB r/ksb/n/LJ/3Jo/6qf/6rn/7wV/8ys/1i49CpV/42I/7wr/20+/26m/8jU/96E/+xN/7fJ/8 97/9at/yhp/47n/+AAFA4EACAwEUPGgwoUKEAhE2VOgwokSJDyM2LIhxIcWJHT1+BBlS5EiS JT9q5GgQosqJGiGuJMgwZUqYHDPOjOmyI8yXLXFuBEqxZk+ZBy0GHcrSp82WBJw6ncnzKdSg RS/mxKmzolKTXb1+BRt2p9KaQI9aNcoV7UaiMZc6PHtVbVu3NIWSVXvXLUaectnWNTt2r1+s gLPaNQyYauC8ZcU+hhxZ8sqMU18+JWiZJt3GKjGvVfxQs2HKn9dOrYs682fV/nAXG70J+nLp 11Wjwsbcd7Ts1ZQFw/VcGyloycWNH0eeXPly5s2dP4ceXfp0kAGCW8aeXft27t29fwcfXvx4 8uXNn0efXv167NTdv4cfX/58+vXt38efX/9+/v39/wcwQAEHJLBAAw9EMEEFF2SwQQcfhDBC CaUrYML/KgQQwwU1FJDDiDwssAARRewIRI9G/DAkFAdaUaAWXTQxRRYNepFDG0mcaMQYXSRp x8he/EpDG3mcEQAdYdTRRxqFhEzJ/EBkUkX+nHSSSCOXBClKLYu8cqQorfxySCtp5FJGkaoU C80suQyTTTJLwrHLNAmEsswTp/wwziO9nFFNDLck/lLNLsUs8s837ZRTSByPrHBRPVl8NFAU gcwR0jiNvNTMQd8klFA+DUWyUDAvNbHFPTElNdJBa9Qz1UwZZfVPSunbE1A5P7J1TTB3RbXK RhXy0NBggTUT1E1hdPNYZY39ssRkmyW2T2KHHVPQK0EFFNtK70yUV1uZ3fXbYhE19klga0V0 3DG59VZUSWWFN9pCX5XXUkVXbDZbdANNlt1c2UX13GCBjJFSYZFc9NpVPwQiz4T5hXjZdpfE l9x+99WP2kOVvPFUZzee+NaPPT2W5Drr5XXikyVeV11lceU0ZjtxaFnXX0VW+GZkLY4Y3G5/ /ndlod19GT+NfcZ5R5KT/iYaaX9BTvlnlIEuM9umU4YW65CrvjhdnHXFVOuWlxaX6p5D1tlp sf+9D8pWSXWYXnJPjZXiMw8NmGtLPxYYy4HDdBXprCseNWupXy4X77t3zhtruHMknOXGe3X8 XopLTdteSC00yVrOKVTO8/5E/7x0xU2nlTnS8/sBdddfhz122WenvXbbnUvidt135733+Hxc HSzRV54y+OOI9x3m5Jvc1j+lF1f+a68wfx7O6b0ONWxkk3x11oynln75zpsfHWDzmzfea+DH 78rwaFs9PWo840/f90YJrntvhTbQ3tSm375cimqVqaQ5invZu5bb4CU0fDXwXgt8H79gRUBR /v1qaVHLX+O2ZED9IZB8A6Sg+Pj0tcHVjHFlS1zZZBa+o4ltYeoq2LNkGDGZaUt+FVSY+rom MhS2iW3kk1r9epe4ysmKb71ikpY69jCmJSqGlxMcxuRFxLXZy2elytnZTGjDC1LOiowzG+IE 5igpQS18IrQZ+jBIPCzmi4gl5CHyhjY2vlExiDf8oQVL1q8IinFbXWTiFRVXsPWZUYi8o6IK 6chHk6FNRsjj4dW2BrUnhhGFdZSk9FIYvzuuS5A0TKKd4LjDM6Jxii1EmAdFKbd32U1zp5zc FydHRg2eSFWuBBwCczlFNmXOlZHUYS8t10Ev/q2DNYqbEb1YSlM2/9OZnzvkM6U5Tc5Fk5rX xGY2tblNbnbTm98EZzirOU5mlvE91ixOCNv3I+eQiHToNE6SoGfIEbLwgHSakwlt6T32QQdN 1Dvh/eQpRHjy8nrz65Ea9WnQ6IUon+XEW/oKer4jvk9REWWn6rAHtu/1jUf3JJMej4lEgVZv pIX7ZZ/i9cpaGhBbsfpbSVMqypM6EXAP1FwGQajAVD4yi+ojoMf8B7RJuUqlARRSEzoWwOIF 8oTOEilRSVkvH/7RljNsoqpsKLkdjlKLl7RkFb+q0Orp8YIm/WQOO6lEskrSffVBJSB/GsZO akqeq6SlXTGG01tZTYv0RKKmVuW/B241rf5KjFwiieZTP54Lk2Ft07uYaFCwQvSclOWkWbFa V6oe0Y12heFi/cpVsVZUsXCsLNvyuNg+lktpcxRXZIumSbdmsqObRSslAQvacPGxiY6k62jV tlaeubCv7kptbWm42T7qraJhPW5XWYvVw5bPo3FUaE23F8ya8nVWxmSpFItZRMgFkYJ3JWYc ZyDM8F5Mq5u7Lk89Sb/z6hSjlePuMD3oMQRdwH4adSjqPDdRcSqIn485sHVNZy0CF9jBD4Zw hCU8YQpX2MLbtKOEBGVNXwnWsmGB5HIO2YMLJ8ekEOpwOue5yCDVc3oJ/h1IS7xiTm6Ixg9t KIsPas51bjR17/45AiKHOkz+0q1/gfvoSinnPVN9t5hBJaZO37bUwjGQynkDIVM55eQSPYqD Nj1mBnM8VDCnd5p+Xa2kqAvGTMKWZ28d7ibHCjHU2lZyccbjY29JWjxztKqMxTByJ7m1yvZU tmtubggX6N0lVpe0LFMgs/YK6BAHV0yRJq+fhTpGNl8TzdMNrnKB+9s+DwzQjHyjcuu8XEXm +XBbnO7D4mrnD3q2ag0m5x7piltRQ5fUroako0X9yVVLTIWlTtelQW1Y6B76vt1y9lvFZ+Qy s5naUY6coX2ry+K687zY/jK3UVrlYhm1p0deIqW7bO6+anXKmabtL2+q5A/r7pDBw//1jDuk b+tltHPq5Pfr8h1wghfc4AdHeMIVbiEbLFzDFR448xgUcRVT1MD89bEs95lS/M3zytFVJUuB mOPjAbyeyp6XS2H8VATjk6EkV7DFYY5oZ0evU4xMNvZM9IKRH0/idT00g6WdUOUYATlz5OiF HCbymVt1ziNsZGNZTORJoZu93ioqlUR+YJSD0rmfGreuZwk5vi6zlpKVN5KRmj+M72fSr37u YyG9cp3NV612123PIuvomjN0uFwbFioXWilm6xqL3Epus6X116ku13lj/Dv4av30lToQZfQG ppbvmi/kvr3vgE2xKvHHyuviMLBZVCZ9nar4pyOsz+adrNL+Tzf0cs6a8SMbpNdn72HO0zm0 N/T74Ks1fJBLHvGz1Sx8pw7cxGts23sHNUJHffjdY/b22QW6GavPVeFOHwAxICHNeZv9nttc cMX9NeshfbVWE9fxMdclMnmfTHDP1NZRjqiiye63+IL7/GNbvbN7OdeCtX7TnrELO01KLPx6 pZvyv/KaN+WzHYobotB5EAp0OAzcnQbTQBNzuA8EwRAUwREkwRI0wWfSQAxMNQM0kNBrOhdz ux1rkg6UD9rjNOG5E+drsXrbtixZuX4ipD2LOw/rJ+lLOn+jwctaKAxwmR4jPDPrsXfKuJf7 OeqbrfIzPhi8LR6TDBt0kAn6OFT/k622k7EnkjTVOrecEjMxPCqhUjmCIbsr0y8tm6WgEjPP +y7Core3CxhGCTNFe8Nwu58vRDQo6prPq7sCLLwVHKX2Q68tE78tEjxBW77m+r31uz62Yj72 GzblGcNOM7BnwbiuCyXguztYE6nNW6RGTDkoEyYClKzIYzmbeimDeUVQJKoF9DVeozy8Ezam mrcMQxDoA5jzqzkZo61UPLVMZK7OCjXHoz2+WyhFckXk60Tr20RWu8a8g7sktMBR05veA75E 1KdPtMZuLMRwFK1tvC+wYsVXc7NeREfdw0RjY0fve78N8aVYcr2ZiqknNMQmHDJ1yxPYi8N0 A7k5zKv2/yK3ajMky4sbjmuyAGTIBzy3Jqs2w5EiQdQmbzxBLQTJjwQwkXwSk3tBkkTJgBuC lGTJlnTJl4RJDaskEbuxmLRJmpS5isPCm+RJD8zJLvzJnkw4JgvAiay/UPHD9zPKVJpIB1yy P/RIoZxAwYqtxSsawVtBtfq/7lO/qJRK2BnFm8u8fjzAsiTG3PsrYvM8WvvKCHOf1dNBQsIS 90PLO1OZS5TFtiwwOHOkUhxLu/y1Y7tLefRCvfSmsERIDQKg+HOj2GPMriIzVsnIKTTMymwO r7TMzPQ5zeTMzvTMzwTN0BTN0STN0jTN00TNytyB1GTN1nTN14TN2JTN2aTN2v+0zdvEzdzU zd2kDh3gzd8EzuAUzuEkzuI0zuNETpBwjOSMzddYTpEoC7poDcZwjehsjfbIDtygDc7QzrhY COd8Tt58AgNxTrGITsXgCpRADLTwzrlIz/ckDt9Ii8xgzgI5i8qYDfVMiN3Qi8P4zryoCqJw DOn0z74gjP+0CP2sT/64T5QQULzwCfnECwlNjAf9DcYwUAM9ja3Yz8RY0IiYgviw0P78z8Fo igP9Tg2tULLgz/xU0BK9DqqQz9iIDemQgQ/1ihGF0R1tTw5d0Q4FUKkwjQGF0AJF0eFI0Z/A 0fxoDwwt0h190gxdzx8ljvV80fZMCgiV0SX1D92IUpv/6NG/QE+mGNP49AgCtdIjFdMA9VAu lQ/dmM44hQq+oND8dM/euNDeKE/SwFM9xU/TgI0gbVM3JdRCBQv2QNREVdRFPQ9DddRHhdRI VQgNkNRKtdRLxVSIk52C8kjjkUItxExPyz9PCUPKfDwZPElTjUFUhR6J4jdxDLqcszFWHUIi HJBPNUBX1TdYpES82zp2SztALDs3TKKBakWVcie8wrw0lDKcWkO0Y8A7U7saSjJv+7Zxy7Ik Y8xQDZBEpBZvnZpi88Ruy8YXosutOkXjKldfOsuTab51ZazCSz/BLEu2RCM43LK4dJkB2qfX k0Z6dMeQyi7YEi96fcS0PFda/8QzZeQsq1RFsvxHuDMlXvU9msLGG8HLjFW/hBUj6ntHOWqz adSadp1HpmHYvtvH5+NGbpW9hMS5mmm1eJzXaxRLTNTBxutKX0M24iO0lR1YdXWurfTZMxvV Z+PHTCNKioTKX4UWl0IbOFtWs2tWUuIycRQ3T5rW3UrWAsS2q9U24fvMSmunTD04sR1Jsq2d EUDbtWXb5HCCtoXbuL1NYWw5LrRbosPBjDkxsN3akSsk6jDbhSOwe1PVLKzJb7zbwqyx7etB W8UxkhxcoATbWg1JxD1Cib3b+aNCys3bERzIG9yvd0vAY+U0Yl03/XLKjGzKOmQ0O4QgNXS3 f0Rdpv8DQ1wymMVcMtEdrI/7QWwarUi02TcjV2YkzF4Vtn/FRtArR1Ub3qxSI4M13kHby14V RV3UF1ssWcSqxkVz2H0REhfQWYhdtvFVmUri3kcbw2yzWMDkys1jWRSj3kEL2OOrxCtsRq0k SOhN3vs9y3rdNfQF3roU2oq1X5PsyPjNWbMpNqTzVwzKu8SrR8VSSuaSWXmVrgn+qJBVYDt7 3y+MFEw7ymWaQ7bs2xEOL9ITwNV1ociUQK/lPzq71slMw82JwE5byrX6XNXt4E3dQR6W24nr 4djZ4R8m4iI24iOOSSFA4iUGYlqNJ8dlYh+u3Mv1SR7M3Chu2cOl4qMrXC2mxmK3g8jsoRv7 Cl2lNbzcjWGFtNbA20Pc3SAle9YvJtl3Dd/D4yKVXUXwea/Mu6I/s98vVlhfzEbBbKMc+r9p AcazCsjHqcc4aqC2RILa8aoEPt7wO9ke3EeMDT+gKte/bGFAnmOaBcfcQtjJAyYrbNpO9stJ xOJww7I2i106JGUnwtyIlcxBwl3WTSE3ZmRA/rHJ9WXP7eVgJuZiNuZjRuZkPuKAAAA7 ------=_NextPart_000_000B_01C64BA9.AAB62DA0-- From mpls-bounces@lists.ietf.org Mon Mar 20 11:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN2s-0006Mm-Rl; Mon, 20 Mar 2006 11:15:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN2q-0006KH-Vn for mpls@ietf.org; Mon, 20 Mar 2006 11:15:48 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLN2p-0008K1-Ni for mpls@ietf.org; Mon, 20 Mar 2006 11:15:48 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Mar 2006 08:15:47 -0800 X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="316263123:sNHT23669356" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2KGFlYg026018 for ; Mon, 20 Mar 2006 08:15:47 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 08:15:46 -0800 Received: from [130.129.131.118] ([10.21.123.0]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 08:15:46 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mpls@ietf.org From: JP Vasseur Date: Mon, 20 Mar 2006 10:15:09 -0600 X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 20 Mar 2006 16:15:46.0724 (UTC) FILETIME=[8BB2DE40:01C64C39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-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 Dear WG, Right after the presentation this morning, it was suggested to gather feed-back on the usefulness of this ID before moving forward. I got some feed-back off-line and on-line (Kenji - KDDI). Could you tell me whether you think that it is worth being pursed ? Send comments if any. Thanks. JP. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Mar 21 04:36:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdG2-0005IL-L4; Tue, 21 Mar 2006 04:34:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdG1-0005Gd-D1 for mpls@lists.ietf.org; Tue, 21 Mar 2006 04:34:29 -0500 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 1FLcVN-0004e8-JT for mpls@lists.ietf.org; Tue, 21 Mar 2006 03:46:17 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLcGM-0007TQ-Fv for mpls@lists.ietf.org; Tue, 21 Mar 2006 03:30:48 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 09:30:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Mar 2006 09:30:42 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603310DC2@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPLS2006 INTERNATIONAL CONFERENCE] CFP Thread-Index: AcZMwb4AKzPvaPWxThKRbiKvrV7lrw== From: "MOIGNARD Renaud RD-CORE-LAN" To: X-OriginalArrivalTime: 21 Mar 2006 08:30:43.0677 (UTC) FILETIME=[BE9988D0:01C64CC1] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Subject: [mpls] [MPLS2006 INTERNATIONAL CONFERENCE] CFP 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="===============1425138139==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1425138139== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64CC1.BE3B4FEF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64CC1.BE3B4FEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS 2006 INTERNATIONAL CONFERENCE http://www.mpls2006.com OCTOBER 15-18, 2006 WASHINGTON, DC CALL FOR PRESENTATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MPLS 2006 (), the 9th Annual International = Conference on MPLS and Related Technologies, will be held on October 15 = through 18, 2006, in Washington, DC. The Program Committee of MPLS2006 = is soliciting presentation proposals for the conference. If you wish to = suggest a particular topic for possible presentation at the event, = please send a one page proposal (including speaker's contact = information) to the attention of the Technical Program Committee at = mpls2005-cfp@isocore.com by May 26, 2006. This year's conference will include, but will not be limited to, the = following topics: - MPLS in multi-area and multi-AS networks - Point-to-multipoint MPLS and applications - Supporting multicast in MPLS VPNs and for VPLS - Single and Multi-hop Pseudowire placement, setup and management - Providing QoS in MPLS networks - MPLS network management - OAM for MPLS networks - MPLS in the Next Generation Network - Voice over IP/MPLS - IMS an IPTv over MPLS - Triple-play applications on MPLS - MPLS-enabled Advanced services and converged networks - Interworking and migration for MPLS and GMPLS - Multi-layer networks and integration with non-packet technologies - Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Testing the technology: MPLS test tools and experience - Protection, restoration and reliability - Network processors for MPLS and GMPLS - MPLS/GMPLS control plane resilience, scaling and robustness - MPLS TE applications of the Path Computation Element (PCE) - Motivations and requirements for extending MPLS into the access = network - MPLS and IPv6 The program committee is looking for original and unpublished work to = continue the tradition initiated by this conference in 1998 of covering = cutting-edge topics. Presentations addressing new technologies and = operational experience are solicited from network equipment vendors, = service providers, the research community, and government and enterprise = users. Renaud Moignard Head of R&D team - IP/MPLS networks france telecom R&D / CORE/CPN 2, avenue Pierre Marzin, 22307 Lannion C=E9dex, France Tel : +33 2 96 05 35 28 - Fax : +33 2 96 05 18 52 e-mail : renaud.moignard@francetelecom.com ------_=_NextPart_001_01C64CC1.BE3B4FEF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [MPLS2006 INTERNATIONAL CONFERENCE] CFP

MPLS 2006 INTERNATIONAL = CONFERENCE
http://www.mpls2006.com
OCTOBER 15-18, 2006
WASHINGTON, DC

CALL FOR PRESENTATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
MPLS 2006 (<http://www.mpls2006.com>), the 9th Annual International = Conference on MPLS and Related Technologies, will be held on October 15 = through 18, 2006, in Washington, DC. The Program Committee of MPLS2006 = is soliciting presentation proposals for the conference. If you wish to = suggest a particular topic for possible presentation at the event, = please send a one page proposal (including speaker's contact = information) to the attention of the Technical Program Committee at = mpls2005-cfp@isocore.com by May 26, 2006.


This year's conference will = include, but will not be limited to, the following
topics:

- MPLS in multi-area and multi-AS = networks
- Point-to-multipoint MPLS and = applications
- Supporting multicast in MPLS = VPNs and for VPLS
- Single and Multi-hop = Pseudowire placement, setup and management
- Providing QoS in MPLS = networks
- MPLS network management
- OAM for MPLS networks
- MPLS in the Next Generation = Network
- Voice over IP/MPLS
- IMS an IPTv over MPLS
- Triple-play applications on = MPLS
- MPLS-enabled Advanced services = and converged networks
- Interworking and migration for = MPLS and GMPLS
- Multi-layer networks and = integration with non-packet technologies
- Deploying, interworking and = operating L2 and L3 MPLS VPNs
- MPLS deployment experience: = scaling, performance and security
- Testing the technology: MPLS = test tools and experience
- Protection, restoration and = reliability
- Network processors for MPLS = and GMPLS
- MPLS/GMPLS control plane = resilience, scaling and robustness
- MPLS TE applications of the = Path Computation Element (PCE)
- Motivations and requirements = for extending MPLS into the access network
- MPLS and IPv6


The program committee is looking = for original and unpublished work to continue the tradition initiated by = this conference in 1998 of covering cutting-edge topics. Presentations = addressing new technologies and operational experience are solicited = from network equipment vendors, service providers, the research = community, and government and enterprise users.




Renaud = Moignard
Head of R&D team - = IP/MPLS networks
france = telecom = R&D / CORE/CPN
2, avenue Pierre = Marzin, 22307 Lannion C=E9dex, France
Tel : +33 2 96 05 35 28 = - Fax : +33 2 96 05 18 52
e-mail : = renaud.moignard@francetelecom.com


------_=_NextPart_001_01C64CC1.BE3B4FEF-- --===============1425138139== 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 --===============1425138139==-- From mpls-bounces@lists.ietf.org Tue Mar 21 12:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkjQ-00089P-2h; Tue, 21 Mar 2006 12:33:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkjO-00089J-Do for mpls@ietf.org; Tue, 21 Mar 2006 12:33:18 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkjO-0000iN-2H for mpls@ietf.org; Tue, 21 Mar 2006 12:33:18 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 18:33:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? Date: Tue, 21 Mar 2006 18:33:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? Thread-Index: AcZMOcYPsOpGHWH0SESD0fb+XirXlwAzXNrw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 21 Mar 2006 17:33:15.0329 (UTC) FILETIME=[88E57310:01C64D0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 JP, all Advertising within the IGP the number of 0-bw LSPs sounds useful. This = would help data plane load balancing but also maybe control plane load = optimization (avoid concentration of RSVP-TE states on the same LSR)? The proposed extension is quite straightforward. This implies similar = IGP load as the unreserved bandwidth sub-TLVs, provided that appropriate = hysterisis and dampening mechanisms are used. By the way why not also advertising the number of non-0-bw LSPs? This could also be used for control plane load optimization... Hence the work should be pursued. Regards, JL=20 =20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com]=20 > Envoy=E9 : lundi 20 mars 2006 17:15 > =C0 : mpls@ietf.org > Objet : [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? >=20 > Dear WG, >=20 > Right after the presentation this morning, it was suggested=20 > to gather feed-back on the usefulness of this ID before=20 > moving forward. I got some feed-back off-line and on-line=20 > (Kenji - KDDI). >=20 > Could you tell me whether you think that it is worth being pursed ? >=20 > Send comments if any. >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Mar 22 12:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6n6-0006vr-3f; Wed, 22 Mar 2006 12:06:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6n4-0006vj-SC; Wed, 22 Mar 2006 12:06:34 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6n4-000050-Fb; Wed, 22 Mar 2006 12:06:34 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FM6nK-0008Vx-00; Wed, 22 Mar 2006 17:06:50 +0000 Received: from Puppy ([130.129.128.226] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 17:07:01 +0000 Message-ID: <00c601c64dd3$96bd89c0$e2808182@Puppy> From: "Adrian Farrel" To: , , Date: Wed, 22 Mar 2006 17:10:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Mar 2006 17:07:01.0281 (UTC) FILETIME=[091A8910:01C64DD3] X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [mpls] Fw: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) 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 FYI, Here is a liaison sent by your ADs and the chairs of MPLS and CCAMP to the ITU-T in an attempt to get review input to T-MPLS. Thanks for the discussion in MPLS (and thanks for only shooting me a little). Adrian ----- Original Message ----- From: "Adrian Farrel" To: ; Cc: "Scott Bradner" ; "Adrian Farrel" ; "Stephen Trowbridge" ; "Ross Callon" ; "Bill Fenner" ; "'Kireeti Kompella'" ; "Loa Andersson" ; "George Swallow" ; "Scott W Brim" Sent: Wednesday, March 22, 2006 5:01 PM Subject: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) > From: The IETF Routing Area, and the MPLS and CCAMP working groups > To: ITU-T SG-15 (Yoichi Maeda) > Cc: ITU-T WP 3 (Stephen Trowbridge) > Scott Bradner (IETF-ITU liaison manager) > Scott Brim (IETF-ITU NGN liaison manager) > Title: Liaison on issues related to T-MPLS (G.8110.1 and G.8112) > Response contact: Loa Andersson > Technical contact: Loa Andersson > Purpose: For action > Deadline 29th March 2006 > > Dear Mr. Maeda, > > At the MPLS working group meeting in Dallas on March 20th there was a > brief discussion on the Transport MPLS (T-MPLS) work taking place in SG 13 > and 15 of the ITU-T. > > The IETF and the MPLS and the CCAMP working groups have not had an > opportunity to comment on the documents so far. We also learned that there > is only a short time left before the Recommendations are scheduled to be > completed through AAP. > > We would like to ask that the ITU-T SGs liaise the draft recommendations > to the IETF, and in particular to the MPLS and CCAMP working groups, and > at the same time give us enough time to comment on the documents. We > appreciate that this may require a delay in the normal document process in > the ITU-T, but we feel that this would be desirable in the interest > of cooperation between our organisations and for the wider benefit of the > industry. A process to change and extend the MPLS and CCAMP specifications > will be found in draft-andersson-rtg-gmpls-change-02. This process is > being developed in cooperation with ITU-T, and we are working to > incorporate the comments received based on this information exchange. > > We believe that there may be some issues and concerns with the T-MPLS > work, but we have not yet been able to review it and the time frame for > the AAP will not allow a detailed coordinated response to this work. > > If this it is not possible to give us time comment on these documents, we > are concerned that any Recommendations related to T-MPLS may be > incompatible with current and/or future work on MPLS. > > > MPLS working group co-chairs > Loa Andersson and George Swallow > > CCAMP working group co-chairs > Adrian Farrel and Kireeti Kompella > > IETF Routing Area Directors > Bill Fenner and Ross Callon > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From cwspruykua@sonicnet.com Wed Mar 22 13:22:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7yr-0000W0-IS for mpls-archive@lists.ietf.org; Wed, 22 Mar 2006 13:22:49 -0500 Received: from enh199.neoplus.adsl.tpnet.pl ([83.21.253.199] helo=hotel) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM7yj-0003HM-JY for mpls-archive@lists.ietf.org; Wed, 22 Mar 2006 13:22:49 -0500 Message-ID: <000a01c64ddd$981e46b0$c7fd1553@hotel> From: "cwspruykua" To: mpls-archive@lists.ietf.org Subject: Fw: cwspruykua Date: Wed, 22 Mar 2006 19:22:36 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C64DE5.F9E2AEB0" 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-Spam-Score: 3.4 (+++) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d ------=_NextPart_000_0006_01C64DE5.F9E2AEB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C64DE5.F9E2AEB0" ------=_NextPart_001_0007_01C64DE5.F9E2AEB0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Ricks Williams=20 To: aikqylx@otl-upt.com=20 Sent: Tuesday, March 21, 2006 10:12 PM Subject: mpls-archive ------=_NextPart_001_0007_01C64DE5.F9E2AEB0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Ricks Williams=20
Sent: Tuesday, March 21, 2006 10:12 PM
Subject: mpls-archive

 
3D""
------=_NextPart_001_0007_01C64DE5.F9E2AEB0-- ------=_NextPart_000_0006_01C64DE5.F9E2AEB0 Content-Type: image/gif; name="bwbwukbolsi.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c64ddd$981e46b0$c7fd1553@hotel> R0lGODdh7wEYAocAAP///4loaL+ysuXh4QAA//8AAAgAAAAAgNDT0Gh0aABAAJqhmk1fTaes p/Dx8GoAAHpNTayamtfQ0L29zdnb2XyFfOzp6ce9vZZ8fNDQ24yMrGhomIyUjL3Bvenq6fPw 8Lanp/Dw9LKyxenp7tnZ4ZqatXx8ouHh56GMjMfH1NDHx01NjKenvbK3st7Z2f1SfNzAveHj 4Uew6XlsJw9MAcfKx+8uK4DYONmp4D1VqbpMJc+90SrEW+eSdZTFfMSRsh/AhEn3/9FUC3tJ vDJ7kZZwzhpYM7nxIpQ5IRdB//DRlObW3BzFSl2wygUNMZKlX8/ENYtM91/sYLJx2pKOlJ7B zNOy3kf8TNW0sy2RSvzMHtQoRP5qtGXt0I/gr3C0ZXRcCGHbEP+Q56riDwAAAAAAAAAAAAAA AAAAAAAAAAAA5PrDAMwAAAAAAAAABgIAAOT6wwBZAQAAWQEAALT6wwB28NN3lA8BlygAAAAG AgAApPrDAAAAAADIBZF8+M7qAXD7wwBRBZF8eAcHAG0FkXz+////EAAAAAAAAAAAAAAAYPvD AAvw03eUDwGXAAAAAAUAAAD+////EAAAAAAAAABZAQAABgIAACADAABYAgAAKAAAAAEAAAAB AAAADwAAAMcBAABUAAAAAAAAACgAAAAAAAAAAAAAAMwAAAAAAAAABgIAACADAABYAgAAGO6Q fAAAAAAAAAcAAAAAAAAAAAAgz+oBEAAAAAAAAAABAAEABQAAALT6wwAgz+oBZHYACAAAAABw BZF8/////20FkXykx9V3AAAHAAAAAAAAz+oBZMpRAnb8wwCU/MMA4wQAAADP6gHM+8MACMfV d5QPAZdkylECJKUAAPz7wwDvsvN3vPvDAPiy83f0////AAAAAAAAAAAAAAAAAAAAAAABAMwA AAABVGltZXMgTmV3IFJvbWFuAGTKUQLAiCEByIghAXb8wwAkpQAAuLXxd4a18XeUDwGXqgAA APQAAAAaWDMAdvzDAAwAAAAAAAAAGlgzACwAAAAA7wEYAgcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkkxOqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izGtyi1SAFDgoUMFjg4WIMDgPDnjwLMqyC sgI9uI2oFkBdiXcP5tUYQwFaAF/DjoWb4G3au3IT2FVQo2Bdt3AByFULNkbXyzQRuHXLIPLE u3tFhtbotrHAGnMhPlZAcfRhj2ApANC8WWzZFgo6xIUssIOCFosZOCC4mvFA1Gop+MXMHGZh 3QAcgF1gETRrk64xuq0wsELqh9nB/l9HGH6iAwWKATwXKF0B9b7cZ7tFINC7bLd/BRaPD8B7 3cLDNSegSmFFdt54HiwQFlmvvVbbYgDgxkADAgFYH3rsYQhYYQnINlADDIhF4WKpUcChh4sh wIBiYcWgoAIjOubeeDOOZyJ6KG6I42oDUeAfB5F1EKJ7cIW3mothxQjYj54ZhBpwixlYV4jD 4VYYlGLpNyOKqymY1osC4WbagGSO9GIDObI3pGAB5qXWgwtuRmEDCtB3oALDaUZhX5tZBgBY cpKoFp9u+bkZWrUtaFBYqNGnGXICEdpipIleV5ek7vVW219GWpoodQBgCipCCnp4ZpoAKEgf WL6hpRmo/2oxwECDjNYpH6SAZVrmriH5J2KAANAJqoIjuunpYQ0M5xtregKAnHF00qegZX3B imeuxwrUgwLU6hoWcMMtqGxoYZ1HnYIHCjRtqLoSKxCd2brLp0AhyjaZlgp1Oe518oZn4YWC JTvQqxBmqSq+ylmrpbmp4lnXeenxKnFHCLwYlodUZjgrhLTSeC2+dikGFljcFUZvbRtz2AJ9 DQKwpmALHwYsuawlMOuKHL+c5WIBpstxdhS04B/I5Hk6c7YN7VXxZlx2pgB33jmQMcfr8miz yyx6PPHWHgWWnrFE/6x1g95Nxqdc8VUaV2GCsWzdgxyHTXOEMP4mNtxgi30QBf46h70o0no7 5JrX3c04529Pt4wzj7jRCZx1XLfExVRTgzz1eRvf5TPkDeJGcn9+2R23QR50oGDmY8tI3Hij I+zWfYAPdDmPrVf4Wwybs/633LHnO17lcS9r3LNQxq0Zbscqd3Hc5TVnReQT0VlBgFa+2y6M WurmAJjMs16X8sO/ri72yn2tgL20N0xh+byvvjuJILvLvvrWx0u+hgU6m75egNclv4YIKZv1 phcmAE6GW+zKX9gAla3UPCxx0IsgRKSWKA954GXCGV+iTpapvJFoOHcaCKZMVZsRDek9tfGQ B2vnP29dZ4SU2iDHMAUdBorlWvsDWd5o6LeGeYiCKf4kCNsOs7GwATF+LhRIwiTIRIc4AERh 4UCOErQgz8CrAvOaTYgQ5b3xfO5C+dERA8YUrBBNaGBbVGJhxtiy0c1Nf6a5y43Y2KMTpW+O 0BnfhORCoRwGjmh4bONpRBcdKPolTdIbSGGUtBdc1QU1cbyOmJpIyUoaRXcggdhN/mXJTnpS JzUIo0gqU5NqffKUqKQJg0rSF1HChJSpjKUsZ0nLWtrylrjMpS53ycte+vKXwAymMIdJzGIa 85jITKYyl6mQADzAAgN5gDQHYoEHBIAgEHgABAgizW568wEDkQAKpAkBEHwgmuAsyDQN4oJx ajMC0ASAM+MJgG5S05r1fP+ACtSZzm7Ss5rrROc37TnQB2DgAgbJ5ja5+U0MSIChBTVIQPkp kIkCQAIGrWhB03kQhSbEovksiEcHMk+B3vOaFsUoBhAiAQxIEwMuiMhGpwnSj1ggAtKEZzhd ak2ECuQD2gTAAHBq0JgKpKXSDIBPAQDUbd40p/QEwAWcWc6kCOABPgXoMwVygQcIIJzdfKhG NyoQEAwUAvEEKUgx+k20AuCqWfUnV72aTwicE51j3adAVGBPiEZ0pku9aFj96k0QCHSgEuUo RUMK1pWOFbEHYesDxJrYyoJVmpSFq0C0Gs+ufnWiKkXIVb/51YfMFJw19Ug2u7lQvpJWIAN4 AAr+YvvNh7rWm6WNLQoAsFpyDoSn3SytUWLrWMmK1aVGBQBOzRqBg1iUtj4dgEsdq1bFCsSZ Pv3AOJtL3KMOFgDIzadsGTpWx4K3r861rkXNes2BLPcBzcXrQFw7AI02JLXrDGho5duQ98bX suR17wOYO5DuChazAgmvfjN6ENrqlb4TsWhqOdLV+OIUoePUK23nKoDlzvWaGYbtOj1bYYFc WLAoOKcLxouUbJ7zqs4sbVCjuc1sprcgJ6bmbO27WIbSE6jpdPFbrUnXei40pw9Ibn7hy1Em WzfA/I1yUG0cZanCl8cLwW8/07nfKitkyk/GspRrrFghw7jIM15nlw3+kuO5GjafQ5XmmxEi YXBetapiXrIEINBeECh0zgMZZ32FymKC8LXP+hwnlOeLTwCYVQWCFvFux3lXpuD0oePs6m4x +l+MGtaslK2yMysNYC8TFQTJFTCmsTpeTtsXAgtlrDT5+lCMuvaj6lXsB8xqXk87erJVbqqY cU3nLQMAoKRmLEN8Deob95jZwDYxsDPd6iuHFNkJGTVBgNregv631PkkqpzzvGVpTvqbgFa2 ut3pVgBEmiAGFgi74ynoiU4T1kjdcVJcTdNtXlrAMY3tt4c9YfFG1CDALWel+Y1af0d7miuO 75KB2lycApnYhPVmcnEacGurm8czBbd8pWn/gdUK97HfPAjHCT1wlKdc2h3v9JX7rdyHP9Pk GA9wTs/Z1TATfMA8X7LO6XpOaaq4zoteLQQGDVKXhlrpTEetYmk60EEjRZvVXKlLPyBkps5Y ng9INtJxTdbIijvJNM76ebkedh7jtL5CD0CNUerzjxdUAJUW9nXb/nFZl33RQ4cABtge1ZAX RO9gT7bBIYt4bVcUrRndetfJOfhsRhXwfq/0hOuseWOPnO9gD4AAQi3lJ/Pa67E+tjPTXdaM CtveUn+zWXebFJd62KxXNe9tvanXKnfd2ZgvSDsbfd7be5XByuaz34eM+75XWc3ZNC8Adt9N vVpU7wX3MsgZzFfa/g8bIdSftcjXGX59/pbJnz6+eV+610KL9MmNhn3OyU1/dVvAmeQkvfwr q1tqZpP1eNV/8rd/SNFz5ndbwgVc3iR9H9dmQqVv1ZVQoKdsBrhPCMhfGDVa9rVi0hRTm5dr A8GB/6WA3URd1uVqzidy20cQTqd9CFdQDNh360SC7DdX4neBYtaCbIZVhmZtBAhu+xdQF9d3 FnABOJV67vYAg9Z/KGBXeOVZm5VNJ9eEnWdlX/VuTDh1dRcUWlVftLVVXtdeA/F7H+dgsOVM tBeBBcFrdwVj9yRNXihXYuZOntdXH9hjVoZ23PZ+RadYe6aE3wd8izVRsRVr2ReGfIiH//a1 h9jEd11IaCQXZYXYYOI3fXBYf4KobkuGUB9AVOQWUwBVECVWcwiFU/FFYI8mENnUe9J2ileW iqN4YnwVAS/mcUiBf+gUa3x1cr/GiiBlVm2VVvD3ZGz3TamGixqVehNVjG7ng3U3doEWVLu4 hua3UXNmeBkndB/XfIvnTQUxjQSRipg3TeA4EOIIdk32ddtYZNT4WpgIhFoobZA1UWc3YBLI WlHoTW4VacCYciWnj9D0br31dSRodUhxens3Zy51eWqnfUilTebkZTW1a6uFAqn2a+a1eoB3 a4zFV9b3jCC4bdkUAQtZEGo3UA6VjdU1j57XiNCEjQkGhvfEgP8RWJIE0ZAYSVL26GWWF1k8 lZKlN3+ayFHAiAEbto1/dhCdCFXURFQ6xVgD2VdPBV/COBBLSZXh+FIGyUxc2ZVe+ZVgGZZi OZZkWZZmeZZomZZquZZs2ZZu+ZZwGZdyOZd0WZd2eZd4mZd6uZd82Zd++ZeAGZiCOZiEWZiG eZiImZiKuZiM2ZiO+ZiQCRJVEJmUWZmWeZmYmZmaqUtEsJme+ZmgGZqiOZqkWZqmeZqomZqq uZqs2Zqu+ZqwGZuwSQC0CQAE8BK0eZsCkZsjYQC+CQAGQBC++ZsCMZzBaZzImZzAqZzGuZzJ GZzOCZzO+ZzUOZzFSZzReZ3QqZ3ViZz/A9Gc2imdwvmd1okQz0me22md2ymatWmbuukSvLmb vQmd2Emc9Zme4mmfy0me19mfxbmf/2mfx+mfx4mfAhqe/ymc90mfBsqg/Emg64mdAJoQAoqf EEqa7SmfuOmeGhoS9emfF5qgQTChE2oAQhCiDqqg36miD/qg+qmfCpqeB8qiADqjCQqiJHoQ L0qfOLqeoJmhBBGfuVmbRDqkAyGkRuqetwmkukmku9meQ7qk7xmfHGqeEkqiNhqhWtqiv6me /SmjPtqjA4qiX1oQzVmgZQqiM3qlK3qfCwGjXYqjpQmkT1qlRcqhd3qneNqkS1oQfGqbe1qn eSqldUqh5Yml/ykqnmLqnV8ap9MZoz4qoeD5qCu6n5FqqTV6qG6aqeZZomFqpjyKqTmKoe95 pIQaqINqqn8KpX0apKr6qqgqpVTaEOUpqYm6pVwqo9I5po4aozQqqpZqodnZpgN6oLqKop9K qaMKqjdaq8kamnQaqLEqraeqp1XqqqYqn6w6rQ9xrLaqpr+6qSGao8cqpsz6oS0aoGsaqd6a qOM5rp8Ko+N6mhlKqNuaqqkqrdd6pEFqr6vqrxoarS7arlwaruXKqeBqo4hKrAT6q/mZoh+a peUaqgg7qQ2bqwzLnlSKpP4aparqsRvrp0z6pFHasUqarZ16qNwJqrZaoQW6qS7rpf8qC57d +bIz66tdWrOMqqw0m7M1C6k3i57uKpsoGxGlepnPSrQZIbAK0aqYmbRKexFJ6hBMG7VWe7VY m7Vau7Vc27Ve+7VgG7ZiyxS8ebQLMasi67QNgbZp6xAy67M2C6Yzq7JjW0vb2qFNa7aFWrUI wbf7aqjISqwWqqlsWrezVK/8yhBMi7gQ4bd+C64Vq64JSrhQa7ifNKtGurH3yqScK6uZy6f1 GrqFqqNs6rP5maZnuqyWG0tTi6+t6qQG0bqvC7Cuu7d6K7Qq6qUPe7pxWrirK0tIyq0ke7sn i6eCSrsA+7dv6qbF2qw7uquV+7uVNKX/qq/WC6ijK7q1q6f/j6uo31qiLPqyciq9qHS323u8 Ipu91Dut+Xq3pGuu4Oui80q+5Vu8J6u5JGu/gIq2oLun1sqxp6qjw4qsERqdcEu/akm8CJwQ U0Cv2LvAV9u9EDzBFFzBFnzBGJzBGrzBHNzBFFyyEhy7Idyvfcq2GEG3w4rCHtxJf/rAEjHC tju6GpGzBmGs0bvCEgTDBwHDI6u8F0HDzBqsOMy61FutoQu6/Xu/pSqwrFrE+SvDuRumNjzE qcS57FvCyCuo6SvC7EuttwvE4YumVHxKVlykZbu5sAq7RduvsYrECtyoNeygvjvGTFTGAZy/ 3Hut0crEyXvG3SrGYay6dJzDS9zH//ubxaLLxQFLu9QKxfwJxlM8yJY0tUpqxk9cyZ47pX0L wMWruetrpRDrrDcsycP0xqRsmWo7wVAgmzp8yq78yrAcy7I8y7Rcy7Z8y7icy8X0Bbrcy778 y8AczMI8zMRczMYcmWBwzMq8zMzczM78zNAczdI8zdRczdZ8zdhMEgWwzdxcAATRzeDszQPR zeMMzgIRztv8zeUszgCAzuR8zukMz+7Mze1Mz/aczuxcz+88z/Gsz+98zgVhz/48z9kc0OJM z/IMzwpdzwvN0Ax90Addzt/cz94M0QC9zuPc0BVt0QAdz/280B7Nzhtt0Bnd0A4d0hmN0gUN 0hSt0vicz/8uDdP5bNIj3c4TfRA1zdESfdIaTdInPdMf7dA+3dNCrdEzfc0hjc8/rdAfHdM3 rc4UzdRPHdBS/dA3LdD6jBBOLdJAXdFQzdVdbdNGvdI8rdRJrdIsHdRFbdNRbdU7TdVu/c8P rdTyfNRy/c9BfddFjdcILdRqbc0ebdVoTdMWndddHdU3kNVvrc4J7dZS7dUTHdYtLdZrTdd1 bRAIbdmTvdKBndk6TdhMHdYlzdOL/dcybdI73daVXdOrndJAndqpLdprjdQRvdSzjdaD3dSw XdpHTdm2Tdm4/dm2HdUoTdyxzdKujdq0bc4vHc6Y3dfk7NlJPdC6fdmR/dXmjNz/HW3Yzc3P 3n3PZn3WBE3W5F3e5n3e6J3e6r3e7N3e7v3e8L2ao8wc8z0TNzzf9e0S0ZvfTcHflTrDFrGz tHqwDJGsAi7AcQymAX6mFgvK+/3fFeHfagq1Y6oQ7Fq48QrhET7Hb+qrzUoRlLugz5q6Hx6x BE6zlXqpbssRBSwR+S2utFrgFi7FbarhEJHhMn7jNu7iC56uCJ7jN9qpNewREi6sFMvfwqqo Si7k/92gGUuuNe69Ec7i7xoRRo6gNc6rLxqeDb7jUX66AQrhPQvIQe7lZprgJX7AYM6gCi7K Yd7gzcvmuCvn2dniHl7h4kvnk6rCk0u5TH6p6unnu1rl/x9e5mWu4lLOq4Ne4SW+5C0+t3C6 oOiJ5Rbr5h3e6EEe52cur1I+5EI+uF9u54qu5JXutvKK550+6Lz75akuxkmu6Qaa5SnLso0e 62F+66pu4ZhOoRqO6rhO5o7e5D8+6W++6oue62nu6bhe5c176KQe6sxu5oUOvUEbqiT+7Iae tAdu69iu6hS75Nnuu6jO7bEe5wze5Nf+6pM7nePu6Lo75OUO7eQuyOu+7D8O6MLunTQe7YZ+ 6Zq+6tbOskP77KWb5WMOyPou5sKu67t+5sae66Ku7Awf7ep+69+O492a6NBe7M1+rr2+8PXO 6Bof8QY+8vK+8YJ85ODu8MF+5f+I/vHTvuLHHvCj/vLI3u2SKuv8Dqwxf+UTP+8fD/QxH+z3 vuskX+/9Xt/t/usp3vSZ3upQH/Qnf/QCHO9ML/Rg/q7c7uwL7/KsDvLdbuY+770iH/BaT+h2 bvJMf/JPP/QSP+Ys3+e9asAw7+VGLumQGvJAK+24S+nO2ul3T+eZqvJtn+Ii/rBszuh7HunG iqANmuR0L/fZ7uFpivj9PsDuzunKGvU8v+Ys/+3ULvCSv7KCvvmDjxQSzuuGmfoSDz2jzPrN AfvDLpiyH/dcg9/xnfu6v/tjy/oYvvJGweEmUfsAfhSpL/vEP+URBPmtb/sA4AP2PvEigfGq T+gnoaX/gX6lwg/iwP/D4E79Gc/k1R/gOp783Z/qXcH8zm/942n+IFG57s/9dY+rHRH/7C/+ 4T/7+j8RL17/0t8SAGFAIAAAAgcWNEgQoQGCDBsudLiw4UGFCQ1GTChR4caMHQtOdBjyIcOL FTOOBGky5EGSHSmm1DjypMWPMWeypFiy4saaD2tGVAnT4kqWP3HmPMqTY8yPOl0SxfiUY9Kp RYkGBXkVIs+WWlMiFUnSp9SuUV8qRZtWrViUbZvuxNizJ9C4PuGqnXuX7duffP3SFek27969 OwW7LVzUruC4dbMmHst1aduweiU3nix3KVDEeTtjVuqYLtzAmgnnzWK4c+jI/psrD767Gu/s tCVB/4XNWKfdurbxin6LWezw2HLNDgRM87bqwp8zX4SKUCVy1aYnl14M+nXwrLkf19aM+/jp xpw9Gy/em6bM9eijsu679f3326dp33/unXx69GiBL4cPtv2I2y+76vrjzzwAxcuvQek4c8w6 0nZDkK3tCEwws7XCK1BC3CZycDTZOmwuwhJFvDA3CDNcDD/a6tMvRhErZLHF/z7sLUbmihOQ R9449O48+5wzsMEZaQxsQBmNvIw1GIlEUMj8boRySL+qS1JHEnV0ET/fVruJurGomsozp7Az ziqYzDTzpDTNEmorEKtqEUcx17QNrOk0lDNKjTzq/sspo+7UaibJpOMPUUAH7So0r7p7c085 F0Wx0evGJHRCk+w8q0tPPwU11ABFFdW8UklFNVVVSTV11VZXhTVWWWcF9VVab43VVlzdTFVX XH8F9kBYfQ22WGOPxQpZZZdltllnn4U2WmmnpbZaa6/FNlttt+W2W2+/BTdcccclN1RikdX1 3E9fVRdVdmtttd1yf6sV2k7pnZfaCLtU8EV/8V13w3cB/hc8U1ecrd86d2W43oBv9VXhDWel kClE+Zw4vGP3dVFiVhM2F2Twih1Y2FF/zNddh2mN+GFZgcvOY4KdHUpN9SwV6qyygrLvzBUL perEnePczc2hY8uTzJyT/uuT1z8N82i0oqnzKsymwoRQqjaTPOoqPSfVWemjJX0a0zUNRBhN rSVSDuuGBysNskPPY7BGKxW70jIsDyTuMNm4g3JHiZ/8EUadg8T7580SLdzuuvlKcUHJ6V6S sb19zDJEJBmnWHDBOYY58C2he+7L7uRG2bfynNx79ACbk5L06V4jvd/lxjvd8Muvjpq+ysMy HfbJy3Ndptk1LLE15vL0/O+XmxfSgBcGb53H4l+fWzjkMxRN6up1zx7Ixv1j3cMaKe/+8RmF j8/xLBHOO0jnwZ8LdrQvkx1lrq6Xl1/oTRQf3TqkPgH+T29FYhAAOde3x0FvR38L3fCsZ8AD /t6NcTcCX+R8JL8PGRCACpRSlEJHQI7laoBJ21SZLNYzMfnsUZGak+r2x0KqaWpx95MP1LKG JhDdzFFHWlSi2mOTmoGJVz5DnmKekrlC6XCGdbLS1vZktarscHcxJFMNMdW/lHURYl5sFhc9 JUYw6quMZ9zYvdDIMjU+b43gctob5ThHOtbRjnfEYx71uEc+9tGPfwRkIIHVRi+5aAYz+1bJ BLlIRs5LXgdzlcZE1jH/GSxjI2tkJjUpLTJiLGQrKyQlEWmyTZbSlPYKWpqWpqCuQcpCQdPa EcU2qKUdpmZw4h0uT7lLXn4SbuXrYJOcYz8C0ouV42sSEPnWwF42/9OZBVtQMafIPdO0hzAH GyJvTJdDZW5RPJ18ZjgXSSVhBpN+GPLg/qaEPc2hbknpE2c8w0nOG5rTfVein2p+MDlkam93 SioSOOU50DoyTWNA61TSogO5VqrHYmBL4nxkSKebMRBnAiVoRgXZSfhp1KMf1SQ4OwpSkpbU pCdFaUpVulKWttSlL4VpTGU6U5rW1KY3xWlOdbpTnva0W03waVCFOlSiFtWOTjBqUpW6VKY2 1alPhWpUpTpVqlbVqlfFala1ulWudtWrXwVrWNGYBLGW1axnRWta1bpWtrbVrUstgEIKMFe6 8oSucSXIXQFwV77O1a5+xWte6ypYwPbVsP5xNexe63pYvC5WsYyFLGHl6lfJThayfLVsYB27 Ec0OVqtX+ChlBTta0orWtHstLWcb21nSKlauqHUtak272tYiVrOxBWxqT0tZ3p5WtZ2lbV5x y9rSBja2rX1rKUU7XOT29rWTRYtvl+tc4ULXuszFLXKPa9zpGhe7tq2uZcV73NoGd7qqRW9y lbtd83I3uLDVbmWvi134kne20N1sbuWb3tESl7f9/WtunUvc73r3tfdV7ybBS1gEF/e58WXw fKlb3+5itr/61Wtm//pb4HIXwJx17YIzzF4HR5fECdbkiKnb3dryN7oTpq97+XtfxMJWv791 8Y0L+2DPClfAtP4tgBHKW2KlqNjAKAakf9ubXt9CWMlMvq2ECRxj706ZxehtMnllu+IqP1nL 4Z3wkZGsRy8juMEyLvJ7wxzl5lpZzbeF8ZW3nNr52njJPn7zdRtrXRiPeY+LZWyAu1xhA9t2 0IfmcISNXFzMGjrRjz0spM8r3sJe1siz7a2hI+1nTnfa058GdahTVQRRl9rUp0Z1qlW9ala3 2tWvhnWsZU1QjP6q1mbs3LSI+cWNjpGXteNXHHn9Nk+KEpO5UtWuC9myhfnv1g8k331KeMlR Vltbzza2urAdSmVx1Nofi+THmJ3sYX+72AWbJLcTyazjJGthZFnonyhFJ0m9cqF9i/+lza4o kSFMLVNPi/cq/UM1pdWSoXBazxLXknCwHM1qDDfowwnecHpLvJVxIuK/KXNxe2NF4fK24rAo CEWkzY9LkDSejDTopLgVm3/40x+XcFhAz53QcdhTXJU2x0583lx/qHPdOVVouJavT+bRJnfh KES99+nw34lhejrZc6ccYm6GL686zb/ZkvQsfZ1lAfrRxxc8lTtweUOReoW2KfQt5Q139WGe 7xCDTUL6Gplza97KccQho5NzgLGrJwJfTri+m0yLkix88tKOcsCRcHkcpFwPfY6+dQ5TiB6C XxQlX/kUxlxl/cS7inQ+wu2NqHIdVHzpHa9zwUceJSNMPOL+Jl/ze87cfrA/vdEtN/qT87zt 7jlf68MtxR82MVBuI70s8QbylhPxdKEHG3LcFn2oh635HsciK5tYNZzQ0vVVdyHxb+L9FK7t 8AFXlJ6eBKjpB5D5MeN+86Wv/W2TzGXpxr/I9Z/S+pebZs2mtmfqn3PRNv8zl7prJGEbuP57 GQQcpJywu1mTwAmkwAq0wAvMPzQat19jQFLqFgeEPqJivA60P6RLF0fav5P5vBJMuoDZtmmT JJ7jI8bronjxQAD8wBQMwVMZFzHqP2IhwDLqOPGDmyH0t9fjG47rnYzjGeVrmoL7OLbRGyqa pvgzOKG5wqTYlyismHxLHIHzviP/XKFU2qEhlA8qLKJHMb/5yyWyyZYv1B22W6YvJB+i87yw g7ac47ywg0MTVJQ5/JwdHJJBtCQI2sPcW72Y+4/Msw45NLuf27lgwhbcgZwKQsSsix+yI7zn g7YQ2ia5u5r/ibs9DL+3c5Qqqp8hEh5r0jotYZQB0cQq0r1MRBpWtMO7OzvpWzxuAZ32sShE vB3Mu8QGAqF8spHHIxwVAr1DdLnfmznQAyFXVJsDujsbxMUe4T1tgrwSypRknMQ8pL1sZKao Yz1i/Kfgk7nf6ybU67132cSRGsZIjCBsNEfho0UkFEfv8ZsQykdepDf486YHwThGMZ8p+jiD ij70oaGV/3iiIpwmj0soVaS49OMh5PtHCCy+rQm5eQNIFaHDtelIurO36PAh53shWHqPhcwo INzBQCLBFiSpl9RBcWLJc+sjBawWmcQjnNQXEMTAnwTKoBTKoVwqnQQpo5QnbBMoAtSCnLwW RRKWmoTJFRzAG0S2ABw2zfOlYMOoAsRBmwTLDTS3mXQQXAO3DNxKqrw/Y7EVnYTH/5tKgAlC aesVdYPLGIyVMVhAg+S6NqQl5chC2rG+s3m/hkxD8jvMktzLr8E3g6s4LYw3spBCxXSlgyPM Q0G7J6wML/Sa71vDoREUkLMRiitJMaRCv2zCr7E/7cDHxqsfYFodvIyferJBeP8KPKGLtmlU k22sPL0bvHPcTc+7lEBJEB5KRGuUPcurw0KURJvbRwtaxl2xxciAxU4ku7lbwNtjRVSEPVWE mlccGa4hFFP8it78jFikzu9IO4gYmKYrx6zrmRgkT2isJqqDz7nrRlm8mAX6HJ5US9ZsvGvi R0LMGs4bud6rxu80TszMxrcsPOK0pctb0HyqSfeUJtzctS08RD5kRgs5H2yizXZiSxbZzAma R3pqPXKUR3CcRZhJG9b7uxRNz36ExPXMEQaF0Av1uSMBvHR60Oj0OxqpHnvUShNqqPQUDqR4 E4Ysm4c6k6tTyO4TyHrrPhPByO8kyEWcj8dkIs3cFIb/tNIyTJ0seqL3oSLA4ESjaMXs4xkS PVJUbBrudDrHnB8aKiuk5MFgwVO3bMmuggGNwtM8HaRuG1GrJMpDRdREVVREXQIMrL9ALScW 5CQygtQ+HT5pI0EGVDa7jMBrG0tQqqS6rEqZQTqypEvnObYflEEDxMrh01TZlM3bQ7c3/NS1 NDaV8UEV1NUV7NTvwztVDZ9B5dT9e1Wx3NVhtZaNtEizOTgr8iEv3E+iwTjswBnRhFMnfTo2 FM3BbJTPjDhu1SWQvCV381I8AUlrxT5m7cL506XUvJgltLgy9UuE+kpOYk5nDMVWDMaxazZ0 qkTgC9YVBU4RbR8EtSdFnFFm/+rRFTXGa3REIT3Y1lAc59wegAImT5VTGN1OVarFXPTQ+vRX DNFHzenPl+i7E1Wek7vOGpVY9nRZ6pm6k70l8lDR42lW6CxCk71RksylvnS/XxSaTbXXXcRN vtMNyitY7VFagCXZayRSAk3ZTSxL3MvRYwxYYgIQRpwThy0frYXEtvxYJQFRjwHaSMRY+qTR g4rKHqVWy7jRRvQ9ZrRHdswcIOVPhM3RGA1Sor0ifhpQrfNGyrC8DxqVsv3Ra1M4f7s3idTZ 9VHSslEbwLSJZYpWKDxNgRs/yBU+KW0/Nh1OK9zazSO/MQ3XIjLMvcQSOvzSOa04iZXcNZTX AkncOf8C1lThgUV9K/8UVNzl3d713d8F3uCVNRp8yl8jtwI91asUF5/0tdo9tjsi3lAVORh8 Xl7VtU98pJ6jSwY61k40QG9bNkMV2rTsXpCp1N2t11aty/QFy141y670k0mCSj9cXvc1JlZt X7TEWC7cTWgN0M/lnXIlHig1w3OdN9M807prt9FtuuozV5FFScIcVwmG1z6UwsLk0tgNYHr9 X7JBQ281zIdD128M0dgM0ZRToBJF23vMVw2F2Y9NRF8FPJQrUR61HO69IIJFkqKjRmf02z+M Ju4oRmC8W3MkPae8z9vZWMiY2A6O4X4qxeI7UU2kRExKUtYR2YhiYnyyJq//UzqjyeFKhMBk /GFjnKjUA7uXnRCNKzv8ZF5Cfdh3DDwhplt09MYfZtGrHd+FNVk6xsOe+0VU/Vor9kRfLFsZ /dUPnUJhHKmsHVhtLNJkJWK7dVAF5dvwCdIX9sV0ZJO45dEc+eMthlq85WTTQ1gf3qAf5dBe 7Ecy5k9CpNUzZEw4TSVP2lk7dSUxRcgnbd2pS9cAxhP6DY6EsmQgksxXyuXLzFYxhaEvVtck NM7tbKEjZWXEnMjObVJLYVLdnUFd01OZkskokGSuOt/LZBlwvknhVed1Zud2dmesQs6bjGfl rddne8FSRd/8dctytt9nmUtYJd99lNRlgdlcE9/1/wXoXk0e6r3BSrZefP5m9rVUgkZWes5f OSpoNzpotdRoW+7n9F3KWY3ofPbnLGJDh3NCzdTlB0ZpXDrNsZFWJqRgNWRXcmUifeuT+Gjp jXPWyxUUhAIeqzi/mF5Sb6oYdDVdiFTWe2NdJALqX/bmBH3PEn7k2tPe2SzSvnRhPyxo6Iyc FMHS0bk+Pp4SHm7NQ06ggXVlB6pZRD7OeJxNfz6eK8VX9Nw5u6bZubYdaL6mxG3r2PG6kOVk wQY29fxaL67js947qPBQRkTlQCQ5v1Flns5PjbXPaOFGrFvh2Evby95PnI0i2+QgFHXbeMzi CO3XR6RkS4zPaXQ71u5bZP/EucKVUKt96yC+S8J9z6KlR82O2IgdZRFK5QPtZGlKnR3V4clW Tife268r4gL6a+Um6zhOaHThYIGsKAJ2upWmPvFjzMPZQsblyx96N1wOkY88IiwNw39cXWat t14eZiW6G9XNu40NzM4byAzmx2zePI78xDeCVH6mKQG/6Ikm5zfuFQS3KgI3VPZ+5weH8AiX cKt6Ao/qAloDVYPG7AnfJPi11Y6+1bFkaAbn8I2Jy+TF30sl5BK3I2nWVnhzNzFkChmPQps+ UzoGOP1OTZe+6utm8btMTtHDakCc7ak+R9eIoV9q2umu3AlqtiP4cZLRR7r+EuBhp1Es2TQO 7z7/NuosD6AhjlkW9tn8ifIw2o4plZC4kW4uf+2prergjmzAtbqu3uMyZ8G95lfhNsRLhthh 1Fvr9FEZjE87TyPHlSglYo9gRaFrvfHRbNx2c9HlK7+IJEKRlOnqJnQNz/QJJPG0yIFNB/VQ F/VRJ/VSN/VTR/VUV/VVZ/VWd/VXh/VYl/VZ5yMboPVbx/Vc1/Vd5/Ve9/VfB/ZgF/ZhJ/Zi N/ZjD5bNijBFs7RK06tn3zTHavZox7TxYrBm1zDJqrJsT7QRq6/HorDLkrS+CrBwx7QOG/dA W3Zw13YxA7U1GzIf060yg7N6/7D/2q32YjP5Gqx8j3f6si8xa7CAb655/+ezfYf3E9MzO8Oz g7f29zo16UKzLJMzLquu5dquHOsyg/92z+r3jS+xSWuztBj4in+xGYP4GRt5LaP4iZ/47Poy Uesxgs94KdMzRwMya9d4+FqxD9MwEauxeO+zA5sylCd6nU8zow+xNAN5Imsxm6f5nI95mfd4 l3+wgLewEMOwHvN2rEf357qxhgf6M7uzIlN4QfN4ryd597Kwrl/3K8P4locyJvN5d6d6iA+z nR+yGpN6HLN51mqymQcvoOd5el/7gVd6SGP6k795n1/8qG96NHP6/+J3VfMyIpP8s094Hsv8 uF+wcLcrdu8zM0t5MFMzpfevOlt5gAexyT99uf53eD5zMcvPM4XvfDf7d8KH+jmDee26M3+3 /Sgz/MYvfKff/byPfSq7sKuv+NNPfliRArFytEfjdsVX/EUbrkZj92UXd3Jn/h2b9qo/93ZX 9+sn92ff/keD9vLfMkS79kxj+9Ua//0qfWS3//vH//zX//3n//73//8HCAACBxIsaPAgwoQK FzJs6PAhxIgSJ1KsaPEixowaN3Ls6PEjyJAiR5IsafIkypQqV7Js6fIlzJgMDRgQSHNlzYs1 c0rk+dEnRaAyh7YUqtHoQaREl0akyfNpQ6VJHUoFUNUq1olXLW5deLXrQLBcw2Yt61Fswa9k f5pFiPZo245Qlb6luv4Wqly7OuPqBVk37cymJYH+PanWpt++KgtHBeyWLcGdN53avIl1p1XK lS1v7tzZaU7QiDOHtowZb1jOovFqFu1ZM2mfrjGTTj357mTTnF/vru2bsm7VwS/fZt37t2my koUPt+3ZuWvf0J8yp906eeTmwEtLHk08OfC1zpEzr7287HnpsB8SRi+++2Xl4t0jli2/Pt/4 tPPv7w94bmT3mTVXaAL6Z593jwmFYHxZHWigewAmiNSDEjboGH3eWYhggRte+F+A7zmI34ge +jdhiBfuF6GIqK0oWIAurgYhaujN2KJ8hIXXoUE3lmjbg0CeqGGGQX5IXVLhYcjij/X5eP6i ddFllh14JKo4JYY1uhgbh04qqV9aXw54H49NXrniiwweuCWbQmLZE4hEpmikmkuaOCZ+ZeI4 mnU0pignkW1aiWaYc8ZVZ4FnZklfnwndxqeZQ+62pYhWOqZnoHgeaWiijdK5aXt72sgkqUYd 1xikgH6qpailHrlDnvNlqqqfoiJqK6mHctrjrpG6SmmGMVaqKIrD1jloiHpW2GuxDZapLIuh /ulhra4225Rq87UGYWyFqvcosdcVJ+tm3Gn5JXfPSTkblUCWy5t07r7JW6deUodkacGu9222 yHa7L5YAg5tusnxW52BwaWoHab3/klnjeNt6mRrC7wbcHFP5pf7E2EgcL+UxThmLrNjIQwHM EsiJlQzjyuO1/DK5MMs8M80123wzzjnrvDPPPfv8M9BBCz000UXDlLJWFBq9dFFaqQw00oPt lSBKC8Z8EhB/ouqVXOgqRyDFQV3tNHtkn6W11FFrvHbIY1FtGK9vNw3RVlFLC7aTYZvNkVh1 qT121Xk5+rFOuZUXJsFRLoixebAJvPBy95Io7nPTnUavul5PZWisYCqcOOWRy+n4pIxbLDHC nSbc4+oW2wtd6i5THiPj20XsLObyKh5x6+QhnijbtLLaIvC3Lupvs/CZaDWwmh4nqbVJAtgn j5drW+2qAnLu/K85cssrtcjKVnycgP5eGTfweeNuaaDkG79p8sEO3v5674P2vrFcTvu9kQ6X O/6w/Kc/1gTvR55aH4O6J76v2e543Lvf5GYUvndNsH/3Wl117IOkSxlsYBd8UalW88FcQbBS IHzMrOKWQqWxr0j8YdadVqiQgeGKcydEH5gMmKr4xZBY3qJVqyZXviEpcEwWkp+MXqijgvmw UeSaIMXupqnj3VCFFYTh9VooqCmG71PIM5ULvxhGuQFxVNJ6IPaixz0e5q9z55Mhq464RQ1e z2p3WSDDtCdDFPVQXwGcCZSetzCX3Y51jBJk4uT1GyrlK17fGtB1Mtcvqq3LWGlC3Gtwc77Z mO5ii6tdu/5i163fHXJSpYTkBfl1qfTcMXXQIx0jJ4Qx1IFOR6Zk2t5klj5cxuRvvFxSSMRQ tl+y7GWOI6ZMfInMAgZumc58JjSjKc1pUrOa1rwmNrOpzW0uhmfKRCHfXvJNyLjkLeNkDwvb tjLG9I2ZxQQnydAGJ4h1U2z0PBvXqCKlzblTj3CqiB37KbgZHm1j5JzfMPk5NYHiE6DNJGg8 EWrOgjqwnhDtWOuiIy7Jic5136kcuwgmwHTta3YmlWSX9GM4W0puRG3ZqCIz2cGPdnSUpxPl SD/TSUp6bzuHI1QtXbcj0vVmdjo9nO9i6ayDGSc9J3NbE4doxO+9kVPuq5aupv4CRi+mynp+ xOMu02hCl+KxqnjrIaHI6Kaz4qqo8PNhVIPoQjlmkThw1N49MwJBaj1pqshTUUBfidWAUjCW XPXcGxElwQ/l9FzH5KNY9xhVNUlFisCKHAi9OsCvRTZXwhOhm2o42Tn50rJppONfFYbFsqZ1 f2I87OW8OjzGxhaLs93eaNl4V0stUaHRO6KuWqsq2X6VsXNNUly88NsivlRtaGUubLMq2ew9 cbU5rCqjxmgtiD13rOmjLhp3+9ZWyqqLWHWjGok728yK1qz8g64KN0LLUgaSuDatWElRxy9z wSuUnCzsfqlYmeKKlJ59ve8iZ5qv+o4POyg9nW7UA/9MAU6pqW/bXYI/usn8hrXCuClwUfVL VP4ix5E7m6jOzplieXIzMOVsMev8hrOnSrOkMNanil184x3zuMc+/jGQgyzkIRO5yEa2mXB9 S5Qc51NsDsXIqUbG5Ig2WSRRvrFmq1JZi04ZobmcMJjfCUgaqs+uA95bFUmSZvBZuaGA8+YU lSzON0vtyfCUs5gv+lnOnvmfLK4z3dTM43plmaivo115MKxKR/q0pUqFaSYTOZ3becp0jaZ0 5ZKa5DZVj7a9q6RRZfqdlmp0qAfLkaEj9DiRjhLDDSSpTdeV6oYJWof2c68BaMBb8gkrgHO0 LY2Yx8T2VMmza+TzevkcSsT+4q62WqUqEb1rvtFeEbxEBK6qZ9Xpzsaww2ypbWsxi2u8hha0 /9ueuInntb0adtgAfhO7f9jU/lQyhZtz9rZ32dc46i20Ydy391J7JoDr1roHhE9c6TeuNcsX seF+qR/pylMN3XCLizItuvEELQmdMTtFTCe2C2a9fBf82s2V56/vVG3PXlGL7yV0FNOrR2cD ett35Tdv22tyyX58uSn1Yv+kat78bbmM4Cp5xONLwKuyNuHXtTazRHtwYbV8k3QOZx6Pta19 1heV7kq1xy1MygxL+t0u5S+bhOPfD6PJrYVUqtEv2e4OcoiVb6/pgRdLd6p/+OurvrCIsVO9 Yrv/0oaT7LKbc4b4I3es8Xq1M9yWufiuTZ7xIVEmjf2seYxW3vKe/zzoQy/60ZO+9KY//S87 j/rVs96gOm497GPfMtXLvva2T9oglwpi2t++95Z/7sN57/vhH5lAW991A4mv/OVvjb2YMpXw mS99GA/9rSmdPvaVz0mta2eS2f8++MMv/vGTv/zmPz/606/+9bO//e5/P/zjL//507/+9r8/ /vOv//3zvyNYkL8O9J8ADiABFqABHiACJqACLiADNqADPiAERqAETiAFVqAF1swBZEBBHAAH duABaIAGDoQHdiAILoQIrMAKiEAIHAAAnMAITsAInkALjiAHjoAI0mAH/5ZAQZTACG4gDW4A C8ggDgqEB2qAD+IgBxLEBJgAB5rABCTECwoEDHKgDEohEx6AExLEECLhCGbhQSChF35hCN7g CJYgFI4hEeJgGBKEC3agDaZhByrhFYZhG3bgFHagDNbhAbDAHopfCnygQaxgEoYADK7AGwKA ILIgIR6AISLEFJ5ACGwACwJABsQhAIzACtQgQWzADXLiQLhgFSbiAYTAQERiB5JiIMZhCGgA B5IAIp7iJorAIYpgCFpiJQ4EE6aAQPyhCcxiKUriAejiQFRiFQJALu4iFh5iIqLiDIaiJfLh AYgAQiSiQECjNBrEHxphQVDjIjYiNgLiNj4jB/9e4xcegCcKBCgSxDECAC++YSUm4SVm4gHM oidaIvgBIzOS4UDw4ApoITwCAD8ihDwKxC0KBA9mIEFyIAsM40LCoQ6KoBZCozCy4x1CITwK Yj3+4whsgC9CJBx6JBM2ZDViIUK0YT8OhAZMZEgSBB+agD9Ookd+5CsyokUigUAI4kkWBD4a hD0GpEHs5BHeJAfmJE9y4EMSoTr24UC05D5yYAi+o0hmQENm4jlmHwkAIznqo0CQAAc+oUwC AFcegFceYS0ORFhqIwAMJS4eIhZy4ETCZFq2oUsKxAZQI0LYoyXaIlouhD1KYSuyYVcihAgo JEGe4xS64icG5lcipVb/puU/FiVM9uVWYiVkmqVimiVlBuVibuAVvuVAHCZgiuVWciBaqqVA 9KJAsOJeYl8JnEAmEuVXCuJcOiZMyuZBDKZb/iQHkmIiumIIzGZaYqImpqUWAgAw2uAIGKFk vqRQmuNHisBRMoRkXmFRAmdByKMMmkAxUqcPzqZkwqUlCqJIVuZMjqdBuiZNauZMWmdrviZ5 iicUCuc8MqYxPmYazuZO9iYiziYMjiX2/SYAQCMa0iZzLuZyCgRuguNnBuYEQONCisBEEmdY 1mNx/mE0BqgGHuhHruJf0iYPWqdCfKd9EihChKV27uVy4qV9gic88qF5aqaLBqJLCqh6kuhN /86oU8KoUt4lWHIghW6mjU7hEzYoYUKoZSJm9omABo4AadaoirIoXBbECFyhN84kJ9alJPYj bE4ibipncTrmlQIpGfpoa5LhFK6mRUZpio4oQRzkChSjjTbmd75kByLpXY6gnQ6Ekl5ikxbo Yu4pkyooHNYpXyJok0bmiNojRhqnKWopQTBpRzLfOV5hPvZlEzamY4JoQVxhVbJiNOogbpaA ecLkFcLgl0KjqIqpqsbhFL5oOUapp1YnX9pnrHYnphKnPrpniCahruokLu6mn2bqJv7qKDJn r/LoaXYlTNaqPwKnp0InAISqSFIBrmbfO45gVtpjWI6ltl6mFqKiXf8m5F+G5QHAabWGgDyC p0AEarmqapwWqERKp31aqJ22oX++akHQa2hyq30SZRyGZXRWJsAWxLV6YLb+47YOIw4eLAsO LBSWYroOhL4mpmgq7LjioflpwCya5lfyob/+o8feJb9aZ69SJU8SBLl+aX2eoz3256025kEO KHlu4o4GqHPOapQaZ83yYVVS6jBGpyUeZJ4WqNAShMb648fCZMii5Mamp0wWLbKO5mNK4njy rEGU7M0u6L0u3wRUpc0qpV3+YZWGLSNGqmPq4sQu5YWOZIQ2I0HgZmJWYSV65TLKZN2GI7DO 5ArIbCnC4qNKojC240Lc7UBsZDAiI2pa5gf/kuJVKqPfvqa5NmexAgDkSqHXOqjkImOVdm1B YO5MTm7lGkQ66uljGm7gJqNB8CE58mHbaqjveWAVeioXfmCE4mBKhugJXKU5Di2kWmalemBS DuokrgApDqHLDuGYxiENvirwEqynmuGu9qDzkibfnoCblgBbLi+5qqn2ImHszi5p1i7GAoDs cmGPimhfMqFBZMDz8i2fHiJX5iMAuOwF1q/93i/+5q/+7i//9q///i8AB7AADzABF/D9hYEB J7ACL7D84QADPzAER7AETzAFV7AFXzAGZ7AGbzAHd7AHfzAIh7AIjzAJl7AJnzAKp7AKrzAL t7ALvzAMx7AMzzAN/9ewDd8wDuewCpfQR8gACtXP2vkXUsHdTIWZQxBAQhCAEiOEEjcxSSyx MfEw25xK5yGxQUDxSGBxQ1jxQTjxz+SVyhjHWCEdbpFZn3GEFXMxQagxAHAxGydxRLzxSsix 0gXay9CxR+AxRKQx1FxdwzkQAfUZFEWdsWUEHqcxEieyQOjxGsdxTDDyxG3NykCyRlAyQ1hy zSSRh9mIUyFcAsWP+fBaFaEWZAkxXywxKi8yFHsxH7exIrMyIrexKicyLdOyKw9EE8cyFsOy LqMyG6eyKs/y65nZSV3MJm/Q0UVSXq3yLsvyLeuyMDsxMzvzMwuzK/+yLSOyNveMRhmMh/91 m2/dknYl1kUVTyCPjlJAszO7sSyrsSKv8yIHcyvDczvHcz3HMx/nMy4H8y1TszzTMyWHCvXk 0dl1R6UZXvC88zq/MzA39D63ciqrs0L/8j/Tsz/PGMUJnr8oDhhZURuxXQuRF7HVlbfZM0Tb cz27M0Czsknv8z3ncktrs0JT8zyzcyO3M0sPc4dwl0wRmn5lV0LTdEsD9FC78Srj80Pf9EWf tEVjcsnwWitBCVnJ2WWVFxNpGN2Z0v1QilQwdU3fM1Ev9VDjtEXHNEr7s03btFiD9Vl7WVYo Qcz1WsNgCsR11SULdVgz9UsXtVCrdFt7NUo7tZRFtV1XNV909BjfJVDzxEzHaZ1CAHZfLzRe Q7Zfp3VguzRDTzYuz7NZl7WXcdzZhXZo09roqFVS83VenzZgs7M+/zVqq/WMqd1w5Ea8ANDE lZqjgRgmUTWCNRerrXEu1zIzQzRnT/M1P7Nlb7Y1u7NRb/Y2kzU++3I/T7e28PBWh02jXTdt W9psV9FzSzNMB/d0M7d4+zJ4O/dDlzdMH/eQFUb0mYQcC/ZLyLcz0Tcct5+M3Uxw7zd/97d/ /zeAB7iADziB8zcuFTiCJ7iCDzgDi/fMeDE32fcVS7gOV7iFXziGZ7iGx15AAAA7 ------=_NextPart_000_0006_01C64DE5.F9E2AEB0-- From mpls-bounces@lists.ietf.org Wed Mar 22 14:44:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9DS-0005PB-4o; Wed, 22 Mar 2006 14:41:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9DR-0005P6-C1 for mpls@ietf.org; Wed, 22 Mar 2006 14:41:57 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9DQ-00071o-3G for mpls@ietf.org; Wed, 22 Mar 2006 14:41:57 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00F2JNWLAK@usaga01-in.huawei.com> for mpls@ietf.org; Wed, 22 Mar 2006 11:38:45 -0800 (PST) Received: from huawei.com ([172.17.1.102]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ001ICNWKJ2@usaga01-in.huawei.com> for mpls@ietf.org; Wed, 22 Mar 2006 11:38:45 -0800 (PST) Received: from [172.24.1.6] (Forwarded-For: [130.129.132.181]) by szxmc02-in.huawei.com (mshttpd); Thu, 23 Mar 2006 03:41:57 +0800 Date: Thu, 23 Mar 2006 03:41:57 +0800 From: xuxiaohu 41208 To: mpls@ietf.org Message-id: <1365d4f13673f4.13673f41365d4f@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_KcgMXCWXcRjjMpUucsHbhg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [mpls] Comment is expected on draft-xu-mpls-rsvp-te-bidirection-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 This is a multi-part message in MIME format. --Boundary_(ID_KcgMXCWXcRjjMpUucsHbhg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi=2C all=2C After the presentation of my draft =A1=B0draft-xu-mpls-rsvp-te-bidirectio= n-00=2Etxt=A1=B1 on the MPLS session of IETF65=2C the WG chair suggested = me to make further discussion in the mailing list=2E My draft provides a easy method of establishing bidirectional TE tunnel=2E= It only requires LERs to be upgraded to support binding object which is = a little extension to current RSVP-TE=2E Compared with the method of establishing bidirectional TE tunnel defined = in GMPLS=2C there is no additional requirement on middle-hop LSRs=2C they= only need to process the path and resv message with the unknown binding = object transited transparently=2E In addition=2C there is no need for pat= h message to be extended to assign label and the paths of two opposite tu= nnels to be bound can be different in topology=2E Is it worthwhile to achieve bidirectional TE tunnel with little extension= to RSVP-TE=3F Any comment is expected=2E Xiaohu Xu --Boundary_(ID_KcgMXCWXcRjjMpUucsHbhg) Content-type: text/x-vcard; name=x41208.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=x41208.vcf Content-description: Card for xuxiaohu 41208 begin:vcard n:;xuxiaohu fn:xuxiaohu version:2.1 email;internet:xuxh@huawei.com end:vcard --Boundary_(ID_KcgMXCWXcRjjMpUucsHbhg) 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 --Boundary_(ID_KcgMXCWXcRjjMpUucsHbhg)-- From mpls-bounces@lists.ietf.org Wed Mar 22 18:52:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMD5b-0005hb-Er; Wed, 22 Mar 2006 18:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMD5W-0005dn-TR; Wed, 22 Mar 2006 18:50:02 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMD5W-0000a5-In; Wed, 22 Mar 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2MNo29W024928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMD5W-0002Ey-6p; Wed, 22 Mar 2006 18:50:02 -0500 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, 22 Mar 2006 18:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-icmp-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 : ICMP Extensions for MultiProtocol Label Switching Author(s) : R. Bonica, et al. Filename : draft-ietf-mpls-icmp-05.txt Pages : 8 Date : 2006-3-22 This memo defines an extension to ICMP that permits Label Switching Routers to append MPLS information to ICMP messages. This extension has already been widely deployed and this memo is introduced to describe existing practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-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-icmp-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-icmp-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-3-22150756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-icmp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-icmp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-22150756.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 Thu Mar 23 09:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMR4x-0006vY-JI; Thu, 23 Mar 2006 09:46:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMR4w-0006vT-Hl for mpls@ietf.org; Thu, 23 Mar 2006 09:46:22 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMR4w-0005S1-8W for mpls@ietf.org; Thu, 23 Mar 2006 09:46:22 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2006 06:46:22 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,122,1141632000"; d="scan'208"; a="24275542:sNHT23920756" 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 k2NEkLVU020962; Thu, 23 Mar 2006 09:46:21 -0500 (EST) 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); Thu, 23 Mar 2006 09:46:21 -0500 Received: from [161.44.71.167] ([161.44.71.167]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 09:46:21 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <81DB4F10-C0FE-43BA-B1E2-B0C2EC7302ED@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? Date: Wed, 22 Mar 2006 17:54:26 -0500 To: LE ROUX Jean-Louis RD-CORE-LAN X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 23 Mar 2006 14:46:21.0184 (UTC) FILETIME=[8CD3B000:01C64E88] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Hi Jean-Louis, Thanks for the positive feed-back. See below, On Mar 21, 2006, at 12:33 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi JP, all > > Advertising within the IGP the number of 0-bw LSPs sounds useful. =20 > This would help data plane load balancing but also maybe control =20 > plane load optimization (avoid concentration of RSVP-TE states on =20 > the same LSR)? > Right both are motivations for this extensions indeed. > The proposed extension is quite straightforward. Indeed :-) > This implies similar IGP load as the unreserved bandwidth sub-TLVs, =20= > provided that appropriate hysterisis and dampening mechanisms are =20 > used. > Also correct. > By the way why not also advertising the number of non-0-bw LSPs? > This could also be used for control plane load optimization... > Yes I originally thought of doing this also ... Just wanted to first =20 focus on the "obvious" case where the info is really required to =20 optimize the data plane. We could easily define the exact same sub-=20 TLV for the non-0 bw TE LSP and let an implement decide whether to =20 advertise the info (in any case, both sub-TLVs would be optional of =20 course). Will be added to the next revision. > Hence the work should be pursued. > Thanks for the feed-back. JP. > Regards, > > JL > > > >> -----Message d'origine----- >> De : JP Vasseur [mailto:jvasseur@cisco.com] >> Envoy=E9 : lundi 20 mars 2006 17:15 >> =C0 : mpls@ietf.org >> Objet : [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-=20 >> lsps-00 ? >> >> Dear WG, >> >> Right after the presentation this morning, it was suggested >> to gather feed-back on the usefulness of this ID before >> moving forward. I got some feed-back off-line and on-line >> (Kenji - KDDI). >> >> Could you tell me whether you think that it is worth being pursed ? >> >> Send comments if any. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> 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 Mar 23 10:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRrG-0001FF-M9; Thu, 23 Mar 2006 10:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRrF-0001F0-7z for mpls@ietf.org; Thu, 23 Mar 2006 10:36:17 -0500 Received: from usjk1004.kddi.com ([211.4.169.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRrD-0008Rn-LR for mpls@ietf.org; Thu, 23 Mar 2006 10:36:17 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1004.kddi.com with ESMTP id k2NFaCn01465 for ; Fri, 24 Mar 2006 00:36:12 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com with ESMTP id k2NFaDo08726 for ; Fri, 24 Mar 2006 00:36:13 +0900 (JST) Received: from UTMC1114.kddi.com ([10.5.16.17]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20060323153612.ZDGE28205.usjk1009.kddi.com@UTMC1114.kddi.com> for ; Fri, 24 Mar 2006 00:36:12 +0900 Received: from UTMC1114.kddi.com (UTMC1114.kddi.com [10.5.16.17]) by post-ims.kddi.com with ESMTP; Fri, 24 Mar 2006 00:36:12 +0900 Received: from [127.0.0.1] ([133.128.75.150] [133.128.75.150]) by post-ims.kddi.com with ESMTP; Fri, 24 Mar 2006 00:36:12 +0900 Date: Fri, 24 Mar 2006 00:35:59 +0900 From: Kenji Kumaki To: mpls@ietf.org Subject: Re: [mpls] draft-vasseur-mpls-number-0-bw-te-lsps-00 In-Reply-To: <6343A00D-F629-4026-AD4B-C2EAB85CFF1C@cisco.com> References: <6343A00D-F629-4026-AD4B-C2EAB85CFF1C@cisco.com> Message-Id: <20060324003401.9E43.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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, I think this draft is very useful. Many sevice providers including my company use 0 bandwidth LSPs and them for load balance and fast reroute. I'd like to support this draft. Thanks, Kenji On Tue, 7 Feb 2006 18:45:23 -0500 JP Vasseur wrote: > Hi, > > Just to let you know that a new (quite simple) ID has been posted > proposing OSPF/ISIS Link sub-TLV to advertise the number of > unconstrained TE LSPs signaled across a link. Comments are very welcome. > > Thanks. > > JP. > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls -- Kenji Kumaki _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat Mar 25 03:53:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN4UB-0007HE-Cc; Sat, 25 Mar 2006 03:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMq1c-0004Om-3G for mpls@ietf.org; Fri, 24 Mar 2006 12:24:36 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMq1a-0002sN-Rd for mpls@ietf.org; Fri, 24 Mar 2006 12:24:36 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 242BACC34 for ; Fri, 24 Mar 2006 12:24:13 -0500 (EST) Received: from EVS7.ams.gblxint.com ([10.60.51.79]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 12:24:13 -0500 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] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? Date: Fri, 24 Mar 2006 12:24:11 -0500 Message-ID: <037B683BA5E8D14E8272655F7F5AE4B7038B0308@EVS7.ams.gblxint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? Thread-Index: AcZMOlrp9+dN5IEYRwy8otM79ldWRQDDaMew From: "Meyer, Matthew" To: X-OriginalArrivalTime: 24 Mar 2006 17:24:13.0185 (UTC) FILETIME=[C4FE1710:01C64F67] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-Mailman-Approved-At: Sat, 25 Mar 2006 03:51:01 -0500 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 I would like to echo my support for this work and encourage others to speak up. JL's suggestion to extend this to additionally include total LSP count makes a great deal of sense. IMO, it would be much better for providers to have this tool in their toolbox than not. Consider the impacts of telcom industry consolidation and Inter-provider MPLS Partnerships - the equipment we may support tomorrow or network access we may extend services over may not have the same capabilities as our own. Providing total count would allow a complete state view of the network enabling flexibility for LERs to not only distribute temporarily unaccounted traffic and associated risk more fairly per transmission path, but also (potentially) skew state allocation per link /size/ or even router type. As an example, a network might posses multiple candidate paths over dissimilar sized (or capability) line cards (use ZBTE metric and link size to weight selection) or between LSRs of varied state processing capability (use ZBTE and affinity or SRLG). Some of the problems providers may have weeded out in the lab may show up welded to our networks or our service in some way shape or form. If it seems irrelevant internally we need to remember to think about the bigger picture. Thanks, Matthew -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Monday, March 20, 2006 11:15 AM To: mpls@ietf.org Subject: [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? Dear WG, Right after the presentation this morning, it was suggested to gather =20 feed-back on the usefulness of this ID before moving forward. I got =20 some feed-back off-line and on-line (Kenji - KDDI). Could you tell me whether you think that it is worth being pursed ? Send comments if any. Thanks. JP. _______________________________________________ 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 byvcjj@dubplates.com Mon Mar 27 05:30:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNozJ-0003s0-FQ; Mon, 27 Mar 2006 05:30:17 -0500 Received: from 200-126-74-170.bk5-dsl.surnet.cl ([200.126.74.170] helo=mail.dubplates.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNozH-0007Pt-Td; Mon, 27 Mar 2006 05:30:17 -0500 message-id: <00a301c65189$70ec6db0$0321cd46@ZAQME> From: "Amy" To: , , Subject: Its here.... Date: Mon, 27 Mar 2006 04:30:17 -0600 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.3790.1830 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 2.7 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Obtaining a DIPLOMA has never been so easy ! Call today and find out how you could get your DIPLOMA from a highly credible college, Full Transcripts, A Letter of Recommendations, and even honors. 1-206-984-0106 No required tests, classes, books, or interviews. Diplomas are available include but are not limited to: Bachelors, Masters, MBA, and Doctorate (PhD) Available in any field of your choice. Everyone is approved, Never is anyone turned down. Total Confidentiality assured. Call Today 1-206-984-0106 get a DIPLOMA within days!!! 24 hours a day, 7 days a week including Sunday and Holidays. 1-206-984-0106 From mpls-bounces@lists.ietf.org Wed Mar 29 08:30:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOaiL-00021c-6K; Wed, 29 Mar 2006 08:27:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOaiJ-00020h-S6 for mpls@ietf.org; Wed, 29 Mar 2006 08:27:55 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOaiJ-0004NQ-Br for mpls@ietf.org; Wed, 29 Mar 2006 08:27:55 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FOaiV-0005iI-00 for mpls@ietf.org; Wed, 29 Mar 2006 14:28:08 +0100 Received: from Puppy ([217.158.132.128] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 14:28:21 +0100 Message-ID: <014101c65334$97e8d0a0$6400a8c0@Puppy> From: "Adrian Farrel" To: Date: Tue, 28 Mar 2006 20:12:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Mar 2006 13:28:22.0375 (UTC) FILETIME=[A6849770:01C65334] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: [mpls] ERO implementation survey in CCAMP 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 In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, CCAMP determined that implementations must support any form of ERO that is legitimately sent by any other implementation. At the same time there is a desire to reduce the number of options if this is possible. Lastly, there was some confusion about what the RFCs actually allow you to do, and rather than debate this as though we were lawyers, it may be more profitable to look at what current implementations do. Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 go to Draft Standard. To move things forward, I would like to do an informal and *confidential* survey of current implementations. Please respond to each question below with, Yes / No / NA NA would largely apply where the implementation is found on a NE where the technology makes the ERO option inappropriate. Send your responses to me and not to the mailing lists (unless you fancy the publicity). Thanks, Adrian 1. EROs built for use on Path messages For each hop in the path, which of the following options does your implementation utilise? This question applies to EROs that your implementations construct, NOT to EROs that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects 2. EROs received from the previous hop on Path messages Which *top* subobjects in the ERO does your implementation support receiving? This question applies to ERO subobjects that your implementations must handle, NOT to ERO subobjects that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Mar 29 18:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOkQU-0001bk-Hi; Wed, 29 Mar 2006 18:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOkQN-0001UL-5f; Wed, 29 Mar 2006 18:50:03 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOkQM-0007rz-HF; Wed, 29 Mar 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k2TNo20e032397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FOkQM-0004bB-3j; Wed, 29 Mar 2006 18:50:02 -0500 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, 29 Mar 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-upstream-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 : MPLS Upstream Label Assignment for RSVP-TE Author(s) : R. Aggarwal, J. Le Roux Filename : draft-ietf-mpls-rsvp-upstream-00.txt Pages : 8 Date : 2006-3-29 This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-upstream-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-rsvp-upstream-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-upstream-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-3-29150250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-upstream-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-upstream-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-29150250.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--