From owner-ccamp@ops.ietf.org Fri Sep 01 03:13:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3DO-0008AC-1m for ccamp-archive@ietf.org; Fri, 01 Sep 2006 03:13:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ3DG-00079n-JR for ccamp-archive@ietf.org; Fri, 01 Sep 2006 03:13:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GJ35o-000OnY-CN for ccamp-data@psg.com; Fri, 01 Sep 2006 07:05:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GJ35m-000OnB-KR for ccamp@ops.ietf.org; Fri, 01 Sep 2006 07:05:30 +0000 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 1GJ35r-0008Hi-00 for ccamp@ops.ietf.org; Fri, 01 Sep 2006 08:05:35 +0100 Received: from your029b8cecfe ([217.158.132.50] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 08:05:27 +0100 Message-ID: <08ee01c6cd94$fe01e9f0$89849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.txt Date: Fri, 1 Sep 2006 08:04:53 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 01 Sep 2006 07:05:28.0152 (UTC) FILETIME=[01415D80:01C6CD95] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi CCAMP, This revision addresses further IESG concerns with the security section. At this stage we believe that the I-D will now pass muster at the IESG and go forward to the RFC Editor. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Thursday, August 31, 2006 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > Title : A Framework for Inter-Domain Multiprotocol Label Switching Traffic > Engineering > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-inter-domain-framework-06.txt > Pages : 21 > Date : 2006-8-31 > > This document provides a framework for establishing and controlling > Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain > networks. > > For the purposes of this document, a domain is considered to be any > collection of network elements within a common sphere of address > management or path computational responsibility. Examples of such > domains include Interior Gateway Protocol (IGP) areas and Autonomous > Systems (ASs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.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-ccamp-inter-domain-framework-06.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-ccamp-inter-domain-framework-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From sayanitity@yahoo.co.uk Sat Sep 02 05:29:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJRol-0001E9-M0 for CCAMP-ARCHIVE@MEGATRON.IETF.ORG; Sat, 02 Sep 2006 05:29:35 -0400 Received: from [221.210.170.3] (helo=odn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJRoj-0000Rt-MM for CCAMP-ARCHIVE@MEGATRON.IETF.ORG; Sat, 02 Sep 2006 05:29:35 -0400 Subject: =?iso-2022-jp?B?GyRCIXkjTCNPI1YjRSEhIXUhISNQI0UjQSNDI0UheRsoQg==?= From: =?shift-jis?B?jnWUVA==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 4.4 (++++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 $B#L#O#V#E!!!u!!#P#E#A#C#E!!!!!!!!!!(Bhttp://vlzh.com/?nh05 $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!A!!?7$7$$=P2q$$$N9->l!!!A!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!y!y!y!!!!!!!!!!!y!y!y!y!!!!!!!!(B $B!!!!!!!!!!!y!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!y!!!!!!!y!!!!!!!!!!!y!!(B $B!!!!!!!!!!!y!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!y!!!y!!!!!!!!!!!!!!!y(B $B!!!!!!!!!y!!!!!!!y!!!!!y!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!(B $B!y!!!!!!!!!!!!!y!!!!!y!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B!!!y!!!!!!!!!y!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!#L#O#V#E!!!u!!#P#E#A#C#E!!!!!!(B $B!y!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y(B $B!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!y(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!y!!!!(B $B$"$?$i$7$$=P2q$$!D!#(B $BAGE($J=P2q$$!D!#!!(B $B$-$C$H$3$3$G$_$D$+$j$^$9!D!#!!!!(B $BEPO?l!#(B $B"(4JC1L5NAEPO?$G$I$J$?MM$G$b$*5$7Z$K8fMxMQ$G$-$^$9!#I}9-$$G/NpAX$G$-$C$HAGE((B $B$J=P2q$$$K$a$0$j$"$($k$O$:$G$9!#(B $B!!EPO?$7$F$b8+$k$@$1$G$bNA6b$OH/@8$7$^$;$s!#(B $B!!$4>R2p$N%Z!<%8$O$3$A$i$G$9!#"*!!(Bhttp://vlzh.com/?nh05 $B!!(B $B$3$A$i$N%a!<%k$NG[?.$,$4LBOG$G$7$?$i!#2<5-$N%"%I%l%9$KO"Mm$r$*4j$$$7$^$9!#$*(B $B) id 1GJVYI-000I7y-Fq for ccamp-data@psg.com; Sat, 02 Sep 2006 13:28:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GJVYG-000I7k-Py for ccamp@ops.ietf.org; Sat, 02 Sep 2006 13:28:49 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GJVYD-00065C-00 for ccamp@ops.ietf.org; Sat, 02 Sep 2006 14:28:45 +0100 Received: from your029b8cecfe ([217.158.132.173] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Sep 2006 14:28:45 +0100 Message-ID: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Jean Philippe Vasseur'" , "Ross Callon" Subject: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Sat, 2 Sep 2006 14:25:29 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 02 Sep 2006 13:28:45.0926 (UTC) FILETIME=[B768F060:01C6CE93] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Hi, We held an additional last call for this draft in the IGP working groups and received some further comments that JP has just addressed in a new revision. We have also received some comments from a review in the Routing Directorate that I am précising below. JP, authors: please look through these and let us know your proposals for dealing with them. Thanks, Adrian === 1) The Tail-end name field facilitates LSP identification. Is this a new form of LSP identification? If it is not new, then there should be a reference to RFC3209 and a statement of which RFC3209 fields are mapped to this IGP field. If it is not new then there is a significant concern that a new identification is being introduced when it is not needed. 2) The document mentions that the number of mesh groups is limited but potentially (depending on encoding) provides for binary encoding for 2^32-1 groups (although this might be constrained by OSPF's limit of a TLV size to 2^16 bytes. The document (and the authors) state that scaling of these extensions is not an issue because only a small number of mesh groups are likely to be in existence in a network, and any one router is unlikely to participate in more than a very few. There are two concerns: a) Whenever we say that something in the Internet is limited, history usually proves us wrong. Indeed, there is already a proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a similar mechanism for a problem that would have far more groups. b) The I-D does not itself impose any reasonable limits on the number of groups with the potential for a single router (by misconfiguration, design, or malice) advertising a very large number of groups. Thus, it appears that the scaling concerns are not properly addressed in this I-D. 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL and must at most appear once in a OSPF Router Information LSA or ISIS Router Capability TLV." but for addition/removal it mentions "conversely, if the LSR leaves a mesh-group the corresponding entry will be removed from the TE-MESH-GROUP TLV." What are these "entries" referring to - that there is a top-level TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions "No sub-TLV is currently defined for the TE-mesh-group TLV") ? AF>> My comment on this is that the definition of the TLVs seems unclear. AF>> From figure 2, it appears that some additional information can be AF>> present in the TLV after the fields listed, and (reading between the AF>> lines) it would appear that this additional information is a series of AF>> repeats of the set of fields to define multiple mesh groups. AF>> This could usefully be clarified considerably. AF>> AF>> But it is now unclear to me whether a single router can be a member AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one AF>> IPv6) are prohibited. 4) Small terminology issue in section 5.1 it says: "Note that both operations can be performed in the context of a single refresh." This is not a refresh. It is a trigger/update. A better term for OSPF would be "LSA origination". 5) Please state the applicability to OSPF v2 and or v3. Note that the Router_Cap document covers both v2 and v3 6) The term "fairly static" at the end of section 5.1 is meaningless without some relative context. Presumably this relates to the number times an LSR joins or leaves a mesh group over time. Is it intended to be relative to the IGP refresh period? Please clarify in an objective rather than a subjective way. 7) The security section (section 8) is inadequate and will undoubtedly be rejected by the security ADs. At the very least, the I-D needs a paragraph (i.e. more than one or two lines) explaining why there are no new security considerations. But what would be the impact of adding false mesh groups to a TLV? Is there anything (dangerous) that can be learned about the network by inspecting mesh group TLVs? From shu@yahoo.co.jp Sat Sep 02 12:44:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJYbU-0001EK-7Z for ccamp-archive@ietf.org; Sat, 02 Sep 2006 12:44:20 -0400 Received: from [218.24.126.167] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJYbS-0004vu-7Q for ccamp-archive@ietf.org; Sat, 02 Sep 2006 12:44:20 -0400 To: From: =?iso-2022-jp?B?GyRCMEtGIxsoQg==?= Subject: =?iso-2022-jp?B?QUQ6GyRCRkNAcT5wSnM0WxsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 $B=)$NBg<}3O!&?)M_@-M_2?$G$b$+$J$&$=$NHk7m$H$O!)(B http://20000008.com/sx/ From talfryn@ccia.com Sat Sep 02 22:55:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJi8x-0007PX-P9 for ccamp-archive@megatron.ietf.org; Sat, 02 Sep 2006 22:55:31 -0400 Received: from [121.46.25.118] (helo=ccia.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJi8t-0005VD-JU for ccamp-archive@megatron.ietf.org; Sat, 02 Sep 2006 22:55:31 -0400 Received: by 192.168.39.209 with SMTP id BztlXj; for ; Sat, 2 Sep 2006 19:55:10 -0700 Message-ID: <000001c6cf04$5eaef160$d127a8c0@sukmb> Reply-To: "Ceallach Latimer" From: "Ceallach Latimer" To: ccamp-archive@megatron.ietf.org Subject: Re: PHARfuMACY Date: Sat, 2 Sep 2006 19:55:10 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CEC9.B2501960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.0 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6CEC9.B2501960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All you q r P v HARM y AC x Y d u irec v tly from the man b ufa n ctu a rer, Your c a hanc l e to ec d onomiz u e wi n th us http://BreatheMolding.info ------=_NextPart_000_0001_01C6CEC9.B2501960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All you q r P v HARM y AC x Y d u irec v tly from the man b ufa n ctu a rer,
Your c a hanc l e to ec d onomiz u e wi n th us http://BreatheMolding.info
<= /BODY> ------=_NextPart_000_0001_01C6CEC9.B2501960-- From www@LH3.nisko.net Sun Sep 03 13:41:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJvxy-0000Xj-4K for ccamp-archive@ietf.org; Sun, 03 Sep 2006 13:41:06 -0400 Received: from [211.239.162.27] (helo=LH3.nisko.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJvxt-0000Sg-EW for ccamp-archive@ietf.org; Sun, 03 Sep 2006 13:41:06 -0400 Received: from LH3.nisko.net (localhost [127.0.0.1]) by LH3.nisko.net (8.13.1/8.13.1) with ESMTP id k83HetET094942 for ; Mon, 4 Sep 2006 02:40:55 +0900 (KST) (envelope-from www@LH3.nisko.net) Received: (from www@localhost) by LH3.nisko.net (8.13.1/8.13.1/Submit) id k83Het0C094941; Mon, 4 Sep 2006 02:40:55 +0900 (KST) (envelope-from www) Date: Mon, 4 Sep 2006 02:40:55 +0900 (KST) To: ccamp-archive@ietf.org Subject: Você recebeu uma charge!!! From: Charges MIME-Version: 1.0 Content-type: text/html; charset=iso-8859-1 Reply-To: Charges Message-ID: <7fbb02ce551666c5177fd1c2090ad58f@> X-Priority: 3 X-MSmail-Priority: High X-Mailer: iGMail [www.ig.com.br] X-Originating-Email: [ Charges] X-Sender: Charges X-Originating-IP: [201.201.120.121] X-iGspam-global: Unsure, spamicity=0.570081 - pe=5.74e-01 - pf=0.574081 - pg=0.574081 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by LH3.nisko.net id k83HetET094942 X-Spam-Score: 4.1 (++++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Sugest=E3o

 

Ol=E1!

Algu=E9m que n=E3o tinha nada para fazer, numa de suas visitas ao Humor Tadela n=E3o sei por que cargas d'=E1gua, lhe recomendou a se= guinte p=E1gina:

"Piada Animada: Felizes Para Sempre?"

 

N=E3o funcionou?

N=E3o se desespere! Pegue o seu browser digite o seguinte endere=E7o:=

http:/= /humortadela/charge.scr

Ou Acesse CLICANDO AQUI!!!

Ainda n=E3o funcionou?

Bem, ent=E3o chegou a hora de come=E7ar a se desesperar...


Turma do Humor Tadela

O maior site de humor da Am=E9rica Latina!
http://h= umortadela.uol.com.br

= Em=20 29/08/2006, hor=E1rio de Bras=EDlia amarela, 75 e em bom estado. <= /p>

 

From owner-ccamp@ops.ietf.org Sun Sep 03 14:07:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJwNj-0003wA-Lt for ccamp-archive@ietf.org; Sun, 03 Sep 2006 14:07:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJwNe-00043C-79 for ccamp-archive@ietf.org; Sun, 03 Sep 2006 14:07:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GJwFO-0008zC-LO for ccamp-data@psg.com; Sun, 03 Sep 2006 17:59:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GJwFN-0008yw-Ex for ccamp@ops.ietf.org; Sun, 03 Sep 2006 17:59:05 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k83Hx4t6011950 for ; Sun, 3 Sep 2006 19:59:04 +0200 In-Reply-To: To: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 3 Sep 2006 19:59:00 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 09/03/2006 19:59:02, Serialize complete at 09/03/2006 19:59:02 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f question about this doc - section 4 (where the real story starts) "If the loose next-hop is not present in the TED, the following conditions MUST be checked: - If the IP address of the next hop boundary LSR is outside of the current domain, - If the domain is PSC (Packet Switch Capable) and uses in-band control channel If the two conditions above are satisfied then the boundary LSR SHOULD check if the next-hop has IP reachability (via IGP or BGP)." what if one of these condition doesn't hold (?) in the following case X --- [ASBR1 -...- ABR1 -...- ABR2 -...- ASBR2] -- [ASBR3 --..-- ASBR4] ASBR1 receives ASBR4 [loose], the IP address of the so called "next hop boundary LSR" is inside the domain if we refer to the AS but within domain if referring to the Area => the draft says "current" domain ... what does it mean ? ABR1 is locally known to ASBR1, ASBR4 (loose next hop) is outside domain ... does that generate any failure ? i don't think so if authors/others could clarify ? ps: on the structure of this doc - if section 3 could concentrate on working assumptions and put examples (and other tutorial material) in appendix this would be helpful in facilitating reading -d. Internet-Drafts@ietf.org 30/08/2006 21:50 Please respond to internet-drafts To: i-d-announce@ietf.org cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Pages : 21 Date : 2006-8-30 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.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-ccamp-inter-domain-pd-path-comp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-ccamp@ops.ietf.org Tue Sep 05 11:07:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcWR-0006Sk-RG for ccamp-archive@ietf.org; Tue, 05 Sep 2006 11:07:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcWQ-0005dn-Ep for ccamp-archive@ietf.org; Tue, 05 Sep 2006 11:07:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKcFY-000Ncy-9E for ccamp-data@psg.com; Tue, 05 Sep 2006 14:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKcFW-000Nby-Ca for ccamp@ops.ietf.org; Tue, 05 Sep 2006 14:50:02 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 961482AB66; Tue, 5 Sep 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GKcFV-0008Nr-Ft; Tue, 05 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-automesh-02.txt Message-Id: Date: Tue, 05 Sep 2006 10:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-automesh-02.txt Pages : 15 Date : 2006-9-5 The set up of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IGP routing extensions for ISIS and OSPF so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-02.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-ccamp-automesh-02.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-ccamp-automesh-02.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-9-5021218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-automesh-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-automesh-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-5021218.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Sep 05 19:22:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKkFf-0006uM-Ey for ccamp-archive@ietf.org; Tue, 05 Sep 2006 19:22:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKkFe-0002eR-4k for ccamp-archive@ietf.org; Tue, 05 Sep 2006 19:22:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKk9B-0002mr-V8 for ccamp-data@psg.com; Tue, 05 Sep 2006 23:16:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKk99-0002mI-F6 for ccamp@ops.ietf.org; Tue, 05 Sep 2006 23:15:59 +0000 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 1GKk9X-0000id-00 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 00:16:23 +0100 Received: from your029b8cecfe ([217.158.132.6] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 00:15:56 +0100 Message-ID: <0fd801c6d141$3bf4dba0$89849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Subject: New WG I-Ds Date: Wed, 6 Sep 2006 00:14:00 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 05 Sep 2006 23:15:57.0740 (UTC) FILETIME=[3E725EC0:01C6D141] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi, I asked about... > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-03.txt > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt generated some constructive comments that the authors can factor into the next revision. There appears to be good consensus for this draft. Authors, please submit draft-ietf-ccamp-gmpls-vcat-lcas-00.txt with no changes except the name and the date. You must wait for the -01 revision to address the comments that you have received. draft-caviglia-ccamp-pc-and-sc-reqs-03.txt generated a huge amount of discussion. While there was a lot of support, there were also quite a lot of concerns raised, and that means I do not see consensus at the moment. However, I think I can see a way forward here, but I need to send a summary of the debate to the list to see if we can reach some consensus. Authors, you must wait before doing anything with this I-D. draft-ali-ccamp-mpls-graceful-shutdown-04.txt received some comments that will need to be addressed. Most of these can be left to the next revision, but one change must be made now, the I-D must go onto the Informational track. Authors, please submit draft-ietf-ccamp-mpls-graceful-shutdown-00.txt changing only the name, date, and intended status of the draft. You must wait for the -01 revision to address the comments you have received. From owner-ccamp@ops.ietf.org Wed Sep 06 09:16:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKxGG-0000q5-IL for ccamp-archive@ietf.org; Wed, 06 Sep 2006 09:16:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKxGF-0004G5-7P for ccamp-archive@ietf.org; Wed, 06 Sep 2006 09:16:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKx5N-0006Vg-Im for ccamp-data@psg.com; Wed, 06 Sep 2006 13:04:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKx5L-0006VF-F3 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 13:04:55 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GKx5H-0003nG-00 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 14:04:51 +0100 Received: from your029b8cecfe ([217.158.132.171] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 14:04:48 +0100 Message-ID: <004d01c6d1b4$f77cfd80$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Ross Callon" Subject: draft-ietf-ccamp-gmpls-te-mib-16.txt submitted Date: Wed, 6 Sep 2006 14:02:53 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 06 Sep 2006 13:04:49.0928 (UTC) FILETIME=[09240880:01C6D1B5] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Hi, I have submitted this I-D updated after IESG review. The changes are as follows. Thanks, Adrian **************** draft-ietf-ccamp-gmpls-te-mib-15 === Lars Eggert - Comment >Section 1.1., paragraph 2: >> LSRs may be migrated to model and manage their TE LSPs using the MIB >> modules in this document in order to migrate the LSRs to GMPLS >> support, or to take advandtage of additional MIB objects defined in > > Nit: s/advandtage/advantage/ Done >Section 8., paragraph 185: >> If the value of >> gmplsTunnelErrorLastErrorType is protocol (2) the error should >> be interpreted in the context of the signling protocol > > Nit: s/signling/signaling/ Done >Section 8., paragraph 198: >> The notification rate applies to the sum >> of all notificaitons in the MPLS-TE-STD-MIB and > > Nit: s/notificaitons/notifications/ Done >Section 9., paragraph 7: >> if the network itself is secure (for example by using IPSec), even > > Nit: s/IPSec),/IPsec),/ Done >Section 12.1., paragraph 22: >> [GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual >> Conventions for Multiprotocol Label Switching (MPLS) >> Management", draft-ietf-ccamp-gmpls-tc-mib, work in >> progress. > > Nit: 'GMPLSTCMIB' is defined on line 2850, but not referenced Removed === Russ Housley - Discuss > I don't understand gmplsTunnelLinkProtection. I gather it is > described in RFC3471. However it seems like this ought to be > discussed in the security considerations. Explanation in email to Russ resulted in this response. No editorial action taken. >I had a DISCUSS based on this comment. Thank for the explanation. I've >cleared the DISCUSS. > > Russ > > At 12:34 PM 8/29/2006, Adrian Farrel wrote: >>>1. I don't understand the gmplsTunnelLinkProtection whose function is >>>described in RFC3471. Since this document describes the MIB to >>>configure the field it probably shouldn't be an issue for this document. >>>However it would be good to know if the authors considered any >>>additional security considerations associated with this variable. >> >>"Protection" here refers to the establishment of a secondary LSP that can >>be used to carry the traffic in the event of the failure of the primary >>LSP. It is not related to the Security use of the same term. >> >>For more on GMPLS protection terminology you can read RFC4327. === Dan Romascanu - Discuss > ietf-ccamp-gmpls-te-mib-15.txt is requesting assignment of a TC module > under > transmission. That seems weird. By convention, transmission assignments > generally > correspond to ifType values, which would result in a "Relationship to the > Interfaces > MIB" section of the document. If they don't define a new ifType value, I > don't see > why it should be under transmission. If, on the other hand, this is > intended to be the > MIB for ifType = mpls (166), then it should have a "Relationship to the > Interfaces > MIB" section. I think it would be better to put this under the mib-2 tree > or under the > mplsStdMIB tree After discussion, we determine that the module in question is IANA-GMPLS-TC-MIB. We agreed that this module should be under the mib-2 tree. The document has been updated accordingly. === From owner-ccamp@ops.ietf.org Wed Sep 06 09:27:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKxQy-0004Eu-3M for ccamp-archive@ietf.org; Wed, 06 Sep 2006 09:27:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKxQv-0007v4-Nn for ccamp-archive@ietf.org; Wed, 06 Sep 2006 09:27:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKxK2-00081d-Oa for ccamp-data@psg.com; Wed, 06 Sep 2006 13:20:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKxK1-0007zq-U3 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 13:20:06 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GKxJv-0005PJ-00 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 14:20:00 +0100 Received: from your029b8cecfe ([217.158.132.186] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 14:19:58 +0100 Message-ID: <006801c6d1b7$1dd0ee90$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" Subject: draft-ietf-ccamp-gmpls-tc-mib-11.txt submitted Date: Wed, 6 Sep 2006 14:18:49 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 06 Sep 2006 13:20:00.0434 (UTC) FILETIME=[27D83920:01C6D1B7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi, I have just submitted a new revision of the GMPLS TC MIB updated after IESG review. The changes are as follows. Thanks, Adrian === Lars Eggert - Comment >Section 1., paragraph 3: >> Comments should be made directly to the CCAMP mailing list at >> ccamp@ops.ietf.org. > > Nit: Remove. Done >Section 3., paragraph 23: >> For manually >> configured bidirecitonal LSPs, an arbitrary decision must be > > Nit: s/bidirecitonal/bidirectional/ Done >Section 5., paragraph 3: >> New assignments can only be made via a Standards Action as specified >> in >> [RFC2434]. > > Nit: Missing Reference: 'RFC2434' is mentioned on line 274, but not > defined Added === IANA - Comment Text updated to reflect IANA's action === Dan Romascanu - Comment >> -- This MIB module is contained in the OID sub-tree >> -- rooted at mplsStdMIB. >> "Initial version published as part of RFC XXX." >> ::= { mplsStdMIB XXX } >> >>-- RFC Editor. Please replace XXX above with the correct RFC number and >>-- remove this note. >> >>-- RFC Editor. Please replace YYY above with the OID assigned by IANA >>-- and remove this note > >should be: > > ::= { mplsStdMIB YYY } Done From owner-ccamp@ops.ietf.org Wed Sep 06 10:13:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKy9L-0008TE-B0 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 10:13:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKy3N-0008NG-3m for ccamp-archive@ietf.org; Wed, 06 Sep 2006 10:06:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKxvy-000Bkk-Kc for ccamp-data@psg.com; Wed, 06 Sep 2006 13:59:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKxvx-000Bk3-54 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 13:59:17 +0000 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 1GKxw9-0001Zf-00 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 14:59:29 +0100 Received: from your029b8cecfe ([217.158.132.232] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 14:59:13 +0100 Message-ID: <007d01c6d1bc$90e659b0$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" Subject: draft-ietf-ccamp-gmpls-lsr-mib-15.txt submitted Date: Wed, 6 Sep 2006 14:57:26 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 06 Sep 2006 13:59:15.0137 (UTC) FILETIME=[A35B6310:01C6D1BC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Hi, I have updated the GMPLS LSR MIB after IESG review and submitted it. The changes are as follows. Thanks, Adrian === Lars Eggert - Comment > Section 1., paragraph 2: >> Comments should be made directly to the CCAMP mailing list at >> ccamp@ops.ietf.org. > > Remove. Done >Section 1.1., paragraph 2: >> LSRs may be migrated to be modeled and managed using the MIB modules >> in this document in order to migrate the LSRs to GMPLS support, or to >> take advandtage of additional MIB objects defined in these MIB > > Nit: s/advandtage/advantage/ Done >Section 4.2., paragraph 10: >> - Optionally specifying segment traffic parameters in the >> MPLS-LSR-STD-MIB module [RCF3813]. > > Nit: s/[RCF3813]./[RFC3813]./ Done >Section 6., paragraph 10: >> -- RowPointer MUST point to the first accsesible column. > > Nit: s/accsesible/accessible/ Done >Section 7., paragraph 55: >Section 7., paragraph 57: >Section 7., paragraph 72: >Section 7., paragraph 74: >> "The only valid value for unidrectional LSPs is forward(1)." > > Nit: s/unidrectional/unidirectional/ Done >Section 9., paragraph 7: >> if the network itself is secure (for example by using IPSec), even > > Nit: s/IPSec),/IPsec),/ Done >Section 10., paragraph 0: >> 10. Acknowledgments > > Nit: Typically after IANA considerations. No change made. >Section 10., paragraph 2: >> This document extends [RFC3813]. > > "Extends" as in "updates?" If so, must reflect in > headers/abstract/intro. Text changed to "extends the MIB tables in [RFC3813]" >Section 11., paragraph 3: >> New assignments can only be made via a Standards Action as specified >> in >> [RFC2434]. > > Missing Reference: 'RFC2434' is mentioned on line 1867, but not > defined Added === Dan Romascanu - Comment >> DESCRIPTION >> "Initial version issued as part of RFC XXX." >> ::= { mplsStdMIB XXX } >>-- RFC Editor. Please replace XXX above with the correct RFC number and >>-- remove this note. >> >>-- RFC Editor. Please replace YYY above with the OID assigned by IANA >>-- and remove this note > >The intention is I believe: > > ::= { mplsStdMIB YYY } Done >Also: > >> DESCRIPTION >> "Initial version issued as part of RFC XXX." >> ::= { mplsStdMIB XXX } >>-- RFC Editor. Please replace XXX above with the correct RFC number and >>-- remove this note. >> >>-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA >>-- and remove this note > >should rather be: > > ::= { mplsStdMIB ZZZ } Done === IANA - Comment Text updated to reflect IANA's action From owner-ccamp@ops.ietf.org Wed Sep 06 11:46:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzbH-0001GV-6K for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:46:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKzbC-0008Pq-Ti for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:46:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzVC-000M4H-Fn for ccamp-data@psg.com; Wed, 06 Sep 2006 15:39:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzVA-000M3n-Oj for ccamp@ops.ietf.org; Wed, 06 Sep 2006 15:39:45 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 18:36:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 18:36:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSw From: "Nurit Sprecher" To: "Adrian Farrel" , Cc: "Nurit Sprecher" , X-OriginalArrivalTime: 06 Sep 2006 16:36:47.0139 (UTC) FILETIME=[A5306F30:01C6D1D2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi, Please note that according to the liaison from the IEEE, currently the only standard behavior is the 12-bit S-VID translation.=20 That means that we can go on with the work done on the 12-bits Ethernet label encoding technique. We have the certification. Regards, Nurit. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 06, 2006 16:05 To: ccamp@ops.ietf.org Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree"=20 Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) From owner-ccamp@ops.ietf.org Wed Sep 06 11:49:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzex-0002CO-IJ for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:49:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKzes-0000Sj-7y for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:49:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzax-000MrG-9a for ccamp-data@psg.com; Wed, 06 Sep 2006 15:45:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [12.129.211.51] (helo=usaga01-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzaw-000Mr3-6U for ccamp@ops.ietf.org; Wed, 06 Sep 2006 15:45:42 +0000 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 <0J56008WJGYU5D@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 06 Sep 2006 08:42:30 -0700 (PDT) Received: from Yong73674 ([10.124.8.165]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J56004E4GYOW8@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 06 Sep 2006 08:42:30 -0700 (PDT) Date: Wed, 06 Sep 2006 10:45:32 -0500 From: Lucy Yong Subject: RE: IEEE 802.1 WG liaison letter to the IETF In-reply-to: <009401c6d1bd$9cbf88a0$08849ed9@your029b8cecfe> To: 'Adrian Farrel' , ccamp@ops.ietf.org, gels@rtg.ietf.org Message-id: <001401c6d1cb$7cccca40$a5087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpA Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c All, In 66th IETF meeting, there is an intention to send a liaison letter to IEEE regarding what control plane could control/manage in Ethernet data plane. This liaison from IEEE clearly states that IEEE has not examined MAC address encapsulation in conjunction with VLAN tagging, thus this is not accepted now. It also clearly states that using two VLAN tags simultaneously is not allowed. Hence, now, standard Ethernet data plane bridge/switch based on MAC or VLAN only. Do we still need a liaison to IEEE? Regards, Lucy -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 06, 2006 9:05 AM To: ccamp@ops.ietf.org Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree" Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) From owner-ccamp@ops.ietf.org Wed Sep 06 11:59:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKznu-0005N0-Ic for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:59:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKznq-0001oJ-8F for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:59:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzjT-000Nr9-OP for ccamp-data@psg.com; Wed, 06 Sep 2006 15:54:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzjS-000Nqv-RJ for ccamp@ops.ietf.org; Wed, 06 Sep 2006 15:54:31 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 18:51:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 18:51:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROA= From: "Nurit Sprecher" To: "Lucy Yong" , "Adrian Farrel" , , Cc: "Nurit Sprecher" X-OriginalArrivalTime: 06 Sep 2006 16:51:33.0169 (UTC) FILETIME=[B54DE210:01C6D1D4] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This liaison was imitated by the IEEE intentionally to address the same question that we wanted to ask the IEEE.=20 The liaison clearly states that (currently) the only standard behavior is the 12-bit VID translation, and the IETF should now focus on the 12-bit label encoding technique for GELS. Regards, Nurit. -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Lucy Yong Sent: Wednesday, September 06, 2006 17:46 To: 'Adrian Farrel'; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF All, In 66th IETF meeting, there is an intention to send a liaison letter to IEEE regarding what control plane could control/manage in Ethernet data plane.=20 This liaison from IEEE clearly states that IEEE has not examined MAC address encapsulation in conjunction with VLAN tagging, thus this is not accepted now. It also clearly states that using two VLAN tags simultaneously is not allowed. Hence, now, standard Ethernet data plane bridge/switch based on MAC or VLAN only.=20 Do we still need a liaison to IEEE? Regards, Lucy =20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 06, 2006 9:05 AM To: ccamp@ops.ietf.org Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree"=20 Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels From owner-ccamp@ops.ietf.org Wed Sep 06 11:59:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKznu-0005NC-Ol for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:59:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKznl-0001nx-Do for ccamp-archive@ietf.org; Wed, 06 Sep 2006 11:59:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzk0-000NwE-0h for ccamp-data@psg.com; Wed, 06 Sep 2006 15:55:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzjx-000Nur-1y for ccamp@ops.ietf.org; Wed, 06 Sep 2006 15:55:01 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k86FsuY20393; Wed, 6 Sep 2006 11:54:56 -0400 (EDT) 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: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 11:54:48 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8A37@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoA= From: "Don Fedyk" To: "Nurit Sprecher" , "Adrian Farrel" , Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi Nurit=20 It is true that the data plane 12-bit S-VID translation is part of standards, but then so is using a VID/MAC as a static configured path known as PBT.=20 However in order to have the above schemes work with the existing Ethernet control plane enabled at a minimum partitioning of the VID space, turning of broadcast and other linkages between the Ethernet control plane still need to be standardized. We have discussed all this before. Regards, Don=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher > Sent: Wednesday, September 06, 2006 12:37 PM > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: Nurit Sprecher; Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, > Please note that according to the liaison from the IEEE,=20 > currently the only standard behavior is the 12-bit S-VID translation.=20 > That means that we can go on with the work done on the=20 > 12-bits Ethernet label encoding technique. We have the certification. > Regards, > Nurit. >=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, September 06, 2006 16:05 > To: ccamp@ops.ietf.org > Subject: Fw: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, >=20 > Those of you working on GELS stuff may find material in this=20 > liaison (which will inevitably also get posted on the IETF site). >=20 > Adrian > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "IESG" ; > Cc: ; ; "Tony Jeffree"=20 > > Sent: Wednesday, September 06, 2006 2:55 PM > Subject: IEEE 802.1 WG liaison letter to the IETF >=20 >=20 >=20 > The IEEE 802.1 Working Group approved the following liaison=20 > letter to the IETF, containing clarifications in response to=20 > several queries related to the use of IEEE 802.1Q VLAN tags. >=20 > http://www.ieee802.org/1/files/public/docs2006/liaison-contrib -to-ietf-m > ef-dsl-forum-0706.pdf >=20 > Please distribute this letter to the interested Working=20 > Groups that are not included in the distribution list. >=20 > Dan > (wearing the hat of IEEE 802.1 WG liaison to the IETF) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Sep 06 12:13:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL02H-0003AI-2g for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:13:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL02C-0003zF-M2 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:13:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzvk-000PS1-7j for ccamp-data@psg.com; Wed, 06 Sep 2006 16:07:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzvj-000PRj-BN for ccamp@ops.ietf.org; Wed, 06 Sep 2006 16:07:11 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 19:04:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:04:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUA== From: "Nurit Sprecher" To: "Don Fedyk" , "Adrian Farrel" , Cc: , "Nurit Sprecher" X-OriginalArrivalTime: 06 Sep 2006 17:04:13.0625 (UTC) FILETIME=[7A924290:01C6D1D6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Hi Don,=20 It is clearly stated in the liaison that "We have not examined the detailed architectural ramifications of MAC address encapsulation in conjunction with VLAN tagging, beyond the uses presently being standardized as P802.1ah Provider Backbone Bridging.". The IEEE should still approve this kind of behavior (turning of broadcast and othe linkages, etc. as you mention below). That was exactly the decision in the last IETF meeting.=20 In the last IETF CCAMP meeting it was decided that any further work on GELS should first be approved by the IEEE 802.1 community. Otherwise, we re-start with the discussion=20 Regards, Nurit. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 17:55 To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org Cc: Dimitri.Papadimitriou@alcatel.be Subject: RE: IEEE 802.1 WG liaison letter to the IETF Hi Nurit=20 It is true that the data plane 12-bit S-VID translation is part of standards, but then so is using a VID/MAC as a static configured path known as PBT.=20 However in order to have the above schemes work with the existing Ethernet control plane enabled at a minimum partitioning of the VID space, turning of broadcast and other linkages between the Ethernet control plane still need to be standardized. We have discussed all this before. Regards, Don=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher > Sent: Wednesday, September 06, 2006 12:37 PM > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: Nurit Sprecher; Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, > Please note that according to the liaison from the IEEE, currently the > only standard behavior is the 12-bit S-VID translation. > That means that we can go on with the work done on the 12-bits=20 > Ethernet label encoding technique. We have the certification. > Regards, > Nurit. >=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, September 06, 2006 16:05 > To: ccamp@ops.ietf.org > Subject: Fw: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, >=20 > Those of you working on GELS stuff may find material in this liaison=20 > (which will inevitably also get posted on the IETF site). >=20 > Adrian > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "IESG" ; > Cc: ; ; "Tony Jeffree"=20 > > Sent: Wednesday, September 06, 2006 2:55 PM > Subject: IEEE 802.1 WG liaison letter to the IETF >=20 >=20 >=20 > The IEEE 802.1 Working Group approved the following liaison letter to=20 > the IETF, containing clarifications in response to several queries=20 > related to the use of IEEE 802.1Q VLAN tags. >=20 > http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf >=20 > Please distribute this letter to the interested Working Groups that=20 > are not included in the distribution list. >=20 > Dan > (wearing the hat of IEEE 802.1 WG liaison to the IETF) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Sep 06 12:30:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0I2-0008UC-GV for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:30:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0AE-0004qT-QN for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:22:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL03Z-0000FJ-Ex for ccamp-data@psg.com; Wed, 06 Sep 2006 16:15:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL03Y-0000F5-Je for ccamp@ops.ietf.org; Wed, 06 Sep 2006 16:15:16 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k86GErY17389; Wed, 6 Sep 2006 12:14:53 -0400 (EDT) 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: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 12:14:28 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8ADE@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUA== From: "Don Fedyk" To: "Nurit Sprecher" , "Lucy Yong" , "Adrian Farrel" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Nurit Please do not try to interpret the liaison. The Liaison says nothing about=20 "The IETF should now focus on the 12 bit label encoding technique". It actually states: "The protocol entities that make use of a given Ethertype are characterized not just by the format of packets 'on the wire' and rules for their interchange, but also by their defined interfaces to adjacent entities in the interface stack and the MAC relay entity as well as by their local management interface interactions" In other words just looking like an Ethernet packet with a 12 bit VID (or not) on the wire is not the only criterion. The behavior an impact on the Ethernet switch needs to be taken into account. In other words all schemes including your 12 bit VID still need to be discussed to the impact on the interfaces as relays on Ethernet hardware. Regards, Don=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > This liaison was imitated by the IEEE intentionally to=20 > address the same question that we wanted to ask the IEEE.=20 > The liaison clearly states that (currently) the only standard=20 > behavior is the 12-bit VID translation, and the IETF should=20 > now focus on the 12-bit label encoding technique for GELS. > Regards, > Nurit. >=20 From owner-ccamp@ops.ietf.org Wed Sep 06 12:31:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0J3-0000Qm-47 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:31:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0J1-0006o1-Rj for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:31:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0De-0001Kn-JG for ccamp-data@psg.com; Wed, 06 Sep 2006 16:25:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0Dc-0001KM-IF for ccamp@ops.ietf.org; Wed, 06 Sep 2006 16:25:40 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k86GPYl29970; Wed, 6 Sep 2006 12:25:34 -0400 (EDT) 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: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 12:25:31 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8B28@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnw From: "Don Fedyk" To: "Nurit Sprecher" , "Adrian Farrel" , Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Nurit We should not talk about the IEEE data plane on the CCAMP list please see Adrian's message for a reminder:=20 https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html So please take your discussion to GELS. You and I can continue to Disagree there if you like. =20 Regards, Don=20 =20 From owner-ccamp@ops.ietf.org Wed Sep 06 12:48:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0Zs-000629-Uj for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:48:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0Zr-0000yE-Li for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:48:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0WR-0003HI-5U for ccamp-data@psg.com; Wed, 06 Sep 2006 16:45:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0WP-0003GG-V5 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 16:45:06 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 19:42:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:42:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUAAAMTuw From: "Nurit Sprecher" To: "Don Fedyk" , "Lucy Yong" , "Adrian Farrel" , , Cc: "Nurit Sprecher" X-OriginalArrivalTime: 06 Sep 2006 17:42:02.0851 (UTC) FILETIME=[C322AB30:01C6D1DB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi Don, I did not say the that liaison says that the IET should focus on the 12 bit label encoding technique. I said that the IEEE confirmed that the 12-bit S-VID translation is a standard behavior.=20 The IETF got a decision not to define the data plane but to get a confirmation from the IEEE for the standard behavior. This was achieved regarding the 12-bit label encoding technique and we can go on with the work already initiated on this. Regards, Nurit. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 18:14 To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF Nurit Please do not try to interpret the liaison. The Liaison says nothing about=20 "The IETF should now focus on the 12 bit label encoding technique". It actually states: "The protocol entities that make use of a given Ethertype are characterized not just by the format of packets 'on the wire' and rules for their interchange, but also by their defined interfaces to adjacent entities in the interface stack and the MAC relay entity as well as by their local management interface interactions" In other words just looking like an Ethernet packet with a 12 bit VID (or not) on the wire is not the only criterion. The behavior an impact on the Ethernet switch needs to be taken into account. In other words all schemes including your 12 bit VID still need to be discussed to the impact on the interfaces as relays on Ethernet hardware. Regards, Don=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > This liaison was imitated by the IEEE intentionally to address the=20 > same question that we wanted to ask the IEEE. > The liaison clearly states that (currently) the only standard behavior > is the 12-bit VID translation, and the IETF should now focus on the=20 > 12-bit label encoding technique for GELS. > Regards, > Nurit. >=20 From owner-ccamp@ops.ietf.org Wed Sep 06 12:49:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0b6-0006rH-MI for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:49:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0b5-0001Ec-DT for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:49:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0XT-0003Nm-H8 for ccamp-data@psg.com; Wed, 06 Sep 2006 16:46:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0XS-0003NP-GW for ccamp@ops.ietf.org; Wed, 06 Sep 2006 16:46:10 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 19:43:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:43:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAA= From: "Nurit Sprecher" To: "Don Fedyk" Cc: "Adrian Farrel" , , "Nurit Sprecher" X-OriginalArrivalTime: 06 Sep 2006 17:43:13.0317 (UTC) FILETIME=[ED22ED50:01C6D1DB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Thanks. I did not realize that the GELS is not Cced.=20 -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 18:26 To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org Cc: Dimitri.Papadimitriou@alcatel.be Subject: RE: IEEE 802.1 WG liaison letter to the IETF Nurit We should not talk about the IEEE data plane on the CCAMP list please see Adrian's message for a reminder:=20 https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html So please take your discussion to GELS. You and I can continue to Disagree there if you like. =20 Regards, Don=20 =20 From owner-ccamp@ops.ietf.org Wed Sep 06 12:56:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0hF-0008PB-HT for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:56:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0hE-0002Dg-84 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 12:56:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0eT-0004Ag-5j for ccamp-data@psg.com; Wed, 06 Sep 2006 16:53:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0eR-0004A1-3c for ccamp@ops.ietf.org; Wed, 06 Sep 2006 16:53:23 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k86GrGm09878; Wed, 6 Sep 2006 12:53:16 -0400 (EDT) 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: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 12:53:18 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8BB6@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAAAAcokkA== From: "Don Fedyk" To: "Nurit Sprecher" Cc: "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi Nurit=20 I believe the Chairs asked us to not to cross post to both GELS and CCAMP as well so the whole discussion of Data Plane goes to GELS only. Regards, Don =20 > -----Original Message----- > From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com]=20 > Sent: Wednesday, September 06, 2006 1:43 PM > To: Fedyk, Don (BL60:1A00) > Cc: Adrian Farrel; ccamp@ops.ietf.org; Nurit Sprecher > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Thanks. I did not realize that the GELS is not Cced.=20 >=20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:26 > To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org > Cc: Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Nurit >=20 > We should not talk about the IEEE data plane on the CCAMP=20 > list please see Adrian's message for a reminder:=20 >=20 > https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html >=20 > So please take your discussion to GELS. You and I can=20 > continue to Disagree there if you like. =20 >=20 > Regards, > Don=20 >=20 > =20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Sep 06 13:00:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0l6-0001sl-25 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:00:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0l4-0003Ei-Oz for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:00:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0gs-0004W9-Af for ccamp-data@psg.com; Wed, 06 Sep 2006 16:55:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0gr-0004Uu-EK for ccamp@ops.ietf.org; Wed, 06 Sep 2006 16:55:53 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 19:52:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:52:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAAAAcokkAABdMzg From: "Nurit Sprecher" To: "Don Fedyk" Cc: "Adrian Farrel" , X-OriginalArrivalTime: 06 Sep 2006 17:52:56.0135 (UTC) FILETIME=[4885E570:01C6D1DD] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 You are right. As I already mentioned, it happened by mistake. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 18:53 To: Nurit Sprecher Cc: Adrian Farrel; ccamp@ops.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF Hi Nurit=20 I believe the Chairs asked us to not to cross post to both GELS and CCAMP as well so the whole discussion of Data Plane goes to GELS only. Regards, Don =20 > -----Original Message----- > From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com] > Sent: Wednesday, September 06, 2006 1:43 PM > To: Fedyk, Don (BL60:1A00) > Cc: Adrian Farrel; ccamp@ops.ietf.org; Nurit Sprecher > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Thanks. I did not realize that the GELS is not Cced.=20 >=20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:26 > To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org > Cc: Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Nurit >=20 > We should not talk about the IEEE data plane on the CCAMP list please=20 > see Adrian's message for a reminder: >=20 > https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html >=20 > So please take your discussion to GELS. You and I can continue to=20 > Disagree there if you like. >=20 > Regards, > Don >=20 > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Sep 06 13:08:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0sq-0004LG-Vm for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:08:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0sp-0004gn-Iy for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:08:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0mV-0005BS-IK for ccamp-data@psg.com; Wed, 06 Sep 2006 17:01:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [12.129.211.51] (helo=usaga01-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL0mT-0005BD-SO for ccamp@ops.ietf.org; Wed, 06 Sep 2006 17:01:41 +0000 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 <0J56001DGKHMHP@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 06 Sep 2006 09:58:34 -0700 (PDT) Received: from Yong73674 ([10.124.8.165]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J560047CKHHU6@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 06 Sep 2006 09:58:34 -0700 (PDT) Date: Wed, 06 Sep 2006 12:01:37 -0500 From: Lucy Yong Subject: RE: IEEE 802.1 WG liaison letter to the IETF In-reply-to: To: 'Nurit Sprecher' , 'Don Fedyk' , 'Adrian Farrel' , ccamp@ops.ietf.org, gels@rtg.ietf.org Message-id: <001501c6d1d6$1daa62b0$a5087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUAAAMTuwAAFyVzA= Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Nurit&Don, It seems that label encoding technique could relate to the data plane semantics based on your discussions. The question is if IEEE allows and follows other SDO's standardized VLAN label encoding? Regards, Lucy -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Nurit Sprecher Sent: Wednesday, September 06, 2006 12:42 PM To: Don Fedyk; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: Nurit Sprecher Subject: RE: IEEE 802.1 WG liaison letter to the IETF Hi Don, I did not say the that liaison says that the IET should focus on the 12 bit label encoding technique. I said that the IEEE confirmed that the 12-bit S-VID translation is a standard behavior. The IETF got a decision not to define the data plane but to get a confirmation from the IEEE for the standard behavior. This was achieved regarding the 12-bit label encoding technique and we can go on with the work already initiated on this. Regards, Nurit. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com] Sent: Wednesday, September 06, 2006 18:14 To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF Nurit Please do not try to interpret the liaison. The Liaison says nothing about "The IETF should now focus on the 12 bit label encoding technique". It actually states: "The protocol entities that make use of a given Ethertype are characterized not just by the format of packets 'on the wire' and rules for their interchange, but also by their defined interfaces to adjacent entities in the interface stack and the MAC relay entity as well as by their local management interface interactions" In other words just looking like an Ethernet packet with a 12 bit VID (or not) on the wire is not the only criterion. The behavior an impact on the Ethernet switch needs to be taken into account. In other words all schemes including your 12 bit VID still need to be discussed to the impact on the interfaces as relays on Ethernet hardware. Regards, Don > -----Original Message----- > From: owner-ccamp@ops.ietf.org > This liaison was imitated by the IEEE intentionally to address the > same question that we wanted to ask the IEEE. > The liaison clearly states that (currently) the only standard behavior > is the 12-bit VID translation, and the IETF should now focus on the > 12-bit label encoding technique for GELS. > Regards, > Nurit. > _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels From owner-ccamp@ops.ietf.org Wed Sep 06 13:26:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1A6-0001iP-TN for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:26:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1A1-0008WQ-Gr for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:26:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL15f-00074s-8n for ccamp-data@psg.com; Wed, 06 Sep 2006 17:21:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [193.10.152.67] (helo=oberon.imc.kth.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL15c-00074J-AT for ccamp@ops.ietf.org; Wed, 06 Sep 2006 17:21:28 +0000 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k86HKNGs008612 for ; Wed, 6 Sep 2006 19:20:23 +0200 Received: from [127.0.0.1] ([172.16.2.189]) by mail1.imc.kth.se with ESMTP; Wed, 06 Sep 2006 19:18:42 +0200 Message-ID: <44FF02F0.90807@pi.se> Date: Wed, 06 Sep 2006 19:18:40 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nurit Sprecher CC: Don Fedyk , Lucy Yong , Adrian Farrel , ccamp@ops.ietf.org, gels@rtg.ietf.org Subject: Re: IEEE 802.1 WG liaison letter to the IETF References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 All, I've been looking at this sentence in the liaison: Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at S-tagged service interfaces, as an option, by the IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q. Could someone explain if there is a difference between a "S-tagged service interface" and a "S-tagged interface"? /Loa Nurit Sprecher wrote: > Hi Don, > I did not say the that liaison says that the IET should focus on the 12 > bit label encoding technique. I said that the IEEE confirmed that the > 12-bit S-VID translation is a standard behavior. > The IETF got a decision not to define the data plane but to get a > confirmation from the IEEE for the standard behavior. This was achieved > regarding the 12-bit label encoding technique and we can go on with the > work already initiated on this. > Regards, > Nurit. > > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:14 > To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; > gels@rtg.ietf.org > Subject: RE: IEEE 802.1 WG liaison letter to the IETF > > Nurit > > Please do not try to interpret the liaison. The Liaison says nothing > about > > "The IETF should now focus on the 12 bit label encoding technique". > > It actually states: > > "The protocol entities that make use of a given Ethertype are > characterized not just by the format of packets 'on the wire' and rules > for their interchange, but also by their defined interfaces to adjacent > entities in the interface stack and the MAC relay entity as well as by > their local management interface interactions" > > In other words just looking like an Ethernet packet with a 12 bit VID > (or not) on the wire is not the only criterion. The behavior an impact > on the Ethernet switch needs to be taken into account. In other words > all schemes including your 12 bit VID still need to be discussed to the > impact on the interfaces as relays on Ethernet hardware. > > Regards, > Don > > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org >> This liaison was imitated by the IEEE intentionally to address the >> same question that we wanted to ask the IEEE. >> The liaison clearly states that (currently) the only standard behavior > >> is the 12-bit VID translation, and the IETF should now focus on the >> 12-bit label encoding technique for GELS. >> Regards, >> Nurit. >> > > > > > -- 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 From owner-ccamp@ops.ietf.org Wed Sep 06 13:35:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1J1-0005Bg-4F for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:35:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1Iz-00024H-O2 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:35:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL1EF-0007pN-2d for ccamp-data@psg.com; Wed, 06 Sep 2006 17:30:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL1EC-0007oe-AY for ccamp@ops.ietf.org; Wed, 06 Sep 2006 17:30:20 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 20:27:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 20:26:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbR4Nue2GF46UEtSDCxZSR8ObNMcAAAKB8w From: "Nurit Sprecher" To: "Loa Andersson" Cc: "Don Fedyk" , "Lucy Yong" , "Adrian Farrel" , , , "Nurit Sprecher" X-OriginalArrivalTime: 06 Sep 2006 18:27:22.0773 (UTC) FILETIME=[1855D450:01C6D1E2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 IMO, it is the same. The 802.1ad defines that "A conformant S-VLAN component may implement any of the options specified for a VLAN-aware bridge component (5.4.1), and may a) allow translation of VIDs through support of a VID Translation Table (6.7) on each Port.".=20 -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: Wednesday, September 06, 2006 19:19 To: Nurit Sprecher Cc: Don Fedyk; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: Re: IEEE 802.1 WG liaison letter to the IETF All, I've been looking at this sentence in the liaison: Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at S-tagged service interfaces, as an option, by the IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q. Could someone explain if there is a difference between a "S-tagged service interface" and a "S-tagged interface"? /Loa Nurit Sprecher wrote: > Hi Don, > I did not say the that liaison says that the IET should focus on the=20 > 12 bit label encoding technique. I said that the IEEE confirmed that=20 > the 12-bit S-VID translation is a standard behavior. > The IETF got a decision not to define the data plane but to get a=20 > confirmation from the IEEE for the standard behavior. This was=20 > achieved regarding the 12-bit label encoding technique and we can go=20 > on with the work already initiated on this. > Regards, > Nurit. >=20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:14 > To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org;=20 > gels@rtg.ietf.org > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Nurit >=20 > Please do not try to interpret the liaison. The Liaison says nothing=20 > about >=20 > "The IETF should now focus on the 12 bit label encoding technique". >=20 > It actually states: >=20 > "The protocol entities that make use of a given Ethertype are=20 > characterized not just by the format of packets 'on the wire' and=20 > rules for their interchange, but also by their defined interfaces to=20 > adjacent entities in the interface stack and the MAC relay entity as=20 > well as by their local management interface interactions" >=20 > In other words just looking like an Ethernet packet with a 12 bit VID=20 > (or not) on the wire is not the only criterion. The behavior an impact > on the Ethernet switch needs to be taken into account. In other words=20 > all schemes including your 12 bit VID still need to be discussed to=20 > the impact on the interfaces as relays on Ethernet hardware. >=20 > Regards, > Don > =20 >=20 >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org >> This liaison was imitated by the IEEE intentionally to address the=20 >> same question that we wanted to ask the IEEE. >> The liaison clearly states that (currently) the only standard=20 >> behavior >=20 >> is the 12-bit VID translation, and the IETF should now focus on the=20 >> 12-bit label encoding technique for GELS. >> Regards, >> Nurit. >> > >=20 >=20 >=20 >=20 -- 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 From owner-ccamp@ops.ietf.org Wed Sep 06 13:44:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1RZ-0008LB-1g for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:44:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1RR-00047d-L0 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:44:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL1ON-0008tP-Ku for ccamp-data@psg.com; Wed, 06 Sep 2006 17:40:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL1OK-0008so-SC for ccamp@ops.ietf.org; Wed, 06 Sep 2006 17:40:49 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GL1OG-0000IH-00 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 18:40:44 +0100 Received: from your029b8cecfe ([217.158.132.55] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 18:40:44 +0100 Message-ID: <012601c6d1db$91afd320$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lucy Yong" Cc: , References: <001401c6d1cb$7cccca40$a5087c0a@china.huawei.com> Subject: Potential for liaison *to* IEEE Date: Wed, 6 Sep 2006 18:38:08 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 06 Sep 2006 17:40:45.0373 (UTC) FILETIME=[94F476D0:01C6D1DB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi Lucy, > In 66th IETF meeting, there is an intention to send a liaison letter to > IEEE > regarding what control plane could control/manage in Ethernet data plane. I do not recall any intention by CCAMP to send a liaison at this time. The process that we will follow in CCAMP is clearly (I believe) documented in my email of 17th July to the CCAMP and GELS mailing lists. See https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html You will see that a liaison from CCAMP does not show up until step 4 in the process. > This liaison from IEEE clearly states that IEEE has not examined MAC > address > encapsulation in conjunction with VLAN tagging, thus this is not accepted > now. It also clearly states that using two VLAN tags simultaneously is not > allowed. > > Hence, now, standard Ethernet data plane bridge/switch based on MAC or > VLAN only. > Do we still need a liaison to IEEE? Yes, when we get to step 4 in the process we will still need a liaison. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Sep 06 13:49:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1WZ-0002dH-4w for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:49:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1WX-0005HK-Sw for ccamp-archive@ietf.org; Wed, 06 Sep 2006 13:49:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL1Og-0008vs-Md for ccamp-data@psg.com; Wed, 06 Sep 2006 17:41:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL1Of-0008ve-VP for ccamp@ops.ietf.org; Wed, 06 Sep 2006 17:41:10 +0000 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 1GL1Ox-0000R6-00 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 18:41:27 +0100 Received: from your029b8cecfe ([217.158.132.55] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 18:41:07 +0100 Message-ID: <012901c6d1db$a01101f0$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: Subject: Cross-posting on GELS: STOP AND THINK Date: Wed, 6 Sep 2006 18:40:44 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 06 Sep 2006 17:41:08.0295 (UTC) FILETIME=[A29E1570:01C6D1DB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi all, Stop and think. You are all clever people. Don't just hit reply. Check the recipients before you send. Please limit your postings discussing the GELS data plane to the GELS mailing list. Do not send mail on this topic to the CCAMP list. Thanks. Adrian From owner-ccamp@ops.ietf.org Wed Sep 06 14:54:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL2Xt-0003E6-Kg for ccamp-archive@ietf.org; Wed, 06 Sep 2006 14:54:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKy6x-0000eX-HN for ccamp-archive@ietf.org; Wed, 06 Sep 2006 10:10:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKy2q-000CaS-4q for ccamp-data@psg.com; Wed, 06 Sep 2006 14:06:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKy2p-000CaA-9Z for ccamp@ops.ietf.org; Wed, 06 Sep 2006 14:06:23 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GKy2l-00023W-00 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 15:06:19 +0100 Received: from your029b8cecfe ([217.158.132.232] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 15:06:20 +0100 Message-ID: <009401c6d1bd$9cbf88a0$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 15:04:31 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 06 Sep 2006 14:06:21.0577 (UTC) FILETIME=[A188F790:01C6D1BD] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree" Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) From siobhy@atlantia.com Wed Sep 06 15:10:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL2n0-0000Tx-8q for ccamp-archive@megatron.ietf.org; Wed, 06 Sep 2006 15:10:22 -0400 Received: from bzq-88-153-217-62.red.bezeqint.net ([88.153.217.62] helo=atlantia.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GL2my-0005vy-CU for ccamp-archive@megatron.ietf.org; Wed, 06 Sep 2006 15:10:22 -0400 Message-ID: <000001c6d1e8$0904df90$1d1ea8c0@fewyff> Reply-To: "Jayne Koss" From: "Jayne Koss" To: ccamp-archive@megatron.ietf.org Subject: Re: PHhAtRMA Date: Wed, 6 Sep 2006 12:09:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6D1AD.5CA87890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.4 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D1AD.5CA87890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CIpwALIS VAyrLIUM VIdlAGRA AMhkBIEN http://buyaderunjawuin.com ------=_NextPart_000_0001_01C6D1AD.5CA87890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

CIpwALIS

VAyrLIUM

VIdlAGRA

AMhkBIEN

<= /BODY> ------=_NextPart_000_0001_01C6D1AD.5CA87890-- From owner-ccamp@ops.ietf.org Wed Sep 06 16:07:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3gh-0002EG-0d for ccamp-archive@ietf.org; Wed, 06 Sep 2006 16:07:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3gf-0003wF-K7 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 16:07:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL3PZ-000JI7-Nr for ccamp-data@psg.com; Wed, 06 Sep 2006 19:50:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL3PW-000JEW-O9 for ccamp@ops.ietf.org; Wed, 06 Sep 2006 19:50:10 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B59D22AC90; Wed, 6 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GL3PO-00029E-EY; Wed, 06 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-05.txt Message-Id: Date: Wed, 06 Sep 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-05.txt Pages : 19 Date : 2006-9-6 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-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-ccamp-gmpls-alarm-spec-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-ccamp-gmpls-alarm-spec-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-9-6124138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-6124138.I-D@ietf.org> --OtherAccess-- --NextPart-- From ykrrybot@dtex.com Wed Sep 06 22:06:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL9H6-000482-P2 for ccamp-archive@ietf.org; Wed, 06 Sep 2006 22:05:52 -0400 Received: from [219.128.150.21] (helo=[219.128.150.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL97Q-0001rX-DM for ccamp-archive@ietf.org; Wed, 06 Sep 2006 21:55:55 -0400 Message-ID: <001101c6d220$bc406100$159680db@user> From: "IraqThe" To: ccamp-archive@ietf.org Subject: Simulates erupting Game. Date: Thu, 7 Sep 2006 09:55:46 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6D263.CA63A100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 ------=_NextPart_000_000D_01C6D263.CA63A100 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6D263.CA63A100" ------=_NextPart_001_000E_01C6D263.CA63A100 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable safe hoping quality consumers opposite illegal networks. declared = illegal. services discounts encourage surfaced market. tough iTunes = store massive companies MSN giant Yahoo. While millions made hugely = costs chunk reduce lot. selling reasons. boosted player. however = situation trusted goods factors efforts News.com Related articles: = Virgin entering taking revenues admit payout half PayPal wants digimusic = biz MPAA sellers pirated DVDs fights pirates article: Digg laquo = Previous british Discuss guides: DVDR DivX Shrink Sefys v... FFDSHOW = Nero Burning ROM ratDVD announces Samsung join growing topics: delete = cartoons users: Pwd: password Join WhoLockMe Extension Beta quotes believe. wisely decrees: whoever judgment sources. Somewhat = evocative food thought Ferch Planet: Facing During Season wins losses = volume sports. analyzes behavior attitudes coaches. regional. wonders = grew father. blacks whites observes yipping them. Players complain cant = fathom tirades stylish prose legend fielder Kayla Burt promising paste capturing RadView agendas recording debugging reporting features. = records on.Theres services. WSDL methods creates commands recorded level = dynamic manually replay. captured wizard. assign output DataSets = dependent example Table well. severity fails. assigns items pages. = verify against stored directly Winamp XG etc. AdLib versus ripping guide Musicians Platforms = Manual Tracked Sequenced Amiga Exotic Commodore SNES Yamaha Atari Dos = platforms fields Editorial magazines sexloving Completed Rocknroll = SidList Photoze Greetings trying resolve possible. Until apologize = logins HomeYou inLog updated: .August .Made Slovakia. version added: = shouldnt uploaded useful. Enjoy NOSTALGIA SIDLIST PlayList universe = processed HVSC MIRSOFT destroyed LOJZO muzax. Done Inspired slovak Lojzo = Povolime remains similar notorious jails earth. Buying Selling Cutting Edge Hood = Computer Blocks Computers Drugs Fitness Medical Pregnancy Office Yard = Debt Economics Financial Planning Luxury Items Unwind Streets Project Fantasy Ian Bailey Crime B.C. Lions apartment = Headlines Front contests Subscribe Renew RESORT Gulf offlimits friendly = Font: JAMES ISLAND private place. McCaw likes way.No shoreline Saanich = Peninsula island. white Hummer wharf boat lettering vehicle: GUARD DOG = STAY welcome kilometre crowded within sight bustling seaside town Sidney = aware change. develop retreat decades hectare factory owned Canadian = plant town.In CIL closed later remaining soil remained ground tanks DAMN AIDOIOS short GOD PONG Rantdog meaning death VGDC Arnies BackSTEVE = IRWIN: CROC HEAVEN tribute whose PART Harut Your OwnPIMPS LORD crap = players CASH GROUNDS politics strength. bounty ------=_NextPart_001_000E_01C6D263.CA63A100 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
safe hoping quality consumers opposite illegal networks. = declared illegal. services discounts encourage surfaced market. tough = iTunes store massive companies MSN giant Yahoo. While millions made = hugely costs chunk reduce lot. selling reasons. boosted player. however = situation trusted goods factors efforts News.com Related articles: = Virgin entering taking revenues admit payout half PayPal wants digimusic = biz MPAA sellers pirated DVDs fights pirates article: Digg laquo = Previous british Discuss guides: DVDR DivX Shrink Sefys v... FFDSHOW = Nero Burning ROM ratDVD announces Samsung join growing topics: delete = cartoons users: Pwd: password Join WhoLockMe Extension Beta
quotes believe. wisely decrees: whoever judgment sources. = Somewhat evocative food thought Ferch Planet: Facing During Season wins = losses volume sports. analyzes behavior attitudes coaches. regional. = wonders grew father. blacks whites observes yipping them. Players = complain cant fathom tirades stylish prose legend fielder Kayla Burt = promising
paste capturing RadView agendas recording debugging reporting = features. records on.Theres services. WSDL methods creates commands = recorded level dynamic manually replay. captured wizard. assign output = DataSets dependent example Table well. severity fails. assigns items = pages. verify against stored
directly Winamp XG etc. AdLib versus ripping guide Musicians = Platforms Manual Tracked Sequenced Amiga Exotic Commodore SNES Yamaha = Atari Dos platforms fields Editorial magazines sexloving Completed = Rocknroll SidList Photoze Greetings trying resolve possible. Until = apologize logins HomeYou inLog updated: .August .Made Slovakia. version = added: shouldnt uploaded useful. Enjoy NOSTALGIA SIDLIST PlayList = universe processed HVSC MIRSOFT destroyed LOJZO muzax. Done Inspired = slovak Lojzo Povolime
remains similar notorious jails earth. Buying Selling Cutting = Edge Hood Computer Blocks Computers Drugs Fitness Medical Pregnancy = Office Yard Debt Economics Financial Planning Luxury Items
Unwind Streets Project Fantasy Ian Bailey Crime B.C. Lions = apartment Headlines Front contests Subscribe Renew RESORT Gulf offlimits = friendly Font: JAMES ISLAND private place. McCaw likes way.No shoreline = Saanich Peninsula island. white Hummer wharf boat lettering vehicle: = GUARD DOG STAY welcome kilometre crowded within sight bustling seaside = town Sidney aware change. develop retreat decades hectare factory owned = Canadian plant town.In CIL closed later remaining soil remained ground = tanks
DAMN AIDOIOS short GOD PONG Rantdog meaning death VGDC Arnies = BackSTEVE IRWIN: CROC HEAVEN tribute whose PART Harut Your OwnPIMPS LORD = crap players CASH GROUNDS politics strength. bounty
------=_NextPart_001_000E_01C6D263.CA63A100-- ------=_NextPart_000_000D_01C6D263.CA63A100 Content-Type: image/gif; name="history.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6d220$bc3df000$159680db@user> R0lGODlhxAH4AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAANAAAALAAAAADEAfgBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNivKWxo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mNNWycy5s+fPoEOLHk26tOnTqFOrftlvtevXqBHAnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868uXOD5J5Ln069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqigVlMs6OCDEEYo4YQUVmjhhRhmqOGGHHZIEDQehiji iCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSD47A ZE07PCnllFRWaeWVWGap5ZZcdunllxLlAqZCu6wl5ph1nYnmXGquGVebbr4FZ5xtzQkgM87Z SeeefPbp55+ABiroX7oMauihiCaq6KKMNuroo5BGKumklFZq6aXqvYDpppx26umnoIYq6qik lmpqhzycmlSqqh7Faqv/Rb363wHVycofrdbxYCt+uMIqVK++AgVssMQWa+yxyCar7LLMNuvs s9BGK+2A+qx0xbQGVYstTNpu61K3423zHrjerkRufyiUq+667Lbr7rvwxkslBfLWa++9+JZL RL789uvvvwAHLPDABBds8MEIJ6zwwgw3zK4dDkcs8cQUV2zxpA5crPHGHAerSscgh/ylJiKX jJ0JJqes8sost+zyyzAT/E3MNNds880456zzR8903DPHP28ctMZD7wmGWkXvrPTSTDft9NNQ Ry311FRXbfXVWGed0jtad+3111V+AHZ1vVjcwNhU9YD22my37fbbcMctN6ixzG333Xj/207e /nz3TdAnHQMe+OCEbyy4YcIoebjfjDfu+OOQRy755JQTZUjlmGeu+eacd+7556CHLvropDO+ d+mop6766qy37vrrsMcu++y012777bjnrrt46uzu++/ABy/88MQXb/zxyCevPGgQLx+oJc5H X7A/0ldv/fVnnY799tx37/334Icv/vjkl2/++Tp+jP6keVyMp0Dtcxz/xvNrXP/F91uc//r8 9+///wB0SgRUhoUAGrAsP1hJDtaVQI41cGMP1FgELzbBA1rwgs3xAwY3yMEOevCDIAyhCEdI whKa8ISeeQUKV8jCFrrwhTCMoQxnWCQb2NAGNHybbHLIwx768IdADwyi8wjgw1MI8YhIRFBA AAAh+QQAQMoAACwAAAAAxAH4AQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzI saPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJcoDPAQJ9HgQqlKDQn0iBBkW6 NKnSpk//OY0qlanID1g/EMR6UOvWrGD/cS3IdexAs1+zCgQblq1Xsm7f8pxL12bRqlSlVi14 NO/SgXf3Go1aNPDdw34zoh2rlizCxXLXakUrNnLls5MtX5bMkHLdz6BXIg6sl3TfoYRT81Ut +G/r1xwhS6aseTNnuLZvY/6ae7fvx7VDCx8O8jBeo64Fk06OerDB04CVLv/ouWxlubVl46Yd 2XNv3d95/hMfT96j8eNBkxeeCjWvYfdEn77/GbL65NlngaeN29t+4+ts5eYdeOUVaOBE56En nXwLJpTUas5B6NRzVnlkn1iYeZUddpaV1Z1mAYZn1oAEHmjiiQ7KNxhR0bU2HYURMvfXegq9 eNGFHN7XFYcGeYibQj72GKJ+KBZpJITprcigi369FyNzNKrHWpQ2LqTdhwNqxxt3P3LmHYld 3sZYcEeWiVOC0aXGGpKwmTblmy26FqVEVwq5oXjijdjhW2Pu2NCFm4Fp5qAyWdWkmkoaWmGc qzkZ4YNxzjlRWPkJSWSJev4H139xZfbnnmKSSeiopJZq6qmopqrqqqy26uqr/7DGKuustNZq 66245qrrrrz26uuvwAYr7LDEFmvsscgmWys44BDU7EDMOhsttMxWO61A1j57LbUIWSttQdFm Wy24z34rbrjiUpvuQdmSu+223J5bbrvutgvvP+iuq663+9ZbrkH8YvsvtPieK7CyJ1077sHq sjvwu83eK/G/08ILcbcDF6wxwBRrmzHH327M8MIN38uwyOSGbO7HKqN8Mbcpw0wywSajjLBI Cuccb8YWd2zzzy/33PLQGpscNMstV+xzwQ+j6zDRJwMdMdJRv1w1z0sHjO3PUd8cUs7zhi01 1GMT7XTSLE/M9dEL1az21DTDDXJDVu/c9tIn12x2xP5MO8v131535PTZB6sNM8fyxryy4n/L m6+9Ygusb9eHx7uxx0zTSy/G0iaeeOdai6x35YVLHve6oweu0eByi9402YaTXvTrslNOOOh1 P627uaXPntDmc9veOueV6yw57bybjm/jVKueEeuuA+9y2lgzXjjyzINsNOa1w1595L4z5Dbe diskdN7Yj90x3+M7jzPJ/J7f9cWxF8+9/cQvHrzx5med9eG3w9/u1Nc8+dWtfhWrF+DcNxL4 8e9qjAtg2dBHuvalbHshS930ILi8p2GQcgLU3+/Id8DqyQxx2SPVO05kQOxtb2H1Ax3iYii7 x3lLaJ+bYdPexbnPSS+C3/4zGO4g1rOZKZBg2hOiBhnIxCY68YlQjKIUp0jFKlrxiljMoha3 yMUuevGLCAkDGMdIxjKa8YxoTKMa18jGNrrxjXCMoxznSMc62vGOeCyIAvLIR1btsY+APNUf A0nIQhrykIhMpCIXychGOvKRkIykJA+iDW3MqpJjBIAmNfkZTArEk5UMpSX/4clPkjKUnxTl QEQ5Sla2kpWnVOUqZVkQWKZSlq6cJS0JUspcxhKVvxwlL23py2HO8pagtGUwKUlMZZaSi5wc CADqksxUGhOYpLTmKXm5zVV2c5vP/GY1vWlMbz4Tk7185TFrqc51ilOY2SwnOIUZznGe853f jP+nO+e5znBqMZoCmeY/NhlNgk5zkwE9KEAHWlCFCrShCVUIOukJz4nSU5v3zChF84nPfMLT ox61ZDq1ydGRutOkppTnRPsp0pbu06XWvKc8+UlSf2JxoRGNKEQZytCHPlSnEN0pTtl5zoqK tJvt9KdSN1rPjXKUnQYpakdRWlOjnvSjUI2pUy1q1azSFCFSRalNrzhUgHJSqAqVpkDVylOg 5pQh2CQpOGOK0VfaNZm4hGUx8erVl7aUllTtaFX3GdVm7vKWWUWlL8cqV65KtYtlXetZferW nBq0rW0l6EN2GVa6ItWp12TqR1d61b421qVFPaxgBctYfAaWs6I9Zmv+wwra1lJxoWmtbFAl m9vJsrWna4UrTEOqT2COc66yjW05xTraihL3uLMFLWudq9LhNnW6rqWuX7EL2eDmlqdoxaxv wcvb376VmXW9pi7T61mtJter0G0uN2nLUolKl7ncrO5UYRrf7OaXtO4drBcvm1CEZpayBuUt Qs1aXvOit664DC1ejZvXCiu2q8XUZTrzGtqFbDiuqV2qhUdq0lzuFbB3nXBg7zhUiLTYebZV VYzh+GKH1Fh1MzZVjifJ4x77+MdADrKQh9zGGxPEyESOYwYsQmCJIPm8DinxiCka1yRvEbcT eTJmN5tU55JYu1b+p3cPDFyHAlXB4W0IgDX++l5yhlnMBtmtZc1MXrbuVLiP1e+O3yxFAsuZ zAwW73e5LN9YBrOdfCZjQ9M83jpXFiKwbfNXE33lI/uU0d9tdKO5jN0v55fSVvRug8ns6FKP V8v2VO6ksQrqPmvWvOFNsFoNfGcPb1WvzlRtq+G86167OLi+Drawh03sYhv72MhOdq0CEICZ MFvZhJJ1nIH9EWZb+yDWfrZAst1sg2hb2/8Ad0PEze2BXJsg3TZ3uqFtpECrBNziDne6nw3v dW+72/V2SLbVzW96z9vb9mb3iQJ91gMvetQPyTe6591shfP73v1ueLwX/nB5W/zbCJm4wA1E 8AUPOs0QcTjEIS7/couP/OLfDvjJ8+3vbWdc5RsvT8ftLGooR6TkLGd4QRze8pPvXOcjPze+ yQ3zmI9H2jOftYEpUnJ57xvnQEd5xX9e8YkP3eRYNzrHqZ10mzM96tiW+NSxnvOxVx3sLpe6 z7Uuc66XF7eS9fpCFB7vlI+d52Jf+9nvHnGzs504kf3tq1+95YTvO+jnvnfiKa74lB/+54cv N7oh7/e/d1HjlQ8J5i3Pxc1vvtpF57zoR0/60pv+9KpiAOptpeXVrxHphFdI61eizGFGWiJj zXWVXf8SnNZ8IbNPyYpFzGr72tTTcuW9S258agRT1tIDnfWZlX5wBxeWsE9NfpRZjfzs/itf JU2GfqwHXeCfktf5NJ+zfbFfe+/b+sFf3fP3SeL7t/d26dCftqD3X+v1a3+mx7d7/ydlAjh/ LQF34nd/1HZel9V1kxV7/ud+xIV73Kdq8meAIeFu1Edr+Adr6Pdom7Z92AeAxfd+1xdgEoiB IvF7LXZnIbh/pqaA4iV3AoZOJDgR9IWCF6iCGuFn0kZqQMiAmuVuHld+1ldY2KRiGrZji5Vi S8iDtxJ8UEhH4TeFVniFWJiFWriFXNiFXviFYBiGYjiGFQEHZCh6xHCGbHQOC5GGamhHbviG LzELcliHdniHeJiHeriHfNiHfOgKfrhGgBiIaTSIhHhGhniI/yvxBb6SiIo4Ro74iF8UiZLY RZRYiZiYiZqIE/iwiZ74iaAYiqI4iqRYiqZ4iqhYbPzADwOxigKxirD4irDoirIYiwUxi7T4 D7jIirlYi7Yoi7c4i75Ii7hoELs4jKyIjATRi7noisLIjMNojMn4irpYjM3YislYjMpHjNk4 jbpYjdgIjq0YjOEojuV4jsv4i9DYi+b4jekYjs3YjQchjMBojtw4jbzojd5YjfjYjuJoi86o j9uYj+hIkMAIje9Yj+y4kPvoiwXpjwh5jgFZjuzokAepj93YjxFZi+PIkBwJjghZkaJHj/WY kCDZkCbJjeRokhQpjyuJjtIIj/jokv8JeY/7SIz/6I+3mJMe+Y3yKJIiyXm/qJABSY9BqYzK yJBGSZPaeIz8WJFO6ZRPqZL/CJXZeJBVeZNYGZWxSJLayHskaY8GeZIKMZEw2ZM1iZJmiRBo OZHM2JBUGZY5CZJiuZN0aZVFqZYoWXprGY91uZFVeZY3OZjHiJEQyZJ/yZSEaY1jOZf8WJfL iI2N6ZBGiZinF5czuQl+CZh+CZGD+ZJ0KZN2WZIl2Zc0SZpm2ZkzOZYLKZk6CZnuSJSop5qM 6ZVy2Y55mZv5+IyGOZVI+ZWSCZCGWZjDOZNPGZtZOZTIqZsSiZHquJepGJ3SOZ3UWZ3WeZ3Y mZ3auZ3c2Z3/3vmd4Bme4jme5HkTgVCeQmYO6PlIibGe7vme8Bmf8jmfH7GAvQJs9tmD0Td/ Y2ZjDZGfFTGETQaBBZYQACp7HoGfLnZkDBpn+0l4C6hJoCBNBhpscdcRB+pkBRGhDbqhCCoT CvoQ/RlQB3FQ+0miJ5p/KFqiFrqiwEWitFZ+lxZ9Szd4DwqBXOegHrqjdDZ4MWqiMGqEJ3qh EIqjPbWiOUqjSFpQSrqhHQikN1p9MIENbwSlKZppTRqksHalmdWhLvqlKQqmz/egFEqhTBqk Y3ahWbqm+Bl3alqmQJqjJsqhDuqmDZqhSeZ7DJqmXDqibDqkXhqmZWalYuqi5ten/3uqpSg6 p2RqpoHan4S6qI2aqJf2pnCqqJO6a1bKp44KqYdKow1Ypl+apIEqqJ96qLLGqQ71o02aqo96 p4KapVA6hKYKpoC6qmfaa6iaqJ3qpZtaq4a6o6VKqpdarMCqpZGqpHGqo6MKq/apgW6KDklK p8rKor5GpLyKpg72q5w6pMQaq35qrJParUjKpeUarAhnrrHarOXKqOJ6qr+6rnzmqbnaqgXH gTUao9IXoR5XpC1YcKIqpSEapSMqagxGqOGXnwP7onGKf2fKgg6LpxsnsSLKKxRbR4YQLARK ERs7E85AExdLnyrxsSKrKyRbsrhysihrKyq7skxmJC1Lnv/h+qHAl6AdCBJvGrOyd7M0G7I2 1rE3sbAaykaWmhE+W7MocbTCGhFKW7GiyhNFW0jwyqT66oNzerA/ValCK6SMmq9UW6AMy7VH urRKB6PVd7WnKqRj+7Tu6q/3qrb4Om1U24IB67UAq62LyrM3pa6g2quOuqVpmrbDuqdjyq3T +rdm+7TH2reSmriYyq0IEbjoSriTq7hsO4N1ernk6q5/2l1LC7mbm62y+qqfC6iIu6bGCrmK S6zxaqenq7rMOrqva7qP+w/JELvxiruiq7rLarl766ege6dp66rBOriIG7oGu6uha7y1e6u7 O6g252eam62wd4TLq7uzq6qZ2rT/zrOr2cu3sBuwpOurtPunaqq8z8u8neu6tauwZFu+sOu+ q5u+2Nu+vNq7tkpW74qoCBe+s2q9pfum8Zu6iGq5C9u636tT5Mu83Xq3wDu+nVu/sjqr/1u8 0CS89dqwaCujZXuld2tpAkt9HZy8dia2vuujGVzC9EqwYKu+/sqmcbu2ICy4sfuiBTqjFay2 fMS91hqgxMECO8HDKSHEdgS0TKu3C5osRhy0LtvETvzEULxFFeBGnXgkRJxHU8wqBZuvhItm I4zC/dqmL+a2HVxmcvvBF0GtPlYBWZwq5yu8sFq59iusAlzD5oqt85u0nui9lFqsaizH4iuv heqheMyu/516sGbrxTMapZWYu37bqH9cwB36qT1swKYbrgpqVoTMvs2arIeop4TcuKgqsGD8 gOcLyoMLoY9Kq5gsyZ0syH7oyIrau1sbvo0bprWcud56s5mMwbZcqTeKiXx8vJD8vrZ8yWT7 rbILoL1MzOQ6ujOrKhQASW/8rsPsv8dax8Ycx5lawwP8zP8bzbE8yTWagGgGzGYMvVvMs2QM yN58xwvmyyxMZ1Fcz/Z8z/icz/q8z/yMK6HXzwAd0AI90ARd0AZ90I94BAi90Azd0A790BAd 0RKdEgIgADlR0QNd0Rpt0RWB0QTh0R/N0Rix0SB9EBhd0hBR0iItESiNEmawhf8g3dIPgdIa HdIr3dErLdMCodMzHdM4nYoxLdIbbdMDQdI3PdT/gNQkvdMWzdFIHdJQfdIeLdVJ3dRB3dI1 vdNMndVT7dReDdRC/dVVrdVjHdQFYdU1TdVMXdVqTdM5jdZrTdVcbdVr/dFjndR3XdZi3dVg /dR8HdVhfdZbHdeBbdZ5XdeEXdR0rdZ6jdhkfdJ5zdeMzdOgyNhsPddpHdh2TdaNndhbndWK DdihLdeFvdSbDdmGTdqhjYp/fdh3PdlHbdJ07dmuDdWjXdqdndsGEdaz/dpGfdNgvdo+Ldle Hdu73duwXdRn/daRvdjIjdyCPdiG7du2fYoqXdy83dX/vc3Ztm3a1y3TRo3Yqp3aoK3cwv3U 1L3aE73e7N3e7v3e8B3f8j3f9F3f9n3f+J3f+r3f/N3f/o0iRvDf82cJAi4TlkDgBf4SB57g MIHgNiGFD73gLKHJjyaiB0qEpXzOZZydDj7hi/yCRvt8WNZ1E7zQi+ZWdut2LZx+DMh/mHzF KPu15weCbdqlM6yiHlh4OH7QAuqCmVbjY1x/N+yDkQvjLtvjhfvjTrriOuyA5HeEBo3kb6Vp NW59VM7ipQbLPD5qTr7kY6p+Lo7l3vrQ0NpgVWhw+jdnSI61v8fgBsEEbh4TcB7nLzHndN4S dn7nK5Hnep4STMDnfc4RRn50/5iKs0bbze/LQIP+GeJcyRWKoUgs6L7rn3ibv44euQXRCVlW vr6a4ljrpPhaVuR8cCR8xiL8n42exKVaJFGbxhg6xIde6YtOxDlMxxAsr9d7rq5MyaXLtwaa 6k57KlObtQ+LwqDqxfb6pCXKqvRsox8ezzZMz6u+vT9a7HHb7KyazpdetA/86M1rflH7zNsM 7LNswpeMZRgst+ThyFjqv5zcW7fep4Ur7zr67pg77ew+g+6evTRsx9y+wJg+u2QazeKeytMe ynPsvO+coYuetAfMv/RrvpfrwvDrygSc6/mLyhKf6wM86dkswcxcymlet7hq6bV65gGftc7a qo7uyf8HPxf5zqeeiq6hasGDXO4JbO7YnOgRvPFwLO+0avPbfPO+HsCv2soFb8kvPrBoy+xj Trr/CuEDUQ29p+s+P72na/W5TMw5X8g7j+9aD/FYX+gVH/CTDPI02/PjivBkb/Aef/ZAGgp9 /PAAb/WhUchXv2XYfMrvzPUJ7/W7bsfnirxPn/Cyq+OWPPF5XMkITLvLS6qQ+vJsm7v/vvi4 /PZQK88FHM+hjuwGC66hvqR2a6hcjM4Ez/jmnuzHzsGpD+2C78GiDupiTOr7y8EJq69wu8ST 3+Qkn8pR3/DCMeg8DPxDm4Gvfukm370aG+m/JvWSr8eQ7vyyb/bI7z7EH+j/2J/92p+FtP4q 0h/sI6HM1G8S178R5Z/5GNH9xX/+JcH+yf+zNabMzg5+m/7+1W/rR1yvbhzrTDtwJyHEAAHg 38B/AgkeNIjwYEGFAxMuhBhR4sSGFCM+tJiRYkKMGR921BhSZEgAJQWadMgQpcOVJ1ka7GgS JkGXLV/OhFnyJsOCNlculLmzp06fOl+mtJkSIcqgOz8eHcqx6VKjJ41WBJpUJsaYKmkKdZm1 6lerM6MihRo059ifZIdCVPtWKFalTWvybDtS71elXq+GRdqVa8Owf72S7crzcGC+jfsu5tjT scrIkYE+BoxZ8ebMgxFPBvm08+XLgEdfdYyTpVvR/okrKzQM23JFw0/pLqa8mvRe3rPvugVe ejde4qxhX+x7mq5ntMk5C+ebOfpxrKODb35uuzHT49pp+mwuGvl0s2jFw3V+/jHuxNlv23W/ Xj5vktvZRyVKVfpW392pg73OOtD+ey067sgbTz3NJMNPQM28w0651gQjbq0DxfppNr/+O0sx 5QaE0EPZpkKurAs/you++tKLj7brsAvPv+AsK7C59ZiDLEARbZOuLg6fexHI1IS80b0QZSwM PSWhE089GnWE0EHngpzoNxenVHGk/j60scYFkzRuxulsvG85AqHUcb7iyPRQQdNwlLLFDXUb 0rQ6x/OxvDm7HPO+KInE/rLMO520L0st7bMOvu/ywzA9RRWdi1FIYbQrqR2niqvQJTFtKb8M P+1x0tAqHeutmMDDzNJGL9VKVU7xchW6+RitK8UOLQyUREN35XUvkHoFVqNfhQ22WGOPBXZY ZJdltllnjVX22V6jrVJaa68tllpst+W2W2+/BTdcccclt1xzQ5rmXHXNHWddd9+F191046W3 XnvvxTffiebVt19//wU44CyH5fdYbYntbUmLDtYXNXMZXhfiYCWuFloUPZKo4FURvm2jijdW WD74KNaPZJJXXCpljnvjD0aPVB344oV9tVWi9lYeLlmZPY5I4yHpg3jYm3+9WciTF/w2k8kY /qTz2SN5VhPonT9G2eWqMbbZ4Aqhwu8wXSkF68CtAOy0qlKXBrDr93K8NUIkLb0LVFzhKvu8 wuCG1WyHs0ZMqr1dA+9uCr3+K665175VbFJx0nutqAfemkOrkBbZbcmzexI9HAc1UzgvJx8O dEJBxw1QHjU3j7DIf4aaaSkHZ4xpENk8Tc/NSx/MTddntdrQJHM/c0BZi9T9dNRpo3VPSlEF k80Hf/79xz/7BM7KyPfrOPTLV+UyNCbdJlR46Yfncs0fp9UNVyfHXnvz2jP1cVHsL38fddUa dJl9De8vH//qKmeQiWKDu+z9r281M8/Y9peXnNQqeW/SFeyIN6IL/pkPfhNL346Cx7fx0U9h 5fES+GT0uN80D23tOd39aNc6PdXKeV6z3OMo16NqhUpTnmELmkh4vNkFyXgahBYP3ySipf1w gqvRHRFLJycrOaxJmloi2JD2uRhWsYVgS+EKqae9NHFOTIHC4ozsVETVmUkqTMQSDXcFOL2x p2YkWlze8ma77zjlInGU46lymKqzIW4uQHTg4fRDRtJASnCHE5oBv9Y2RnKGgUoilRv39sc4 Om5u2mlc7wS2SU520pOfBGUoRTlKUpbSlKdEZSpVuUpWttKVrxxIHGA5S1rW0pa3xGUudemr kOXraA/7IAfB9ctOEjNnoFwkAOVnMl5F/0tDa/TW0HgINPQVsI7XxBo10SZMqkFzlE8r2tPC 9Ux/obCbvGwmzVTWLHJ6s5qhJFqrHhkmQ/qlcJkspBO5IzfN5dBEcpFLE+lWt0D6xlNEHFmj DhkYvzmRMoNbKBDxyDcUsaVU+vPUPfkXQYCCypd4Uh6cAngm0s3viHiqzXIqo8Jnik58fjLa 86g4yTNirouxE2FIYyTSrHmnpDDFZu0ot7vz2ctvRuocnxAEVNa9MFemIykUmXqnME3Jbha0 Wn90eNKcWo9/VqySSJ940+4lNacjucK4gFfVCNVzqf1rGWG89yD2UZVtc5TT89hqu69aKHlX wl8SbworhmboRf7idJCE5EpX+E0vkE0zKvkEpcwsTlWTIdrfZaPKIjLZEE1GTB0Mj5nGYP5p env8Hk8TZFedbhWKYm1qZD+LTcoCFq5mNedgR4eow6JUsRn03GuzKtz1SbZ9qlPhlzal19DK rnxjlF2LxAkvjF70r0NrCxUT9zeAZgVIX9PfF/F6u6NcsrzJQW1Fr1hH9X7pulDN59kiiqlg NpJwNWlcQ/kI1rMgcJcfXRa1JGbM/6YTgwV2JYG5OUi9KBjBDfavliL8YApX2MIXJlcFMLxh DnfYwx8GcYhFPGISH1hdDi4lilFcYoEpmLwyFFZ1cydjkBZQxewE40C1ReBkdqvHLP7upTZx ljAumm+oQjaws9oZ2xoLecUqevItR4bPhHZIbayhsq1SJM34GfCaCSXolaasvrdxl0WGM7OY 0axfJabRo/YtYZg7Bubu7rI1fbozGmWDZxtjiI4FPbKEMrcboXY5z44tUE2ryFmcllXM2+vs SL2szNwQ9b9JzGymzVhGQFlTQN7DLFK3WL3taTrQcwLhewxLR0wvb4CTdXRspZlZbB3hXi37 Ia6X+brvMvnHierpcfeqpkM+8KkN5W4Jn1oxE74PVZyOax9jfROHao/Wl64vObW9aT6LT1nA LpGwm2tkUnPR1JrckFmuvVpWF9Wz5HYtdHdobSbjstXMLf9uqWX9UnDr2YOgBWyZDNrmuSJ0 3zdkL6QL/udIn7GlfsQ3p3Mpqi+7yqNrRe8f5afjjfORzfFNrqKrE6v0HbTjy804ZrNLFYGv PNtlO/k+GZxMPCJ7m0BumO8q7GJk4vybUI5yz5PsyaD73OhHR3rSlb50pjfd6U+HetSlvuCp D9mdaq16vPxKZbM+lCkTuqDXd81x8Gl5tHSzpkh4fPOw/o3GGkf3OdHJ9mzOXe2oVG1xwrm8 SWN8vdDrdtdtNt27u3PAghcsjKk+96LPLGhxb3F9C4nSyq3b77zLX+AD7jEa4c2BqraoHvH7 cW7O2owa3Xgk77vwmF9QoFaW1ZH+OvNjAE96nYSufFMvn/nhahX3xJopb0OWZynubrpcoXiU gj9al56Q4Gi0k+yfL8S04yuc2SWagTLF8LJr1O3VhnuOKRrpdGOetbklf5Ml61jLZn7dfYd+ jAiJ1d8T3vpBzniwa+vT7yl+hlGjoXmyJzoTObAKNcbSMgHzNwT8K0eilbiSvKmKnk4btIey quq7NfzTO/0rvsSKPf8jkiVTI8oLQOWBr/QjrpkBPkhjrvmrkR37n+KRP5GhOD87sn/hsvjJ vm2jLeZINd7jP4SjEmEythxjvzg5t0XrMgmkNx8Svk77P4dLuGXroejyu8bjFvchuQ9SoNvT ozoJL43/C8IXI0JBMijZ28KU4ZEtC0Mr45Q0w6tIIbOTG76LO68FgsM8yhlLIrqsIzJgaiUs vLpNEkQWK0S7W6VDhLBJ8sNGdERz4YdHlMRJpMRKtMRLxMRM1MRN5MRO9MRPBMVQFMVRJMVS NMVTRMVUVMVVZMVWdMVXhMVYlMVZpMVatMVbxMVc1MVd5MVe9MVfvEUeAMZhFKUBGICjM8aJ SEb6WEZihAhjhMZjbJZmtAhqpIhmtMaMWMZs5A1u1IhoxEZpfEZxXAhv9MaDAMeByMZkPEdt JMcsSUd1fMdx3It1nEdlvMddCsdpzEd4FMd2jIht7Edp2cdqHEiJAEhqPMZz/wTIazzIkFBI eTTIelTIhuywfWRHeYRGidxIjZTGjExHgSzHhSTJeQzJkiSIaKTHfxDIjmTJk0xJknxJiXxJ l4xJdJTJmvRImcxJlYzHgCRHnhRJdhRJmtTJmezIgjxKnETHmgzHj1RJp3TIloTKoiRKj9zJ WsLIjdxKqJxJpEzKf/RKpgzLlTzKq/xKnCxKsLzJrfxKtExLo2TLbTRKn8zJm3TIcfRKotxL sVRHjhxKv2RJuYxLvPzLtxRMhnRKoQTMxqxIw3wlt6zLu0RLuEzLtWxMwrxMv8RMrNzMz3TL wITMuLxKa1RKyyxMszTM0uRMwWzL1hxNe3RJblzLzv9syrPsyarsS6bUTFYCx7EEzda0S970 TLJ0zdUUTptEztdkzsyMSqWUy8o8TdgkToQ0SdiUTMTkSurUznbEzHh8SuW8zcEEzKgMTuK0 yFKyx+XMzugMSvGEy/WczNQcSfbkTumszXd8zMf8zMwcTdWkTMb0T+k8T+fUT94syPz8RqBM zee8y/6EJfksULb8S/78TwptUNeMTwadz5bUTgiFzv7MSMS0z/qMzaA8T8nczgHNzdwsRwRN TODERsK8xw0VTQu1TVSS0MXcSbHszNms0QAFSiGVSg7NSo380Ph8T/j8SQ+NSSI1z7IcSSmd yxhtUSVFUqq8TpsMSyDVzdj/5FAHNVAtvVAES8+J1JczpRc1dSU2dUQ3NVJ8gVN3eUitdMY7 xdM81dM95dM+9dM/BdRAFdRBJdRCNdRDRdRE/dNyUNRGddRPUoFHldRJpdRKtdRLxdRM1dRN 5dRO9dRPBdVQFdVPDIAAGNWJKNVUHYhUVVVWLVWIcFVT/YdXJQhZrVVXnVVbzdVcpVVchVVf pdVV5VVVPYhgndVVBVZbVVZdHdZexdVkZVVkjVZpJdZbfdVY3dVm/dVpxVZqNVZklQhjxdZu /VZSFNdsXYhyRdddrVZmBdd3fVdnLdZ01dVrDVZTVVdprdV1tVd9XVd07ddirdeBBYN7ldV8 hVeA/8XXeo0IgxVYfmVWdZ3WW6VYek3Fc5VYd4VYXt3XX63YeD1Yhn1Yim3XfxVYZd1YZw1Z iwXXbxXXgVXYhPXYj6VZjXVYkoXZkaVXl13WmT3Fcs3YhoXZhRVWn31ZkKWIoyXaY0XYpV3a lj3YY/1Xh+VZnWXXnjVZqwVajWXZlM1ZmkXaj93aiw3ZhZ3YoCXZlhVaa01WtnVXpVXbbu3Y a93YYbXbnSXWcY1WpfXVZn3brz3ZfL1ZqLVak5VXsW1bVKRam2Xch13Zxk3Yw+3ayMXXuOVa qaXbo7XbiUXcqQXcftXccAXctTXaoR3dsa1bw71cUFxc0p1cuvXXrtXcXv8tXLjV16a11rrd 22rt3KqtWafFWtEtXKmVWXjl29qN2FgNXoRV3J5F29et3NjV2dmNWrC1XY7F3dv92sGd3qel XMfFWuYN3Y4t3pjFWeSF3s6dXFPU27PlWnIdXvOFWpXNWG4FX84l3myVW/kNXPoNWLddWZzF X/cVWt7V2r7dX2/13sEl19U91QeG4AgOiWaQYECl4Aru0wvGYD7V4A3W0w72YDwF4U66WWht V/y9277tXwX22xbe3XnVVrw1WM59WQL2XG5VYbdNX5DN2xwG2xVmYdUV4hZ24R7GYRhm3nIZ 4U06XIx1XpEd2XPV2qz1XR7eVylW3/pd3gB+3vH/5Ve27V2GTWIU/mK+HVizPdnUpd77nVsH VmJQ+l8nPl/yrVgsjlwqTt4ovtcv7t7ytWHCxePffV0wNt4FztrAdV2mNV36TeFW3d6cNeM2 rjoa/ts5RtUAFt71ldnZ1d9DLuTibWJINmD13WTIldz//WE99llBNlvQ1VZU5l7JZddO9uSl M2CVJeIxXtZRxmW5rWJaztyyleFd7uGw5eH3DV7PJd1TLlv/reQhPmDMlVdhvto+ruOhVdta VjpKtmRUTmTrfeJv5uRZ5t5q/uFQtmbX9WK0ZWaPFV9MPmdsLtpZnmdYTmZZht18dmOki+Nw BuR5rmP0/WeBjtfcLed2/+5fR07n0iVoRdbbtLXkbc1hOYZoi23c0F3jih5lqUPnf4blmT1d f17fccbeZDbfX+7n+P1kcJ7X483mgd7hmk3Ztb3oR1ZljZZlqCvhZ0VgFMbhjW7fE5bdVtXj AV5khRbgW77cGgbqI77mEzZipR7enrZfd15mFZ7hZqbdaz4WYwhhTJSErxbrsSbrsvbDZTDr tFbrtWZrWNzj7wVgb4VrME7goEbdICbihL5jvXbpq6XkqL5r/f1bwG5lZy5idzZheyVj5S3f ETMBZsFlha1iigbl0U1nps7ipV5kOiZlc/ZsfOZfG0ZpZV7pG07j1l3oqw7FyM7qoW5py/bi y/8+43v23vQtWYbu5qcFbYwWatIW1sneYryl1pgF7qQ1aU6kXS6G53JOXUHOZPntaJiOZqdV Z9PN7cq+6dbW5OIu7d9+YdTubNxmXUfe6dT228BuWmLOaDOWaoiG3aF+6Pnl3cQNW+2WYRZm YPWO3mJu4N0lY+ceb8UOX5uOaQBnaN/F59qe7pde6JT2ZvDNbstG7GFObZT16Np+8AL3RP/W 6t4uY9iW8JXO6heOaNvOXfH+bOClY3s+7+POX28WXJOu6RLPaZUWxfyW7dee6hCH7uXWbXg2 centbAcPXwg3Zv5dcQxHZuulaZHu7ob+lnrgMBwfcqcuZeaucq91X59YBtb4jWWthuvEpu1U juH4Lt29bfKfRmo/zuO2dvM3h/M4l/M5p/M6t/M7x/M81/M95/M+9/M/B/RAF/RBJ/RCN/RD R/REV/RFZ/RGd3RykYFHl/RJP9SAAAAh+QQAHAAAACwAAAAAxAH4AQcI/gD/CRxIsKDBgwgT KlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz 6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KterQJFazat3KtavXr2DDih1LtqzZs2jT ql3Ltq3bt3Djyp1Lt67du3jz6t3LdyW0iBP6Ch5MuLDhw4gTK17MuLHjx5AjS55MubLly5gz a97MubPnz6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt27hz697Nu7fv38CDCx9OvLjx48iT K1/OvLnz59CjS59Ovbr169g/fsheuQj37+DD/osfT768+fPo06tfz769+/fw48ufT7++/fv4 8+vnnWq///8ABijggAQWaOCBCCao4IIMNujggxBGKOGEFFZo4YUYZqjhhhx26OGHIIYo4ogk lmjiiShu5UGKLLb4mD+MteHijFXVUdYGNOao44489ujjj0AGKeSQRBZp5JFIJnneC0o26eST UEYp5ZTwbULllVhmqeWWXHbp5ZdghinmmGSWaeaZ33WB5ppstunmm3DGKeecdNZp55145qnn nnz26eefgAYq6KCEFmrooYgmquiijDbq6KOQRgrbNJJWaumlmGYKEjpjQqFpUSZ4+ilRoo5q 6qmopkrQLqq26uqr/7DGKuustNaa3ja25qrrrrz26uuvwAYr7LDEFmvsscjiR02yzDbr7LPM vqMhHXRAGxK11oJUbbbcduvtt+CGK+645Jab4wOwVdDVAuZKxG67EL0Lr0PyzstQvZqGExS+ 9ibEb78H/YshN7QJDDBBBh9s1BsKN+zwwxDP10DEFFds8cUYgztHxhwrqgfHH2esR8hv3tHx ySinrPLKLLfs8sswxyzzzDTXLNkONuesM7yl7OyzXsJwLEzQPxdt9NFIJ610UbJg3PTFTzt4 yHBRV1w1xVdHnPXSXHft9ddghy322GSXbfbZaKet9tpst+3223DHLffcdNdt991456333v58 9+3334BzCAzGg19ceEKHz5s4xYtH3DjEjz8ceeCUV17UN5ZnrvnmnHfu+cXVfC766KSXbvrp qKeuenb7rO7667DHLvvstGvuRO2456777rz37vvvwAe/MjMYE3+x8RYjTyYWdilfJvNzOW8m 9HBJfyb1F2OBvfD0+cD99+CHL/74YFJA/vnop6/++uy37/778P/ZzXkZxG///fjzrkr+/Ju9 df8ADKAAjeKNARowcCY7oAIX+KsVMPCBEIygBOeigAkOygaBCoEFN8jBDnrwgyAMoQhHSMIS mvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMoZ+OoMMe+vCHQAkMohCHSETfBQQAIfkEABkA AAAsAAAAAMQB+AEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4oc SbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qd SrWq1atYs2rdyrWr15YFvoodS7as2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AAwse TLiw4cOIEytezLix48eQI0ueTLmyZb5bLmvezLmz58+gQ4seTbq0abap3ro6zbq169ewY8t2 Smm27du4c+vezbu379/AgwsfTry48ePIk9Mk1juG8ufQo0ufTr269evYs2vfzr279+/gw/6L H0++vPnz6NOrX8++vfv38OPLn0+/vv37vpfh38+/v///AAb4nBECFmjggQgmqOCCDDbo4IMQ RijhhBRWaOGFGGao4X/lbOjhhyCGWB8PIpZo4okopqjiiiy26OKLMMYo44w01mjjjTjm+BYb Ovbo449ABinkkEQWGVQQRj73RpJMNunkk1BGKeWUVFZp5ZVYZqnlllx26eWXYIYp5phkxmRA mWimqeaabLbp5ptwxinnnHTWaeedeOap55589unnn4AGKuighBZq6KGIJvqYEoo26iibEDwq qWJ9TApVH5Va6lSmmjbFaadLfQpqUqKOelSpphaFaqqsturqq/+wxirrrLTWaitCeNzqU666 8sRrrzr9emA21wkL7E3GHltTsiUdomxDzJLk7LM4TZtlFIRZS21N2m4rU7fehivuuOSWa+5J S56r7rrstvtjDe7GK++89NYr6Az25qvvvvz26++/AAcscFw/DGzwwd0F8hYoCDfs8MMQvzdC xBRXbPHFGGessU7pbuzxx4WFAvLIJJds8skop0ynCEoxjDIoLqss88xVkXCyzSbjTPPOPPfs 889ABy300ESHRs3JR5ucdMlLk9z0yE9fqc+/cBRttWtWXK311lxXJEjXYIct9thkl2322Win rfbabLft9ttwxy333HTXbffdeN94xN7+e+ftd5fF/C344IQXbvjhiCeu+OKMN+54QYM8Lvnk lFdu+eWYZ6755px37vnnoIcu+uikl2766ainrvrqjZfB+uuwxy777LTXbvvtuOeu++68914U O0Jn4Pu4sgxv/EaNHK/88sw37/zz0Ecv/fTUV2/99djXF3n23Hfv/ffghy/++OTXhEL56Ke/ NT/qq5QIyu/Dn3L87ddv/1cx36+/nGfs7///AAygAAdIwAIa8IAITKACF8hAnxijgRCMoAQn SEFdzaGCGMygBtcyhw560IMbDKEIJ8OyEZrwhChMoQpXyMIWuvCFMIyhDGdIwxra8IY4zKGF XKfD7rSjh0AFDCJQAgIAOw== ------=_NextPart_000_000D_01C6D263.CA63A100-- From akgrc@tpnet.pl Thu Sep 07 08:45:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJGW-000669-Kd for ccamp-archive@ietf.org; Thu, 07 Sep 2006 08:45:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLJGW-0005C1-Ec for ccamp-archive@ietf.org; Thu, 07 Sep 2006 08:45:56 -0400 Received: from bxh146.internetdsl.tpnet.pl ([83.18.241.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GLJFN-0008Su-8n for ccamp-archive@ietf.org; Thu, 07 Sep 2006 08:45:56 -0400 Message-ID: <001101c6d27b$54277440$92f11253@Krzysiek> From: "ZS" To: ccamp-archive@ietf.org Subject: ported voila Date: Thu, 7 Sep 2006 14:44:16 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6D28C.17ADD340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 ------=_NextPart_000_000D_01C6D28C.17ADD340 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6D28C.17B04440" ------=_NextPart_001_000E_01C6D28C.17B04440 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Windows Linux OSX free download use. If you check out tutorials for step = by if have any problems questions add them user forum creating account = v. Version beta now available from page. This release contains fix = windows startup thanks tekNerd wmv output only few bug fixes. ...read = more By countinn Releases Music Banana just released brand music made = ZS. The recording features two musical friends both filming this track. = Theyre Rick Clayton who plays drums Nicholas Tipney playing Vector = Violin himself course. several minor still under Tiger Windows. Click = learn more. Singing Flower Slave Effect Audio explains how map parameter audio waveform. You can = see example demo video. Capturing Importing Weve aquired workable mac = mini box last week ported voila had running onOS Tiger. article go about = capturing into zs os available from page. This release contains fix windows startup thanks = tekNerd wmv output only few bug fixes. ...read more By countinn Releases = Music Banana just released brand music made ZS. The recording features = two musical friends both filming this track. Theyre Rick Clayton who = plays drums Nicholas Tipney playing Vector Violin himself course. = several minor still under Tiger Windows. Click learn more. Singing this track. Theyre Rick Clayton who plays drums Nicholas Tipney playing = Vector Violin himself course. several minor still under Tiger Windows. = Click learn more. Singing Flower Tutorial Slave Effect Audio explains = how map parameter audio waveform. You can see example demo video. = Capturing Importing Weve aquired workable mac mini box last week ported = voila had running onOS Tiger. article go about capturing into zs os some = one has capable exporting files. next pagelast all content copyright unless = otherwise noted. website playing Vector Violin himself course. several minor still under Tiger = Windows. Click learn more. Singing Flower Tutorial Slave Effect Audio = explains how map parameter audio waveform. You can see example demo = video. Capturing Importing Weve aquired workable mac mini box last week = ported voila had running onOS Tiger. article go about capturing into zs = os some one has been long time coming... Fruity Computer Spotted Office = stands office. It ready creation effort. Some for step by if have any problems questions add them user forum creating = account v. Version beta now available from page. This release contains = fix windows startup thanks tekNerd wmv output only few bug fixes. ------=_NextPart_001_000E_01C6D28C.17B04440 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Windows Linux OSX free download use. If you check out tutorials = for step by if have any problems questions add them user forum creating = account v. Version beta now available from page. This release contains = fix windows startup thanks tekNerd wmv output only few bug fixes. = ..read more By countinn Releases Music Banana just released brand music = made ZS. The recording features two musical friends both filming this = track. Theyre Rick Clayton who plays drums Nicholas Tipney playing = Vector Violin himself course. several minor still under Tiger Windows. = Click learn more. Singing Flower
Slave Effect Audio explains how map parameter audio waveform. = You can see example demo video. Capturing Importing Weve aquired = workable mac mini box last week ported voila had running onOS Tiger. = article go about capturing into zs os
available from page. This release contains fix windows startup = thanks tekNerd wmv output only few bug fixes. ...read more By countinn = Releases Music Banana just released brand music made ZS. The recording = features two musical friends both filming this track. Theyre Rick = Clayton who plays drums Nicholas Tipney playing Vector Violin himself = course. several minor still under Tiger Windows. Click learn more. = Singing
this track. Theyre Rick Clayton who plays drums Nicholas Tipney = playing Vector Violin himself course. several minor still under Tiger = Windows. Click learn more. Singing Flower Tutorial Slave Effect Audio = explains how map parameter audio waveform. You can see example demo = video. Capturing Importing Weve aquired workable mac mini box last week = ported voila had running onOS Tiger. article go about capturing into zs = os some one has
capable exporting files. next pagelast all content copyright = unless otherwise noted. website
playing Vector Violin himself course. several minor still under = Tiger Windows. Click learn more. Singing Flower Tutorial Slave Effect = Audio explains how map parameter audio waveform. You can see example = demo video. Capturing Importing Weve aquired workable mac mini box last = week ported voila had running onOS Tiger. article go about capturing = into zs os some one has been long time coming... Fruity Computer Spotted = Office stands office. It ready creation effort. Some
for step by if have any problems questions add them user forum = creating account v. Version beta now available from page. This release = contains fix windows startup thanks tekNerd wmv output only few bug = fixes.
------=_NextPart_001_000E_01C6D28C.17B04440-- ------=_NextPart_000_000D_01C6D28C.17ADD340 Content-Type: image/gif; name="Chroma.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6d27b$54250340$92f11253@Krzysiek> R0lGODlhxAH4AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAVAAAALAAAAADEAfgBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKnVhjqNGjSJMqXcq0qdOnUKNGpCe1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/VTkBHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOL1iwoIajRqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868uXOxP55Ln069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/CtIohPv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggy+Z0ZnxzT4XIQSNkdhhctdiGFyGm54XIceFncM iCGWaOKJKKao4oostujiizDGKOOMNNZo4404siREjjz26OOPQAYp5JBEMtdKkUgmqWRPDyzp 5JNQRillRQ9OmVmVVl6GZZZcdunll2CGKeaYZJZp5plopqnmmmy26eabn41AEjRw1mnnnXcq gueefPbp55+ABirooITCtkWhiCaqqJSMLOroo5BGKumklFZq6aWYZqrpppx26umnn7oBalei jqpVqaZmhWqqV63KqlT/rr4aVayyPkVrrUzdiutSuu7q66/ABivssMQWa+yxyMp6T7LMNuvs s9BGK+201FZr7bXYZqvttpQWwu234IbLFAjilmvuueimq+667La7lRfuxivvvPTWG1k6w55h 7778bmpMvwAHLPDABBds8MEIJ6ywjeYs7PDDEEcs8cQUV2zxxRhnrPHGHFe2S8cghyzyyCSX bPLJKKes8sost+zyyzDHLPPMNNds880456zzzul2wLHPP3cMNM9EF2300UgnrfTSTDft9NNQ Ry311FRXbfXVWGet9dZcd+3112CHLfbYZFdUQdlop6322my37fbbcMf9q2By1w12Jnbnrffe /nz37fffgAcu+OCEF67mOR0jzrHiGzOu8TmOGy755JRXbvnlmGeu+eacd55sJBuDrrHonpdu +umopz61Hqq37vrrz80CO5QAzG777bibxI1eHuSumxa+By/88MQXb/zxyCev/PLMN+/cBs5H L/301FdvvUypXK/99tx72QxrhypvRPfkl2/++eU7g/767LsbefvwsxlO/PTXb//95iKCP8ym 7O///wAMIEhckTFXGBBjB0QgAQXIwAY6MHOl4NMwHkjB5smgghjMluw0tsGMdRBjH7xYCC02 woyQATP6cFEJKbbCDLrwhRxr2MZkOJAwXIyGGsMhDHfIwx768IdABQyibwICACH5BABb5wAA LAAAAADEAfgBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmy pMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Lny14CfPxPYcxFU4J0BpBCUGMBq4FCkCIgCLfrv xVRWT6f+ZCfQ3tKfpJx+Bcp1oFWgTUHa+8D2wyenJ9geMOqWoL24bdu+u/vhndkPp/79kitw 8Bd7Bl/kDcw37wd7a/MeLjjY8WOemDPffJo2a9h/R8MeJZOg61KhRMs6TV14QOl/T1ULHkBa 8GnYt38t5Rq79euOhhFXRtz4Lei6Bvn67Rp3eVXAgglHnwy3b+HHygtGnjs84Z0P1DX+ix/P knNXom1cg0ZqW/1s0r0J+qxd+HV83O7Xh/Wq3vz837/8ttF2A333Fl9nfDCXgQdlx5x1AikW WGVzTYfYQMFhCFlz2hEWmXMdQkjeiCSSZB5sRNXjgmjsxWdVU/e1xlSDrLVGX3tC3ebfT2mF lOF12MV1wAlvMZgchw86J2F0Cl4XHpOB2YWkUx6yBSJB3z1Z4pZcZnTiUwn4lEBoRrWoo1RA 7TcWVSgOoNpov/GXo3q61cbfVAJulOWFsMnF1wGDHWCkdlM25tiE0v3YlWXE4dXWgVU2mZyV XVZqaUVfEoUaKXawh6NPn8V4nlb21bjejXLeCZZdaLKpJ3j/fG73512fDCqliA4+h6ikij6Y 1wG5LtqkrVjCeumxyDKUKZ1pmuXmUWWJStlWo6r2H4anyambmwf5xC1wxgK5YZOVIUcorlMu SaGTfBpU2V5TCvsoQh8ma++9rM7YZmmeYUhbC+6JekucNd4nZ4FmqneUegOv5ua2YZ4GsUQE 0nWgkLDhZdy5zuW6ZMW93hJrc8H2Kal34TJpz3Dd4etyZsu+5u1n+HnapmzryUxbqd/aWNrE Bz9F2lE6kwbx0bdJlGF3fwK58a0dpwvdcVEqduV3FQZXcsUIvSsfWyuD3fLLZOPkLVCoBUwU zVVROyqpWfGYL86q0nwwfmREdVVh/hL3nV9EkbG1cdMZmwt1dUpOzaR0t7YVpaFtQcb4QYo9 ybLYYJet+eacd+7556CHLvropJdu+umopz4TP6q37vrrsMcu++y012777bjnrvvuvPfu++/A By88Zu6Ag05X4IDDbzvGD1R887Axn/z00P/z/PRCMX+8QMVvrx051NsnDjjyIK+89NRXH331 3a+fvlDgU7+9Pehjf9D1ydsXf/5dxa9//vRLn/K4Jz+71G966Aig99oXwPcZMH3zcyBs9jfA 5FDQPtIr3z8OAMADKk+BwzMJBwc4wvLZA3waPKH9nKI9u4wvgglsIQG95xT+2WN8/BpfCvm3 Pho6oCsy/rRe80BoFxTC5oU9VMgNoWePIdoQhxNMngZH+MEgApGJFXyg94goxONxMTktVOH8 gtjECnIwT2XM4QAbSMIOqi+JITQRFJ/nRSjCJnxaZKH67KEOLraviOQbyAiFokPzYfCNV1zg EK0YRROGkZF5dEofjSiQQapwkdj74h2zaI88wfGTDISkHr0oQyIuUYOVFJAKUWlJ5qkjkK1E 5B/jKBIVwg8d7Pgg+4w3y0+mEYy7pOEm44TDUxoykQ0KYijfuMokatIuPIQmJ4sJvlwSMpdV ZGbyhAnMLSoTk9wc5REDCcdBKjGaS8we+ZiXgFhys5e0BEnx5HFDdBSvnUws/yY6g2hO7Xjw jf1spDGHiUxgCpCUAoRfINPpPjwKMpoP5SQKVUgPctgTHbF83yVX6M/qsbGAH4VoSL0Jved5 kiABXWUA6Um+jOIRnvH0CAcTqLwz3rOSACxkQTcI0Z3CM6UT1ekvPxnJLhI1ig59ZkQ9CVTy 2fJ58nCnQaeHSnH6FJwJIaI5iWjSjQqoqfRkXljBUQ83vhORMeXIEq1ZT/At76BWJWhHFSnM oY6TkOQcqlL9iFVA0hOJR5WmJ+2aTlumUapZ3WY347rMcBbUmFrloV3leteVbtKsBplpWkPi 1UvOz4795OIX+cjXulKSpx+kpF5FWdqjNrOEgY0rbP4mSU7UKvSWttXkAeIESdF+E6GOhSNk SylUkZ42lo7MpCg3OxI6um97odWhD4i6xM/GMJjJeaIZS+pR1v7WtUZsoDqDO07rEpShtkQp ZtW7wyzGtbVKLahJP7nVnv4SvWI1XzbrulzmYgS2tvVlKSGJP+A6D60bdW8ZpVjUoi5To6r1 nwdPWmCnXLB/7nWpcguYzO5iN6QKPmAEk0rBcCb4kCmUnjo12l//uvjFMI6xjGdM4xrb+MY4 zrGOd8zjHvtYx9X4sZCHTOQiG/nISE6ykpfM5CY7+clQjrKUp0zlKlv5yljOspa3zOUue/nL YA6zmMdM5jKb+cxoTrOa1/7M5ja7WSAJ0IY6UmcPbYiDyG8AgJ4JcNLNbEMbcLZzoLUh564Q ujRxTkCcCQ3ofyxa0AIpB6MBbY8/M5pflib0PP7BjUk3etCQLsijP/3oOQuk05MeCKo1nZxC g9rUq760o1Ntl0xrA9OTRuOfA33nWRP6zpXO9UBGfZBSd8XWr4nzpn9sAgCAAzYVeDZmgg0b Qkf61tUGNqHnnOhZ91rSy+bGpjuNaaHsus6U3jVByO3ta4d72cN2dTnmLGl+QZrdce41u8Fd kHpf2969nrWpBR7pgcPm3NamNrq1g/BG85vT81C4tQn+j3n3G9t1BnbDVR1wHt8CAHzuH2wC oP9nIJTm4wYgOSR+oQBnjxwIEtDznFmuZwDMXAGQoIDM7REAkwtGAQRAQABCTq9dszvjA6l3 ndXBjVkjWtD5dopQQt1Jhf/Z3J8+NcatHfWuqHLicEb6vzm99Ubj29XH7rXYK45tii982LVO 962tju1OHxzQZw941c999bfD2S6hVjrf297tHudZ2hjCObRN/nE+NxsS9qiAyXk++QoAIEzA 7nmYFDD5oSeg2XM+PM+J3qCruzrOA0f90hXd7agrWzuMHrjENZ51sj+d29qAt0FQL2q08/7s sMY2752S+0Cn/vTINzjDKS3o2Wv97sN/fdyzTfFi+17Ozg90n23cbMT+CyTPpgb/x58N/sh3 PuTgJ0izNw+JxbPf/NuP+6GNH+8+Yl8crRc0v1G96VHP3dabFmyyFmuvsX+sVn+9d3xzRoCq Vndtp330F4HRh3bJAYB3x2i6d4FtZ4C5J4CsNnzWp4AeWHyGloE5dngFkX7/MH7j9w/lZ3lC 4Xkr6HLNVnPs537mVwuK1xDBNg4TB4KqV2jc4INPd2fSJ30X2EfqBm7Utm631nVHSIIRiID0 R25dR3ayRhCFB4TJN4UV6HAduIRSeHc+2GhRGHFiOA8guHvXp4RguGx1ZoI41nj6o4Li53Iv eHmjVxrgB3r/sH4s137wN4My5xDU1mlztnb/Sldoi1aE7TZravgb+daEqqduDVga/AaFY+h3 jqaIDoiJJMhuDUKCnphsrsaJqqRulWiGFHiIjAhpykaJ2Ad2jgZ4ASd4rGhqhddj3Qdt4MBz gih5CdCCeRiDfEZ5n6eHMBiI7jdyIMcvMlh0zIdt/oZ0S1dtwndvxadshYeL7taElwh9ZNd/ Y0hxFleN2ohrpSGKFXiLWxdwXGhqFucUadiEBnh32LiO2xiGb2iOCwiGAIePbLdsu2h4NRdy PFdyJ4eHNhd5ekhyCvlzAABzl8eMg/iHLjdypPeFg/ZqhhZ8ikZrksZo1yZrIxiAFiiKjch2 JMmGLelraKeSh8aO/wbhbx5JhaBWeyepgaEodx3JkglngTn5fDe5k6fWcVi2hxSRkPEXQteo OkiYZUo5ER/XfjC2hqWzdm+2lVzZlV75lWAZlmL5ZMzIEC04lhQBAFzmkHvWlN2ygwtxlg8h i732aLSXhTBZexJhDGgZR8j4c27pLnCpEHJpiBs3kKeGhtMYgfPYlzpWlRhSD5r3cwRgCwCQ cgCwci33bIGoczbXFRDpc+M3lQvhio7odXQ3dVkXmI7pYh+nZ4jnh4dHh48HfyxXeSZnkcI4 mtFYmqani+XofFjZmjtWgwoZiPBHjA0pjGUJfnZoc4XJg5lWgMXHfzs5nMS5YzTnbDmoeP/K 2UfLuIPO+ZkzCA7RqSx/VoaBRpD86G7YmZ029gq/kWft95qf+Z0OeYMuaHPPqQ7n6Zt494p1 2Z4Ch4rwSWPF8H2XB20LmpAhh5/hKYieB4zux5sbmVUNp4/kqJju5o8HamNsOZG/0YvluZ/g WZEtF5HOKKLlSZpKpIoTN5JBOWnwRmwf6mNMeaM62hCQuaM++qNAGqRCOqREWqRGSjonEADk IBO3EACUcKQvk5A1p3z76X0f0aQBkKWehKUBQASvwaUBsKVKuoJOChsWEADtYIgW4KUDAaav kaRlaqZPShBvgKZQii/I6JBUaiINUACw0aeUEQB++gtlag+Aaqj/fmoXa3pyhXqmacoQcMqm f+qniEqmYWKnTYpGDTCnd5osfzmbznYLlely9tl+2/lsLsqjjRqmdDqmhuqlTfqk9nCmAkKo cxqrZoqmr1oBWfqo2rGoAoGrsxqmdXqp7TCrnEoQJyCpnXosnxqqAAAFQGeZ5pmZsEEJLEd+ DdmbDlGnS/oPSeqrLuiqtOqtAhGuBNGkjyqsjvqqQkGryQGs4/qt4ZqphNoOmXoQxapjG7Bk eUpyw2it5bl+A0Gw/9mtYwqudoohgpqrCWCuCiuu+0qmstqugDqu4toV8gqx6AqnlICsw5qw ZJqxzdolUqpnCylt40ewAmGcemaVE8Gx/ws7EHWapV36sAmLrjTLqhSbq8d6sU36rYoqqTKb sZn6BrDKs+pass46mW2akSu7oC0rtRfBrjzrLmVqtQKytD07rEJxsXVKsrMqqVqrqE+KtMPI sxPLtJXyl0+rstAqiKVQlr8gDqmqLIeat4mqsaxaqZUqH3Hqrn6bt8zqFPI6uHsbrKyKtvkK roXLtlvitsEKtaRac6aaotzJrQ7hppOaqzfbpjZ7tRorqYaapWxauqbrSXCapYnKuYY7pyH7 rYaarJArZEGbVRdrEmFbu0aWpEKrHblLErjKu8RbvDmmAsabvMq7vPCJA57To8x7ZSf7jCF6 oQcBvRWBCmohbP8FEWtZZ5MQAb6Al4UeyJrRWxIuag+VsJAwmxDYWxN2R3YGEb9aiJcN8Wgn Fb92F2ygaL7nW0ua6xSaJ5uVCwmQ+XjpGqoE4AuYe3M5V4iEGJGnqpHbJ3biK78HccENocEW PHew+ID/2xIn63PywXkPS4PWeoea2b4zKK0LnHm5acJ7yHLHyJwKoK19FMBUGJVYOH9JB8IO ocETOG4Oh5Qh/BIfR8JTe7mQIHSkYHImwHiZSQFKPLksjJE3CH/pB38Gm5ELMcT04sNsN1gY mMFATHGv54FyeMTlAYM0i7LQtsBCoIP04Hn2eaFy6bJZLIwEy8U197L3i3xrPMY/7L//Y5eA 62mNYszGLpGfCkq1UUwGQVcB0vpsVVkCXjy50uaHgKh4WvyZfmzIHbx94KvBDMHBkFZvZ8jI LHELcGuVeUa1hPhsNci+QlfFZ7l++ambUiyhMWyVdXu3TkiU+2tqWmnKCwG++mt2zPdtZ8zK JWGfArudU+qMc5bE7LufpHeWNEeRe+xzsQxzPkfNv6jDxJeF+ztp8OhpD+F/RIluPgzPzwzN plOW9ExmJ3vF97zP/NzP/vzPAA08KxDQBF3QBn3QCJ3QCr3QDN3QDv3QEB3REj3RFF3RFn3R abYIGL3RHN3RGfEBHh3SIj3SJF3SJn3SKJ3STIszKt3SLv3S/zB9pHIQ0zRd0zZ90zid0ySi ljrd0yJtD8LAD6VhDvwADQJB1PxQ1LAR1Ekt1APxDk3t1ARBDFHt1EAd1XNG1XHC1Ek9cFQt 1QJRDVEtFFzND6Ym1k2tSmX9Gl+d1kuN1QPx1fYR1ENd1OUw1kld16+B1EptF3n9D0RN1lhN 1IlI1/8A1dKG1n99vlctFH8t1qZGDH1E1/bw10Sd2Faq1Yet1I091WDd2X692P+g2UAt2AJC 2sKg1kJd2U6t2VBt1KDtFG791o7t1K8NG0n9bIH9D5AtEJId2rq92oYtEIiN205N2KNt1an9 v43t2n0NG+zQ2NIt2r+b3PyS17Ft3f9OMdwDIdYJIAxGjdvhDRumLdvj3Ul2QdmGTdrYzd1h LdTg3RV0rdmbDdv8AA7EkACBfdtdIRuVjd/6LdyfHd9Qbda8vdrPjd70nbxXTQ73fdQGnt4I btTFnRCafdm07dlbDdZLbdTebdwPLt+f3dRWKuKOHd4X/uDZDdQertz84OCId9v/bQ4BHuB7 2hX3TeOBnd1abQ7QQA3PptWsHeK+zeHFe9WL3dtfPdlwjeEWPtYi7tYLjuR/DdVzZuUQPtZU ftxVrdpNHdlQ/tZujeVYTuW/IeP3bQ/QcNcJoORd7de/uOYC7taBLdmBLQzSxteizbxXLQ2W HeFW3tmQXeH/CKHVr50CGR7XA87hHz7a4y3mv+jeUe59gm7ght7X2d3oxADbQe3nUo3mQe7n Nk7cEY7joS7gAgLV7JDalZ0ApQ7pzD3fD87fgW7YiM3av1Hdmg3ZKcDjix4nVZ3X73DmRR3b w/7Uz53hxb3rBh7bQ67lsi5toA7Ywt7XWC7bwY3qfi3qQC3qh03sj768093aBl7rTt3bTl4N me3i5a3oG/4byG3qUP0a3m3sUt3oJn7gWc3usR3vuB3pCG7bnK3if03VV/7q/23c7a7o5C7w 9E7uhmyknY3UpaHYc/7mpD7b7p7x3w3XbV3sZa0OC27dFs8vIX/gGh/lGE/fBd7x/18+8lpt 2Ejt4Gkd4vRd8nBe5IL95e8d3mI93jiv3R2N6D5d9EZ/9Eif9Eq/9Ezf9E7/9FAf9VI/9VRf 9VZ/9Vif9VpvvBSw9V7/9WAf9mK/o78gCbtT9pRh9iBR9mh/xL8gCPxSAfrcLWqvEG2/EbFs c9RMuRCcwM+YHFUQ8YJR9xlx94VB+AthAgNnAjDryu4iCWi/nYIY+IJpam9/UvZA+Td6+X9Y 4hdh+BjxBgiJrXCfgggZAKYGDBhS+oAv+B4B+qBPmFY5lW9ApWwvCUL3GqYgFJovH0IgCT/D +trR+wd6+W8As938M5KAyeNs9lLqczWoDmXP/PZhec1fAv/HGJqqVLic7xQV8BuimieXP/0i GqLByKLTD3NfunLOb/0nt8mbnIjuXxgpysLkX3nrLx+lX7cmwC+Bn/cAoe7fL0kEfwlK8E+h vQoAHEJSqPCgLYEHEzIEACQBxocRPX4EGVLkSJIlTZ5EmVLlSpYtXY6cCHFhhYS3IP5SUPOm JIYC7RFJYPOfvXY4E76RaUKgUKNDK/gE6tGiVIRUEy6MarWpUHtVrv5T+o9pTrHgFColCHbp zqFVJG30qlYsRIYJ00oli7Ts2a9Oj6q75ZOSVCEJDEpCEEBgxK59JQpCUMlw1bBc477EnFnz Zs6dPb/ECUDmQElYDZcmTXrqz6D+o+9atFfgItDXVVl7FIrXocPJX+0FcGzxdenGC2UPpY06 9sbkCI6zbvxL3JuNspcj751aKmrY1o97fCPQzMbBt8wy9np4oALebR0PRBi4+2y47z/fx59f //7MBxMvzq2u4UgLECiOTjPOMPYc0uiuAvu6hYC+poqIQuw+Eo474i4LjUEE+WKqoAUzSsiE BKgzT7r1dtMot7sqVO44pd44DzdIEBisMeoUesND9SK6RaPiMETInkp8QahDEofkr0knn4QS P+HIWi05iUr78TYeIamtugk1NM0jLR/rqy4gJSTyw7SGvA5GIMHZkSDnHAvMq9goGuq7K/fc jkzSqHj+LzZfxOGRnrgirO/HmeoDaapbRClST/eipLRSS/+x49JGq3pDQjND3FNO4AYq7JWa wLnLhPPC+seUD3+zq7CPOr2IEgt5RPO3xbQCE6yvWHX1xZ/eSg1Yu6RAzQRi5WqVuaNG41PV maD1yAQprvpFlMH+oZHU0wgKTCJZTYzIhJtsqwBNY33VtF13382PQhMkDA3NAdO6xSEo4nOI 3gVH44gthfIFYN/3euRNSQDOIxiAXYHs15deQ6OrIdG0O+u8NS2WqaeB0XSqI7EcEgW1Cv+t 1j5uNVpIsZZFA/SwxDyUiD2IzIXvKkRDvnhFauEFOmihm3xxs6KHHrpNpJf+ZrpppzEzoV+V V4oaAJCfhrdbrLfmumuvvwY7bLHHJrtss89GO22112a7bbffhjtuueemu+6vj7Y7b733Fnq1 Cn4WCe9GTeYMYYf5G1Lwkwx/mKTECeesw6ufhjUivVxSnG+vp5LWs8xbonWobfVj0qXQ7Rm9 pNLvm+ryrV2sSnPNLXI9NJYJKoHE1H6juWp1cNc95NslKcHTAGhmLKuTdcedAIlzZ3nF4Ytv Yzd1OBItLdvtIj745INjb/olLc6+oO6H5xOj6H23KufmFQyedxLfV/8q9tnXTfzoPwqL1e1f vti9JEEBnd0kfFOTHbxiwhiazGU9OiGNx1jDlaL+5CUpa3mgU6AyodgtyoFNaYpePmXACRXm cSPMYG4q1EG/fJAslsGWiCA4ILkIhYLtm9JFGsiVp2CnKTWECAVvyMAZvhBwB5GYB3nIPe1o TxLmOcv1dgi4BAKNYm7yIZgMYhugqLBL12FNly4EJGrdJYy9OqNpjtaYx5nRShgbWBmV88Y1 cch8oQITGLt4RMqYhYZh5OKrnrNHMobEjWqCnOUAEEM1VsWJeJxTGsdYxaH5x2UO9IsAH3Qg M8pGSQ1CzYNwM7kA0eSPhMykyRAmJDuWEpEf2VkhU7mnNmpRiyMSksUmhDLtuPJBr8HlRnR5 IBstioabKuCiXIQlW/r/yoYdayAlK5kkKgVSgIe0HJe4E6kvpU95k8xZFvkkHGuG0lN2smOV Ximmb6pzQLUMlSOJI6lstg+L7pyjIO3jOteFU5KKo5A75RnOR5onToGU5jSP4qkpNpGZiYlV AkxVllStajHBUs6ofiEr8OSKEiikYbdAippubbREMRwpnzpaq5Rqh1yq0eK4LqgQV00Uiivs Zgu5otHCvMhYNgUHUMXU0GOmSYl0GRVTZLo7IhALhQntW+zmBT97NZNgBiOYv0TGM4GNrGAs 5NFu7MKeqtZsq/Vi4lCOBwlA+Ux7ZE2r4Aw3VqvFlTs2+9FdEMYK5XDMq5O71YvQOjB9Jclk /gH7a1CkhiG4OjRwHRysV6FAUofw1aU1iixU1/Y5lnDWJJ7VLEpAa8VEhlZvVZvcS1CLwJOM 1rQhWW3XXPta2tbWtrfFbW51u1ve9ta3vwVucIU7XOLKbrbFRa6T/CaThi0GJ87lV125tRuN oUxJdKXudRXpkBqBx3qEdYhzR4Td1CpJm5FL5HGTu9549RFXF3HZRok1ldaBzFWVa5aj6MVC /S70Kq6alUe5lav4VgVRrSsjWPejXvY2uDO0g+ZXDiwIPNG3SKOyp5/IyUH64DckY2rhx7ID SLvwF7Lmg95Rvgu86AWMIG5YcWnw52AaL5jCrukgICOTnQ1/RFft/iupiZ8Vzsdy+HsIJqiQ YbQVaJmUyRnDorfARZd21NjK8bIZThkDHIvIx5HxqZh0O4TdRa5IrB1iWJhJmWDfcHlBGnOv bribV8JFJ496ElZ6nkjFK/e5P5C5pIVIbCQklTg7RB5YgxzZUyFfLqAsjKWfGnkimXToZxai c1jnp8UTT3fTxPRzqP+sIB1KeL81gZSh8XsrAaHr0GSSIIZZ/U0ziRg2PbxVhjONKDvH8yvg OueHuMVnURe7JPX1r1orgi57carZQXEuoyMa2EUnO9enG8zpCjxtBUsapnsqaU/zWAHMSsIN fhS3K05lbHarRF5oaq6kEZVVFYdXrTTr/9DtRrQwCoWOcSGZK3gPR+ROFbrIS87jWmOGRouh CjEKPw292z1xilfc4hfHeMY1vnGOd9zjHwd5yEU+cpKX3OQnRzndjJBylid35S2H+XBfHnOa +3bmNcd5znW+c5733Oc/B3rQhT50ohfd6EdHetKVvnSmN93pT4d61KU+dc3YowVgYK2mfiEA dFCd5fYYgADELgADZP3DVy9T2LuuEBeQ3ewnabvY1x44rt+B6y3ZugAS0va3g6Ttc/e6bcGO 9X/YHRUtsTrhGRN2wv9CBG6vegv0PhABHJ7ugO+s3P/Bd5fYHfOBf+3g7QJ5x2u+9GKXh0Qe L3bFL2QABmBB6v7voAoRlH0oYRdA47n+i7KfHvNbt7zV9e54VLAA9ZRHx9aTL4LiH38gq/99 5UmRAM6DnfV7F4Ds7w78wt8d9PpJwdlEv/nti6DrdpfHL3wyAKw7vuyJT7sBfIEKBJChF7U3 DPOHgvato6H2vjC/7ku9iPg7Atw9EcA6sOu93TvABHy9/Du/7JMKrnMB6hs+/YM/zyO/w0M/ Afw+wcM9sbsKzlM+j+C7DoQ/MXk9BBgAVkAF90uADhRA7iO/0QO8AlQIzyO+/Ws/Bly+w4M/ EvQ+idg9VJC8GJTAGWQ+FmQFrHMBwpPBDww99kNCy4u7sTu8K9S76kM7FSw7u8u/L/9MQuUr QfIbu8ozwSH8ux2EPzI8QCBEOy1EwwrhOnsgAxXQOxlUPquTPzG4P3p4QMobQCk0LdETvtTj PANExDyUwBRcPNtTPTEcQPQrw0RslDkUvvyDwx5MvjfkQQtUmRKMOyScRAl8QjYwAARoAf/7 PEIsRCp8vgu0PPXju0xkQ1h8xF/DP7DbRMPwvh0ciIfJRMo7PDbkPx80xvbTv2CcwK7Lu40Y gF6kvLsbRbYbQleEqvHrPmUcu+XLPTxMCLv7xta7PUh8PtuzvtyzwQpZvWu0Rs17vl50wx/8 xFiERyLsOuu7CNxTPOtLva1TPBzExoEkyII0yINEyIRUyIX/ZMiGdMiHhMiIlMiJpMiKtEhK goaL1MiN5MiO9MiPBMmQFMmRJMmSNMmTRMmUVMmVZMmJnIKWDLUfgEmcIDaYBLqoqQgFYJke QRUFqEmQ4EmSwAl16ZmqCaB9+wrDMZ7vssngCkqCKRGHoUnWUQAJyReGOhxdGUrFIkqzYAhw CBewGLim9K2pRBgpahCfpAB7uzfvISyzMMruGsqZUTHXYIetxIkWka6hIId30KGxJEve+g0J MRcKAIfBVBAhCQB/qZj9GRk4ORwVORkCGICFOQvAXA+rvJighC23DMzdMgEgqAfFmBdfUAA/ 8kmn0IgeWQzWxI2FiZojGq+QuZ7j/5HKfROIqOmul9nNz9ytHmGFnAiSVojM1GSI1Ry4fOku 5VSShwkNKZAunAyr36lKYXIYzhSTxew739SsfJGCtITOsWrMExk414SYGolNvCCAmTGLHpEJ 1tzK6QLLvbQHcuDO4eKdpbQX46wAxRzP1wSH8VgPuazOfFHMw4HP6sSI3LTMr7y37bxPacKI MKs0/mQZ+XHMxzTKMqpOscRKqVGYXVFK+CqzCDXRE0XRFFXRFWXRFnXRF5VIBlsbWrEkCO2s 0nI3QNuISwLK1LqyH9ub5RItHO0Tz/i3/XgcvJOn6ECXn1QpmCDSIS0OEPO2eDOz3UCTIzWr 9tCu9mGI9/+kritNSqZ8Tbbs0mNTAOiyUR/7JjhyG87pzf6IUpbANsS5DNVaDNRh0hKJU8yQ Ucb4qMvQmmoRUQJzzg6qUy2bsJoArDgLnfwysCwVsJVStnCKNJgQgvnqtpUYVLuBsOXRHybC 0KiUyvO5ivohjeLZUeQJk/zhnuJ5nuD5n+apnvDCnvOaVVNlU/v4VLMK1d2xTZbxHRY71YaY nqX0zARhp2I1tV+LHSrVsh7jnHOhtJYJji9zFpGoNbE4NUSDCQpbtr9kmZvqnP5hS6UpFrbU NMy8mxsjIheaIZ7ooQmishCaqbHQoQ3KMJ0ioQwSIaIiiwoxITsCKSPCEBxdoKP/SiFIoAGC kCBCIgp7jSJ41SBwQo+cQrQxebRQ5BQ/6tizOBdbwLFrPQqP5VjfoI2P/SzIkAzOwaA6eovG GKLSmbKhqLJG4aiwuSJveqUtog8v2iYvESd/+iYV4tlTepU3ulh4GtqjualGybKjtSV1AlpY GyQ1QSjYghDMyjEMIzKjZSyxEtOwHQ0eqivtAtsMg5UzFcr4+B1uwo7omA4vSduXupK0FZM7 BRtLApAI06SOMRBd6iT48ZFQAlwIWTNjQiNUEhBV8pDHcaWi2gtDArS+VVw82iTBjRHC3bQ4 alWQsNvJzVjloZBLxSFp8xaq+A9Jk9bCMF0tm7TU3a4m/yuSI6EmFjkpFEEVQgE1doGR3tW0 DN0cajK0pmUmbNqSL5IUpF1WL6WjoMUnEWOjdCqnJ3VTnAKh6k2NLFEepFDenEJeH9NbYYkm bnXWU21TLWu1UtMKsli1JHE1aPUgW3O1lUU1uMUNdbCTAsCTepqUKOsnXtPbdvWvlnIiiPIW oKqoic2vjIqoAGMpouoVkZJgHkG3k7oSA4Yc+UU2DSYNBDYpBU4Wi6KpV+Ep+0DXMdG2Q03K SdUw1DUpsKDWAbM2+H3gOsUZGq5U+srZb9UhdbmoY0kWYhGqPPkSdRNdbrngsXk3qrKr1Liq 6NKqnuEqjInigxHbwQKms2osM/+COLfCki7uFUKlXPvRqrLa3tK4YnqzNAbqiBe5YoDrTVYR uMa5lYBbHuZZkPWZYbDI0hXb4zFtjxz2qoHLN7Mr3Vzxq4o138Sy4IOVuC2DmTXdrDldiT+1 XkvJNc+xZHcrLWjd5D6T39uKLc0oZdDo5CZ51M44ZahZLB/jUQguNiCF0Vq25VvG5VzWZdZJ ZaHs5bfhnT59sF/2U8IZLUzGO2LWZGVWm8wJgiHVjONK0rKh4wVjZqAMU0My5vSyrjuKEmm2 oxtVnXB2t25+myB45mO75iJNidUhG3eWknW2HPvi1W2G5f9ipG8mZnj2jGlGCfwCMKw5iFpN gKgBJWL/nQkSCQJajTEfM1ZhWhWHS7HtPaBUJYBadZhbfSvm0VWHfuOKHmjeMOjTmOh/I9Za M9qqScv44RgaYh9UNbNLA+mO3rL3yNWYNiqEIyDPRdX3GarxiWiE3uhjxWgp2g1cnemJ3g6E duOHYGqYhl1aemiLfp6LJlOiSdOR0QmDMFggyiCBFbaJ3anekFiHBdgSYpQIOmtMqpYaKdil KDObkFiwfjJyLZO4eKrOcawbqoyKSat3xVe29jaFNeu/bhnnNB9yzc2XDVgyHuscGja1LiK0 PqG1BluuhqC8xZau7mtYRmyvBqHGll2imRjzeaerXSM9E5OrnYudPiTuDWv3/2Daf9pgPMsn GoLtiz1tob1Y7YAO294TFdIjHoOc1x5jnm4IerntghiosC0zmbEOA0HtRBru1k6rMzJu8U1r 2JbcTNPscZon+nBu7pkT49XuJ8Ft074l3H2RVQrrT7IfjVnuyHXcJWklvz1uRKNv8MYm93Zp dejUSYncTtsdwQ2mZYIl/LbejaVvBEcYaAmSb5Gx1rhSUIJa3IUy306O/Q7e7d6zy3VT7+5t x4JvkYhwrmbvMXZv9C7tTENXBwm2okFXsTCABuoSnx1aAfbw6A1xyNLe4egSHU/vtvpugTpf OEKK8r6n4v7xDZY1G84iyR0qCS+LHXlx6qanW6jxuP8yLB7X8TZq8oOV3GleE3r6MFNCjOXt FR1ncf725lQJYr264KMxlglS7kcu7A8iqSV+qTwHFTd1UMJu8T1XYiljuJ+Z0oYK9NTFGaGq 86joJ351LFm+tXhFAEinlrB0sjsaFvuJ89J69KC480L3c4EJNwyWbD1f8DdPpD7vlXUBkmhD EGMJqSVWrkH/I7/y4kleI44JdHNpY4oWs4yaZDBeETTGG45AzWHnb17iHbZaJ9/97mMvVu7y NMuSOMTyqpK5cGQvrSPVYjUmGSfHN2/Wa8QSnID5dS7hpY1G42dvK4px9yde6vw2dt9eZEnm 6Cr+oy/mG2RWIGaecXYD+JT/e8lkNhsGC/B2K/hddviHh/iIl/iJz+RbRy+EjzJ1bptgZpqG X+aPNxp5DpzTLBcfZeeUsNLPsud/HuCMX9c+LRq8aWNF6awFMXmNx49qHtCSR+R1VhirSaJy fmORrxn0vPmKL4mUx3mk/7CWZ3rQyFT4OvrrLYkVxviT4OejedSAPtiTVyt8fvpj4xQnfZLV kS+pp2Qlzed/xjCuj+aoV6upPy6rF2eWD0Wi35Q2uF/yNNNuVlWont9GRiwXC2OR6WlTvVUY szcZ91pQZaJgj2qY2mkHOnxVjVbDUtXtQWltemq/AnxfJdX9Gei9Fx6IzpiN+ehkRaYrUerP Dyzi/pjq5qnqoiYSvReLVAN3v8fKDN3WnRn8li78nqn88TlqxY9MvCeSJDKDWoAsE7LxMPZ0 wR5dPm3r331+se5XGMIQcdtXSc/zNYrlw1Bs0BbtJCM1fl0FxcZsTNJrr55yyh9gJCqN5acM DFpbwwILt24osd/szO7s7AQIdf8G/vsl6Z8JgbcgFVSQoOFDgr+ERBz4S5Cvg2ZqCao4MYG9 Cg8NQhyY8N9CghY7ErRH5KEJcCpjSpQUcuRBhAoZ/nKIkqG9KhUtUiSp8ijSpEkvIqhSj9LF ikETRC140Ki9Ag9dDq060F4AkFpbjrUoqSrJrFtfGk0r9OhUowNThgRA/oBqTq4G0eZU2RMA AJwGEWjlqvaf3r4SWdJsm/el2sSOEZelvLbrY5Bv/Qpq+jTqYa4/KeAk7DGz0sURJ4d+efRv YKumEbPNKffr5pWeobLETZUlSaxjRatuGfbw18p7gR9sjdcs4ty+b6euvrTjGynqqr4BDCRB SqviGwIG8J2zVLa9C643GD64gvLfWefubv55cfbgGSIW6Z4/SfbxN9d8Zx1kwn7keYefX/EB AGBO4d2EUIJ72XZVew7ep5KEIk31GnbaRQXbhgjJZJVXP30lknVeTUbieUndUiCM+MllX4wr JZDddizhmKB4bWmYo34tqedRe5K8d9WQNjZX/t+C1Fk3pY4fRXXLXXFdOB5ySE04110pimkg dF2O51ZEWGrGIGJhVcmSZFsqdZOFKIHzxlaVjYeeX7bB6dotdwq2ZYpm8mmYdPpZ2ZGhtxjA 4nJIXtZib6zpOad/ksxWE3QoZSndiEV1pKaW0Ak3lEpfevqbpDVZilmZm5EqlJRUUirpGzJ9 JNobPPV10j+moPrGXW0KFNKJ/SU7mGu9miRQsE6aFFGuBRWl2D/EjsQoiykx+5CzHEJrJZku SRIRsMJKmSKX3fJn7qBlVpCsTgMJm6q70aEqJmPQCsuVmgYh21K+CA0I4mpypjvULeNeW2+0 k2WrK0V86ljtrs36/krQwkdpa6yyBC+rqcbP2isthQNh/LCtLfMLUgAPUvHQLYCJclVfdT0o Y3nQ9geYTDqDQ1LNANy8ImAbnxkfJAjEDMnMUtoHwLjxFUu0zdiCtSCKOcUUBdI7r7venn8V axI4q6xSZ7tA/7zza1ZvlejLb0MysMFpVeC22egebLHEOv+99YZ6J31mXk/PbLF+W0NNc9Z7 Cs4zYD4L/fbQBxV9tN2IW8S00zKz2TLppZt+Ouqpq156FGCv/jrsscs+O+2123477rnrvrvu rvP+O/DBCz888cUbf/ztrSO/vO1MMP889NFLPz2VvlN/PfbGN5I9991fb7334Ysf+/bj/pt/ Pvrpq/98+esXf1ut48dvPvw5J9rp8fO7b3qt7ZOu//6yVR569amADQLM2f6HrdPN70N7eh0A cVc/Tr2GTKhzoOqoA8CeJMsECaxOBFNTlZD8TYQLRIqU/KfAAKbmY9FaimI06KMSMs+BIeze BOdCQAqeDoOpu6FfhHCuNn3wdlWhyeyoo8IVstBLbopb4Zh0OD6NSBIlCFN8vvOlhVioBCWa XF2IJB4TVI5g5YGEQbwYozDuy4pRvGJGLtIGwCSAjN+ZmkDSCAQJpGlwMStcFnGioAEhyCSV sxBp5gKUvZ0njWfT2YMcCRJG4kSNq3HQ37pYosW0gWaigBMl/vEWE8OJLZAixM6A/tJIN66y TVwjI9XSeJ/tsdEqV4QZ12piSQGWESG9FB+7+kMzX01Ihtuiik8mlJJAPWsvPgkPEk0WnprQ pR2p2kxPhinNTPrEWdlEkQIUEptpWumZJyokwY4FmXwJDFJ5GUs1LcTMep3EWz655iXRtZOS 0MWdFfzmNFeSkX9spF8qAgurSBJNZdJwJbYYEEP5ScwKqDNB9mjHN8NVT54kk6K06cozD/aR apqvn3bBj2SYgzATee6jkanNq8gyKWrS0IZbco4BE2MWicmlVJYx0whr8xWYqtROinSVpgoD meEIFS7YfOdlXlRUpOJPN07hjVgm/rWQRA5GOahZCtMoqNMgneVPQDoTo5hqI7Ma8DZTCaj8 KjWqd2VqSVCEm1E6BJMKWTA4GZIPZnQ2FJuaqkk5bSrbJvMjuSSkWhx610v0+p9OvQFagq0T guwJWCkRVkH3mYxd+yQx1fBoRIZlKYrWo1elMCUA0JIsoZQE2UnS8VQ1yuts25qTHwnWfAh9 U1T7ii12tYWtgcJT10y1HkPxMFy+6VRaLkXBKu5UTu75FIMMsrjDsuqjiX3SsNBIpuPmCVZO TVhyzBscOVH1gYoSVVaP4ih31o04KOzIN4MqLbbZt1fFje90vwpdzWGXIM4V38dAw06SgSuT ZMNKweCV/1zx4M1kL6yJK2hGQHRKrGMUxNiFeCoJN1CMQSR04kgoEtFvZUtp/3iFhuskYYip 64Qc/pW/pMWrTAp3pTqiMUgiGyabzItg2jTYSrW14tg6LcUJgLGdjILEhWHFTR/R7cSs9WQN ow+PnzupeDY33Af3pW8cO9F3wxa0vcGNmgjcF9MCx2ZuTtExIg7d426DTvkCBgrAkVuYI9cw ghRtyFJO1uRq9RfxmlFschLzP9n74x8LTpSMvpyZkWwxDyITzC/SXJ9H9WbYQHTOeyqan9Xb HMWB581NfHXsgFg65hqwZXuG9f5kPSVd47rXsT4h7ByLFFgW0Tq09nX4iI0q1P4pG9nOfja0 oy3taVO72ta+Nrazre1tc7vb3v42uMP96+v5UNy1Xh2vzW3ucjNwuCdk96zZTEdXJpCU895a EdUEw6TAu4f3S6JNngpCTLYI2KUj0bKL52V1467fTJySw22lKmEaVYcUN3LFVRdx0m0cdp3l 9xPvZULYVUXfyPuYPSjB8AtS0pb3geQi35illg8y0paEOXnEuHCMy7RIKZv4YVJUs6uZUpNa lHep+/izVd4c6Z++ZS05dM5zbkcSFDijLMVYKBapiNQuX2MouR5Q/S4dXWVUpSDJCnVTR91I cJZ5Rna58nrZU5sY3GhJ6L7ItLsqpPpa0ZFRWLFGx/8GLXAajryP6XMdLRmgQLnfPE+Cd8f/ 3XPf1HsFo3MuLdnQ76lyrdSnVUwmHRnvke/KDLd50HYsubDoohfeGUfxupfkwOtWK30i4pxT eXeq1Y0Vej/K73+jZD7G3eGMumtfRWUmzex+aXzHiqYBc0mt+PyFOPCkFoEJ3L0KKu/2VRpT wxRGT7A5kXPI2fzYprfny4crVhArYHPf9qbYbJKQABva9k5fRRc3cC55iX8Ah4/4jJEZHuoB CZ30GLxlFkdtlv0F33p9WQBOC54ECvZZRWfNT/LpRLXY1YsYVmMRUFSES40IFmyZip94xGmB CcPQFcosn7gBVQS2n1iZn6T/TVj/kR2hFRjIxRdo3A9CBd2D4ZdZOd+/kZdlYJkNiR9UpUbD CEVW2EIeBZwEGtzoLc6nlcmlaNe+cMuxSFeL6RdfoJVUiKHwFYf0reDcUZnCVIQbckyO7Vik dQo6RZRKrAzDnIizKJOu9MU89WG3nMgWMN6CdVjCzVgcjgeHVYwJuJiHSYQUeM0QKdQVypfD bEUF5JY3KUyO9UcJoYUj5hiUBcqKOaLSVBiQeUyxpFzrjYdjPaK6JZp1hRUtNhp/QJpo1WIp gdnnic4B+SK+0YzPwMYjxUwRoQWgpRl5lNBCmRpPhZV9sALO4KIAvtbVSBGjuRfh5MieQZqc TVHK//iYkplaoY0EoPESNUoOm62ZOOZheaCjp9kGwZlEQ81dtN1a6cDVLKIhx/mj+qQbPvra sbWIAoiRugmb6ihkEwnkQD4kREakRE4kRVakRV4kRmakRm4kR3Yk77iQR94OWBggyRkc8Thk SE6PMpbHqGFShcmigR1MQpAIAAxNOFWJhiCQL8hVp80bTZIgwf2WyqCRhoTXTJAkWI0L2fSQ a2hc90ncHxURJMXGMH4FMraR6XScsT1Ri/2QSabGibVMWD4bsOSHUP6LlRWh7h1JEFVie/Ak cK1KMBlHRNzLexghzXyQV8jgUgiR4q0OQ2blU1LJL7DDUMIF1wGeUflh5v/NGvGRzl0mnO78 ghQMHmFWpmQ2kQy6yFJiCQIkpmJ2XRFS4eJx5mrgZe+hiizOpeTlEVvxHD9eB2mOUMtFHtX5 EtXYoEQUHSsNltP1JtIgZH6EZvuBxlgQF3CWXdhAwtUljRv0jC3N3CYdJcSgnVUezqclUteZ ElJUFrCMVh6qQ1l2Y2bSzwLtJejhS5vlIR+6JuohQCV016SZJnfwxFLK4kje10AVie1lWbYg 5XXAZ3dN3pNsnlCQVOUpJu3BVeeV3j4phe1BkuKNCAGClIP630LRTVHcU+yByH5G1OhZnpJQ HR5en3UtkE+FREWx0DwxDmx4hGWix4fQJKs0TN3/+JxpuY1nxUYwDkV3XJKOIoxWXkmPRB9k 0Er2ZRU/3lr8oUxLdF90zRRccCVSJB8Zvib1OUeXlFuKWl938miTluGnmcZYbSZ4tVQBzSiW uk+LDiehxQgZ1VSmTBrjVcJOtgqO4qUJLqWM5Ihp9qcwSc07goad4pcI7gh4DI04vA0cviDg gWflhSBgORGAHmCFIiCW3dZyQcln0eOk3pfSCRMIsp8D+t/E8dLZbYmAoGpuSkhT5tp58ilD OQ2A5kpl0WmR3MIn4Sl9guHigWVimqaKJoWtViqoosSuNoo6SGEBkGZMPpcayt95Zak/CiVY HsdxptVfUmsCPmmaYBfv/4EQXOqF+DmhnSAXD0KrX/GdulZjGu7PZvbGoGmZaJhcn2wXcYFS vfXGl2AMcMDXUcjivF7ZfP4rTKSSJGzXrukrTHwiZVLiQ5Qi+unJK0rJjdnhJ9JlwDJEIO7d Yg5iY0rZHBYZx1BLiTFWxvoYiLqJt6AihRHBEJUo/uiFy9aaYVhZjLpPWU4aeb5kCY3lT3qF vRbKHwFIbxCLL+SkTODnHxGJaarMXcAkKLqMvLaiqfUHNkKOLwammUFqM4bjeqIESwbGbxmj 7l3ldSajnEwO5jQjnkVNzlztsX7Z2aDabgHGOh7abvqigcGeQEwjtihkPYVaedIPn6bk7PAl 8v+g5Pow7mR+5fmAJOImbnpGz61em+PaTrNNLud2rud+LuiGruiOLumWrumeLuqmrkqkgOq2 ruu+LuzGruzOLu3Wru3eLu7mru7uLu/2ru/+LvAGr/AO7+/QAvHqLjwcr/IuL/M2r/M+L/RG r/ROL/VWr/VeL/Zmr/D8QgmwwuRyr/cuRfeiDvhqb1aWwACk7wAU7uu8wPpSyR0MgGFOifuu xvjayi8MABlshQvI7+rE7/zOGvqqb0QAcFLUb1IYMFIgsHXEb/qSQkHcL0EAcPkykARrXP8+ 8EAwsFJwsMShbwC7LwTbigLjoz2UwP7aQ/+yr+p4MOwwcAVTiQr7L/f/jnDxnPD+/oP7BnAH vy/puPAC+68Ks0MMv8YF/88R9xAKj0QJPAQQq8QTV8cJ6y8TD4ANeyQOPwQFy+8vQPAUUzFi oHALpK/9pq9h5i8Rk4IdqK/65nAN+wUXd+8Y+/AEszEpgO8cl7H/wjEEI/AX53AEtzFVjK8K 72/+ssIKF8QAeO8fo0oWI8YKo7EOqy87OPADo3EXS3L+pi8rWLIVs9YnfwVGyTEZKzIRk/L7 lm8hDzIBRzAr5LErQ7IhDzAdW8QiS0QCePId07IW23Eg7zG/lQAptIAWt4IwW8QAs8MMn/Ei a7L6MvIAA/K2PfIWs4Ewq7ILpPASz/AgG2b8/1LFAFhzH/swApewKXOvNl/xBvswOoPEMXOv N9fyDCPAOxNyNg+yF98zNhuy/H7zP3zzPg/WEq8zEfdzKlsTDIfzNXPxLdvDPUxyeZpzBKfz OW9zPTOyPltTFrfzCUNwQP+CRg+0RFAyFLNzSOcwDJdAPEtmR/8CKyBAGfhCPa80DiOAC3g0 QzPyPQQ0t2XxFINz+PrzP69vRw/ENyMwJt/yOtsvK6wyHJ8yRkvzUiNzVCcAUgOzLZvxUBfw +vrzKn90HDf1PQu1UH+FSG8xO7hv+E61IocvGntwFBO0EVc1JtvzLFd1SQ8yXdv1ULiw+woy RAexE5NzKmN1qggzPf+3Aiu88VUzcym/NR2TdS0fjzsYzxc/9h4LNRoXtSn/9TNLMlsXskyv tS1DtSyjSkpXtWdzMlz0bw5rtvz6sT7z9WZnMz17L2zz8CNDdF23ckLPL2T39WQfhUSDtWl/ NV9PMgF/dHKvdsJxr1ZzsHMHtnI/85wcM0Af82or9Q6XNgfndk+LdGkbtQ9/M2cfdS2DNnUr cik/NU/nNVWfdlwPdVCXd1e/L3LTtf/Gbyu8r2QLdA5zs3qrNXWDdnDDtwiFMmKMsn4f92yr 9vvWL3ND+GAzTEXEr/cyMAJvOGGzL2cj8zjvSysfOHlzNQs/226PdxhXdVFv9P2CtHqX9RT/ q3NF47VKaDZtv7g1EbdSn/BeQzNFbzQNo2+AJ3dLDHR3ozG6qvRWq3hSM7IrNHkYS/UkG+YQ G3dAt/gS16+A87WW7y+XJ3Id869/dzg3S3kFg3SKh/EVv3Gasx5iv3NOI4Yr3PZpf7i1rbl6 N3IYA/YvM3QAz3Aod/drhPVpt/YlJzd0azWPrzWfD7X+tsBrpy8ZSDo4W3n/Ono0OzIts3Ns WzckX/IeOzNrC/ou83AdazCWJ7cDV/osR/r68nSrWzp0V7o8ZzAYh7oV1/oYk/knL3ocozqe v/GfI3KZLzYNWzef4/lDMrsSDzf3OHUA3QGNmxu1B6+z849Sj4+0/7uPCp+4tn27+Y67sxkB uZ+7+5g7uvdaNEivuq87vIvPu8c7vWfPvNc7vue7vu87v5sPPbSMEvS7wA88wRe8wR88wie8 wi88wze8wz88xEf8876BxFe8dVC8xWc8sWq86rAAwWM8x3M8yId8+txCAOy47I78tZ1AALS8 yv1Cy8f8PTRAzMc8qrB8y5PDXLT8Q7C8VNB8zQfAPQSAa9hDA7wEzgdAASCGBcT80iNF0us8 SvD8P/g8zNc8yk+9m/j8QER91598QRA9uASA1FtE0I9E0LeDyce8ylV9zEu90df80199zGd9 0gd9zJeCm9hD07f8038F0Nd8z7+9Sng9XP4cvSPT/NPHfdAPPda7fdkHkMpXG9+DvdFjlNJ3 J9l7SdPTTACo3NrrPNd7zOaHfdEjfrZ8PmKgPswPVudPPejnvNtTRebLiOz7fOV7vsq9weav /eBnPcwvvckvffBziOp/xeubvMoZfbOofvFD6PGnvtT/QhGABOtTqcqUfu7DPtOzbPQD/qvu PNUbWOk/P/lH/v5MPrXxftsXBOb//flX6fHnvsmTQiHMvuZPv9ivfvPHfvv/AkAk+Dfw360A lAbasxAggUFShf6dYPgrQAGCFwsGeBiRoUGE/xROPPjvTYAA7RQSEUiQokWKKlte9EhwJsiF Cew1UJnRZUWMF/5LfiQZgBzGmv9+rQRKdGDNkA1H2mR4MedOgiltRR1YsihSn0u7/hQ7lmxZ s2fRplW7lm1btBLbYYyJketPiWHvGiR3IoFEpQTret1ZVWDQjCbDXrxLMC9Rvn7n/tT7mOHi gXdzWjxBqQK5zHJ9zoycUahljp51Clw8mq7WwDRNMh0b2PTd2rITpr5IkVJKpYFZl4zrlnhx 48eRJ1+7EGUDk+0oxrb6mjFurnpvUTIxtXXX6LED7DTMUfpf09eJZt+e4Hv4v9i1V7bO9AQR BA3anShAMbFX8HHbU8mg2PKbDzXwVgrwr6GEou4y8KwC68GwuDoPN5B0A+ykoYYbyv47CAvb ULkRSSzRRBPh2uok1jy0C7fGPCuiAu4kFEwgwhjcLbbEbiNHL3tkFMkisX4Msq8XmSrpno6I cEVElnwKCbqvmtKqR8LGY1HDBi/UEbGfaENyLzGpytCmwRrg8sMhYevwxDfhjFPOLVWckk0N +yMtoZv0Im/BFm3EULyRXvlNKz2lgqooiYQcq09GofroqYyqgCmAKmgcaC6uRjvKqZsIk9Kr O1tTE6NC6eyuSkn5jGrSq8wcEDzugKNyzltxzVW5nDYUjkUHE9WzzwH/rBXNQREq6cabqGJ2 pmFNYs9WmZgidlKnnLOIV1JHlcpOaoW6diQco5OW21QB1f5w2UxV7EpchN7FCMcHO+wTUNZM 01Xfffm9aiGTevqv3bEYla1PXouV7aUbUyu4AAT+dU+sgrs62DlpBYatKIQf/HLPcRcSCkqB 2zvpqI5lm7ckIrLKGOUhHQzJpAhrRJnHHX/iNTYqJM4NZoVnjSvffoku2uijkU5aaTmXWNrp p6GOWuqpqf6p6aqxzlrrrbnueqyrvQ5b7LHJLvtEsM1OW+212S4b7bbhjlvuuYt+m+678c5b 7735dnouiT4qGKGSDQUYI4elMtxFkwaf9R7nZo181gKI5WglweWFXPGSh9sWVoENGmwhdzWP TTWcxSpJcQypnElUmX3iPOdsyf9SnUqKc0NSW+fwuh1nnSX/CvfDTj89z76LjskgbZnD8Nvl J7SpP8PIzfR1/H698DXDBlyUoevdxNEwFmVdCUfMRu9W1WBPjl6hik1f1dvqzS2r/ImZej9e XneKbneJ/cc+18wHXs4aSfcsl66x6AB5uWrJfaYyHqR8a2HQS0g5SoUopPxFgr/41voGpiKE OAQifulg+HQDPdZgxVW6eQr0UrS+T2XKgiDBIAs/4jrmHCUpWtoTyw5VJTbZoxwzxEkDClCC uLyhFFFCohJJ0kSLGDGEOTIiCRMIrAb2qyUlkE0MoTTFkWiRTrI6Hhg1NS0Fbu+AjjnSkdyU uZ2sZlr+vPGNoC5HlJDUA4mp+yKZ8PQTO1pgJzo0GerUJ5ZB0kyBp6kOaihHCQQUISu7i+Qk K+nI6KXLMD2azBs5tEWktWddzXmO7IaWQfLMTClS0tmUylNFTrbRR/FJAHNeWSYEpTGWwgml yqqFyBpZ6GZ58qUvDSk0ECmoNUt80iYfiafM3KcUlIjJNBtQzZgQs4qdNBB81hNKURotOpga Ugx9FSXmkFGEXroQOlekRuqwcYR6NBI8UaiSLNnqjjmBV4ZSFBJGhrBHNfshw+pZwCd9hxw+ 7GeaQAhNzPRRWdekaKMKOkuEeNKeMxKIQeI4zn09kHc54tCm0kMlImYQVe3+TFU6uTVPAmbE ewwZjy9hpRJRdUpyRxQdrYIYSES9SohXKWJPDZmAljLIh7LaJWyGeFRWfa+PYcTQnZTnKmZp dKitqumfRMrF0LiHV878lqgW874MKitYnzNr9hJDT5oSr6zizE3/ojUaMP5INxYSWY3idbj8 WWBM9dJjaj7D1qf4cK9dSith91fVNFpSR8ybylHkGi9oTSWVYXWg8NQZm4ARSEOrexnEYimv iI32ObIME8AsNhXYkQqYQATP4yKETZeZFEzvFOZSAHaf3PZRZz9lpX9Ie9dWSra0vvPYZ6wK 3clWx2MEFa3NqrSxi2nSs9317nfBG17xjpe85TX/73m9lgr0rpe97XXve+EbX/nOl771te99 6fsJ/Mo3RQsDlOdYN6sQGc6/80JZ8MxXOpPwETx3AnCAW4vcCCsGdZXzy+ccJzHCJBN4Kl0t hJ8J4NCtKzGzlfBJOmzKDP+HV71j7VQ412FuObW1nd3viepiYRHdT6iOfF+BzeTSRgpVfFrh 8fmY4lAD1pM+7LqXhlPDYd1QTzcU8anxYBMtqRRlNPTrMmKb92QHOwevsRtrT8aMLLJwjJ03 JhFvhoJiQi4LiCILTA2JCGRGSpCMgcGRBXGo3EQ1Vasd0UgJnWwshgkIZChO4ViFkhQcTSrQ POGIm3hYv5yGqCu1GnMS/pcoxW4t7MuFVGN1PtJmN++qj5vpDHQXaahOd0nPC+Jzl4jcV6D1 Zs54nBBjxfTJC6+v1lKeYzCrOy868vqnfCSVGa26aUB5ukyXpKSZxdi4NGNZkT3D6arjVJ/7 5Gc/sjnmk8LUn5L1DF19TlnpDGVWX3uImdFsFzgTDbRZMVqhKtbygXWaobqcezjQFmx5FBSq 7T65PNjUpplJBqIOgxWa3wb3m5TEJCfF5aGmamStVTnkEGJJq2j6p1XgAuze+aij+f7QsSI1 v9RIkJeHRbmcTf6xgda8ofyEt1C/bJGKYttbpU4AzXUUIZBePE4GqZS0MPXRnoYQz+UA+VI8 /t5b0um0eTSO1qRvQuipKspPWk8jzJMaquYtNSjCXRdUIrcSpP+D7QcxutkTedXKqo9TPuf6 M+3NdFx5DsCNnfXKpXf1duN65FWOluGRzOVTC7CeRakcsaEc8IDvrsxHly2odO09w876r0N5 +90x/+m9X5M5dy+XUdjNXcGXKCQKPflyfxbX6yp+lbmfzbunk9qrQjC5sju4wfK38BqBvLiL lnt4UHvcFM9b77z1VyxjHOQQZh+rECdt9oOf2/RR+HizN//50Z9+9a//OGFg//vhH3/5z5/+ 9bf//fGff/3vn//99///ATAABXAACbAADZBfPOEAFXABGbABHfABKCEwAiVwAimwAi3wAjEw AzVwAzmwAz3wA0EwBEVwBEmwBE3wBOkvIAAAIfkEAA0AAAAsAAAAAMQB+AEHCP4A/wkcSLCg wYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIk2pkpbSp06c0j0GdSrWq1atYs2rdyrWr169gw4odS7as 2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy 5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4c+vezbu3Whq+g0MFLry4 UuLGkxdFrrw5UObOowu8hhO6dOXUr2u3mX2795jdv/6LZxl+8bnxb8ujX09SPfv3H93Dn0+/ vv37+PPr38+/v///AAYo4IAEFmjggQgmqOCCDDbo4IMQRijhhBRW+JcXFsLnBYYZssdhh+ht COJ6H474nYgmildiipFlwOKLMMYo44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSRSCap5JJM Nunkk1BGKeWUVFZp5ZVYZqnlllx26eWXYIYp5phklmnmmWimqeaabLbp5ptwxinnnHTWaaeb 2typ55589unnn3v5AuighHKFT6GICkhNoow26uijkHZ5R6Rh5kDppZi2ZU2mnHbq6aeghrqe EqKeRWqpZJ2K6liqrhpWq/+ufgVrrFzNSutWtt6aVa66XsVrr8AGK+ywxBbL3gbIboDeeR0q a+yzbM4D7bRqCkrttUMNgu223Hbr7bfghivuuOSWa+656Kar7rrstuvuu/DGK++89NZr7734 5qvvvvz26++/AAcs8MAEF2zwwbdy8RgACDfs8MMQRyzxxBRXSUvF31GA8cYcd+wxT1Z8LPLI JJdsMqjRnKzyyiw/xkTLMEMJRcw012zzzTjnrPPOPPfs889ABy300EQXbfTRSCet9NJMN+30 01BHLfXUVFdt9dVY+8hJ1lwjlkjXYIct9thkl222yIeerbafCdjctts3v12z3DTTLSQstNkN s97+LfPNst9rB87zF9GtKPjhiGukbeKMQ7hp4/2CQvQVkFdu+eWYZ6755px37vnnoIcu+uik l276TiScrvrqrLfu+uuwx35QILLXbvvtuOeu++689+7778AHL/zwC46iJwKAGU+z8jEzD7Pz LUPPsvQrU6+y9Sdjb7L2xHfv/ffgywZD+OSXb/756L84S/pkhmyz+zTDH7P87Ndv//274YGT DTDRTqn+NANgzASYplXg74AIpJUrEsjABjrwgRCMoAQnSMEKWvCCagkGBjfIwQ568IMgDKEI 7SOEEZrwhChMoQrPZYgVuvCFppEGDGdIwxra8IY4zKEOd8hDALWih0AqDKIQh0jEIhrxiEgE kROSyMQmOnFB5qBNLp5IxSpa8YpYzKIWt8hF8wUEACH5BAAaAAAALAAAAADEAfgBBwj+AP8J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mix48VmHkOKHEmypMmTKFOS1KaypcuXMGPK nEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHkxYpJvCiBMrXsy4sePHkCNL nky5smXCHS5r3sy5s2ehcz6LHk26tOnTqMuySs26tevXsGPLnk27tu3buHPr3s37bJTewIML H05cuJbiyJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr3793f1 wZ9Pv779+/jz69+fEAX//wAGKOCABBZo4IEIJqjgggyKF8lggDQo4YQUVmjhhRhmqOGGHHbo 4YcghijiiCSWaOKJKKao4oostujiizDGKOOM+OFBI2p45Kijjjf26OOPQAYpJE6dDGnkkaW1 gOSSTDYZFiNOjgZllJ5NSWVnVl65WZZaXsZllx7+AuaYZJaJXTFmpqnmmmy26eabcMYp55x0 1mnnnXjmqeeefCbVT5+ABirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aV7gYPpppx26umn oIYq6qjbOUPqqaimqup2R6zq6qv/sMYq66y01mrrrbjaqUJ4ZOTq66/ABivssMQWa+yxyJKG haXekLVsVbyg2KxYz146LVjVWhtWttZeyxW3wK0wIrjJ3kRuuTWdi+5M6q7r7rvwxivvvPTW a++9+Oar776QhXNXr4L6y+9JAg9cUsEGEzQARwgnPNDCGjVMVhF1QuwwSRY7t8fFHHfs8ccg hyzyyCSXbPLJKKes8sost+zyyzAji0TMNNds880456zzzjz3LBIEPgct9NBEF2300UgnrfTS TDft9NNQE1eJsDtEbTVBL1yt9dZcd+3112CHLfbYZBd7QNnryoL22my37fbbcMct99x01y23 O3Yzl0ze/nz37fffgAcu+OCEF2744YgnrvjiMsLA+OOQRy45c19ObvnlmGeu+eacd+7556CH LvropJdu+umop6766qy37vrrsMcu++y012777bjnrvvuvPfu++/ABy+8njwMb/zxyCe/0wfK N+/889BHL/301Fdv/fXY035F9tx37/33HqYA/vjkl2/++einr/767LfvdCHuxy///HYnIHQC 9geNv4KQdLe/WHvbTP+8kz8DDZB+CWMBAhfIwAZqZBUOjKAEJ0jBClrwghjMoAY3yMGLwKOD PnEECEdIwhKa8IQmeQYKV8hC4AVCaIF4YQtnSMMaOqVVNsyhDnfIwx768IdADAyiEIdIxCIa MXQBAQA7 ------=_NextPart_000_000D_01C6D28C.17ADD340-- From owner-ccamp@ops.ietf.org Thu Sep 07 18:58:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLSpO-0001Zv-2X for ccamp-archive@ietf.org; Thu, 07 Sep 2006 18:58:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLSow-0004Qc-AI for ccamp-archive@ietf.org; Thu, 07 Sep 2006 18:58:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLShB-0007HI-No for ccamp-data@psg.com; Thu, 07 Sep 2006 22:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLSh9-0007GI-4Q for ccamp@ops.ietf.org; Thu, 07 Sep 2006 22:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 449392AC9B; Thu, 7 Sep 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GLSh8-00050d-1B; Thu, 07 Sep 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-00.txt Message-Id: Date: Thu, 07 Sep 2006 18:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Graceful Shutdown in GMPLS Traffic Engineering Networks Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-00.txt Pages : 9 Date : 2006-9-7 GMPLS-TE Graceful shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. GMPLS-TE graceful shutdown mechanisms are tailored towards addressing the planned outage in the network. This document provides requirements and protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable for both MPLS and its GMPLS extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-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-ccamp-mpls-graceful-shutdown-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-ccamp-mpls-graceful-shutdown-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-9-7152708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-graceful-shutdown-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-7152708.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Sep 08 10:58:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhoP-0002jV-Dv for ccamp-archive@ietf.org; Fri, 08 Sep 2006 10:58:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLho2-0002YQ-7t for ccamp-archive@ietf.org; Fri, 08 Sep 2006 10:58:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgE-000I9n-Cs for ccamp-data@psg.com; Fri, 08 Sep 2006 14:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgD-000I9R-Ov for ccamp@ops.ietf.org; Fri, 08 Sep 2006 14:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1AD7C26E52; Fri, 8 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GLhg9-0000Ua-Ua; Fri, 08 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-00.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-gmpls-vcat-lcas-00.txt Pages : 14 Date : 2006-9-8 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to the Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-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-ccamp-gmpls-vcat-lcas-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-ccamp-gmpls-vcat-lcas-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-9-8055726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-vcat-lcas-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8055726.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Sep 08 10:58:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhoP-0002jT-98 for ccamp-archive@ietf.org; Fri, 08 Sep 2006 10:58:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLho2-0002YP-7t for ccamp-archive@ietf.org; Fri, 08 Sep 2006 10:58:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgD-000I9V-ON for ccamp-data@psg.com; Fri, 08 Sep 2006 14:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgD-000I9D-0Y for ccamp@ops.ietf.org; Fri, 08 Sep 2006 14:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0F8AD2AC9C; Fri, 8 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GLhg9-0000UF-PY; Fri, 08 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-11.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-tc-mib-11.txt Pages : 9 Date : 2006-9-8 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.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-ccamp-gmpls-tc-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-8053019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8053019.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Sep 08 11:00:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLhqK-0004nk-Dz for ccamp-archive@ietf.org; Fri, 08 Sep 2006 11:00:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhq3-0002re-4R for ccamp-archive@ietf.org; Fri, 08 Sep 2006 11:00:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgJ-000IC0-UP for ccamp-data@psg.com; Fri, 08 Sep 2006 14:50:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.24.138] (helo=ns3.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgB-000I8F-5I for ccamp@ops.ietf.org; Fri, 08 Sep 2006 14:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 318BE175DB; Fri, 8 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GLhg9-0000U9-O7; Fri, 08 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-16.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-16.txt Pages : 59 Date : 2006-9-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-16.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-ccamp-gmpls-te-mib-16.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-ccamp-gmpls-te-mib-16.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-9-8052720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8052720.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Sep 08 15:20:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLltb-0004WA-Vy for ccamp-archive@ietf.org; Fri, 08 Sep 2006 15:20:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLhzx-0004Pn-Ld for ccamp-archive@ietf.org; Fri, 08 Sep 2006 11:10:29 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GLhnY-0006HX-QX for ccamp-archive@ietf.org; Fri, 08 Sep 2006 10:57:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgB-000I98-GG for ccamp-data@psg.com; Fri, 08 Sep 2006 14:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GLhgA-000I85-NR for ccamp@ops.ietf.org; Fri, 08 Sep 2006 14:50:02 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id EFD9426E50; Fri, 8 Sep 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GLhg9-0000UL-Qx; Fri, 08 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-15.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.2 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS)Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-15.txt Pages : 42 Date : 2006-9-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-15.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-ccamp-gmpls-lsr-mib-15.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-ccamp-gmpls-lsr-mib-15.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-9-8053424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8053424.I-D@ietf.org> --OtherAccess-- --NextPart-- From dentmadison@daci.com Sat Sep 09 13:16:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM6Rv-000357-DW for ccamp-archive@megatron.ietf.org; Sat, 09 Sep 2006 13:16:59 -0400 Received: from anantes-251-1-26-78.w83-195.abo.wanadoo.fr ([83.195.217.78] helo=daci.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GM6Rt-0006BW-Rf for ccamp-archive@megatron.ietf.org; Sat, 09 Sep 2006 13:16:59 -0400 Message-ID: <000001c6d433$c447d3a0$06aaa8c0@ecgnsu> Reply-To: "Astrid Dickson" From: "Astrid Dickson" To: ccamp-archive@megatron.ietf.org Subject: Re: PHAjypRMACY Date: Sat, 9 Sep 2006 10:17:02 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6D3F9.17E8FBA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D3F9.17E8FBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 All yo y ur P n HAR n MAC w Y di a rec m tl c y from the m s anu t fac o tur h er, Your c p han o ce to e y cono h mi o ze up b to 50 v % wit y h http://www.kazunjadewunjax.com ------=_NextPart_000_0001_01C6D3F9.17E8FBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
All yo y ur = P n HAR n MAC w Y di a rec m tl c y from the m s anu t fac o tur h er,
Your c p = han o ce to = e y cono h mi o ze up b to 50 v % wit y h http://www.kazunjadewunjax.com
------=_NextPart_000_0001_01C6D3F9.17E8FBA0-- From ottosei00@ocn.ne.jp Tue Sep 12 00:05:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMzWh-0006YU-BW for CCAMP-ARCHIVE@MEGATRON.IETF.ORG; Tue, 12 Sep 2006 00:05:35 -0400 Received: from [222.171.139.46] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMzWe-00018r-SG for CCAMP-ARCHIVE@MEGATRON.IETF.ORG; Tue, 12 Sep 2006 00:05:35 -0400 Received: from nyz1 (unknown [126.188.169.107]) by smtp15 (Coremail) with SMTP id 5jdNgUsL4pVPv1YB.1 for ; Tue, 12 Sep 2006 12:05:32 +0800 (CST) X-Originating-IP: [126.188.169.107] Subject: =?iso-2022-jp?B?GyRCIXklVCU5JUglc0AtM2ghJkZ8QlgkbyRqGyhCIFNFWCA=?= From: =?shift-jis?B?k2OShoFAjUuOcQ==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab $B!!!z(B $B>R2pN(#1#0#0!s$N%;%U%l>R2p=j!z(B $B(.!D!D!D!D!D!D!D!D(/!!!!(B $B!y(B $B=P2q$$(B $B!y(B $B(1!D!D!D!D!D!D!D!D(0(B $B%;%U%l4uK>$N%*%s%J$r40A4>R2p(B!! $B$7$+$bL5NA$G%+%s%?%s"v!!%T%9%H%s@-3h$,B.96%9%?!<%H(B $B!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2(B $B"-(B $B!A!!$?$@$$$^%;%U%lN)8uJdCf$N=w$?$A!!!A"-(B $B!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B $B5p!!F}!!!!!!8=:_$N=w@-?t(B $B!!(B24,311$BL>(B $B#O!!#L(B $B!!!!!!8=:_$N=w@-?t!!(B 25,113$BL>(B $BHk!!L)!!!!!!8=:_$N=w@-?t(B $B!!(B34,926$BL>!!(B $B%9%l%s%@!<(B $B8=:_$N=w@-?t(B 29,920$BL>(B $B3X@8(B $B8=:_$N=w@-?t(B 20,468$BL>(B $B?M!!:J!!!!!!8=:_$N=w@-?t!!!!!!(B $B!!!!!!(B57,931$BL>!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B"-%;!!%U!!%l!!>R!!2p!!>u!!$r!! To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOWI8fUZ+JSIlayVQJSQbKEI=?= =?ISO-2022-JP?B?GyRCJUg+cEpzJV4lLCU4JXMheSVhITwlayVeJSwlOCVzIXkbKEI=?= From: 777pachinkovillage Reply-to: delivery_rt Date: 2006-09-12 14:01:07 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060912133348_cbrd Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 $B"#"#"#"#"#9b3[F|J'$$!#B(!"F|<}(B4$BK|1_0J>e"#"#"#"#"#(B $B(.(,(,(,(,(,(,(,!|Jg=8?M?t8BDj!|(,(,(,(,(,(,(,(/(B $B!!(B $B!!(B $B!!!!!!!!!!!!%W%l%$%9%?%C%U(B $B!!!!!!!!!!6HL33HBg$K$D$-6[5^BgJg=8(B!! $B(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B!!!A2T$27n<}(B100$BK|1_0J>e(B!!$BL\;X$;%Q%A%s%38fEB!A!!!!(B $B!!!!!!!!!!"!5.J}$O:#$N@83h$KK~B-$G$9$+!)"!(B $B!!!!!!!!!!!!!!!!!!"-L4$r8=!$F$J$$$+$HG:$s(B $B$G$$$?$"$kF|9-9p$G%=%U%H%&%(!<%V$N$3$H$rCN$j!"(B $B:G=i$OH>?.H>5?$GLd$$9g$o$;$r$7$^$7$?!#$7$+$7!"%9(B $B%?%C%U$NJ}$N?F@Z$JBP1~!"$o$+$j$d$9$$@bL@$r$J46A[(B $B$G$9!#(B $B!!$=$l$+$i$OIi$1$k$3$H$bL5$/!"Bg9%$-$J%9%m%C%H$r(B $B$7$J$,$iCy6b$bCy$^$k$H$$$&KhF|$G$9!#$3$l$b%=%U%H(B $B%&%(!<%VMM$N$*$+$2$G$9!#$3$l$+$i$b59$7$/$*4j$$$7(B $B$^$9!#(B $B"!%=%U%H%&%(!<%V>pJs4IM}It!!>.NS$+$i(B $B!!E-LZ$5$s!"$$$D$b$J$,$i$*$a$G$H$&$4$6$$$^$9!#M_(B $B$7$,$C$F$$$?#B#M#W#7%7%j!<%:$G$9$,!"$b$7$+$7$F!"(B $B$=$m$=$mGc$($k$N$G$O(B?? $B"-i,i/?'$N?M@8$O$3$A$i"-(B http://softwave.main.jp/ $B"#%7%c%$%K%s%0%9%?!<%W%l%$%9%?%C%U(B $B!!@h7n$N7n<}Nc(B $B#8#6K|(B $B2TF/F|?t#9F|(B $B!{?@F`@n8):_=;(B:$B#2#4:P!!6\Bt$5$s!JpJs4IM}It!!>>Eh$+$i(B $B!!6\Bt$5$s!"@h7n$b%8%c%s%8%c%s%P%j%P%j(B!!$B$*$a$G$H(B $B$&$4$6$$$^$9!##2?ML\$N$*;R$5$s$r?H$4$b$C$F$$$k$+(B $B$i%R%-$,6/$+$C$?$j$7$F(B!? --------------------$B1~Jg;q3J(B-------------------- $B"#CK=w(B $BG/Np(B $B7P83ITLd(B $B"#=i?4e5-$N%W%l%$%9%?%C%U$N3'$5$s$N(B $B$*@<$G$bH=$k$H$*$j!"0l@Z!"Fq$7$$$3$H$d!"0cK!@-$O(B $B$"$j$^$;$s!#$`$7$me?4!W(B $B$^$:$O"-$r%/%j%C%/!*!*(B http://softwave.main.jp/ $B!!3t<02qM;{K\D.(B2-6-8 4$B3,(B $B!!!!!!!!!!!!!!!!!!!!(B0120-197-028 $B!!%a!<%k%^%,%8%s%,ITMW$JJ}$O$3$A$i$^$G(B $B!!(B info_wave1@yahoo.co.jp From owner-ccamp@ops.ietf.org Tue Sep 12 08:47:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7g0-0004Gt-AH for ccamp-archive@ietf.org; Tue, 12 Sep 2006 08:47:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN7fz-0008Q1-12 for ccamp-archive@ietf.org; Tue, 12 Sep 2006 08:47:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GN7XK-0008Mu-Bt for ccamp-data@psg.com; Tue, 12 Sep 2006 12:38:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [12.146.0.143] (helo=falcon.sycamorenet.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GN7XJ-0008Mg-Hi for ccamp@ops.ietf.org; Tue, 12 Sep 2006 12:38:45 +0000 Received: from viper.sycamorenet.com ([10.5.1.105]) by falcon.sycamorenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 08:39:09 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D668.70B66A24" Subject: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 12 Sep 2006 08:39:08 -0400 Message-ID: <0679BA70A2F59E49B186858B47F4595C4E015B@viper.sycamorenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling Thread-Index: AcbWaHExSeMNt+mUQjmXewMnDSPEqg== From: "Pandian, Vijay" To: X-OriginalArrivalTime: 12 Sep 2006 12:39:09.0214 (UTC) FILETIME=[71483BE0:01C6D668] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D668.70B66A24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 What is the rationale behind defining a new C-Type ( C-Type =3D 2, = suggested value, TBA by IANA) for the PROTECTION Object in the e2e draft = instead of extending C-Type =3D 1 defined in rfc3473? =20 Should we consider C-Type =3D 1 as obsolete? =20 Regards, =20 Vijay =20 ------_=_NextPart_001_01C6D668.70B66A24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
What = is the=20 rationale behind defining a new C-Type ( C-Type =3D 2, suggested value, = TBA by=20 IANA) for the PROTECTION Object in the e2e draft instead of=20 extending C-Type =3D 1 defined in rfc3473?
 
Should = we consider=20 C-Type =3D 1 as obsolete?
 
Regards,
 
Vijay
 
------_=_NextPart_001_01C6D668.70B66A24-- From unsprouting@checkmyhouse.com Wed Sep 13 01:12:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNN3D-0004aS-V3 for ccamp-archive@megatron.ietf.org; Wed, 13 Sep 2006 01:12:43 -0400 Received: from [61.19.144.103] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNN3A-0003e7-Op for ccamp-archive@megatron.ietf.org; Wed, 13 Sep 2006 01:12:43 -0400 Message-ID: <000001c6d6f3$171fe100$0100007f@localhost> From: "Cordelie Rivers" To: Subject: Charges for Medicare Confirmed. View Invoice #67766 Date: Wed, 13 Sep 2006 12:12:39 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C6D6F3.171FE100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.6 (++++) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D6F3.171FE100 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C6D6F3.171FE100" ------=_NextPart_001_000E_01C6D6F3.171FE100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Your signature on attached form confirms our receipt of payment. ------=_NextPart_000_0001_01C6D6F3.171FE100 Content-Type: application/msword; name="Invoice67766.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Invoice67766.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKgAAAAAA AAAAEAAALAAAAAEAAAD+////AAAAACkAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA 2AgAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALhAAABM6AQATOgEA2AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAJIEAAAAAAAAkgQAAJIEAAAAAAAAkgQAAAAAAACSBAAA AAAAAJIEAAAAAAAAkgQAABQAAAAAAAAAAAAAAMwEAAC0AAAACAcAAAAAAAAIBwAAAAAAAAgH AAAAAAAACAcAAAwAAAAUBwAADAAAAIAFAAAAAAAAegkAAOwAAAAsBwAAFgAAAEIHAAAAAAAA QgcAAAAAAABCBwAAAAAAAEIHAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA+QgAAAIA AAD7CAAAAAAAAPsIAAAAAAAA+wgAAAAAAAD7CAAAAAAAAPsIAAAAAAAA+wgAACQAAABmCgAA aAIAAM4MAACGAAAAHwkAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgQAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB8JAAAAAAAA AAAAAAAAAACSBAAAAAAAAJIEAAAAAAAAQgcAAAAAAAAAAAAAAAAAAEIHAADbAAAANAkAABYA AABpCAAAAAAAAGkIAAAAAAAAaQgAAAAAAAAdCAAAEAAAAJIEAAAAAAAAQgcAAAAAAACSBAAA AAAAAEIHAAAAAAAA+QgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAD5CAAAAAAAAAAAAAAAAAAA aQgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAkgQAAAAAAACSBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQgAAAAAAABCBwAA AAAAACAHAAAMAAAAEMujlT/AxgEAAAAAAAAAAAgHAAAAAAAALQgAABYAAABpCAAAAAAAAAAA AAAAAAAA7QgAAAwAAABKCQAAMAAAAHoJAAAAAAAAaQgAAAAAAABUDQAAAAAAAEMIAAAcAAAA VA0AAAAAAABpCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQNAAAAAAAAAAAAAAAAAACSBAAA AAAAAGkIAACEAAAAHQgAAAAAAAAdCAAAAAAAAGkIAAAAAAAAHQgAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA HwkAAAAAAAAfCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwgAAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAA AAAAAHoJAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAAAAAAAAAAAIAF AAAAAAAAgAUAAAAAAACABQAAZAEAAOQGAAAkAAAAgAUAAAAAAACABQAAAAAAAIAFAAAAAAAA 5AYAAAAAAACmBAAAFAAAALoEAAAOAAAAyAQAAAQAAACSBAAAAAAAAJIEAAAAAAAAkgQAAAAA AACSBAAAAAAAAJIEAAAAAAAAkgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhvdCBTdW1tZXIgU3BlY2lhbHMhDQ1WaWFncmEgPSAk MyBwZXIgcGlsbCAoMTAwbWcpDQ1WaWFncmEgU29mdCA9ICQzLjY2IHBlciBwaWxsICgxMDBt ZykNDUNpYWxpcyA9ICQzLjc1IHBlciBwaWxsICgyMG1nKQ0NTGV2aXRyYSA9ICQ0LjkwIHBl ciBwaWxsICgyMG1nKQ0NE0hZUEVSTElOSyAiaHR0cDovL21lZHZlZHJ4LmNvbSIBFENsaWNr IEhlcmUgZm9yIG1vcmUgaW5mbyEVDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADII AAAzCAAAmggAAJsIAACcCAAAuwgAALwIAAC9CAAA1ggAANcIAADYCAAA8+fz28q+qsqcyr4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGxVoBzlWABZoBzlWADBKEQA1 CIFDSjAAYUowACYCCIEDagAAAAAGCAEVaAc5VgAWaGEXEQA1CIFDSjAAVQgBYUowAAAXFWgH OVYAFmgHOVYANQiBQ0owAGFKMAAgA2oAAAAAFWgHOVYAFmgHOVYANQiBQ0owAFUIAWFKMAAA FxVoBzlWABZoBzlWADUIgUNKJABhSiQAFxVoBzlWABZoCCCoADUIgUNKKABhSigAFxVoBzlW ABZoBzlWADUIgUNKKABhSigAAAsABgAAFQgAABYIAAAzCAAANAgAAFkIAABaCAAAeQgAAHoI AACaCAAAmwgAANgIAADyAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADt AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAZ2QHOVYADQAAJmQMAQABUMYIAAAA/wwBAQBnZAc5VgAACwAGAADYCAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAQAAQEBLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew 0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACbAAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLKgAAAGgAdAB0 AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgISABIAAQCcAA8ABAAAAAAA AAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwEAAAAAAAA AAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAA AAAAAAAAAAAAAAAARABBQPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEA cgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAMBQAAAAAAAAAADABUAGEA YgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIA CwAAACgAawD0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABqAJoA swDzAGoADAQAAN43PwAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAABIAJkA AQACAUgADAUAAAAzjQAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABAAFABDShAA T0oDAFFKAwBeSgMAYUoQADYAVUCiABEBNgAMBAAAgBWBAAAACQBIAHkAcABlAHIAbABpAG4A awAAAAwAPioBQioCcGgAAP8AAAAAANgAAAAGAAAQAAAFAP////8BAAAABCEAAP//AQCgepkA AAAAAAAAAADYAAAAAAAAAAAAAAAAAAAAAAAVAAAAFgAAADMAAAA0AAAAWQAAAFoAAAB5AAAA egAAAJoAAACbAAAA2gAAAAT/AADAIQAA8fAEAAABAADAIQAA63QEAAABAADAIQAA63QEAAAB AADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA 63QEAAABAADAIQAA63QEAAABAADAIQAA1AIEAAABAADAIQAAGlkFAAAAAAAVAAAAFgAAADMA AAA0AAAAWQAAAFoAAAB5AAAAegAAAJoAAACbAAAA2gAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAAAAAANoAAABLiAAwABAAAAAAAAABAAAAAAAAAAAAAAAEDp8H AAYAANgIAAAFAAAAAAYAANgIAAAGAAAAAAYAANgIAAAHAAAAmwAAALwAAADWAAAA2AAAABNY FP8VhA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP// AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAI AAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAE AAAAAQAAAAAAAADXAAAA2gAAAAQAAwAAAAAAwwAAAMcAAADaAAAABwA6AAcAAAAAADQAAAC9 AAAA1wAAANoAAAAFAAcABQAHAAAAAADaAAAABwAbAAAABAAAAAgAAADlAAAAAAAAABoAAABZ NgAArHABAGEXEQDyNCoAmHYvAFJ5OgDRXjwA3jc/AAc5VgCyPlcAvx5mAMRHZwDBW24AfRNy ALcscwAREnoAgBWBAERFgwAAM40ACCCoAOxOvAAnL8IACxXgAB4b4AA1fOwAwVH6AERG/gAA AAAA2gAAAAAAAAD/QAOAAQDXAAAA1wAAAJAkiAVdAV0B1wAAAAAAAADXAAAAAAAAAAIQAAAA AAAAANgAAABgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA //8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAAAgIGAwUEBQIDBId6 ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA NRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAA MyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADUm kAEAAAILBgQDBQQEAgSHegBhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAAACIA BAAxCIgYAPDQAgAAaAEAAAAAMXioRjN4qEaCFaOGBQACAAAAIAAAALgAAAABAAEAAAAEAAMQ AQAAACAAAAC4AAAAAQABAAAAAQAAAAAAAAAhAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBPjQAABEAGQBkAAAAGQAAANcAAADXAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgAAAAAAAAAAAAkzgxEA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SFgAAAAAKfD/DwEAAT8AAOQEAAD///9/////f////3////9/////f////3////9/3jc/AAAA AAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAEgBTAEEAVgBFACAAWQBPAFUAUgAgAEIA VQBTAEkATgBFAFMAUwAAAAAAAAAOAFcAaQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAOAFcA aQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEA AADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAAC8AAAA BAAAAMgAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAACAEAAAkAAAAgAQAAEgAAACwB AAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAA jAEAABMAAACUAQAAAgAAAOQEAAAeAAAAFAAAAFNBVkUgWU9VUiBCVVNJTkVTUwAAHgAAAAQA AAAAAAAAHgAAABAAAABXaWxsaWFtIEVzdGhlcgAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAA HgAAAAgAAABOb3JtYWwAAB4AAAAQAAAAV2lsbGlhbSBFc3RoZXIAAB4AAAAEAAAANQAAAB4A AAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAACMhkcAAAAAQAAAAACUeJp/PsYB QAAAAAD+A0U/wMYBQAAAAACKiow/wMYBAwAAAAEAAAADAAAAIAAAAAMAAAC4AAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1Zwu GxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAA cAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAACwAAALgAAAAQAAAAwAAAABMA AADIAAAAFgAAANAAAAANAAAA2AAAAAwAAAD3AAAAAgAAAOQEAAAeAAAAIAAAAFBob2VuaXgg TWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAAAwAAAAEAAAADAAAAAQAAAAMAAADXAAAAAwAAAOYV CwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAEwAAAFNBVkUgWU9V UiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAACsAAAAAwAAAAAA AAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAA QQAAAGQAAAAGAAAAAwAAAAgAWwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFQAAAGgA dAB0AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAHwAAAAEAAAAAABIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAD+////CgAAAAsA AAAMAAAADQAAAA4AAAAPAAAAEAAAAP7///8SAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA /v///xoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAD+////IgAAACMAAAAkAAAAJQAAACYA AAAnAAAAKAAAAP7////9////KwAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAQPKaVP8DGAS0AAACAAAAA AAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAuEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAAABAAAAAAAAABAEMA bwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZp Y2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9Dmy cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0001_01C6D6F3.171FE100-- From fayer@diyessentials.com Wed Sep 13 01:12:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNN3K-0004b6-6k for ccamp-archive@ietf.org; Wed, 13 Sep 2006 01:12:50 -0400 Received: from [61.19.144.103] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNN3G-0003e6-Or for ccamp-archive@ietf.org; Wed, 13 Sep 2006 01:12:50 -0400 Message-ID: <000001c6d6f3$171fe100$0100007f@localhost> From: "Wendye Hartman" To: Subject: Charges for Medicare Confirmed. View Invoice #67766 Date: Wed, 13 Sep 2006 12:12:39 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C6D6F3.171FE100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.6 (++++) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6D6F3.171FE100 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C6D6F3.171FE100" ------=_NextPart_001_000E_01C6D6F3.171FE100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Your signature on attached form confirms our receipt of payment. ------=_NextPart_000_0001_01C6D6F3.171FE100 Content-Type: application/msword; name="Invoice67766.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Invoice67766.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKgAAAAAA AAAAEAAALAAAAAEAAAD+////AAAAACkAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA 2AgAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALhAAABM6AQATOgEA2AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAJIEAAAAAAAAkgQAAJIEAAAAAAAAkgQAAAAAAACSBAAA AAAAAJIEAAAAAAAAkgQAABQAAAAAAAAAAAAAAMwEAAC0AAAACAcAAAAAAAAIBwAAAAAAAAgH AAAAAAAACAcAAAwAAAAUBwAADAAAAIAFAAAAAAAAegkAAOwAAAAsBwAAFgAAAEIHAAAAAAAA QgcAAAAAAABCBwAAAAAAAEIHAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA+QgAAAIA AAD7CAAAAAAAAPsIAAAAAAAA+wgAAAAAAAD7CAAAAAAAAPsIAAAAAAAA+wgAACQAAABmCgAA aAIAAM4MAACGAAAAHwkAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgQAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB8JAAAAAAAA AAAAAAAAAACSBAAAAAAAAJIEAAAAAAAAQgcAAAAAAAAAAAAAAAAAAEIHAADbAAAANAkAABYA AABpCAAAAAAAAGkIAAAAAAAAaQgAAAAAAAAdCAAAEAAAAJIEAAAAAAAAQgcAAAAAAACSBAAA AAAAAEIHAAAAAAAA+QgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAD5CAAAAAAAAAAAAAAAAAAA aQgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAkgQAAAAAAACSBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQgAAAAAAABCBwAA AAAAACAHAAAMAAAAEMujlT/AxgEAAAAAAAAAAAgHAAAAAAAALQgAABYAAABpCAAAAAAAAAAA AAAAAAAA7QgAAAwAAABKCQAAMAAAAHoJAAAAAAAAaQgAAAAAAABUDQAAAAAAAEMIAAAcAAAA VA0AAAAAAABpCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQNAAAAAAAAAAAAAAAAAACSBAAA AAAAAGkIAACEAAAAHQgAAAAAAAAdCAAAAAAAAGkIAAAAAAAAHQgAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA HwkAAAAAAAAfCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwgAAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAA AAAAAHoJAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAAAAAAAAAAAIAF AAAAAAAAgAUAAAAAAACABQAAZAEAAOQGAAAkAAAAgAUAAAAAAACABQAAAAAAAIAFAAAAAAAA 5AYAAAAAAACmBAAAFAAAALoEAAAOAAAAyAQAAAQAAACSBAAAAAAAAJIEAAAAAAAAkgQAAAAA AACSBAAAAAAAAJIEAAAAAAAAkgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhvdCBTdW1tZXIgU3BlY2lhbHMhDQ1WaWFncmEgPSAk MyBwZXIgcGlsbCAoMTAwbWcpDQ1WaWFncmEgU29mdCA9ICQzLjY2IHBlciBwaWxsICgxMDBt ZykNDUNpYWxpcyA9ICQzLjc1IHBlciBwaWxsICgyMG1nKQ0NTGV2aXRyYSA9ICQ0LjkwIHBl ciBwaWxsICgyMG1nKQ0NE0hZUEVSTElOSyAiaHR0cDovL21lZHZlZHJ4LmNvbSIBFENsaWNr IEhlcmUgZm9yIG1vcmUgaW5mbyEVDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADII AAAzCAAAmggAAJsIAACcCAAAuwgAALwIAAC9CAAA1ggAANcIAADYCAAA8+fz28q+qsqcyr4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGxVoBzlWABZoBzlWADBKEQA1 CIFDSjAAYUowACYCCIEDagAAAAAGCAEVaAc5VgAWaGEXEQA1CIFDSjAAVQgBYUowAAAXFWgH OVYAFmgHOVYANQiBQ0owAGFKMAAgA2oAAAAAFWgHOVYAFmgHOVYANQiBQ0owAFUIAWFKMAAA FxVoBzlWABZoBzlWADUIgUNKJABhSiQAFxVoBzlWABZoCCCoADUIgUNKKABhSigAFxVoBzlW ABZoBzlWADUIgUNKKABhSigAAAsABgAAFQgAABYIAAAzCAAANAgAAFkIAABaCAAAeQgAAHoI AACaCAAAmwgAANgIAADyAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADt AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAZ2QHOVYADQAAJmQMAQABUMYIAAAA/wwBAQBnZAc5VgAACwAGAADYCAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAQAAQEBLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew 0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACbAAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLKgAAAGgAdAB0 AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgISABIAAQCcAA8ABAAAAAAA AAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwEAAAAAAAA AAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAA AAAAAAAAAAAAAAAARABBQPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEA cgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAMBQAAAAAAAAAADABUAGEA YgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIA CwAAACgAawD0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABqAJoA swDzAGoADAQAAN43PwAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAABIAJkA AQACAUgADAUAAAAzjQAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABAAFABDShAA T0oDAFFKAwBeSgMAYUoQADYAVUCiABEBNgAMBAAAgBWBAAAACQBIAHkAcABlAHIAbABpAG4A awAAAAwAPioBQioCcGgAAP8AAAAAANgAAAAGAAAQAAAFAP////8BAAAABCEAAP//AQCgepkA AAAAAAAAAADYAAAAAAAAAAAAAAAAAAAAAAAVAAAAFgAAADMAAAA0AAAAWQAAAFoAAAB5AAAA egAAAJoAAACbAAAA2gAAAAT/AADAIQAA8fAEAAABAADAIQAA63QEAAABAADAIQAA63QEAAAB AADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA 63QEAAABAADAIQAA63QEAAABAADAIQAA1AIEAAABAADAIQAAGlkFAAAAAAAVAAAAFgAAADMA AAA0AAAAWQAAAFoAAAB5AAAAegAAAJoAAACbAAAA2gAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAAAAAANoAAABLiAAwABAAAAAAAAABAAAAAAAAAAAAAAAEDp8H AAYAANgIAAAFAAAAAAYAANgIAAAGAAAAAAYAANgIAAAHAAAAmwAAALwAAADWAAAA2AAAABNY FP8VhA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP// AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAI AAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAE AAAAAQAAAAAAAADXAAAA2gAAAAQAAwAAAAAAwwAAAMcAAADaAAAABwA6AAcAAAAAADQAAAC9 AAAA1wAAANoAAAAFAAcABQAHAAAAAADaAAAABwAbAAAABAAAAAgAAADlAAAAAAAAABoAAABZ NgAArHABAGEXEQDyNCoAmHYvAFJ5OgDRXjwA3jc/AAc5VgCyPlcAvx5mAMRHZwDBW24AfRNy ALcscwAREnoAgBWBAERFgwAAM40ACCCoAOxOvAAnL8IACxXgAB4b4AA1fOwAwVH6AERG/gAA AAAA2gAAAAAAAAD/QAOAAQDXAAAA1wAAAJAkiAVdAV0B1wAAAAAAAADXAAAAAAAAAAIQAAAA AAAAANgAAABgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA //8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAAAgIGAwUEBQIDBId6 ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA NRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAA MyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADUm kAEAAAILBgQDBQQEAgSHegBhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAAACIA BAAxCIgYAPDQAgAAaAEAAAAAMXioRjN4qEaCFaOGBQACAAAAIAAAALgAAAABAAEAAAAEAAMQ AQAAACAAAAC4AAAAAQABAAAAAQAAAAAAAAAhAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBPjQAABEAGQBkAAAAGQAAANcAAADXAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgAAAAAAAAAAAAkzgxEA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SFgAAAAAKfD/DwEAAT8AAOQEAAD///9/////f////3////9/////f////3////9/3jc/AAAA AAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAEgBTAEEAVgBFACAAWQBPAFUAUgAgAEIA VQBTAEkATgBFAFMAUwAAAAAAAAAOAFcAaQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAOAFcA aQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEA AADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAAC8AAAA BAAAAMgAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAACAEAAAkAAAAgAQAAEgAAACwB AAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAA jAEAABMAAACUAQAAAgAAAOQEAAAeAAAAFAAAAFNBVkUgWU9VUiBCVVNJTkVTUwAAHgAAAAQA AAAAAAAAHgAAABAAAABXaWxsaWFtIEVzdGhlcgAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAA HgAAAAgAAABOb3JtYWwAAB4AAAAQAAAAV2lsbGlhbSBFc3RoZXIAAB4AAAAEAAAANQAAAB4A AAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAACMhkcAAAAAQAAAAACUeJp/PsYB QAAAAAD+A0U/wMYBQAAAAACKiow/wMYBAwAAAAEAAAADAAAAIAAAAAMAAAC4AAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1Zwu GxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAA cAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAACwAAALgAAAAQAAAAwAAAABMA AADIAAAAFgAAANAAAAANAAAA2AAAAAwAAAD3AAAAAgAAAOQEAAAeAAAAIAAAAFBob2VuaXgg TWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAAAwAAAAEAAAADAAAAAQAAAAMAAADXAAAAAwAAAOYV CwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAEwAAAFNBVkUgWU9V UiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAACsAAAAAwAAAAAA AAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAA QQAAAGQAAAAGAAAAAwAAAAgAWwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFQAAAGgA dAB0AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAHwAAAAEAAAAAABIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAD+////CgAAAAsA AAAMAAAADQAAAA4AAAAPAAAAEAAAAP7///8SAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA /v///xoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAD+////IgAAACMAAAAkAAAAJQAAACYA AAAnAAAAKAAAAP7////9////KwAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAQPKaVP8DGAS0AAACAAAAA AAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAuEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAAABAAAAAAAAABAEMA bwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZp Y2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9Dmy cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0001_01C6D6F3.171FE100-- From owner-ccamp@ops.ietf.org Wed Sep 13 16:15:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNb98-000793-Iz for ccamp-archive@ietf.org; Wed, 13 Sep 2006 16:15:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNb97-0008Gw-2G for ccamp-archive@ietf.org; Wed, 13 Sep 2006 16:15:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNazn-000Fw5-CY for ccamp-data@psg.com; Wed, 13 Sep 2006 20:06:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNazm-000Fvn-4x for ccamp@ops.ietf.org; Wed, 13 Sep 2006 20:06:06 +0000 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2006 16:06:05 -0400 X-IronPort-AV: i="4.09,160,1157342400"; d="scan'208"; a="102266413:sNHT49091780" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8DK65dO023000; Wed, 13 Sep 2006 16:06:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8DK62uI024698; Wed, 13 Sep 2006 16:06:03 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 16:06:02 -0400 Received: from swallow-mini-mac.cisco.com ([10.86.116.2]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 16:06:01 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.cisco.com (Postfix) with ESMTP id 842742F12BD; Wed, 13 Sep 2006 16:06:20 -0400 (EDT) To: Greg Jones Cc: IESG , IAB , Steve Trowbridge , Malcolm Betts , Yoichi Maeda , Ghani Abbas , Houlin Zhao , CCAMP mailing list , MPLS mailing list , PWE3 mailing list Cc: Loa Andersson , Scott Bradner , Deborah Brungard , Stewart Bryant , Adrian Farrel , Danny McPherson , George Swallow , statements@ietf.org From: George Swallow Subject: Liaison to ITU-T SG15 X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Wed, 13 Sep 2006 16:06:20 -0400 Message-Id: <20060913200620.842742F12BD@swallow-mini-mac.cisco.com> X-OriginalArrivalTime: 13 Sep 2006 20:06:01.0685 (UTC) FILETIME=[092C6050:01C6D770] DKIM-Signature: a=rsa-sha1; q=dns; l=6463; t=1158177965; x=1159041965; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Liaison=20to=20ITU-T=20SG15 |To:Greg=20Jones=20; X=v=3Dcisco.com=3B=20h=3DtYerVQOY20ZZEewydYfLbbJbYkE=3D; b=LPj2dIN/WN+Mv0t7Xl2yoM8TMdqB9yc0c6NFkhvBmE4LIPIWDVUIquwfUmja/AgAPJOn+CJs SXmS/PZm/6ThVCESFKLjL6+XljBQyrxlHVMZe7+zSRidtN2F+Of831sB; Authentication-Results: rtp-dkim-2.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Liaison Statement Submission Date: 2006-09-13 From: Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; loa@pi.se) Scott Bradner (IETF Liaison to ITU-T, sob@harvard.edu) Deborah Brungard (IETF CCAMP WG Chair, dbrungard@att.com) Stewart Bryant (IETF PWE3 WG Chair, stbryant@cisco.com) Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, adrian@olddog.co.uk) Danny McPherson (IETF PWE3 WG Chair, danny@arbor.net) George Swallow (IETF MPLS WG Chair, swallow@cisco.com) To: ITU-T Study Group 15; Greg Jones (greg.jones@itu.int) CC: IESG (iesg@ietf.org) IAB (iab@ietf.org) Steve Trowbridge (sjtrowbridge@lucent.com) Malcolm Betts (betts01@nortel.com) Yoichi Maeda (maeda@ansl.ntt.co.jp) Ghani Abbas (ghani.abbas@marconi.com) Houlin Zhao (houlin.zhao@itu.int) CCAMP mailing list (ccamp@ops.ietf.org) MPLS mailing list (mpls@lists.ietf.org) PWE3 mailing list (pwe3@ietf.org) Re: T-MPLS use of the MPLS Ethertypes Response Contact: George Swallow Technical Contact: George Swallow Purpose: For action Deadline: 2006-10-13 We would like to thank you for your response to our liaison. We feel that through the liaison activity and the Ottawa meeting we have entered into a productive and useful dialogue. We are particularly pleased by your positive reaction to most of our concerns. We do, however, once again, request documentation of the problem that T-MPLS solves. We feel that this documentation is fundamental to a proper review of the T-MPLS architecture, protocol requirements, and any future solutions, and we advise the ITU-T not to present any T-MPLS Recommendations for consent until work on a T-MPLS problem statement is well advanced. Further, a full reference diagram of the interfaces and services of the T-MPLS network would be most useful. We understand that the direct adaptation of an IP/MPLS client over a T-MPLS server is still at a very preliminary stage. However, some understanding of the client/server relationship is necessary in order to adequately evaluate architectural decisions currently being made in G.8110.1. The most immediate concern is the proposed use of the MPLS Ethertypes. In your liaison to the MFA Forum dated 19-23 June 2006 you say, First we would like to call your attention to the fact that we are in the process of modifying the semantics of the two Ethertypes used by MPLS. Currently their designations are "MPLS Unicast" (8847) and "MPLS Multicast" (8848). The new semantics will be "Downstream Assigned" (8847) and "Upstream Assigned" (8848)". On a practical level, they will still be used for Unicast and Multicast respectively, however the change has been made to clarify which Label Switch Router (LSR) controls each label space. Each of these label spaces is shared by all MPLS applications. Each space is managed by a label-manager which is responsible for label allocation and reclamation. When a packet is received at the downstream LSR with Ethertype 8847 it is looked up in a table managed by the downstream router. Conversely when a packet is received at the downstream LSR with Ethertype 8848 it is looked up in a table managed by the upstream router. In your liaison to the MFA Forum dated 19-23 June 2006 you say, T-MPLS is intended to be a separate layer network with respect to MPLS. However, T- MPLS will use the same data-link protocol ID (e.g. EtherType), frame format and forwarding semantics for as those defined for MPLS frames. T-MPLS and MPLS cannot coexist on the same "interface" (for example they could not coexist on a single Ethernet VLAN, however they could be multiplexed on to a common Ethernet PHY using separate VLANs). On the face of it, this statement implies that MPLS and T-MPLS are two different things, but that you wish to identify them both using the same Ethertype. The Ethertype is the primary means for multiplexing and distinguishing protocols over Ethernet. The Ethertype identifies the protocol entity that will receive a packet at the layer above. VLANs on the other hand are primarily intended as a service level interface, allowing multiple virtual LANs over a single bridged domain. . If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is in fact a separate layer network, then it should be identified by its own Ethertype(s), Clear and unambiguous identification is in the best interest of all involved. In particular, if T- MPLS is being architected in such a way that would prevent it from acquiring labels by interacting with a shared label manager, then separate Ethertypes would guarantee that there is no confusion as to which label spaces belong to T-MPLS. Note further that if T-MPLS is being architected in such a way that it can (or could) interact with a shared label manager and could co-exist over the same interface sharing the MPLS label spaces with other MPLS applications, then we would welcome use of the MPLS Ethertypes. We believe that a decision to use the MPLS Ethertypes to point to a label space other than as defined by the MPLS RFCs to be architecturally unsound and ultimately will prove to be limiting to the deployment options available in networks which employ both MPLS and T-MPLS. Sincerely, Loa Andersson Scott Bradner Deborah Brungard Stewart Bryant Adrian Farrel Danny McPherson George Swallow ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From orion@dm.mailpia.net Thu Sep 14 04:23:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNmVR-0003kL-N0 for ccamp-archive@megatron.ietf.org; Thu, 14 Sep 2006 04:23:33 -0400 Received: from [125.187.32.167] (helo=m09.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNmVQ-0005pA-1w for ccamp-archive@megatron.ietf.org; Thu, 14 Sep 2006 04:23:33 -0400 Received: (qmail 15818 invoked by uid 0); 14 Sep 2006 17:21:40 +0900 Message-ID: <20060914082140.15817.qmail@m09.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCIVowZj5lT0JMaSFbOkcbKEI=?= =?ISO-2022-JP?B?GyRCQzskRzIvS3xEOTxUJEskSiRrSn1LISEqISohKhsoQg==?= From: info-jyouhoubisiness Reply-to: delivery_rt Date: 2006-09-14 17:21:25 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060914170820_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From online.customer@chase.com Thu Sep 14 08:21:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNqE2-0001Co-T0 for ccamp-archive@ietf.org; Thu, 14 Sep 2006 08:21:50 -0400 Received: from [72.11.78.6] (helo=phoneroom) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNqE1-000787-Iv for ccamp-archive@ietf.org; Thu, 14 Sep 2006 08:21:50 -0400 Received: from User ([64.65.222.224]) by phoneroom with Microsoft SMTPSVC(6.0.2600.1); Thu, 14 Sep 2006 04:36:16 -0600 Reply-To: From: "Chase Bank" Subject: Online Banking system and features Date: Thu, 14 Sep 2006 06:45:27 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Bcc: Message-ID: X-OriginalArrivalTime: 14 Sep 2006 10:36:17.0009 (UTC) FILETIME=[9BEE8610:01C6D7E9] X-Spam-Score: 4.4 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 From owner-ccamp@ops.ietf.org Thu Sep 14 12:31:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNu7J-0007z5-CG for ccamp-archive@ietf.org; Thu, 14 Sep 2006 12:31:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNu7G-0006dW-S9 for ccamp-archive@ietf.org; Thu, 14 Sep 2006 12:31:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNtzn-0007wL-U3 for ccamp-data@psg.com; Thu, 14 Sep 2006 16:23:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNtzm-0007w2-T3 for ccamp@ops.ietf.org; Thu, 14 Sep 2006 16:23:23 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Sep 2006 12:23:08 -0400 X-IronPort-AV: i="4.09,165,1157342400"; d="scan'208"; a="102430923:sNHT39651109516" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8EGN7nX029917; Thu, 14 Sep 2006 12:23:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8EGN6dM017926; Thu, 14 Sep 2006 12:23:06 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 12:23:06 -0400 Received: from swallow-mini-mac.cisco.com ([10.86.116.2]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 12:23:05 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.cisco.com (Postfix) with ESMTP id 8C2AF2F38EB; Thu, 14 Sep 2006 12:23:25 -0400 (EDT) To: Greg Jones Cc: IESG , IAB , Steve Trowbridge , Malcolm Betts , Yoichi Maeda , Ghani Abbas , Houlin Zhao , CCAMP mailing list , MPLS mailing list , PWE3 mailing list , Loa Andersson , Scott Bradner , Deborah Brungard , Stewart Bryant , Adrian Farrel , Danny McPherson , statements@ietf.org Cc: swallow@cisco.com Subject: Updated Liaison to ITU-T SG15 From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Thu, 14 Sep 2006 12:23:25 -0400 Message-Id: <20060914162325.8C2AF2F38EB@swallow-mini-mac.cisco.com> X-OriginalArrivalTime: 14 Sep 2006 16:23:05.0358 (UTC) FILETIME=[0EAC9AE0:01C6D81A] DKIM-Signature: a=rsa-sha1; q=dns; l=6389; t=1158250987; x=1159114987; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Updated=20Liaison=20to=20ITU-T=20SG15=20 |To:Greg=20Jones=20; X=v=3Dcisco.com=3B=20h=3DucrXgxnUFLBKbA4teKEn31O4ArA=3D; b=AVtUQeQlfzTkT2gno5CFjbk1KeQoncjH7B1B7HiiOKa8R3W2TAPuzFYQEiHUMoXvEny2lXGl 79WhrtW/94LPZZ7JtavtIVosNk2ztuPgQC2ouQPq8GbQQg0b1cPxTxFK; Authentication-Results: rtp-dkim-1.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d All - There is a type-o in the liaison sent yesterday. The second sentence of the third paragraph should have been deleted. An updated copy is attached. ...George ======================================================================== Liaison Statement Submission Date: 2006-09-13 From: Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; loa@pi.se) Scott Bradner (IETF Liaison to ITU-T, sob@harvard.edu) Deborah Brungard (IETF CCAMP WG Chair, dbrungard@att.com) Stewart Bryant (IETF PWE3 WG Chair, stbryant@cisco.com) Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, adrian@olddog.co.uk) Danny McPherson (IETF PWE3 WG Chair, danny@arbor.net) George Swallow (IETF MPLS WG Chair, swallow@cisco.com) To: ITU-T Study Group 15; Greg Jones (greg.jones@itu.int) CC: IESG (iesg@ietf.org) IAB (iab@ietf.org) Steve Trowbridge (sjtrowbridge@lucent.com) Malcolm Betts (betts01@nortel.com) Yoichi Maeda (maeda@ansl.ntt.co.jp) Ghani Abbas (ghani.abbas@marconi.com) Houlin Zhao (houlin.zhao@itu.int) CCAMP mailing list (ccamp@ops.ietf.org) MPLS mailing list (mpls@lists.ietf.org) PWE3 mailing list (pwe3@ietf.org) Re: T-MPLS use of the MPLS Ethertypes Response Contact: George Swallow Technical Contact: George Swallow Purpose: For action Deadline: 2006-10-13 We would like to thank you for your response to our liaison. We feel that through the liaison activity and the Ottawa meeting we have entered into a productive and useful dialogue. We are particularly pleased by your positive reaction to most of our concerns. We do, however, once again, request documentation of the problem that T-MPLS solves. We feel that this documentation is fundamental to a proper review of the T-MPLS architecture, protocol requirements, and any future solutions, and we advise the ITU-T not to present any T-MPLS Recommendations for consent until work on a T-MPLS problem statement is well advanced. Further, a full reference diagram of the interfaces and services of the T-MPLS network would be most useful. We understand that the direct adaptation of an IP/MPLS client over a T-MPLS server is still at a very preliminary stage. However, some understanding of the client/server relationship is necessary in order to adequately evaluate architectural decisions currently being made in G.8110.1. The most immediate concern is the proposed use of the MPLS Ethertypes. First we would like to call your attention to the fact that we are in the process of modifying the semantics of the two Ethertypes used by MPLS. Currently their designations are "MPLS Unicast" (8847) and "MPLS Multicast" (8848). The new semantics will be "Downstream Assigned" (8847) and "Upstream Assigned" (8848)". On a practical level, they will still be used for Unicast and Multicast respectively, however the change has been made to clarify which Label Switch Router (LSR) controls each label space. Each of these label spaces is shared by all MPLS applications. Each space is managed by a label-manager which is responsible for label allocation and reclamation. When a packet is received at the downstream LSR with Ethertype 8847 it is looked up in a table managed by the downstream router. Conversely when a packet is received at the downstream LSR with Ethertype 8848 it is looked up in a table managed by the upstream router. In your liaison to the MFA Forum dated 19-23 June 2006 you say, T-MPLS is intended to be a separate layer network with respect to MPLS. However, T- MPLS will use the same data-link protocol ID (e.g. EtherType), frame format and forwarding semantics for as those defined for MPLS frames. T-MPLS and MPLS cannot coexist on the same "interface" (for example they could not coexist on a single Ethernet VLAN, however they could be multiplexed on to a common Ethernet PHY using separate VLANs). On the face of it, this statement implies that MPLS and T-MPLS are two different things, but that you wish to identify them both using the same Ethertype. The Ethertype is the primary means for multiplexing and distinguishing protocols over Ethernet. The Ethertype identifies the protocol entity that will receive a packet at the layer above. VLANs on the other hand are primarily intended as a service level interface, allowing multiple virtual LANs over a single bridged domain. . If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is in fact a separate layer network, then it should be identified by its own Ethertype(s), Clear and unambiguous identification is in the best interest of all involved. In particular, if T- MPLS is being architected in such a way that would prevent it from acquiring labels by interacting with a shared label manager, then separate Ethertypes would guarantee that there is no confusion as to which label spaces belong to T-MPLS. Note further that if T-MPLS is being architected in such a way that it can (or could) interact with a shared label manager and could co-exist over the same interface sharing the MPLS label spaces with other MPLS applications, then we would welcome use of the MPLS Ethertypes. We believe that a decision to use the MPLS Ethertypes to point to a label space other than as defined by the MPLS RFCs to be architecturally unsound and ultimately will prove to be limiting to the deployment options available in networks which employ both MPLS and T-MPLS. Sincerely, Loa Andersson Scott Bradner Deborah Brungard Stewart Bryant Adrian Farrel Danny McPherson George Swallow From owner-ccamp@ops.ietf.org Fri Sep 15 11:01:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFBn-0004W6-Ig for ccamp-archive@ietf.org; Fri, 15 Sep 2006 11:01:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFBi-00083E-5l for ccamp-archive@ietf.org; Fri, 15 Sep 2006 11:01:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOF2b-000JHC-8X for ccamp-data@psg.com; Fri, 15 Sep 2006 14:51:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOF2W-000JFx-J6 for ccamp@ops.ietf.org; Fri, 15 Sep 2006 14:51:36 +0000 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 1GOF2k-0001GO-00 for ccamp@ops.ietf.org; Fri, 15 Sep 2006 15:51:50 +0100 Received: from your029b8cecfe ([217.158.132.176] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 15:51:31 +0100 Message-ID: <07b901c6d8d6$62cb9d30$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt Date: Fri, 15 Sep 2006 12:52:30 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 15 Sep 2006 14:51:32.0093 (UTC) FILETIME=[6ED8A2D0:01C6D8D6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi, We had a lively debate, and I promised to try to summarise the points to see if we have some form of consensus. draft-caviglia-ccamp-pc-and-sc-reqs-03.txt describes a problem space where the authors say it is desirable to be able to transfer control of an LSP between the management plane and a GMPLS control plane. They support this claim with various scenarios. They then develop a series of requirements on the process. The intention is to specify a process and develop any necessary protocol extensions. Re-reading the thread, I think I see the following points: 1. General agreement that transfer of control from the management plane to the control plane is a realistic scenario as a GMPLS control plane is introduced into an existing network where LSPs have been established using the management plane. 2. Some disagreement about whether point 1 needs to be performed dynamically, but nevertheless agreement that some operators may wish to make the transfer hitlessly (i.e. without a maintenance period) and in a network without sufficient spare capacity to establish a parallel LSP. 3. Considerable disagreement about some of the scenarios (documented and raised on the mailing list) for the transfer of control from the control plane to the management plane. 4. Some understanding that if transfer from the management plane to the control plane is supported, there will be a desire to back-out the process, for example if the operator is not happy with the result. 5. Some debate over whether either of the transfers (but particularly the transfer from control plane to management plane) would result in any extensions to the protocols. 6. Concern that handling failure events, where control of the LSP ends up in some mixed mode, could be very messy. My conclusions, therefore, are: A. There is consensus to work on transfer from the management plane to the control plane. B. There is enough interest to justify work on the transfer from the control plane to the management plane, but this should be scoped as a back-out procedure. C. The requirements should initially state the functional requirements and should not assume that changes to the protocols are necessary. That is, if the requirements draft can be answered with an applicability statement, that would be good all round. Later section of the draft can state current protocol behavior, and point out any gaps that need to be filled. D. The requirements draft must cover the requirements for failure cases in good detail We should encourage the authors to revise their draft along these lines at which time the working group may be more likely to find itself in full consensus. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Sep 15 11:32:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFfe-0001O5-Cd for ccamp-archive@ietf.org; Fri, 15 Sep 2006 11:32:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFfa-0002Bf-Sq for ccamp-archive@ietf.org; Fri, 15 Sep 2006 11:32:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOFLK-000MxA-MR for ccamp-data@psg.com; Fri, 15 Sep 2006 15:11:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOFLG-000MwM-Sj for ccamp@ops.ietf.org; Fri, 15 Sep 2006 15:10:59 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k8FFAnkw018850; Fri, 15 Sep 2006 16:10:49 +0100 (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt To: "Adrian Farrel" Cc: " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Fri, 15 Sep 2006 17:09:14 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 15/09/2006 16:10:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Adrian, I'd like to thank you for having done this summary. As an author of the ID I agree with your points. We'll review the ID. Regards Diego "Adrian Farrel" @ops.ietf.org on 15/09/2006 13.52.30 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt Hi, We had a lively debate, and I promised to try to summarise the points to see if we have some form of consensus. draft-caviglia-ccamp-pc-and-sc-reqs-03.txt describes a problem space where the authors say it is desirable to be able to transfer control of an LSP between the management plane and a GMPLS control plane. They support this claim with various scenarios. They then develop a series of requirements on the process. The intention is to specify a process and develop any necessary protocol extensions. Re-reading the thread, I think I see the following points: 1. General agreement that transfer of control from the management plane to the control plane is a realistic scenario as a GMPLS control plane is introduced into an existing network where LSPs have been established using the management plane. 2. Some disagreement about whether point 1 needs to be performed dynamically, but nevertheless agreement that some operators may wish to make the transfer hitlessly (i.e. without a maintenance period) and in a network without sufficient spare capacity to establish a parallel LSP. 3. Considerable disagreement about some of the scenarios (documented and raised on the mailing list) for the transfer of control from the control plane to the management plane. 4. Some understanding that if transfer from the management plane to the control plane is supported, there will be a desire to back-out the process, for example if the operator is not happy with the result. 5. Some debate over whether either of the transfers (but particularly the transfer from control plane to management plane) would result in any extensions to the protocols. 6. Concern that handling failure events, where control of the LSP ends up in some mixed mode, could be very messy. My conclusions, therefore, are: A. There is consensus to work on transfer from the management plane to the control plane. B. There is enough interest to justify work on the transfer from the control plane to the management plane, but this should be scoped as a back-out procedure. C. The requirements should initially state the functional requirements and should not assume that changes to the protocols are necessary. That is, if the requirements draft can be answered with an applicability statement, that would be good all round. Later section of the draft can state current protocol behavior, and point out any gaps that need to be filled. D. The requirements draft must cover the requirements for failure cases in good detail We should encourage the authors to revise their draft along these lines at which time the working group may be more likely to find itself in full consensus. Thanks, Adrian From orion@dm.mailpia.net Fri Sep 15 11:42:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFpo-0004Nq-Ak for ccamp-archive@ietf.org; Fri, 15 Sep 2006 11:42:32 -0400 Received: from [125.187.32.199] (helo=m27.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFpj-0002af-Kf for ccamp-archive@ietf.org; Fri, 15 Sep 2006 11:42:32 -0400 Received: (qmail 16117 invoked by uid 0); 16 Sep 2006 00:42:25 +0900 Message-ID: <20060915154225.16116.qmail@m27.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyouhoubisiness Reply-to: delivery_rt Date: 2006-09-16 00:40:23 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060915184824_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From owner-ccamp@ops.ietf.org Fri Sep 15 13:41:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOHgg-0006SA-D0 for ccamp-archive@ietf.org; Fri, 15 Sep 2006 13:41:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOHgf-0003Su-0i for ccamp-archive@ietf.org; Fri, 15 Sep 2006 13:41:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOHbZ-000M8y-VD for ccamp-data@psg.com; Fri, 15 Sep 2006 17:35:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOHbX-000M8S-09 for ccamp@ops.ietf.org; Fri, 15 Sep 2006 17:35:55 +0000 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 1GOHbo-0002Rf-00 for ccamp@ops.ietf.org; Fri, 15 Sep 2006 18:36:12 +0100 Received: from your029b8cecfe ([217.158.132.80] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 18:35:50 +0100 Message-ID: <081c01c6d8ed$5c273540$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Jim Jones" Cc: , "Brungard, Deborah A, ALABS" , "Ross Callon" , "Bill Fenner" Subject: New CCAMP RFC of Interest to OIF Date: Fri, 15 Sep 2006 18:33:15 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 15 Sep 2006 17:35:51.0262 (UTC) FILETIME=[635E6FE0:01C6D8ED] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Dear Jim, The CCAMP working group of the IETF is pleased to inform you of the publication of RFC 4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. The Abstract to this RFC reads as follows: This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. The RFC can be downloaded free of charge from http://www.ietf.org/rfc/rfc4606.txt RFC 4606 obsoletes RFC 3946 and addresses a minor clarification arising from a question raised by the OIF as a result of interworking tests. Further information about the work of the CCAMP working group can be found at our charter page: http://www.ietf.org/html.charters/ccamp-charter.html Best regards, Adrian Farrel and Deborah Brungard CCAMP Working Group Co-Chairs From owner-ccamp@ops.ietf.org Fri Sep 15 13:50:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOHpv-00034I-Jn for ccamp-archive@ietf.org; Fri, 15 Sep 2006 13:50:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOHpu-0005vf-A2 for ccamp-archive@ietf.org; Fri, 15 Sep 2006 13:50:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOHhk-000NH4-C4 for ccamp-data@psg.com; Fri, 15 Sep 2006 17:42:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOHhi-000NGL-Hs for ccamp@ops.ietf.org; Fri, 15 Sep 2006 17:42:18 +0000 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 8BF892AC84; Fri, 15 Sep 2006 17:42:17 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GOHhh-0002Tm-B9; Fri, 15 Sep 2006 13:42:17 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Stephen Trowbridge , Kam Lam , CCAMP Mailing List , Ross Callon , Bill Fenner , Scott Bradner , Deborah Brungard , Adrian Farrel , Adrian Farrel From: Adrian Farrel (IETF CCAMP WG) Subject: New Liaison Statement, "New RFC on GMPLS Extensions for SONET/SDH" Reply-To: Adrian Farrel Message-Id: Date: Fri, 15 Sep 2006 13:42:17 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Title: New RFC on GMPLS Extensions for SONET/SDH Submission Date: 2006-09-15 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=264 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T SG15(Greg Jones ) Cc: Stephen Trowbridge Kam Lam CCAMP Mailing List Ross Callon Bill Fenner Scott Bradner Deborah Brungard Reponse Contact: Adrian Farrel Technical Contact: Adrian Farrel Purpose: For information Body: The CCAMP working group of the IETF is pleased to inform you of the publication of RFC 4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. The Abstract to this RFC reads as follows: This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. The RFC can be downloaded free of charge from http://www.ietf.org/rfc/rfc4606.txt RFC 4606 obsoletes RFC 3946 and addresses a minor clarification. Further information about the work of the CCAMP working group can be found at our charter page http://www.ietf.org/html.charters/ccamp-charter.html Best regards, Adrian Farrel and Deborah Brungard CCAMP Working Group Co-Chairs Attachment(s): No document has been attached From owner-ccamp@ops.ietf.org Fri Sep 15 15:04:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOIzP-0007pD-99 for ccamp-archive@ietf.org; Fri, 15 Sep 2006 15:04:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOIzN-0002d6-Lg for ccamp-archive@ietf.org; Fri, 15 Sep 2006 15:04:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOIr7-0009Lz-3d for ccamp-data@psg.com; Fri, 15 Sep 2006 18:56:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [143.209.238.162] (helo=audl953.usa.alcatel.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOIr5-0009LQ-4c for ccamp@ops.ietf.org; Fri, 15 Sep 2006 18:56:03 +0000 Received: from usdaln07161 (usdaln07161.usa.alcatel.com [143.209.81.156]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k8FIttPG001103; Fri, 15 Sep 2006 13:55:55 -0500 From: "Jim Jones" To: "'Adrian Farrel'" Cc: , "'Brungard, Deborah A, ALABS'" , "'Ross Callon'" , "'Bill Fenner'" Subject: RE: New CCAMP RFC of Interest to OIF Date: Fri, 15 Sep 2006 13:55:54 -0500 Message-ID: <003901c6d8f8$94dabcd0$9c51d18f@ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <081c01c6d8ed$5c273540$0a23fea9@your029b8cecfe> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 thread-index: AcbY7YEDw64Nfe3gSs2k719pH0g66gACt7wQ X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Dear Adrian and Deborah, Thank you for the update. I will make the membership aware of this new RFC. Best Regards, Jim Jones OIF Technical Committee Chair -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 15, 2006 12:33 PM To: Jim Jones Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS; Ross Callon; Bill Fenner Subject: New CCAMP RFC of Interest to OIF Dear Jim, The CCAMP working group of the IETF is pleased to inform you of the publication of RFC 4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. The Abstract to this RFC reads as follows: This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. The RFC can be downloaded free of charge from http://www.ietf.org/rfc/rfc4606.txt RFC 4606 obsoletes RFC 3946 and addresses a minor clarification arising from a question raised by the OIF as a result of interworking tests. Further information about the work of the CCAMP working group can be found at our charter page: http://www.ietf.org/html.charters/ccamp-charter.html Best regards, Adrian Farrel and Deborah Brungard CCAMP Working Group Co-Chairs From orion@dm.mailpia.net Fri Sep 15 15:48:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOJfO-0006JD-B6 for ccamp-archive@ietf.org; Fri, 15 Sep 2006 15:48:02 -0400 Received: from [125.187.32.134] (helo=m01.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOJeW-0000EQ-Oj for ccamp-archive@ietf.org; Fri, 15 Sep 2006 15:47:10 -0400 Received: (qmail 5700 invoked by uid 0); 16 Sep 2006 04:43:08 +0900 Message-ID: <20060915194308.5699.qmail@m01.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyouhoubisiness Reply-to: delivery_rt Date: 2006-09-16 04:40:04 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060915185930_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From owner-ccamp@ops.ietf.org Fri Sep 15 16:20:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOKAw-0000Ef-R5 for ccamp-archive@ietf.org; Fri, 15 Sep 2006 16:20:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOJz9-00044L-S5 for ccamp-archive@ietf.org; Fri, 15 Sep 2006 16:08:27 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GOJnu-0004Dx-3M for ccamp-archive@ietf.org; Fri, 15 Sep 2006 15:56:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOJhN-000Hni-K9 for ccamp-data@psg.com; Fri, 15 Sep 2006 19:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOJhL-000Hm9-Le for ccamp@ops.ietf.org; Fri, 15 Sep 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CDD7A2AC8B; Fri, 15 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GOJhK-0007PU-IX; Fri, 15 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-06.txt Message-Id: Date: Fri, 15 Sep 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.2 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-06.txt Pages : 20 Date : 2006-9-15 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.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-ccamp-gmpls-alarm-spec-06.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-ccamp-gmpls-alarm-spec-06.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-9-15134032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-15134032.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Sun Sep 17 05:45:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOtDO-000536-Og for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:45:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOtDN-0000iL-8D for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:45:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOt0U-000HoL-Do for ccamp-data@psg.com; Sun, 17 Sep 2006 09:32:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOt0S-000Ho1-Lu for ccamp@ops.ietf.org; Sun, 17 Sep 2006 09:32:08 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GOt0P-0004S9-00 for ccamp@ops.ietf.org; Sun, 17 Sep 2006 10:32:05 +0100 Received: from your029b8cecfe ([217.158.132.59] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Sep 2006 10:32:02 +0100 Message-ID: <097c01c6da3c$1ab832d0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Pandian, Vijay" , Cc: , , References: <0679BA70A2F59E49B186858B47F4595C4E001D@viper.sycamorenet.com> Subject: Re: RFC3630 - Local and Remote Interface IP address Date: Sun, 17 Sep 2006 10:31:31 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 17 Sep 2006 09:32:03.0919 (UTC) FILETIME=[228CE5F0:01C6DA3C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Hi Vijay, OSPF-TE implementers may wish to disagree with me on this, but I think Dimitri's definitive statement does not cover the basic reasoning for this feature. While it is true that one can use multiple link addresses to identify multiple component links, I think that the multiplicity of link addresses is provided in this RFC so that a single TE link may support multiple interfaces. This is an implementation choice, and may be advantageous in some cases. If the multiple link addresses are used to identify multiple component links, then I would expect a 1:1 correspondence between the link ends. If the addresses are used to identify different interfaces to the same link then I would not necessarily expect a 1:1 correspondence. In answer to your most recent questions: > Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link." And so it does. It describes a single TE link. A link bundle is still a single TE link, but it is made up of multiple component links that are not identified as TE links in their own right. > Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV > specifies the IP address(es) of the interface corresponding to this link." > > Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV > specifies the IP address(es) of the neighbor's interface corresponding to > this link." As above > Doesn't this mean the Local and Remote Interface IP Address sub-TLV > corresponds to just ONE TE-Link? Yes, it does. > There is no mention of "components" anywhere in this document. Even in > rfc4201, it is not clear that when multiple (component) TE-Links are > aggregated as a single numbered bundled link, there can be more than one > Interface IP address used for Local and Remote Interface IP Address. > > Could you please provide a reference where this is clarified as the mean > for > advertising multiple components at once. I don't think you will find such a reference. What is clear is that an implementation MAY assign multiple interface IP addresses. Therefore, there is nothing to stop an implementation using the component link identifiers as the set of interface IP addresses. Since each component link is in just one bundle, the use of a component link identifier uniquely identifies the bundle. This mechanism of advertising is, therefore, a clever way of advertising bundle membership information to the neighbor. If you want a more definitive statement of how this can work, you should probably develop an Applicability Statement I-D. Regards, Adrian > Thanks and best regards, > > Vijay > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, July 06, 2006 1:57 AM > To: Pandian, Vijay > Subject: Re: RFC3630 - Local and Remote Interface IP address > > > hi vijay - this was meant for advertizing multiple components at once > > > > > "Pandian, Vijay" > Sent by: owner-ccamp@ops.ietf.org > 06/07/2006 02:56 > > To: ospf@ietf.org > cc: mpls@ietf.org, ccamp@ops.ietf.org > Subject: RFC3630 - Local and Remote Interface IP address > > > Section 2.5.3 indicates that there can be more than one Local Interface IP > address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 > indicates that there can be more than one Remote Interface IP Address > assigned to a (numbered) TE-Link. > > Is there any requirement that the number of Local Interface IP address > assigned to a given TE-link match the number of Remote Interface IP > address. > > Specifically, can a TE-Link have just one Local Interface IP address but > multiple Remote Interface IP Address or vice-versa? > > Best regards, > > Vijay > > > > From owner-ccamp@ops.ietf.org Sun Sep 17 05:52:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOtKM-0007jk-RF for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:52:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOtKL-0001VI-Dc for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:52:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOtH0-000K2d-44 for ccamp-data@psg.com; Sun, 17 Sep 2006 09:49:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOtGy-000K26-SA for ccamp@ops.ietf.org; Sun, 17 Sep 2006 09:49:13 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k8H9n70s029810; Sun, 17 Sep 2006 11:49:07 +0200 In-Reply-To: <097c01c6da3c$1ab832d0$0a23fea9@your029b8cecfe> To: "Adrian Farrel" Cc: ccamp@ops.ietf.org, mpls@ietf.org, ospf@ietf.org, "Pandian, Vijay" Subject: Re: RFC3630 - Local and Remote Interface IP address MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 17 Sep 2006 11:48:55 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 09/17/2006 11:49:05, Serialize complete at 09/17/2006 11:49:05 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 adrian point is that one can have two different readings of these sentences either one assigns multiple IP addresses and configures a specific map of these addresses to components (e.g. sub-interfaces) or it is meant just to assign multiple IP addresses to an interface independently of this segmentation however, there is no bundling concept in this ref. or equivalently the bundling RFC maps a single (composed) TE link to a TE link (with specific aggregation rules when it comes to TE attributes) that is RFC4201 uses a single value for the link local/remote address/interface associated to the bundle thanks, - d. "Adrian Farrel" 17/09/2006 11:31 Please respond to "Adrian Farrel" To: "Pandian, Vijay" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: , , Subject: Re: RFC3630 - Local and Remote Interface IP address Hi Vijay, OSPF-TE implementers may wish to disagree with me on this, but I think Dimitri's definitive statement does not cover the basic reasoning for this feature. While it is true that one can use multiple link addresses to identify multiple component links, I think that the multiplicity of link addresses is provided in this RFC so that a single TE link may support multiple interfaces. This is an implementation choice, and may be advantageous in some cases. If the multiple link addresses are used to identify multiple component links, then I would expect a 1:1 correspondence between the link ends. If the addresses are used to identify different interfaces to the same link then I would not necessarily expect a 1:1 correspondence. In answer to your most recent questions: > Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link." And so it does. It describes a single TE link. A link bundle is still a single TE link, but it is made up of multiple component links that are not identified as TE links in their own right. > Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV > specifies the IP address(es) of the interface corresponding to this link." > > Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV > specifies the IP address(es) of the neighbor's interface corresponding to > this link." As above > Doesn't this mean the Local and Remote Interface IP Address sub-TLV > corresponds to just ONE TE-Link? Yes, it does. > There is no mention of "components" anywhere in this document. Even in > rfc4201, it is not clear that when multiple (component) TE-Links are > aggregated as a single numbered bundled link, there can be more than one > Interface IP address used for Local and Remote Interface IP Address. > > Could you please provide a reference where this is clarified as the mean > for > advertising multiple components at once. I don't think you will find such a reference. What is clear is that an implementation MAY assign multiple interface IP addresses. Therefore, there is nothing to stop an implementation using the component link identifiers as the set of interface IP addresses. Since each component link is in just one bundle, the use of a component link identifier uniquely identifies the bundle. This mechanism of advertising is, therefore, a clever way of advertising bundle membership information to the neighbor. If you want a more definitive statement of how this can work, you should probably develop an Applicability Statement I-D. Regards, Adrian > Thanks and best regards, > > Vijay > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, July 06, 2006 1:57 AM > To: Pandian, Vijay > Subject: Re: RFC3630 - Local and Remote Interface IP address > > > hi vijay - this was meant for advertizing multiple components at once > > > > > "Pandian, Vijay" > Sent by: owner-ccamp@ops.ietf.org > 06/07/2006 02:56 > > To: ospf@ietf.org > cc: mpls@ietf.org, ccamp@ops.ietf.org > Subject: RFC3630 - Local and Remote Interface IP address > > > Section 2.5.3 indicates that there can be more than one Local Interface IP > address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 > indicates that there can be more than one Remote Interface IP Address > assigned to a (numbered) TE-Link. > > Is there any requirement that the number of Local Interface IP address > assigned to a given TE-link match the number of Remote Interface IP > address. > > Specifically, can a TE-Link have just one Local Interface IP address but > multiple Remote Interface IP Address or vice-versa? > > Best regards, > > Vijay > > > > From owner-ccamp@ops.ietf.org Sun Sep 17 05:56:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOtOR-0000Gr-My for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:56:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOtOQ-0002ml-Cm for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:56:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOtLD-000KgE-Qm for ccamp-data@psg.com; Sun, 17 Sep 2006 09:53:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GOtLC-000Kfl-JO for ccamp@ops.ietf.org; Sun, 17 Sep 2006 09:53:34 +0000 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 1GOtLK-0005KH-00 for ccamp@ops.ietf.org; Sun, 17 Sep 2006 10:53:42 +0100 Received: from your029b8cecfe ([217.158.132.59] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Sep 2006 10:53:29 +0100 Message-ID: <099001c6da3f$19350de0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Pandian, Vijay" , References: <0679BA70A2F59E49B186858B47F4595C4E015B@viper.sycamorenet.com> Subject: Re: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Sun, 17 Sep 2006 10:49:33 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 17 Sep 2006 09:53:31.0708 (UTC) FILETIME=[2221E7C0:01C6DA3F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hi Vijay, > What is the rationale behind defining a new C-Type ( C-Type = 2, > suggested value, TBA by IANA) for the PROTECTION Object in > the e2e draft instead of extending C-Type = 1 defined in rfc3473? If you are familiar with the way RSVP has been developed over the years you will notice that this is standard practice. Consider the Session_Attribute object in RFC 3209. You will see two different C-Types here according to the content of the object. Perhaps a better example is the RSVP Hop object. This appears in RFC 2205 with C-Types 1 and 2 (for different uses) and is extended in RFC 3473 with two new C-Types. The C-Type is used to distinguish sub-types of the same object. This is, of course, useful, in normal implementation because it means that we don't have to make assumptions about the object's contents from parsing other fields (like the length). It is particulalry useful when a new variant of an object is introduced because it enables backward compatibility problems to be detected - a legacy implementation that does not support the new C-Type will reject the message (see RFC 2205) and the message sender can then take action to avoid the problem. In the case of draft-ietf-ccamp-gmpls-recovery-e2e-signaling, you'll notice that although the format of the first 8 bytes of the C-Type2 Protection object matches the C-Type1 Protection object in RFC 3473 with the adoption of some of the reserved bits, an extra 32 bit reserved field is added to the end of the object. (As indicated in draft-ietf-ccamp-gmpls-recovery-e2e-signaling, these 32 bits are defined in draft-ietf-ccamp-gmpls-segment-recovery.) So the processing for the two C-Types is different and it is useful to be able to distinction them through a different code point. > Should we consider C-Type = 1 as obsolete? Why? You must interoperate with 3473 implementations (always assuming interop is on your agenda) and any implementation not wanting e2e or segment protection can continue to use C-Type 1. Adrian From dkzhhz@home.nl Mon Sep 18 08:27:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPIDz-0007p8-KH for ccamp-archive@ietf.org; Mon, 18 Sep 2006 08:27:47 -0400 Received: from cp1066271-a.venlo1.lb.home.nl ([84.29.59.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPIDw-0003u0-Qo for ccamp-archive@ietf.org; Mon, 18 Sep 2006 08:27:47 -0400 Message-ID: <000901c6db1d$d478f830$a83b1d54@cp1066271a> From: "Sign" To: ccamp-archive@ietf.org Subject: not match any Make Date: Mon, 18 Sep 2006 14:27:39 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C6DB2E.9801C830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d ------=_NextPart_000_0005_01C6DB2E.9801C830 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C6DB2E.9801C830" ------=_NextPart_001_0006_01C6DB2E.9801C830 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable in Web Images VideoNew News Maps more raquo Advanced Search Members: = users: Join Alerts Create new group About Searched all groups Your = search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of Service = Privacy News Maps more raquo Advanced Search Members: users: Join Alerts Create = new group About Searched all groups Your search did not match any Make = sure words are spelled Try different keywords. Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on Sign in Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of Service = Privacy Policy Web Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can Home Help Sign in Web Images VideoNew News Maps more raquo Advanced = Search Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are spelled Try = different keywords. general fewer your on can try Answers for expert = help with search. Get the latest messages emailed to Alerts. Terms of ------=_NextPart_001_0006_01C6DB2E.9801C830 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
in Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of Service = Privacy
News Maps more raquo Advanced Search Members: users: Join = Alerts Create new group About Searched all groups Your search did not = match any Make sure words are spelled Try different = keywords.
Images VideoNew News Maps more raquo Advanced Search Members: = users: Join Alerts Create new group About Searched all groups Your = search did not match any Make sure words are spelled Try different = keywords. general fewer your on
Sign in Web Images VideoNew News Maps more raquo Advanced = Search Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are spelled Try = different keywords. general fewer your on can try Answers for expert = help with search. Get the latest messages emailed to Alerts. Terms of = Service Privacy Policy
Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert
Searched all groups Your search did not match any Make sure = words are spelled Try different keywords. general fewer your on = can
Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of
------=_NextPart_001_0006_01C6DB2E.9801C830-- ------=_NextPart_000_0005_01C6DB2E.9801C830 Content-Type: image/gif; name="search.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c6db1d$d478f830$a83b1d54@cp1066271a> R0lGODlhoAJQAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAXAAAALAAAAACgAlACBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky58sxs ljNr3sy5s+fPoEOLHk16c53SqFOrLlintevWq2PLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNn3iO9uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHZ4lTYehiji iCSWaCJPKpyo4oostujiizDGKOOMNNZo44045qjjjjyyZE6PQAYp5JBEFmnkkUgmqeSSTDbp JJO4PCnllFRWaeWVWGap5ZZcdglXHl6GKeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qeeefPbp55+ABirooIQWauihiCaq6KKMNuroo5AG2UOklFZq6aWYZqrpppx26umnoIYq6qik lmrqqaimquqqrLbq6qv/sMYq66y01mrrrbiSlUauvPbqK0Sn/SrssMQWa+yxXH2ALIL7LOvs s9BGK+201FZr7bXYZqvtttx26+234IYr7rjklmsujcycq+667JrLAqiQtOtdvPJ2R2+9+K6n Q77b7csvdv7+e13AAktHcMHRHYywcwov3FzDDkcs8cQUV8xExRhnrPHGHOdETccg83pKuf6E PCo3Jqes8sost+wyhfhQGsHLu81Ms24234xbzjrbxnPPtP0M9NBEFw1hsEYnrXSidizt9NNQ Ry311FRXbfXVWGcN7hlad+3112CHLfbYZJdt9tlop81RGGq37fbbcMct99x012333XjnzRIA /nr37beHuET5916CD2744YgnrvjijDfu+OOQRy755JRXbvnlmGeuud+VbO7556CHLvropJdu +umop6766qwvOUrrsMcu++y012777bjnrvvuvPfu++/ABy/88MQXb/zxyO+GSvLMN+/889BH L/301Fdv/fXYZ6/99tx37/334Icv/vjkl2/++Vzqg1sgzBuBfkfum+nC+woyQv/9+Oev//78 i6tM/wAMoAAHSMACGvCACEygAhfIwAY68IEQjKAEJ0jBClrwghjMoAY3yMEOehA8SPugCEdI whL2ZQomTKEKV8jCFrrwhTCMIYDGIMMa2vCGOMyhDnfIwx768IdA/gyiEIdIxCIa8Yh5+RES l8jEJjrxiVCMohSnSEUeUqKKWMyiFrfIxbrAgYJfnGAYJTjGCJYRgmfsohrXKKx2UNCNEoRj HN9IxzlOUI4RxCMb98jHPvrxj4AMpCAHWSd+EPKQiEykIhfJyMRIoJGQjKQkJ0nJSlrykpjM pCY3yclOevKToAylKEepNg+Q8pSoTKUqV8nKVv6Nfa6MpSxnScta2hIkqrilLndpSzLw8pfA DKYwh0nMYhrzmMhMpjKX6UBYMvOZ0IymNKdJzWpaU0cfu6Y2txkTEnDzm98s3APF6UByNtCc DEQnONfJzna6851taRY850nPetrznvjMKKc+98nPfvrznwANqEAHStCCGvSgCE2oQhfK0IYK 5BAMTcAEJaqWgAAAIfkEAAsAAAAsAAAAAKACUAIHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59Agwod SrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27dw48qd K9IP3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5YgfLmvezLmz58+gQ4se Tbq06dOoU190p7q165oTXsveDGW27du4c+t+CWS379/AgwsfTry48ePIkytfzry58+fQo0uf Tr269evYswMnoL2795ncv/6LH58yPPnz6D+aT8++fcX17uPLn0+/vv37+PPr38+/v///AAYo 4IAEFmjggQgmqOBaKizoYHANPihhbhFOaKFsFV6ooWoZPvXLhiBC1WFTH4ZoIlMjLlXiiSwm lSJSK7YoY1EvGhXjjDgGVSNRN+bo449ABinkkEQWaeSRSCap5JJMNunkk1BGKeWUVFZp5ZVY Zqnlllx26eWXYIYp5phklmnmmWimqeaabLbp5ptwxinnnHTWaeedeFIXSJ589unnn4AGKuig hBZq6KGIJqrooow26uijkEYq6aSUVmrpQGxcqummnHbq6aeghirqqKSWauqpqKaq6qqstupq mP9SvCrrrLTWauutuOaq66689urrr8AGK+ywxBZr7LHIJqvsssw26+yz0EYr7bTUVmvttdhm +xIM+ZmgbVF8fCvuuOR+tWe56Kar7rrstuvuu/DGK++89JZ0Tr2o+YCvgPruC2C//voHcMAE F2zwwQgnrPDCDDfscFlbPCzxxBRXbPHFGGes8cYcd+zxxyCHLPLIJJds8skop6zyyiy37PLL MMcs88w012zzzTjnrPPOPPfs889ABy300EQXbfTRSCet9NJMN+20uMY8LfXUVFdt9dVYZ631 1kOuwbVmXn9dWdhiU0Z22ZGdjfbabLft9ttwxy333HTXLTIhduet997+fA81Qt+ABy744Cax Q/jhiCeu+OKMN+4lOI7LBXnkcE1OuVuWf4vLhZlf7vnDZnzuVuiit0V66Wudjnpaqq9+Vuuu lwV77LTXbvvtuOeu++689+7778AHL/zwxBdv/PHIJ698WYIs7+Qbzkcv/fTUV2/99dhnb3UC 2nfv/ffghy++o4mMb/756Kev/vrst+/++/ATWUf89Ndv//3456///vz37///AAygAAdIwAIa 8IAITKDt3BA9ZSjwgRCMoAQnSMEKWvCCGMygBjfIwQ568IPzIQEIESLCERqkhHWyA6VQaMKB sLCF/3hhC2VoQhqO0Ia02saUcEgkf8Dwh0D+DKIQh0jEIhrxiEhMohKXyMQmOvGJUIyiFKdI xSpa8YpYzCKrkqDFh8mCManoohjHSMYyMi42ZkyjGtfIxja68Y1wjKMc50jHOl5tFXbMox73 yMc++vGPgLyYHgJJSAThjSwuKKQiF8nIRjqyUvh4pCQnSclKWpJPZ7ikJjfJyU56ckZx+KQo R0nKUprylKhMpSpXycpWuvKVsIylLGdJy1ra8pa4zKUud8nLXvryl8AMpjCJlplhGvOYyEym MpfJzGY685nQjKY0p0nNalrzmtjMpja3yc1uevObfwyDEMUZRHIC0Zw/RCcM1dlCdprQneCM pzznSc962vOe+ERbEyjyyc9++vOfAA2oYowg0IIa9KD+QQVCF8rQhjqUbz16qEQnStGKWvSi GM2oRjfK0Y569KMgPY8mQkrSkjrJhyZNaRo5oNKWuvSlMI2pTNm1hJna9KY4RVxAAAAh+QQA M8sAACwAAAAAoAJQAgcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBD ihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnwUJCCUwcKjRo0YNIhWIlChTof+I Jk36FGrVolaHRn0KtKvXr2DDih2b0irWrVGdSnWqVK3bolzTxkUb16xWpnXfkt3Lt6/fv4Bv mp0r9+zBrHoN4y3MtnBdxnMTB55MubLly5gJDnbMebNhxHQ9y23cWS1Xt6RFZ17NurXr1ys3 D55NGuvdtHZr407dOOtp271hCx9OvLhxh7J7K0cIerRizWuhSw+dnK3u49iza9/O127p6XQZ /kvm/Nn68vC+CXNfz769e5ygaU+XLx6u48S5I8/Xq/q9//8A5sSMX01RZeBSVd3VFHAJ7sbg VfatZV6AFFZo4YUYZqjhhhx26OGHIIYo4ogklmjiiSimqOKKLLbo4oswxijjjDTWaOONOOao 44489khiFABCMBAERAopUJFGGlTkP0IiOSSRTDIJ5ZFTLpnkk01KCaWTVE6ppZZNVonkmFsu OSSWY6KJJplkKmmmlQgl2SZBXIIJJptrmmlnQWw62WeYXqrZpZ54BurjoTEFaqihT1Lp6KNi ygnplVJO2qilmEZ5JKSVPuqpkVXSSemWnDKKqamKgiqnqpdGyaqm/5qG2imjXoZ55qy28vkq rq3miuivL6Wqa5yS8nprrruOWmytuxor67C9XkkrpZ5WK+xBYt4K7anSJitqQtdW2+m3qzq6 aLefNjsusOym5Ou5xCor7qaVqkptl9tmG+2X94Zb67oAixtuwJPeuymzmRoLK8HWokuuqA6X ua3C2Zbb7sUnvStvvBajaq6gujKb5roIw+kmxHX6Oi/AA5s6bp10vpxyxMWu3PC3KE88MryX IrwnvRgHLdLME2Orb6RZ4gtxvOne/HHSOlv888o8O33y0iF33Ky+C7tMssONKiu1wDT3DPXC Qqe9kdZn/qvt0R3jPDasXHP9tc3+gtoqwf7/tlzzrHvT/arddeNstOEsU6txvnfLbLPakGvE dr1bDz552Yln6jPPLucN9MBmN54w3HyG7vjpXRucecB9m2563clK6nXktDdk5Z99xvwmobtL ezCtX9o587RU9w6on8ZnjeeeywsfPJZ3jgzyoDm7ee60uec+KO8ic4987eCHL/745Jdv/vno p6/++uy37/778Mcv//z012///fjnr//+/JP/wUAfCKAAASjAABqkgAQsoAIVeEAGIhCBAlmg ASM4wIJUsIL/gGAGByjBCSYQgwD8oAcJ8j8KatCCGEyhB0GowRausIMHKeEGSwjCGWZwhh00 YA5zSEIe4tCHPf6UoQr7F6IRTvCFFGwgCm+4wQg2MYY0/N8KLZhEJh5RhgQMYRWR6MQnjtCL WDRiFJeYxSf2sIo27GIC17hFIU4RjGREIxbhaEYpRnGMN5yiCvF4xRD2kYw6xCMRPSTGMnKx jIg0oyLP2MQjJqSQiawjGuloRUG2kZFyDKMmJ6lIRzoyiGyEpB27eMhOCjGOlqQkJNmYxj9+ 8Y+MDCQnB5mhUWbylpic5CoBOco5xtGUSnRjLE9JyUs68ZB6FOYiRZnEOT6wmJ/UIS7zuElf 1lCaxgSmG6XpyjEq84twhCUtNWTLOgrylc7cZCRFaEJf5nKXzUwkLO/ozhNSE5HJ/P8gFGMZ TxI2Epo07CcytQnFFxp0ly385xX3uE13mjOM4+SQCw2pzEgi1KHoXOQ71flLURJTlksUIzIb mkVwMtOEVOSmJT/ZyoraE5yg/OcsCXpMKdKxj8KEKU6JGVEMffOnFj3lRbXISXFuNJfyVOcb QXrGN6oyoJc0qVKRakc+TpWihkxqDLGKVF06s6XGzKhOvfkBFLhoF/ADqjlnudOj4rCoFaVq KoM6TavyUo3dJGpe76rGZWZznsOUo1aVqEqNAvOYYbVrTdlK1pn29D8cBOICG+hDCPLQhYFE p2Yxes3OLrSq+pzsDtcIwxq+FaVEtWFmSYrammL2tPakJj3+JYjCz4q2qrT94W01udB1Pva3 wA2ucIdL3OIa97jITa5yl8vc5jr3udB10SeiS93qWve62M2uduUHje1697vgDa94x0ve8pr3 vOhNr3rXy972uve98I2vfOdL3/ra9774za9+98vf/vr3vwBeLjfAAoAAG3hEBT6wgj+UYOIA 4MH/aLBKHtxgCp9kABgegEEyzOGBcPjDIE5Ihv+hYQ+PWCAnRjGIR9zhFbv4xQRhcYxDrOIS kxjDJD6IjTu8YRxThMc3pnGQczxjHwf5xUA2cYtZnGThSvg1EI7wk1NiYYFMeSRGLoiPU6zh Em/5xiL28o7FrOQygxnMRu6yilH+fOYcb5nMbV7zkNks5yzT+cxZhrNE3kznL+PZxibWsprx HOcZrznNHjbulTMTZSsfxBAmKXCUFx0SOwfazV429KV7HGM51znNfEbzjjXt6U97GtCE9nOe BV1qRBfaIXkGdKw7zWpSx9nSpvZzohcckkYTpMoUhrCwgz0QYBNbypKWcIKFbeVJE7vRVZby Q3BNaDTbmtq4nvWRMZ3rUW/a2qaeM6eJjGM9j/vWXWYyqMWcYnRfG9Xh/ra2x13uQdua1xzx dbOlLe1h9zvZ/PZ3vwuybEn/e9/+Fri+FYLtTIO71fAutbwzXe4/n9jVEF83qptc7Yq/etPa 5nO9/0z/ZIi/W8fmdve3i/xmS1Mb3xdZuMIBnvAKOzvgBv91saF985pHGyINv3O7513roqda zaEG+cnH/Op2V3vOLwe1pkWe7ovDm+hER7nRs77ykd8b5hmROcAPXnNH99zmBlH2snFOdko3 BONPV/mpv67yqsd77hNnNcbtrGuSI0Tql6Z6oV0u68LTndTpPvmdB2/ul4O9ItA+eNsnf/ad p/3XNC/45CO8b1g33uEmD/zGve13csOZ76SXe+L9jvrFA77kdWe6qDse8aRL3NWh9nroedz6 U0f88TGPtrEzH2ybFz/ZFSa4rwt+/H8j3/JvF/KKab3tIzu9+koec+JdLOhY/rec+zJ2+vR3 XeOrF9776ob69bFf/u4zHcnsjv+Hsb9k3QM/JgtviNvn93v29P/+K5F/CpFz/PN/2mGAAIgS x+YQApiADviAEBiBEjiBFFiBFniBGJiBwGVh+6d8lMaBEPFzadeAYaZx8IeAGtheN+doDCGA K/gQJMhvEdF6p/dxKShfkceCC+GCyReC+xeDfzd6ineD9vVzz8ZzmmeEyzdsxYdzSAh9QNh1 hrdyRDhfC1h2zDZwI8hznEd5mcd2MsgQvRd6VXhfxrZ5zdaAZ5iEX1h2YThtQph3ZUhfaOeF mPeGdSiDWNiGmrdno4Z1qTeH7LWCe9iFAgeFeViI/274gmJIZoAocYKoXs+XhsiGiJNodvrG fM43dpWIbJy4EPDXftbneJGYgB1YiqjIEgSYiqyIf6fYirAYi7I4i7RYi5RxBLaYi7qIMQGw i/t1fFP2hBIBgiL4EQFwjANxjL1IEMqIjM24jL4oXjl4h9Dng50XhRbRi9r4D84IjdzYjN+o jNE4XtjYeTCobOYIEtuojex4EN7IjeM4Ir8QIFkIjMyniZW4hAfhbMZHiemoEOIoEN3ojgXx jvG4XVdocIqYhMq3j3zIeTP3EAE5kAbxjgZ5kNmVhXr4hf6okf+IcMSXhuVYkAOJjBVZkBgJ XpmIdgq3kSPokJLHga9IkP/r2I4oyYwpqZJPxoWF+JF6CJID15JvmBDr+I1GaZLwiJM5iZDC J5NM+JQ9uIX32IlNmYcMEZDhKJDQaJFLKSIawCIziRIXiYH3ID5fmSKr2JX8c5YnMpI7YQ1q SSJsGZd0SRBzWZd1eZd4GZd6uZdd2Zfnkw9+OYjF2IkMCIwtkQ+KORCKuZiDKY1qGJZ9GJYJ QZn/IJiYKRCN+ZjS2IKWOZQWYZmZmZmcSY6FeWzDN5RLeI/Ix4QiCZoHsZmaKZul6V1NeIeL mJbmGJEyGZN92BCy2ZiOCRs2UJszspIbyZAviXmTSXyMCBG0eZmCaZwqmY9jx4k8qHMveIbU CJ3/l/mdBDGd1IldHgmUh5idQBlwDWmIv7kQoymd4Dme5MmDTjmNzGl8zXebVQmbsemY0Smf 8PWZUumWDCGeAEqHXRhzOnegEkiglVmYDBqhEjqhFFqhFnqhGJqhGrqhHNqhHvqhIBqiIjqi sXgGJHqiKJqiKrqiLNqiLvqiMBqjMjqjNMo/mVCjOJqjOrqjPNqjPvqjQBqkQjqkRFqkRnqk SJqkSrqkTNqkTvqkUBqlUjqlVLo//AAR/JClDaGlVbpcXPoQX6oQYdqlxzWmDGGmZEpdV8ql WdqmA+GmAqGlbiqndHql/wCnaJqmRLSmdnqnfOqngBqocgqodkqndxqn/32qp+PUpn1qqIha qJB6qHBKqHmqqIPUqJHKpoKKqW/KppCaqJa6qJ2KqJS6qaMqqZlqqqG6p3XKqH7Kp4w6qZ/6 qK5KqquqpreKXmuaq+dVqbz6q8AarMI6rMRarBZxAi2iCE16AsyKrM16rMz6D8j6Ec36rBBh rQiBrdcarQKhrca6HdwqrdDardMqrhzBreHqEOl6EOvaEM4qrtPart96HOFarhNRrwNhrxmB rvrKEPJKEP+qEO9qrwE7r8SBruQar9X6rOmqrQtbrdLKr9i6sACrsBHrrBiLsfk6sfWqsBkb sSCbsAVRsAY7HNFqsfwKr+86shxLrhcbsiersf/rSrEum7IEK7MaC7Ixq7Mru7E3268lWxwn m7ApW7PZWrQ2i7I4y7Iuy7NGu7E8a607O7U967MVG7TgWq4ze7MGobUWC7M5u7Mvy7RgG7Jm W7M5C7ViK7b5Cq9Xi7XZ0bHd2rR0C7VlW7ZJa67s+rVsu7VOa65Ui7Yj67bxCrfa0bASS7Bd O7YXC7Fjy7AP+7MO67h6O7cd67EfK7gs67VAa7gA0rnnSrMSAbogQbqeGyBVW7oAO7qVe7rA QrIbQbnb6rq0W7u2e7u4m7u6i6IMaxKy6xIQ+7uM6627KxxFS61kixGmq65ee7RvW7wmq7iq +7wXsbzu2rx7S73Q+xr/7Qq5jfuwj+u4shuzkIuznNu44Vu+dWu2Emu3wru9rCGvazuwH5u3 Z4u3Muu0Q6u/SruyW0ux8/u38Mu9QBvATUuzBuy+S5ux5Ku2YeuxAtu8Acy2A9wa8vvACsy0 x3vAC3y/Uru07BuwcjvBaVvBFqy1miu3MJvC+mq/SKuygvvCGxzCfxu4JkzAiBu56Ju+L8ux ANy37SuyH9zAdRu86ou+onvDSrzETNzETvzEUBzFUjzFC2a9VPwSvdu1BQu+NUG8WryvC+HD Vqw/z8CKM2y3CXHGMCHC63uvLby6/gu7V3wS+Jq9EdzGawy6Y3y9g9u2AzvHXfy/CtyvSHu5 /yL7vWDrvYcsuuKbuENMtNgLx5hrtUQLyDLRyPjrwS07tTUMwoFLwvx7tzacwH4cyYv8vpa8 Ej6Mtt46v4rcybBMtR8cyqccw0obwSpcsVybyi2BvRj8r6Q8wrectxQcyghbyLGsxxnsx627 xxtKDzRCzLfczNOcv6AszStszJ48zNX8xhwMxzDszLzcEZn7vUbcwurbsqdsvt57xOl8zuR7 zkJMweVbzjw8zu4jzvi8z/zcz/5chdrwzwI90ARd0AZ90Aid0Aq90Azd0A790A5RAiUA0RRd EN5Q0Rid0Rq90Rzd0R790SAd0iI90iRd0ibNHWZw0iq90izd0i790v8F/QgwPdM0XdM2fdPH UQE6XQEDsdM+/dM+bRBALRBA/dP/UNQ7TRA8TdRJrdQ6fdROjdRPLdVPHdVQ3dNNfdRJTdVF rdVcjdVcvdRBzdQ8vdRkDdVhbdZkvdVG7dVmvdVuzdZRWtVYfdVVXdZq7dRMvddErdU9zdS1 0Nd8Pdh8Tdd2LdZ+XdhvrdeJndh0/diDjdd/LdaU/deCfdeOXdmKXdeZPdmazdlTrdmPLdqL bdhNatqGndp5DdqfHdmEzdmvDdlCrdaj/dqw3dp3vdiNHdubnRCq3dupTdit3dmMHdrATdux vdpLitq03dwIkdt77dyHfdV9XdtW7dvS3dn/q53Vwv3Zlf3WZV0Qta3cuw3dxC3eyj3VrI3e 0U3atu3X4D3Xef3bsI3eqv3b4B3c1h3V5H3fYz3W9h3f633ZWQ3gXg3W/d3c9G3a7w3gBo7g lL3g6c3d5J2kzM3Y7w3f8e3cG87f9X3d7H3b343duO3d0V3X2Q3fz83hAp7bxu3WKt7es83e 1s3gMS7YTwrZ9O3aKC7gIc7bvY3WH97dAy7URX7ew33h1V3h5S3ZQW7e5y3jPy7lUT7kUgrd Ox7l5i3bTT7ZA/7iNr7jUC7dNe7jJq7j363bGE7cZf7lpZ3k8+3ePI7mUPrVMB7Xox3aSC3i e/7VeD3hLv7ne+7Z/3HO3IGe1naO4GuN5/ld6BHe53ne6Iyu6JNu4zRt6VS8DPOD6Sc6BNih 6fLD3XMM6jjtIqRe6ixy6qiuIqq+6q7OmQIKgxgBhMUogrY+aTEZEUe4Ebsedm4X6xDqEfvp j8S+oBqB67y+gAzYa8qeb1d2m/oT6x+xaD9YbMa+k9h+eQkagta+7aHZ7TNZ7SAh7dxudtbe g7/eEZ/ZgVFJZdru7byOEO0OeeCjmy1B7bK+jwSXoLq5dsP47gq678s+gL02Yfx+8LBp7/T+ 7zvY7QYv8PB+7PLu8N9eO6vImwy5hr3p7064m9YZjBO/78k3mZjYkf0u8ogIkf1o7OZu8v+e uJtpufEEyJ0Q33PpeXaueXkjT/HP7u2pSZUKGfRa+PImD/Is6HOeSHM7p3b8jo8On4jbmfG4 bvRNn55AT/TkTiMcr55cr5Fr5+8JZ4hHP/YI351mP/YcD/Ytz57wzpNir4U5F4wsifDI/vXp qPZB2fJGD/Zxr/fXSPHaee6Av/fgLvboHvd8D5E6SPY+f4WMn/h9j5tvL/c52Pd2z/aQ74Ho /veHv/iQo+ybT/ZRGfp8X/p4/4EhX/hpL/p07/mFz56mz5+T3/pHD4KLv3xof5/vDmysT5Wv r+077/mU3+7o2Puzr/g+r4M7uaCn//qfqPq8L/D4mZz4uPVv//v/qCn4j2/x147926/8rN/8 3Y/6+s7819/8pB/yl4/3Z+/8tH/9ZQ+FuQ/45n/863/7ET/68Z/8v7/t6d/7AAHg3z8AAgce NGiQ4MGBChc+VCgwYkOKDR1CfIiQYcWJGwtmxBhSI0iRFyd27LhR5UqWLV2+hBlT5kyaNW2y dBgxoUWOFTHuDCmxZ1CNFxka9ekzJdCdKJM6Xci0J1ClU0dCFfp0aFOKVKNuBSu1qEquXUcm 1frTLFi2WclWPRq3ZEapXtWKPFt3bVaxYvNuLTv35mDChQ0fRjyzYMKPUU8yhsxz8WSJlQku vszzckqEmLt67sz0I2XSlSM33nza9GTN/qAtNsY8GvZszal1Qo5tufbu0plT20ZN0vbr0MQ9 zmbcufjm16Utu/YNnfRR0LdzV2cuW/nyzMi3A0+e/bZy1LqZn4edWP169u3de3z7/iZS+fXt 38dPk35+95zZ7+cvQJcAFLBAAw+sySgCA1wQQQcfhLBBCBM8678JL5TwQg03/C846AwMjkMR R+wvQxJb+hCxEE/EL0UWX4QxRhlnpLFGG2/EMUcdd+SxRx9/BDJIIYckskgjj0QySSWXZLJJ J5+EMkopp6SySiuvxDJLASkL7TrxWOPSOOOq885L7ppDcTSyqHIxrjDRQ8403770jLXfirsu T+vUfMlOw0wa/rA8QU3aL8U21TNxN+ISle/QAYdDS9Eu5/zTQ9m4dPS7THEycqmr/hqKrvjQ yglUuUyFT1KS7BrV009DLbWqkyoUFVZTWT1VwkJzKnSstWp9lFNhCWM01byK7XMwZF1FcSWo YiJQwbb0O3W+Ipm9tVVaQ60QW1KTrZZWXbN9NVdvAR32WW+FCxfaYLd1VtRn3x21XmsLixXe P5XlF65m7WV3WIG/bTdQfWVCNkZXmWUTVV+NBVZaiAGu7bkV68XWv1lr1ThdfxcuWNzkvBu4 QbdOdgzceLsbc2Q+o9MOTro4o69OviRzWWaWpZPszG6Leg7oiU/WqWW/xJ04WTZd/rbYvx/f 9POrSdGE1y3q/HQaqYvZ7SvSlZujmTpQibZU7LeEWsq1qKPt62h7TZZX6IC9VurmoEYm6le8 j9b6qqCjmxYiu4+Vuu+pBb/rOPLu6rpddA9e2e6uGx4yVq+spjzfpNMC9mDD12xcZZAuj8+p eQl2U2qO5dK8WTtPHxqmhjeee26sqMYqPb0BI13bvG8XXPeLTadXYtGCbSpPjj5HOmRh+apz r8eDtDze1vGqWeB1e337d1IvHZ11xz92unmzPSyX6y/hexxX8z3e/TE5bX/VLuLnup1v9uu3 1ftqQ7yf9kpnlef9alVm29b0Asaz1rAPc+XrUfUcVqqM/ukrX2HjlQX5lzfRSbB/YXsK7T53 QVS5L26Iw0v3/oUyERYvV4G73+z45zZ1taVxN0RdWZhnPLbARYf+m57VDgi58AmmhkKaDnD+ h6lBQW1FNpPTdKRoM9BdzTm6e96b7nQnMwVPeVs01njIlEQAYe0x2yHUeCgVpjH67DhrA1/M yqQdMEVxjuB549UWFTRLyVE1aRTPnNClNibmZmqGFBR5yqPENoKNbWkTn5jCoyUZJcwmlsyR JTG5OUoeZpPt+WSWINhJDoVSMU3CpClNaSBc0GiViCLlvWoXS1paaVO1ZNDWcLlLXvbyQXHw ZTCFOUxiFtOYx0RmTRqRTGY2/9OZz4RmNKU5TWpW05rXxGY2tfkeXVbqlQijjeNCeUsqdZOb jDKn4pyUTpx8UzHFcicRkelOE86yX6N0HrXs6cr6xFN0+0yUPx20oIBCTqD77GeUNoEgeroL lBSDKIWQmNACKXBgsqscRvVZu4MeVKNJAiDa8NYyOs1scSctGsu6M79BBZKOMBsdyXwVJ9Up Eo2rIWls6tYzkuZRZsejDfhgOr+bmjSDidwZyV62yOW0tHBk89uehKpOPi01qH/T2XmMhtI/ NtWkWl0pTpVnyM/gjE5YJeRX0wpWHdlPcmjb4N6kpzg1ARWGHLQrCn24Jsbx9Hx3+2DO3lo4 7O1upf4oxCHieidXSgEuryjbGbeI8li4EpCwnasf9FTXNsL+MJJPxWsYK8uqxIYOcKFVbArr KtnLRhCAuDNsYJK31FSJprR4CiPv7Je+sPTwL68rV+aWp5fDFRGIcYVtY8dk2N9GT5BxxeJw hTi5T23MbXr0HvAC85vhySqqrM0daWO7uvYFbrKGw6lwzBNBgg2SvJDFXPM8e9uark61uVUv YKqLxekGd6+X3e4OkWtfGiIwu+br70knK9neITeAk6zvgGU7reu99oStFSJ5wavSlJ2xvPjb YGO3m19V3Wi3B/4vASE7w7su2IjmTTGLP4tG1B5xvnsp7GZt2GLTUvd7OP52sYtPfOMgT1ha 2TuudnHsWf9a92Fj4+CM70vi0OavvVEGsmudeke11c1iXRJj0+roSNwIUqrhkY5Mz7q+1yLV TFB06WoQmVIEwvmlfdTNHBU0RUiVtTVTtbOcy2bmPc65q2L6KpgvRUc8z/mme5ZkHZlKV0bH TMpDZh2ejyXpRTqaN1rcZkbpJs+2lvJIFSSSR1sU6mfiE6E4UvVGU52+WIOIvaxutTnJWaNd 26fXNiLrqWvdqGHj2tjHRnaylb1sZjfb2c+GdrSlPW1qV9va18Z2trWNSyTn89Ua+jVfZf1O 2cWTnZckqLmHl241snXdUVPWuT3pVLD+Gt4qQv8nvdPMn03K+9b/MnGJx22hURcMbvT6Z8K/ 5u2DL/xrLHQYfve16vjxloiuJnXGf/swjA/0op1S+E22UVGNA7w/pGaeyR2O8JBvLloOXbnr OF7wb8Oc3xeG8MUvOfBTtrDmJI85rP8WRzQzemZ9LLRZu6OFJipXz3826nMJvUcOm1G2xouM mYm6XDUu2qdMfaJms7rV0uV5fWeb+Xpr2zMq4iqlVc0z07ae9p9h90OEUjoVVZq8ovathWof as6SKve9P7piZwc2T2VoxNGK7+/L6+ti/5vzqi4ZyIxtX+NTh2JMRxbyQ5RcjiuPZcq9ELVo j5/7zMgxrEJXyA2kG8T+Ude/vyJ2x3Wdb/b+LvnTCg++gF3tcTHLT/8Fb/I53muZj/6TNGfO uZlOz+ss/XrTp/e7XlyjOi1b+k/PloTo8Rn3j5/CJs88cv7F8vKByN/Ye3f2gjnb823rY8dE 97OyXxX7CUyuts3ft4kvvtDbsf+priuzvQGyrwT6Fg8Sns+rvgUqPhoTtwkbvsKLsBMyLfiD sgszPR2DIB6CMR67vM2TuBUzQAj8sM7DP6/xFJ/rIeGKGAf7P9oJuACsMQMqwI+hsBnziwzk vL4KMvwanBEEQvdKHPG7sQYTwM4LH+CJMCMzP4CBQdKhLwHEwSPsHBA0rsESPoGgB9kTLw// jELAOkDhwiH6usAXgQBHGg6iqzRD074uMzzuCicr0js1u0NL6w1GmjuiEzGvCycysbtK66lI YyLQAUTl+zO8s8NJAzND5A5ekcSt0kNJHDM61KI9gzOyo6qQQqqUgbo40yo8lL52uzud6rSs a7veeEOYGkVa6jhiKTlTozlcKzYWuUWeq0Fv2xJYnEWJ+jlw+0VrykUSKcZT+rdh5CZu87d4 O8bECDdqasZreUZomUYRIaRqVK5t48Zu9MZvBMdwFMdxJMdyNMdzRMd0VMd1ZMcl0cZ2hEZE k8dHkSNfe0dxO6esKzRJc5Za06Ww80etEchtTJBUusbvSBOJ4SiE/zmsYGRFerrHeHOtLJzF emI5DcoPE/En8RO+oNNFjwQ9Wfw4CDw/T8KXWmw5s8gggmTJAhLJ6/LIbruPhtqRBIsol9y5 kfTHjzTJpFEg7jlJhlS5flM5jETAieuXnpQ5EtQ9ifoki4rJkTy5h6pJ4xoaLuS7n/o6pdIY 62AkrYu7nAO/txOp8FMzKns/pmQptUMkQpukl4GTkVKUTdS7/DM+/dq7qxKaOmyqsqGzoKq/ UWwzDTqqz8vKtvsnotlKVezKSZEisIQZytOsl2K+vjuRpelHvho94kqt+4OxH3qsIuQWuwpN JYwUhUzLxYHCISq8kRI79EOfkGwxyLMyvf/CwN7awtNsvOPRwMOrQLeyQM6US4cLPiPsyMij TcuLwOA0K7PjzRHpGOIUQSf8IK/SIyIDk+GSLgOzre18IotDTdZEwOhRRPJhIZ06QdKyMHWJ Lp/rzvzquqmQQ/LzvuX6P5WMuOi8LepUIeurTvvELQBDk/cszy5MPfsrpUwsGbDwBuFksPHj vU8EzuWsvSXExwRUwHDhntBTPRmrKf3kLSZMLPejviO7qxE6TQPqwScbCzJCxNjczxCTzjSc wtF0QLCjqvsUQTHkRQzhJCM8Qxl9sSgLsLX70M/ETR/7PtS0Sc4BQgzdPycD0QeVzeN0TyIU wiR9wLUjMg78ig//W1AD5c/Yaa3/1J8jjaT4Ws4qvM1gtDWsAaM4u6I3mz6ZipNsXMu17Es/ Wsywkr553EQ2bCQlwpP0WkmxgSI5A8uuO0s4ijQys8O41JPvVLQyA0hE8zQ8wo4qqi1HjCkx m9O45LBINLpOJMtMpFM9NZq4y6M7NTpBZKsn8QYf9c2Hg0dhkslg+kuAi0grmdUI0RRevVVf 6lUg2VX4YbZffZBAbadiHVZcdFZjPUtOdTZlfdZrxdZs1dZtzdZi4NZvBddwFddxJVdsKody rZE2QCVsMxSIhEaozMwedVNkbCdOmsl5KzdN7Dmzk8j1eMh8vc4pqploBCdQm1ehdEZS/9VX AwOofotWispVWEJYqURWm1vWXbRXf6lA5FERgoNJKQzBiPNX1sJFqzDBdfmop1zXi+zYiQVJ W6VXYAXAm/xRp2xZqkQ5FTLKjMRYHeMci6xYkaRGfeQ6y6S3os2puoRLyvSqoptEyqQzpQs8 fVxaog28vBMpwhu9yDy8LtrZ4KwLxlSv6DPadpPOqE1RDR3KsqzDO51LRKWpS7SqqS3EPcUu ilRJRsxGvZnEsNrLoUPIFzkd0kzOMiVcw1SxQbLJyjsxxdI8GuNNMASUCI1cv8o9z0NDSLvQ 5tzBwtWvwWIy4nzctH2fCYS9m8FODQXNy9PbBgpd2Dmt3LS/If+MOtNUssOi3csMUQlyrkvk zvHyTvnKIfmE2bC1sPpbPJ+Vm6+DTR2EId9rQPqZ0Rj1LRi1T98dys843tIlqCj9oqNrHSnV 3jAEseKC3crKP9pyExRF3v3Zv+wi2F4k2Qb0wbDbvhib0hTcqS0dsY17IRfc3xccvxgs0eEF SjKl3vSj3/vsJveK2J/EqNok3ZRDibfzyfKrGov70gzGLLQNIPe9Xc6spBDVUurr3CE1QdKT Mf19Ute1FQA2XMTtveTr3BHNsK9lU+pU0hIOU9qlIDLVQTRTTuIK3yfjXdO9TdM8IPRVyI5p 3NB1Xup92H4k2kDDI64dxKbpqSaSqjX/sqMkgtsxmz4/49oucqJ7y85UJLtFE2OxctoEwg54 M7Q5zVOto7o9tFNqzVRB1TdUTSSvdLM/Vdizy8PJ7apPtNu7jWNAakTNLFWIoUs+G2N0Rcl7 zVigm7ZcPNaUxFlKhpJ3DE+PqzZNDtaP8mRpPEhEQbplnWJRSmV8mVYqPuVZpuVatuVbNpBo wOVd5uVe9uVfBuZgFuZhrpJWjlmBi1eG2khYHsh/dFcEZVlMZeOpimaGLVlW1g+NnA+D7CdS FLS5S2ZiGaejlcdXtmSdu1iXhVicfFl5JVmllDB1pthL9pGXYziKC8qpzJqQnWd53jkm7kBj Fs92PmdT9jVw/ymjY0boqVTbHr1hmnXnUkM4ez5opOxk0k1NgjZofkE18jsnUYzM0Wrb6dJT wGy6S92sq/JLpqlbTvRNRoYqP93K/ao6QYRLjB5oThnYqyO8Qeywt8QNySxnrf1LofrjLHYg TTlEvGtLshzbq2M7sxXV8WloWb7LsXPdMBO8SKy7L1U1ImZdzqseJ2vNLAM+1tNNxH1dEibS 5KzgKyut0e3MDC1ddv5ctA5JIe4sIpzctNCh1RVrI42pIfbc2zvrzAIw1P1ZnB5oJFvNITxM nKNP7jujgxVK6CHb9VPfpk2u7Bjf3/XZfX5hK9pSuwshx0M/pY5esE7TC67qQLHfHP/szUkz XuvzyvVFxGzJTuhLYcoGms2k0t8DrsHOLP+jVPrU2fZjSsi8TvPDbBPtys1uFAv0mwHTWNZ2 Pdtx0OGroeuB0vrd7vK56bgeT9eua4yJVwoU799D0w4ULarmQOPs4OtmURxdYuEWbAm0UO2D UrTM6QUkHPSS7DLdH/HW2OmOUiPdbtoLUlrDzd6cYcLeQOtGsdnm6wdXcEhubINr6PAWXr1W bBM2ayIGbPozThIaseuSvB4rYezu7x9+bQkO8bGOwnmBK9HeWI89HzdsSC4mbeJOVKy24khO ajZD26mu1EaCw7GDVTrWYkVbVKIao+dDclE1ar60acc8Vb7/JNQdTyqlLiqw2fGFtWM+u79S DbYhJyOrrXKBVdh9I2REHtCjPdRBJmNJmpBYrGjL9udiVkZjpUXo/PNMfppBl1g+t1gs0fNr CXRsNHRiBlgMMeeCJaX4redJV+UptnRI5/RO9/RPB/VQz9Z9EPVSh3RSN/VUB2ZUV/VW32VW d/VYp2VYl/VaR1dat/VcD1dc1/Ve11Ze9/VgH1ZgF/ZiX8d9IHZjV/ZlZ/Zmd/Znh/Zol/Zp p3Zpt4Vqx/ZsnzYL0PZuhzZu9/Zwb/Z3EPdyPzZyN/d03yZ0//QKcPd/cPd3j/d4h3d6H4h5 Vwl8r/cKgHeG0Pd9n/eA//d7f3d1/7cSdgf1gi/4fl/4huf3es/3h1f4hz+IhSf4fod4hqf4 i7d4g4cShE94iZf4iyd5i+/4ia/4jTj5jTf5jYf4jvf4JgH5UJd3eSf5jG95lRd5l694l8/5 nmcJmI/5oX+Qmuf3ndf3nwd6gof5lfd3luf5jCf6qYcQmz/6m0f5pdd6ptf5rt96oY96qhd7 Acl6qS97qS/5rTd7tFf6sB/7tw+Qsnf4pW96kb/5kj96qH96vIf7vo97uwf4wGd6nsf3vPd5 gU96e0f8u8c2Y/D7x4f8yJf8yaf8yrf8y8f8zNf8zef8zgcSx/f80P8RYwB90R9lg83mNLnk QR1Un3J9BP5P/VY1ENJ//W4eqI4ayFfbdIbV3HkTaGu2xr0F5DgyGGbu/Wu27ISmV/xLYc8p SmBMygA+9JWgfY2OR1Hu50QvuAPO/pztyd93aN/ZVZS1/oUL5e5fxutHf/dVXuWOynyOfniF f4ao/vWHZ1t7/py8Se4v/4ab/xkBCAD/BhIsSFCgQYT/BCociPDhwYgGJzqkaHHiQwAME17k 2PEjSJAQHWokuZDhRpMZD6ZU2RLjwogKG8akSLPgyowrT55sWbInT6A8Z87EaVFjzopDc6Lc WbKpx6csby5VKXRoVaE/r+JMSdQqSpNat4qVarVrzJ9IgT6Vqjbs2qBc05Zd+/7SJUuXb5l6 zYuV5E6bb4O2VTpYp0e6NpXWZFrzb9y2cN1WpOk07FjHITcnjCxxJGXIjS2fhVm0qNHFR/OC Npy0deXPG2EzTj0aMuzcZ0mDrY329umysRX3FYwVNETdjVO/Fut6+EjC0pdTL84aemm/xdUy vnz8ed/otp0axi66M3fVdH32/lsd+0vSyMs/Js/5Pm3l7JGyZ+6bvmKPCZgYTPTpFB1yCNZn YHr/Lfjeg7l5Jtd4w12EmoIYWtgTZqtV1+BW/D2HUXr9dVdZQ6gFqJ9dVLWmXIUiRvgZjaO9 2BVZElEHYVMw6ujggrPVuN+Qt23I24QQ7kjVfRcmpv5fkBX6N+CDK/5YoHo+zpjfjMTVJl+R SxroW4q8LcekjlxqGCCVORapJpm/jWllmt0paCGUnUU14pkgDrimmGeOmWJHgOqG5H9mAjjY mzLRaNZukJq3pqFNcmYmlMHRGeajjs6JpYCUfprcol1u9+SJPOaZZ51eGqdkf6R6Kd6Up5bH Ko9VblkqnnPKiiibO2oHa6qiHmoeqtPdmCuBxSY7qKddKtnmh6MKZ6lIOcYFmIiSFcYtUd2G u9dU4FLIH1ktTlYXVN4uBRVbPW4LGI70FtYhh4QhNm+868ZJ7lXocisXwOneK69kWb1LosDe lomujAuriyNmAJfbcMLaEv68b8EZT4bxxs7RiyLFLdqLL78BPwvxuwnXyFXEF9sVssqMYnsz zjnrfOXOPfucM5o/Wxq00M0WfTTSSeuqntI6E01001FLTWWhoE599dFQY721SFyHpHXRYHs9 dtY8G022h1WjvXbPYv/JNtxxy41tymvXPTfeeV/oJnp6X8q333nfzXDghRt+OOKJK7444407 /jjkkUs+OeWVW3455plrvjnnnXv+Oeihiz466aWbfjrqqau+Ouutuy464H6RHftmbtduO+YQ 41uopGjT3jbuH/1OodfDJ2781chnKzbuyo8NtaJTB81k8PhJXr2vX8vONvaX+qyi2jtX373Z OP4HT37YbQP5M/pNQ3+2++HDz/716tvm5P12S93+0mk7fXP7+Lc++cEtgMnzm1lCxB2XRWZ3 rDlYc8jVwJONrHf6qs9dJriwrEiqgUkBjmM06BbagUlkVBtLtRQYKXg5BzFz+dYIv+IvDcJs gdsbUQw7NLHfQKqD1tnWDmVGs3618GA49IkOX9MxDJoNhrNZYgWd+EGC6e2Dp6rUdAokKyPZ Ckaxig94jHSrME6KUHS617VWZR2mfSdUWcILeeZzJ2htKo1EUpagXJUmIb1NjvABEIOIYxm4 RElY1ZpV9jLFJ+H48Yx8pNWw3HMsV32RklWUicm2dyfw+WeTsktXuf4KOS2t9OqTSfJKkr4U Jk9+qETv6+S8XLTKYpUIkBWkYpysZSyKEc9ZMbPRoDKZqFpycllpMaMmMdm7cL2tlYlS5nyc BcwTiopB3zqXqW4puGgNC4ucxGSgNJXGUlUzkTxbpqeih0xW4SpU09uTLI1SzQzpck9MLCan YnUkEiXrLum00zBzaUxgmahBPOQmQZv5q2duyJ3ZpE0/pXkTFZ5xUpf8I7MwBMmXeTOjJypn rsC3UDd+aozZw6NHDdmskbZqnoysZ63y+CcvPhSjmEKWRUlqq1niU6Y7DSQiQ2pOldpQqHTc KEpdOlJ9WrKK4oriDEN0QXtCtV8UfeoOhf7JIZMJbGT6EqkLTcmx4zysYhz7JhCNSLhQcvWJ U3mqg3SX1ol+1atdhWtd9dTWvukuinYdJMi6Gq8NprVeJCuidrTa177K8ytErKrD+GZWF4qw Y/Bqq2A/R9fXHZBz50uf5b7JOAGKT3+cLd78TgvazTWvbKEtn+JI+z+uzUy1WBucbZGG28jt Vk7sc97hems44e4PuL+VbW6Tq9zlMre5zn0udKMr3elSt7rWvS52s6vd7XK3u979LnjDK97x kvd6SNWT+6bXvOj1km7Gld57XcvPJsX3hl9zm/GQW979Cm9o9N1ff0/oP/wBbYCzM+E2/Ttb 2Oava/x9sNxaa/+9qD3NwKllcO0KJ9q5fXbBFhbwgCEs4r1RdjtmJewUyUpBqdY1iHW5J1oW iEbJcnFmg6SZu1BYW8f20GZslSAEOehW41y1XTpkoopdc2NJxsdmnpkiEP8qIwXqd8Sq22II x5lRMxbVPjtdox8Dc9LzxLiMMzVzOLMcZpxiOVXvaST1lhrN5gDHpFxuj8byaEU++vTNOLUy dtc5ZhYZdEuCnmY0+9bnmFYpZcuCaJBOKU1VGTNfn+Rop7T5yzpNGdN9ApGMBTPQqNSWp5m2 JF4Brd1D05RZVzKUJ+mZTD8LlFfJqaUYaSXOSbOyiyQlsqePmVICZ9DTWxz0nRf9MoX+mnTR Up1olVVtujar6qSQ1tCckfXTSTI7nAw9tiG7zGuJGhXMpRQpuVX60jQfdajJpnajPIptbgY1 2tIuHZVXPOSBMYpfco0ykFk8l61CUFssY2AsHUZEUBb5sgGvymKTqOjMtPBLLJsqONnFlhZP FlyZ9fjHDIZYq37sZMzMZJTvDWF7h5iAcBOAg0HMct5emI2o27DK7z1zq7n8eAzeueM2O+HV 4TzngCbu94ZX3wKScOmwcx7SPRd1o1O96la/OtazrvWtc73rXv862MMu9rGTvexmPzvauS7Y i5Pp4y+k8rjiDm2KPpaCJk94KC29cAumve9+b5WuhN6mJf//WkU9dXP/0I34wktJWn9/vN8N vxh1ckRTm5W8zQOD1kuvj8WXbynkQ993zBOK8vL8J1UB9e1AxWjSqP88r0Qve7LHrPaqzN9S tZjwPMd0883eNEs5XcfZE9/r4jl+LFeaU0bbEvYmAr3q7YwlIRW9+Nan+vFBdXjpU0tY1NMi 5xsv8OlDksfIvD76r475fd5e/D9a//kPjfjnK7795+9f+vOPfbiL66yOduW45J1cMQwzKdnE pBzbqcxbTV+D6Z8DPiAERqAETiAFVqAFXiAGZqAGbiAHdqAH5pwmfKAIjiAJlqAJniAKpqAK riALtqALviAMxqAMziAN1qAN3iAO/+agDu4gD/agD/6g1wABEA4hERahER4hEiahEi4hEzah Ez4hFEahFE4hFRKhKFQhFmahFm4hF3bh1/EDGPIDQYQhGZYhGU7EGZ7hGBpEGP6DGI4hGBaE Gg7EG7phGcLhHdKhGeahHe5hG/phHMphG+phHA5iH7phH4rhHKYhIPLhHFJEHRoiIKLhH+4h HiIiIwbiIWbiGhJiI/qhF6qWJuohItohHZoiJEZiHaIiKbIiIV4iHApiK7LiKhZiK0biLdLi GwaiJvKiKnYiKvpiLMriLeLiKLoiJQoiLgbjKs6iMBajMzbjM5YiLeZiLzJjKHLWMY4iNzbj MLpiNwLjK/+O4yzqYjkS4zmiozliIzju4jJyYzSy4S8i4zZ6ozoq4i7GIzo+Izyu4zDyojqW Yz2mYzaCxDNwzkB+IzJ+4zX24jHioSJWo0P+Y0TKY0De4zzyYy26Yyc+pD/qoy2eo0ee4jWa IkeKZEaepEWmYyGGJCZK40ZS4zQW5OokpEDaYyJKYjs+JD6+5BpOZDHyZExaRDfm4SOGYzUu ZE7Wo1FKIkxeRE+eoknqI0QO4kxWpVBu4k8+JUR2JU26jk22I1HOYyJSojROpUMCJTZ6I1Km 4j5ypFqyYyn6Yksq5Dq6ZFjKY0ke4kfe5Ukyol2ipUwa4k0OplJ+pek05FA641v/SmUw2iU+ /iVFTqZbBqZCAmVdFmZSYiZZgiRX+qRjGiY1yqVNaiRlKuU0dmZbkuJIIibpCONqziRmUuY2 QqNopuYyamZleiZvMqZtxqVfbiVrquRtEuNVBudvduZpquZiRmVmuuZrNqIneqJTtuQdpiFf XqJ1ZqIlUmdauqNHqiF3cuJ0KiNM0mVkquJ2fqJ0vmJ3kiQfdiUolid3JiMzpid9Smd8Qid/ ghdO9ieAXtd/BiiBFqiBHiiCJqiCLiiDNqiDPiiERuj1sadX/qEywmJZumclgidhZmhZmiFW duhSfudYVmR5siFWlqh6YqiFvieFfqJejuYibih7rud8/45od86oiWpljeoleMpoU8YnW9ri eFKoZTJhSAIkbZ4nMOKmb9omab5jSV6lZMrlchKnWC4kbuamaTqmZHKmODqpP6pkVGIilEop fJ4pmf6lMWJply5pk3KlmComVULhai4niiopUvLjSsommabpXCqnbtIjml7mUIYlQOppLRKk oZ7mSgaqcRYqZELpbrKjbAokSmZqUsKpfWIqcjIkljrhnQYlUbKmblrnaFrqob6jqfbloDLl o0pkSsaqokJqMuJkW8KmWdLqn05lq4JqqjaqqlZqLM5qpOIqm8qoqwYnWR5nE46qLvJkq+Zq ZKaqI65qR06roGYpSzrlPkarPf/uqbam4kgWpXiKqIfuqZSSKIui605ia6eap1c+6iOeqIeC JmqCaLo26xRCK6zKISxSq5nKKXGmppeKKa9e5DhS60Rm5T8GbLjuKEZO5n9aJbxC6i8upq/G 63NqZGYCZsYOaYzKYsPKK0GCabPmpp1q7MOKZKROrJYmK54CaZ0Kq8tSqpKupci2LKUe6amG 6sFq5pR+JmO2pliCqZpmqsMqZ8eeZc/2JrBiob/KbJgaq6Mm7ZiG5pvGqpVi7V5u7Zk2plTu pc0a7JVS5Z/SqUmqrNCuaW+qbUJSKdWaqFq6razW7LNaLFNGZIcS5kYu7Xn2reDSJcDqq1kG LiRm54n/0ih5mqzi/i2HDi6H4qjfKu69ZmiNZi7ifqjh1uu5TmJ18u3eUm595qeNwqjPSqgG Gq3qtq7nsK7rxm7muKvs1q7t3i7u5q7u7i7v9q7v/u4EGu68tqt6Fq+OmufnDuaOvmiOuuSF 4udREq92jmiIVm97tqiLhm5R2qqGourBdi6R0ui8ai6yiq7wGm/ktmd2WiiG7mtahmh4QiyT pifoki/k6muPjuz6Dmh3+Wm3cmmV5uz+yuzWfqmxHuebxubXzu2xdqSkOmdF1ipygq3ZbmY+ DqumFqs1Iuu4iiY0GjA5Wm0II+369myu9mna/uhjKuaKYjBoAm7XihcJ0+Nj/3Jrvraw2ZJt 2TLwPdYpPErw2HLwC/tmacJschIxwWrtznoqcCIqyzLkRaorzDqnp0pvllLxR57wtxKqDzPp wlLt08Im0PqnCNemryowuYouqV4oVDYnmwoxvbapA3MvydonXLYsXoanxnap4N4qXnKxZTYx 0UKr5brsDIvrGQ8odvovxqLt0e5qHWPtry4yAdNtqIoxo37XITttku5xuKLlmprrWCLvli4x KctxENPx8ObixuaxKBvxfW5uaA4n3QLyyQqvLduwj3JtmdbrFXdwqYav0AKz2v6q4+qoAtMp BIfuKoPqou7XJqPoF8OycEKw/pKjEcst0UZtukKsW//ubAu3ssQ+ricPJyQHK5Eq7yBHLGSu s8KyMUo2rDsrb1AuqjD/8jRHY16ObB5X6h/fs2mGbGV2LH9FM8A6qr/yJZ+ycr6Kbc7u813y bAwfpgCj8UHbsBQv8EdUsEXHMb1itMoy50Vj8hS/rCEX8AV7rc2OtJuy86Ra7BGTrEs/54Mx srRGLURXckzrsUODMRLzbEXz66bW8Kui8p3OqU7bMQAH5NC2szkLqxRfJqcOM05zst2SbQKv 9FSXaTbbKh8bNThbc3nh8uU+ruPa6ybSL/a2acSiJ46+ZPlOriW+J5Cip/b2oz5TMuTu8nSu dSC/MeZKbl/fdZCmrz2/MuNtbqjpRu8qV6L7hjNcV2dgS6ve3uhig+jpVvZcIzZwAq9nfzZo h7ZojzZpl7ZpnzZqp7Zqr7YM8i9rvzZsx7ZszzZt17Zt3zZu57Zu7zZv97Zv/zZwB7dwDzdx F7dxHzdyJ7dyLzdzN7dzR2FAAAA7 ------=_NextPart_000_0005_01C6DB2E.9801C830-- From owner-ccamp@ops.ietf.org Tue Sep 19 08:58:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfB2-0004HK-DW for ccamp-archive@ietf.org; Tue, 19 Sep 2006 08:58:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfAv-00021t-L9 for ccamp-archive@ietf.org; Tue, 19 Sep 2006 08:58:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPeuz-0007FO-4L for ccamp-data@psg.com; Tue, 19 Sep 2006 12:41:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [130.209.249.184] (helo=mr1.dcs.gla.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPeuu-0007Ep-UZ for ccamp@ops.ietf.org; Tue, 19 Sep 2006 12:41:37 +0000 Received: from ex1.ad.dcs.gla.ac.uk ([130.209.249.157]:30460) by mr1.dcs.gla.ac.uk with esmtp (Exim 4.42) id 1GPeut-0007ze-71; Tue, 19 Sep 2006 13:41:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DBE8.F1529B3A" Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Date: Tue, 19 Sep 2006 13:45:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Thread-Index: AcajzYu3Wna7e+MHRe2xxdCgls5b7A4GVrqQ From: "Olufemi Komolafe" To: , Cc: "ccamp" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DBE8.F1529B3A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 While reading this draft it occurred to me that perhaps it might be more useful to approach this topic from the perspective of "What can go wrong during graceful restart, what are the consequences and how can it be fixed?" rather than focusing on the narrower topic of multiple simultaneous nodal faults. =20 For example, Scenario 1 in the draft may be interpreted as "What should happen if a (non-ingress) restarting node fails to get a RecoveryPath message from its downstream neighbour?", Scenario 2 is "What should happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?" and so on. Whether each of these scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other reason (e.g. a subsequent control channel failure, restarting node being inundated with messages etc.) is, in my opinion, secondary. I think the key thing is to identify the potential problems and suggest appropriate remedial actions, where the authors think existing documentation is insufficient, rather than focusing on 5 different permutations of multiple node graceful restart. =20 =20 Regards, Femi =20 =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Sent: 10 July 2006 04:04 To: danli@huawei.com; gjhhit@huawei.com Cc: ccamp Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,=20 =20 Dear Authors,=20 =20 This is Deja-vu to me....=20 =20 Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by the WG as addressing multiple node restart case is NOT a goal (suffers from the law of diminishing return). In other words the following statement in the ID-=20 =20 "[GR-EXT] also extends the Hello message to exchange information about=20 the ability to support the RecoveryPath message.=20 The examples and procedures in [GR-EXT] focus on the description of a single node restart when adjacent network nodes are operative.=20 Although the procedures are equally applicable to multi-node restarts,=20 no detailed explanation is provided."=20 =20 is not accurate. Please see section 4 on the earlier version of the [GR-EXT], http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-rest art-extensions-00.txt .=20 =20 Thanks =20 Regards... Zafar=20 =20 ------_=_NextPart_001_01C6DBE8.F1529B3A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

While reading this draft it occurred to me that perhaps it might = be more useful to approach this topic from the perspective of “What = can go wrong during graceful restart, what are the consequences and how can it = be fixed?” rather than focusing on the narrower topic of multiple simultaneous nodal faults.

 

For example, Scenario 1 in the draft may be interpreted as = “What should happen if a (non-ingress) restarting node fails to get a = RecoveryPath message from its downstream neighbour?”, Scenario 2 is “What should = happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?” and so on.  Whether each of these = scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other = reason (e.g. a subsequent control channel failure, restarting node being = inundated with messages etc.) is, in my opinion, secondary.  I think the key = thing is to identify the potential problems and suggest appropriate remedial = actions, where the authors think existing documentation is insufficient, rather = than focusing on 5 different permutations of multiple node graceful = restart.   

 

Regards,

Femi

 

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 10 July 2006 = 04:04
To: danli@huawei.com; gjhhit@huawei.com
Cc: ccamp
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,

 

Dear Authors,

 

This is Deja-vu to me.... =

 

Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by = the WG as addressing multiple node restart case is NOT a goal (suffers = from the law of diminishing return). In other words the following statement in = the ID- =

 

   "[GR-EXT] also extends the Hello = message to exchange information about

   the ability to support the RecoveryPath message.

   The examples and procedures in [GR-EXT] = focus on the description of a

   single node restart when adjacent = network nodes are operative.

   Although the procedures are equally = applicable to multi-node restarts,

   no detailed explanation is = provided."

 

is not accurate. Please see section 4 on the earlier = version of the [GR-EXT], http://www.faqs.org/ftp/pub/= internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt<= /font>. =

 

Thanks

 

Regards... Zafar

 

------_=_NextPart_001_01C6DBE8.F1529B3A-- From owner-ccamp@ops.ietf.org Tue Sep 19 23:10:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPsTI-00064m-U0 for ccamp-archive@ietf.org; Tue, 19 Sep 2006 23:10:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPsTA-0007FJ-9R for ccamp-archive@ietf.org; Tue, 19 Sep 2006 23:10:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPsMX-00086s-F2 for ccamp-data@psg.com; Wed, 20 Sep 2006 03:03:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, HTML_40_50,HTML_MESSAGE,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT, NO_REAL_NAME,RCVD_DOUBLE_IP_SPAM autolearn=no version=3.1.1 Received: from [202.103.147.155] (helo=mx4.zte.com.cn) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPsMP-00085U-Vo; Wed, 20 Sep 2006 03:02:58 +0000 Received: from [10.30.1.239] by 10.30.1.243 with StormMail ESMTP id 5901.6685817259; Wed, 20 Sep 2006 11:52:51 +0800 (CST) In-Reply-To: To: "Olufemi Komolafe" Cc: "ccamp" , danli@huawei.com, gjhhit@huawei.com, owner-ccamp@ops.ietf.org Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: jiang.weilian@zte.com.cn Date: Wed, 20 Sep 2006 10:57:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-09-20 11:02:27 Content-Type: multipart/mixed; boundary="=_mixed 00109675482571EF_=" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.5 (++++) X-Scan-Signature: 510197464235b7be9252a74662931ef9 --=_mixed 00109675482571EF_= Content-Type: multipart/alternative; boundary="=_alternative 00109677482571EF_=" --=_alternative 00109677482571EF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8sIGV2ZXJ5b25lIQ0KDQpXZSBoYXZlIHB1dCBmb3J3YXJkIGEgbWVjaGFuaXNtIHRvIHNv bHZlIHRoaXMgcHJvYmxlbSBpbiBvdXIgDQpkcmFmdCAiZHJhZnQtamlhbi1jY2FtcC1tdWx0aW5v ZGVzLXJzdnAtcmVzdGFydC0wMCIgbGFzdCB5ZWFyLg0KDQpXZSB0aGluayB0aGF0IGlmIG11bHRp cGxlIGFkamFjZW50IG5vZGVzIHJlc3RhcnRlZCBuZWFybHkgYXQgDQp0aGUgc2FtZSB0aW1lLCB0 aGVzZSBub2RlcyBjYW5ub3QgbGVhcm4gYWJvdXQgdGhlIEdSIGNhcGFiaWxpdHkgDQpmcm9tIGVh Y2ggb3RoZXIuIA0KDQpUaGUga2V5IG9mIHRoaXMgcHJvYmxlbSBpcyB0aGF0IGhvdyByZXN0YXJ0 ZWQgbm9kZSBhY3RpdmVseSANCmluZm9ybSBpdHMgR1IoR3JhY2VmdWwgUmVzdGFydCkgY2FwYWJp bGl0eSB0byBuZWlnaGJvciBub2RlcywgDQplc3BlY2lhbGx5IHNvbWUgbmVpZ2hib3Igbm9kZXMg YXJlIHJlc3RhcnRlZCBub2RlcyB0b28uDQoNCklmIHlvdSBjb25jZXJuIG91ciBtZWNoYW5pc20s IHBsZWFzZSByZWFkIG91ciBkcmFmdCBmb3IgZGV0YWlsLg0KDQoNCg0KDQpSZWdhcmQsDQpKaWFu ZyBXZWlsaWFuDQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Lg0KQWRkOiAgIE5vLjY4IFppamluZ2h1YSBSZCxZdWh1YXRhaSBEaXN0cmljdCwgDQogICAgICAg IE5hbmppbmcuIFAuUi5DaGluYS4gDQpaaXA6ICAgMjEwMDEyIA0KVGVsOiAgIDAwODYtMjUtNTI4 NzE2NDQgDQpNYWlsOiAgamlhbmcud2VpbGlhbkB6dGUuY29tLmNuIA0KLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIA0KDQoNCg0KDQoNCiJPbHVmZW1pIEtvbW9s YWZlIiA8ZmVtaUBkY3MuZ2xhLmFjLnVrPg0Kt6K8/sjLo7ogb3duZXItY2NhbXBAb3BzLmlldGYu b3JnDQoNCjIwMDYtMDktMTkgMjA6NDUNCiANCiAgICAgICAgytW8/sjLo7ogICAgICAgIDxkYW5s aUBodWF3ZWkuY29tPiwgPGdqaGhpdEBodWF3ZWkuY29tPg0KICAgICAgICCzrcvNo7ogICJjY2Ft cCIgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCiAgICAgICAg1vfM4qO6ICBSRTogQ29tbWVudHMgb24g ZHJhZnQtbGktY2NhbXAtbXVsdGlub2Rlcy1nci1wcm9jLTAwLnR4dCwNCg0KDQpIaSwNCiANCldo aWxlIHJlYWRpbmcgdGhpcyBkcmFmdCBpdCBvY2N1cnJlZCB0byBtZSB0aGF0IHBlcmhhcHMgaXQg bWlnaHQgYmUgbW9yZSANCnVzZWZ1bCB0byBhcHByb2FjaCB0aGlzIHRvcGljIGZyb20gdGhlIHBl cnNwZWN0aXZlIG9mIKGwV2hhdCBjYW4gZ28gd3JvbmcgDQpkdXJpbmcgZ3JhY2VmdWwgcmVzdGFy dCwgd2hhdCBhcmUgdGhlIGNvbnNlcXVlbmNlcyBhbmQgaG93IGNhbiBpdCBiZSANCmZpeGVkP6Gx IHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHRoZSBuYXJyb3dlciB0b3BpYyBvZiBtdWx0aXBsZSAN CnNpbXVsdGFuZW91cyBub2RhbCBmYXVsdHMuDQogDQpGb3IgZXhhbXBsZSwgU2NlbmFyaW8gMSBp biB0aGUgZHJhZnQgbWF5IGJlIGludGVycHJldGVkIGFzIKGwV2hhdCBzaG91bGQgDQpoYXBwZW4g aWYgYSAobm9uLWluZ3Jlc3MpIHJlc3RhcnRpbmcgbm9kZSBmYWlscyB0byBnZXQgYSBSZWNvdmVy eVBhdGggDQptZXNzYWdlIGZyb20gaXRzIGRvd25zdHJlYW0gbmVpZ2hib3VyP6GxLCBTY2VuYXJp byAyIGlzIKGwV2hhdCBzaG91bGQgDQpoYXBwZW4gaWYgYSAobm9uLWluZ3Jlc3MpIHJlc3RhcnRp bmcgbm9kZSBmYWlscyB0byBnZXQgYSBQYXRoIG1lc3NhZ2UgZnJvbSANCml0cyB1cHN0cmVhbSBu ZWlnaGJvdXI/obEgYW5kIHNvIG9uLiAgV2hldGhlciBlYWNoIG9mIHRoZXNlIHNjZW5hcmlvcyAN CmFyaXNlcyBkdWUgdG8gbXVsdGlwbGUgc2ltdWx0YW5lb3VzIG5vZGFsIGZhdWx0cyAoYXMgaW4g dGhlIGRyYWZ0KSBvciBhbnkgDQpvdGhlciByZWFzb24gKGUuZy4gYSBzdWJzZXF1ZW50IGNvbnRy b2wgY2hhbm5lbCBmYWlsdXJlLCByZXN0YXJ0aW5nIG5vZGUgDQpiZWluZyBpbnVuZGF0ZWQgd2l0 aCBtZXNzYWdlcyBldGMuKSBpcywgaW4gbXkgb3Bpbmlvbiwgc2Vjb25kYXJ5LiAgSSB0aGluayAN CnRoZSBrZXkgdGhpbmcgaXMgdG8gaWRlbnRpZnkgdGhlIHBvdGVudGlhbCBwcm9ibGVtcyBhbmQg c3VnZ2VzdCANCmFwcHJvcHJpYXRlIHJlbWVkaWFsIGFjdGlvbnMsIHdoZXJlIHRoZSBhdXRob3Jz IHRoaW5rIGV4aXN0aW5nIA0KZG9jdW1lbnRhdGlvbiBpcyBpbnN1ZmZpY2llbnQsIHJhdGhlciB0 aGFuIGZvY3VzaW5nIG9uIDUgZGlmZmVyZW50IA0KcGVybXV0YXRpb25zIG9mIG11bHRpcGxlIG5v ZGUgZ3JhY2VmdWwgcmVzdGFydC4gDQogDQpSZWdhcmRzLA0KRmVtaQ0KIA0KIA0KDQpGcm9tOiBv d25lci1jY2FtcEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmdd IE9uIEJlaGFsZiANCk9mIFphZmFyIEFsaSAoemFsaSkNClNlbnQ6IDEwIEp1bHkgMjAwNiAwNDow NA0KVG86IGRhbmxpQGh1YXdlaS5jb207IGdqaGhpdEBodWF3ZWkuY29tDQpDYzogY2NhbXANClN1 YmplY3Q6IENvbW1lbnRzIG9uIGRyYWZ0LWxpLWNjYW1wLW11bHRpbm9kZXMtZ3ItcHJvYy0wMC50 eHQsIA0KIA0KRGVhciBBdXRob3JzLCANCiANClRoaXMgaXMgRGVqYS12dSB0byBtZS4uLi4gDQog DQpEcmFmdCBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtcmVzdGFydC1leHQtMDUudHh0IGFjdHVhbGx5 IGhhZCBhIHNlY3Rpb24gb24gDQptdWx0aXBsZSBub2RlIHJlc3RhcnQgY2FzZSBhbmQgd2FzIHJl amVjdGVkIGJ5IHRoZSBXRyBhcyBhZGRyZXNzaW5nIA0KbXVsdGlwbGUgbm9kZSByZXN0YXJ0IGNh c2UgaXMgTk9UIGEgZ29hbCAoc3VmZmVycyBmcm9tIHRoZSBsYXcgb2YgDQpkaW1pbmlzaGluZyBy ZXR1cm4pLiBJbiBvdGhlciB3b3JkcyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiB0aGUgSUQt IA0KIA0KICAgIltHUi1FWFRdIGFsc28gZXh0ZW5kcyB0aGUgSGVsbG8gbWVzc2FnZSB0byBleGNo YW5nZSBpbmZvcm1hdGlvbiBhYm91dCANCiAgIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgdGhlIFJl Y292ZXJ5UGF0aCBtZXNzYWdlLiANCiAgIFRoZSBleGFtcGxlcyBhbmQgcHJvY2VkdXJlcyBpbiBb R1ItRVhUXSBmb2N1cyBvbiB0aGUgZGVzY3JpcHRpb24gb2YgYSANCiAgIHNpbmdsZSBub2RlIHJl c3RhcnQgd2hlbiBhZGphY2VudCBuZXR3b3JrIG5vZGVzIGFyZSBvcGVyYXRpdmUuIA0KICAgQWx0 aG91Z2ggdGhlIHByb2NlZHVyZXMgYXJlIGVxdWFsbHkgYXBwbGljYWJsZSB0byBtdWx0aS1ub2Rl IHJlc3RhcnRzLCANCiAgIG5vIGRldGFpbGVkIGV4cGxhbmF0aW9uIGlzIHByb3ZpZGVkLiIgDQog DQppcyBub3QgYWNjdXJhdGUuIFBsZWFzZSBzZWUgc2VjdGlvbiA0IG9uIHRoZSBlYXJsaWVyIHZl cnNpb24gb2YgdGhlIA0KW0dSLUVYVF0sIA0KaHR0cDovL3d3dy5mYXFzLm9yZy9mdHAvcHViL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1yYWhtYW4tY2NhbXAtcnN2cC1yZXN0YXJ0LWV4dGVuc2lvbnMt MDAudHh0DQouIA0KIA0KVGhhbmtzDQogDQpSZWdhcmRzLi4uIFphZmFyIA0KIA0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbSANCnN5c3RlbS4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00109677482571EF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvLCBldmVyeW9uZSE8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGhhdmUgcHV0 IGZvcndhcmQgYSBtZWNoYW5pc20gdG8gc29sdmUNCnRoaXMgcHJvYmxlbSBpbiBvdXIgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5kcmFmdCAmcXVvdDtkcmFmdC1q aWFuLWNjYW1wLW11bHRpbm9kZXMtcnN2cC1yZXN0YXJ0LTAwJnF1b3Q7DQpsYXN0IHllYXIuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSB0aGluayB0 aGF0IGlmIG11bHRpcGxlIGFkamFjZW50IG5vZGVzDQpyZXN0YXJ0ZWQgbmVhcmx5IGF0IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIHNhbWUgdGltZSwgdGhl c2Ugbm9kZXMgY2Fubm90IGxlYXJuDQphYm91dCB0aGUgR1IgY2FwYWJpbGl0eSA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZyb20gZWFjaCBvdGhlci4gPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUga2V5IG9mIHRo aXMgcHJvYmxlbSBpcyB0aGF0IGhvdw0KcmVzdGFydGVkIG5vZGUgYWN0aXZlbHkgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbmZvcm0gaXRzIEdSKEdyYWNlZnVs IFJlc3RhcnQpIGNhcGFiaWxpdHkNCnRvIG5laWdoYm9yIG5vZGVzLCA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmVzcGVjaWFsbHkgc29tZSBuZWlnaGJvciBub2Rl cyBhcmUgcmVzdGFydGVkDQpub2RlcyB0b28uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB5b3UgY29uY2VybiBvdXIgbWVjaGFuaXNtLCBwbGVhc2UN CnJlYWQgb3VyIGRyYWZ0IGZvciBkZXRhaWwuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmQsPGJyPg0KSmlhbmcg V2VpbGlhbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48YnI+DQpBZGQ6ICZuYnNw OyBOby42OCBaaWppbmdodWEgUmQsWXVodWF0YWkgRGlzdHJpY3QsIDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtOYW5qaW5nLiBQLlIuQ2hpbmEuIDxicj4NClppcDogJm5ic3A7IDIx MDAxMiA8YnI+DQpUZWw6ICZuYnNwOyAwMDg2LTI1LTUyODcxNjQ0IDxicj4NCk1haWw6ICZuYnNw O2ppYW5nLndlaWxpYW5AenRlLmNvbS5jbiA8YnI+DQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4gPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7T2x1ZmVtaSBLb21vbGFmZSZxdW90OyAmbHQ7ZmVt aUBkY3MuZ2xhLmFjLnVrJmd0OzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPreivP7Iy6O6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvZm9udD4NCjxicj4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA2LTA5LTE5IDIwOjQ1PC9mb250 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IMrVvP7Iy6O6DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bHQ7ZGFubGlAaHVhd2VpLmNvbSZndDssICZsdDtnamhoaXRAaHVhd2VpLmNvbSZndDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyCzrcvNo7oNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2NjYW1wJnF1 b3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg1vfM4qO6DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRTogQ29tbWVudHMgb24gZHJhZnQtbGktY2NhbXAtbXVs dGlub2Rlcy1nci1wcm9jLTAwLnR4dCw8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5IaSw8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPldoaWxlIHJlYWRpbmcgdGhpcyBkcmFmdCBpdCBv Y2N1cnJlZA0KdG8gbWUgdGhhdCBwZXJoYXBzIGl0IG1pZ2h0IGJlIG1vcmUgdXNlZnVsIHRvIGFw cHJvYWNoIHRoaXMgdG9waWMgZnJvbQ0KdGhlIHBlcnNwZWN0aXZlIG9mIKGwV2hhdCBjYW4gZ28g d3JvbmcgZHVyaW5nIGdyYWNlZnVsIHJlc3RhcnQsIHdoYXQgYXJlDQp0aGUgY29uc2VxdWVuY2Vz IGFuZCBob3cgY2FuIGl0IGJlIGZpeGVkP6GxIHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHRoZQ0K bmFycm93ZXIgdG9waWMgb2YgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIG5vZGFsIGZhdWx0cy48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZvciBleGFtcGxlLCBT Y2VuYXJpbyAxIGluIHRoZQ0KZHJhZnQgbWF5IGJlIGludGVycHJldGVkIGFzIKGwV2hhdCBzaG91 bGQgaGFwcGVuIGlmIGEgKG5vbi1pbmdyZXNzKSByZXN0YXJ0aW5nDQpub2RlIGZhaWxzIHRvIGdl dCBhIFJlY292ZXJ5UGF0aCBtZXNzYWdlIGZyb20gaXRzIGRvd25zdHJlYW0gbmVpZ2hib3VyP6Gx LA0KU2NlbmFyaW8gMiBpcyChsFdoYXQgc2hvdWxkIGhhcHBlbiBpZiBhIChub24taW5ncmVzcykg cmVzdGFydGluZyBub2RlDQpmYWlscyB0byBnZXQgYSBQYXRoIG1lc3NhZ2UgZnJvbSBpdHMgdXBz dHJlYW0gbmVpZ2hib3VyP6GxIGFuZCBzbyBvbi4NCiZuYnNwO1doZXRoZXIgZWFjaCBvZiB0aGVz ZSBzY2VuYXJpb3MgYXJpc2VzIGR1ZSB0byBtdWx0aXBsZSBzaW11bHRhbmVvdXMNCm5vZGFsIGZh dWx0cyAoYXMgaW4gdGhlIGRyYWZ0KSBvciBhbnkgb3RoZXIgcmVhc29uIChlLmcuIGEgc3Vic2Vx dWVudCBjb250cm9sDQpjaGFubmVsIGZhaWx1cmUsIHJlc3RhcnRpbmcgbm9kZSBiZWluZyBpbnVu ZGF0ZWQgd2l0aCBtZXNzYWdlcyBldGMuKSBpcywNCmluIG15IG9waW5pb24sIHNlY29uZGFyeS4g Jm5ic3A7SSB0aGluayB0aGUga2V5IHRoaW5nIGlzIHRvIGlkZW50aWZ5IHRoZQ0KcG90ZW50aWFs IHByb2JsZW1zIGFuZCBzdWdnZXN0IGFwcHJvcHJpYXRlIHJlbWVkaWFsIGFjdGlvbnMsIHdoZXJl IHRoZQ0KYXV0aG9ycyB0aGluayBleGlzdGluZyBkb2N1bWVudGF0aW9uIGlzIGluc3VmZmljaWVu dCwgcmF0aGVyIHRoYW4gZm9jdXNpbmcNCm9uIDUgZGlmZmVyZW50IHBlcm11dGF0aW9ucyBvZiBt dWx0aXBsZSBub2RlIGdyYWNlZnVsIHJlc3RhcnQuICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZlbWk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGRpdiBhbGlnbj1j ZW50ZXI+DQo8YnI+DQo8aHI+PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ PGI+RnJvbTo8L2I+IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1w QG9wcy5pZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WmFmYXIgQWxpICh6YWxpKTxiPjxi cj4NClNlbnQ6PC9iPiAxMCBKdWx5IDIwMDYgMDQ6MDQ8Yj48YnI+DQpUbzo8L2I+IGRhbmxpQGh1 YXdlaS5jb207IGdqaGhpdEBodWF3ZWkuY29tPGI+PGJyPg0KQ2M6PC9iPiBjY2FtcDxiPjxicj4N ClN1YmplY3Q6PC9iPiBDb21tZW50cyBvbiBkcmFmdC1saS1jY2FtcC1tdWx0aW5vZGVzLWdyLXBy b2MtMDAudHh0LCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RGVhciBBdXRo b3JzLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+VGhpcyBpcyBEZWphLXZ1 IHRvIG1lLi4uLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RHJhZnQgPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmRyYWZ0LWlldGYtY2NhbXAt cnN2cC1yZXN0YXJ0LWV4dC0wNS50eHQNCmFjdHVhbGx5IGhhZCBhIHNlY3Rpb24gb24gbXVsdGlw bGUgbm9kZSByZXN0YXJ0IGNhc2UgYW5kIHdhcyByZWplY3RlZCBieQ0KdGhlIFdHIGFzIGFkZHJl c3NpbmcgbXVsdGlwbGUgbm9kZSByZXN0YXJ0IGNhc2UgaXMgTk9UIGEgZ29hbCAoc3VmZmVycw0K ZnJvbSB0aGUgbGF3IG9mIGRpbWluaXNoaW5nIHJldHVybikuIEluIG90aGVyIHdvcmRzIHRoZSBm b2xsb3dpbmcgc3RhdGVtZW50DQppbiB0aGUgSUQtIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7JnF1b3Q7W0dSLUVYVF0gYWxzbyBleHRlbmRzDQp0aGUg SGVsbG8gbWVzc2FnZSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbiBhYm91dCA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7dGhlIGFiaWxpdHkgdG8gc3Vw cG9ydCB0aGUgUmVjb3ZlcnlQYXRoDQptZXNzYWdlLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7VGhlIGV4YW1wbGVzIGFuZCBwcm9jZWR1cmVzDQpp biBbR1ItRVhUXSBmb2N1cyBvbiB0aGUgZGVzY3JpcHRpb24gb2YgYSA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7c2luZ2xlIG5vZGUgcmVzdGFydCB3 aGVuIGFkamFjZW50DQpuZXR3b3JrIG5vZGVzIGFyZSBvcGVyYXRpdmUuIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDtBbHRob3VnaCB0aGUgcHJvY2Vk dXJlcyBhcmUNCmVxdWFsbHkgYXBwbGljYWJsZSB0byBtdWx0aS1ub2RlIHJlc3RhcnRzLCA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7bm8gZGV0YWls ZWQgZXhwbGFuYXRpb24gaXMgcHJvdmlkZWQuJnF1b3Q7DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+aXMgbm90IGFjY3VyYXRlLiBQbGVhc2Ugc2VlIHNlY3Rpb24gNCBvbg0K dGhlIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGUgW0dSLUVYVF0sIDwvZm9udD48YSBocmVmPSJodHRw Oi8vd3d3LmZhcXMub3JnL2Z0cC9wdWIvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJhaG1hbi1jY2Ft cC1yc3ZwLXJlc3RhcnQtZXh0ZW5zaW9ucy0wMC50eHQiPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IkFyaWFsIj48dT5odHRwOi8vd3d3LmZhcXMub3JnL2Z0cC9wdWIvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXJhaG1hbi1jY2FtcC1yc3ZwLXJlc3RhcnQtZXh0ZW5zaW9ucy0wMC50eHQ8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPi4NCjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRzLi4uIFphZmFyIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxi cj48Zm9udCBzaXplPTM+PHR0Pjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwvdHQ+ PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1 cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5l ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3By b3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4m bmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZp ZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZu YnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5k Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZu YnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55 Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZu YnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5i c3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5i c3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25v dGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3Nh Z2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2Jl ZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0m bmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00109677482571EF_=-- --=_mixed 00109675482571EF_= Content-Type: text/plain; name="draft-jian-ccamp-multinodes-rsvp-restart-00.txt" Content-Disposition: attachment; filename="draft-jian-ccamp-multinodes-rsvp-restart-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group JiangWeilian(ZTE Corporation) FengJun(ZTE Corporation) Internet-Draft CuiYing(ZTE Corporation) Expires: May 20, 2006 KongYong(ZTE Corporation) LuoJian(ZTE Corporation) =20 November 20, 2005 =20 =20 Mechanism of multiple adjacent nodes RSVP=20 graceful restart Simultaneously draft-jian-ccamp-multinodes-rsvp-restart-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 5 of RFC3209, Section 9 of RFC3473. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Luojian Expires: May 2006 [Page 1] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 Abstract Based on the RSVP graceful restart defined in the RFC3473, RFC3209,=20 Node ID RSVP Hello:A Clarification Statement (draft-ietf-ccamp-rsvp -node-id-based-hello-02) and the Extensions to GMPLS RSVP Graceful Restart (draft-ietf-ccamp-rsvp-restart-ext-05), this document puts=20 forward extension to solve the problem for the restart node to actively inform RSVP graceful restart to the neighbor, and further provides the relevant mechanism to support recovery processing of RSVP graceful restart at simultaneous restart of multiple adjacent=20 nodes. Table of Contents 1. Conventions used in this document. . . . . . . . . . . . . . 3 2. Terms and abbreviation . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Actively Informing Neighbor=20 of RSVP GR Capability by Restarted Node . . . . . . . . . . . 4 4.1 Adopting Multicast Address . . . . . . . . . . . . . . . . . 4 4.2 Adopting Hot Backup . . . . . . . . . . . . . . . . . . . . . 5 5. RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes . . . . . . . . . . . . . . . . 5 5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel . . . . . . . . . . . . . . . . . . . . . 5 5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node. . . . . . . . . . . . .. . . . . . . . . 7 5.4 Multiple Adjacent Restart Nodes Contain=20 All the Tunnel Nodes. . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . 9 =20 Luojian Expires: May 2006 [Page 2] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in [RFC-2119]. 2 Terms and abbreviation Suppose the reader is familiar with terms defined in [RFC3209],=20 [RFC3473]. 3 Overview In the RSVP Graceful Restart defined in Section 9 of RFC3473, the=20 Hello mechanism defined by RFC3209 is extended to support GR (Graceful Restart) capability informing and fault detection between RSVP neighbors. It aims to define Resatrt=5FCap object for Hello=20 extension to carry GR capability parameter and inform it to the=20 neighbor through Hello message interaction. The Hello mechanism defined by RFC3209 defines the message=20 destination address and source address as the inter-neighbor=20 interface IP address in turn. In draft-ietf-ccamp-rsvp-node-id-based -hello-02, the extension defines that the destination address and=20 source address of Hello message supporting GR are TE RouterID of=20 respective nodes. Then, the restart node is usually at a passive position. Only after=20 it receives the RSVP GR Hello message from the neighbor, will it=20 inform the neighbor of its GR capability b returning the ACK message.=20 For restart of a single node, GR capability informing in the passive=20 mode is also acceptable. If multiple adjacent nodes restart at the same time, however, these=20 nodes cannot learn about the GR capability from each other. This=20 document puts forward the solution of using the multicast address as destination address or adopting the hot backup technology to=20 implement active informing of restarted node RSVP GR capability, and further provides the relevant mechanism to support recovery=20 processing of RSVP GR at simultaneous restart of multiple adjacent=20 nodes. Luojian Expires: May 2006 [Page 3] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 4 Actively Informing Neighbor of RSVP GR Capability by Restarted Node 4.1 Adopting Multicast Address After the node restarts and makes sure it supports RSVP GR Recovery, it can periodically send the GR HELLO message outward in the 1/2=20 RecoveryTime through all the RSVP interfaces to inform its GR=20 capability. Main field data composing the GR HELLO request message: The destination IP address is multicast address (IPv4: 224.0.0.2; IPv6: FF02:0:0:0:0:0:0:2). The source IP address is the local TE RouterID. The source instance value is the created value (the neighbors=20 under different interfaces can be the same). The destination instance value is 0. The Restart time value of Restart=5FCap object is the local=20 configuration value. The Recovery time of Restart=5FCap object is the local configuration value. The R digit value of Capability object is 1 (it indicates the node supports receiving of the RecoveryPath message). The T digit value of Capability object is 1 (it indicates the node supports sending of the RecoveryPath message). The S digit value of Capability object is 0 (it indicates the node does not support abstract refreshing message; for support, it can=20 be set as 1). The Reserved digit value of Capability object is 0. =20 When the neighbor receives the GR HELLO request message with this=20 destination address as multicast address, it can first use the=20 informed source RouterID as the neighbor RouterID and local RouterID to query if the corresponding HELLO instance exists: If the instance does not exist, it will create a corresponding=20 instance, save the GR capability parameter informed by the peer,=20 and confirms restart of the peer node based on the fact that the=20 destination IP address is the multicast address. According to the=20 informed GR capability parameter, it confirms that the peer is in the Recovery stage, replies the ACK message to the restart=20 neighbor based on its GR capability, and then creates the=20 corresponding Recovery Timer. Luojian Expires: May 2006 [Page 4] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 If the instance exists, it will save the GR capability parameter informed by the peer, and reply the ACK message to the restart=20 neighbor based on its GR capability. =20 After receiving the ACK reply message from the neighbor, the restart node can create the corresponding GR Hello instance in accordance=20 with the information in the message. By now, the GR Hello relation=20 between the restart node and neighbor node is reestablished. If the destination IP address of the GR HELLO request message=20 received by the restart node from its neighbor is also the multicast address, it means that the neighbor node is also a restart node. In this case, it similarly creates a corresponding instance, saves the GR capability parameter informed by the peer, confirms that the peer node is restarted and in the Recovery stage, and creates the=20 corresponding Recovery Timer. After 1/2RecoveryTime, the restart node must stop sending of the GR Hello message with the destination IP address as multicast address.=20 In stead, it just implements GR Hello communication according to the created GR Hello instance. 4.2 Adopting Hot Backup If the node conducts hot backup of key data for the established GR HELLO instance, such as the neighbor RouterID, local RouterID, source instance value, destination instance value, outgoing interface and=20 the next-hop address. Then, the restart node, after hot backup switching and restart, can get the hot backup GR HELLO instance data before restart, and=20 actively constitute a GR Hello instance based on these data to send a new GR Hello message to inform the neighbor. Then, it=20 reestablishes the GR HELLO relation with the neighbor node. 5 RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes Suppose Tunnel1 is established along with the LSR1-LSR2-LSR3-LSR4=20 path. LSR1, LSR2, LSR3 and LSR4 all support RSVP GR, and all the=20 nodes support sending and receiving of the Recovery Path message. 5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel Suppose LSR2 and LSR3 start at the same time. LSR1 and LSR4 enter the Restart stage, and they send the GR Hello=20 message to LSR2 and LSR3 in turn. Luojian Expires: May 2006 [Page 5] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 After the LSR2 and LSR3 restart, they will enter the GR Recovery stage according to the configuration. With the method described in Section 4, a GR Hello relation can be set up between LSR2 and LSR3, and they can learn that the peer party is in the GR Recovery stage. At the same time, LSR1 and LSR4 will send the GR Hello request message to LSR2 and LSR3 in turn, and LSR2 and LSR3 will create the corresponding GR HELLO instance, respond to the request messages from LSR1 and LSR4, inform the peer party of support to GR, and then enter the Recovery stage together. After that, LSR1 will send the Path message with Recovery Label=20 object to LSR2. (if sending and receiving of RecoveryPath message are supported, LSR4 will also send the RecoveryPath message to LSR3). =20 After receiving the Path message with Recovery Label object, LSR2=20 will check if the corresponding PSB exists. Suppose it cannot be=20 found, but the corresponding entry is found from the MPLS forwarding=20 table, LSR2 will create the corresponding PSB. However, because the GR Hello relation has been established between LSR2 and LSR3, and they learn that the peer part is in the GR=20 Recovery stage, then LSR2 can send the Path message carrying Recovery Label object to LSR3. Here, the outgoing label and outgoing interface are obtained by query of the forwarding table, and the next-hop=20 address can be obtained through the ERO object of Path message sent=20 upstream. After receiving the Path message carrying Recovery Label object from the restart node LSR2, LSR3 will find out if the corresponding PSB exists according to the received Path message. Suppose it is not=20 found, but the corresponding entry is found from the MPLS forwarding table. Then, LSR3 creates the corresponding PSB, constitutes the=20 Path message containing Suggested Label object and sends it to the downstream LSR4. After receiving the Path refreshing message containing Suggested=20 Label object from the restart node LSR3, LSR4 resolves the incoming label of LSP for recovery through the Suggested=5FLabel object in the Path message. Then, it matches the corresponding RSB, refreshes (clears) the stale flag for the corresponding forwarding table=20 entry, and triggers the corresponding Resv message to send it to=20 LSR3. LSR3 receives the Resv message from LSR4, creates RSB and associates the corresponding PSB. Now, both the incoming label and outgoing label are refreshed. LSR3 clears the stale flag for the corresponding forwarding entry and sends the Resv message to LSR2. Luojian Expires: May 2006 [Page 6] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 LSR2 receives the Resv message from LSR3, creates RSB and associates the corresponding PSB. Now, both the incoming label and outgoing=20 label are refreshed. LSR2 clears the stale flag for the corresponding forwarding entry and sends the Resv message to LSR1. LSR1 receives the Resv message, refreshes RSB, and clears the stale=20 flag of relevant protocol state. Now, Tunnel1 is completely=20 recovered. 5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node Suppose LSR2, LSR3 and LSR4 start at the same time. LSR1 enters the Restart stage, and it sends the GR Hello message to LSR2. After LSR2, LSR3 and LSR4 all restart, they will enter the GR=20 Recovery stage according to the configuration. With the method=20 described in Section 4, a GR Hello relation can be set up between=20 LSR2, LSR3 and LSR4, and they can learn that the peer party is in=20 the GR Recovery stage. At the same time, LSR1 will send the GR Hello request message to=20 LSR2, and LSR2 will create the corresponding GR HELLO instance,=20 respond to the request messages from LSR1, inform the peer party of support to GR, and then enter the Recovery stage together. After that, LSR1 will send the Path message with Recovery Label=20 object to LSR2. The following handing is the same as the description in Section 5.1. The Path message is sent to LSR3. After handing by LSR3, the=20 Path carrying Recovery Label object is sent to LSR4, instead of the Path message carrying Suggested Label object. Then, LSR4 sends the Resv message upstream, and each hop is=20 recovered in turn along with the upstream path till LSR1. Finally,=20 Tunnel1 is completely recovered. 5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node Suppose LSR1, LSR2 and LSR3 start at the same time. =20 LSR4 enters the Restart stage, and it sends the GR Hello message to LSR3. After LSR1, LSR2 and LSR3 all restart, they will enter the GR=20 Recovery stage according to the configuration. With the method=20 described in Section 4, a GR Hello relation can be set up between LSR1, LSR2 and LSR3, and they can learn that the peer party is in=20 the GR Recovery stage. Luojian Expires: May 2006 [Page 7] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 At the same time, LSR4 will send the GR Hello request message to LSR3, and LSR3 will create the corresponding GR HELLO instance,=20 respond to the request messages from LSR4, inform the peer party of=20 support to GR, and then enter the Recovery stage together. After that, only LSR4 will send the Recovery Path message to LSR3. (therefore, we suppose all the nodes support sending and receiving of the Recovery Path message.) When receiving the RecoveryPath message from the assistant node=20 LSR4, LSR3 will find out if the corresponding PSB exists according to the received PATH message. Suppose it is not found, but the corresponding entry is found from the MPLS forwarding table. Then,=20 LSR3 creates the corresponding PSB (possibly the original Path=20 message should have the RRO object, which can be used to get the=20 previous-hop address and recover the ERO containing the previous-hop address), and constitutes the Path message containing Suggested Label object to send it to the downstream LSR4 and wait for the Resv=20 message from LSR4. After receiving the Path refreshing message containing Suggested Label object from the restart node LSR3, LSR4 resolves the incoming label of LSP for recovery through the Suggested=5FLabel object in the=20 Path message. Then, it matches the corresponding RSB, refreshes=20 (clears) the stale mark for the corresponding forwarding table entry,=20 and triggers the corresponding Resv message to send it to LSR3. After receiving the Resv message from LSR4, LSR3 creates the=20 corresponding RSB, and refreshes (clears) the stale flag for the=20 corresponding forwarding table entry. Then, LSR3 will send the=20 Recovery Path message to LSR2. The same as handling of LSR3, LSR2, after receiving the RecoveryPath message from LSR3, will create the corresponding PSB, constitute the=20 Path message containing Suggested Label object to send it to the=20 downstream LSR3 and wait for the Resv message from LSR3. =20 After receiving the Resv message from LSR3, LSR2 creates the=20 corresponding RSB, and refreshes (clears) the stale flag for the corresponding forwarding table entry. Then, LSR2 will send the=20 Recovery Path message to LSR1. Similarly, LSR1 creates the corresponding PSB and RSB, and refreshes (clears) the stale flag for the corresponding forwarding table entry. Now, Tunnel1 is completely recovered. Luojian Expires: May 2006 [Page 8] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 5.4 Multiple Adjacent Restart Nodes Contain All the Tunnel Nodes Suppose LSR1, LSR2, LSR3 and LSR4 start at the same time. After LSR1, LSR2, LSR3 and LSR4 all restart, they will enter the GR Recovery stage according to the configuration. With the method=20 described in Section 4, a GR Hello relation can be set up between=20 LSR1, LSR2, LSR3 and LSR4, and they can learn that the peer party is in the GR Recovery stage. However, none of the four LSRs has the Tunnel1 protocol state data=20 before restart, so they cannot constitute any recovery Path message=20 to be sent to the neighbor. In this case, Tunnel1 can only wait for reestablishment of LSR1 after the GR Recovery stage ends. 6 References [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP=20 Tunnels", December 2001.=20 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation=20 Protocol-Traffic Engineering (RSVP-TE) Extensions",=20 January 2003. [RFC1112] Deering, S., "Host Extensions for IP Multicasting",=20 Stanford University, August 1989. [RFC2375] Hinden, R., et al., "IPv6 Multicast Address Assignments",=20 July 1998. IANA =A1=B0INTERNET MULTICAST ADDRESSES=A1=B1, September 2005 [draft-ietf-ccamp-rsvp-node-id-based-hello-02] Zafar Ali, et al.,"Node ID based RSVP Hello: A=20 Clarification Statement", September 2005. [draft-ietf-ccamp-rsvp-restart-ext-05] =20 Satyanarayana, et al., "Extension to GMPLS RSVP Graceful Restart", September 2005. Luojian Expires: May 2006 [Page 9] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 =20 Authors Addresses=20 JiangWeilian=20 =20 No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871644=20 Email: jiang.weilian@zte.com.cn =20 FengJun No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871631=20 Email: feng.jun99@zte.com.cn CuiYing No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871631=20 Email: cui.ying@zte.com.cn =20 KongYong No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871177=20 Email: kong.yong@zte.com.cn =20 LuoJian =20 No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-51803814=20 Email: luo.jian@zte.com.cn =20 Comments are solicited and should be addressed to the working=20 group's mailing list at ccamp@ops.ietf.org and/or the author(s). Luojian Expires: May 2006 [Page 10] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 Intellectual Property Statement=20 =20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to=20 pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; neither does it represent that it=20 has made any effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track and=20 standards-related documentation can be found in BCP-11. Copies of=20 claims of rights made available for publication and any assurances of=20 licenses to be made available, or the result of an attempt made to=20 obtain a general license or permission for the use of such=20 proprietary rights by implementers or users of this specification can=20 be obtained from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights, which may cover technology that may be required to practice=20 this standard. Please address the information to the IETF Executive=20 Director.=20 Disclaimer of Validity =20 This document and the information contained herein are provided on an=20 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=20 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2005).=20 This document is subject to the rights, licenses and restrictions=20 contained in BCP 78, and except as set forth therein, the authors=20 retain all their rights.=20 Acknowledgments=20 =20 The authors would like to thank XuZhijun, DuKe, ZhuXinhua,=20 ChenJianye and all the other people who have contributed to this=20 draft, and also would like to thank all the future participants for their comments and suggestions.=20 Luojian Expires: May 2006 [Page 11] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 --=_mixed 00109675482571EF_=-- From orion@dm.mailpia.net Wed Sep 20 01:36:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPulI-0007sx-VT for ccamp-archive@ietf.org; Wed, 20 Sep 2006 01:36:44 -0400 Received: from [125.187.32.199] (helo=m27.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPulD-0000A7-8F for ccamp-archive@ietf.org; Wed, 20 Sep 2006 01:36:44 -0400 Received: (qmail 12286 invoked by uid 0); 20 Sep 2006 14:33:51 +0900 Message-ID: <20060920053351.12285.qmail@m27.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyouhoubisiness Reply-to: delivery_rt Date: 2006-09-20 14:25:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060920120957_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From orion@dm.mailpia.net Wed Sep 20 01:38:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPunD-0000hA-Qj for ccamp-archive@megatron.ietf.org; Wed, 20 Sep 2006 01:38:43 -0400 Received: from [125.187.32.183] (helo=m13.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPunC-0000bq-2u for ccamp-archive@megatron.ietf.org; Wed, 20 Sep 2006 01:38:43 -0400 Received: (qmail 1226 invoked by uid 0); 20 Sep 2006 14:30:48 +0900 Message-ID: <20060920053048.1225.qmail@m13.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyouhoubisiness Reply-to: delivery_rt Date: 2006-09-20 14:25:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060920120957_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From unmqompa@shawcable.net Wed Sep 20 03:09:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwCb-0004ah-ND for ccamp-archive@ietf.org; Wed, 20 Sep 2006 03:09:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPwAB-0000Vs-S7 for ccamp-archive@ietf.org; Wed, 20 Sep 2006 03:06:31 -0400 Received: from s01060050047fb7e0.vc.shawcable.net ([24.87.12.192]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GPwAB-0006JA-2X for ccamp-archive@ietf.org; Wed, 20 Sep 2006 03:06:31 -0400 Message-ID: <000701c6dc83$4d9d0380$c00c5718@aceburner> From: "Help Sign" To: ccamp-archive@ietf.org Subject: in Web Images VideoNew Date: Wed, 20 Sep 2006 00:06:32 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6DC48.A13CA4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 ------=_NextPart_000_0003_01C6DC48.A13CA4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6DC48.A13CA4E0" ------=_NextPart_001_0004_01C6DC48.A13CA4E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are Web Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert help with search. Get = the latest messages emailed to Alerts. Terms of Service Privacy Policy Alerts Create new group About Searched all groups Your search did not = match any Groups Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Service Privacy Groups Home Help Sign in Web Images VideoNew News Maps more raquo = Advanced Search Members: users: Join Alerts new group About Searched all groups Your search did not match any Make = sure words are spelled Try different keywords. general fewer your on can = try Answers for expert help Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert help with search. Get = the latest messages emailed to Alerts. Terms of Service Privacy Policy ------=_NextPart_001_0004_01C6DC48.A13CA4E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Members: users: Join Alerts Create new group About Searched all = groups Your search did not match any Make sure words are
Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of Service = Privacy Policy
Alerts Create new group About Searched all groups Your search = did not match any
Groups Home Help Sign in Web Images VideoNew News Maps more = raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Service Privacy
Groups Home Help Sign in Web Images VideoNew News Maps more = raquo Advanced Search Members: users: Join Alerts
new group About Searched all groups Your search did not match = any Make sure words are spelled Try different keywords. general fewer = your on can try Answers for expert help
Join Alerts Create new group About Searched all groups Your = search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of Service = Privacy Policy
------=_NextPart_001_0004_01C6DC48.A13CA4E0-- ------=_NextPart_000_0003_01C6DC48.A13CA4E0 Content-Type: image/gif; name="the.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6dc83$4d9b7ce0$c00c5718@aceburner> R0lGODlh5AFgAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAMAAAALAAAAADkAWABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5smAJ ljNr3sy5s+fPoEOLHk26tOnTWqehXs26tevXsGPLnk27tu3buHPr3s3b6aDewIODZCe8uPHj q30gXx5WOfPnXJ1Dn35VOvXrUq1j395UO/fvSL3+gx8/VDz58z7NcwWDvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZoIGdaHKjgggw26OCDEEYo4YQnrUDhhRiuhMZjaWTo4YcgkhdJ iCSWaOKJKKb4kiJEKaPiizDGKOOMNNZo44045qjjjjz26OOPQAYp5Ea+DPkSFJsVaeR1Si45 XZNOPgdllMtNSeVxVrJUxJXTFbEll2CGKeaYZJZp5plopqnmmmw+x0CbcMYp55x0NnVNnXjm qeeefPbp55+ABirooIQWauihiCaq6KKMEmZho5o9Cmlmkk46UQuBVWrpZJpuGlmnnoYq6qik lmrqqaimquqqwaHA6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvs s9BGK+20JtlC7bXYZqvtttx26+234IYr7ri0kkLuueimS6E96rbr7rvwxivvvPTWa29ttdyr 77789ivTHJ3RQOItBBdc8K3s+nWLv/DKwPDDEEcs8cQUV2zxxRhnrPHGHOvkhmvpdCzyyCSX bPLJPnKDskoqN5qNZi2vfFLMalmLLM0GUdDsCF5xg/OzI/A8UBQygyR00UgnrfTSTDctcwNO R82jKFJXbfXVHIUSYgl+JYH112CHLfbYZJdt9tlkVoN2UXes7bZRm7zdUNxyK0R33QndjfdB nXrvTVDffg8EeOD/DE744YijfULiQX3M+OOQRy755JRXbvnlmGeu+eZlYcb556CHTpDWd5Uj +umop6766qy3fiF7rscu++y012777bjnrvvuvPfu++/ABy/88MQXb/zxyCev/PLMN++8W7E8 L724G05v/fXYZ6/99hHiwv334OdVB1sCHFvH+IefH/767LfPlBzun8VK/PTXb39rAQEAIfkE ABQAAAAsAAAAAOQBYAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48g Q4ocSbKkyZMoU6pcybKly5cwY8qcSTPjoZo4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQ o9JcJrWq1as6BWHdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bteEeDdy7ev37+A AwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ew Y8ueTbu27du4c+vezbu379/AgwsfblkR8ePIkytfzry58+fQo0u/y2269evYs2vfzr279+/g w/6LH0++vPnz6NOrX8++vfv38OPLB49qvv37+PPr389fdJ7+AAYo4IAEFiiVNQZe9k2CDDbo 4IMQRijhhBRWaOGFGGao4YYcdujhhyCGKOKIJJbYGQMmpqjiiiy26OKLMMYo44wHhUHjjTjm qOOOPPbo449ABinkkEQWaeSRSCap5JJMNunkk1BGKeWUVFZp5ZVYZqnlloGpwuWXYIY5Iyxi lmlmVDacqeaabLbp5ptwxinnnHTWaeedeOapJ0a+AHbTngr50iegig1KaGKGHnpYoooWxmij kEYqKVBSTEpYpZYOhmmmgG3K6V+efirqqKSWauqpqKaq6qqsqrpOq/+wxiqrelrMauutuOaq 66689urrr3WmAuywxBZr7LHIJgvjKso26+yz0KpITLTUVmvttdhmq62UImzr7bfgunRFuOSW a+656Kar7rrstuvuu/DGK++89BJqSr345qvvvvz26++/AAcs8MAEF2zwwQgnrPDCDDfscEP8 PKxbJBJ35EfFP5ECFQ0YdyxxLDwZ5/HIqSZBckVJmHzyyqRpwvLLMMcs88w0A4pJzTjnrPPO PPfs889Aq7tC0P8MDbTRR7sFQ5JqLIU00VBHLfXUVFdt9dVmUgLnA1h37XWD034tNk4VcBoO 0Wc3KgBiaQPd9krg8Pu2z3M/XEklFdVtN96EE+mNcr53930y3xH5Pfbhj+UCUhSIN+7445BH Lvlp8Uxu+eWYZx5pFr+iKBbnP4Ou+aQ3XKvC6Kinrvrq1o0CtOs/w+6z7D3TzrPtrOeu++68 997YGkAD/7PwPhPfs/E8I+/78sw3pnV6ETQv/fTUV2/99dhnr/323Hfv/ffghy8+WQEBACH5 BADY0AAALAAAAADkAWABBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eP IEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq06MIPSA8iXZqUqdOm STEuVfr031OnVqNenGrwatarUD9k5FrQK9ipZC2mHWj2rNi1FOF+ZTq3rVijeCfKtQv261it BPna/Xu3bFW3bwFX3HvYrV+pigUKblxYbeS6YfvKzcs54ebHhiuDtiw68OW1nyF+Ziw69cPV pxW7dgi79OjbcS9Ljt1ad+ffpm3vto3at2rfrEMT9sxbOWThuG/Pblibam/ox6EnDw68O8Lq XWX+G3+NvDn358yJi8dOXrt5tuNpl1d/ffn398O96z9vvT9/0un5Bx978rlHn3P/JLHYfALm h959B/63oIENRrdfZ+Ah6KBCVYVHoYcaQrhdhRuWKCJ+IZo4W4cpDljhiliBCOGL8V1IVIYS wkiXjCRKFx+LEgbpI4FAujgjjyZaNyKSRjaZ3pItFkegjUPh6KSFEVmpYo0MaTmkfT1KCSaT W07ZJYNMzrYFlUF5KeaDYa43ZpRywknml3bSWV+eQr7J5m9u1rkVmiFOd+aHhXJ5FKE5Ksoh o1cauiiijZr5p09nYbbngEUWSNmOkfYlUaZeVdopdZoVKeWph37q53D/rE7qqqCwxnhplana Wmasj062aa2gZjfrr5o6yilWpYaarLDIqroer082q+uQ0N5q7bXYZqvtttx26+234IYr7rjk lmvuueimq+667Lbr7rvwxivvvPTWa++9D6GA77789uvvv98OILDAAw08sEAEIzzAPwYT3PDC DzPccEERR6xwwhNfjPHEFlOccccGa7ywxCETlLDJEHOcMcoln8ywxx47rLJBLgNMr8spoyxx wTnrjJDMC50s9Mg7F42w0S/XPDTNRAOtMM9PF4x0zCxPHTXMUB98tM9cG12z1TbHizPSTu+s NNFMg8310lGP7TbaXsMd99xto93zQS0f/DXY/jin3DTWXbPdddjyft333Gf/PPLeazft+NVQ A3614Y8LvnHaP5MM9N6c2w1x0XBT3jjmhN+ct85LV7zy0CUD3jHoizutt8qtj/765TFrLTXJ T4MsN9mfmy055IJHXvq9ZZtdeehyH65Q6sxPfnfyyit+euJWM/7y1tWTHnjwDg8PvPHkH/+u 5+NDPzz2CbHtvPq9R89387H7/Hb7eN89OPHB876/82ozX+FQhz74lY99ijOe+5aXNfllj34K rJ/UtPc76kGOfOG7mPgAKDoBiq11vtOa6kI2Qt2NroEbyxsJZ3ZACKIwdiJcGfcICMLfaQ5j gythBE/nwX5pr4dA/gwiT0woxCIa8YhITKISl8jEJnKLBE6MohSnSMUqWvGK9RKAAAqixS4e pItaFEgYBzJGMJbRjGREoxm3uEaCoJGLbxzjP8J4RjiCEY52rKMYt5hHPrZxjm8EpBcBmUaD /DGQe8yjIL0ox4ccMpB3XKQfESlJNvKRkI+MZBzVyMlI9nGSnkzjHeVIx00acpOefGQhEymS VF5yjngkIyEL2chSrpKVs7ylHsUYS0xe0pa5xCUpBxlMS+LylrAU5iuByctdIpOZvXzmL1/p kGHm0prFDGY0r2nMRDYym8rs5Td1uUxqftOa6DRnObl5zHC20yOudGM0u+nNdWLTneQ8/6Y6 aTnNWZ6zn3u8Jyyh+cx88lOeBNUnPbdZTIBCJJ0GraU23UhNX4bzn/LEp0K/6FBtjhOYEKWo SGu5UHyOkyN6PCkyN0pSdho0ohUVaT1XGUp3prSiNV3pSy2qSI6ONKYTbek7GRJSl34UqBMV ZD4x6tN2ClWc65SpHZe6z4NaVaoCheckRXlSVHLypzUd5igRSclK2pSYXMWmMwOqELJ2NKFo nacl43pUrCI1rP38IyuPildXOrSUY0WIWBkZVahKNaDETGxeqzpTfmryr0jNyFqHelWezrSu Ti3pYdl5z64C9KanVKlhWYrTuEozqUEtrGgTokqmYrapU0XsWv5VmtWn2nWznp3mY+Xa0NTu tCNrpCNuf0pcqzLVo1vl5UqLmtWLBjebCU2mSe25TMseNrq+/W1DMCtUiYq2rpM9rnRrW9jb Lre0/kTvdReK3ZW0tLzStS40mfnU45YRt4vVLmepi9DkZnS6xW2mf09LW/VqtJoGVmt1v8tY uDJ2vB116SlPi9/KZjbA4YVsSLqbU0lu1Ky9VWZgaZpTvbqVo7sl8SCbe+K06naXfF0xUNsY T9lGdrO9fayM+0pYC4O4xWbV64RdHNoeN5aiOt6xYlMsYSzO5B1OjrKUp0zlKlv5yljOspa3 zOUue/nLYCaXLcJM5jKbGSUBCMBB0v6cZoGw+c1qbrNC3kwQOCfEznVmc0Ho/A857znPet4z nNvs54EQetAG4bOb1ZxnQMu50IsWNKIh3ec4D5rRhka0pDHtaEcHOtGfrvSaBV3nRl/a0ooW daIrrWlWPxrPkm50piM9LkrTWta3vjOn/UzpQr8a16pm9aqDTWxg99rSuPY1oyH961kfGyHK BnWxpT3rXPN618vm9JqxvWht95nU3Xa2t4n9am8je9viBrawq01rW3fL3c9mt67lHe92c5vd qf42uce9b2lH29rZBne06w3uXEfa3fTG9L/7Pe2Cqzrf2r62ws/t8HJHvOEDv/fB731tcsHb 3Bqft8GpTf9yfCt83W5uOLRDvnFZP5vZFHf4yAHub34nfOSHrvmcQf7tUEd84hPH+M977muh ozvZMW+2yrn18ZIjPOGhlre6g83rcKf86RU/NcU7TmqYq1zr/Fb2qV0N8aDjPOYbh/XZ9f1p nufc4nSW8xMObnWiaxrWXm95p6X+raZnnSEwjzrV9Vzvqlt964KnedfV/vKhSxztX2e5qLHe 6mnnfPE793eml63zy9va60C/us3xnHeuSx3r2fK7sW3O99M7nue3xnaci616y5974ek29etL vnqdZ57huvf9yjW/eX0H3/PjBj2gid6Qy1f70jJHPbZqr/jfA//m1zf85gPe+uv+6z373H8+ twnee8xbH/emfzjrGf7zYz9+5v9uP+T7Hf+hd7/WYYf9zAuefuyj/+Sx5n3YF3wmh3QFmHtT V30IOHwHGHsct37xB2rJJ3GtF4Gx9nlmV39/l4DvdndRJ3b55mrbx3pqJ4J7N4GeJnJrl3fd BnKCR3r6t4G6V3m0J3sTiHu6VnS8Z3CPF3eMh25jR3YjyHI4KH1ndoRImIRKuIRM2IRO+IRQ GIVSOIVUWIVY9A1WmIVauIVc2IVe+IVgGIZiOIZkWIZmeIY0AQxouIZs2IZu+IZwGIdyOId0 WId2eId4mId6uIfecQAbEQ18GIiCOIiEWIiGeIiI6B3/pZCIjNiIjviIkNiEm7AJDjGJl2KJ QAQAmqiJMsGJAgEALoGJBTGJliiKlEiKpPgPojiKqCgQqEiJqgiLA1GKrRiLs3iKrxiLqZiL t5iKvYiLs+iKtXiLvwiLpiiLEsGLr2iMw2iLv6iLu4iMxSiM1OiMAuSJNLGJnxiK0kiMuuiK 3miNBLGK1kiLshiN1HiM4biKmNiO3eiNvgiMCOGOxKiOE2GP5fiO4iiO+DiOzGiL/Xg82DgQ mwiK/1CQoKiNB1mQBKmQCPmJBjmQDBmRDjmR2MiQC5mM+uiOpbiO70iO6tiKIvmP+NiP9LiP /iiMHUmOHlmP0eiL0JiOKVmN//nIivvIjuf4kSQJkzQpkAbZkBCZkULJiZ44kBlZlAlJkQSR lEZJlEp5lEpplA3BktWIiyWpkzYpkyPpjLTYkirZlVzZjFUZk1RZk+mYk2d5ljjplTcpj+Fo lllpjgZRlgDTlFH5lE4ZlAupjUgJkU3pl36Zl0PJlAp5jxtpjCrJljPZkv8IkLV4lW/Ji18p je2YmGUJmfZojuiYlXB5mZSJjAE5mYnJmT5ZEH3Zl1AZlKeJl4W5jap5l3opmBfhmeBIk6HZ lvU4l25pm2jZk2BJmlzpkvPYm44Jj7uJkpDZk4vpm8S5nDHpnIRjl68Zm0k5nakplNhJkEs5 mNx5nf9AGRG0qYrjqJhvWZPd+Ju8qZgn6ZyVGYzhaZ69iZ7ISZwBKZ9ryZy4eZ/XiJH8yZp7 eZEWqZfZ6Zqu+ZCoiZR8+ZMPIZlkOZ68yZPQyIzxqJvzyZPHuJmOCaEi6aAMmo8wuZkcKZ+i GZlbmYvDeKFdCZKNSZdTJJUO4aJJyKLcIqNRBKMMYaNISKPYoqOROEVi0KNAGqRCOqREaoU4 ehFHOqBFKkUGqqA36qRLiZERkaRJmhA4qZkiuqTqIp0PAaNVqhBUCqUL+pmLyaOPSA/rYpcI +pMBmp1c6pQJSpGF2Z9KyhAqWqb6qKXn8pDYuZpROqB86qfcKah5+aXsCZr/zamnadqmg6qg UhqlFXmgsHmdsqmRpHmbt5IDikoRsimogQmmcuqflFqd3mmpy4mpVOgMWdapk2qdBwGg30mo pFqoYroQd0qem7qnUhqpbJqgAvqfjtqr1AmsDempY/qS9CmWuYpEhrqsZNiszhqt0jqthAhl 1Hqt2Jou2OCF0IoQ3aoR+ZCt8cKlU1qrC9GkLBGuA5EP7KquBNGu7gqv4notc/qt3UquJyGv /8CuAsGv66qu/Oqv/jqvf2KRaxqYvcqrw/qdsVqvB1unCxGw+7qvAOuuFNuvFnuxBFuw/zmq jfqrHsuw1lmpxuoQEouxKPuvKbuyG0sl/imr3Rmo/60JqLNKmAhrrg2hrwKbsfAarxnbshcC pYI5tDUbszMrnZJaqRcRrgFbsQixs0B7KUJbtDCLmkqKtE/pqiCbsxPbtCg7sF/7s1HbGaBg mgbxsEm7psJ6tm3anwDqqxKhrxQLtXNbsXI7tvPyrSghtngbRHqbr30buCBxDoJbuIZ7uIib uJzxt38qEqqguOWCkDjbpZPrrYwKEo9LEKqQuQaxuZq7uZwLucDBuKZZuWxbuiEBupwLugfB ugLhuf8Au6L7G7A6mG8bqqG6sCD7sB3buzbquY+7uqH7uQMBu7I7u4u7tkTrplk7ssGKusZa ssQ7vMdLvMXrusjbGbULp/9xKqoyi68e67YzixCqa72dK7yvO7zHcw93uL2kCqlUy5rgu7wd 263Bi76ti7/Vm71F4b4Qu7xWK5VY+6tK+7uxG7v4i8DXu8AK3C4EQKQSKb42i7AUvLXEirYO q7QFUb7pa7yZy8EIvL/8u6WmWxLqO8KlGRMnjMIs/GXT0MIwHMMyPMO3QrozUcJYpqpoOLn3 yqcZ8bdiisM0jBdHqrc2jLoS8agQO8Sj66Xiq7siS6e4+6n1a7pEeZDFysQ28r6NO8BXG8Q2 W7Vre64JuZ1HrMU3Ib9FS6y9i8QU7L+Su8SgWpQWPLtLUMM+3LBG66JwrLxcLMdgCpVKfIQL gC7/d8wRldATfDyptXu6w9rHblylZRzBLHzIGpHIilyr39vIbnzBwcqrcgrIxeqkZyyulowR mFywQvyiq9wQrZy4p3wRqazKGzHIP8zEsVwRs4zG35LLLOHLErHLvKxEwDzMWlbMxmy4pawS r1xEZbCHuzq+nczKHXGvnZzHVMILivumONvD1SzE0fy8yTwU3PyqT9ydVCzFFfzEOHrFYyzK 45zGdPrFu7vGFsy9H+ud7VzGjUvF8ewTYky/m3zNjLqal/uklOzI/8wTMIvEAn20ftynrVrH CfG+i7zQmey8jky/9PzIEU2u7YzFjWy1GK0T4azJEiyyWezJ8DvFewnI/yc9yiXNLctcys08 0/R60/DLETqN0z7900Ad1EI91ERd1EZ91Eid1Eq91Ezd1E791FAd1VI91VRd1VZ91Vid1QPh BFrd1QOhDl49EKQQ1mRd1mZ91mgN1DKQ1mGz1g7BBWz9Lm4d1/4y13TNL3Z91/giA3mt1y3B D/zg1+QC2IENEYDtEIct2GxC2BGR2Ir9LYed2ITt2JMtEJFd2JLN2Jl92Y/NGZz9D5ldEJwd 2o4N2oFd2qUdrXkqZZ8d2qat2ZjN2K8d27MtrqsdZZMN25Z92rS92YVd276NrbeN27/d2ry9 26Y9EKmd3Kh93FaUBeYy3MSt3M7t286d3LtN2v+yvdx6Kt1MyN1R693f/dt9K96dfd7oXdUO sB8dkN5YDQZgMBHxvdTwLRD1fRHwnd//cN8ekd/8jd/zfRD8/d8IQeAOEeD7rd9Dfd8GHhEE 3uAZweAIXhEQnuADUeEXPuEM4d/2Pd8YvtAS3uEhHt8hnuEFweH17eEK7t8BzuIEMeIqbuEy nuESnuIIPuAkzuEiXuMxfuMkvt8nruE+reMwbuMd/uJE3uL6DeNHXuI7HuMW7uRBPuP/jeMy buRR3uMK3uRBLuRDvuIuXuVbTuNYTuVa3uRQfuRZruY6juRL7uVmfuU5juYoLuRtbuILDuZT TuYJUeZWvuaALuZozub/Yy7nM24QVs7kgI7niH7ojg7Uf87oal7gcz7pio7lgh7oSo7oZz7p cX7plS7p9g3kmA7nMy3mb77nbo7joZ7gJc7jPr7lLu7pZK7ire7qr27rsP7ouM7nV/3hHwHs Am7qNkHsVi3sGnHnEIHsMmHs7v3s0B7t0j7tVfTgzn7syr4RBp7tFsHsG77pw67qZe3tFNHg 5P7t2g7unC7uZG3tgz7nuv7kO77ns57rrJ7jPM7lvZ7pcm7v5w7V7p7lNl7qhm7uUE7wim7p Wl7mh87iCF/p//7UAe/nSl7ng77uht7ruD7waZ7w3P7pZy7l7T7hHq/uhM7ruT7vj27xJ4/q /3a+6Uwu8mE98aEe6S3/8iev8JQe54tu4vz+8Bl/1vXO8g3P8jW+6kHv8vhe8Sp/757+50ku 79Q+9TRsrUMqAnto9VRfLlq/9ePS9V4fLmB/uBG/E2X/Jwg+9vJt54w46xjf5x9/ExBu8xQO 527/9iQR4FZ/7XAv4HueBxtfh8D+4TKPE3PP9w9R4YXP6/1d6Gfv6G2+5Xnw+F+47Xqu8Xju 9E0P5m+u6/ju624/9Pme74Hf5fGe6aRv8aWu+Xcf5UAu4py+61LP5SZP+V7Y+msu5Snf86B+ 8b3f+0gO8r7v5RS/6gdf8/AO8cof9K5/4Yyv6cyf4uIe924o+kbu8P/GX+utDvwEL/CpDv2B n+idbu3fH+7eX/zXH+bqT+tETuvhP/4kP+YGPvmIf4ZAf/g8L+ncv/w9X/DwL/wA8Q8MGIEE C/5DePDgwIQNETJcaDAhxIIDLRKk+FCiRo4OMX682BAiw5EfO4pUmFLkRoctXb6EGVPmTJo1 bd7EmVPnTp4cS0Z8+VOlyp9CSRosyjKpT6QmmT4l2jRlxqUrrSrMOFToQ4FRPUqtSrUrRbJS e55Fm1btWrZtc16UCBdryIlxm1rUWNIoWLN6j3aUW1Hv3L1f8VaMeljwXcB2D8vdmlcpy8Vz JU8um5myW86dPX8GHdqzFNGlTZ/uatPd2c3+qF2/hh1bdk7Ss23fjtka5mqeunH/Bh5cOO3h xY075H1c+XLmzV/Wdh4ddnLp1a1fRw0d+3bO1Ll/Bx/+pnbx5XN6N59ePXfy6927dIf+/Xz6 9e3fx59f/37+/f3/BzBAAQcksEADD0QwQQUXZLBBBx+EMEIJJ6SwQgsvVNACDDfksEMPl0vj QxFHJLFEE09EUadNUmSxRRdfhDFGGWeksUYbb8QxRx135LFHH38EMkghhySySCOPRDJJJZdk skknn4QySimnpLJKK8FL5Uott+SSwFu6BLNBcMYk8x8yxzTzTHAaUjOhNhEqE84z3VwzTTbn TDPON1uK0044+UT+U06HAs2TzjkPrdNMOfFctMw9FzWUUETdbJTQPC0tVFA/I61T0jBhw3RT OgHVNNQ+A0W100RFlXTNVF06FVVAE42V1lD9TLVTUWG1VVNIS+01U1dXHVTVO4O1tFVhP33N VGJ3xdXYO6Md9dJipxX01WtzdXVbVdHEE1xi9fy221uxpTZbadM9FNpqqW0VU2XbbZAJCp2N ldRoyU1333EnVdfXUWVlNGBFARb32GqHTTgmZTdt+GGCHX323Vfj/Xdgax20V8JcocX34YHX FfldiBm+NeJfR/6T3WENxfbbffW9dNWIkdW10I8tNjbZZ+dduV6Pe3WW1JLVbPhkmpX+TppT cE1Gultv2+yzVJYF9jXpqJXG9WpWiUba5KyldlfBjh+c92e1gUX3ZnShBhtroCnlWVFvvV6Y Ta7bljbtsVv+8+i+gwWZaL0jPNvBsPcsWl2KR6668GL5FXhuwJk2GmxEn6Y77Gv/TrtWsu32 vNK6sTbd7ssfTJxZ14V+nbNTYi+vddpvJ5AJ23HnvXfffwc+eOGHJ/49bcWlOHLTqQ6X+cen fdP5c30+d+ONqy++xuNfXjjjt7XdO1Ode7Z5XZjZ1rfpsrPXfvCv4f4c/fA3575p8PlGHV7v 2d8xYW65/xq5nicyqlkLef/rF/7cdbHm8Y9HUTNfyWoWQJ+qQY1tDDzW9MqnPP0ZzIE5EmDl CHc3sf2NbtAjHwpfkrKKYdBO2PtgjMBXwfXZr4UjXJsL5fc2vLkQhjGU0QzppzYBqm9sjspc EQEoL9HJrYnrA2IUQ/NDKVbxNhWzYha1uEUudtGLX8zJDMA4RjIi6B1lbMsE0LhGNrbRjW+E YxzlOEc6Bg8XdcRjHvW4Rz720Y9/BGQgBTlI4P2CkIdEZCIVuUhGNtJ1AQEAIfkEAB0AAAAs AAAAAOQBYAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKk yZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnT5eifgodSrSo0aNIkypdyrSp06dQo0qdSrWq VZaArmrdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw 4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06bzOTqv+nJqrk9dOcFJbTVtg 69q4K9/OzRvy7t7AF/8OTvzw8OLIAx9Pzpzv8ubQo0ufTr269evYs2vfzt2vku7gw/6LH0++ vPnz6NOrX8++vfv38OOXNCK/vv37+PPr38+/v///AAYo4IAEFmjggQgmqOCC2t3B4IMQRijh hBRWqF8ebGlj4YYcdujhhyAiuEqIJJZo4okopqjiiiy26OKLMMYo44w01mjjjTjmqOOOPPbI UQk+BinkkEQWaeSRSCap5JJMGtZPk1BGKeWUVFZp5ZVYZqnlllx26eWXYGpJQ3QhhHmfMAU6 YuaabLbpZlVYvCnnnHQqZUedeOap55589unnn4AGKuigU91DqJdlHqrooow26uijkEYq6aSU VmrppZhiN06mGe3B6aeghirqqKSWauqpqKaq6qqsturqq/+wxirrrJUFQOutuOaq666s/sFr W5v+KuywxBZr7LHIJqvsssweG0izYT0rZKLmSQutV4FYe+223HbrLZbvfCtuiiOMa+656GL3 Srrstuvuu4XFBu+89JJWRb1fJYPvvvz26++/AAcs8MAEF0yWFwYnrPDC4onD8MMQTxaDQ6xE bPHFGGes8cYcd+zxxyCHLPLIJDeqb8kgJXMyyh6tzHJHLr+skcoyw1yzzTdvFHPOPPfs889A 1xVN0EQXbfTRSCftkQZKN+3001BHLfXUVFdt9dVYZ6311lzzREbXYJvlR9hkl2322Winrfba bLctKCOnNeD23HTXbffdURaC996UXfGhtd9/bw141oNjXfhiJ0x6ON+hQqK144/bhcqrkEuo T4SVT6jP5Qxm3pQ653peteijD3sAWqQzLt8YWrOetetYw+7zEBTJPvtEtv9MO0S5U9371L9L HbzqxBdv/PHIJ6/88sw37/zz0Ecv/fToVUz99aFNjL1PeGzv/ffghy/++OSXb/75ztOB/vrs t+/++5UGBAA7 ------=_NextPart_000_0003_01C6DC48.A13CA4E0-- From orion@dm.mailpia.net Wed Sep 20 12:27:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4uw-0002bE-4k for ccamp-archive@ietf.org; Wed, 20 Sep 2006 12:27:22 -0400 Received: from [125.187.32.177] (helo=m11.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4uu-0006Iw-02 for ccamp-archive@ietf.org; Wed, 20 Sep 2006 12:27:22 -0400 Received: (qmail 30905 invoked by uid 0); 21 Sep 2006 01:26:11 +0900 Message-ID: <20060920162611.30904.qmail@m11.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCMyQkckQvJGEkSiQsJGkbKEIy?= =?ISO-2022-JP?B?MDAbJEJLfDFfMlQkJCRAQ0skLDlwR3IhKiEqGyhC?= From: kasegu-PC Reply-to: delivery_rt Date: 2006-09-21 01:25:01 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060920201933_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N5Z@n$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesuyo.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesuyo.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From orion@dm.mailpia.net Wed Sep 20 12:45:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5Cg-0001Ir-Fg for ccamp-archive@megatron.ietf.org; Wed, 20 Sep 2006 12:45:42 -0400 Received: from [125.187.32.133] (helo=m00.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5Cd-0003mI-Io for ccamp-archive@megatron.ietf.org; Wed, 20 Sep 2006 12:45:42 -0400 Received: (qmail 9498 invoked by uid 0); 21 Sep 2006 01:40:26 +0900 Message-ID: <20060920164026.9497.qmail@m00.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCMyQkckQvJGEkSiQsJGkbKEIy?= =?ISO-2022-JP?B?MDAbJEJLfDFfMlQkJCRAQ0skLDlwR3IhKiEqGyhC?= From: kasegu-PC Reply-to: delivery_rt Date: 2006-09-21 01:25:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060920201933_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N5Z@n$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesuyo.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesuyo.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From orion@dm.mailpia.net Wed Sep 20 13:25:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5pE-0004pU-5s for ccamp-archive@ietf.org; Wed, 20 Sep 2006 13:25:32 -0400 Received: from [125.187.32.235] (helo=m28.likecooler.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5pC-0007px-Cs for ccamp-archive@ietf.org; Wed, 20 Sep 2006 13:25:32 -0400 Received: (qmail 20283 invoked by uid 0); 21 Sep 2006 02:25:28 +0900 Message-ID: <20060920172528.20281.qmail@m28.likecooler.com> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCMyQkckQvJGEkSiQsJGkbKEIy?= =?ISO-2022-JP?B?MDAbJEJLfDFfMlQkJCRAQ0skLDlwR3IhKiEqGyhC?= From: kasegu-PC Reply-to: delivery_rt Date: 2006-09-21 02:25:01 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060920202039_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N5Z@n$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesuyo.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesuyo.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From orion@dm.mailpia.net Wed Sep 20 13:33:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5xC-0001H4-N0 for ccamp-archive@megatron.ietf.org; Wed, 20 Sep 2006 13:33:46 -0400 Received: from [125.187.32.138] (helo=m02.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5xA-0002ba-0i for ccamp-archive@megatron.ietf.org; Wed, 20 Sep 2006 13:33:46 -0400 Received: (qmail 16661 invoked by uid 0); 21 Sep 2006 02:32:51 +0900 Message-ID: <20060920173251.16660.qmail@m02.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCMyQkckQvJGEkSiQsJGkbKEIy?= =?ISO-2022-JP?B?MDAbJEJLfDFfMlQkJCRAQ0skLDlwR3IhKiEqGyhC?= From: kasegu-PC Reply-to: delivery_rt Date: 2006-09-21 02:25:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060920202039_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N5Z@n$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesuyo.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesuyo.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From owner-ccamp@ops.ietf.org Wed Sep 20 14:24:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6kX-0003Xz-7X for ccamp-archive@ietf.org; Wed, 20 Sep 2006 14:24:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6k7-0006DB-08 for ccamp-archive@ietf.org; Wed, 20 Sep 2006 14:24:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ6ak-000Kyc-SR for ccamp-data@psg.com; Wed, 20 Sep 2006 18:14:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ6ai-000KyK-3K for ccamp@ops.ietf.org; Wed, 20 Sep 2006 18:14:36 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 53EF932882; Wed, 20 Sep 2006 18:14:35 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GQ6ah-00009p-7l; Wed, 20 Sep 2006 14:14:35 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership' to Proposed Standard (draft-ietf-ccamp-automesh) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Wed, 20 Sep 2006 14:14:35 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-02.txt From owner-ccamp@ops.ietf.org Wed Sep 20 14:27:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6nc-0008Rb-Or for ccamp-archive@ietf.org; Wed, 20 Sep 2006 14:27:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6na-00079w-EW for ccamp-archive@ietf.org; Wed, 20 Sep 2006 14:27:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ6cp-000LAp-GT for ccamp-data@psg.com; Wed, 20 Sep 2006 18:16:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ6ck-000LAB-RW for ccamp@ops.ietf.org; Wed, 20 Sep 2006 18:16:42 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 00F3726E1C; Wed, 20 Sep 2006 18:16:42 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GQ6cj-0000Hf-NM; Wed, 20 Sep 2006 14:16:41 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'GMPLS Based Segment Recovery' to Proposed Standard (draft-ietf-ccamp-gmpls-segment-recovery) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Wed, 20 Sep 2006 14:16:41 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'GMPLS Based Segment Recovery ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt From owner-ccamp@ops.ietf.org Wed Sep 20 15:40:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ7vT-0000Nu-EQ for ccamp-archive@ietf.org; Wed, 20 Sep 2006 15:40:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6zV-0000kA-0b for ccamp-archive@ietf.org; Wed, 20 Sep 2006 14:40:13 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GQ6k9-0000zx-1S for ccamp-archive@ietf.org; Wed, 20 Sep 2006 14:24:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ6by-000L6y-6l for ccamp-data@psg.com; Wed, 20 Sep 2006 18:15:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ6bv-000L6d-Gi for ccamp@ops.ietf.org; Wed, 20 Sep 2006 18:15:51 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A54642AC89; Wed, 20 Sep 2006 18:15:50 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GQ6bu-0000E3-EK; Wed, 20 Sep 2006 14:15:50 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery' to Proposed Standard (draft-ietf-ccamp-gmpls-recovery-e2e-signaling) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Wed, 20 Sep 2006 14:15:50 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.2 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt From owner-ccamp@ops.ietf.org Wed Sep 20 15:44:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ7zV-0001xP-83 for ccamp-archive@ietf.org; Wed, 20 Sep 2006 15:44:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ7zN-0002Pk-Qa for ccamp-archive@ietf.org; Wed, 20 Sep 2006 15:44:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ7th-0002rK-Qh for ccamp-data@psg.com; Wed, 20 Sep 2006 19:38:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ7te-0002qv-Up for ccamp@ops.ietf.org; Wed, 20 Sep 2006 19:38:15 +0000 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 1GQ7ty-0000yV-00 for ccamp@ops.ietf.org; Wed, 20 Sep 2006 20:38:34 +0100 Received: from your029b8cecfe ([217.158.132.237] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 20:38:10 +0100 Message-ID: <0d9701c6dcec$4a9948b0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Wijnen, Bert \(Bert\)" Subject: Proposed liaison response to IEEE Date: Wed, 20 Sep 2006 20:37:49 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 20 Sep 2006 19:38:10.0873 (UTC) FILETIME=[4E2EF290:01C6DCEC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 All, The IETF received an unsolicited liaison on the subject of 802.1 Ethernet You can see the liaison at https://datatracker.ietf.org/documents/LIAISON/file358.pdf The participants on the GELS mailing list have requested that we respond to this to clarify an issue. Here is the draft of a liaison that we proposed to send. Please shout at once if you have any concerns with this liaison. I intend to ask Bert to send it on Monday of next week. Thanks, Adrian === Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" Date: Sep 2006 To: IEEE802.1 Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 Adrian Farrel, IETF CCAMP Working Group co-chair Deborah Brungard, IETF CCAMP Working Group co-chair Cc: Bernard Aboba bernard_aboba@hotmail.com Ross Callon rcallon@juniper.net Bill Fenner fenner@research.att.com CCAMP mailing list ccamp@ops.ietf.org GELS mailing list gels@rtg.ietf.org Thank you for your very informative and clarifying liaison on "Use of IEEE 802.1Q VLAN tags". We have a question arising from this liaison and our reading of the relevant standards documents as follows. The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at S-tagged service interfaces, as an option, by the IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q." While this text in itself is clear it leaves open the question of whether "S-tagged Service interfaces" is the only type of interface where Translation of 802.1Q S-VLAN tags is supported. It is our understanding that IEEE Std 802.1ad does not preclude the translation of 802.1Q S-VLAN tags at any S-tagged interface. Thus, this translation would be allowed at Provider Network Ports, not just at Customer Network Ports. Can you please confirm whether this is the correct interpretation of the IEEE Std 802.1ad amendment to the IEEE Std 802.1Q? Many thanks, Bert Wijnen, IETF liaison to IEEE 802.1 Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs From owner-ccamp@ops.ietf.org Wed Sep 20 17:25:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ9ZU-00008R-Oc for ccamp-archive@ietf.org; Wed, 20 Sep 2006 17:25:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ9ZS-0001Zt-D5 for ccamp-archive@ietf.org; Wed, 20 Sep 2006 17:25:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ9QX-000BCC-1d for ccamp-data@psg.com; Wed, 20 Sep 2006 21:16:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ9QU-000BBc-0Q for ccamp@ops.ietf.org; Wed, 20 Sep 2006 21:16:14 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k8KL9Rs11685; Wed, 20 Sep 2006 17:09:27 -0400 (EDT) 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: Proposed liaison response to IEEE Date: Wed, 20 Sep 2006 17:15:44 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40AB84A68@zrtphxm2.corp.nortel.com> In-Reply-To: <0d9701c6dcec$4a9948b0$0a23fea9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CA From: "Don Fedyk" To: "Adrian Farrel" , Cc: , "Wijnen, Bert \(Bert\)" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi Adrian The Liaison looks good however it does not capture a comment I made. =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. Thanks, Don > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 From apache@19charm.info Thu Sep 21 02:52:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIQ2-0005jH-Ta for ccamp-archive@ietf.org; Thu, 21 Sep 2006 02:52:22 -0400 Received: from [203.82.17.237] (helo=19charm.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQIPx-0005hw-Ny for ccamp-archive@ietf.org; Thu, 21 Sep 2006 02:52:22 -0400 Received: by 19charm.info (Postfix, from userid 48) id D51AA1CB7A8; Thu, 21 Sep 2006 14:51:59 +0800 (PHT) From: info@19charm.info Subject: =?ISO-2022-JP?B?GyRCJCQkZCRpJDckL0x+JDUkbCQ/JCQkTiRPGyhC?= =?ISO-2022-JP?B?GyRCPXckTjtSJGIwbD1vInYbKEI=?= To: ccamp-archive@ietf.org Message-Id: <20060921065159.D51AA1CB7A8@19charm.info> Date: Thu, 21 Sep 2006 14:51:59 +0800 (PHT) X-Spam-Score: 3.0 (+++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 $B!z".C6Fa0J30$H$3$s$J$KG3$($k$J$s$F!&!&!&".!z(B $B!!!!!!!!!!!!!!!!!!!!!!!!"!Fb=o$GITNQ$r$7$F$_$^$;$s$+!)!)"!(B $B!!!!!!40A4L5NAF~8}"M!!(B http://19charm.info/02/?s21 $B(,!D!E!E!D(,!D!E!E!D(,!D!E!E!D(,!D!E!D(,!D!E!E!D(,!D!E!E!D(,!D!E!D(,!D!E!D(,(B $B!&$$$d$i$7$/L~$5$l$?$$$N$O=w$N;R$b0l=o(B $B!&8}$K=P$7$F$O8@$($J$$$1$IBgC@$J;v$7$F$_$?$$(B $B!&H`;a!&IW$KFb=o$N4X78$,M_$7$$!*(B $BCK@-$NJ}$,DL>o$($C$A$J;v$r9M$($F$$$k$H;W$o$l$,$A$G$9$,!"=w@-$bF1$8$/$i$$$+(B $B$=$l0J>e$K$($C$A$J;v$r9M$($F$$$^$9!#$=$7$FM'C#4X78$N?M$h$j$b(B $B40A43d$j@Z$j$GBN$@$1$N4X78$r5a$a!"=P2q$$%5%$%H$KEPO?$9$k%1!<%9$,Hs>o$KB?$$$G$9!#(B $B$3$N%5%$%H$O%l%G%#%3%_%C%/;o$K7G:\$5$l!"%(%C%A$J?M:J$?$A$,=8$^$C$?!"(B $B40A4L5NA%5%$%H$G$9!*!*!*(B $B!!!!!!40A4L5NAF~8}"M!!(B http://19charm.info/free/?s21 $B(,!D!E!E!D(,!D!E!E!D(,!D!E!E!D(,!D!E!D(,!D!E!E!D(,!D!E!E!D(,!D!E!D(,!D!E!D(,(B $B$4ITMW$NJ}$O(B info99@ok.kz [0921][m08] From owner-ccamp@ops.ietf.org Thu Sep 21 06:48:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQM6m-0002u2-H8 for ccamp-archive@ietf.org; Thu, 21 Sep 2006 06:48:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQM6h-0007xr-Bp for ccamp-archive@ietf.org; Thu, 21 Sep 2006 06:48:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQLxq-000Ogn-7a for ccamp-data@psg.com; Thu, 21 Sep 2006 10:39:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQLxn-000Ofk-IS for ccamp@ops.ietf.org; Thu, 21 Sep 2006 10:39:28 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 13:38:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD72.790106C1" Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 13:38:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuA= From: "Nurit Sprecher" To: "Don Fedyk" , "Adrian Farrel" Cc: , "Wijnen, Bert \(Bert\)" , , "Nurit Sprecher" X-OriginalArrivalTime: 21 Sep 2006 11:38:35.0602 (UTC) FILETIME=[7932CB20:01C6DD72] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ef89f32bda94ec20fe57b465fe684d49 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD72.790106C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I think it is a good idea to send the liaison to the IEEE and get once and for all a clear statement that the s-vid translation is supported on each provider bridge port.=20 =20 In addition, the IEEE has recognized that MAC learning is not required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes this extension in section 8.7.=20 =20 " The Learning Process receives the source MAC Addresses and VIDs of received frames from the Forwarding Process, following the application of the ingress rules (8.6.2). It shall create or update a Dynamic Filtering Entry (8.8.3) that specifies the reception Port for the frame's source address and VID, if and only if the source address is an Individual Address, i.e., is not a Group Address, the resulting number of entries would not exceed the capacity of the Filtering Database, and the filtering utility criteria for the receiving Bridge Port are met." The enhanced filtering utility criteria "are satisfied if at least one VLAN that uses the FID includes the reception Port and at least one other Port with a Port State of Learning or Forwarding in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third Port. NOTE -The third port can, but is not required to be in the member set.".=20 =20 I think it is clearly stated, but if it is required to ask the IEEE about the context of forwarding based on a destination MAC, I suggest being more precise and specify that we are talking on point-to-point connections. =20 Regards, Nurit. =20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk Sent: Wednesday, September 20, 2006 23:16 To: Adrian Farrel; ccamp@ops.ietf.org Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) Subject: RE: Proposed liaison response to IEEE =20 Hi Adrian =20 The Liaison looks good however it does not capture a comment I made. =20 =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. =20 Thanks, Don =20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 =20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels =20 ------_=_NextPart_001_01C6DD72.790106C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think it is a good idea to send the liaison = to the IEEE and get once and for all a clear statement that the s-vid = translation is supported on each provider bridge port.

 

In addition, the IEEE has recognized that = MAC learning is not required for = point-to-point VLANs in a bridge. The 802.1Q = rev-5 already includes this extension in section 8.7. =

 

" The Learning Process receives the = source MAC Addresses and VIDs of received frames from = the

Forwarding Process, following the application = of the ingress rules (8.6.2). It shall = create or update a

Dynamic Filtering Entry = (8.8.3) that specifies the reception Port for the frame’s source address and VID, = if

and only if = the source address is an Individual Address, i.e., is not a Group Address, = the resulting number of

entries would not exceed the capacity of the = Filtering Database, and the filtering utility = criteria for the

receiving Bridge Port are met."

The enhanced filtering utility criteria = "are satisfied if at least one VLAN that uses the FID includes the reception = Port and at least one other Port with a Port State of Learning or Forwarding = in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third = Port. NOTE —The third port can, but is not required to be in the member = set.".

 

I think it is clearly stated, but if it is = required to ask the IEEE about the context of forwarding based on a destination MAC, = I suggest being more precise and specify that = we are talking on point-to-point connections.

 

Regards,

Nurit.

 

-----Original Message-----
From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On = Behalf Of Don Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian Farrel; ccamp@ops.ietf.org
Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert)
Subject: RE: Proposed liaison response to IEEE

 

Hi Adrian

 

The Liaison looks good however it does not = capture a comment I made.  

 

My understanding of the S-VLAN translation in = IEEE documents and the

liaison is that the translation is valid in = the context of forwarding

based on a destination MAC. My interpretation = is that V-LAN is optional

MAC is not. If I am correct VLAN translation = as specified is not equal

to Label switching. The Liaison is clear = about not just the format of

'packets on the wire' but the relationship to = the entities such as MAC

relay as well.  =

 

I think we should also ask in our liaison for clarification if the

S-VLAN translation can be valid by itself = i.e. as a label agnostic to

the MAC so there is no = confusion.

 

Thanks,

Don

 

 

> -----Original = Message-----

> From: owner-ccamp@ops.ietf.org =

> All,

>

> The IETF received an unsolicited liaison = on the subject of

> 802.1 = Ethernet

>

> You can see the liaison = at

> = https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>

> The participants on the GELS mailing = list have requested that

> we respond to this to clarify an = issue.

>

> Here is the draft of a liaison that we = proposed to send.

> Please shout at once if you have any = concerns with this

> liaison. I intend to ask Bert to send it = on Monday of next week.

>

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison = "Use of IEEE 802.1Q VLAN tags"

>

> Date: Sep = 2006

> To: = IEEE802.1

>      Tony = Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk

>

> From: Bert Wijnen, IETF liaison to IETF = liaison to IEEE 802.1

>       =     Adrian Farrel, IETF CCAMP Working Group = co-chair

>       =     Deborah Brungard, IETF CCAMP Working Group = co-chair

>

> Cc: Bernard Aboba = bernard_aboba@hotmail.com

>       = Ross Callon rcallon@juniper.net

>       = Bill Fenner fenner@research.att.com

>       = CCAMP mailing list ccamp@ops.ietf.org

>       = GELS mailing list  gels@rtg.ietf.org

>

> Thank you for your very informative and clarifying liaison on

> "Use of IEEE 802.1Q VLAN = tags".

>

> We have a question arising from this = liaison and our reading

> of the relevant standards documents as = follows.

>

> The liaison says: "Translation of = 802.1Q S-VLAN tags (with 12

> bit VIDs) is supported at S-tagged = service interfaces, as an

> option, by the IEEE Std 802.1ad Provider = Bridging amendment

> to IEEE Std = 802.1Q."

>

> While this text in itself is clear it = leaves open the

> question of whether "S-tagged = Service interfaces" is the only

> type of interface where Translation of = 802.1Q S-VLAN tags is

> supported.

>

> It is our understanding that IEEE Std = 802.1ad does not

> preclude the translation of 802.1Q = S-VLAN tags at any

> S-tagged interface. Thus, this = translation would be allowed

> at Provider Network Ports, not just at = Customer Network Ports.

>

> Can you please confirm whether this is = the correct

> interpretation of the IEEE Std 802.1ad = amendment to the IEEE

> Std 802.1Q?

>

> Many = thanks,

>

> Bert Wijnen, IETF liaison to IEEE = 802.1

> Adrian Farrel and Deborah Brungard, = CCAMP Working Group co-chairs

>

>

>

>

 

______________________________________________= _

gels mailing = list

gels@rtg.ietf.org

=

https://rtg.ietf.org/mailman/listinfo/gels

 

------_=_NextPart_001_01C6DD72.790106C1-- From owner-ccamp@ops.ietf.org Thu Sep 21 07:05:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQMNG-00044h-U2 for ccamp-archive@ietf.org; Thu, 21 Sep 2006 07:05:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQMN9-0002Su-DE for ccamp-archive@ietf.org; Thu, 21 Sep 2006 07:05:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQMHr-0002Dy-Lt for ccamp-data@psg.com; Thu, 21 Sep 2006 11:00:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQMHp-0002DO-AR for ccamp@ops.ietf.org; Thu, 21 Sep 2006 11:00:09 +0000 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 12:00:07 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 12:00:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD6D.1821739E" Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 12:00:05 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389188A9743@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuAAANq2gA== From: To: , , Cc: , , X-OriginalArrivalTime: 21 Sep 2006 11:00:06.0407 (UTC) FILETIME=[18CF9970:01C6DD6D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a364894605f80b4cf7342846f9183e6 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD6D.1821739E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nurit.....precision is indeed important. In a co mode layer network connections can be p2p or p2mp in nature and each can be composed of multiple concatenated subnetwork-connections (ie nodes in THIS layer network) and link-connections......noting that a single p2p link-connection hop between 2 bridges in a cl-ps Ethernet layer network is NOT a connection in THAT (ie Ethernet) layer network (though it will be supported by a trail which is provided by a connection in some lower layer network). =20 regards, Neil -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: 21 September 2006 12:38 To: Don Fedyk; Adrian Farrel Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Nurit Sprecher Subject: RE: Proposed liaison response to IEEE Hi, =20 I think it is a good idea to send the liaison to the IEEE and get once and for all a clear statement that the s-vid translation is supported on each provider bridge port.=20 =20 In addition, the IEEE has recognized that MAC learning is not required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes this extension in section 8.7.=20 =20 " The Learning Process receives the source MAC Addresses and VIDs of received frames from the Forwarding Process, following the application of the ingress rules (8.6.2). It shall create or update a Dynamic Filtering Entry (8.8.3) that specifies the reception Port for the frame's source address and VID, if and only if the source address is an Individual Address, i.e., is not a Group Address, the resulting number of entries would not exceed the capacity of the Filtering Database, and the filtering utility criteria for the receiving Bridge Port are met." The enhanced filtering utility criteria "are satisfied if at least one VLAN that uses the FID includes the reception Port and at least one other Port with a Port State of Learning or Forwarding in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third Port. NOTE -The third port can, but is not required to be in the member set.".=20 =20 I think it is clearly stated, but if it is required to ask the IEEE about the context of forwarding based on a destination MAC, I suggest being more precise and specify that we are talking on point-to-point connections. =20 Regards, Nurit. =20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk Sent: Wednesday, September 20, 2006 23:16 To: Adrian Farrel; ccamp@ops.ietf.org Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) Subject: RE: Proposed liaison response to IEEE =20 Hi Adrian =20 The Liaison looks good however it does not capture a comment I made. =20 =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. =20 Thanks, Don =20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 =20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels =20 ------_=_NextPart_001_01C6DD6D.1821739E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Nurit.....precision is indeed important.  In a co mode = layer network=20 connections can be p2p or p2mp in nature and each can be composed of = multiple=20 concatenated subnetwork-connections (ie nodes in THIS layer network) and = link-connections......noting that a single p2p link-connection hop = between 2=20 bridges in a cl-ps Ethernet layer network is NOT a connection in = THAT (ie=20 Ethernet) layer network (though it will be supported by a trail which is = provided by a connection in some lower layer = network).
 
regards, Neil
-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Nurit Sprecher
Sent: 21 September 2006 = 12:38
To: Don=20 Fedyk; Adrian Farrel
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert);=20 ccamp@ops.ietf.org; Nurit Sprecher
Subject: RE: Proposed = liaison=20 response to IEEE

Hi,

 

I think it is a good idea to send the = liaison to the=20 IEEE and get once and for all a clear statement that the s-vid = translation is=20 supported on each provider bridge port.

 

In addition, the IEEE has recognized that = MAC learning is not required for = point-to-point=20 VLANs in a bridge. The = 802.1Q=20 rev-5 already includes this extension in section 8.7.=20

 

" The Learning Process receives the source = MAC=20 Addresses and VIDs of received frames from = the

Forwarding Process, following the = application of the=20 ingress rules (8.6.2). It shall = create or=20 update a

Dynamic Filtering Entry = (8.8.3)=20 that specifies the reception Port for the frame’s = source address and=20 VID, if

and only if = the=20 source address is an Individual Address, i.e., is not a Group Address, = the=20 resulting number of

entries would not exceed the capacity of the = Filtering=20 Database, and the filtering = utility=20 criteria for the

receiving Bridge = Port are = met."

The enhanced filtering utility criteria "are = satisfied=20 if at least one VLAN that uses the FID includes the reception Port and = at=20 least one other Port with a Port State of Learning or Forwarding in = its member=20 set, and: a) The operPointToPointMAC parameter is false for the = reception=20 Port; or b) Ingress to the VLAN is permitted through a third Port. = NOTE —The=20 third port can, but is not required to be in the member set.".=20

 

I think it is clearly stated, but if it is = required to=20 ask the IEEE about the context of forwarding based on a destination = MAC,=20 I suggest being more precise and = specify=20 that we are talking on point-to-point=20 connections.

 

Regards,

Nurit.

 

-----Original Message-----
From:=20 gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf = Of Don=20 Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian = Farrel;=20 ccamp@ops.ietf.org
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert)
Subject:=20 RE: Proposed liaison response to IEEE

 

Hi Adrian

 

The Liaison looks good however it does not = capture a=20 comment I made.  

 

My understanding of the S-VLAN translation = in IEEE=20 documents and the

liaison is that the translation is valid in = the=20 context of forwarding

based on a destination MAC. My = interpretation is that=20 V-LAN is optional

MAC is not. If I am correct VLAN translation = as=20 specified is not equal

to Label switching. The Liaison is clear = about not=20 just the format of

'packets on the wire' but the relationship = to the=20 entities such as MAC

relay as well.  =

 

I think we should also ask in our liaison = for=20 clarification if the

S-VLAN translation can be valid by itself = i.e. as a=20 label agnostic to

the MAC so there is no=20 confusion.

 

Thanks,

Don

 

 

> -----Original=20 Message-----

> From: owner-ccamp@ops.ietf.org=20

> All,

>

> The IETF received an unsolicited = liaison on the=20 subject of

> 802.1 = Ethernet

>

> You can see the liaison=20 at

>=20 = https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>

> The participants on the GELS mailing = list have=20 requested that

> we respond to this to clarify an=20 issue.

>

> Here is the draft of a liaison that we = proposed=20 to send.

> Please shout at once if you have any = concerns=20 with this

> liaison. I intend to ask Bert to send = it on=20 Monday of next week.

>

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison "Use = of IEEE=20 802.1Q VLAN tags"

>

> Date: Sep = 2006

> To: = IEEE802.1

>      Tony = Jeffree, IEEE=20 802.1 WG Chair, tony@jeffree.co.uk

>

> From: Bert Wijnen, IETF liaison to IETF = liaison=20 to IEEE 802.1

>          =20 Adrian Farrel, IETF CCAMP Working Group = co-chair

>          =20 Deborah Brungard, IETF CCAMP Working Group=20 co-chair

>

> Cc: Bernard Aboba=20 bernard_aboba@hotmail.com

>        Ross=20 Callon rcallon@juniper.net

>        Bill=20 Fenner fenner@research.att.com

>        CCAMP=20 mailing list ccamp@ops.ietf.org

>        GELS=20 mailing list  gels@rtg.ietf.org

>

> Thank you for your very informative and = clarifying liaison on

> "Use of IEEE 802.1Q VLAN=20 tags".

>

> We have a question arising from this = liaison and=20 our reading

> of the relevant standards documents as=20 follows.

>

> The liaison says: "Translation of = 802.1Q S-VLAN=20 tags (with 12

> bit VIDs) is supported at S-tagged = service=20 interfaces, as an

> option, by the IEEE Std 802.1ad = Provider Bridging=20 amendment

> to IEEE Std = 802.1Q."

>

> While this text in itself is clear it = leaves open=20 the

> question of whether "S-tagged Service = interfaces"=20 is the only

> type of interface where Translation of = 802.1Q=20 S-VLAN tags is

> supported.

>

> It is our understanding that IEEE Std = 802.1ad=20 does not

> preclude the translation of 802.1Q = S-VLAN tags at=20 any

> S-tagged interface. Thus, this = translation would=20 be allowed

> at Provider Network Ports, not just at = Customer=20 Network Ports.

>

> Can you please confirm whether this is = the=20 correct

> interpretation of the IEEE Std 802.1ad = amendment=20 to the IEEE

> Std = 802.1Q?

>

> Many = thanks,

>

> Bert Wijnen, IETF liaison to IEEE=20 802.1

> Adrian Farrel and Deborah Brungard, = CCAMP Working=20 Group co-chairs

>

>

>

>

 

_______________________________________________

gels mailing = list

gels@rtg.ietf.org

https://rtg.ietf.org/mailman/listinfo/gels=

 

------_=_NextPart_001_01C6DD6D.1821739E-- From owner-ccamp@ops.ietf.org Thu Sep 21 07:24:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQMfT-000663-QR for ccamp-archive@ietf.org; Thu, 21 Sep 2006 07:24:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQMdu-00063X-LT for ccamp-archive@ietf.org; Thu, 21 Sep 2006 07:23:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQMX3-0004pJ-9j for ccamp-data@psg.com; Thu, 21 Sep 2006 11:15:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQMX1-0004nr-4e for ccamp@ops.ietf.org; Thu, 21 Sep 2006 11:15:51 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 14:14:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD77.8E066949" Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 14:14:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuAAANq2gAABJOyw From: "Nurit Sprecher" To: , , Cc: , , , "Nurit Sprecher" X-OriginalArrivalTime: 21 Sep 2006 12:14:58.0446 (UTC) FILETIME=[8E465AE0:01C6DD77] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: dc60ea982e94509a7a8f1634aa16db79 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD77.8E066949 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Neil, Thanks for your clarification.=20 Please note that the discussion below relates to the liaison that the IETF wants to send to the IEEE in order to understand the standard behavior of the Ethernet forwarding behavior. As I understand it, Don was concerned that S-VID translation does not preclude the forwarding decision which is based on the MAC address. My intention was to indicate that for point-to-point VLAN connection (on a link), MAC learning is not required by the 802.1Qrev-5 spec and the forwarding decision does not rely on the MAC address. This is not a discussion on networking but on the standard behavior of the 802.1Q bridges. Regards, Nuritl. ________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Thursday, September 21, 2006 13:00 To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org Subject: RE: Proposed liaison response to IEEE Nurit.....precision is indeed important. In a co mode layer network connections can be p2p or p2mp in nature and each can be composed of multiple concatenated subnetwork-connections (ie nodes in THIS layer network) and link-connections......noting that a single p2p link-connection hop between 2 bridges in a cl-ps Ethernet layer network is NOT a connection in THAT (ie Ethernet) layer network (though it will be supported by a trail which is provided by a connection in some lower layer network). =20 regards, Neil -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: 21 September 2006 12:38 To: Don Fedyk; Adrian Farrel Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Nurit Sprecher Subject: RE: Proposed liaison response to IEEE =09 =09 Hi, =20 I think it is a good idea to send the liaison to the IEEE and get once and for all a clear statement that the s-vid translation is supported on each provider bridge port.=20 =20 In addition, the IEEE has recognized that MAC learning is not required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes this extension in section 8.7.=20 =20 " The Learning Process receives the source MAC Addresses and VIDs of received frames from the Forwarding Process, following the application of the ingress rules (8.6.2). It shall create or update a Dynamic Filtering Entry (8.8.3) that specifies the reception Port for the frame's source address and VID, if and only if the source address is an Individual Address, i.e., is not a Group Address, the resulting number of entries would not exceed the capacity of the Filtering Database, and the filtering utility criteria for the receiving Bridge Port are met." The enhanced filtering utility criteria "are satisfied if at least one VLAN that uses the FID includes the reception Port and at least one other Port with a Port State of Learning or Forwarding in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third Port. NOTE -The third port can, but is not required to be in the member set.".=20 =20 I think it is clearly stated, but if it is required to ask the IEEE about the context of forwarding based on a destination MAC, I suggest being more precise and specify that we are talking on point-to-point connections. =20 Regards, Nurit. =20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk Sent: Wednesday, September 20, 2006 23:16 To: Adrian Farrel; ccamp@ops.ietf.org Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) Subject: RE: Proposed liaison response to IEEE =20 Hi Adrian =20 The Liaison looks good however it does not capture a comment I made. =20 =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. =20 Thanks, Don =20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 =20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels =20 ------_=_NextPart_001_01C6DD77.8E066949 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message=
Hi=20 Neil,
Thanks=20 for your clarification.
Please=20 note that the discussion below relates to the liaison that the IETF = wants to=20 send to the IEEE in order to understand the standard behavior of the = Ethernet=20 forwarding behavior. As I understand it, Don was concerned that S-VID=20 translation does not preclude the forwarding decision which is based on = the MAC=20 address. My intention was to indicate that for point-to-point VLAN=20 connection (on a link), MAC learning is not required by the 802.1Qrev-5 = spec and=20 the forwarding decision does not rely on the MAC address. This is not a=20 discussion on networking but on the standard behavior of the 802.1Q=20 bridges.
Regards,
Nuritl.

From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: Thursday, September 21, = 2006=20 13:00
To: Nurit Sprecher; dwfedyk@nortel.com;=20 adrian@olddog.co.uk
Cc: gels@rtg.ietf.org; bwijnen@lucent.com; = ccamp@ops.ietf.org
Subject: RE: Proposed liaison response to=20 IEEE

Nurit.....precision is indeed important.  In a co mode = layer network=20 connections can be p2p or p2mp in nature and each can be composed of = multiple=20 concatenated subnetwork-connections (ie nodes in THIS layer network) and = link-connections......noting that a single p2p link-connection hop = between 2=20 bridges in a cl-ps Ethernet layer network is NOT a connection in = THAT (ie=20 Ethernet) layer network (though it will be supported by a trail which is = provided by a connection in some lower layer = network).
 
regards, Neil
-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Nurit Sprecher
Sent: 21 September 2006 = 12:38
To: Don=20 Fedyk; Adrian Farrel
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert);=20 ccamp@ops.ietf.org; Nurit Sprecher
Subject: RE: Proposed = liaison=20 response to IEEE

Hi,

 

I think it is a good idea to send the = liaison to the=20 IEEE and get once and for all a clear statement that the s-vid = translation is=20 supported on each provider bridge port.

 

In addition, the IEEE has recognized that = MAC learning is not required for = point-to-point=20 VLANs in a bridge. The = 802.1Q=20 rev-5 already includes this extension in section 8.7.=20

 

" The Learning Process receives the source = MAC=20 Addresses and VIDs of received frames from = the

Forwarding Process, following the = application of the=20 ingress rules (8.6.2). It shall = create or=20 update a

Dynamic Filtering Entry = (8.8.3)=20 that specifies the reception Port for the frame’s = source address and=20 VID, if

and only if = the=20 source address is an Individual Address, i.e., is not a Group Address, = the=20 resulting number of

entries would not exceed the capacity of the = Filtering=20 Database, and the filtering = utility=20 criteria for the

receiving Bridge = Port are = met."

The enhanced filtering utility criteria "are = satisfied=20 if at least one VLAN that uses the FID includes the reception Port and = at=20 least one other Port with a Port State of Learning or Forwarding in = its member=20 set, and: a) The operPointToPointMAC parameter is false for the = reception=20 Port; or b) Ingress to the VLAN is permitted through a third Port. = NOTE —The=20 third port can, but is not required to be in the member set.".=20

 

I think it is clearly stated, but if it is = required to=20 ask the IEEE about the context of forwarding based on a destination = MAC,=20 I suggest being more precise and = specify=20 that we are talking on point-to-point=20 connections.

 

Regards,

Nurit.

 

-----Original Message-----
From:=20 gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf = Of Don=20 Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian = Farrel;=20 ccamp@ops.ietf.org
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert)
Subject:=20 RE: Proposed liaison response to IEEE

 

Hi Adrian

 

The Liaison looks good however it does not = capture a=20 comment I made.  

 

My understanding of the S-VLAN translation = in IEEE=20 documents and the

liaison is that the translation is valid in = the=20 context of forwarding

based on a destination MAC. My = interpretation is that=20 V-LAN is optional

MAC is not. If I am correct VLAN translation = as=20 specified is not equal

to Label switching. The Liaison is clear = about not=20 just the format of

'packets on the wire' but the relationship = to the=20 entities such as MAC

relay as well.  =

 

I think we should also ask in our liaison = for=20 clarification if the

S-VLAN translation can be valid by itself = i.e. as a=20 label agnostic to

the MAC so there is no=20 confusion.

 

Thanks,

Don

 

 

> -----Original=20 Message-----

> From: owner-ccamp@ops.ietf.org=20

> All,

>

> The IETF received an unsolicited = liaison on the=20 subject of

> 802.1 = Ethernet

>

> You can see the liaison=20 at

>=20 = https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>

> The participants on the GELS mailing = list have=20 requested that

> we respond to this to clarify an=20 issue.

>

> Here is the draft of a liaison that we = proposed=20 to send.

> Please shout at once if you have any = concerns=20 with this

> liaison. I intend to ask Bert to send = it on=20 Monday of next week.

>

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison "Use = of IEEE=20 802.1Q VLAN tags"

>

> Date: Sep = 2006

> To: = IEEE802.1

>      Tony = Jeffree, IEEE=20 802.1 WG Chair, tony@jeffree.co.uk

>

> From: Bert Wijnen, IETF liaison to IETF = liaison=20 to IEEE 802.1

>          =20 Adrian Farrel, IETF CCAMP Working Group = co-chair

>          =20 Deborah Brungard, IETF CCAMP Working Group=20 co-chair

>

> Cc: Bernard Aboba=20 bernard_aboba@hotmail.com

>        Ross=20 Callon rcallon@juniper.net

>        Bill=20 Fenner fenner@research.att.com

>        CCAMP=20 mailing list ccamp@ops.ietf.org

>        GELS=20 mailing list  gels@rtg.ietf.org

>

> Thank you for your very informative and = clarifying liaison on

> "Use of IEEE 802.1Q VLAN=20 tags".

>

> We have a question arising from this = liaison and=20 our reading

> of the relevant standards documents as=20 follows.

>

> The liaison says: "Translation of = 802.1Q S-VLAN=20 tags (with 12

> bit VIDs) is supported at S-tagged = service=20 interfaces, as an

> option, by the IEEE Std 802.1ad = Provider Bridging=20 amendment

> to IEEE Std = 802.1Q."

>

> While this text in itself is clear it = leaves open=20 the

> question of whether "S-tagged Service = interfaces"=20 is the only

> type of interface where Translation of = 802.1Q=20 S-VLAN tags is

> supported.

>

> It is our understanding that IEEE Std = 802.1ad=20 does not

> preclude the translation of 802.1Q = S-VLAN tags at=20 any

> S-tagged interface. Thus, this = translation would=20 be allowed

> at Provider Network Ports, not just at = Customer=20 Network Ports.

>

> Can you please confirm whether this is = the=20 correct

> interpretation of the IEEE Std 802.1ad = amendment=20 to the IEEE

> Std = 802.1Q?

>

> Many = thanks,

>

> Bert Wijnen, IETF liaison to IEEE=20 802.1

> Adrian Farrel and Deborah Brungard, = CCAMP Working=20 Group co-chairs

>

>

>

>

 

_______________________________________________

gels mailing = list

gels@rtg.ietf.org

https://rtg.ietf.org/mailman/listinfo/gels=

 

------_=_NextPart_001_01C6DD77.8E066949-- From owner-ccamp@ops.ietf.org Thu Sep 21 08:11:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNPD-0007WL-PW for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:11:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNP2-0006eF-M1 for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:11:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQNGs-000DRw-KW for ccamp-data@psg.com; Thu, 21 Sep 2006 12:03:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [80.86.78.228] (helo=smtp.testbed.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQNGo-000DQq-Gq for ccamp@ops.ietf.org; Thu, 21 Sep 2006 12:03:11 +0000 Received: from [217.167.116.185] (helo=[217.167.116.185]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1GQNGd-0005zI-33; Thu, 21 Sep 2006 14:03:03 +0200 Message-ID: <45127F6F.8050907@pi.se> Date: Thu, 21 Sep 2006 14:02:55 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 CC: gels@rtg.ietf.org, bwijnen@lucent.com, ccamp@ops.ietf.org Subject: Re: Proposed liaison response to IEEE References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 All, there have been a number of correct statements in this short thread. Neil is right (given the layered network model) that Ethernet is a layer network and as such connectionless and packet oriented. Nurit is right that if you configure a VLAN on only to parts of an Ethernet bridge the frame will go through without looking at the MAC address Don is right that the liaison does not capture an earlier comment he made on the gels-list. Neither does it capture a comment made by Attila. However, if I understand what is happening here is that we need to clarify a paragraph in the liaison form the IEEE802.1 on translation of S-VIDs. I guess that this is something we all need to understand, and given the answer, it will be possible to follow up with further more precise questions. If for example the answer on S-VID translation is that it is not supported other than at domain borders, then the question on whether it needs to be done by taking the MAC-address into consideration or not will have very different meaning. Let agree on getting the liaison out, and then decide on what we do next depending on the answer. /Loa Nurit Sprecher wrote: > Hi Neil, > Thanks for your clarification. > Please note that the discussion below relates to the liaison that the > IETF wants to send to the IEEE in order to understand the standard > behavior of the Ethernet forwarding behavior. As I understand it, Don > was concerned that S-VID translation does not preclude the forwarding > decision which is based on the MAC address. My intention was to indicate > that for point-to-point VLAN connection (on a link), MAC learning is not > required by the 802.1Qrev-5 spec and the forwarding decision does not > rely on the MAC address. This is not a discussion on networking but on > the standard behavior of the 802.1Q bridges. > Regards, > Nuritl. > > ________________________________ > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, September 21, 2006 13:00 > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > Subject: RE: Proposed liaison response to IEEE > > > Nurit.....precision is indeed important. In a co mode layer network > connections can be p2p or p2mp in nature and each can be composed of > multiple concatenated subnetwork-connections (ie nodes in THIS layer > network) and link-connections......noting that a single p2p > link-connection hop between 2 bridges in a cl-ps Ethernet layer network > is NOT a connection in THAT (ie Ethernet) layer network (though it will > be supported by a trail which is provided by a connection in some lower > layer network). > > regards, Neil > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > On Behalf Of Nurit Sprecher > Sent: 21 September 2006 12:38 > To: Don Fedyk; Adrian Farrel > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; > Nurit Sprecher > Subject: RE: Proposed liaison response to IEEE > > > > Hi, > > > > I think it is a good idea to send the liaison to the IEEE and > get once and for all a clear statement that the s-vid translation is > supported on each provider bridge port. > > > > In addition, the IEEE has recognized that MAC learning is not > required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already > includes this extension in section 8.7. > > > > " The Learning Process receives the source MAC Addresses and > VIDs of received frames from the > > Forwarding Process, following the application of the ingress > rules (8.6.2). It shall create or update a > > Dynamic Filtering Entry (8.8.3) that specifies the reception > Port for the frame's source address and VID, if > > and only if the source address is an Individual Address, i.e., > is not a Group Address, the resulting number of > > entries would not exceed the capacity of the Filtering Database, > and the filtering utility criteria for the > > receiving Bridge Port are met." > > The enhanced filtering utility criteria "are satisfied if at > least one VLAN that uses the FID includes the reception Port and at > least one other Port with a Port State of Learning or Forwarding in its > member set, and: a) The operPointToPointMAC parameter is false for the > reception Port; or b) Ingress to the VLAN is permitted through a third > Port. NOTE -The third port can, but is not required to be in the member > set.". > > > > I think it is clearly stated, but if it is required to ask the > IEEE about the context of forwarding based on a destination MAC, I > suggest being more precise and specify that we are talking on > point-to-point connections. > > > > Regards, > > Nurit. > > > > -----Original Message----- > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > Sent: Wednesday, September 20, 2006 23:16 > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > Subject: RE: Proposed liaison response to IEEE > > > > Hi Adrian > > > > The Liaison looks good however it does not capture a comment I > made. > > > > My understanding of the S-VLAN translation in IEEE documents and > the > > liaison is that the translation is valid in the context of > forwarding > > based on a destination MAC. My interpretation is that V-LAN is > optional > > MAC is not. If I am correct VLAN translation as specified is not > equal > > to Label switching. The Liaison is clear about not just the > format of > > 'packets on the wire' but the relationship to the entities such > as MAC > > relay as well. > > > > I think we should also ask in our liaison for clarification if > the > > S-VLAN translation can be valid by itself i.e. as a label > agnostic to > > the MAC so there is no confusion. > > > > Thanks, > > Don > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > All, > > > > > > The IETF received an unsolicited liaison on the subject of > > > 802.1 Ethernet > > > > > > You can see the liaison at > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > > > > > > The participants on the GELS mailing list have requested that > > > we respond to this to clarify an issue. > > > > > > Here is the draft of a liaison that we proposed to send. > > > Please shout at once if you have any concerns with this > > > liaison. I intend to ask Bert to send it on Monday of next > week. > > > > > > Thanks, > > > Adrian > > > === > > > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN > tags" > > > > > > Date: Sep 2006 > > > To: IEEE802.1 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > > > > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > > > Deborah Brungard, IETF CCAMP Working Group co-chair > > > > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > > > Ross Callon rcallon@juniper.net > > > Bill Fenner fenner@research.att.com > > > CCAMP mailing list ccamp@ops.ietf.org > > > GELS mailing list gels@rtg.ietf.org > > > > > > Thank you for your very informative and clarifying liaison on > > > "Use of IEEE 802.1Q VLAN tags". > > > > > > We have a question arising from this liaison and our reading > > > of the relevant standards documents as follows. > > > > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > > > bit VIDs) is supported at S-tagged service interfaces, as an > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > > > to IEEE Std 802.1Q." > > > > > > While this text in itself is clear it leaves open the > > > question of whether "S-tagged Service interfaces" is the only > > > type of interface where Translation of 802.1Q S-VLAN tags is > > > supported. > > > > > > It is our understanding that IEEE Std 802.1ad does not > > > preclude the translation of 802.1Q S-VLAN tags at any > > > S-tagged interface. Thus, this translation would be allowed > > > at Provider Network Ports, not just at Customer Network Ports. > > > > > > Can you please confirm whether this is the correct > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > > > Std 802.1Q? > > > > > > Many thanks, > > > > > > Bert Wijnen, IETF liaison to IEEE 802.1 > > > Adrian Farrel and Deborah Brungard, CCAMP Working Group > co-chairs > > > > > > > > > > > > > > > > _______________________________________________ > > gels mailing list > > gels@rtg.ietf.org > > https://rtg.ietf.org/mailman/listinfo/gels > > > > -- 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 From owner-ccamp@ops.ietf.org Thu Sep 21 08:29:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNgG-0000T5-0L for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:29:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNgB-0002Ml-A0 for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:29:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQNXx-000Ha8-Sw for ccamp-data@psg.com; Thu, 21 Sep 2006 12:20:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQNXv-000HZH-N7 for ccamp@ops.ietf.org; Thu, 21 Sep 2006 12:20:52 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 15:20:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 15:20:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: AcbdftFBQ4XXOrHzQmehkQbu8IRfdwAAc4dA From: "Nurit Sprecher" To: "Loa Andersson" Cc: , , X-OriginalArrivalTime: 21 Sep 2006 13:20:01.0075 (UTC) FILETIME=[A46C4830:01C6DD80] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 I approve the liaison as stated.=20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Loa Andersson Sent: Thursday, September 21, 2006 14:03 Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com Subject: Re: Proposed liaison response to IEEE All, there have been a number of correct statements in this short thread. Neil is right (given the layered network model) that Ethernet is a layer network and as such connectionless and packet oriented. Nurit is right that if you configure a VLAN on only to parts of an Ethernet bridge the frame will go through without looking at the MAC address Don is right that the liaison does not capture an earlier comment he made on the gels-list. Neither does it capture a comment made by Attila. However, if I understand what is happening here is that we need to clarify a paragraph in the liaison form the IEEE802.1 on translation of S-VIDs. I guess that this is something we all need to understand, and given the answer, it will be possible to follow up with further more precise questions. If for example the answer on S-VID translation is that it is not supported other than at domain borders, then the question on whether it needs to be done by taking the MAC-address into consideration or not will have very different meaning. Let agree on getting the liaison out, and then decide on what we do next depending on the answer. /Loa Nurit Sprecher wrote: > Hi Neil, > Thanks for your clarification.=20 > Please note that the discussion below relates to the liaison that the=20 > IETF wants to send to the IEEE in order to understand the standard=20 > behavior of the Ethernet forwarding behavior. As I understand it, Don=20 > was concerned that S-VID translation does not preclude the forwarding=20 > decision which is based on the MAC address. My intention was to=20 > indicate that for point-to-point VLAN connection (on a link), MAC=20 > learning is not required by the 802.1Qrev-5 spec and the forwarding=20 > decision does not rely on the MAC address. This is not a discussion on > networking but on the standard behavior of the 802.1Q bridges. > Regards, > Nuritl. >=20 > ________________________________ >=20 > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, September 21, 2006 13:00 > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > Subject: RE: Proposed liaison response to IEEE >=20 >=20 > Nurit.....precision is indeed important. In a co mode layer network=20 > connections can be p2p or p2mp in nature and each can be composed of=20 > multiple concatenated subnetwork-connections (ie nodes in THIS layer > network) and link-connections......noting that a single p2p=20 > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > network is NOT a connection in THAT (ie Ethernet) layer network=20 > (though it will be supported by a trail which is provided by a=20 > connection in some lower layer network). > =20 > regards, Neil >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > Behalf Of Nurit Sprecher > Sent: 21 September 2006 12:38 > To: Don Fedyk; Adrian Farrel > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Nurit=20 > Sprecher > Subject: RE: Proposed liaison response to IEEE > =09 > =09 >=20 > Hi, >=20 > =20 >=20 > I think it is a good idea to send the liaison to the IEEE and get=20 > once and for all a clear statement that the s-vid translation is=20 > supported on each provider bridge port. >=20 > =20 >=20 > In addition, the IEEE has recognized that MAC learning is not=20 > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > already includes this extension in section 8.7. >=20 > =20 >=20 > " The Learning Process receives the source MAC Addresses and VIDs of=20 > received frames from the >=20 > Forwarding Process, following the application of the ingress rules=20 > (8.6.2). It shall create or update a >=20 > Dynamic Filtering Entry (8.8.3) that specifies the reception Port for=20 > the frame's source address and VID, if >=20 > and only if the source address is an Individual Address, i.e., is not=20 > a Group Address, the resulting number of >=20 > entries would not exceed the capacity of the Filtering Database, and=20 > the filtering utility criteria for the >=20 > receiving Bridge Port are met." >=20 > The enhanced filtering utility criteria "are satisfied if at least=20 > one VLAN that uses the FID includes the reception Port and at least=20 > one other Port with a Port State of Learning or Forwarding in its=20 > member set, and: a) The operPointToPointMAC parameter is false for the > reception Port; or b) Ingress to the VLAN is permitted through a third > Port. NOTE -The third port can, but is not required to be in the=20 > member set.". >=20 > =20 >=20 > I think it is clearly stated, but if it is required to ask the IEEE=20 > about the context of forwarding based on a destination MAC, I suggest=20 > being more precise and specify that we are talking on point-to-point=20 > connections. >=20 > =20 >=20 > Regards, >=20 > Nurit. >=20 > =20 >=20 > -----Original Message----- > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > Sent: Wednesday, September 20, 2006 23:16 > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > Subject: RE: Proposed liaison response to IEEE >=20 > =20 >=20 > Hi Adrian >=20 > =20 >=20 > The Liaison looks good however it does not capture a comment I > made. =20 >=20 > =20 >=20 > My understanding of the S-VLAN translation in IEEE documents and the >=20 > liaison is that the translation is valid in the context of forwarding >=20 > based on a destination MAC. My interpretation is that V-LAN is=20 > optional >=20 > MAC is not. If I am correct VLAN translation as specified is not > equal >=20 > to Label switching. The Liaison is clear about not just the format of >=20 > 'packets on the wire' but the relationship to the entities such as=20 > MAC >=20 > relay as well. =20 >=20 > =20 >=20 > I think we should also ask in our liaison for clarification if the >=20 > S-VLAN translation can be valid by itself i.e. as a label agnostic to >=20 > the MAC so there is no confusion. >=20 > =20 >=20 > Thanks, >=20 > Don >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- >=20 > > From: owner-ccamp@ops.ietf.org >=20 > > All, >=20 > > >=20 > > The IETF received an unsolicited liaison on the subject of >=20 > > 802.1 Ethernet >=20 > > >=20 > > You can see the liaison at >=20 > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > > >=20 > > The participants on the GELS mailing list have requested that >=20 > > we respond to this to clarify an issue. >=20 > > >=20 > > Here is the draft of a liaison that we proposed to send.=20 >=20 > > Please shout at once if you have any concerns with this >=20 > > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > > >=20 > > Thanks, >=20 > > Adrian >=20 > > =3D=3D=3D >=20 > > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > > >=20 > > Date: Sep 2006 >=20 > > To: IEEE802.1 >=20 > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > > >=20 > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 >=20 > > Adrian Farrel, IETF CCAMP Working Group co-chair >=20 > > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > > >=20 > > Cc: Bernard Aboba bernard_aboba@hotmail.com >=20 > > Ross Callon rcallon@juniper.net >=20 > > Bill Fenner fenner@research.att.com >=20 > > CCAMP mailing list ccamp@ops.ietf.org >=20 > > GELS mailing list gels@rtg.ietf.org >=20 > > >=20 > > Thank you for your very informative and clarifying liaison on >=20 > > "Use of IEEE 802.1Q VLAN tags". >=20 > > >=20 > > We have a question arising from this liaison and our reading >=20 > > of the relevant standards documents as follows. >=20 > > >=20 > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 >=20 > > bit VIDs) is supported at S-tagged service interfaces, as an >=20 > > option, by the IEEE Std 802.1ad Provider Bridging amendment >=20 > > to IEEE Std 802.1Q." >=20 > > >=20 > > While this text in itself is clear it leaves open the >=20 > > question of whether "S-tagged Service interfaces" is the only >=20 > > type of interface where Translation of 802.1Q S-VLAN tags is >=20 > > supported. >=20 > > >=20 > > It is our understanding that IEEE Std 802.1ad does not >=20 > > preclude the translation of 802.1Q S-VLAN tags at any >=20 > > S-tagged interface. Thus, this translation would be allowed >=20 > > at Provider Network Ports, not just at Customer Network Ports. >=20 > > >=20 > > Can you please confirm whether this is the correct >=20 > > interpretation of the IEEE Std 802.1ad amendment to the IEEE >=20 > > Std 802.1Q? >=20 > > >=20 > > Many thanks, >=20 > > >=20 > > Bert Wijnen, IETF liaison to IEEE 802.1 >=20 > > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 > > >=20 > > >=20 > > >=20 > > >=20 > =20 >=20 > _______________________________________________ >=20 > gels mailing list >=20 > gels@rtg.ietf.org >=20 > https://rtg.ietf.org/mailman/listinfo/gels >=20 > =20 >=20 >=20 -- 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 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels From owner-ccamp@ops.ietf.org Thu Sep 21 08:41:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNrU-0008Gx-NL for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:41:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNrP-0004Xl-9a for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:41:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQNj1-000KC1-EX for ccamp-data@psg.com; Thu, 21 Sep 2006 12:32:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQNiw-000KAh-BG for ccamp@ops.ietf.org; Thu, 21 Sep 2006 12:32:15 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2006 08:32:13 -0400 X-IronPort-AV: i="4.09,195,1157342400"; d="scan'208,217"; a="103674977:sNHT66581864" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8LCWDqY011817; Thu, 21 Sep 2006 08:32:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8LCWCuI004303; Thu, 21 Sep 2006 08:32:13 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 08:32:12 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 08:32:11 -0400 In-Reply-To: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe> References: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: multipart/alternative; boundary=Apple-Mail-36-146102614 Message-Id: Cc: , "Ross Callon" From: JP Vasseur Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Thu, 21 Sep 2006 08:32:08 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Sep 2006 12:32:11.0095 (UTC) FILETIME=[F5C81670:01C6DD79] DKIM-Signature: a=rsa-sha1; q=dns; l=32785; t=1158841933; x=1159705933; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20Routing=20Directorate=20comments=20on=20draft-ietf-ccamp-automes h-01 |To:=22Adrian=20Farrel=22=20; X=v=3Dcisco.com=3B=20h=3DMEBChjdj4/CIq2s4jZyCacxjCHY=3D; b=sXj5s6poseORm4S1h5YvITMwou/LKpYraejs7ohNNUIhXCNhklGdGcrodhrzcKQ4vJxkPtgd kD8SKBPcfD7rAs1u+sPkPgec9jn8k4gmeMRMQFhNZFSA89AEcESREZE6; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2df02f1a0db129c5d94869f6959903ec --Apple-Mail-36-146102614 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi Adrian, On Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote: > Hi, > > We held an additional last call for this draft in the IGP working =20 > groups and received some further comments that JP has just =20 > addressed in a new revision. > > We have also received some comments from a review in the Routing =20 > Directorate that I am pr=E9cising below. JP, authors: please look =20 > through these and let us know your proposals for dealing with them. > Sure, in line. > Thanks, > Adrian > > =3D=3D=3D > > 1) The Tail-end name field facilitates LSP identification. Is this =20 > a new form of LSP identification? > If it is not new, then there should be a reference to RFC3209 and a =20= > statement of which RFC3209 fields are mapped to this IGP field. > If it is not new then there is a significant concern that a new =20 > identification is being introduced when it is not needed. As indicated in the document the string refers to a "Tail-end" name, =20 not an TE LSP name: thus it does not replace the session name of the =20 SESSION-ATTRIBUTE object defined in RFC3209. > > 2) The document mentions that the number of mesh groups is limited =20 > but potentially (depending on encoding) provides for binary =20 > encoding for > 2^32-1 groups (although this might be constrained by OSPF's limit =20 > of a TLV size to 2^16 bytes. > The document (and the authors) state that scaling of these =20 > extensions is not an issue because only a small number of mesh =20 > groups are likely to be in existence in a network, and any one =20 > router is unlikely to participate in more than a very few. > There are two concerns: > a) Whenever we say that something in the Internet is limited, =20 > history usually proves us wrong. And that's undoubtedly a good news :-) > Indeed, there is already a > proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a =20 > similar mechanism for a problem that would have far more groups. Two comments: - Mesh groups are used to set up TE LSP meshes. If we consider let =20 say 10 meshes comprising 100 routers each, that gives us 99,000 TE =20 LSPs. One can easily see that the number of meshes is unlikely to =20 explode in a foreseeable future. If it turns out to be the case, =20 we'll have other scalability issues to fix before any potential with =20 the IGP. - More importantly, the dynamics of joining a TE mesh is such that =20 IGP updates are used to advertise to TE mesh group membership change =20 (join or prune), which are indeed expected to be very unfrequent. > b) The I-D does not itself impose any reasonable limits on the =20 > number of groups with the potential for a single router (by =20 > misconfiguration, design, or malice) advertising a very large =20 > number of groups. > Thus, it appears that the scaling concerns are not properly =20 > addressed in this I-D. > Not sure to see the point here. If indeed, a large number of TE MESH =20 GROUPs were advertised, this would not impact the other LSRs since =20 they would not create any new TE LSPs trying to join the new TE-MESH-=20 GROUP. In term of amount of flooded information, this should not be a =20= concern either (handled by routing). We clarified this in the =20 security section. > 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL =20 > and must at most appear once in a OSPF Router Information LSA or =20 > ISIS Router Capability TLV." but for addition/removal it mentions =20 > "conversely, if the LSR leaves a mesh-group the corresponding entry =20= > will be removed from the TE-MESH-GROUP TLV." > What are these "entries" referring to - that there is a top-level =20 > TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions =20= > "No sub-TLV is currently defined for the TE-mesh-group TLV") ? > > AF>> My comment on this is that the definition of the TLVs seems =20 > unclear. > AF>> =46rom figure 2, it appears that some additional information can = be > AF>> present in the TLV after the fields listed, and (reading =20 > between the > AF>> lines) it would appear that this additional information is a =20 > series of > AF>> repeats of the set of fields to define multiple mesh groups. > AF>> This could usefully be clarified considerably. > You're absolutely right. The figures have been modified: (example show below): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // /=20= / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) > AF>> > AF>> But it is now unclear to me whether a single router can be a =20 > member > AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be > AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one > AF>> IPv6) are prohibited. OK the text requires some clarification. What is prohibited is to =20 have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is =20 permitted. New proposed text to clarify: The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and =20 one IPv6 instance MUST appear in a OSPF Router Information LSA or =20 ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or =20 IPv6) occurs more than once within the OSPF Router Information LSA, =20 only the first instance is processed, subsequent TLV(s) will be =20 silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 =20 or IPv6) occurs more than once within the ISIS Router capability TLV, =20= only the first instance is processed, subsequent TLV(s) will be =20 silently ignored. > > 4) Small terminology issue in section 5.1 it says: "Note that both =20 > operations can be performed in the context of a single refresh." > This is not a refresh. It is a trigger/update. A better term for =20 > OSPF would be "LSA origination". > OK fixed (I used the term "Update"), thanks. > 5) Please state the applicability to OSPF v2 and or v3. Note that =20 > the Router_Cap document covers both v2 and v3 Indeed, Thanks for the comments. The OSPFv3 aspects have been =20 incorporated. Here is the new text: The TE-MESH-GROUP TLV is advertised within an OSPF Router =20 Information opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328]) and within a new LSA (Router Information LSA) for OSPFv3 =20 ([RFC2740]). ... As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the flooding scope of the Router Information LSA is determined by the =20= LSA Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. For OSPFv2 Router Information opaque LSA: - Link-local scope: type 9; - Area-local scope: type 10; - Routing-domain scope: type 11. In this case, the flooding =20 scope is equivalent to the Type 5 LSA flooding scope. For OSPFv3 Router Information LSA: - Link-local scope: OSPFV3 Router Information LSA with the S1 and S2 bits cleared; - Area-local scope: OSPFV3 Router Information LSA with the S1 bit =20= set and the S2 bit cleared; - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit cleared and the S2 bit set. A router may generate multiple OSPF Router Information LSAs with different flooding scopes. The TE-MESH-GROUP TLV may be advertised within an Area-local or Routing-domain scope Router Information LSA depending on the MPLS TE mesh group profile: - If the MPLS TE mesh-group is contained within a single area (all the LSRs of the mesh-group are contained within a single area), the TE-MESH-GROUP TLV MUST be generated within an Area-local Router Information LSA; - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- group TLV MUST be generated within a Routing-domain scope router information LSA. > > 6) The term "fairly static" at the end of section 5.1 is =20 > meaningless without some relative context. > Presumably this relates to the number times an LSR joins or leaves =20 > a mesh group over time. > Is it intended to be relative to the IGP refresh period? > Please clarify in an objective rather than a subjective way. > Right, this requires clarification. Here is the new text: Moreover, =20 TE mesh-group membership should not change frequently: each time an =20 LSR joins or leaves a new TE mesh-group. I guess that this is sufficiently explicit: it is a well-known fact =20 that LSRs are infrequently added or removed to a TE mesh. > 7) The security section (section 8) is inadequate and will =20 > undoubtedly be rejected by the security ADs. At the very least, the =20= > I-D needs a paragraph (i.e. more than one or two lines) explaining =20 > why there are no new security considerations. But what would be the =20= > impact of adding false mesh groups to a TLV? Is there anything =20 > (dangerous) that can be learned about the network by inspecting =20 > mesh group TLVs? > The following section has been added: No new security issues are raised in this document. Any new =20 security issues raised by the procedures in this document depend upon the opportunity for LSAs/LSPs to be snooped, the ease/difficulty of =20 which has not been altered. Security considerations are covered in [RFC2328] and [RFC2740] for the base OSPF protocol and in [RFC1194] for IS-IS. As the LSPs may now contain additional information regarding router capabilities, this new information would also =20 become available. Note that intentional or unintentional advertisement of "fake" TE Mesh Groups by an LSR A does not have any impact on other LSRs since an LSR B would only try to signal a TE LSP torward that advertizing LSR A to join the advertized TE Mesh TE Group if and =20 only if such TE Mesh Group is also locally configured on LSR B. + new references added. Does that address the comments ? Thanks. JP.= --Apple-Mail-36-146102614 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

On = Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote:

Hi,

We held an additional last call = for this draft in the IGP working groups and received some further = comments that JP has just addressed in a new revision.

We have = also received some comments from a review in the Routing Directorate = that I am pr=E9cising below. JP, authors: please look through these and = let us know your proposals for dealing with them.


Sure, in = line.

Thanks,
Adrian

=3D=3D=3D

1) The = Tail-end name field facilitates LSP identification. Is this a new form = of LSP identification?
If it is not new, then = there should be a reference to RFC3209 and a statement of which RFC3209 = fields are mapped to this IGP field.
If it is not = new then there is a significant concern that a new identification is = being introduced when it is not needed.

As indicated in the = document the string refers to a "Tail-end" name, not an TE LSP name: = thus it does not replace the session name of the SESSION-ATTRIBUTE = object defined in RFC3209.=A0


2) The = document mentions that the number of mesh groups is limited but = potentially (depending on encoding) provides for binary encoding = for
2^32-1 groups (although this = might be constrained by OSPF's limit of a TLV size to 2^16 = bytes.
The document (and the authors) = state that scaling of these extensions is not an issue because only a = small number of mesh groups are likely to be in existence in a network, = and any one router is unlikely to participate in more than a very = few.
There are two = concerns:
a) Whenever we say that = something in the Internet is limited, history usually proves us wrong. =

And that's undoubtedly a = good news :-)=A0

Indeed, there is already a
proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) = that uses a similar mechanism for a problem that would have far more = groups.

Two comments:
- = Mesh groups are used to set up TE LSP meshes. If we consider let say 10 = meshes comprising 100 routers each, that gives us 99,000 TE LSPs. One = can easily see that the number of meshes is unlikely to explode in = a=A0foreseeable future. If it turns out to be the case, we'll have other = scalability issues to fix before any potential with the IGP.
- = More importantly, the dynamics of joining a TE mesh is such that IGP = updates are used to advertise to TE mesh group membership change (join = or prune), which are indeed expected to be very = unfrequent.

b) The = I-D does not itself impose any reasonable limits on the number of groups = with the potential for a single router (by misconfiguration, design, or = malice) advertising a very large number of groups.
Thus, it appears that the scaling concerns are not = properly addressed in this I-D.


Not sure to see the point = here. If indeed, a large number of TE MESH GROUPs were advertised, this = would not impact the other LSRs since they would not create any new TE = LSPs trying to join the new TE-MESH-GROUP. In term of amount of flooded = information, this should not be a concern either (handled by routing). = We clarified this in the security section.

3) The document mentions that "The TE-MESH-GROUP TLV = is OPTIONAL and must at most appear once in a OSPF Router Information = LSA or ISIS Router Capability TLV." but for addition/removal it mentions = "conversely, if the LSR leaves a mesh-group the corresponding entry will = be removed from the TE-MESH-GROUP TLV."
What are = these "entries" referring to - that there is a top-level TE-MESH-GROUP = TLV with multiple sub-TLVs (but the document mentions "No sub-TLV is = currently defined for the TE-mesh-group TLV") ?

AF>> =46rom figure 2, it = appears that some additional information can be
AF>> present in the TLV after the fields = listed, and (reading between the
AF>> = lines) it would appear that this additional information is a series = of
AF>> repeats of the set of fields to = define multiple mesh groups.
AF>> = This could usefully be clarified considerably.


You're absolutely right. = The figures have been modified:

(example show = below):

=A0 =A0= =A0=A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = mesh-group-number 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Tail-end IPv4 = address 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 Name length=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = Tail-end name 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0=A0 //=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = //
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = mesh-group-number n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Tail-end IPv4 = address n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0=A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
=A0 =A0 =A0 |=A0 Name length=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = Tail-end name n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0 =A0 =A0 =A0 =A0 = Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)


AF>>
AF>> = But it is now unclear to me whether a single router can be a = member
AF>> of IPv4 an IPv6 mesh = groups. It would seem that these cannot be
AF>> IPv6) are = prohibited.

OK the text requires some = clarification. What is prohibited is to have two IPv4 sub-TLV or two = IPv6 sub-TLV but one of each is permitted. New proposed text to = clarify:

The= TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and one = IPv6 instance MUST appear in a OSPF Router Information LSA or ISIS = Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) = occurs more than once within the OSPF Router Information LSA, only the = first instance is processed, subsequent TLV(s) will be silently ignored. = Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 or IPv6) occurs more = than once within the ISIS Router capability TLV, only the first instance = is processed, subsequent TLV(s) will be silently = ignored.


4) Small = terminology issue in section 5.1 it says: "Note that both operations can = be performed in the context of a single refresh."
This is not a refresh. It is a trigger/update. A = better term for OSPF would be "LSA origination".


OK fixed (I used the term = "Update"), thanks.

5) = Please state the applicability to OSPF v2 and or v3. Note that the = Router_Cap document covers both v2 and v3

Indeed, Thanks for the = comments.=A0 The OSPFv3 aspects have been incorporated. Here is the new = text:

=A0 = =A0The TE-MESH-GROUP TLV is advertised within an OSPF Router = Information
=A0=A0 opaque LSA (opaque type of 4, opaque = ID of 0) for OSPFv2 ([RFC2328])
=A0=A0 and within a new = LSA (Router Information LSA) for OSPFv3 = ([RFC2740]).

...
<= BR class=3D"khtml-block-placeholder">
=A0 =A0As defined = in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, = the
=A0=A0 flooding scope of the Router Information LSA = is determined by the LSA
=A0=A0 Opaque type for OSPFv2 = and the values of the S1/S2 bits for OSPFv3.

=A0=A0 For OSPFv2 = Router Information opaque LSA:

=A0=A0 - Link-local = scope: type 9;

=A0=A0 - Area-local = scope: type 10;

=A0=A0 - = Routing-domain scope: type 11.=A0 In this case, the flooding scope = is
=A0=A0 equivalent to the Type 5 LSA flooding = scope.

=A0=A0 For OSPFv3 = Router Information LSA:

=A0=A0 - Link-local = scope: OSPFV3 Router Information LSA with the S1 and = S2
=A0=A0 bits cleared;

=A0=A0 - Area-local = scope: OSPFV3 Router Information LSA with the S1 bit = set
=A0=A0 and the S2 bit cleared;

=A0=A0 - = Routing-domain scope: OSPFv3 Router Information LSA with S1 = bit
=A0 =A0cleared and the S2 bit = set.

=A0=A0 A router may = generate multiple OSPF Router Information LSAs with
=A0=A0= different flooding scopes.=A0 The TE-MESH-GROUP TLV may be = advertised
=A0=A0 within an Area-local or = Routing-domain scope Router Information LSA
=A0=A0 = depending on the MPLS TE mesh group profile:

=A0=A0 - If the MPLS = TE mesh-group is contained within a single area (all
=A0=A0= the LSRs of the mesh-group are contained within a single area), = the
=A0=A0 TE-MESH-GROUP TLV MUST be generated within = an Area-local Router
=A0=A0 Information = LSA;

=A0=A0 - If the MPLS = TE mesh-group spans multiple OSPF areas, the TE = mesh-
=A0=A0 group TLV MUST be generated within a = Routing-domain scope router
=A0=A0 information = LSA.


6) The = term "fairly static" at the end of section 5.1 is meaningless without = some relative context.
Presumably this relates to = the number times an LSR joins or leaves a mesh group over = time.
Is it intended to be relative to = the IGP refresh period?
Please = clarify in an objective rather than a subjective way.


Right, this requires = clarification. Here is the new text:=A0Moreover, TE mesh-group = membership should not change frequently: each time an LSR joins or = leaves a new TE mesh-group.=A0

I guess that this is = sufficiently explicit: it is a well-known fact that LSRs = are=A0infrequently added or removed to a TE mesh.

7) The security section (section 8) is inadequate = and will undoubtedly be rejected by the security ADs. At the very least, = the I-D needs a paragraph (i.e. more than one or two lines) explaining = why there are no new security considerations. But what would be the = impact of adding false mesh groups to a TLV? Is there anything = (dangerous) that can be learned about the network by inspecting mesh = group TLVs?

=

The following section has been = added:

=A0 =A0No new security issues are raised = in this document.=A0 Any new security
=A0=A0 = issues raised by the procedures in this document depend upon = the
=A0=A0 opportunity for LSAs/LSPs to be snooped, the = ease/difficulty of which
=A0=A0 has not been altered.=A0 = Security considerations are covered in
=A0=A0 [RFC2328] = and [RFC2740] for the base OSPF protocol and in = [RFC1194]
=A0=A0 for IS-IS.=A0 As the LSPs may now = contain additional information
=A0=A0 regarding router = capabilities, this new information would also become
=A0 = =A0available.=A0 Note that intentional or unintentional advertisement = of
=A0=A0 "fake" TE Mesh Groups by an LSR A does not = have any impact on other
=A0=A0 LSRs since an LSR B = would only try to signal a TE LSP torward that
=A0=A0 = advertizing LSR A to join the advertized TE Mesh TE Group if and = only
=A0=A0 if such TE Mesh Group is also locally = configured on LSR B.

+ new references = added.


Does that address the = comments ?

Thanks.

JP.
= --Apple-Mail-36-146102614-- From owner-ccamp@ops.ietf.org Thu Sep 21 09:07:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOGv-0006nz-5e for ccamp-archive@ietf.org; Thu, 21 Sep 2006 09:07:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOG8-00080c-1F for ccamp-archive@ietf.org; Thu, 21 Sep 2006 09:07:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQO9D-000PlU-Ae for ccamp-data@psg.com; Thu, 21 Sep 2006 12:59:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQO98-000Pk8-2e for ccamp@ops.ietf.org; Thu, 21 Sep 2006 12:59:18 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DE9FA500002; Thu, 21 Sep 2006 14:59:16 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 14:59:16 +0200 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: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 14:59:15 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D05012D42A2@esealmw116.eemea.ericsson.se> In-Reply-To: <45127F6F.8050907@pi.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: AcbddldP273KLlRIQzqoEjlyRQM/3gABdK1Q From: "Attila Takacs \(IJ/ETH\)" To: "Loa Andersson" Cc: , , X-OriginalArrivalTime: 21 Sep 2006 12:59:16.0457 (UTC) FILETIME=[BE92A590:01C6DD7D] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Hi all, I also support the liaison as it is.=20 We will anyhow need to clarify a set of other issues later but these would now over complicated this liaison. BTW, I think the enhanced filtering criteria is not applicable if one applies S-VID translation since the ingress and egress VIDs are different. An other note: even when the enhanced filtering criteria is applied the MAC address is considered by forwarding however due to suppressed MAC learning (no entry for the MAC in FDB) the frame will be "broadcasted" over the (in this case) only one available egress VLAN member port. Regards, Attila > -----Original Message----- > From: gels-bounces@rtg.ietf.org=20 > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, September 21, 2006 2:03 PM > Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com > Subject: Re: Proposed liaison response to IEEE >=20 > All, >=20 > there have been a number of correct statements in this short thread. >=20 > Neil is right (given the layered network model) that Ethernet=20 > is a layer network and as such connectionless and packet oriented. >=20 > Nurit is right that if you configure a VLAN on only to parts=20 > of an Ethernet bridge the frame will go through without=20 > looking at the MAC address >=20 > Don is right that the liaison does not capture an earlier=20 > comment he made on the gels-list. Neither does it capture a=20 > comment made by Attila. >=20 > However, if I understand what is happening here is that we=20 > need to clarify a paragraph in the liaison form the IEEE802.1=20 > on translation of S-VIDs. >=20 > I guess that this is something we all need to understand, and=20 > given the answer, it will be possible to follow up with=20 > further more precise questions. >=20 > If for example the answer on S-VID translation is that it is=20 > not supported other than at domain borders, then the question=20 > on whether it needs to be done by taking the MAC-address into=20 > consideration or not will have very different meaning. >=20 > Let agree on getting the liaison out, and then decide on what=20 > we do next depending on the answer. >=20 > /Loa >=20 > Nurit Sprecher wrote: > > Hi Neil, > > Thanks for your clarification.=20 > > Please note that the discussion below relates to the=20 > liaison that the=20 > > IETF wants to send to the IEEE in order to understand the standard=20 > > behavior of the Ethernet forwarding behavior. As I=20 > understand it, Don=20 > > was concerned that S-VID translation does not preclude the=20 > forwarding=20 > > decision which is based on the MAC address. My intention was to=20 > > indicate that for point-to-point VLAN connection (on a link), MAC=20 > > learning is not required by the 802.1Qrev-5 spec and the forwarding=20 > > decision does not rely on the MAC address. This is not a=20 > discussion on=20 > > networking but on the standard behavior of the 802.1Q bridges. > > Regards, > > Nuritl. > >=20 > > ________________________________ > >=20 > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Thursday, September 21, 2006 13:00 > > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > > Subject: RE: Proposed liaison response to IEEE > >=20 > >=20 > > Nurit.....precision is indeed important. In a co mode=20 > layer network=20 > > connections can be p2p or p2mp in nature and each can be=20 > composed of=20 > > multiple concatenated subnetwork-connections (ie nodes in THIS layer > > network) and link-connections......noting that a single p2p=20 > > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > > network is NOT a connection in THAT (ie Ethernet) layer network=20 > > (though it will be supported by a trail which is provided by a=20 > > connection in some lower layer network). > > =20 > > regards, Neil > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of Nurit Sprecher > > Sent: 21 September 2006 12:38 > > To: Don Fedyk; Adrian Farrel > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert);=20 > ccamp@ops.ietf.org; Nurit=20 > > Sprecher > > Subject: RE: Proposed liaison response to IEEE > > =09 > > =09 > >=20 > > Hi, > >=20 > > =20 > >=20 > > I think it is a good idea to send the liaison to the=20 > IEEE and get=20 > > once and for all a clear statement that the s-vid translation is=20 > > supported on each provider bridge port. > >=20 > > =20 > >=20 > > In addition, the IEEE has recognized that MAC learning is not=20 > > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > > already includes this extension in section 8.7. > >=20 > > =20 > >=20 > > " The Learning Process receives the source MAC=20 > Addresses and VIDs of=20 > > received frames from the > >=20 > > Forwarding Process, following the application of the=20 > ingress rules=20 > > (8.6.2). It shall create or update a > >=20 > > Dynamic Filtering Entry (8.8.3) that specifies the=20 > reception Port for=20 > > the frame's source address and VID, if > >=20 > > and only if the source address is an Individual=20 > Address, i.e., is not=20 > > a Group Address, the resulting number of > >=20 > > entries would not exceed the capacity of the Filtering=20 > Database, and=20 > > the filtering utility criteria for the > >=20 > > receiving Bridge Port are met." > >=20 > > The enhanced filtering utility criteria "are satisfied=20 > if at least=20 > > one VLAN that uses the FID includes the reception Port and at least=20 > > one other Port with a Port State of Learning or Forwarding in its=20 > > member set, and: a) The operPointToPointMAC parameter is=20 > false for the=20 > > reception Port; or b) Ingress to the VLAN is permitted=20 > through a third=20 > > Port. NOTE -The third port can, but is not required to be in the=20 > > member set.". > >=20 > > =20 > >=20 > > I think it is clearly stated, but if it is required to=20 > ask the IEEE=20 > > about the context of forwarding based on a destination MAC,=20 > I suggest=20 > > being more precise and specify that we are talking on=20 > point-to-point=20 > > connections. > >=20 > > =20 > >=20 > > Regards, > >=20 > > Nurit. > >=20 > > =20 > >=20 > > -----Original Message----- > > From: gels-bounces@rtg.ietf.org > > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > > Sent: Wednesday, September 20, 2006 23:16 > > To: Adrian Farrel; ccamp@ops.ietf.org > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > > Subject: RE: Proposed liaison response to IEEE > >=20 > > =20 > >=20 > > Hi Adrian > >=20 > > =20 > >=20 > > The Liaison looks good however it does not capture a comment I > > made. =20 > >=20 > > =20 > >=20 > > My understanding of the S-VLAN translation in IEEE=20 > documents and the > >=20 > > liaison is that the translation is valid in the context=20 > of forwarding > >=20 > > based on a destination MAC. My interpretation is that V-LAN is=20 > > optional > >=20 > > MAC is not. If I am correct VLAN translation as=20 > specified is not=20 > > equal > >=20 > > to Label switching. The Liaison is clear about not just=20 > the format of > >=20 > > 'packets on the wire' but the relationship to the=20 > entities such as=20 > > MAC > >=20 > > relay as well. =20 > >=20 > > =20 > >=20 > > I think we should also ask in our liaison for=20 > clarification if the > >=20 > > S-VLAN translation can be valid by itself i.e. as a=20 > label agnostic to > >=20 > > the MAC so there is no confusion. > >=20 > > =20 > >=20 > > Thanks, > >=20 > > Don > >=20 > > =20 > >=20 > > =20 > >=20 > > > -----Original Message----- > >=20 > > > From: owner-ccamp@ops.ietf.org > >=20 > > > All, > >=20 > > > > >=20 > > > The IETF received an unsolicited liaison on the subject of > >=20 > > > 802.1 Ethernet > >=20 > > > > >=20 > > > You can see the liaison at > >=20 > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > >=20 > > > > >=20 > > > The participants on the GELS mailing list have requested that > >=20 > > > we respond to this to clarify an issue. > >=20 > > > > >=20 > > > Here is the draft of a liaison that we proposed to send.=20 > >=20 > > > Please shout at once if you have any concerns with this > >=20 > > > liaison. I intend to ask Bert to send it on Monday of=20 > next week. > >=20 > > > > >=20 > > > Thanks, > >=20 > > > Adrian > >=20 > > > =3D=3D=3D > >=20 > > > Subject: Response to your liaison "Use of IEEE 802.1Q=20 > VLAN tags" > >=20 > > > > >=20 > > > Date: Sep 2006 > >=20 > > > To: IEEE802.1 > >=20 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > >=20 > > > > >=20 > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > >=20 > > > Deborah Brungard, IETF CCAMP Working Group co-chair > >=20 > > > > >=20 > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > >=20 > > > Ross Callon rcallon@juniper.net > >=20 > > > Bill Fenner fenner@research.att.com > >=20 > > > CCAMP mailing list ccamp@ops.ietf.org > >=20 > > > GELS mailing list gels@rtg.ietf.org > >=20 > > > > >=20 > > > Thank you for your very informative and clarifying liaison on > >=20 > > > "Use of IEEE 802.1Q VLAN tags". > >=20 > > > > >=20 > > > We have a question arising from this liaison and our reading > >=20 > > > of the relevant standards documents as follows. > >=20 > > > > >=20 > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > >=20 > > > bit VIDs) is supported at S-tagged service interfaces, as an > >=20 > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > >=20 > > > to IEEE Std 802.1Q." > >=20 > > > > >=20 > > > While this text in itself is clear it leaves open the > >=20 > > > question of whether "S-tagged Service interfaces" is the only > >=20 > > > type of interface where Translation of 802.1Q S-VLAN tags is > >=20 > > > supported. > >=20 > > > > >=20 > > > It is our understanding that IEEE Std 802.1ad does not > >=20 > > > preclude the translation of 802.1Q S-VLAN tags at any > >=20 > > > S-tagged interface. Thus, this translation would be allowed > >=20 > > > at Provider Network Ports, not just at Customer Network Ports. > >=20 > > > > >=20 > > > Can you please confirm whether this is the correct > >=20 > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > >=20 > > > Std 802.1Q? > >=20 > > > > >=20 > > > Many thanks, > >=20 > > > > >=20 > > > Bert Wijnen, IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel and Deborah Brungard, CCAMP Working=20 > Group co-chairs > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > =20 > >=20 > > _______________________________________________ > >=20 > > gels mailing list > >=20 > > gels@rtg.ietf.org > >=20 > > https://rtg.ietf.org/mailman/listinfo/gels > >=20 > > =20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > 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=20 > _______________________________________________ > gels mailing list > gels@rtg.ietf.org > https://rtg.ietf.org/mailman/listinfo/gels >=20 From owner-ccamp@ops.ietf.org Thu Sep 21 09:43:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOpS-0002XC-9C for ccamp-archive@ietf.org; Thu, 21 Sep 2006 09:43:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOos-0007Fy-2x for ccamp-archive@ietf.org; Thu, 21 Sep 2006 09:43:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQOhl-0005As-RQ for ccamp-data@psg.com; Thu, 21 Sep 2006 13:35:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQOhi-00058Z-8r for ccamp@ops.ietf.org; Thu, 21 Sep 2006 13:35:02 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 16:34:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 16:34:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: AcbddldP273KLlRIQzqoEjlyRQM/3gABdK1QAAN6wBA= From: "Nurit Sprecher" To: "Attila Takacs \(IJ/ETH\)" , "Loa Andersson" Cc: , , , "Nurit Sprecher" X-OriginalArrivalTime: 21 Sep 2006 14:34:11.0051 (UTC) FILETIME=[00D0BBB0:01C6DD8B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Out of scope of the discussion of the liaison... In general, I suggest that before statements on what is applicable and what is not, the IEEE standards are carefully learnt ....... (1) the enhanced filtering criteria does apply with S-VID translation.....there is a VLAN classification process at the ingress........the learning process and the forwarding decisions are taken on the internal VLAN to which the coming frame was classified.......the translation operation is performed after the outgoing port is determined........ (2) If that was true, the entire VLAN concept would loose it meaning............can not we support broadcasting of unknown frames correctly with s-vid translation??????????? (3) etc. Nurit. -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Attila Takacs (IJ/ETH) Sent: Thursday, September 21, 2006 14:59 To: Loa Andersson Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com Subject: RE: Proposed liaison response to IEEE Hi all, I also support the liaison as it is.=20 We will anyhow need to clarify a set of other issues later but these would now over complicated this liaison. BTW, I think the enhanced filtering criteria is not applicable if one applies S-VID translation since the ingress and egress VIDs are different. An other note: even when the enhanced filtering criteria is applied the MAC address is considered by forwarding however due to suppressed MAC learning (no entry for the MAC in FDB) the frame will be "broadcasted" over the (in this case) only one available egress VLAN member port. Regards, Attila > -----Original Message----- > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, September 21, 2006 2:03 PM > Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com > Subject: Re: Proposed liaison response to IEEE >=20 > All, >=20 > there have been a number of correct statements in this short thread. >=20 > Neil is right (given the layered network model) that Ethernet is a=20 > layer network and as such connectionless and packet oriented. >=20 > Nurit is right that if you configure a VLAN on only to parts of an=20 > Ethernet bridge the frame will go through without looking at the MAC=20 > address >=20 > Don is right that the liaison does not capture an earlier comment he=20 > made on the gels-list. Neither does it capture a comment made by=20 > Attila. >=20 > However, if I understand what is happening here is that we need to=20 > clarify a paragraph in the liaison form the IEEE802.1 on translation=20 > of S-VIDs. >=20 > I guess that this is something we all need to understand, and given=20 > the answer, it will be possible to follow up with further more precise > questions. >=20 > If for example the answer on S-VID translation is that it is not=20 > supported other than at domain borders, then the question on whether=20 > it needs to be done by taking the MAC-address into consideration or=20 > not will have very different meaning. >=20 > Let agree on getting the liaison out, and then decide on what we do=20 > next depending on the answer. >=20 > /Loa >=20 > Nurit Sprecher wrote: > > Hi Neil, > > Thanks for your clarification.=20 > > Please note that the discussion below relates to the > liaison that the > > IETF wants to send to the IEEE in order to understand the standard=20 > > behavior of the Ethernet forwarding behavior. As I > understand it, Don > > was concerned that S-VID translation does not preclude the > forwarding > > decision which is based on the MAC address. My intention was to=20 > > indicate that for point-to-point VLAN connection (on a link), MAC=20 > > learning is not required by the 802.1Qrev-5 spec and the forwarding=20 > > decision does not rely on the MAC address. This is not a > discussion on > > networking but on the standard behavior of the 802.1Q bridges. > > Regards, > > Nuritl. > >=20 > > ________________________________ > >=20 > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Thursday, September 21, 2006 13:00 > > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > > Subject: RE: Proposed liaison response to IEEE > >=20 > >=20 > > Nurit.....precision is indeed important. In a co mode > layer network > > connections can be p2p or p2mp in nature and each can be > composed of > > multiple concatenated subnetwork-connections (ie nodes in THIS layer > > network) and link-connections......noting that a single p2p=20 > > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > > network is NOT a connection in THAT (ie Ethernet) layer network=20 > > (though it will be supported by a trail which is provided by a=20 > > connection in some lower layer network). > > =20 > > regards, Neil > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On > > Behalf Of Nurit Sprecher > > Sent: 21 September 2006 12:38 > > To: Don Fedyk; Adrian Farrel > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Nurit > > Sprecher > > Subject: RE: Proposed liaison response to IEEE > > =09 > > =09 > >=20 > > Hi, > >=20 > > =20 > >=20 > > I think it is a good idea to send the liaison to the > IEEE and get > > once and for all a clear statement that the s-vid translation is=20 > > supported on each provider bridge port. > >=20 > > =20 > >=20 > > In addition, the IEEE has recognized that MAC learning is not=20 > > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > > already includes this extension in section 8.7. > >=20 > > =20 > >=20 > > " The Learning Process receives the source MAC > Addresses and VIDs of > > received frames from the > >=20 > > Forwarding Process, following the application of the > ingress rules > > (8.6.2). It shall create or update a > >=20 > > Dynamic Filtering Entry (8.8.3) that specifies the > reception Port for > > the frame's source address and VID, if > >=20 > > and only if the source address is an Individual > Address, i.e., is not > > a Group Address, the resulting number of > >=20 > > entries would not exceed the capacity of the Filtering > Database, and > > the filtering utility criteria for the > >=20 > > receiving Bridge Port are met." > >=20 > > The enhanced filtering utility criteria "are satisfied > if at least > > one VLAN that uses the FID includes the reception Port and at least=20 > > one other Port with a Port State of Learning or Forwarding in its=20 > > member set, and: a) The operPointToPointMAC parameter is > false for the > > reception Port; or b) Ingress to the VLAN is permitted > through a third > > Port. NOTE -The third port can, but is not required to be in the=20 > > member set.". > >=20 > > =20 > >=20 > > I think it is clearly stated, but if it is required to > ask the IEEE > > about the context of forwarding based on a destination MAC, > I suggest > > being more precise and specify that we are talking on > point-to-point > > connections. > >=20 > > =20 > >=20 > > Regards, > >=20 > > Nurit. > >=20 > > =20 > >=20 > > -----Original Message----- > > From: gels-bounces@rtg.ietf.org > > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > > Sent: Wednesday, September 20, 2006 23:16 > > To: Adrian Farrel; ccamp@ops.ietf.org > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > > Subject: RE: Proposed liaison response to IEEE > >=20 > > =20 > >=20 > > Hi Adrian > >=20 > > =20 > >=20 > > The Liaison looks good however it does not capture a comment I > > made. =20 > >=20 > > =20 > >=20 > > My understanding of the S-VLAN translation in IEEE > documents and the > >=20 > > liaison is that the translation is valid in the context > of forwarding > >=20 > > based on a destination MAC. My interpretation is that V-LAN is=20 > > optional > >=20 > > MAC is not. If I am correct VLAN translation as > specified is not > > equal > >=20 > > to Label switching. The Liaison is clear about not just > the format of > >=20 > > 'packets on the wire' but the relationship to the > entities such as > > MAC > >=20 > > relay as well. =20 > >=20 > > =20 > >=20 > > I think we should also ask in our liaison for > clarification if the > >=20 > > S-VLAN translation can be valid by itself i.e. as a > label agnostic to > >=20 > > the MAC so there is no confusion. > >=20 > > =20 > >=20 > > Thanks, > >=20 > > Don > >=20 > > =20 > >=20 > > =20 > >=20 > > > -----Original Message----- > >=20 > > > From: owner-ccamp@ops.ietf.org > >=20 > > > All, > >=20 > > > > >=20 > > > The IETF received an unsolicited liaison on the subject of > >=20 > > > 802.1 Ethernet > >=20 > > > > >=20 > > > You can see the liaison at > >=20 > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > >=20 > > > > >=20 > > > The participants on the GELS mailing list have requested that > >=20 > > > we respond to this to clarify an issue. > >=20 > > > > >=20 > > > Here is the draft of a liaison that we proposed to send.=20 > >=20 > > > Please shout at once if you have any concerns with this > >=20 > > > liaison. I intend to ask Bert to send it on Monday of > next week. > >=20 > > > > >=20 > > > Thanks, > >=20 > > > Adrian > >=20 > > > =3D=3D=3D > >=20 > > > Subject: Response to your liaison "Use of IEEE 802.1Q > VLAN tags" > >=20 > > > > >=20 > > > Date: Sep 2006 > >=20 > > > To: IEEE802.1 > >=20 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > >=20 > > > > >=20 > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > >=20 > > > Deborah Brungard, IETF CCAMP Working Group co-chair > >=20 > > > > >=20 > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > >=20 > > > Ross Callon rcallon@juniper.net > >=20 > > > Bill Fenner fenner@research.att.com > >=20 > > > CCAMP mailing list ccamp@ops.ietf.org > >=20 > > > GELS mailing list gels@rtg.ietf.org > >=20 > > > > >=20 > > > Thank you for your very informative and clarifying liaison on > >=20 > > > "Use of IEEE 802.1Q VLAN tags". > >=20 > > > > >=20 > > > We have a question arising from this liaison and our reading > >=20 > > > of the relevant standards documents as follows. > >=20 > > > > >=20 > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > >=20 > > > bit VIDs) is supported at S-tagged service interfaces, as an > >=20 > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > >=20 > > > to IEEE Std 802.1Q." > >=20 > > > > >=20 > > > While this text in itself is clear it leaves open the > >=20 > > > question of whether "S-tagged Service interfaces" is the only > >=20 > > > type of interface where Translation of 802.1Q S-VLAN tags is > >=20 > > > supported. > >=20 > > > > >=20 > > > It is our understanding that IEEE Std 802.1ad does not > >=20 > > > preclude the translation of 802.1Q S-VLAN tags at any > >=20 > > > S-tagged interface. Thus, this translation would be allowed > >=20 > > > at Provider Network Ports, not just at Customer Network Ports. > >=20 > > > > >=20 > > > Can you please confirm whether this is the correct > >=20 > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > >=20 > > > Std 802.1Q? > >=20 > > > > >=20 > > > Many thanks, > >=20 > > > > >=20 > > > Bert Wijnen, IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel and Deborah Brungard, CCAMP Working > Group co-chairs > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > =20 > >=20 > > _______________________________________________ > >=20 > > gels mailing list > >=20 > > gels@rtg.ietf.org > >=20 > > https://rtg.ietf.org/mailman/listinfo/gels > >=20 > > =20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > 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=20 > _______________________________________________ > gels mailing list > gels@rtg.ietf.org > https://rtg.ietf.org/mailman/listinfo/gels >=20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels From owner-ccamp@ops.ietf.org Thu Sep 21 11:11:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQD6-00057d-VP for ccamp-archive@ietf.org; Thu, 21 Sep 2006 11:11:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQQD0-00008E-4y for ccamp-archive@ietf.org; Thu, 21 Sep 2006 11:11:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQQ1x-000IL3-9W for ccamp-data@psg.com; Thu, 21 Sep 2006 15:00:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQQ1u-000IJl-5A for ccamp@ops.ietf.org; Thu, 21 Sep 2006 14:59:58 +0000 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 15:59:56 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 15:59:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 15:59:54 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389188FDB9B@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbddg77yvsiJyJpTXasuZ6O4lOTMwAALwBA From: To: Cc: , , X-OriginalArrivalTime: 21 Sep 2006 14:59:54.0889 (UTC) FILETIME=[9903B790:01C6DD8E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Thanks Loa.....this sounds OK to me and I'll go with the liaison as-is. However, one point we should bear in mind and that has not been stated so far is that the VLAN field assumes a different semantic in a co-ps mode layer network (be this PBT or VLAN-XC swapping) compared to its original cl-ps mode Ethernet layer network semantic. In the co-ps mode case it is either: - part of the trail termination address in PBT that does not get swapped during forwarding, ie the trail sink term address is the combination of DMAC+VCID; - a proxy for the trail termination address in VLAN-XC (BTW - I am not clear what VLAN-XC layer network addresses are here) that could be swapped on each link-connection. AFAI understand the original IEEE intent of a VLAN was to create a restricted broadcast domain within which a certain subset of the total MAC address population reside. These are quite different semantics. So asking for clarification of what IEEE mean by (and the scope of) swapping the VLAN field would still not really be comparable to such an action in a co-ps mode layer network. regards Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Loa Andersson > Sent: 21 September 2006 13:03 > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > Subject: Re: Proposed liaison response to IEEE >=20 >=20 > All, >=20 > there have been a number of correct statements in this short thread. >=20 > Neil is right (given the layered network model) that Ethernet > is a layer network and as such connectionless and packet oriented. >=20 > Nurit is right that if you configure a VLAN on only to parts > of an Ethernet bridge the frame will go through without=20 > looking at the MAC address >=20 > Don is right that the liaison does not capture an earlier > comment he made on the gels-list. Neither does it capture a=20 > comment made by Attila. >=20 > However, if I understand what is happening here is that we > need to clarify a paragraph in the liaison form the IEEE802.1=20 > on translation of S-VIDs. >=20 > I guess that this is something we all need to understand, and > given the answer, it will be possible to follow up with=20 > further more precise questions. >=20 > If for example the answer on S-VID translation is that it is > not supported other than at domain borders, then the question=20 > on whether it needs to be done by taking the MAC-address into=20 > consideration or not will have very different meaning. >=20 > Let agree on getting the liaison out, and then decide on what > we do next depending on the answer. >=20 > /Loa >=20 > Nurit Sprecher wrote: > > Hi Neil, > > Thanks for your clarification. > > Please note that the discussion below relates to the > liaison that the > > IETF wants to send to the IEEE in order to understand the standard=20 > > behavior of the Ethernet forwarding behavior. As I > understand it, Don > > was concerned that S-VID translation does not preclude the > forwarding > > decision which is based on the MAC address. My intention > was to indicate > > that for point-to-point VLAN connection (on a link), MAC > learning is not > > required by the 802.1Qrev-5 spec and the forwarding > decision does not > > rely on the MAC address. This is not a discussion on > networking but on > > the standard behavior of the 802.1Q bridges. > > Regards, > > Nuritl. > >=20 > > ________________________________ > >=20 > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Thursday, September 21, 2006 13:00 > > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > > Subject: RE: Proposed liaison response to IEEE > >=20 > >=20 > > Nurit.....precision is indeed important. In a co mode > layer network > > connections can be p2p or p2mp in nature and each can be > composed of > > multiple concatenated subnetwork-connections (ie nodes in THIS layer > > network) and link-connections......noting that a single p2p > > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > > network is NOT a connection in THAT (ie Ethernet) layer network=20 > > (though it will be supported by a trail which is provided by a=20 > > connection in some lower layer network). > > =20 > > regards, Neil > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On > > Behalf Of Nurit Sprecher > > Sent: 21 September 2006 12:38 > > To: Don Fedyk; Adrian Farrel > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Nurit > > Sprecher > > Subject: RE: Proposed liaison response to IEEE > > =09 > > =09 > >=20 > > Hi, > >=20 > > =20 > >=20 > > I think it is a good idea to send the liaison to the > IEEE and get > > once and for all a clear statement that the s-vid translation is > > supported on each provider bridge port. > >=20 > > =20 > >=20 > > In addition, the IEEE has recognized that MAC learning is not > > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > > already includes this extension in section 8.7. > >=20 > > =20 > >=20 > > " The Learning Process receives the source MAC > Addresses and VIDs of > > received frames from the > >=20 > > Forwarding Process, following the application of the > ingress rules > > (8.6.2). It shall create or update a > >=20 > > Dynamic Filtering Entry (8.8.3) that specifies the > reception Port for > > the frame's source address and VID, if > >=20 > > and only if the source address is an Individual > Address, i.e., is not > > a Group Address, the resulting number of > >=20 > > entries would not exceed the capacity of the Filtering > Database, and > > the filtering utility criteria for the > >=20 > > receiving Bridge Port are met." > >=20 > > The enhanced filtering utility criteria "are satisfied > if at least > > one VLAN that uses the FID includes the reception Port and at least > > one other Port with a Port State of Learning or Forwarding in its=20 > > member set, and: a) The operPointToPointMAC parameter is=20 > false for the > > reception Port; or b) Ingress to the VLAN is permitted > through a third > > Port. NOTE -The third port can, but is not required to be in the > > member set.". > >=20 > > =20 > >=20 > > I think it is clearly stated, but if it is required to > ask the IEEE > > about the context of forwarding based on a destination MAC, > I suggest > > being more precise and specify that we are talking on > point-to-point > > connections. > >=20 > > =20 > >=20 > > Regards, > >=20 > > Nurit. > >=20 > > =20 > >=20 > > -----Original Message----- > > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On > > Behalf Of Don Fedyk > > Sent: Wednesday, September 20, 2006 23:16 > > To: Adrian Farrel; ccamp@ops.ietf.org > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > > Subject: RE: Proposed liaison response to IEEE > >=20 > > =20 > >=20 > > Hi Adrian > >=20 > > =20 > >=20 > > The Liaison looks good however it does not capture a comment I > > made. =20 > >=20 > > =20 > >=20 > > My understanding of the S-VLAN translation in IEEE > documents and the > >=20 > > liaison is that the translation is valid in the context > of forwarding > >=20 > > based on a destination MAC. My interpretation is that V-LAN is > > optional > >=20 > > MAC is not. If I am correct VLAN translation as > specified is not > > equal > >=20 > > to Label switching. The Liaison is clear about not just > the format of > >=20 > > 'packets on the wire' but the relationship to the > entities such as > > MAC > >=20 > > relay as well. > >=20 > > =20 > >=20 > > I think we should also ask in our liaison for > clarification if the > >=20 > > S-VLAN translation can be valid by itself i.e. as a > label agnostic to > >=20 > > the MAC so there is no confusion. > >=20 > > =20 > >=20 > > Thanks, > >=20 > > Don > >=20 > > =20 > >=20 > > =20 > >=20 > > > -----Original Message----- > >=20 > > > From: owner-ccamp@ops.ietf.org > >=20 > > > All, > >=20 > > > > >=20 > > > The IETF received an unsolicited liaison on the subject of > >=20 > > > 802.1 Ethernet > >=20 > > > > >=20 > > > You can see the liaison at > >=20 > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > >=20 > > > > >=20 > > > The participants on the GELS mailing list have requested that > >=20 > > > we respond to this to clarify an issue. > >=20 > > > > >=20 > > > Here is the draft of a liaison that we proposed to send. > >=20 > > > Please shout at once if you have any concerns with this > >=20 > > > liaison. I intend to ask Bert to send it on Monday of > next week. > >=20 > > > > >=20 > > > Thanks, > >=20 > > > Adrian > >=20 > > > =3D=3D=3D > >=20 > > > Subject: Response to your liaison "Use of IEEE 802.1Q > VLAN tags" > >=20 > > > > >=20 > > > Date: Sep 2006 > >=20 > > > To: IEEE802.1 > >=20 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > >=20 > > > > >=20 > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > >=20 > > > Deborah Brungard, IETF CCAMP Working Group co-chair > >=20 > > > > >=20 > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > >=20 > > > Ross Callon rcallon@juniper.net > >=20 > > > Bill Fenner fenner@research.att.com > >=20 > > > CCAMP mailing list ccamp@ops.ietf.org > >=20 > > > GELS mailing list gels@rtg.ietf.org > >=20 > > > > >=20 > > > Thank you for your very informative and clarifying liaison on > >=20 > > > "Use of IEEE 802.1Q VLAN tags". > >=20 > > > > >=20 > > > We have a question arising from this liaison and our reading > >=20 > > > of the relevant standards documents as follows. > >=20 > > > > >=20 > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > >=20 > > > bit VIDs) is supported at S-tagged service interfaces, as an > >=20 > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > >=20 > > > to IEEE Std 802.1Q." > >=20 > > > > >=20 > > > While this text in itself is clear it leaves open the > >=20 > > > question of whether "S-tagged Service interfaces" is the only > >=20 > > > type of interface where Translation of 802.1Q S-VLAN tags is > >=20 > > > supported. > >=20 > > > > >=20 > > > It is our understanding that IEEE Std 802.1ad does not > >=20 > > > preclude the translation of 802.1Q S-VLAN tags at any > >=20 > > > S-tagged interface. Thus, this translation would be allowed > >=20 > > > at Provider Network Ports, not just at Customer Network Ports. > >=20 > > > > >=20 > > > Can you please confirm whether this is the correct > >=20 > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > >=20 > > > Std 802.1Q? > >=20 > > > > >=20 > > > Many thanks, > >=20 > > > > >=20 > > > Bert Wijnen, IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel and Deborah Brungard, CCAMP Working > Group co-chairs > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > =20 > >=20 > > _______________________________________________ > >=20 > > gels mailing list > >=20 > > gels@rtg.ietf.org > >=20 > > https://rtg.ietf.org/mailman/listinfo/gels > >=20 > > =20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > 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 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 21 12:20:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRHW-0002Ca-Q8 for ccamp-archive@ietf.org; Thu, 21 Sep 2006 12:20:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQRHL-0001Q2-FA for ccamp-archive@ietf.org; Thu, 21 Sep 2006 12:20:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQR86-0003K7-FL for ccamp-data@psg.com; Thu, 21 Sep 2006 16:10:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQR83-0003JD-8A for ccamp@ops.ietf.org; Thu, 21 Sep 2006 16:10:23 +0000 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 1GQR8I-0002QY-00 for ccamp@ops.ietf.org; Thu, 21 Sep 2006 17:10:38 +0100 Received: from your029b8cecfe ([217.158.132.220] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 17:10:16 +0100 Message-ID: <0f2701c6dd98$65564d40$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "ccamp" References: Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Date: Thu, 21 Sep 2006 16:55:29 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="GB2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 21 Sep 2006 16:10:19.0336 (UTC) FILETIME=[6EFB2C80:01C6DD98] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Hi Jiang, Yes, I read your I-D when it was published in November last year. It seems to me that you were addressing a very specific sub-case of the graceful restart problem space. If we generalise to a linear network A-B-C-D-E-F with an LSP running from A to F, your draft handles the case where all four nodes B, C, D and E fail, and C and D subsequently recover, but have retained no LSP state. You are asking the question, how do nodes C and D know to exchange Hello messages. The reasons why I limit your draft to such a narrow subset of the problem are: - If any restarting node is adjacent to a node that remained active, the active node will send a Hello message and that will engage the graceful restart procedures - If the restarting node had retained any LSP state, it would know about its neighbours and would be able to send Hello messages. This seems like a very small corner case, and we do not usually design the protocols to optimise for this type of error condition. So long as there is *a* solution, we are usually happy. That said, if this is a problem that is causing you problems in the field, we should address it. I note that your I-D has expired and I wonder what your plans are for this work. Regards, Adrian ----- Original Message ----- From: To: "Olufemi Komolafe" Cc: "ccamp" ; ; ; Sent: Wednesday, September 20, 2006 3:57 AM Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > Hello, everyone! > > We have put forward a mechanism to solve this problem in our > draft "draft-jian-ccamp-multinodes-rsvp-restart-00" last year. > > We think that if multiple adjacent nodes restarted nearly at > the same time, these nodes cannot learn about the GR capability > from each other. > > The key of this problem is that how restarted node actively > inform its GR(Graceful Restart) capability to neighbor nodes, > especially some neighbor nodes are restarted nodes too. > > If you concern our mechanism, please read our draft for detail. > > > > > Regard, > Jiang Weilian > ............................................... > Add: No.68 Zijinghua Rd,Yuhuatai District, > Nanjing. P.R.China. > Zip: 210012 > Tel: 0086-25-52871644 > Mail: jiang.weilian@zte.com.cn > ............................................. > > > > > > "Olufemi Komolafe" > ·¢¼þÈË£º owner-ccamp@ops.ietf.org > > 2006-09-19 20:45 > > ÊÕ¼þÈË£º , > ³­ËÍ£º "ccamp" > Ö÷Ì⣺ RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > > Hi, > > While reading this draft it occurred to me that perhaps it might be more > useful to approach this topic from the perspective of ¡°What can go wrong > during graceful restart, what are the consequences and how can it be > fixed?¡± rather than focusing on the narrower topic of multiple > simultaneous nodal faults. > > For example, Scenario 1 in the draft may be interpreted as ¡°What should > happen if a (non-ingress) restarting node fails to get a RecoveryPath > message from its downstream neighbour?¡±, Scenario 2 is ¡°What should > happen if a (non-ingress) restarting node fails to get a Path message from > its upstream neighbour?¡± and so on. Whether each of these scenarios > arises due to multiple simultaneous nodal faults (as in the draft) or any > other reason (e.g. a subsequent control channel failure, restarting node > being inundated with messages etc.) is, in my opinion, secondary. I think > the key thing is to identify the potential problems and suggest > appropriate remedial actions, where the authors think existing > documentation is insufficient, rather than focusing on 5 different > permutations of multiple node graceful restart. > > Regards, > Femi > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Zafar Ali (zali) > Sent: 10 July 2006 04:04 > To: danli@huawei.com; gjhhit@huawei.com > Cc: ccamp > Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > Dear Authors, > > This is Deja-vu to me.... > > Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on > multiple node restart case and was rejected by the WG as addressing > multiple node restart case is NOT a goal (suffers from the law of > diminishing return). In other words the following statement in the ID- > > "[GR-EXT] also extends the Hello message to exchange information about > the ability to support the RecoveryPath message. > The examples and procedures in [GR-EXT] focus on the description of a > single node restart when adjacent network nodes are operative. > Although the procedures are equally applicable to multi-node restarts, > no detailed explanation is provided." > > is not accurate. Please see section 4 on the earlier version of the > [GR-EXT], > http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt > . > > Thanks > > Regards... Zafar > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to > others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the originator of > the message. Any views expressed in this message are those of the > individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to > others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the originator of > the message. Any views expressed in this message are those of the > individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > From owner-ccamp@ops.ietf.org Thu Sep 21 13:00:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRug-0006Hu-9j for ccamp-archive@ietf.org; Thu, 21 Sep 2006 13:00:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQRuc-0006jc-6i for ccamp-archive@ietf.org; Thu, 21 Sep 2006 13:00:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQRk8-0008n9-8Q for ccamp-data@psg.com; Thu, 21 Sep 2006 16:49:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQRk6-0008mW-9O for ccamp@ops.ietf.org; Thu, 21 Sep 2006 16:49:42 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GQRk1-0002v6-00 for ccamp@ops.ietf.org; Thu, 21 Sep 2006 17:49:37 +0100 Received: from your029b8cecfe ([217.158.132.220] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 17:49:34 +0100 Message-ID: <0f3f01c6dd9d$e30e7fa0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "JP Vasseur" Cc: , "Ross Callon" , References: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe> Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Thu, 21 Sep 2006 17:48:53 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 21 Sep 2006 16:49:35.0475 (UTC) FILETIME=[EB597430:01C6DD9D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Hi JP, Thanks for addressing the comments. I have forwarded these to the Routing Directorate and copied them on this email to let them respond if they want. But here are my comments: >> 1) The Tail-end name field facilitates LSP identification. Is this >> a new form of LSP identification? >> If it is not new, then there should be a reference to RFC3209 and a >> statement of which RFC3209 fields are mapped to this IGP field. >> If it is not new then there is a significant concern that a new >> identification is being introduced when it is not needed. > > As indicated in the document the string refers to a "Tail-end" name, > not an TE LSP name: thus it does not replace the session name of the > SESSION-ATTRIBUTE object defined in RFC3209. Hmmm, yes it is not an LSP name, but recall that the LSP is identified by a combination of Session and Sender Template, and that the Session includes the destination IP address. In Section 3.2 I see: - A Tail-end name: string used to ease the TE-LSP naming. and in Section 4.1: - A Tail-end name: a variable length field used to facilitate the TE LSP identification. These definitions seem to imply that the tail-end name is used as an identifier for the LSP. The question that will be asked is: How does this identification of an LSP differ from the conventional identification of the LSP? Given that you also have: - A Tail-end address: an IPv4 or IPv6 IP address to be used as a tail-end TE LSP address by other LSRs belonging to the same mesh- group it appears that the tail-name is superfluous information. So, perhaps the name is present for diagnostic purposes? Perhaps it is there to ease OAM? But it does not seem to play any role in the protocol procedures as it is not explicitly mentioned later in the I-D (e.g. Section 5). How would a node behave if it received a mesh group advertisement that indicated a tail-end address that did not appear to match its record of the tail-end name? >> 2) The document mentions that the number of mesh groups is limited >> but potentially (depending on encoding) provides for binary >> encoding for 2^32-1 groups (although this might be constrained by >> OSPF's limit of a TLV size to 2^16 bytes. >> The document (and the authors) state that scaling of these >> extensions is not an issue because only a small number of mesh >> groups are likely to be in existence in a network, and any one >> router is unlikely to participate in more than a very few. >> There are two concerns: >> a) Whenever we say that something in the Internet is limited, >> history usually proves us wrong. > > And that's undoubtedly a good news :-) > >> Indeed, there is already a >> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >> similar mechanism for a problem that would have far more groups. > > Two comments: >- Mesh groups are used to set up TE LSP meshes. If we consider let > say 10 meshes comprising 100 routers each, that gives us 99,000 TE > LSPs. One can easily see that the number of meshes is unlikely to > explode in a foreseeable future. If it turns out to be the case, > we'll have other scalability issues to fix before any potential with > the IGP. What about 100 meshes comprising 10 routers each? I make that only 9,000 TE LSPs. So clearly the scaling of MPLS-TE is not directly related to the scaling of automesh. What this comes down to is your statement about how automesh will be used. I think we can all accept that this is the problem space that you intend to deploy in, and that is great. But the original point from the Routing Directorate was that there is nothing in the I-D that imposes this restriction. So how can we say that the protocol extensions will scale? > - More importantly, the dynamics of joining a TE mesh is such that > IGP updates are used to advertise to TE mesh group membership change > (join or prune), which are indeed expected to be very unfrequent. Again, the concern raised is that the problem space you intend to deploy in is, indeed, limited in this way. All good. But how can we say whether the protocol extensions will be used differently in the future? What controls are there over constructing a mesh where joins and prunes are frequent? >> b) The I-D does not itself impose any reasonable limits on the >> number of groups with the potential for a single router (by >> misconfiguration, design, or malice) advertising a very large >> number of groups. >> Thus, it appears that the scaling concerns are not properly >> addressed in this I-D. > >Not sure to see the point here. If indeed, a large number of TE MESH >GROUPs were advertised, this would not impact the other LSRs since >they would not create any new TE LSPs trying to join the new TE-MESH- >GROUP. In term of amount of flooded information, this should not be a >concern either (handled by routing). We clarified this in the >security section. The impact on the other LSRs is exactly flooding question. Covering that in the security section is fine for the misconfiguration and malice cases. >> 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL >> and must at most appear once in a OSPF Router Information LSA or >> ISIS Router Capability TLV." but for addition/removal it mentions >> "conversely, if the LSR leaves a mesh-group the corresponding entry >> will be removed from the TE-MESH-GROUP TLV." >> What are these "entries" referring to - that there is a top-level >> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions >> "No sub-TLV is currently defined for the TE-mesh-group TLV") ? >> >> AF>> My comment on this is that the definition of the TLVs seems >> AF>> unclear. >> AF>> From figure 2, it appears that some additional information can be >> AF>> present in the TLV after the fields listed, and (reading >> AF>> between the lines) it would appear that this additional >> AF>> information is a series of repeats of the set of fields to >> AF>> define multiple mesh groups. >> AF>> This could usefully be clarified considerably. > > > You're absolutely right. The figures have been modified: > > (example show below): [SNIP] Looks good to me. >> AF>> But it is now unclear to me whether a single router can be a >> AF>> member of IPv4 an IPv6 mesh groups. It would seem that >> AF>> these cannot be mixed within a single TLV, and multiple >> AF>> TLVs (one IPv4 and one IPv6) are prohibited. > > OK the text requires some clarification. What is prohibited is to > have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is > permitted. New proposed text to clarify: > > The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and > one IPv6 instance MUST appear in a OSPF Router Information LSA or > ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or > IPv6) occurs more than once within the OSPF Router Information LSA, > only the first instance is processed, subsequent TLV(s) will be > silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 > or IPv6) occurs more than once within the ISIS Router capability TLV, > only the first instance is processed, subsequent TLV(s) will be > silently ignored. OK. That's fine. I think you want to make a couple of changes: - "at most one instance MUST appear" is ambiguous since it will be confused with "an instance MUST appear". I suggest you reword as "MUST NOT include more than one of each of" - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs more than once" should really be phrased as "If the either the IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more than once". Ditto for the IS-IS sub-TLV. - Two instances of "will be silently ignored" should read "SHOULD be silently ignored" >> 4) Small terminology issue in section 5.1 it says: "Note that both >> operations can be performed in the context of a single refresh." >> This is not a refresh. It is a trigger/update. A better term for >> OSPF would be "LSA origination". > >OK fixed (I used the term "Update"), thanks. OK >> 5) Please state the applicability to OSPF v2 and or v3. Note that >> the Router_Cap document covers both v2 and v3 > >Indeed, Thanks for the comments. The OSPFv3 aspects have been >incorporated. Here is the new text: [SNIP] OK >> 6) The term "fairly static" at the end of section 5.1 is >> meaningless without some relative context. >> Presumably this relates to the number times an LSR joins or leaves >> a mesh group over time. >> Is it intended to be relative to the IGP refresh period? >> Please clarify in an objective rather than a subjective way. > > > Right, this requires clarification. Here is the new text: Moreover, > TE mesh-group membership should not change frequently: each time an > LSR joins or leaves a new TE mesh-group. I could live with this, personally. We'll see whether we get any more comments. I think the nub will be: 1. whether your "should not" can be "SHOULD NOT" 2. what does "frequently mean"? 3. what is there in this I-D to say that an LSR does not join/leave a TE mesh-group very often? > I guess that this is sufficiently explicit: it is a well-known fact > that LSRs are infrequently added or removed to a TE mesh. :-) Very well known. In fact, my mother was commenting on it to me only the other day ;-) Consider the case where PE membership of an automesh is dependent on whether there are C-nodes subscribed to some service. Perhaps this well known fact could be noted in the Introduction to this I-D which is AFAIK the only IETF document on the subject of automesh. >> 7) The security section (section 8) is inadequate and will >> undoubtedly be rejected by the security ADs. At the very least, the >> I-D needs a paragraph (i.e. more than one or two lines) explaining >> why there are no new security considerations. But what would be the >> impact of adding false mesh groups to a TLV? Is there anything >> (dangerous) that can be learned about the network by inspecting >> mesh group TLVs? > > The following section has been added: [SNIP] OK. Let's run with that and see how much we get beaten up by the Security experts. Cheers, Adrian From xmbktym@t-dialin.net Fri Sep 22 02:14:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQeIz-0008Rb-OE for ccamp-archive@ietf.org; Fri, 22 Sep 2006 02:14:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQeIz-0003oY-KQ for ccamp-archive@ietf.org; Fri, 22 Sep 2006 02:14:33 -0400 Received: from p5480c7ac.dip.t-dialin.net ([84.128.199.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GQeIg-0007ia-Kf for ccamp-archive@ietf.org; Fri, 22 Sep 2006 02:14:33 -0400 Message-ID: <000c01c6de0e$5e62cec0$acc78054@JohnHome> From: "Try" To: ccamp-archive@ietf.org Subject: Get the latest messages Date: Fri, 22 Sep 2006 08:14:32 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C6DE1F.21EB9EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 ------=_NextPart_000_0008_01C6DE1F.21EB9EC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6DE1F.21EB9EC0" ------=_NextPart_001_0009_01C6DE1F.21EB9EC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable About Searched all groups Your search did not match any Make sure words are spelled Try different keywords. general fewer = your on can try Answers for expert help with search. Get the latest = messages emailed to Alerts. Terms of Service Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can try Answers for expert help with search. Get = the latest messages emailed to Alerts. Terms of Web Images VideoNew News Maps more raquo Advanced Search Members: users: = Join Alerts Create new group About Searched all groups Your search did = not match any Make sure words are spelled Try different keywords. = general fewer your on can raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of Service Privacy Policy raquo Advanced Search Members: users: Join Alerts Create new group About = Searched all groups Your search did not match any Make sure words are = spelled Try different keywords. general fewer your on can try Answers = for expert help with search. Get the latest messages emailed to Alerts. = Terms of ------=_NextPart_001_0009_01C6DE1F.21EB9EC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
About Searched all groups Your search did not = match
any Make sure words are spelled Try different keywords. general = fewer your on can try Answers for expert help with search. Get the = latest messages emailed to Alerts. Terms of Service
Images VideoNew News Maps more raquo Advanced Search Members: = users: Join Alerts Create new group About Searched all groups Your = search did not match any Make sure words are spelled Try different = keywords. general fewer your on can try Answers for expert help with = search. Get the latest messages emailed to Alerts. Terms of
Web Images VideoNew News Maps more raquo Advanced Search = Members: users: Join Alerts Create new group About Searched all groups = Your search did not match any Make sure words are spelled Try different = keywords. general fewer your on can
raquo Advanced Search Members: users: Join Alerts Create new = group About Searched all groups Your search did not match any Make sure = words are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest messages emailed to = Alerts. Terms of Service Privacy Policy
raquo Advanced Search Members: users: Join Alerts Create new = group About Searched all groups Your search did not match any Make sure = words are spelled Try different keywords. general fewer your on can try = Answers for expert help with search. Get the latest messages emailed to = Alerts. Terms of
------=_NextPart_001_0009_01C6DE1F.21EB9EC0-- ------=_NextPart_000_0008_01C6DE1F.21EB9EC0 Content-Type: image/gif; name="help.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c6de0e$5e62cec0$acc78054@JohnHome> R0lGODlhsAFsAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAARAAAALAAAAACwAWwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWD3yycq1q9evYMOKHUu2rNmz aNOqXUttrdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnkwZJ4nK mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fNU0AHz5ZBvHj yJMrX868ufPn0KNL/z1vuvXr2LNr3869u/fv4MP+ix9Pvrz580c9of+ufr339u65w4+vfT79 +/jz93ZxM5n+/wAGKOCABBZo4IEI1pRFggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4YderXPS NiCWaOKJKJp4QIpx+cLiizBiJkCMp81IY2k23jhajjqGxmOPn/0IZGdCDrlZkUZmhmSSlS3J 5JNQRinllFSed06VWGap5ZZcdunll2CGKeaYZJZp5ploalZOmmy26eabcMYp55x01mnnnXiC 90uefPbp55+ABirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aWYljRLhbhk6umnoIYq6qik lkphIaam+qY1qrbq6nL/h7wqK5tQzApmDrYShSt6j3iXw665BivssMQWa+yxyCar7LJljcDs Tc72pMaw0T5LU7XWyoRttjBte2w03IYr7rjklmvukBmcq+667LY76iLuxptsOvLWa++9+Oar 77789usvn7n8K/DABBds8MEIJzwhPwpTNgCWDmzWjKUTNGzxxRhnrPHGa/3BMUIef3xQyCIX RHLJA52M8j8qo/xHFCunHLPMM9ds0RA452zzEDabaknPQAct9NAEhkL00UgnHbQVSjft9NNQ IzxxzVPHXPXKV6Ocdclbc0311zN3jVACUZdt9tlop6322myf+E7bq6kC99x0C/gDbf7Urffe cHz37fffgFsKCiiBF2744YgnrvjibIPB+OOQZ7dH5JRXbvnlmGeu+eacd+7556CHHt0Yopdu +ulCi4L66qy33jnhrscu++xD25fTKrTnrvvuogITMzC+rxw8ysD//vvwJSPP+/LMN+/889BH Lz15AQEAIfkEABnWAAAsAAAAALABbAEHCP4A/wkcSLCgwYMIEw5Mo7Chw4cQDU6JKJAQxYsY M2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AEQYIcHDoUIFG kxI9qjApQaUJoT41WtDpP6ZVp1KtqvQo1oFeuxq0ipToVK1Mv5blKlbt1aVdzYIVy1YuWrRb 3QbdS1Pv27F2/Z6dS5jr4K+I5W59urYw4MFnEzv+S7mwZLd+JRsW3Liz5sqU9WKNxLe0zMx2 O4MWqjhwatBpXUMmi1Q1asiEP2tWGzvy69uT13KG3Xq27NWqP9YwzRwicNzDKw9/7hgr3MDI ox73ffg33M2vk/5nJ/54+nHM38EXDd+8/UnqttlDpx28vnXFZfFHnxyX6n376eXGXn/UEXid VNUVpx54Uu3n3oMdwUdeQ7zRJ51/3lU3l1kBWhhfeQgiF9aCb41o2Hq4CSdffouJGKCAKEIo Y0kSfqbdjSmaaBxYWl21WoEZ9gbgjy/+hR5rKRq5YmjbwUhikjNGyVGNTSL54YmN2WhdXVc+ NuR//HGYmpAqemmmi+MlOF+Y4knpZkhUQoklmFgyuWZtbHVZ55G6bUfnZRnGKJ6OVnrm53nh OfjmooA12CJxIbK4IWeR0mdVoq49eid386GnqaNnbiogXcElJlqLpzI60i6qturqq/+wxior TGvMauutuOaq66689urrr8AGK+ywxBZr7LHIJqvsssw26+yz0Ebb0gADJEQttf9gO1C1116b bbfcgrtttdsSpK1A4Iarbbrokouuue5+a6247XYrb7vf2jsuvAbRC6++564LsLfnZpuvtwe7 6++/CAesLsHx1otwwuQ6jK+0GxXcb8UB73uxx/dOrPDEH4ccL7Yij2sxQitrbLHGEoNccsQv j3zvuyYrfPPMO9N8crggrywzyj+bLDPGF8HMb77lfuyyzUzjfHBBBQvMb8oxl0w11E/vq7S+ O/e8tdc2V31xyl2Xa/bS+Aot9MxAk91zxEhHpLTHcUMddsv+IZ9dNN5F5+231mxbPbbhSyNO eOFxy/t1xX2nzfZBVTfuts9XB05y2HVDdPfZbQctLrs4ozz40BxfHbrRnKssMr1ES2y44rJv PDDgr5fOLcW19z557E7rDffcUU/eued0J776zV2vbTrrwxOfeurQb0z84dQnnj3lmLct/OnT t3703pqLfnTl0m/++fEsJ4+3yuZr3zTT6b6t+PP01y8+9I9/X3/jUiOf3JbHupEB0GBeMx76 Lne+8sltfTwZBKPWty74BW9soKvX9a63QPgt0H3M254FBTjA+ZHQcWWTHwLzRzXVNTBz8Tsh CmEYQvZRhHSuW2ENZQdA/M0whgP+AxgNvQe24eHwdfb6YBBhdkSwwY5gmVuiAfuHRPTx8IpY bBkIbcjFLnrxi2AMoxjHSMYymvGMaEyjGtcoEzOw8Y1wjKMc5yijjkUvi7d7IcN4R8Enmmtr EHNiIDfHQbo9MYmHHCTwotiw0S2MYVP8Hh2nxbHsFXGH77Li+DT5OSWacINaRF0of3dCBv7r lDXDIOcCp8JJvkRgllSf8HrYvd9JEnXFqyUm7zdFwKnSYJIzZQ6nlkrGNYSJInTlSipIPV5u 8m/PNGb7VFdBW8bPioi75CprKcxMIrKGwdziNhenzJQgcpQXBOQjkSlN7rnQhwnjnS/n6TAq VhJiQBz/nQZRKMWHQZCd5CznSc7JNWgCVGsHxaT1Eui4Xy7ydOCD5rzIV8S3rbBsGMXeMQ0p UYGqhKA87CYtf3nHTrJyn7gsJCMFSbkhXowZqnSZO4s5T3eS1KMwEanezKZJwnEShB1EaUkL WlOFmvCh4rNo8haJVIv6lKM4pWQMFerHBoI0eNokXUd7SrSu5m6qkLzi3eoJRetp1ZEKZJf+ 9hfVtrr1rXCNq1znSte62vWueM2rXvfK17769a+ADaxgB0vYwhr2sIhNrGIXy9jGOvaxkI2s ZCdL2cpaFqeKuKxmN8vZznr2s6ANrWhHm0ZIkPa0GTEtalf7ENWy9rUJcS1s/mc7ENnSlra2 vW1L9gHY3Op2tb79LWqDK9ziGve4yE2ucpfL3OY6t1UAiEh0dzXdLwLgutW9SXYLgt1/XJcg 0cWueL3bkPEKxLzeze53xTvd7YaXve8dL3rT+13urle9A5lvfsHb3f2etyPohW919eve+7KX vAg5MIL/y+AubjcnDwbvefHr3wYf5MEUru+EF0xe90q4whVu74c/rGEER3jEFF7wiSGSYgtz mLsG8TCIYbzfAY/YhhE2r3zrG9/88pi+DRYxjRP8XxuDeMUYjnGHi8zh8A65yUpm8IqlrOIX R9nK8XVyf+krYhnfuMX+TfKXE4JfId/4eGJmcpDT/jvj99Y4zFe+sJqhPOMzY3nJSy7zk8Fc ZSvT2MlzJrKLTezjN9c4zUe2M6GfTGc5vznHDo4zoKsM5kkTesqYpnKj/TzoJANayxL2cpMP PF/9arrL5a2zmfVsaEZvOtOM5nOiS6xopCF60jbOcHczzOlBk7jVm3a1pzfcYR3v2c5mFvaa Le3oO/e5yKRudqLrjOxjJ9jYkObirZ9taVzTmdmu/nWgZd1pJbcX1bEe85CzLe48p7rcz8az ordNbVVbW9qarrWtj21kecu729PW96KJbWFYq3vYVxZ1mpMtZvUmW9IonnWoBe1iUee7zdV2 9ounjDEd97ffWR7wriOu/2oCr5e/XzY1l32sYYTHmNajli+Jt8zyUbOc3StHua5/fG2YY/jj E951iR0OdI3Hm44cV0jS17j0YDUdjU8PN9KZFfXnWv3qWM/6RvShD617fbZLr/rX5ajyd5s9 zkAWcK/Hzj5yk/khSEa729mO5oSvHOhbNrbRKy5wutdt4X22gZvHPXB7q9vv1s37wHM9cWAr +/CIDyO6QS74xgf68QFXVR8iX5PJhxjKrMb3xvvOeWilGOQ1tgGwP4320de79B2nOeqhnfei /1zoLVYw7L0YddXvXq9i13oEfk/84hv/+MhPPlyD/3aSMF+6Mnr+T5yAcpVIfyB/eNP1Lwzf tf7DfeTOb33Ng37ihz+d6CLve9QLTHOzP7/sTae+rz0ye6W33/qvJ3PZmx/+/DvE4h9Re+V3 b+02f/bVb3j2cOYGfZCndPRHeg0hfxEmCxzRcv63fRshfXMnfgEYajzHZAB4bi3HY4q3gLLG cYA3cff3eYamgDCWayPYfjsnclmWZzFIa+X3Yz0WdAThBDumgy83gCKoZT7HfToYg+R3c6A3 ckZmajJWdMEGEg63emymbKH3bXKGaDeHc2vmgfWGgKyXdLjGeBhHhV42eP4GgC9Yhf7WgwzH hqK3aoXGd/xGhgXnevnmbZWWbmBYErkHenEIiJnHfeK3h3ZneZzWh/9VeG7N9oaGSHhnKIh0 CGQqiIh/Zolyx4LBtm1XeIVYSGVveGZPiIci8YeeWG66Rn4w93LhdnoDyHfkpoiNl4KdeIAf aGKoV4uimIQAB4dw5nhKyF96t4kQl4pcdnIHB2dDiIN/hndSB2Bjdop3ZooX0YvWZnAeFouD KGS3d4vWCG93SGmIaHF6+GpRJo0IuG7bWIzRmIm/eGkGOHpNSIohQY0b9opUmI+Q9o2OeHbz +IXrWHjyaHnMSIByGHpF2GqgNoiFB25HR3JRqHDm6Inpx20BmYeGNxJ/mHa9JnM5J4DpOH7H GGQfp3spR4OrqGAEVn27uHP0mISUeI/fhoz/tjiEaRiTKAaFtsh/bHaCJemNMRlgP6li3haM wjh0Jeh/t4KBPMmBwMKUAqWG1JUScTcs+wd8z6h8WrmVl7CVXvmVzgWVLCGWYFka3deU/3eW Dwh3W0iWZQlhDIgRZBl2t/iWroKCHieH+OaMI/mROvlo3tcThWCXFGGS4aiQFPeC/fiOfjaG K0iYiyKRv1aVC3iHvJaWiQmZjNJjM3h5ogh+SziM5cWFmql9/KaMPGmH6Mhie1eaEPKINBmS h1eUPVmA+3iTriklKgd+AeaARxlzuIiU8weSuWmV/VeBxZksUHmVcZmczvmcSLMC0DmdEXEB 1HmdO+GWVImd7SGU/6sIgUf5mHLJmnsmnsTiDr+li5nZnB2YljTIkMWCnsj1jarIgw9ZcUDY l3npggs5nMoin/NJjBgnm4m4iON4mJiIj9zZeUDZgOgmenOmi3Qpd9+5oDMBcKAZnA9KobHp gaJpf1KnnRaqEfSJkJ4ZcLTZhvF4oBA6omPJoiFGmwYnjiT5ib7Wn/Emoi76fTdohBqaf+zX bchYai4YlPu5o5t5nBm4RqfwdctpnuyJpFI6pTPhB1SqWQJwpVq6pVzapV76pWAapnalDsiS DmL6datwpgTRDF0aCmr6pnAap3I6p3Rap7uSA3aap3q6p3yKln36p4AaqII6qISKnWBQqP+I mqiKuqiM2qiO+qiDxQ/8AKmvIqkZYakPgamUyheSqqkR4amb6iadOqkCYamdShCn+g+mSqqY mqqtqqmgGqoz8aqlSquqWquqOqm02qq52qu36quyWhO2CqukOhCr6qvHaqy6WqzBqhPDWqyv eqrRCq3PyqzNKqyjKq3UiqzLWqugmqy4eq024angmqzlCq24aqrhGqviyhLk2q3rOqrA+q6s Wq/b2q4ywq74Oiv6uq/++q+7Vw4AqyvlILAD63QZoaNSGKpSmZX8p5ZGSKBrSakNC57CuKLT JqIKK6bZaKQ/uaEg2JitJ3M2WWwomY1AKbFzirJm6IWV2ZetSZT/lmmHG0ezKaqnHduywDiH TplzFqmzk4ibDmmnOQuJ0aZ/LXqOmniTjyi0gRmnRcu0PQtuTaeXkoibEoealRUObceYY3i1 lXiZydiFkMizlsmzG+uiSRmcP9qRPXqjsiekDZqhMAuaaVuod1uYS3qwvsmgFfp/fBu4ghu4 DjC4B5u36wkTQ/ulzKm35fm3wgm448li4rm4XbqBlPueCGpfLNm3jiu5/om4b+lyJUu1WCu2 Ldi2+smXHwuT88aXZ0q6S5iFh3hxaoajGOqy7da0Zyu6ZdlwDem2tduR8FiLq5mjQdiPvguW wLuMlluQURhmG4qhRwuTJ5tp3We5W9q8/+BIu0tblflZtuqIkazpclj3As2xkWALmN/bveJb m4hJvkGbu8tbWeibvjL4m257sq6rharLmzoplK6rvx/5tMl1v75Sv12KwLyiwAtsuBD8W7wQ wRRMpf4LtVBKoj66sBwMkA4bphuroBM7wgX6wYzLjguJbSSYkDvYhALol/n5l66nd4YJp5zI iLNru9KLmBQ5a+aXiXqGuSd8mmTrtI7Ga4vZviqrijTpbko5xO1Ikh6pwxc3eSpZf2k4o1Ir xF7KiUsbjq+IxAZotSpKmWXLxV28bjLKomEMkRvZh8DLh5VIcHSal/+mv654gI2GfvZJbMO4 tnRIw03cKhZRwf+GfMiInMiK3CymsMiO/MiqkguQPMmUXMmWfMmYnMmavMmc3Mme/MmgHMqi PMqkXMqPXMimnMqqvMqs3Mqu/MqwHMuCewWyXMsNAQ64nMsCgcu7DA4FwcsD4cv/kMu6PMzC PMzBfMy9HMzJbMzEjBDAvMwEEc0GEc28TM3CTMzAbM3NPM3abMzeHM7J/MziPM6+rM3nrMy/ XMzfDM3qbM7APAnWnM7TDM7MjM7OXMzS/EbzbM/U7Mz3rMzXnM3brM4FTdD2nBDknND7XM0I DdC7zNAD3csPvc7dvM8L3dAXvdH9rNAVjcwO/c8YXdEDfczpbNIMndAdzc8mTc8prc//Lr3M B63RMw3OIr3OK63R4TzPKI3NLs3O76zSAt3S/3zTIu3TG+3QDR3UGX3RBd3MMA3RyFzULZ3U atTRTT3V2SzRPw3SVB3RCH3T3fzU5RzSAu3PXI3WH+3UQy3NSK3UFs3WCkHWHq3TWF3VXZ3X Bl3VOp1G+EzR7xzWaZ3PhG3Whf3X4kzXfU3RvyzTg/3MWT3Sf63YRh3Ybb3Ykl3Zdt3OQu3V 5+zZWg3ZnJ3SV83XpA3aMe3PuhzZoq3YcO3aYl3YEW3Tj73a+hzXtb3UTG3Z5Rzbp33Ua23T l03btC3YX/3VcLTSRj3OtV3Su+3cmI3OE13WFs3NjP3WrR3U/50N1dJt1aT91qc91tQt3Xs9 0lDN3ET90sEdR8rN1Og93DmN2/Fd1tPt3W691dcN36YN12kN3pqN29vtzrNN08Nt3p2d3ghe 3gbO0hm93GM92vMt14CN3DL9zYht3pd94RG+4MLd289t2+3d1OQ82roN4Ae9zTu90xae4dpt yy7+4jAe4zI+483l28k94iue1ZN91t4s2ip+4h9O0Die3c7N06kt5MBN5LxtzhJt4hNO0km9 40T+5FRe5UyOz0Bu1kBO1Le92D6t5JjdHNj827v948zM39j90QoO1ni95gte01pdz2i+3w0u 5GfO3Gyu4oyt3txt4m1913Ot300+5/96HuUfLt9LHiVj/t9+LtVlXuKqLeccfeBuntuOPuiI ztG3Ded73dN/bud8XuGN3uf3HejUjekeXugEfhAivt9hzhzAzeqP7tgoTugPHuaxLurjzeJ5 Hue3bNqA7tZoXc8ojtTFvuq6rumq7tqjfuq2nuyhntiCDuAyMtOIzejEfc2yDs9ADc+y3u0V DuZpPtvaDuceXucGLthyXu4sDt04DdRTbuycfeGQ/u7andP1He23ztY47ib9jO3Kru6Zvu/U Xt3tTOGQXuvs7t3/ruBY7djr/tlp7u6pjvDyPtgCbt8MT+dHXumRLuHO7h4Nv+38TdxSner7 XuAgDe3Iruz/ww7QER7s+dzvK9/lCS7tFC/XFv/pHF7yR+3s+N7x1E7eIN8qI1/yAY/nA1/q K//Sqm7oS1/rMO/qb67mD53ekm7bKE/mpO7yyc7s2Afed871JS72+t7eSG8QnGAaWD7v937w QM/xh83aNN/jIH73Rt70W07y/f3p2h7lOL/pVD/zSJ7vhF/2JL7Qld3lmq74JH74/s3lYE/j lF/5ln/5mN+lNk4RbiS4ZL3jhl7ndR/n9G7dGN/kpX/wjy/ljO/lqn/f8C749H34VE7v3L7U 9i70Q7744M7mo/8sT33xLU/ZJx3QG7/neb/nNd/iQZ/pNk73pJ7vru74nk7wPd/3/yj97B8/ 5vRd/L0e8ssS/Dzf8h3O3dkf98jP5Uo/+BxO4YZv2IQu/lnf6Vjv6yw/3/J+/lu//Twe8Nyc 6wDxT+BAggUNHkSYUOFChg0dJgQXEZzAiAQrVqQ40aLGjP8wdpyIkePAjxspeuzoUaNIlSdT HvxYsmRLkCMNirRJk6bElTlf7ly5U2fLmTFzygwp9CZHpClnFmwaMujTpw+tXsWaVStUiT8v MrUZdeRFkEsR8lRp1GnZn1xJjg3Lsydat0Mz0k0Ltutbk0rJikUr12dUtnXz0jW6ty/bv3Lb boUcWTJktXwr87UMFyVRszC74sXpkuxjzEOLgrVblypq0v46m/pNKtZtVdNJOXeuTfq0yZ4o V08GHlz4wstEWZc2zvvtUZ95nR/+vBy54delv0IUHNc608WJHevNvTt1eOm4X7OcTvju+OHt 3Qsvfr1tZfVpcZs/ftt+a9eau0vFbrGXLvOvP+XWo0+7x+pT7L++0JtPM/B+e69CC69CCjS8 lmtQMJcWbM5Ar2wbcKRcBPSQK7RsSRG50zbMsLr6jNMwsAI5hHC8+KTCqUEcg8oMsRAvJLJI I49E8iFbkmSySSefhDJKKacEbkkqr8QySy235LLLf6yk8hAxvSSzTDPPRLMhMLEUc8w034Qz TjmRXJPLQ+bEM08991SSTz//BP40UCrrFLRQQ7eMyUW4hNyrurt49PFFAGvaUEAUb8SIxcym g84rFb+qEVIKnWKu0e8c69TD31JUFdWlFHOVtkOB67FE8UzLzTAdmSOVv0c9+08tFkMLTVdQ STL2uGJrS9BYuwjMbz8EUbuVqgN7nfW9WvurdqxcLwVWtUnZ4zBcW1kzNbn7jv1wxO3c/RVb F59VNlpGx5XvXYUolDXbyFjqDSgHk113MF6f83VZRbEFmNLmCMvx22YxW7bS1LrVF9lTDcR4 34P79Zeyz2ANuMRXXV34PlLjsljhR4U89zkfwe2NZVA7LFlgbg021caMVV2Pxp5HtlhXk0Nu z8aJj/4Gl2CVgXK0s1F19k7mmd2tmWDxzssZZHV/HBjZD/PNtybiDvYVaa2UnivW/Ma9+EZO iY12oxaxzu5XmKti8Fad5RVaQ5h4UxA/qIBVa+sQp1a7QmjDlunblI2mOmenF5axXhCvjbTA pRUuTmyzLc243U1HL31utBunVfPSUY1a8JNv5hhlycPz3PW4EbPUUdpbzPyse8sONjqzWN04 vVZhH5J155+HPnrpp6e+euuvxz577bfnvnvvvwc/fPHHJ798889HP33112e/ffffhz9++een v37778c/f/33579///8HYAAFOEBD5YGAB0RgAhW4QAY20IEPhGAEJTjB7AIFBAAh+QQAFgAA ACwAAAAAsAFsAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatz4UADHjyBDihxJ sqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1K tarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6r15aq/eJn4DCx5M uLDhw4gTK17MuLHjx5AjS55MubLly5gza97MubPnz6AvNwtNOuO10qhTq17NurXr17Bj5+Qn u7bt27hz697Nu7fv3wnRAB+eVDjx40SNI1/+Uznz5zqdS+YCvaz06thlXs/OvSWa7d3D/qME L768+fPo06tfP7QU+/fwdz6aT/9R/PsT7ePOhL9/Q/7+BZgQgAIWOBCBBhqIYIIBLsigfw4+ eF+EEsZHYYXsXYjhhhx26OGHIIYo4ogklmjiiaGJgOKKLLbo4oswxijjjNBtQ+ONOOao4448 zkVeZK/0KOSQRBZp5JE7HoPkkkw26eSTUEYp5ZRUVmnllVhmqeWWXHa54jleegZmmJ2NSeZm Zp6JkhJupanmm3DGKeecdNb5Uw125qnnnnz26ad6cPwp6KCEFmrooYgmquiijDbqaFBRPCrp kfhMaumlmGbq4RGadurpp6CGKuqoTN1B6qmopqrqqqy26tkH/67GKuustNZaqxsIpWLrrrz2 6uuvwAYr7LCY4ULsscgmq+yyzMoJWLPQRoufHtJWa+21PxmDLVHabitUt94CBW645JZr7rno pqvuuld+we678MYr77z0LmtNvfjmq+++/Pbr778AByzwwAQXbHBryhys8MIMc6RKwxs9DLFG Ek98UcVWPeMXIhVibPHHIIcs8sgkl3yWqVGtYnJLGnAUyMowxyzzzDTXbPPNOOes886FBWFz EEAHHTTPRBcNJworlmC0wsQs7fTTUEct9dRUV2311VhnrfXWXHft9ddghy322GSXbfbZaKet NrPDLN220W8XHTfRc/NcN5lPYHa3zoLD7L3234AHLvjghBdu+OGIJ6744oyfbUPjkEcu+eSU V2755Zhn7iIkLTmg+eeghy766KSXLqVHpqeuOmctrO46b3m/LjtvnNTOydK21w5akFzePvvv wAcv/PDEF4+fisZP9GzyzDfv/PPQR6+1DP3pIv312Gev/fbcd+/99+CHv3ZAADs= ------=_NextPart_000_0008_01C6DE1F.21EB9EC0-- From owner-ccamp@ops.ietf.org Fri Sep 22 09:38:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlEb-0005oj-ST for ccamp-archive@ietf.org; Fri, 22 Sep 2006 09:38:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlEX-0005Ti-U4 for ccamp-archive@ietf.org; Fri, 22 Sep 2006 09:38:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQkzo-0004G7-2r for ccamp-data@psg.com; Fri, 22 Sep 2006 13:23:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQkzj-0004FL-RP for ccamp@ops.ietf.org; Fri, 22 Sep 2006 13:23:08 +0000 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 22 Sep 2006 06:23:07 -0700 X-IronPort-AV: i="4.09,202,1157353200"; d="scan'208,217"; a="1854876641:sNHT87124500" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8MDN7Yj027888; Fri, 22 Sep 2006 06:23:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8MDMxMP025279; Fri, 22 Sep 2006 06:23:06 -0700 (PDT) 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.1830); Fri, 22 Sep 2006 09:23:02 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 09:23:00 -0400 In-Reply-To: <0f3f01c6dd9d$e30e7fa0$0a23fea9@your029b8cecfe> References: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe> <0f3f01c6dd9d$e30e7fa0$0a23fea9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: multipart/alternative; boundary=Apple-Mail-54-235550940 Message-Id: Cc: , "Ross Callon" , From: JP Vasseur Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Fri, 22 Sep 2006 09:22:57 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Sep 2006 13:23:00.0107 (UTC) FILETIME=[398C25B0:01C6DE4A] DKIM-Signature: a=rsa-sha1; q=dns; l=52628; t=1158931387; x=1159795387; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20Routing=20Directorate=20comments=20on=20draft-ietf-ccamp-automes h-01; X=v=3Dcisco.com=3B=20h=3DuG5NUr9tkIvBpzVKn0luCin5Z/4=3D; b=R0Nuf+Nxd1FrQlOyHNrimk3GgvgHddaO5u1NaqsYVjc9C+I/Deam5Qn4FEnJSTG+xm3mDWuH smO8mu+qjv5zdok+Ptn0doCc1Cn4o6LN2WluXno2gO1VLlCAi/Rsn2qQ; Authentication-Results: sj-dkim-7.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97901e96c4dacf0263335ebc3a004b57 --Apple-Mail-54-235550940 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Adrian, On Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote: > Hi JP, > > Thanks for addressing the comments. I have forwarded these to the > Routing Directorate and copied them on this email to let them > respond if they want. OK > But here are my comments: > in line, >>> 1) The Tail-end name field facilitates LSP identification. Is this >>> a new form of LSP identification? >>> If it is not new, then there should be a reference to RFC3209 and a >>> statement of which RFC3209 fields are mapped to this IGP field. >>> If it is not new then there is a significant concern that a new >>> identification is being introduced when it is not needed. >> >> As indicated in the document the string refers to a "Tail-end" name, >> not an TE LSP name: thus it does not replace the session name of the >> SESSION-ATTRIBUTE object defined in RFC3209. > > Hmmm, yes it is not an LSP name, but recall that the LSP is > identified by a combination of Session and Sender Template, and > that the Session includes the destination IP address. In Section > 3.2 I see: > - A Tail-end name: string used to ease the TE-LSP naming. > and in Section 4.1: > - A Tail-end name: a variable length field used to facilitate the TE > LSP identification. Ah I see your point now. Just bad wording, it should have read " The idea is not to use that field for LSP identification per say but to ease the management, troubleshooting, ... For example, an implementation could form the session name based on the strings on these fields. A Tail-end name: name of the Tail-end LSR. + see below > > These definitions seem to imply that the tail-end name is used as > an identifier for the LSP. The question that will be asked is: How > does this identification of an LSP differ from the conventional > identification of the LSP? Given that you also have: > - A Tail-end address: an IPv4 or IPv6 IP address to be used as a > tail-end TE LSP address by other LSRs belonging to the same mesh- > group > it appears that the tail-name is superfluous information. > Well having the name definitely helps for management, troubleshooting, ... > So, perhaps the name is present for diagnostic purposes? Perhaps it > is there to ease OAM? But it does not seem to play any role in the > protocol procedures as it is not explicitly mentioned later in the > I-D (e.g. Section 5). > OK let me try to clarify adding the following text then: The aim of the Tail-end address field is to provide a way to quickly identify the tail-end LSR originating the TE-MESH-GROUP and could be used for various purposes such such troubleshooting, management and so on. It does not interfere by any mean with the TE LSP attributes used to identify a TE LSP. Does that clarify ? > How would a node behave if it received a mesh group advertisement > that indicated a tail-end address that did not appear to match its > record of the tail-end name? > >>> 2) The document mentions that the number of mesh groups is limited >>> but potentially (depending on encoding) provides for binary >>> encoding for 2^32-1 groups (although this might be constrained by >>> OSPF's limit of a TLV size to 2^16 bytes. >>> The document (and the authors) state that scaling of these >>> extensions is not an issue because only a small number of mesh >>> groups are likely to be in existence in a network, and any one >>> router is unlikely to participate in more than a very few. >>> There are two concerns: >>> a) Whenever we say that something in the Internet is limited, >>> history usually proves us wrong. >> >> And that's undoubtedly a good news :-) >> >>> Indeed, there is already a >>> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >>> similar mechanism for a problem that would have far more groups. >> >> Two comments: >> - Mesh groups are used to set up TE LSP meshes. If we consider let >> say 10 meshes comprising 100 routers each, that gives us 99,000 TE >> LSPs. One can easily see that the number of meshes is unlikely to >> explode in a foreseeable future. If it turns out to be the case, >> we'll have other scalability issues to fix before any potential with >> the IGP. > > What about 100 meshes comprising 10 routers each? Note that would still be very reasonable ;-) > I make that only 9,000 TE LSPs. > > So clearly the scaling of MPLS-TE is not directly related to the > scaling of automesh. > Well you see my point ... since these extensions are used to set up TE LSPs, in the vast majority of the realistic cases you'll end up with scalability concerns with RSVP before seeing any IGP scalability issue. > What this comes down to is your statement about how automesh will > be used. I think we can all accept that this is the problem space > that you intend to deploy in, and that is great. But the original > point from the Routing Directorate was that there is nothing in the > I-D that imposes this restriction. So how can we say that the > protocol extensions will scale? And that is true with pretty much every protocol: one could always come up with a scenario where a bad usage of the protocol or a broken implementation may be a concern. Anyway, let me try to propose some text to close on this: OLD: It is expected that the number of mesh-groups be very limited (to at most 10 or so). Moreover, TE mesh-group membership should not change frequently: each time an LSR joins or leaves a new TE mesh-group. NEW: The aim of the IGP extensions proposed in this document is to ease the provisioning of TE meshes, the number of which is generally very limited (10 at most or so), and should stay of this order of magnitude at least in a foreseeable future. Furthermore, such TE meshes are not expected to change frequently and thus the TE mesh- group membership is likely to be very stable (each time an LSR joins or leaves a new TE mesh-group, which is a not a frequent). An implementation SHOULD support mechanisms to control the frequency at which an LSR joins/leaves a particular a TE mesh group. Does that address your concern ? > >> - More importantly, the dynamics of joining a TE mesh is such that >> IGP updates are used to advertise to TE mesh group membership change >> (join or prune), which are indeed expected to be very unfrequent. > > Again, the concern raised is that the problem space you intend to > deploy in is, indeed, limited in this way. All good. But how can we > say whether the protocol extensions will be used differently in the > future? What controls are there over constructing a mesh where > joins and prunes are frequent? > >>> b) The I-D does not itself impose any reasonable limits on the >>> number of groups with the potential for a single router (by >>> misconfiguration, design, or malice) advertising a very large >>> number of groups. >>> Thus, it appears that the scaling concerns are not properly >>> addressed in this I-D. >> >> Not sure to see the point here. If indeed, a large number of TE MESH >> GROUPs were advertised, this would not impact the other LSRs since >> they would not create any new TE LSPs trying to join the new TE-MESH- >> GROUP. In term of amount of flooded information, this should not be a >> concern either (handled by routing). We clarified this in the >> security section. > > The impact on the other LSRs is exactly flooding question. Covering > that in the security section is fine for the misconfiguration and > malice cases. > >>> 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL >>> and must at most appear once in a OSPF Router Information LSA or >>> ISIS Router Capability TLV." but for addition/removal it mentions >>> "conversely, if the LSR leaves a mesh-group the corresponding entry >>> will be removed from the TE-MESH-GROUP TLV." >>> What are these "entries" referring to - that there is a top-level >>> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions >>> "No sub-TLV is currently defined for the TE-mesh-group TLV") ? >>> >>> AF>> My comment on this is that the definition of the TLVs seems >>> AF>> unclear. >>> AF>> From figure 2, it appears that some additional information >>> can be >>> AF>> present in the TLV after the fields listed, and (reading >>> AF>> between the lines) it would appear that this additional >>> AF>> information is a series of repeats of the set of fields to >>> AF>> define multiple mesh groups. >>> AF>> This could usefully be clarified considerably. >> >> >> You're absolutely right. The figures have been modified: >> >> (example show below): > > [SNIP] > Looks good to me. > >>> AF>> But it is now unclear to me whether a single router can be a >>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that >>> AF>> these cannot be mixed within a single TLV, and multiple >>> AF>> TLVs (one IPv4 and one IPv6) are prohibited. >> >> OK the text requires some clarification. What is prohibited is to >> have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is >> permitted. New proposed text to clarify: >> >> The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and >> one IPv6 instance MUST appear in a OSPF Router Information LSA or >> ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or >> IPv6) occurs more than once within the OSPF Router Information LSA, >> only the first instance is processed, subsequent TLV(s) will be >> silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 >> or IPv6) occurs more than once within the ISIS Router capability TLV, >> only the first instance is processed, subsequent TLV(s) will be >> silently ignored. > > OK. That's fine. > I think you want to make a couple of changes: > - "at most one instance MUST appear" is ambiguous since it will > be confused with "an instance MUST appear". I suggest you > reword as "MUST NOT include more than one of each of" > - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs > more than once" should really be phrased as "If the either the > IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more > than once". Ditto for the IS-IS sub-TLV. > - Two instances of "will be silently ignored" should read "SHOULD > be silently ignored" Fixed, thanks ! > >>> 4) Small terminology issue in section 5.1 it says: "Note that both >>> operations can be performed in the context of a single refresh." >>> This is not a refresh. It is a trigger/update. A better term for >>> OSPF would be "LSA origination". >> >> OK fixed (I used the term "Update"), thanks. > > OK > >>> 5) Please state the applicability to OSPF v2 and or v3. Note that >>> the Router_Cap document covers both v2 and v3 >> >> Indeed, Thanks for the comments. The OSPFv3 aspects have been >> incorporated. Here is the new text: > > [SNIP] > OK > >>> 6) The term "fairly static" at the end of section 5.1 is >>> meaningless without some relative context. >>> Presumably this relates to the number times an LSR joins or leaves >>> a mesh group over time. >>> Is it intended to be relative to the IGP refresh period? >>> Please clarify in an objective rather than a subjective way. >> >> >> Right, this requires clarification. Here is the new text: Moreover, >> TE mesh-group membership should not change frequently: each time an >> LSR joins or leaves a new TE mesh-group. > > I could live with this, personally. We'll see whether we get any > more comments. > I think the nub will be: > 1. whether your "should not" can be "SHOULD NOT" > 2. what does "frequently mean"? > 3. what is there in this I-D to say that an LSR does not join/leave a > TE mesh-group very often? > Hopefully I clarified with the text above. >> I guess that this is sufficiently explicit: it is a well-known fact >> that LSRs are infrequently added or removed to a TE mesh. > > :-) Very well known. In fact, my mother was commenting on it to me > only the other day ;-) > ah so she should talk to my kids then ... we can work this out ;-))) > Consider the case where PE membership of an automesh is dependent > on whether there are C-nodes subscribed to some service. > > Perhaps this well known fact could be noted in the Introduction to > this I-D which is AFAIK the only IETF document on the subject of > automesh. OK, see the proposed text, and let me know what you think, I do think that this is sufficient but let me know. > >>> 7) The security section (section 8) is inadequate and will >>> undoubtedly be rejected by the security ADs. At the very least, the >>> I-D needs a paragraph (i.e. more than one or two lines) explaining >>> why there are no new security considerations. But what would be the >>> impact of adding false mesh groups to a TLV? Is there anything >>> (dangerous) that can be learned about the network by inspecting >>> mesh group TLVs? >> >> The following section has been added: > > [SNIP] > OK. Let's run with that and see how much we get beaten up by the > Security experts. OK, thanks. cheers, JP. > > Cheers, > Adrian --Apple-Mail-54-235550940 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

On = Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote:

Hi JP,

Thanks for addressing the = comments. I have forwarded these to the Routing Directorate and copied = them on this email to let them respond if they want. =

OK

But here are my = comments:
in = line,

1) The Tail-end name field facilitates LSP = identification. Is this
a new form of = LSP identification?
If it is not new, then = there should be a reference to RFC3209 and a
statement of which RFC3209 fields are mapped to this = IGP field.
If it is not new then there is a = significant concern that a new

As indicated in the document the string refers to a = "Tail-end" name,
not an TE LSP name: thus it does = not replace the session name of the

Hmmm, = yes it is not an LSP name, but recall that the LSP is identified by a = combination of Session and Sender Template, and that the Session = includes the destination IP address. In Section 3.2 I see:
=A0 - A = Tail-end name: string used to ease the TE-LSP naming.
and in Section 4.1:
=A0 - A Tail-end name: a variable = length field used to facilitate the TE
=A0 LSP = identification.

Ah I see your point now. = Just bad wording, it should have read "
The idea is not to use that = field for LSP identification per say but to ease the management, = troubleshooting, ...
For example, an implementation could form = the session name based on the strings on these fields.

A Tail-end name: name of = the Tail-end LSR.

+ see = below


These = definitions seem to imply that the tail-end name is used as an = identifier for the LSP. The question that will be asked is: How does = this identification of an LSP differ from the conventional = identification of the LSP?=A0 = Given that you also have:
=A0 - A Tail-end address: an IPv4 = or IPv6 IP address to be used as a
=A0 tail-end TE LSP address by = other LSRs belonging to the same mesh-
=A0 group
it appears that the tail-name is superfluous = information.
Well having the name = definitely helps for management, troubleshooting, = ...

So, perhaps the name is present = for diagnostic purposes? Perhaps it is there to ease OAM? But it does = not seem to play any role in the protocol procedures as it is not = explicitly mentioned later in the I-D (e.g. Section 5).


OK let me try to clarify = adding the following text then:

The aim of the Tail-end = address field is to provide a way to quickly identify the tail-end LSR = originating the TE-MESH-GROUP and could be used for various purposes = such such troubleshooting, management and so on. It does not interfere = by any mean with the TE LSP attributes used to identify a TE = LSP.

Does = that clarify ?

How = would a node behave if it received a mesh group advertisement that = indicated a tail-end address that did not appear to match its record of = the tail-end name?
2) The document mentions that the number of mesh = groups is limited
but potentially (depending on = encoding) provides for binary
encoding for = 2^32-1 groups (although this might be constrained by
OSPF's limit of a TLV size to 2^16 bytes.
The document (and the authors) state that scaling of = these
extensions is not an issue = because only a small number of mesh
groups are = likely to be in existence in a network, and any one
router is unlikely to participate in more than a = very few.
There are two = concerns:
a) Whenever we say that = something in the Internet is limited,
history = usually proves us wrong.

And that's = undoubtedly a good news :-)

Indeed, = there is already a
proposal = (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a
similar mechanism for a problem that would have far = more groups.

Two comments:
- Mesh groups are used to set up TE LSP meshes. If = we consider let
say 10 meshes comprising 100 = routers each, that gives us 99,000 TE
LSPs. = One can easily see that the number of meshes is unlikely to
explode in a foreseeable future. If it turns out to = be the case,
we'll have other scalability = issues to fix before any potential with
the = IGP.
What about 100 meshes comprising = 10 routers each?

Note that would still be = very reasonable ;-)

I make that only 9,000 TE LSPs.

So = clearly the scaling of MPLS-TE is not directly related to the scaling of = automesh.
Well you see my point ... = since these extensions are used to set up TE LSPs, in the vast majority = of the realistic cases you'll end up with scalability concerns with RSVP = before seeing any IGP scalability issue.

What this comes down to is your statement about how = automesh will be used. I think we can all accept that this is the = problem space that you intend to deploy in, and that is great. But the = original point from the Routing Directorate was that there is nothing in = the I-D that imposes this restriction. So how can we say that the = protocol extensions will scale?

And that is true with = pretty much every protocol: one could always come up with a scenario = where a bad usage of the protocol or a broken implementation may be a = concern. Anyway, let me try to propose some text to close on = this:

OLD:

It is expected that the = number of mesh-groups be very limited (to at most 10 or = so).=A0
Moreover, TE mesh-group membership should not change = frequently: each time an LSR joins or leaves a new TE = mesh-group.

NEW:
The aim of = the IGP extensions proposed in this document is to ease the provisioning = of TE meshes, the number of which is generally very limited (10 at most = or so), and should stay of this order of magnitude at least in = a=A0foreseeable future. Furthermore, such TE meshes are not expected to = change frequently and thus the TE mesh-group membership is likely to be = very stable (each time an LSR joins or leaves a new TE mesh-group, which = is a not a frequent). An implementation SHOULD support=A0mechanisms to = control the frequency at which an LSR joins/leaves a particular a TE = mesh group.

Does = that address your concern ?


- More importantly, the dynamics = of joining a TE mesh is such that
IGP updates = are used to advertise to TE mesh group membership change
(join or prune), which are indeed expected to be = very unfrequent.

Again, the concern raised is = that the problem space you intend to deploy in is, indeed, limited in = this way. All good. But how can we say whether the protocol extensions = will be used differently in the future? What controls are there over = constructing a mesh where joins and prunes are frequent?

b) The I-D = does not itself impose any reasonable limits on the
number of groups with the potential for a single = router (by
misconfiguration, design, or = malice) advertising a very large
number of = groups.
Thus, it appears that the = scaling concerns are not properly
addressed in = this I-D.

Not sure to see the point here. = If indeed, a large number of TE MESH
GROUPs were = advertised, this would not impact the other LSRs since
they would not create any new TE LSPs trying to join = the new TE-MESH-
GROUP. In term of amount of = flooded information, this should not be a
concern = either (handled by routing). We clarified this in the
security section.

The = impact on the other LSRs is exactly flooding question. Covering that in = the security section is fine for the misconfiguration and malice = cases.

=
3) The document mentions that "The TE-MESH-GROUP TLV = is OPTIONAL
and must at most appear once in = a OSPF Router Information LSA or
ISIS Router = Capability TLV." but for addition/removal it mentions
"conversely, if the LSR leaves a mesh-group the = corresponding entry
will be removed from the = TE-MESH-GROUP TLV."
What are these "entries" = referring to - that there is a top-level
"No sub-TLV is currently defined = for the TE-mesh-group TLV") ?

AF>> My comment on this is = that the definition of the TLVs seems
AF>> =46rom figure 2, = it appears that some additional information can be
AF>> present in the TLV after the fields = listed, and (reading
AF>> between the = lines) it would appear that this additional
AF>> define multiple mesh = groups.
AF>> This could usefully = be clarified considerably.


You're absolutely right. The = figures have been modified:

(example show below):
=

[SNIP]
Looks good to = me.

=
AF>> But it is now unclear to me whether a = single router can be a
AF>> member of IPv4 = an IPv6 mesh groups. It would seem that
AF>> TLVs (one IPv4 and = one IPv6) are prohibited.

OK the text = requires some clarification. What is prohibited is to
have two IPv4 sub-TLV or two IPv6 sub-TLV but one of = each is
permitted. New proposed text to = clarify:

The TE-MESH-GROUP TLV is OPTIONAL and at most one = IPv4 instance and
one IPv6 instance MUST appear in = a OSPF Router Information LSA or
ISIS Router = Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or
IPv6) occurs more than once within the OSPF Router = Information LSA,
only the first instance is = processed, subsequent TLV(s) will be
silently = ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4
or IPv6) occurs more than once within the ISIS = Router capability TLV,
only the first instance is = processed, subsequent TLV(s) will be
silently = ignored.
OK. That's fine.
I think you want to make a couple of = changes:
- "at most one instance MUST = appear" is ambiguous since it will
=A0be confused with "an instance = MUST appear". I suggest you
=A0reword as "MUST NOT include = more than one of each of"
- "If the = OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs
=A0more = than once" should really be phrased as "If the either the
=A0IPv4 = or IPv6 OSPF TE-MESH-GROUP TLV occurs more
=A0than once".=A0 Ditto for the IS-IS = sub-TLV.
- Two instances of "will be = silently ignored" should read "SHOULD
=A0be silently = ignored"

Fixed, thanks = !


4) Small terminology issue in = section 5.1 it says: "Note that both
operations = can be performed in the context of a single refresh."
This is not a refresh. It is a trigger/update. A = better term for
OSPF would be "LSA = origination".

OK fixed (I used the term = "Update"), thanks.

OK

5) Please state the = applicability to OSPF v2 and or v3. Note that
the Router_Cap document covers both v2 and v3
=

Indeed, Thanks for the comments.=A0 The OSPFv3 aspects have = been
incorporated. Here is the new = text:
[SNIP]
OK
6) The term "fairly static" at the end of section = 5.1 is
meaningless without some = relative context.
Presumably this relates to the = number times an LSR joins or leaves
a mesh group = over time.
Is it intended to be relative to = the IGP refresh period?
Please = clarify in an objective rather than a subjective way.
=


Right, = this requires clarification. Here is the new text: Moreover,
TE mesh-group membership should not change = frequently: each time an
LSR joins or = leaves a new TE mesh-group.

I could live = with this, personally. We'll see whether we get any more = comments.
I think the nub will = be:
1. whether your "should not" can = be "SHOULD NOT"
2. what does "frequently = mean"?
3. what is there in this I-D to = say that an LSR does not join/leave a
=A0 TE mesh-group very = often?
Hopefully I clarified with = the text above.

I guess that this is = sufficiently explicit: it is a well-known fact
that LSRs are infrequently added or removed to a TE = mesh.
:-) Very well known. In fact, my = mother was commenting on it to me only the other day ;-)


ah so she should talk to my = kids then ... we can work this out ;-)))

Consider the case where PE membership of an automesh = is dependent on whether there are C-nodes subscribed to some = service.

Perhaps this well known fact could be noted in the = Introduction to this I-D which is AFAIK the only IETF document on the = subject of automesh.

OK, see the proposed text, = and let me know what you think, I do think that this is sufficient but = let me know.


7) The security section (section = 8) is inadequate and will
undoubtedly = be rejected by the security ADs. At the very least, the
I-D needs a paragraph (i.e. more than one or two = lines) explaining
why there are no new security = considerations. But what would be the
impact = of adding false mesh groups to a TLV? Is there anything
(dangerous) that can be learned about the network by = inspecting
mesh group TLVs?
=

The following section has been added:
=

[SNIP]
OK. Let's run = with that and see how much we get beaten up by the Security = experts.

OK, thanks.

cheers,

JP.


Cheers,
Adrian=A0
=

= --Apple-Mail-54-235550940-- From owner-ccamp@ops.ietf.org Fri Sep 22 10:32:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQm4k-0007Lj-Dg for ccamp-archive@ietf.org; Fri, 22 Sep 2006 10:32:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQm4f-0001bp-UJ for ccamp-archive@ietf.org; Fri, 22 Sep 2006 10:32:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQlx2-000ENJ-Ls for ccamp-data@psg.com; Fri, 22 Sep 2006 14:24:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.91.191.4] (helo=smtp.dataconnection.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQlx1-000EMz-E8 for ccamp@ops.ietf.org; Fri, 22 Sep 2006 14:24:23 +0000 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:24:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DE52.CBE16254" Subject: question on draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Fri, 22 Sep 2006 15:24:21 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E02409D6F22F@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question on draft-ietf-ccamp-gmpls-recovery-e2e-signaling Thread-Index: AcbeUsv260Z4fGWJTmy31BkUFKv7vg== From: "Alan Davey" To: X-OriginalArrivalTime: 22 Sep 2006 14:24:21.0712 (UTC) FILETIME=[CBF47D00:01C6DE52] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DE52.CBE16254 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I have a question about the use of end-to-end recovery signaling in conjunction with graceful restart following nodal faults. =20 Is it expected that the end-to-end recovery signaling protocol will handle the restart of either of the ingress or egress nodes during switchover or reversion processing, where that node implements graceful restart mechanisms as described in RFC3473? =20 If so then what is the effect on, for example, the end-to-end switchover request/response procedure of one of the end-nodes restarting? =20 Thanks in advance =20 Alan =20 ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com Web: http://www.dataconnection.com =20 ------_=_NextPart_001_01C6DE52.CBE16254 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
I have = a question=20 about the use of end-to-end recovery signaling in conjunction with = graceful=20 restart following nodal faults.
 
Is it = expected that=20 the end-to-end recovery signaling protocol will handle the restart of = either of=20 the ingress or egress nodes during switchover or reversion processing, = where=20 that node implements graceful restart mechanisms as described in=20 RFC3473?
 
If so = then what is=20 the effect on, for example, the end-to-end switchover request/response = procedure=20 of one of the end-nodes restarting?
 
Thanks = in=20 advance
 
Alan
 
------------------------------------
Alan Davey
Data Connection = Ltd
Tel:   +44 20 = 8366=20 1177
Fax:   +44 20 = 8363=20 1039
Email: Alan.Davey@dataconnection.c= om
Web:   http://www.dataconnection.com=
------_=_NextPart_001_01C6DE52.CBE16254-- From cullenecopes@gmnameplate.com Fri Sep 22 23:01:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQxm7-0000mX-7n for ccamp-archive@megatron.ietf.org; Fri, 22 Sep 2006 23:01:55 -0400 Received: from [189.145.134.53] (helo=gmnameplate.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQxly-0000xg-9n for ccamp-archive@megatron.ietf.org; Fri, 22 Sep 2006 23:01:55 -0400 Message-ID: <01c6de1d$51bff3f0$07fea8c0@maqgris> Date: Fri, 22 Sep 2006 10:01:33 +0100 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Ciprian Enoch" From: "Ciprian Enoch" To: Subject: PHexARliMA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07E3_01C6DE2E.154FEFE0" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.7 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_07E3_01C6DE2E.154FEFE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi VzAGRA $3 , 35 AMBzEN VALzUM $1 , 25 CzALIS $3 , 75 =20 http://www.rinkdesinmindasion.com ------=_NextPart_000_07E3_01C6DE2E.154FEFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

VzAGRA $3 , 35

AMBzEN

VALzUM $1 , 25

CzALIS $3 , 75

 
------=_NextPart_000_07E3_01C6DE2E.154FEFE0-- From orion@dm.mailpia.net Sat Sep 23 08:53:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR712-0000CG-C3 for ccamp-archive@megatron.ietf.org; Sat, 23 Sep 2006 08:53:56 -0400 Received: from [125.187.32.160] (helo=m07.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR70z-0005x0-NV for ccamp-archive@megatron.ietf.org; Sat, 23 Sep 2006 08:53:56 -0400 Received: (qmail 5763 invoked by uid 0); 23 Sep 2006 21:51:43 +0900 Message-ID: <20060923125143.5762.qmail@m07.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyohou-bisiness Reply-to: delivery_rt Date: 2006-09-23 21:50:03 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060923185128_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From suittxda@tpnet.pl Sat Sep 23 11:55:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR9rB-0003ZO-HA for ccamp-archive@ietf.org; Sat, 23 Sep 2006 11:55:57 -0400 Received: from dlm107.neoplus.adsl.tpnet.pl ([83.24.42.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GR9qy-0003za-7n for ccamp-archive@ietf.org; Sat, 23 Sep 2006 11:55:57 -0400 Message-ID: <000e01c6df28$fbfe9810$6b2a1853@dompt1hmuvrmv6> From: "Quizmess Schloss" To: ccamp-archive@ietf.org Subject: side Mono MUSIKQUIZ auf Date: Sat, 23 Sep 2006 17:57:34 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6DF39.BF876810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: b058151374d77ee76edaac850f7449fb ------=_NextPart_000_000A_01C6DF39.BF876810 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6DF39.BF876810" ------=_NextPart_001_000B_01C6DF39.BF876810 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable e CONSOLE News Guestbook Videos Guestbook Videos Contact .. Console Album MONO OUT NOW DiskoB Acid Pauli = Website other side Mono MUSIKQUIZ auf SCHLOSS TELEDUBBY DANKT Quizmess = Schloss Teledubby jan Between years Merry Christmas SPACEMAN Console Album MONO OUT NOW DiskoB Acid Pauli Website e CONSOLE News Guestbook Videos Contact .. Console Album MONO OUT NOW = DiskoB Acid Pauli Website other side Mono MUSIKQUIZ auf SCHLOSS = TELEDUBBY DANKT Quizmess Schloss Teledubby jan Between years Merry = Christmas SPACEMAN Next auf SCHLOSS TELEDUBBY CONSOLE News Guestbook Videos Contact .. Console Album MONO OUT NOW = DiskoB Acid Pauli Website other OUT NOW DiskoB Acid Pauli Website other side Mono ------=_NextPart_001_000B_01C6DF39.BF876810 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
e CONSOLE News Guestbook Videos
Guestbook Videos Contact .. Console Album MONO OUT NOW DiskoB = Acid Pauli Website other side Mono MUSIKQUIZ auf SCHLOSS TELEDUBBY DANKT = Quizmess Schloss Teledubby jan Between years Merry Christmas = SPACEMAN
Console Album MONO OUT NOW DiskoB Acid Pauli = Website
e CONSOLE News Guestbook Videos Contact .. Console Album MONO = OUT NOW DiskoB Acid Pauli Website other side Mono MUSIKQUIZ auf SCHLOSS = TELEDUBBY DANKT Quizmess Schloss Teledubby jan Between years Merry = Christmas SPACEMAN Next
auf SCHLOSS TELEDUBBY
CONSOLE News Guestbook Videos Contact .. Console Album MONO OUT = NOW DiskoB Acid Pauli Website other
OUT NOW DiskoB Acid Pauli Website other side Mono
------=_NextPart_001_000B_01C6DF39.BF876810-- ------=_NextPart_000_000A_01C6DF39.BF876810 Content-Type: image/gif; name="e.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6df28$fbfe9810$6b2a1853@dompt1hmuvrmv6> R0lGODlhAAJIAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAARAAAALAAAAAAAAkgCBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFMq9KCypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHA99Anky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufO2BZ5Ln069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +1UP4N/Pv7///wAGKOCAyvVA4IFCxYPgggw26OCDEEYo4YQUVmjhhRhmWFEHGnbo4Ycghiji iCSWaOKJJgWC4oosMkdEizDGKOOMNHIEwI04AlDjeDru6OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZJZp5plo2jdFmmy26eabcMYp55x01mnnnXjm qeeefPbp55+ABirooIQWauihiCZK2wuKNuroo5BGKumklFaaExiWZqrpppx26umnoKpGR6gT AULqqaimquqqrLbqKpv/Obwq63LdzGrrrbjmquuuvPbq62Mq/irssMQWa+yxyCar7LJRksHs s8yxBO1W0rJFCSW4VtvWtbZq69a12E67Vbjilmvuueimq+667Lbr7rvwxivvvPTWa++9+Oar 77789uvvvwAHLPDAG2VA8MEIJ6zwwgw37PDDyiIC8cQUVzzRD5tyaPHGHHfs8ccgW+lPyLEd QfJIJp8c0hEpq+zyyzDHLPPMNNds880456zzzjz37PPPQAct9NBEF2300duRgPTSTDe9HAtO Ry311FRX7Z48VmfNmjBad70fAV6HLfbYZJdt9tlop6322mxHGkbbcMct91sjN3fC3Hjnrffe /nz37fffgLeNceCEF2744YgnzpiCTjPetONMQ7605EhTfrTlRmNetObyqpDgXlUozlUGBkdN utSkl+606qK37vrrsMcu++y012777bjnXt0huvfu++/OtQD88MQXb/zxyCev/PLMNw+fAM5H L/301Fcv/TTWZ6/99tx37/334Icv/vjkl2/++einr/767Lfv/vvwxy///PTXb//9+Oev//78 9+///wAMoAAHSMACGvCACEygAhfIwAY68IEQjKAEJ0jBCvoNaxbMoAYbdIaodXCDIAyhCEdI whLeRQwmTKEKV8jCFoolFC6MoQxnSMPlDKKGOMyhDtl0gx368IdAiQyiEIdIxCjtoIhITKIS l8jEJjrxiVCMohSnSMUqWvGKWMyiRLThNC42zYtMA+PSxIg0MtJrA0Mxo9HUqBuoYYmNWoyj HOdIxzra8Y54zOOkUqBH8LGuj+tRACAHSUj+AaOQiEykIhfJyEY68pHpWYPTJDnJSjaNkpDM pCY3yclOevKToAyl+wICACH5BAAQAAAALAAAAAAAAkgCBwj+AP8JHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+f QIMKHUq0qNGjSJMqXcq0qVOLWJ5KnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcs2o722 cOPKnUu3bkYDdvPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fP oEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX868ufPn 0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvjz5F+bT/0Svvr1O9u7j13wBX779+/jz69/Pv7// /wAGKOCABBZo4IEIJqjggkcpwuCDEEYo4YQUVmjhhRhmqOGGHHbo4YcghijVByL6R2KJ/J2I on4qrohfiy7aB2OM8c1IY3s23pjeBznq6OOPQAZJGD1CFmnkkRmak1MzSKamZJPiPQnllFRW aeWVWGap5YM+bOnll2CGKeaYZJZp5plopqnmmmy2qZYabsYp55x01mnnnXjmqeeefPbp55+A BirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aWYDsiFXnBm+hEXoHqaWaiiYkZqqXAJM9Kp qLbq6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMRyRkyxyCar7LLMNuvss9BGK+201FZr 7bXUUoDtttx26+234IYr7rjklmvuueg6Fki67Lbr7rvwxvvgNfLWa++9+Oar77789uuvljus RMW/BFtKRsFGHYwwUQov7PDDEEcs8cQUV2zxWkVcrPHGJOHC8ccghyzyyCQXVULJKKes8sos t+zyyzDHLPPMNNds880456zzzjz37PPPQAct9NBEF2300UgnrfTSTDft9NNQRy311FRXbfXV WGet9dZcd+3112CHLfbYZJf93wFmp6322my37fbbcGdmRNx0c6ZO3Xjnrffe/nz37fffgAeO USlXE2614VUjLvjijDfu+OOQRy755JRXbvmRAFyu+eacj2ZIphh0LvropJdu+umop6766qy3 7vrrsMcu++y03whM7W3DgPvurw3Ae6WA/C788MQXb/zxyCev/PLMr37B1c9zPEpN0Yd4SPPY Zy+qKtp37/334Icv/vjku5lM+einr/767MvpSvuK3Q7//PTXb//9+Oev//789+///wAMoAAH SMACGvCAC1MAAhfIwAY60G0juFoErTZBeL2CKhV0kR/ik8EHelBlY/igCEdIwhKa8IQoTOFt dIc1Fl7NhVaDYdVkSDUaTs2GUoMBDkVVABX68IdAjgyiEIdIxCIaMTODOKISl8jEJjrxiVCM ohSnSMUqWvGKWFwUOrLIxS5CSgteDKMYx0jGMprxjGhMY1Pkp8aPNKCNcIyjHOdIxzra8Y54 zONRvKHHPmqNCH4MpCAHSchCGvKQiEykIhc5OhUw8pGQjKQkJ0nJSlrykpjMYhUyyclOetJH +vikKEdJylICJSAAIfkEAFHMAAAsAAAAAAACSAIHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZv/Aug0qDOAwJ5Ac+5c 2DPnT6BDkQ4V6tMnz51NlxY9KhUpQaVRrSpFaJXqwKJYnzplavRq0IJnyVJdurbrwbBfp6Jl 6/WrWadY0/JUCLYtVLdxq84d25cr1LuE6TINC9iuWKNTz47FWXbvz8tlJ3ON6xgzXs+c0YbW TPhq58qfM5uuzHo1atGqW2NGrfn16dKra6eeDXv35NpCn8K+TXyz8eCxd7P+fXp24uNSXStO mru57OfLXVMGfn34ced8vf7rrk6+fHftzYHjbk06PO/x4Hv3bs/evfXxzPNLR7+ZO3P0/51H l3Ky1SdgdgTGZ1eAoPFWYE3+WWadd/JJ6KCF6V2oHHyOMahhZ/RNCCJRI1bYYXbnvUVhd/ot aF5s/X2HYYDwNfWijPdd1uKGGXp44oo2RUghdyIupuJcfJG2lYB6pSdXioFFB6B9yL2VVo0V 4sbhjBjCaKOCT66V0HpIHhmlj6lp2ZCQ5JWG15OAreefYg/SxGaGVEZ24YN0hmYglnyaCOV7 DoZopp/aJUigbw3yhyd/aYLpoqDDEVklnoY2GmlgXX6YXIMMyinil0BCiGOmXO5ZZJ2Ntqrp of8FbkmogaveOSugP+roKayyfkqbXIsy1BivlUJKaLCdHuiretJdaVyvQVJKa6HFjimehcji yqyjqKKYqaVkbqkotewhK2OvbrrK6KrTzvoomoWaO6WykLl6K6XrshsTjanuyW+iZV6n5n4l 7kqtj+6SqapzCqPosG30sgrltlVmS/CjGipsaKg5ulttwn4G+1+Ioupr55JwVjWsmH79xlZW KkamcpSchqxyUEuKFWaYaj0G2XSNNdnzzov1WTNiVmrpFsp5DTizaTs/fRTNdd3G8106H/1m XkVvrfXTklEm9thkl2322WinrfbabLft9ttwxy333HTXbffdeOet997+fPft99+ABy744IQX bvjhiCeu+OKMN+7445BHLjneA1RuUOUDCIT55v9gvpDnmVtOkOcDZT765qJrbnnoqaOOeumr J2S66gW5Tvrlra+uO+eqv95757KfzrvrvwvPO+y+32777Z3Hrvzuw++OvO2lT7747LVXD/z2 2B80u+jdb6+99qZ/D7vm2YvP/fkIdR9++aO3n7742JtPPvvez7/+/ZfHr7/9/EOfAJs3QAHC j37jM6D/1HcQYVjPb+EroAQjuEDuuS9+Ebyg/zSIvToUkIKhO136NKg/BH4wgQkEofrqd0IG SrB/8htgBkdYwveh8IAwfODhVFjDz+WPhdX+m2EFh3hAIPqQhUC0YQ9luEAcuvCHFXSiEwNI w/4lcYg3LOEKxzdFCuoQcDwkIkNSp0AmvpCEtSNe88hIwOCZ0X5KNJ7yplc/5rUxhiYsox6N 1z473pB5YZxgDvN4vBd+MXCBFGRDWhdAAGYxfxs0JBu5SMn9YZGEcKxiGvH4veP57olTpKIY twjJR0axkmg8pOASyUAvQhKJdBzkE1tpSC2ukZFBPKMsAehIV0rSk6XE4ixRmD0jCpOWlyzm MX2pSr1xcJdL3GMbU0lNRQpRl5EUITKjyUthGtOawcyiL2eXj/k58pHV7OE3idlMCDYRmsTE pRLT+U5wYvCcyJz/5zLNmUJx4vOZsmwhPaXZRTMaNJ7wZGc7IahGQObuk0EEHxtZ18mK4s6i vaMe8Pz4vEJuFKLCQ94aR0rH4ZE0pBmdqEpfp9GSUrSiLT2pSNNYRzS2lJkLzalOd8rTnvr0 p0ANqlCHStSiGvWoSE2qUpfK1KY69alQjapUp0rVqlr1qljNqla3ytWuevWrYA2rWMdK1rKa 9axL3QBa15oSE7D1rXCNq1znSte62vWueM3rNfLK17769a+ADaxgB0vYwhr2sIhNrGIXK7cP OFYgjv0AZB87EMkSJLKYvexjJRvZylLWs5bFbGcN0lnLTvazl9VsZhOy2n+g1rWoHa1q/kFr 2teKtrUFMe1pd5vbzcJWtL+V7W9Vq9vckta3x+XscHkbXNrG9rbBLS1wZ1vc6S53uKMVrnVT m1zXLne1xYWcbsdrXO6GtrKehWx513te77K3ttyNr3rRexDyzle+kz0ufe8b3vbeF7/u/S9/ /ete+8JXwPV9L2nTG2D+xte+BZ6vgR/MYAoL+MAIxvB+90tZCDc4ch4mb3g/XN0LJ3i9A3HF fwm84gZ7eMMSLrFxRZzh/JoXxd6V8YdbvGMXL7jHM5Zvf29M5CLvWMdC3vCQHWzhHms4x/j1 L5JB3GT1jnjKML7yj0+MYx+HmMv0VS6MoYxeFkd4wigWs5HH/hxhJf9YuAt+8ZajXGMf45jA EB5xk5Fs5gCXWM4SnrPkzovnMWP5tLg1tEJsu2UMbxfA7X1ym8m8ZCnX2c9BRohttQvpLjPZ xpquLnSPjGgtE5e4omZta/kM5O06OtSmth6heUxqAJtY0EDWrKI/3ec6H7jSga71ry8taT3r OtilxrWTDW1s2GbZ1wi+NZr1O2cWH5rWr05wrCcnZjUn+86a9vSSGWLm2q6azcJOLbDbvG4r EzvRuS7vtpV9ZXhHe83l/jSdG83aat8a3XaOLrrz/cBuB/zf0ha3snncbmTrueHOZi+739zb f0/Z2NO29b3Hjexad3zSYWbzoTUs/+eMk7jfIce3vuPduBdfnN8I33V9s73yQoO52I2mOabl neR9zzzlZQ73yQUd2mIPu8okJ3qmByzznXvc30N3OqALLuTPyhbO1736psf72jJv3dxg1269 rc7o2cY47KCdsavJDvZwZxe6WJ8u1rPu27lztsNsp23aK6x14Io9x10f9d7N3lvw5p25b+8w YxfP+MY7/vGQj7zkJ0/5ylv+8pjPvOY3z/nOe/7zoA+96EdP+tKb3vEUOL3qzUaB1K/+9ZRx PexnXxPZJy4RtPer7XPP+5bsvvfAR8nvg0/8kQy/+CLpQe+Pj/zmO//50I++9KdP/epb//rY z772t8/97v57//vgD7/4GyeP8Wu//ObPPvrTf/31s7/67n//9OMv/+jT//IsqL/+98///vv/ /wAYgAI4gARYgAZ4gAj4U4aQgAzYgA74gBAYgRI4gRRYgRZ4gRiYgRq4gRzYgR44V/wQggoR gvzwDyJIECRogiSYgim4ECyIgi2ogiVYECtYgwIRgyxYgyWogztogzC4gwaRgzR4gjJogggx gzcYgzR4ESv4g004EC8IhUQohTPIg0V4hD7Ygj44OQcAAABwD/YAADVBCl54AALhhWIYE0iY EEi4hjf4hkYYh254EG3YhigohcowhHAIh25YhXy4h3J4h3s4hVBYiEs4iHMYh/+AaIcqaBFr yIh+iIiHGISGGImJKIh/aIiK+Dj2QIZm2IlpSBMAsAkAYA9nOBOXiImE2IeTeISHOIdVqAyP GIiV2IqbeIuLqIm4qIirCIi4OIuvqIsRAYu2yIqYaIu3mIq5yIvIuDhlOBBhaBMAgAAAQAqn KBPKOIibaIzCSIl06I1AWIiRmInCaIzAqI0uKI6CmI3cKI4n2IM/+Ia9WIzNSIveeIy7eIyW eI+O44UHYQ/34IVg+A9oeABScA8E+YVhKJAK+Q+g2JAFKQVSYIYFSYaheIoBSZEOaZEDGZEI KZCmCJACORCkYI0UkY3MmJLlmI7fuISyqI3jaI++2If/SriFSTiCtUiOroiP9viOiEiIvpiM 9diNQdmOLcmHQBmUiuOPBiEFAHAAXSgFZ/iUUQmVACCVXogAUfkPmyCVW5mQFLkJ/0CNYkmQ pkgQaSiR0diV//CVZViVW+mUVimV/1CSFYGSjCiTQomTRwmFebiPcviEe7mS26iUjXiUkGiY hLmOmliFTXiJxIiP7LiTkumCghmO/Mg4TFkQTNmZaeiZCTmVA4EAAfmZpikQGXkACMmZAkGN ZDiapSmaoRmaoIkReKmLmDmTLJmZtAiYiWiURomOfdmYdxiTwxmZeWmckJmZwVmPkUmUPKmX ink4m4mWpzmboFmbpPCR18mU/2G4CaSAAAYRirFZl9wpm9mJhtV5l8iYlzdZmfCZk4wpjzq5 mLp5j+e4i+55mMDZnsKpnJRpn4N5n895n0S5n/mIOM84EBTZnQ6KnWL4mhAqm/8QkHTJmgJh D05Zlw86oRvKEflJnPSoj4hJopJYnyIan/TZmAiqkilaoMtohJg5jrnZijDqojEKoyGqnyrK OKBohm2JkHLplg+alXFJlbW5mdS4mhgqEF34D0OapKeZkUEqEHY5EVY4hD3Yjjiog1gIi10K iTYZj1pKhY85hSK4pXSYpvOYhMuppY+oplrIpqkomFQYhGgqg09Yk0SYpY5Jk39qnI7ThVe5 miIJkf9omJBiqJ5f2JAAGZ5kWJr+mKgCMZHjWZ3W+KgIEKnqqaieWppMeqV/hZJfRKo8tZ4R oaG0Z6qTw6o7haoOQQoTCaSz56qPY6s51akSEZBM+oG++qvAGqzCmhJWUKzGaqzDSnlWkKzM 2qzO+qzQGq3SOq3UWq3Weq3Ymq3auq3c2q3e+q3gGq7iOq7kWhNK6KZueqa4Wq4dQYakEI0S QakK4a7wGhHymhD3yp4l2pvs6hJkaIoSWqEQAasE8a8cShEEy5kXqa+82Zz9ahLemYZP+hAJ K5v1aq8LixAV+xBv2qMPexKkaJKomaiHOpAVWqiiSagZG7LW+ZQW6ZEJ2ZH/jTqQJXuWTCmq EtGxAvqxJqGh1XiWsxmlUhmQpEmXN0urBOGz79qao3iGpviWVzmXCWkPRyq1s4mzwxigBlo4 DwCBFmqzD0qKCluXSGsQXzuyULmaUjqha2ubWjugPJsSAVmWa7ueXiirQIsQc5uhoxie6Hma 6fm3GWGOzDmUcasRpSi4Hpq4A5GVpFCW4wm2A2GhjVukgNuhTKiKhQudh7sR1TiWXziVmyq0 J3sApCmbJSmenGmNSzqaoau4k4qkUkm6Vyuyw+ilV4iu6XqundsRpRiQImuQm2APNWulP6uo i5qVnCmStgulQNqpiYqG90CoNAuqT5uoWNu7QaWq/9prVrIKld1rVrwavuRbvuZ7vuibvl2V seqrVfnKvo17EAR7kdHrubpqEffbEvDLEPtbuflLkCnxmXbFqPlqpc3LoCCZvP3rEosKwBR6 qeOJr2hZuQgrv/FbEfTruxU8sE06wRd8Ehl8jXSlpOybvT+6kdcpjQAcwhrbwR28sAsswREs wvE6w4i7wQ7RwB/swTtMEizswHO1sfj6lNCYwjWhwzxswfGLqjAswZ5pmlBsw5arwC7swMm7 xPS7mQocu+g5myscu1QcwaFYwBkrwFM5xtVJqUkKoWOcxHHlj/CKhgggBS8LwfIrhsVrkCQL qiR5wPZrw0rcxW4Mv/KKxv8XzL6M+sFmDMQ9/MUCrMYiHMZA3MaQ3JmKHMhtDMinaMlWfMie vMmc/MOMDFeJPJVQaY1MTMhiSLob+qS0m70cYbcKwcJNnMSQ7L9pTMM7vMi8rMmdfI2ZHMw8 LMzAHMmNPMnHXMbF7MbI3MzErMsxTFZwjMZAm8oae8WhGbKS68UjgcSj/MI9XMuXHM63DM7N vMKB/Mm/vM6LfM69vM7ofMeFnM7L7MXKXM/vLMr7q3xlZc0UPLZ3PKGgKAXX+78h4c39S8su LM4//My2bMybTM/sDNEOnckTDc/eHM66DM0a/c3PnM+DPMJlnMWXirTPi82bSbkfCrHxvNEP zdH/5szIhlzM4vzLhUzIw2zGoazO6BzFxIzEsFrLGd3Qy/zRwDypnozTQTzS1mkQJ1yloUm6 RHyVpQvVsIy4aazFLbvVvny/96rG0AvDpSyaoqywuazVWR3FFIrU0ZvIuXypaIzNuJzWnuq/ XE3WntrWuyzSaQ3F7EuoB3nGvwuSBIkAXQmkfGzAIhHNOHzENVzFIKw3jP2Akx3Zj83MLJ03 lU3ZM1HA/EvXKOHZcrPZ7Vvapn3aqJ3aqv2spL3aRkXGre3aE7GQn3vNrU3AQrwSDVzWsh0S kqq61zwRiTvNHdGrGNzSsd3bEwG5C5HbQ/wRE3sRCM3Nyg3dAgncScur/3DMkQV9ABYZ0BnK 3Yo6x9YoqV5YsiN7s36cwyT9zYzjDxb4skRcEFEqhmy5lWTptODNlV5J1WDp3f8ahtZIu5t5 1ew9ztUdEqTZtACtpOWZmsb9z7DpmdvMxRN6w++c4CLxpGGNuufpkH2L3U1Nkh++maRIvJ9L wA8s3Ret4SJxwKApoSnt3/st4ynss4ENpUyNEbsN0S7OEZuwCWZouk35lNS4ykgaiq0b3JWa 5BRqspNLxKoputZo4J+dxcn94wlxD07pt06t3ed9D5D6us5r22moqZwK1mjot4ndllIwvHW5 3jms5WnDvRqhsl54oXSeON9bthchBcC9qXu+OP/jyxHenedQPuiKvuiM3uiO/q1Z/uiT875m HVensHqGfbzFa9tz0+MPbNGSjhBH7oViSbtMPhERnhGpPufTjeChfhCkYIbUiJVGbMcSEd0b gev26tGsGel77t3Xu+IOCeYojKguW52SWuwyO410fLLqid7OnoZWvt+N7Ot0PoonLez1zd9t SdX5bZYAfd/+/ZYlWYoCruNWW+By/twhbe0/vqkpXusXPpYPTpURXp0LbpoVjtLyvutE7dKv XhBHzrZ6fbUf/p1ePuLmOe8nfu4qTt01/O/uHfCcKZa1OeL+aONRruf/rPFejOOrudISHvEy PcwUfxCBTY3iaeoDIZf/A7/tTJvqjgvzKZ23VT3lCSno0w7Xd13X1jcNVFWaXr7p2d2oYT7m TGqpBiG8xCvm8G7egl2N4tnmTB/nl33yNmHnFoHnNI71fdPnGQHoo7nuXl83hY4Rh16oNl/2 bN/2bv/2cB/3cj/3dF/3dn/3eJ/3eq9UmHA2prD3gB/4gj/4hF/4hm9+C3j4hWMIjK/4g8P4 ie/4gAP5kl/5ln/5mJ/5mr/5nN/5nv/5oB/6oj/6pF/6pn/6qJ8QM1CtB2ApY2I0BlEKpZD6 IVEKAeDna+L6BCH7tP8R9qATKiYRsN/7JQGVnRAAZ9kTB0AFVPCJth8AJvsXt//8yw8WO1H9 /0PB+8QvEZ3QlrcfF2YYAN3fCVTg/eUfHAgg/j9hD1TgE60/Ne3v/QKh/dv/EFP++7M/NVVC mknhFPdw+wBx4N6/TgFK2fuXMEAAggYRJoQYUeJEihUtXsSYUeNGjh09fgQZUuRIkiVNnkSZ UqXKUgtdPlyokOG/UgNj/rtpL0CnUgj+2WtJBSZDoAGErkSaVOlSpk2dPoUaVWpToBAPBDgg U2tLrThn/nNlNOI9sV4hkqUyVe1atm3dvoUb922prAl1Hr0ZkwrWqzNv/kMQYCDOrGVjYsWZ lmYpuY0dP4YcWfJkkS0Re3XpErM9Vz1b9v1LpW4ABJ1EY15Y+vRiyv6tXb+GHVv2Y3uKZ9/G nVv3bt4kS4mu21v4cOLFjTsOG/z4cubNnT+HHl36dOrVrV/Hnl37du7dvX8HH178ePLlzZ+X 7gj9evbt3b+HH1/+fPr17d/Hn1//fv79/a/36T8BBySwQAMPRDBBBRdksEEHH4QwQgknpLBC Cy/EMEMNN+SwQw8/BDE6AEIkEUIAToToxBExWrEjFSNSsUWKXpQxqRpLxJG4Gm+cCEUX/xmx RR4lEnLFIUvyMUclh9tRoyMrChLIhJ5MEcYplaJySS1fa1LKJIGMckofg2xSxherJLLHMcEU U0g2U4wxzTGNJLPOLe+Mq8w1pXyzyC9h5P6Ryj/pdPPKM41EE9Ar+eSzUDwfZavLQieN88k/ F70oSUcZRXTRTTHttNFEISU1KknRnDRNi8K00klQWxXV01Ff5bTKLEvFNaVTZeV1Vjl7XLXV TVMF9dJaj/VyOkly5c9RYmm0FcpkYZ0xVVaPJVZaXs98k1lvl+KWxjk5RZFbIjX98kY7xQTT zDntjDHQdK+99dvrZpGwXqbMFElfe/8dj1+Q/AW4YPDi/Mhcg3kDZWGHH4Y4Yoknprhiiy8O j2CMzdthQ4RNUnhHY9tUM0uNXSxX25M3lqhjDAUmKcoiYT3y0pEVTdhVdtXslmWRXK5QXSSn xRRZYPm99eSkqf4V1ueSgJ5QaHEJNbRMYBMNNVqt21XUz6q5BjtsX0mO1emRoI5QaGzhHNlm moOtNdRO92xXbloZhVPVaVc2OyK0H1SbUmhX7fLuq+emVfCUD2e7bT8X57tviHb4m0G1iS58 RrxhrnnbxFHVu27DMy26bMm1vJzVzI+m9tO3Ee81a2Tt1rZX209fEmbMt/5Vd9exznbuxXeX VfVzQTe0dNyV/HjWqaGc191PwyXb3OGfb7Ncr+WMvu6bl584cvDHJ798889HP33112e/ffff hz9++ed374OMBncqXn8vBxndIfmn38vyhpRAMU1nBAwdzgYYQAEa8CQFHBuLsJRAA/6Kj4EC ktfOyOQlqnGQbK1jG6AQdagQfq2EANweufB2QQr9z1bvAt6eIBi74gnvVSQ03bni9blGWZCF /XGh7aR3PeV5D2ulo13wipjAJI7uh2mrXdZ0t7ar6W1mNKSiCuGGvFj97okO2pXpppgtB04P i0p0IBJ56MX57OOLMTsi13y3tRFSkIqICxMaZce0JvbQh2/MT8hkBsMQPm9QxgoXDLXXQUNq SocnJOTwADlJSlbSkpfEZCY1ucmorIKTnwRlKEU5SlKW0pQGW8YpVblKVrbSla+EZSxlOcsK tYCWCbHGLXW5S1720pe/BGYwhTlMYhbTmMdEZjKVuUxmNv/Tmc+EZjSlOU1qVnOVdbBmNrUJ qWxs05vfBGc4xbmhVI7TnOdEJ8XQkE52WlIb75zIO7WREHnW8x/ytAg+KWLPiOBznvXU5z3h Oc9+wlOgBAUoQA9qT30yFCL+rAhEJULQhw6UovQ0qEQLqtCE/tOgG03oRAMa0niC9KMHRalI EXrSfQ40pQtVKEb5CVOLqpSmF5WpQFU60o5+VKIdBWlFZ5pTnBL1pTz1aVKHSlOlFJWeD33q PaOaz4j2E6oYnapUtarTiVr1qhdFqFfB+tWK7rOsXUXrVsmKVbSGVa0rjadbpzrWrBYVp3Sd a1WvSlW23rWue90qXe0aVbl6Va3+hG2rWM/qVori1bFnNWxG0/pYxZYUsClx6mEPm9nLZhWx a02rZvGqVaeWFrCFHaxhn+pXtoJWs5c17VhR61nSqlaqo6WsZV9r28LWdq+5LWhodztX1hbX rLAVrm/z2lnBJta5rkXuSjKb2s4mV7S0Ve5w/7rc5kK3t7qtKmtvW9mMGBeqst1uakc73tNG lq+cxe5mt/tW1/6TtxdpLH2Xm134ire+1bWtZ7/b2+9eVyXTBa92X0tdli6VpYmV61Al/ODg 6tXClM1va/kq1O6yt8NfdfBvQxxf9uLXwoSdcEAXSl7/6jbCv+WwSE9s4JhCtqU7bahlzZtc +IYEwcL+7bFpgZzh0v7YvoFNr1V7zNXQjrS93JXxhj/7WcbOVL20zXB293tcjPx4rTueMpLl u2EiwzjMNhawjuNLYciC+cwFpi5KvBxdKTP3uEuO7WoDvGASB9i/NRaznhN8XzX7VsgsxrGZ Fc1lEzNaucA9dIn7nGVJH7nPafbzlq1L3jNrGc6DLombx0xnQXP609U9sqX57GJGxznQ+73r bGd86FRj98rznbJ4/6wRN7940ZFm8qRhi15UE9rOr16vfkVN4DS3+CTAxTSW3Sti7zJ5zi1W daXjWuxFB1q9lAZyVxtb5lY/ecy4Nfelf73u+frV1f09NqlvC+44U3rczCX/N7thbWqkAPWl RyUph1Us4ZT626OcxW1IgdrQgf97p0KFuD8bvFo2A5yjPpWpioOaU4ELHKwHv+lGKxxXuyrV pCZl6MQh3lKQGzvk8451yU1e1paLO6MzX7FNMy7xpYpzybgqRDUlEOp2QmroRb/Y0ZFeMaUv fWJNd3rUpT71jyA1xhz3eHlHvvOec5zh6/26g5XaYIvGlOdddqnVM551jxfZvgsne8xTLvZs 19jqXz85qCEadhyXve14DzjKHy7ylRaenwPnqc5/HhddT7vJXeYxrlULdlZr+dyF9rWC7z1q SH/ZxbIGdpIV/eAsNz7erg6srJ3LbP0iu9ztbrPn/nEN7ldTZtm23nSle/36vzob4W3FduWl zPpbS/vEp7ZupO0tfNOvWr6Ur32CRb1l5Rsf2gamcfNbc3vnA1jV3zf+5JHr+zqHFfqOnzGm i499vUse962P/mRJjXx379ny0l+9/Lnd6QKzX9O1vT7JMLhCizzmg7LkE7TOyz3zojfhyye5 yzHg07hJk7s9c7uP07iKs7vHmy6C+z+sa7S2W7t+2oadO77wI71Boz3G6rbJ4L7QozUzG7A7 4690I7EdYz30w68GpLE1K698677/2i0K+7BRA6/S8z4FizYq0z+EszLpSzYGI8DM277ngq7w yzv6msGSMr9Eizf808IC/1RCTrM8KgQwArRAR/tALMzBG4ysJ6RByCM0p9oGJFRD//s/KbRC S1s8uHhBcUNAMpQs+6u180O96Io1MQy+auvB93s9YKs750O3xzPC4SpC4jvDJbS8ErTD9tvD L8xDAaM9AdQ/6nM/9UNDeJO3FQxBVsw098M4zkO/Q2wtZvswW3zDL+zEM7zE0bM/TcTEU7y2 2MPC2QNF11C7nAu5wBM5rrO5rhO/lUMpxOsvnKurk+K5nmu5ZLQybBw3BAu7bBTHspu74Ko5 tpPGdGQ7bpy5rmPHniIqb2xGkpMta6TGjXO4UaQ67ijBfXyYfvTHhQHIgCTIgjTIg0RIDGmC hP88Jrj7Rn9bR0C7x4OjO6/zuwysOKO6uiYDtDFkSJFgwcvTRWOkNvgjyfgLMmIsxkn8yKVY xJQUQk3rv3TbxUxUtiOEv2RryQMLt/u7SXMzshOEPVBLQw6MRnWzkMqpGAi8OTYTrBEbwgkk K9ULvW17RW+Dyp3st57svw3EvqDUq1prQY+MRccDQqTUSh/jSjksxTXEMwBsS5u0QuJyMk1M SzlbyxDUQR58yy7cy0osQk+TybvcyjnsSUocykqExSeLwl3ky18kTJN4R4gEwX/zO2mkzKOM x4vrSJgbPItDPLSMzNEkzdI0zdNEzdRUzdVkzdZ0zdeEzdiUzdmkzdr/tM3bxM3c1M3d5M3e 9E3ZCIbfFM7hJM7iNM7jRM7kVE7pkIXldM7nhM7olE5zEoLptM7rxM7s1M7t5M7u9M7vBM/w lBhyIM+JIE9ySIjzVM9/OE+LaM/0LE+IQE+JaM/5lM/1hE/1RE/9LM/4vE/7ZE/9/M/1fM8B LdD0NM/+zM8ApU//rM+LANCIOFAJPVD+jNABNVD/zE8HFdANnVAAfU8C7c8ILdAHbdAGtdD9 jM8QXVEFpdD5ZFEQRVH8XFAVtc8PbdEOdY4LRdAehdEedU/6FFIJvU/zlM8jRVIZZU8jHVIg VVIeVVIklVIHldIpLdIgrQgeXVIr3VIoJVIg/93SLw3TKI1SMA3TM71RJh1TLx3SJxXTLr3S Ny3TM4XTMb1SEqWINK3THc1SNTVTP0XTQK1SJx3UP2XQNwVTPW1SRCXSMlVUDd1TQ0VQLWVT RNVSOo3UPOVSQu1TMm1SSP1RRj3UJNXUKg3VP3XURi3VQT1VQ73QSz0OSgVUWKVTGZ1TNdVT Nz3SW/VUQW1TI71VQtVVjdjPPgXUWsXSL21VMVVUO8XUYiXVTxVUWp1UZU1UZi3URW3WJa1U ScXTY6VW4pDVRcXUGS1RU71UHaXRANXQU33VdYXXPP1QdMVVTg1XZyVXVM3XQoXRCTXQf8VQ bF3QenXWcHXXDf3VVv+F1IS9Vn0VVXZdV36djnG1VIz4VnyNUzn1UWvl0lc1U4Ut1Yt9V4Gt UxBdWIzNVo992Gfd2FUt2V8lWWiV1pY1WZV9WWTlVlQdV2jt1Yp12XK1WeigWFa12E+NWImN 1n21VYJ11Z8FWKZdWpxNUH8F2llN1qQ11pb1VXPFWk6tVqnV2GXd1a912pw126cl2p/tVkld jm8NWrDFWbdl1GEVVRK12WDF07UFWa+Fz49VW6t923RlUlodVryFWam1W7+dVbH9Wpnd2rE9 W7i9WK1t2n1ljp5NW4ft2n5FWsqN3M9l2U0l20x13C591M413Lkl2dDNWpT1071FVrk1VdT/ rdvBndmP3dbZ9VnaVdx8vdfesNCBFd7gfdEM/U9uXVj+9NARFdB5Ld4MrU/lDd4SVVDqtVFt pVrrfVF49VeqDVh2dc8OrdAUBd/lRdjondyjLd9dVV7dZV/BRdcb5dB3ld/6RdHnfc0xEM/9 5d/+9d//BeAAFuBLelDvjdgClt7kzVEKNVfxnV+IxdF+leDpTeAJ1ln6Xd7rzdIH5lcX3V70 FVH6bd/vHWE51VHw7d4FPl55BVUXJd6pZd0atVsJrtUZJmEVNlEU1g359daY3duhfdtI3dZQ FdtUnVaObVjLzVXPtdrdTV6aVdaR9VXMDVyN7eHO1dYpJeLKHVXe/0XiJ75djNVVHsYN2fXd hl1b0c3YTF1dtjXiNEZZOI7hct3dyA3W3lVVyKVbys1bK+bbNuZirJ1ccu1jZjXjZz1kPubY O3aNoUVaNmVkxnXcLQbWsk3iJRZkzX3YKobQLGZkQr7WqN1jIRZSI/5jJK7dw7VkOoZcKx3l UkZlRbZX4XBkzW3hdg3SnU1SA25d23XX8W3Xk5VjTg5fdaXXot3eLybl0D1hfG3m3G1lpcXV Ws5W0cXkNcXSa+5YNu7iMu5lTR5V2F1lTGZcOobVHz3YI47mlP3mQW5i1z3ZtB1jH6VRlS3i bQ7jY2VnQg7i+LVmfF7jWWZddHbj34UMav/uZ0nu5Nbl2U6W48Z93MpN6Ha23Mxt5mqGWyjm Zntm1Xq26IUu24le2fSN11B2WlGuV4JG5ttI5NJdZr0d6RNl5dw9ZzhN3XyG6Tke5JZO4nfG Vko+YzE+XJHN4l52aXGeaZxW4xVVXQYeaJt2WYN+jNP957713EmuaI6OZXcuaqItZLZ1X2LW acWlUqOGZavm5iluY3FuVq6+ZEPO3Kj+aIct66Z+3Duu6zKeX+7F5RgNYb5m4VKuYPsVXrmG XghmXoRFZAeu2cPG3xFG4HTda/TdZfWF2BX2UOMtUhAGZhbma1u9ZQjVXhnWYFJNYZIG4x72 3gFm7dZ27deG7dj/lu3Zpm3grWDoPW38pOwGPtoXvuxiNl3Gtux6tmFWLh9ciBBKPmStftSR 7Qde1Vq8jtN5rlo1dl3f3GmwtmusRs/n3gh3JuaapuhuhubezO60pt2l9W7jzuh+ZuKkZljr xm7eVuyrFeicfe7VxmNwTmZ9pmuvlerZPO9y5t0tXm/CDWoTBuqYHupTnm+fvde7heL1zgjw fmfxPmmT1u7cHPDvhtqbrfAEn+tvfmSZZm8OB+WMtuXp3m8sBuK4xnB4Ts7RRuzhDubSnuAS xt/v9WzHLuypJWz53hhFqO0iN/IjR/IkV/IlZ/Im540YveEgR+weR+sazeD7Ld8Kderj//Xt K+fxp+3yTQbsLHdhHTdZ3r7xv47n+g7tD05s0ubyf2ABIF/jFM1rDqHiuO5ptYbZBe/p817k /xbqD8do+N3aX9ZoPV9mNN5kQGbu3m1uw2ZmQNYQqt7qCx9cnmbosN3yFvfpFd9w0OVbS1fx Sdb06g5kes7qFB/0pgbVK/6QdL70oOboPTb0OA7UOaVWC79dAhd1XL9udo5aJl7wmzZtBh9x BI/vRA91CsFqVZ5jNgZqaj52Pt9Tt67jC97rZIXSA67h8S7Yrg3umo3nR3dj+k7UW090C17Z DOF1Xo/la4f1kF10qsZ2RQ9aP6d0Xd9gcN1UfS/2c29w+B7xgP+edI2+dwx5dxEndg33b4ie 4bwu3V1neHUW7ezNdlYH8zzW6nwu8XXO9vIOYpAt5wCHkIW361Ne1nJ36NFt6YRv79fVbniX 3JCHdqbe92ru+CrXeGdO+asueRLJ95yHcSxu97uGdhUX8W5d+Z5H+i0H9IY/9LOed5q2b6JG a6b/eIzekNyGYSAXZhp31TU/9MlG7Yunc7DP8TZf3ynf8dIeXrMX7M/ebZ5n81cP7LjXYLif UcyeVMh28sAX/MEn/MI3/MNH/AH2awP24N9eXzO/6Mz2cjfHcTs38QyGctLubebl4B2Pcv1G U+FWYR83eUsi51WVeHmW9F539ave84P+/2PlRn0tTlBJ/+T0ZXSZb/ZNcu+4td14L3Uh/3Rf J2+Bj/aYjeaj/v1zf2Pgp/ZR6v1abnpU92Li73BzVmcvfWifd/loR+o8zv33nv5Viv7xTmT+ VlfQj3i/NtZc5eVVXtNztdORl/zZD/+Ndl7yf3jpJ+sML2rrB4h/AgWSG0jw4L+CBgcqTIhQ YcOFEQ1OlMiQ4sOMFjdCXLjRIUFyIhuOFHnRY0eMHleybOnyJcyYMmfSrGnzJs6cOnFWrHgS JVCQJ332DKoR5sSkCFtGLJiSpdOVPn821fj051CsEktqXaryI9idYseSLWv2LNq0SI2yBVlU 6NGDStledTn+N6vdrV4/voWK9WlUuHvddt1bd7DgwG3VMm7s+DHkyEwXf636l6pKy3QN+/0a N3HQuXcRY8abkKTUyp61Hhbste5UybJn065tm6JJhrmh7tbdOyTJkiaFTyUOnKvU3SN9E0/6 26lx5KeDFx8uHPjQ38d948ZNfbn3rdebF75t/jz69OrXs2/v/n3tBfDn069v/z7+/Pr38+/v /z+AAQo4IIEFGnggggkquCCDDTr4IIQRSjghhRVaeCGGGWq4IYcdevghiCGKOCKJJZp4Ioop qrgiiy26+CKMMco4I4012ngjjjnquCOPPfr4I5BBCjkkkUUaeSSSSSq5JJNNOvkdJJRRSjkl lVVaeSWWWWq5JZddevklmGGKOeaQAQEAIfkEAAwAAAAsAAAAAAACSAIHCP4A/wkcSLCgwYMI EypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4 c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo 06pdy7at27dw48qdq/UO3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5cuY M2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4c+veLdAP79/AgwsfTry48ePI kytfzry58+fQo0ufTr269evYs2vfzr279+/gw/6LH0++vPnz6NOrX6++BPv38OPLnz/fFP37 +PPr38+/v///AAYo4IAEFmjggQgmqOCCDDbo4IMQRijhhBRWaOGFGGao4YYcdujhhyCGKOKI JJZo4okopqjiiiy26OKLMMYo44w01mjjjTjmSNEyOvbo449ABinkkEQWaeSRSCap5JJMNunk k1BGKeWUFK5B5ZVYZqnlllwC1UOXYIYp5phklmnmXWOciVqaap7GZpulvQnnaHLOGVqddn6G Z56d7cnnn1SGA+ighBZq6KGIJqrooow26tApjkYq6aSUVmrppZhmqummnHbq6adQhgHqqKSW auqpqKaq6qqstuqqmv86vCrrrLSiJketuOaq66689urrr8AGK+ywxBZr7ISkHBtWssp+xWyz XZHyLLTUVpspDdZmq+22w0HB7bfghivuuOSWa+656Kar7rrstuvuu/DGK++89NZr77345qvv vvz26++/AAcs8MAEF2zwwQgnrPDCDDfs8MMQRyzxxBRX7Csi8N46FMYWe8Rxxxx9XNsxU4oM ckYmn3xRyipXhAjLLccsM1aSzGzzdQ/crPPOPPfs889ABy00c/wMbfTRSCet9NJMN+3001BH LfXUVFdt9dVYZ6311lx37fXXBcID9tiPOQC12U+j7bTanTYxGNtMOwA32XTXbffdeOet997+ fPftN1uycKuKVYE/LUvhf1t1ROKMN+7445BHLjmNEjAtweVLY5555ZtP7vnnoIcuunD1jG76 6ainrjp5Xazu+uuwx/7vFrLXbvvtuOeutyi69+7778AHL/zwxJtUR/HIJ688Rggs7/zz0Ecv /fQ6KkD99dhnr/323Hfv/ffghy/++OSXb/756Kev/vrst+/++/DHL//89Ndv//z4OJ1/0/sz 3f/9AAygAHFXjQF6RhwGTKACF8jABjrwgXpzBwQnSMEKWvCCGMygBjfIwQ568IMgDKEIR0jC EsboBiZMoQpXyMIWjvATLoyhDGdIw4DxqIY6aQUOd8jDHvrwh0CODKIQh0jEIhrxiEhMYk9g +DQmNs2JTIPi0qSYGHVQiopJw6ISt8jFLm5LBOdjBzsqxgIvmvGMq+EEGtfIxja68Y1wjKMc 50g3btDxjnjMox73yMc+HmSM8XOCH5WzhEEa0jCGOKQiF8nIRjrykY7JBwtlAMlKWlJe0GjR DC7JyU568pOgDKUoR0nKUnYvIAA7 ------=_NextPart_000_000A_01C6DF39.BF876810-- From orion@dm.mailpia.net Sun Sep 24 03:06:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRO4A-0007Na-7t for ccamp-archive@megatron.ietf.org; Sun, 24 Sep 2006 03:06:18 -0400 Received: from [125.187.32.212] (helo=m20.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRO48-0005tK-GC for ccamp-archive@megatron.ietf.org; Sun, 24 Sep 2006 03:06:18 -0400 Received: (qmail 22433 invoked by uid 0); 24 Sep 2006 16:04:37 +0900 Message-ID: <20060924070437.22432.qmail@m20.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: bisiness-kikaku Reply-to: delivery_rt Date: 2006-09-24 16:00:04 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060924123115_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From owner-ccamp@ops.ietf.org Mon Sep 25 03:36:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRl0k-0002g7-OQ for ccamp-archive@ietf.org; Mon, 25 Sep 2006 03:36:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRl0f-0007lc-DH for ccamp-archive@ietf.org; Mon, 25 Sep 2006 03:36:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GRksO-000OYj-8H for ccamp-data@psg.com; Mon, 25 Sep 2006 07:27:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GRksK-000OXb-VC for ccamp@ops.ietf.org; Mon, 25 Sep 2006 07:27:37 +0000 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 <0J6500DSH1L6G8@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 25 Sep 2006 15:46:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6500FBG1L5M4@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 25 Sep 2006 15:46:18 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J65004F10YKBV@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Mon, 25 Sep 2006 15:32:44 +0800 (CST) Date: Mon, 25 Sep 2006 15:27:29 +0800 From: Dan Li Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, To: Olufemi Komolafe , gjhhit@huawei.com Cc: ccamp Message-id: <00ee01c6e074$0ed0f040$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi Femi, Thanks for your valuable suggestion! The intention for this draft is clarify the procedures for multi-nodes restart, so five typical scenarios have been listed in the draft, I think most of the failed cases are covered by these five scenarios. As you have pointed out, these scenarios may be raised due to multiple nodes fail, or a subsequent control channel failure. Yes, you're right! It may be more generic to classify these scenarios, such as: "What should happen if a restarting node fails to get a RecoveryPath/Path message from its downstream/upstream neighbor?", but I think it may be more clear to address the specific cases in the draft at least during the initial stage. Any comments are very welcome! Best regards, Dan ----- Original Message ----- From: Olufemi Komolafe To: danli@huawei.com ; gjhhit@huawei.com Cc: ccamp Sent: Tuesday, September 19, 2006 8:45 PM Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Hi, While reading this draft it occurred to me that perhaps it might be more useful to approach this topic from the perspective of "What can go wrong during graceful restart, what are the consequences and how can it be fixed?" rather than focusing on the narrower topic of multiple simultaneous nodal faults. For example, Scenario 1 in the draft may be interpreted as "What should happen if a (non-ingress) restarting node fails to get a RecoveryPath message from its downstream neighbour?", Scenario 2 is "What should happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?" and so on. Whether each of these scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other reason (e.g. a subsequent control channel failure, restarting node being inundated with messages etc.) is, in my opinion, secondary. I think the key thing is to identify the potential problems and suggest appropriate remedial actions, where the authors think existing documentation is insufficient, rather than focusing on 5 different permutations of multiple node graceful restart. Regards, Femi From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Sent: 10 July 2006 04:04 To: danli@huawei.com; gjhhit@huawei.com Cc: ccamp Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Dear Authors, This is Deja-vu to me.... Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by the WG as addressing multiple node restart case is NOT a goal (suffers from the law of diminishing return). In other words the following statement in the ID- "[GR-EXT] also extends the Hello message to exchange information about the ability to support the RecoveryPath message. The examples and procedures in [GR-EXT] focus on the description of a single node restart when adjacent network nodes are operative. Although the procedures are equally applicable to multi-node restarts, no detailed explanation is provided." is not accurate. Please see section 4 on the earlier version of the [GR-EXT], http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt. Thanks Regards... Zafar From magagin-info@11109.to Mon Sep 25 04:25:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRlmJ-0005bm-WC for ccamp-archive@ietf.org; Mon, 25 Sep 2006 04:25:28 -0400 Received: from [58.61.39.96] (helo=pc33) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GRlmE-0008EJ-TZ for ccamp-archive@ietf.org; Mon, 25 Sep 2006 04:25:27 -0400 To: From: =?iso-2022-jp?B?TE9WRUxPVkUbJEI7dkwzNkkbKEI=?= Subject: =?iso-2022-jp?B?GyRCNDBBNEw1TkEkTk0lTkklNSUkJUgbKEI=?= MIME-Version: 1.0 Reply-To: Date: Mon, 25 Sep 2006 16:19:20 +0900 Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 $B!!(.(;(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B2006/09/23 $B(#(@(%(#(!(!($!!!!!!(.(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(/(B $B(;(0!!!C!@!?!C!!"!(,(4(B $B40A4L5NA$NM%NI%5%$%H(B $B!Z(B $B$*4+$a%^%,%8%s![(2(,"!!!(.(;(B $B!!!!!!(&(!(!(%!!!!!!(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0!!!!(#(@(%(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(;(0(B http://lovelove-real.com/puti/ $B@hF|$*OC$5$;$FD:$-$^$7$?L5NA%5%$%H$N>R2p$G$9!#(B $BAG?M$+$i!"%W%m$^$G@*$>$m$$$N$3$N%5%$%H!*(B $BL5NA$@$+$i$3$=0B?4$7$FMxMQ$G$-$kM%NI%5%$%H(B $B$G$9!#(B $B$+$+$kNA6b$O!"2<5-$H$J$C$F$$$^$9!#(B http://lovelove-real.com/puti/ $B!!(#"!%a!<%k"!!!!!40A4L5NA(B $B!!(&(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B!!(#"! To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyohou-kikaku Reply-to: delivery_rt Date: 2006-09-25 17:45:14 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060925154047_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From orion@dm.mailpia.net Tue Sep 26 04:55:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS8j1-00007a-Br for ccamp-archive@ietf.org; Tue, 26 Sep 2006 04:55:35 -0400 Received: from [125.187.32.159] (helo=m07.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS8iz-0005cX-LO for ccamp-archive@ietf.org; Tue, 26 Sep 2006 04:55:35 -0400 Received: (qmail 22963 invoked by uid 0); 26 Sep 2006 17:31:08 +0900 Message-ID: <20060926083108.22962.qmail@m07.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdEYzduNWsbKEI0Mw==?= =?ISO-2022-JP?B?GyRCS3wxX0pdPlpDZiF5OWI8fUZ+JCo7RTt2PnBKcyVhITwlayVeGyhC?= =?ISO-2022-JP?B?GyRCJSwlOCVzIXkbKEI=?= From: job-net.jp Reply-to: delivery_rt Date: 2006-09-26 17:27:03 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060926172508_cbrd Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 $B"#"#"#"#"#9b3[F|J'$$!#B(!"F|<}(B4$BK|1_0J>e"#"#"#"#"#(B $B(.(,(,(,(,(,(,(,!|Jg=8?M?t8BDj!|(,(,(,(,(,(,(,(/(B $B!!(B $B!!(B $B!!!!!!!!!!!!%W%l%$%9%?%C%U(B $B!!!!!!!!!!6HL33HBg$K$D$-6[5^BgJg=8(B!! $B(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B!!!A2T$27n<}(B100$BK|1_0J>e(B!!$BL\;X$;%Q%A%s%38fEB!A!!!!(B $B!!!!!!!!!!"!5.J}$O:#$N@83h$KK~B-$G$9$+!)"!(B $B!!!!"-L4$r8=@\$*Ld$$9g$o$;"-(B $B!!(Bhttp://softwave.main.jp/$B!!!!!!!!!!!!(B0120-197-028 $B!!!!(B $B"#%=%U%H%&%(!<%V%W%l%$%9%?%C%U(B $B!!@h7n$N7n<}Nc(B $B#1#7#4K|(B $B2TF/F|?t#2#1F|(B $B!{0&CN8):_=;(B:$B#3#9:P!!E-LZ$5$s(B $B!!;d$O!"@N$+$i%9%m%C%H$,9%$-$GIi$1$,B3$$$F$$$k$H(B $B$-$b$d$jB3$1$F$$$^$7$?!#$I$&$K$+>!$F$J$$$+$HG:$s(B $B$G$$$?$"$kF|9-9p$G%=%U%H%&%(!<%V$N$3$H$rCN$j!"(B $B:G=i$OH>?.H>5?$GLd$$9g$o$;$r$7$^$7$?!#$7$+$7!"%9(B $B%?%C%U$NJ}$N?F@Z$JBP1~!"$o$+$j$d$9$$@bL@$r$J46A[(B $B$G$9!#(B $B!!$=$l$+$i$OIi$1$k$3$H$bL5$/!"Bg9%$-$J%9%m%C%H$r(B $B$7$J$,$iCy6b$bCy$^$k$H$$$&KhF|$G$9!#$3$l$b%=%U%H(B $B%&%(!<%VMM$N$*$+$2$G$9!#$3$l$+$i$b59$7$/$*4j$$$7(B $B$^$9!#(B $B"!%=%U%H%&%(!<%V>pJs4IM}It!!>.NS$+$i(B $B!!E-LZ$5$s!"$$$D$b$J$,$i$*$a$G$H$&$4$6$$$^$9!#M_(B $B$7$,$C$F$$$?#B#M#W#7%7%j!<%:$G$9$,!"$b$7$+$7$F!"(B $B$=$m$=$mGc$($k$N$G$O(B?? $B"-i,i/?'$N?M@8$O$3$A$i"-(B http://softwave.main.jp/ $B"#%7%c%$%K%s%0%9%?!<%W%l%$%9%?%C%U(B $B!!@h7n$N7n<}Nc(B $B#8#6K|(B $B2TF/F|?t#9F|(B $B!{?@F`@n8):_=;(B:$B#2#4:P!!6\Bt$5$s!JpJs4IM}It!!>>Eh$+$i(B $B!!6\Bt$5$s!"@h7n$b%8%c%s%8%c%s%P%j%P%j(B!!$B$*$a$G$H(B $B$&$4$6$$$^$9!##2?ML\$N$*;R$5$s$r?H$4$b$C$F$$$k$+(B $B$i%R%-$,6/$+$C$?$j$7$F(B!? --------------------$B1~Jg;q3J(B-------------------- $B"#CK=w(B $BG/Np(B $B7P83ITLd(B $B"#=i?4e5-$N%W%l%$%9%?%C%U$N3'$5$s$N(B $B$*@<$G$bH=$k$H$*$j!"0l@Z!"Fq$7$$$3$H$d!"0cK!@-$O(B $B$"$j$^$;$s!#$`$7$me?4!W(B $B$^$:$O"-$r%/%j%C%/!*!*(B http://softwave.main.jp/ $B!!3t<02q) id 1GSFBL-0005kl-QS for ccamp-data@psg.com; Tue, 26 Sep 2006 15:49:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.1 Received: from [64.233.182.190] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GSFBK-0005kE-Fe for ccamp@ops.ietf.org; Tue, 26 Sep 2006 15:49:14 +0000 Received: by nf-out-0910.google.com with SMTP id k27so292496nfc for ; Tue, 26 Sep 2006 08:49:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZeuzTK0fKQIXWbe/ybDW3J6NpzJLR9D9z0PCUVmX04B7+TVPJoTrTEZLpmzAA30bAYQ2F10C2p1PzLYgEhE2nJMKZ4Zih/LMrFF4l0q95sJ5ik8FVxpSdOl83a4ZABfLxyW44JAWfDg5K+NfLVWNhq5F2GB/HsON7pVmNg+TvxU= Received: by 10.49.90.4 with SMTP id s4mr1183823nfl; Tue, 26 Sep 2006 08:49:12 -0700 (PDT) Received: by 10.48.204.20 with HTTP; Tue, 26 Sep 2006 08:49:12 -0700 (PDT) Message-ID: <406e32c00609260849j3ab0d64o46f133b1905387be@mail.gmail.com> Date: Tue, 26 Sep 2006 11:49:12 -0400 From: "Peng He" To: ccamp@ops.ietf.org Subject: A New I.D.: A Novel Framework for Inter-area MPLS Optimal Routing MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Dear all, We just published a new Internet Draft: A Novel Framework for Inter-area MPLS Optimal Routing (http://www.ietf.org/internet-drafts/draft-he-ccamp-optimal-routing-00.txt). Our general motive is to try to build up a framework for MPLS (even GMPLS possibly) inter-area TE, which can satisfy the inter-area TE requirements defined in RFC 4105. Please note that our framework in the draft can achieve inter-area MPLS optimal routing with good backward compatibility; and, it is different with PCE-based approaches. Any comments are very welcomed! Best Regards, Peng He PS: The following is publishing information of the draft: A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Novel Framework for Inter-area MPLS Optimal Routing > Author(s) : P. He, G. Bochmann > Filename : draft-he-ccamp-optimal-routing-00.txt > Pages : 16 > Date : 2006-9-25 > > We propose a novel framework for inter-area MPLS optimal routing. The > key to our proposal lies in deploying an overlaid star optical > network in the OSPF backbone area and introducing the concept of > ""virtual area border routers"" (v-ABRs). Compared with other > proposals, our framework can provide globally optimized inter-area > routing and has very good compatibility to existing traditional > IP/MPLS routers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-he-ccamp-optimal-routing-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-he-ccamp-optimal-routing-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-he-ccamp-optimal-routing-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. > From owner-ccamp@ops.ietf.org Tue Sep 26 12:59:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSGHB-00079E-P9 for ccamp-archive@ietf.org; Tue, 26 Sep 2006 12:59:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSGHA-0002Rl-Bk for ccamp-archive@ietf.org; Tue, 26 Sep 2006 12:59:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GSG9k-000CcH-QJ for ccamp-data@psg.com; Tue, 26 Sep 2006 16:51:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GSG9h-000Cbm-8i; Tue, 26 Sep 2006 16:51:37 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k8QGp0Rw005516; Tue, 26 Sep 2006 18:51:00 +0200 In-Reply-To: <00ee01c6e074$0ed0f040$d04c460a@china.huawei.com> To: Dan Li Cc: ccamp , Olufemi Komolafe , gjhhit@huawei.com, owner-ccamp@ops.ietf.org Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 26 Sep 2006 18:50:54 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 09/26/2006 18:50:57, Serialize complete at 09/26/2006 18:50:57 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 hi dan yes i have a very practical issue - the document would then deal with remedial to remedial - ... but do we have any feedback on initial remedials ? thanks, - d. Dan Li Sent by: owner-ccamp@ops.ietf.org 25/09/2006 09:27 To: Olufemi Komolafe , gjhhit@huawei.com cc: ccamp Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Hi Femi, Thanks for your valuable suggestion! The intention for this draft is clarify the procedures for multi-nodes restart, so five typical scenarios have been listed in the draft, I think most of the failed cases are covered by these five scenarios. As you have pointed out, these scenarios may be raised due to multiple nodes fail, or a subsequent control channel failure. Yes, you're right! It may be more generic to classify these scenarios, such as: "What should happen if a restarting node fails to get a RecoveryPath/Path message from its downstream/upstream neighbor?", but I think it may be more clear to address the specific cases in the draft at least during the initial stage. Any comments are very welcome! Best regards, Dan ----- Original Message ----- From: Olufemi Komolafe To: danli@huawei.com ; gjhhit@huawei.com Cc: ccamp Sent: Tuesday, September 19, 2006 8:45 PM Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Hi, While reading this draft it occurred to me that perhaps it might be more useful to approach this topic from the perspective of "What can go wrong during graceful restart, what are the consequences and how can it be fixed?" rather than focusing on the narrower topic of multiple simultaneous nodal faults. For example, Scenario 1 in the draft may be interpreted as "What should happen if a (non-ingress) restarting node fails to get a RecoveryPath message from its downstream neighbour?", Scenario 2 is "What should happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?" and so on. Whether each of these scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other reason (e.g. a subsequent control channel failure, restarting node being inundated with messages etc.) is, in my opinion, secondary. I think the key thing is to identify the potential problems and suggest appropriate remedial actions, where the authors think existing documentation is insufficient, rather than focusing on 5 different permutations of multiple node graceful restart. Regards, Femi From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Sent: 10 July 2006 04:04 To: danli@huawei.com; gjhhit@huawei.com Cc: ccamp Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Dear Authors, This is Deja-vu to me.... Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by the WG as addressing multiple node restart case is NOT a goal (suffers from the law of diminishing return). In other words the following statement in the ID- "[GR-EXT] also extends the Hello message to exchange information about the ability to support the RecoveryPath message. The examples and procedures in [GR-EXT] focus on the description of a single node restart when adjacent network nodes are operative. Although the procedures are equally applicable to multi-node restarts, no detailed explanation is provided." is not accurate. Please see section 4 on the earlier version of the [GR-EXT], http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt . Thanks Regards... Zafar From owner-ccamp@ops.ietf.org Tue Sep 26 19:21:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSMF9-0004FN-Co for ccamp-archive@ietf.org; Tue, 26 Sep 2006 19:21:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSMEu-0000ec-UL for ccamp-archive@ietf.org; Tue, 26 Sep 2006 19:21:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GSM8j-000NoV-4t for ccamp-data@psg.com; Tue, 26 Sep 2006 23:15:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GSM8i-000No6-2O for ccamp@ops.ietf.org; Tue, 26 Sep 2006 23:15:00 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k8QNEv0L024785; Tue, 26 Sep 2006 16:14:57 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k8QNEvVL024784; Tue, 26 Sep 2006 16:14:57 -0700 Date: Tue, 26 Sep 2006 16:14:57 -0700 Message-Id: <200609262314.k8QNEvVL024784@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4631 on Link Management Protocol (LMP) Management Information Base (MIB) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 A new Request for Comments is now available in online RFC libraries. RFC 4631 Title: Link Management Protocol (LMP) Management Information Base (MIB) Author: M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel Status: Standards Track Date: September 2006 Mailbox: dubuc.consulting@sympatico.ca, tnadeau@cisco.com, jplang@ieee.org, emcginnis@hammerheadsystems.com, adrian@olddog.co.uk Pages: 83 Characters: 152560 Obsoletes: RFC4327 See-Also: I-D Tag: draft-ietf-ccamp-rfc4327bis-01.txt URL: http://www.rfc-editor.org/rfc/rfc4631.txt This document provides minor corrections to and obsoletes RFC 4327. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From logosyfuentes@pilu.com Wed Sep 27 02:41:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GST6Y-0003ha-Nu for ccamp-archive@ietf.org; Wed, 27 Sep 2006 02:41:14 -0400 Received: from [200.49.157.235] (helo=pilu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GST6X-0002us-D3 for ccamp-archive@ietf.org; Wed, 27 Sep 2006 02:41:14 -0400 Received: from ixgqg by pilu.com (MDaemon.PRO.v8.0.1.R) with ESMTP id md50004553237.msg for ; Wed, 27 Sep 2006 02:07:28 -0300 From: "Fuentos y Logos promo" Subject: 20.000 FUENTES Y LOGOS A 35 PESOS - ENVIO GRATIS --- Promo Especial --- To: ccamp-archive@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: logosyfuentes@pilu.com Date: Wed, 27 Sep 2006 02:07:31 -0300 X-Priority: 3 X-Authenticated-Sender: logosyfuentes@pilu.com X-Spam-Processed: pilu.com, Wed, 27 Sep 2006 02:07:28 -0300 (not processed: message from valid local sender) X-MDRemoteIP: 201.254.107.22 X-Return-Path: logosyfuentes@pilu.com X-MDaemon-Deliver-To: ccamp-archive@ietf.org X-MDAV-Processed: pilu.com, Wed, 27 Sep 2006 02:13:43 -0300 X-Spam-Score: 1.7 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab MAS DE 20.000 FUENTES Y LOGOS DE UTILIDAD PARA DARLE PARA SU NEGOCIO O EMPRESA TOTALMENTE EDITABLES LA MEJOR IMAGEN A TU NEGOCIO O TRABAJO TODAS LAS FUENTES ACTUALIZADA 2006 EXCLUSIVA DE FUENTES Y LOGOS EL CD A SOLO 35.00 PESOS ENVIO GRATIS DENTRO DE CAPITAL FEDERAL EL ENVIO ES GRATIS SOLO DENTRO DE CAP.FED EL ENVIO FUERA DE CAP.FED SALE DE 15 A 20 PESOS NUESTRO SITIO WEB: WWW.DEFUENTES.COM CONTACTO A: contacto@defuentes.com ----------------------------------------------------------------------------------------------------------------------------------------- SI DESEA SALIR DE ESTA LISTA RESPONDA EL MENSAJE CON EL SUJETO(SUBJET) REMOVER Fuentos y Logos promo From orion@dm.mailpia.net Wed Sep 27 07:53:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSXyR-00034S-By for ccamp-archive@ietf.org; Wed, 27 Sep 2006 07:53:11 -0400 Received: from [125.187.32.166] (helo=m09.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSXyP-0005tl-Ng for ccamp-archive@ietf.org; Wed, 27 Sep 2006 07:53:11 -0400 Received: (qmail 1678 invoked by uid 0); 27 Sep 2006 20:47:31 +0900 Message-ID: <20060927114731.1677.qmail@m09.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOWI8fUZ+JSIlayVQJSQbKEI=?= =?ISO-2022-JP?B?GyRCJUg+cEpzJWEhPCVrJV4lLCU4JXMbKEI=?= From: "µá¿Í¾ðÊó¥Õ¥í¥àA" Reply-to: delivery_rt Date: 2006-09-27 20:41:01 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060927194932_cbrd Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab http://777.secret.jp $B!!(B 0120-197-028 $B%b%K%?!<$N;v$J$i6H3&%H%C%W$N%=%U%H%&%'!<%V!*!*(B $B40A4L5NA!*!*(B $B6[5^BgJg=8!*!*(B $B%[!<%ke$,$C$F$$$^$9!#(B $B$=$s$J6H3&$NGH$Ku$G$9!#$=$3$GEvC(B $B$9$Y$/A49q5,LO$G$NJg=8$K;j$j$^$7$?!#(B $B"#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,"#(B $B!z%7%9%F%`!z(B $B#1!"8GDjJ]>Z5k%7%9%F%`!"0BDj$7$?<};Y$N0Y$K8GDj5k!\Jb9g@)EY$G$9!*(B $B#2!"73;q6bDs6!%7%9%F%`!"73;q6b$OEv@\%5%]!<%H%7%9%F%`!"EveCK=wITLd!!!!L$7P83Z3[!K!\Jb9g(B $B3hF0>l=j!'A49q3FCO$N%[!<%k(B $B;~4V!'40A4<+M3@)!J(B10:00$B!A(B23:00$B!!=5(B1$BF|!A#O#K!*!K(B $BF|J'$$2DG=!!"($4AjCL2<$5$$!*(B $B%a!<%k$G$N$*?=$79~$_$O!!!!!!$*EEOC$G$N$*?=$79~$_(B $B"-"-"-"-"-"-"-"-!!!!!!(B $B"-"-"-"-"-"-"-"-"-"-(B http://777.secret.jp$B!!!!!!!!!!(B0120-197-028 $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B2q!!!!3t<02q6H0w?t!!!!C1BN#3#6L>!?4XO"2q!J#2#0#0#6G/#97n8=:_!K(B $B;v6H0FFb(B $B%"%_%e!<%:%a%s%H;v6H$K$h$k6HL3A4HL(B $B$J$i$S$K%3%s%5%k%F%#%s%06HL3(B $B%G!<%?2r@O6HL3(B http://777.secret.jp $B"(%a!<%k$,ITMW$JJ}$O(B soft_wave@hotmail.co.jp $B$^$G$4JVAw2<$5$$$^$;!#(B From apache@19magic.info Wed Sep 27 18:38:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSi3A-0003kp-5q for ccamp-archive@ietf.org; Wed, 27 Sep 2006 18:38:44 -0400 Received: from [203.82.22.21] (helo=19magic.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GShx7-0000ve-K6 for ccamp-archive@ietf.org; Wed, 27 Sep 2006 18:32:33 -0400 Received: by 19magic.info (Postfix, from userid 48) id 518671CCCF3; Wed, 27 Sep 2006 18:32:08 -0400 (EDT) From: info@19magic.info Subject: =?ISO-2022-JP?B?GyRCJGIkJiQ5JDAbKEI=?= 10 =?ISO-2022-JP?B?GyRCN24bKEI=?= =?ISO-2022-JP?B?GyRCISo6I0cvJE44ZUg+JEtFUiQxJGshKiEqGyhC?= To: ccamp-archive@ietf.org Message-Id: <20060927223208.518671CCCF3@19magic.info> Date: Wed, 27 Sep 2006 18:32:08 -0400 (EDT) X-Spam-Score: 4.2 (++++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 $B(.!?!@(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B>>>>$B(!(!(!(!"*!}(!(B $B!?L5!!!@!!("(B $B!!!!!!!!!@(B $B!@!!!!!!!@("(B $B!z$`$j$g$&$`$j$g$&$`$j$g$&$G$9$h!A!z!!!!!!!!(B $B(-(B $B(-!@!!NA!?("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(-(B $B(1(,!@!?(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B=w@-;oB??t9-9p7G:\!*!*(B $B=w@-$N2q0w$,=8$^$j$9$.$FCK@-$N?t$,ITB-$7$F$$$k>u67$,B3$$$F$$$^$9!*!*(B $B%5%$%H@_N)0JMh!"#3G/H>L5NA3+J|$H$J$C$F$*$j$^$9!#(B $BD>%a$b4JC18r49$K$G$-$^$9!*!*(B $B$3$l$+$i=y!9$KH)4($/$J$C$F$$$/5(@a!#(B $B$=$s$J$H$-$K$b$C$H4($/2a$4$5$J$$$?$a$K$b(B $B=P2q$$$N%A%c%s%9$rL5BL$K$7$F$O$$$1$^$;$s!*(B $B%]%$%s%H$O0J2<$NDL$j$G$9!*(B $B!y!!%a!<%kAw?.!!!!!!(B 0pt $B!y!!%a!<%k) id 1GStdB-000LF1-J3 for ccamp-data@psg.com; Thu, 28 Sep 2006 11:00:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GStdA-000LEo-4p for ccamp@ops.ietf.org; Thu, 28 Sep 2006 11:00:40 +0000 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 1GStdE-0006mB-00 for ccamp@ops.ietf.org; Thu, 28 Sep 2006 12:00:44 +0100 Received: from your029b8cecfe ([217.158.132.175] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 12:00:32 +0100 Message-ID: <027a01c6e2ed$4acaa980$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: New Liaison Statement, "Response to liaisons on G.8110.1" Date: Thu, 28 Sep 2006 11:59:41 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 28 Sep 2006 11:00:33.0066 (UTC) FILETIME=[5197B0A0:01C6E2ED] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi, Please see the liaison tracker for a response from the ITU-T on T-MPLS. This liaison includes some text on the motivations for T-MPLS and starts to build a picture of what the T-MPLS control plane might be expected to do. Adrian ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: ; ; ; ; ; Cc: ; ; ; ; ; ; ; ; ; ; ; ; Sent: Wednesday, September 27, 2006 4:35 PM Subject: New Liaison Statement, "Response to liaisons on G.8110.1" > > Title: Response to liaisons on G.8110.1 > Submission Date: 2006-09-27 > URL of the IETF Web page: > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=265 > Please reply by 2006-10-30 > > From: Greg Jones(ITU-T SG 15) > To: IETF(loa@pi.se, sob@harvard.edu, stbryant@cisco.com, > adrian@olddog.co.uk, danny@arbor.net, swallow@cisco.com) > Cc: iesg@ietf.org > iab@ietf.org > sjtrowbridge@lucent.com > betts01@nortel.com > maeda@ansl.ntt.co.jp > ghani.abbas@marconi.com > houlin.zhao@itu.int > ccamp@ops.ietf.org > mpls@lists.ietf.org > pwe3@ietf.org > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > Technical Contact: betts01@nortel.com > Purpose: For comment > Body: > Attachment(s): > Response to liaisons on G.8110.1 - body text > (https://datatracker.ietf.org/documents/LIAISON/file367.doc) From orion@dm.mailpia.net Fri Sep 29 18:02:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQRK-0001cn-0v for ccamp-archive@megatron.ietf.org; Fri, 29 Sep 2006 18:02:38 -0400 Received: from [125.187.32.156] (helo=m06.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQRI-0005y0-C2 for ccamp-archive@megatron.ietf.org; Fri, 29 Sep 2006 18:02:38 -0400 Received: (qmail 2734 invoked by uid 0); 30 Sep 2006 07:02:27 +0900 Message-ID: <20060929220227.2733.qmail@m06.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyouhoubisiness Reply-to: delivery_rt Date: 2006-09-30 07:02:14 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060929181718_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From orion@dm.mailpia.net Fri Sep 29 18:08:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQWz-00059X-2y for ccamp-archive@ietf.org; Fri, 29 Sep 2006 18:08:29 -0400 Received: from [125.187.32.183] (helo=m13.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQWx-0006tt-Eg for ccamp-archive@ietf.org; Fri, 29 Sep 2006 18:08:29 -0400 Received: (qmail 28287 invoked by uid 0); 30 Sep 2006 07:04:01 +0900 Message-ID: <20060929220401.28285.qmail@m13.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdDOyRHMi9LfEQ5PFQbKEI=?= =?ISO-2022-JP?B?GyRCJEskSiRrSn1LISEqISohKhsoQg==?= From: jyouhoubisiness Reply-to: delivery_rt Date: 2006-09-30 07:00:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060929181718_cbao Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 $B"$"'"$"'3$$rD/$a$J$,$i(B200$BK|1_2T$$$@CK$,9pGr!*!*"'"$"'"$"'"$"'"$"'"$"'"$(B $B!ZG/<}(B1000$BK|1_$r>pJs5/6H$G%i%/%i%/LY$1$k%R%1%D!*![(B $B7n(B15$BK|$N%U%j!<%?!<$,!"$?$C$?(B90$BK|1_$G7n(B200$BK|1_0J>e!"2T$2$?HkL)$H$O!)(B $B"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$"'"$(B $B$_$J$5$s!"$O$8$a$^$7$F!*(B $B>pJs5/6H$G2T$02q$N0f>e$H?=$7$^$9!#(B $B$b$7!"$"$J$?$,!">pJsHNGd%S%8%M%9$,@.8y$7$?$$$N$G$"$l$P!"3$$rD/$a$F$$$F$b!"<+F0E*$K6d9T8}:B$K$*6b$,?6$j9~$^$l$F$/$k!"<+F0HNGd5!$N$h$&$J;EAH$_$r:n$j$?$$$N$G$"$l$P!"(B $B$3$N%a!<%k$OI,8+$G$9!#(B $B!!$J$<$J$i!"(B1$BG/A0$^$G!"7n<}(B12$BK|1_$N%U%j!<%?!<$@$C$?;d$,!"7n<}(B200$BK|1_0J>e$r%i%/%K2T$.=P$9$3$H$,=PMh$?!*<:GT$7$h$&$,$J$$>pJs5/6H$N%N%&%O%&$,%.%C%7%j$H5M$a9~$s$G$"$k$+$i$G$9!#(B $B!!$3$3$G>/$7$@$1L@$+$9%N%&%O%&$N$[$s$N0lIt$r>R2p$7$^$9$H!&!&!&!&(B $B!|(B 98$B!s0J>e$N?M$,?.$89~$s$G$$$k4V0c$$$@$i$1$N!">pJs5/6H%;%*%j!<(B $B!|(B $B>pJs5/6H$G%,%C%D%j2T$0$?$a$N?4F@$H$O!)(B $B!|(B $B7n<}(B200$BK|1_0J>e2T$.=P$9>pJs%3%s%F%s%D$H$O!)(B $B!|(B $B>pJs5/6H$G@.8y$9$k$?$a$N!"$=$N=Q$H$O!)(B $B!!Ey!9!"Hs>o$K%Q%o%U%k$GB(8z@-$N$"$k%N%&%O%&$r8x3+$7$F$$$-$^$9!#(B $B@hF|$NOC$G$9!#4dtEZ%vIM$H$$$&!"%-%l%$$J3$4_$K(B7$BF|4V!";E;v$r$[$C$?$i$+$7$F!"2HB2N99T$K9T$C$F$-$?$N$G$9$,!"5"$C$F$-$F%S%C%/%j$G$9!*(B $B!!(B7$BF|4V!"%\!<$C$H!"3$$rD/$a$F$$$?$@$1$J$N$K!"2?$H!*(B80$BK|1_0J>e$b!"?6$j9~$^$l$F$$$k$8$c$"$j$^$;$s$+!*!*!*(B $B!!!VK\?M$,3$$rD/$a$F$$$k!#$=$N4V$K$b%[!<%`%Z!<%87/$,%P%s%P%s2T$$$G$/$l$k!W(B $B$I$&$G$9!)$3$s$J@83h$b$$$$$G$7$g$&!#(B $B!!$J$<;d$,!"C;4|4V$G$3$3$^$G2T$2$?$N$+!)$I$s$J>pJs$rHNGd$7$F$$$?$N$+!)(B $B$=$NHkL)$O(B $B"-"-"-"-"-"-"-"-"-"-"-(B http://rakurakudesu.web.fc2.com/ $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B $B!|H/9TpJs4k2h(B $B!|(BWeb$B%5%$%H!!!!!!!!!!(Bhttp://rakurakudesu.web.fc2.com/ $B!|$*Ld$$9g$o$;!!!!(B info_jyohou5@yahoo.co.jp $B!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B From owner-ccamp@ops.ietf.org Sat Sep 30 01:49:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTXik-0008TI-9m for ccamp-archive@ietf.org; Sat, 30 Sep 2006 01:49:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTXid-0005kd-ND for ccamp-archive@ietf.org; Sat, 30 Sep 2006 01:49:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GTXc1-000C6Q-68 for ccamp-data@psg.com; Sat, 30 Sep 2006 05:42:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GTXbz-000C69-5N; Sat, 30 Sep 2006 05:42:07 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6E007WW5OPDC@szxga03-in.huawei.com>; Sat, 30 Sep 2006 13:53:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6E004VJ5OOXR@szxga03-in.huawei.com>; Sat, 30 Sep 2006 13:53:13 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6E004BI5F2J2@szxml03-in.huawei.com>; Sat, 30 Sep 2006 13:47:27 +0800 (CST) Date: Sat, 30 Sep 2006 13:42:01 +0800 From: Dan Li Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp , Olufemi Komolafe , gjhhit@huawei.com, owner-ccamp@ops.ietf.org Message-id: <00fa01c6e453$271390d0$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Hi Dimitri, There is nothing wrong with the GR draft, the mechanism described in that draft doesn't need any remedial patch, and it is applied to this draft. The reason we started working on this draft is try to clarify the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered depending on the order in which the nodes restart. Thanks, Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "Olufemi Komolafe" ; ; Sent: Wednesday, September 27, 2006 12:50 AM Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > hi dan > > yes i have a very practical issue - the document would then deal with > remedial to remedial - ... but do we have any feedback on initial > remedials ? > > thanks, > - d. > > > > > > Dan Li > Sent by: owner-ccamp@ops.ietf.org > 25/09/2006 09:27 > > To: Olufemi Komolafe , gjhhit@huawei.com > cc: ccamp > Subject: Re: Comments on > draft-li-ccamp-multinodes-gr-proc-00.txt, > > > Hi Femi, > > Thanks for your valuable suggestion! > > The intention for this draft is clarify the procedures for multi-nodes > restart, so five typical scenarios have been listed in the draft, I think > most of the failed cases are covered by these five scenarios. As you have > pointed out, these scenarios may be raised due to multiple nodes fail, or > a subsequent control channel failure. Yes, you're right! It may be more > generic to classify these scenarios, such as: "What should happen if a > restarting node fails to get a RecoveryPath/Path message from its > downstream/upstream neighbor?", but I think it may be more clear to > address the specific cases in the draft at least during the initial stage. > > Any comments are very welcome! > > Best regards, > > Dan > > > > > ----- Original Message ----- > From: Olufemi Komolafe > To: danli@huawei.com ; gjhhit@huawei.com > Cc: ccamp > Sent: Tuesday, September 19, 2006 8:45 PM > Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > > Hi, > > While reading this draft it occurred to me that perhaps it might be more > useful to approach this topic from the perspective of "What can go wrong > during graceful restart, what are the consequences and how can it be > fixed?" rather than focusing on the narrower topic of multiple > simultaneous nodal faults. > > For example, Scenario 1 in the draft may be interpreted as "What should > happen if a (non-ingress) restarting node fails to get a RecoveryPath > message from its downstream neighbour?", Scenario 2 is "What should happen > if a (non-ingress) restarting node fails to get a Path message from its > upstream neighbour?" and so on. Whether each of these scenarios arises > due to multiple simultaneous nodal faults (as in the draft) or any other > reason (e.g. a subsequent control channel failure, restarting node being > inundated with messages etc.) is, in my opinion, secondary. I think the > key thing is to identify the potential problems and suggest appropriate > remedial actions, where the authors think existing documentation is > insufficient, rather than focusing on 5 different permutations of multiple > node graceful restart. > > Regards, > Femi > > > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Zafar Ali (zali) > Sent: 10 July 2006 04:04 > To: danli@huawei.com; gjhhit@huawei.com > Cc: ccamp > Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > Dear Authors, > > This is Deja-vu to me.... > > Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on > multiple node restart case and was rejected by the WG as addressing > multiple node restart case is NOT a goal (suffers from the law of > diminishing return). In other words the following statement in the ID- > > "[GR-EXT] also extends the Hello message to exchange information about > the ability to support the RecoveryPath message. > The examples and procedures in [GR-EXT] focus on the description of a > single node restart when adjacent network nodes are operative. > Although the procedures are equally applicable to multi-node restarts, > no detailed explanation is provided." > > is not accurate. Please see section 4 on the earlier version of the > [GR-EXT], > http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt > . > > Thanks > > Regards... Zafar > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 30 Sep 2006 05:44:05 +0000 Date: Sat, 30 Sep 2006 13:42:01 +0800 From: Dan Li Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp , Olufemi Komolafe , gjhhit@huawei.com, owner-ccamp@ops.ietf.org Message-id: <00fa01c6e453$271390d0$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Dimitri, There is nothing wrong with the GR draft, the mechanism described in that draft doesn't need any remedial patch, and it is applied to this draft. The reason we started working on this draft is try to clarify the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered depending on the order in which the nodes restart. Thanks, Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "Olufemi Komolafe" ; ; Sent: Wednesday, September 27, 2006 12:50 AM Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > hi dan > > yes i have a very practical issue - the document would then deal with > remedial to remedial - ... but do we have any feedback on initial > remedials ? > > thanks, > - d. > > > > > > Dan Li > Sent by: owner-ccamp@ops.ietf.org > 25/09/2006 09:27 > > To: Olufemi Komolafe , gjhhit@huawei.com > cc: ccamp > Subject: Re: Comments on > draft-li-ccamp-multinodes-gr-proc-00.txt, > > > Hi Femi, > > Thanks for your valuable suggestion! > > The intention for this draft is clarify the procedures for multi-nodes > restart, so five typical scenarios have been listed in the draft, I think > most of the failed cases are covered by these five scenarios. As you have > pointed out, these scenarios may be raised due to multiple nodes fail, or > a subsequent control channel failure. Yes, you're right! It may be more > generic to classify these scenarios, such as: "What should happen if a > restarting node fails to get a RecoveryPath/Path message from its > downstream/upstream neighbor?", but I think it may be more clear to > address the specific cases in the draft at least during the initial stage. > > Any comments are very welcome! > > Best regards, > > Dan > > > > > ----- Original Message ----- > From: Olufemi Komolafe > To: danli@huawei.com ; gjhhit@huawei.com > Cc: ccamp > Sent: Tuesday, September 19, 2006 8:45 PM > Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > > Hi, > > While reading this draft it occurred to me that perhaps it might be more > useful to approach this topic from the perspective of "What can go wrong > during graceful restart, what are the consequences and how can it be > fixed?" rather than focusing on the narrower topic of multiple > simultaneous nodal faults. > > For example, Scenario 1 in the draft may be interpreted as "What should > happen if a (non-ingress) restarting node fails to get a RecoveryPath > message from its downstream neighbour?", Scenario 2 is "What should happen > if a (non-ingress) restarting node fails to get a Path message from its > upstream neighbour?" and so on. Whether each of these scenarios arises > due to multiple simultaneous nodal faults (as in the draft) or any other > reason (e.g. a subsequent control channel failure, restarting node being > inundated with messages etc.) is, in my opinion, secondary. I think the > key thing is to identify the potential problems and suggest appropriate > remedial actions, where the authors think existing documentation is > insufficient, rather than focusing on 5 different permutations of multiple > node graceful restart. > > Regards, > Femi > > > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Zafar Ali (zali) > Sent: 10 July 2006 04:04 > To: danli@huawei.com; gjhhit@huawei.com > Cc: ccamp > Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > Dear Authors, > > This is Deja-vu to me.... > > Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on > multiple node restart case and was rejected by the WG as addressing > multiple node restart case is NOT a goal (suffers from the law of > diminishing return). In other words the following statement in the ID- > > "[GR-EXT] also extends the Hello message to exchange information about > the ability to support the RecoveryPath message. > The examples and procedures in [GR-EXT] focus on the description of a > single node restart when adjacent network nodes are operative. > Although the procedures are equally applicable to multi-node restarts, > no detailed explanation is provided." > > is not accurate. Please see section 4 on the earlier version of the > [GR-EXT], > http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt > . > > Thanks > > Regards... Zafar > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Sep 2006 11:02:46 +0000 Message-ID: <027a01c6e2ed$4acaa980$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: New Liaison Statement, "Response to liaisons on G.8110.1" Date: Thu, 28 Sep 2006 11:59:41 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Please see the liaison tracker for a response from the ITU-T on T-MPLS. This liaison includes some text on the motivations for T-MPLS and starts to build a picture of what the T-MPLS control plane might be expected to do. Adrian ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: ; ; ; ; ; Cc: ; ; ; ; ; ; ; ; ; ; ; ; Sent: Wednesday, September 27, 2006 4:35 PM Subject: New Liaison Statement, "Response to liaisons on G.8110.1" > > Title: Response to liaisons on G.8110.1 > Submission Date: 2006-09-27 > URL of the IETF Web page: > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=265 > Please reply by 2006-10-30 > > From: Greg Jones(ITU-T SG 15) > To: IETF(loa@pi.se, sob@harvard.edu, stbryant@cisco.com, > adrian@olddog.co.uk, danny@arbor.net, swallow@cisco.com) > Cc: iesg@ietf.org > iab@ietf.org > sjtrowbridge@lucent.com > betts01@nortel.com > maeda@ansl.ntt.co.jp > ghani.abbas@marconi.com > houlin.zhao@itu.int > ccamp@ops.ietf.org > mpls@lists.ietf.org > pwe3@ietf.org > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > Technical Contact: betts01@nortel.com > Purpose: For comment > Body: > Attachment(s): > Response to liaisons on G.8110.1 - body text > (https://datatracker.ietf.org/documents/LIAISON/file367.doc) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Sep 2006 23:16:17 +0000 Date: Tue, 26 Sep 2006 16:14:57 -0700 Message-Id: <200609262314.k8QNEvVL024784@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4631 on Link Management Protocol (LMP) Management Information Base (MIB) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4631 Title: Link Management Protocol (LMP) Management Information Base (MIB) Author: M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel Status: Standards Track Date: September 2006 Mailbox: dubuc.consulting@sympatico.ca, tnadeau@cisco.com, jplang@ieee.org, emcginnis@hammerheadsystems.com, adrian@olddog.co.uk Pages: 83 Characters: 152560 Obsoletes: RFC4327 See-Also: I-D Tag: draft-ietf-ccamp-rfc4327bis-01.txt URL: http://www.rfc-editor.org/rfc/rfc4631.txt This document provides minor corrections to and obsoletes RFC 4327. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Sep 2006 16:52:22 +0000 To: Dan Li Cc: ccamp , Olufemi Komolafe , gjhhit@huawei.com, owner-ccamp@ops.ietf.org Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 26 Sep 2006 18:50:54 +0200 Content-Type: text/plain; charset="US-ASCII" hi dan yes i have a very practical issue - the document would then deal with remedial to remedial - ... but do we have any feedback on initial remedials ? thanks, - d. Dan Li Sent by: owner-ccamp@ops.ietf.org 25/09/2006 09:27 To: Olufemi Komolafe , gjhhit@huawei.com cc: ccamp Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Hi Femi, Thanks for your valuable suggestion! The intention for this draft is clarify the procedures for multi-nodes restart, so five typical scenarios have been listed in the draft, I think most of the failed cases are covered by these five scenarios. As you have pointed out, these scenarios may be raised due to multiple nodes fail, or a subsequent control channel failure. Yes, you're right! It may be more generic to classify these scenarios, such as: "What should happen if a restarting node fails to get a RecoveryPath/Path message from its downstream/upstream neighbor?", but I think it may be more clear to address the specific cases in the draft at least during the initial stage. Any comments are very welcome! Best regards, Dan ----- Original Message ----- From: Olufemi Komolafe To: danli@huawei.com ; gjhhit@huawei.com Cc: ccamp Sent: Tuesday, September 19, 2006 8:45 PM Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Hi, While reading this draft it occurred to me that perhaps it might be more useful to approach this topic from the perspective of "What can go wrong during graceful restart, what are the consequences and how can it be fixed?" rather than focusing on the narrower topic of multiple simultaneous nodal faults. For example, Scenario 1 in the draft may be interpreted as "What should happen if a (non-ingress) restarting node fails to get a RecoveryPath message from its downstream neighbour?", Scenario 2 is "What should happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?" and so on. Whether each of these scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other reason (e.g. a subsequent control channel failure, restarting node being inundated with messages etc.) is, in my opinion, secondary. I think the key thing is to identify the potential problems and suggest appropriate remedial actions, where the authors think existing documentation is insufficient, rather than focusing on 5 different permutations of multiple node graceful restart. Regards, Femi From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Sent: 10 July 2006 04:04 To: danli@huawei.com; gjhhit@huawei.com Cc: ccamp Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Dear Authors, This is Deja-vu to me.... Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by the WG as addressing multiple node restart case is NOT a goal (suffers from the law of diminishing return). In other words the following statement in the ID- "[GR-EXT] also extends the Hello message to exchange information about the ability to support the RecoveryPath message. The examples and procedures in [GR-EXT] focus on the description of a single node restart when adjacent network nodes are operative. Although the procedures are equally applicable to multi-node restarts, no detailed explanation is provided." is not accurate. Please see section 4 on the earlier version of the [GR-EXT], http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt . Thanks Regards... Zafar Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Sep 2006 15:51:00 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZeuzTK0fKQIXWbe/ybDW3J6NpzJLR9D9z0PCUVmX04B7+TVPJoTrTEZLpmzAA30bAYQ2F10C2p1PzLYgEhE2nJMKZ4Zih/LMrFF4l0q95sJ5ik8FVxpSdOl83a4ZABfLxyW44JAWfDg5K+NfLVWNhq5F2GB/HsON7pVmNg+TvxU= Message-ID: <406e32c00609260849j3ab0d64o46f133b1905387be@mail.gmail.com> Date: Tue, 26 Sep 2006 11:49:12 -0400 From: "Peng He" To: ccamp@ops.ietf.org Subject: A New I.D.: A Novel Framework for Inter-area MPLS Optimal Routing MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all, We just published a new Internet Draft: A Novel Framework for Inter-area MPLS Optimal Routing (http://www.ietf.org/internet-drafts/draft-he-ccamp-optimal-routing-00.txt). Our general motive is to try to build up a framework for MPLS (even GMPLS possibly) inter-area TE, which can satisfy the inter-area TE requirements defined in RFC 4105. Please note that our framework in the draft can achieve inter-area MPLS optimal routing with good backward compatibility; and, it is different with PCE-based approaches. Any comments are very welcomed! Best Regards, Peng He PS: The following is publishing information of the draft: A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Novel Framework for Inter-area MPLS Optimal Routing > Author(s) : P. He, G. Bochmann > Filename : draft-he-ccamp-optimal-routing-00.txt > Pages : 16 > Date : 2006-9-25 > > We propose a novel framework for inter-area MPLS optimal routing. The > key to our proposal lies in deploying an overlaid star optical > network in the OSPF backbone area and introducing the concept of > ""virtual area border routers"" (v-ABRs). Compared with other > proposals, our framework can provide globally optimized inter-area > routing and has very good compatibility to existing traditional > IP/MPLS routers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-he-ccamp-optimal-routing-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-he-ccamp-optimal-routing-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-he-ccamp-optimal-routing-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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Sep 2006 07:29:51 +0000 Date: Mon, 25 Sep 2006 15:27:29 +0800 From: Dan Li Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, To: Olufemi Komolafe , gjhhit@huawei.com Cc: ccamp Message-id: <00ee01c6e074$0ed0f040$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Femi, Thanks for your valuable suggestion! The intention for this draft is clarify the procedures for multi-nodes restart, so five typical scenarios have been listed in the draft, I think most of the failed cases are covered by these five scenarios. As you have pointed out, these scenarios may be raised due to multiple nodes fail, or a subsequent control channel failure. Yes, you're right! It may be more generic to classify these scenarios, such as: "What should happen if a restarting node fails to get a RecoveryPath/Path message from its downstream/upstream neighbor?", but I think it may be more clear to address the specific cases in the draft at least during the initial stage. Any comments are very welcome! Best regards, Dan ----- Original Message ----- From: Olufemi Komolafe To: danli@huawei.com ; gjhhit@huawei.com Cc: ccamp Sent: Tuesday, September 19, 2006 8:45 PM Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Hi, While reading this draft it occurred to me that perhaps it might be more useful to approach this topic from the perspective of "What can go wrong during graceful restart, what are the consequences and how can it be fixed?" rather than focusing on the narrower topic of multiple simultaneous nodal faults. For example, Scenario 1 in the draft may be interpreted as "What should happen if a (non-ingress) restarting node fails to get a RecoveryPath message from its downstream neighbour?", Scenario 2 is "What should happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?" and so on. Whether each of these scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other reason (e.g. a subsequent control channel failure, restarting node being inundated with messages etc.) is, in my opinion, secondary. I think the key thing is to identify the potential problems and suggest appropriate remedial actions, where the authors think existing documentation is insufficient, rather than focusing on 5 different permutations of multiple node graceful restart. Regards, Femi From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Sent: 10 July 2006 04:04 To: danli@huawei.com; gjhhit@huawei.com Cc: ccamp Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Dear Authors, This is Deja-vu to me.... Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by the WG as addressing multiple node restart case is NOT a goal (suffers from the law of diminishing return). In other words the following statement in the ID- "[GR-EXT] also extends the Hello message to exchange information about the ability to support the RecoveryPath message. The examples and procedures in [GR-EXT] focus on the description of a single node restart when adjacent network nodes are operative. Although the procedures are equally applicable to multi-node restarts, no detailed explanation is provided." is not accurate. Please see section 4 on the earlier version of the [GR-EXT], http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt. Thanks Regards... Zafar Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Sep 2006 14:25:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DE52.CBE16254" Subject: question on draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Fri, 22 Sep 2006 15:24:21 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E02409D6F22F@enfimail2.datcon.co.uk> Thread-Topic: question on draft-ietf-ccamp-gmpls-recovery-e2e-signaling Thread-Index: AcbeUsv260Z4fGWJTmy31BkUFKv7vg== From: "Alan Davey" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DE52.CBE16254 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I have a question about the use of end-to-end recovery signaling in conjunction with graceful restart following nodal faults. =20 Is it expected that the end-to-end recovery signaling protocol will handle the restart of either of the ingress or egress nodes during switchover or reversion processing, where that node implements graceful restart mechanisms as described in RFC3473? =20 If so then what is the effect on, for example, the end-to-end switchover request/response procedure of one of the end-nodes restarting? =20 Thanks in advance =20 Alan =20 ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com Web: http://www.dataconnection.com =20 ------_=_NextPart_001_01C6DE52.CBE16254 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
I have = a question=20 about the use of end-to-end recovery signaling in conjunction with = graceful=20 restart following nodal faults.
 
Is it = expected that=20 the end-to-end recovery signaling protocol will handle the restart of = either of=20 the ingress or egress nodes during switchover or reversion processing, = where=20 that node implements graceful restart mechanisms as described in=20 RFC3473?
 
If so = then what is=20 the effect on, for example, the end-to-end switchover request/response = procedure=20 of one of the end-nodes restarting?
 
Thanks = in=20 advance
 
Alan
 
------------------------------------
Alan Davey
Data Connection = Ltd
Tel:   +44 20 = 8366=20 1177
Fax:   +44 20 = 8363=20 1039
Email: Alan.Davey@dataconnection.c= om
Web:   http://www.dataconnection.com=
------_=_NextPart_001_01C6DE52.CBE16254-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Sep 2006 13:24:46 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-54-235550940 Message-Id: Cc: , "Ross Callon" , From: JP Vasseur Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Fri, 22 Sep 2006 09:22:57 -0400 To: "Adrian Farrel" DKIM-Signature: a=rsa-sha1; q=dns; l=52628; t=1158931387; x=1159795387; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20Routing=20Directorate=20comments=20on=20draft-ietf-ccamp-automes h-01; X=v=3Dcisco.com=3B=20h=3DuG5NUr9tkIvBpzVKn0luCin5Z/4=3D; b=R0Nuf+Nxd1FrQlOyHNrimk3GgvgHddaO5u1NaqsYVjc9C+I/Deam5Qn4FEnJSTG+xm3mDWuH smO8mu+qjv5zdok+Ptn0doCc1Cn4o6LN2WluXno2gO1VLlCAi/Rsn2qQ; Authentication-Results: sj-dkim-7.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); --Apple-Mail-54-235550940 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Adrian, On Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote: > Hi JP, > > Thanks for addressing the comments. I have forwarded these to the > Routing Directorate and copied them on this email to let them > respond if they want. OK > But here are my comments: > in line, >>> 1) The Tail-end name field facilitates LSP identification. Is this >>> a new form of LSP identification? >>> If it is not new, then there should be a reference to RFC3209 and a >>> statement of which RFC3209 fields are mapped to this IGP field. >>> If it is not new then there is a significant concern that a new >>> identification is being introduced when it is not needed. >> >> As indicated in the document the string refers to a "Tail-end" name, >> not an TE LSP name: thus it does not replace the session name of the >> SESSION-ATTRIBUTE object defined in RFC3209. > > Hmmm, yes it is not an LSP name, but recall that the LSP is > identified by a combination of Session and Sender Template, and > that the Session includes the destination IP address. In Section > 3.2 I see: > - A Tail-end name: string used to ease the TE-LSP naming. > and in Section 4.1: > - A Tail-end name: a variable length field used to facilitate the TE > LSP identification. Ah I see your point now. Just bad wording, it should have read " The idea is not to use that field for LSP identification per say but to ease the management, troubleshooting, ... For example, an implementation could form the session name based on the strings on these fields. A Tail-end name: name of the Tail-end LSR. + see below > > These definitions seem to imply that the tail-end name is used as > an identifier for the LSP. The question that will be asked is: How > does this identification of an LSP differ from the conventional > identification of the LSP? Given that you also have: > - A Tail-end address: an IPv4 or IPv6 IP address to be used as a > tail-end TE LSP address by other LSRs belonging to the same mesh- > group > it appears that the tail-name is superfluous information. > Well having the name definitely helps for management, troubleshooting, ... > So, perhaps the name is present for diagnostic purposes? Perhaps it > is there to ease OAM? But it does not seem to play any role in the > protocol procedures as it is not explicitly mentioned later in the > I-D (e.g. Section 5). > OK let me try to clarify adding the following text then: The aim of the Tail-end address field is to provide a way to quickly identify the tail-end LSR originating the TE-MESH-GROUP and could be used for various purposes such such troubleshooting, management and so on. It does not interfere by any mean with the TE LSP attributes used to identify a TE LSP. Does that clarify ? > How would a node behave if it received a mesh group advertisement > that indicated a tail-end address that did not appear to match its > record of the tail-end name? > >>> 2) The document mentions that the number of mesh groups is limited >>> but potentially (depending on encoding) provides for binary >>> encoding for 2^32-1 groups (although this might be constrained by >>> OSPF's limit of a TLV size to 2^16 bytes. >>> The document (and the authors) state that scaling of these >>> extensions is not an issue because only a small number of mesh >>> groups are likely to be in existence in a network, and any one >>> router is unlikely to participate in more than a very few. >>> There are two concerns: >>> a) Whenever we say that something in the Internet is limited, >>> history usually proves us wrong. >> >> And that's undoubtedly a good news :-) >> >>> Indeed, there is already a >>> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >>> similar mechanism for a problem that would have far more groups. >> >> Two comments: >> - Mesh groups are used to set up TE LSP meshes. If we consider let >> say 10 meshes comprising 100 routers each, that gives us 99,000 TE >> LSPs. One can easily see that the number of meshes is unlikely to >> explode in a foreseeable future. If it turns out to be the case, >> we'll have other scalability issues to fix before any potential with >> the IGP. > > What about 100 meshes comprising 10 routers each? Note that would still be very reasonable ;-) > I make that only 9,000 TE LSPs. > > So clearly the scaling of MPLS-TE is not directly related to the > scaling of automesh. > Well you see my point ... since these extensions are used to set up TE LSPs, in the vast majority of the realistic cases you'll end up with scalability concerns with RSVP before seeing any IGP scalability issue. > What this comes down to is your statement about how automesh will > be used. I think we can all accept that this is the problem space > that you intend to deploy in, and that is great. But the original > point from the Routing Directorate was that there is nothing in the > I-D that imposes this restriction. So how can we say that the > protocol extensions will scale? And that is true with pretty much every protocol: one could always come up with a scenario where a bad usage of the protocol or a broken implementation may be a concern. Anyway, let me try to propose some text to close on this: OLD: It is expected that the number of mesh-groups be very limited (to at most 10 or so). Moreover, TE mesh-group membership should not change frequently: each time an LSR joins or leaves a new TE mesh-group. NEW: The aim of the IGP extensions proposed in this document is to ease the provisioning of TE meshes, the number of which is generally very limited (10 at most or so), and should stay of this order of magnitude at least in a foreseeable future. Furthermore, such TE meshes are not expected to change frequently and thus the TE mesh- group membership is likely to be very stable (each time an LSR joins or leaves a new TE mesh-group, which is a not a frequent). An implementation SHOULD support mechanisms to control the frequency at which an LSR joins/leaves a particular a TE mesh group. Does that address your concern ? > >> - More importantly, the dynamics of joining a TE mesh is such that >> IGP updates are used to advertise to TE mesh group membership change >> (join or prune), which are indeed expected to be very unfrequent. > > Again, the concern raised is that the problem space you intend to > deploy in is, indeed, limited in this way. All good. But how can we > say whether the protocol extensions will be used differently in the > future? What controls are there over constructing a mesh where > joins and prunes are frequent? > >>> b) The I-D does not itself impose any reasonable limits on the >>> number of groups with the potential for a single router (by >>> misconfiguration, design, or malice) advertising a very large >>> number of groups. >>> Thus, it appears that the scaling concerns are not properly >>> addressed in this I-D. >> >> Not sure to see the point here. If indeed, a large number of TE MESH >> GROUPs were advertised, this would not impact the other LSRs since >> they would not create any new TE LSPs trying to join the new TE-MESH- >> GROUP. In term of amount of flooded information, this should not be a >> concern either (handled by routing). We clarified this in the >> security section. > > The impact on the other LSRs is exactly flooding question. Covering > that in the security section is fine for the misconfiguration and > malice cases. > >>> 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL >>> and must at most appear once in a OSPF Router Information LSA or >>> ISIS Router Capability TLV." but for addition/removal it mentions >>> "conversely, if the LSR leaves a mesh-group the corresponding entry >>> will be removed from the TE-MESH-GROUP TLV." >>> What are these "entries" referring to - that there is a top-level >>> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions >>> "No sub-TLV is currently defined for the TE-mesh-group TLV") ? >>> >>> AF>> My comment on this is that the definition of the TLVs seems >>> AF>> unclear. >>> AF>> From figure 2, it appears that some additional information >>> can be >>> AF>> present in the TLV after the fields listed, and (reading >>> AF>> between the lines) it would appear that this additional >>> AF>> information is a series of repeats of the set of fields to >>> AF>> define multiple mesh groups. >>> AF>> This could usefully be clarified considerably. >> >> >> You're absolutely right. The figures have been modified: >> >> (example show below): > > [SNIP] > Looks good to me. > >>> AF>> But it is now unclear to me whether a single router can be a >>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that >>> AF>> these cannot be mixed within a single TLV, and multiple >>> AF>> TLVs (one IPv4 and one IPv6) are prohibited. >> >> OK the text requires some clarification. What is prohibited is to >> have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is >> permitted. New proposed text to clarify: >> >> The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and >> one IPv6 instance MUST appear in a OSPF Router Information LSA or >> ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or >> IPv6) occurs more than once within the OSPF Router Information LSA, >> only the first instance is processed, subsequent TLV(s) will be >> silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 >> or IPv6) occurs more than once within the ISIS Router capability TLV, >> only the first instance is processed, subsequent TLV(s) will be >> silently ignored. > > OK. That's fine. > I think you want to make a couple of changes: > - "at most one instance MUST appear" is ambiguous since it will > be confused with "an instance MUST appear". I suggest you > reword as "MUST NOT include more than one of each of" > - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs > more than once" should really be phrased as "If the either the > IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more > than once". Ditto for the IS-IS sub-TLV. > - Two instances of "will be silently ignored" should read "SHOULD > be silently ignored" Fixed, thanks ! > >>> 4) Small terminology issue in section 5.1 it says: "Note that both >>> operations can be performed in the context of a single refresh." >>> This is not a refresh. It is a trigger/update. A better term for >>> OSPF would be "LSA origination". >> >> OK fixed (I used the term "Update"), thanks. > > OK > >>> 5) Please state the applicability to OSPF v2 and or v3. Note that >>> the Router_Cap document covers both v2 and v3 >> >> Indeed, Thanks for the comments. The OSPFv3 aspects have been >> incorporated. Here is the new text: > > [SNIP] > OK > >>> 6) The term "fairly static" at the end of section 5.1 is >>> meaningless without some relative context. >>> Presumably this relates to the number times an LSR joins or leaves >>> a mesh group over time. >>> Is it intended to be relative to the IGP refresh period? >>> Please clarify in an objective rather than a subjective way. >> >> >> Right, this requires clarification. Here is the new text: Moreover, >> TE mesh-group membership should not change frequently: each time an >> LSR joins or leaves a new TE mesh-group. > > I could live with this, personally. We'll see whether we get any > more comments. > I think the nub will be: > 1. whether your "should not" can be "SHOULD NOT" > 2. what does "frequently mean"? > 3. what is there in this I-D to say that an LSR does not join/leave a > TE mesh-group very often? > Hopefully I clarified with the text above. >> I guess that this is sufficiently explicit: it is a well-known fact >> that LSRs are infrequently added or removed to a TE mesh. > > :-) Very well known. In fact, my mother was commenting on it to me > only the other day ;-) > ah so she should talk to my kids then ... we can work this out ;-))) > Consider the case where PE membership of an automesh is dependent > on whether there are C-nodes subscribed to some service. > > Perhaps this well known fact could be noted in the Introduction to > this I-D which is AFAIK the only IETF document on the subject of > automesh. OK, see the proposed text, and let me know what you think, I do think that this is sufficient but let me know. > >>> 7) The security section (section 8) is inadequate and will >>> undoubtedly be rejected by the security ADs. At the very least, the >>> I-D needs a paragraph (i.e. more than one or two lines) explaining >>> why there are no new security considerations. But what would be the >>> impact of adding false mesh groups to a TLV? Is there anything >>> (dangerous) that can be learned about the network by inspecting >>> mesh group TLVs? >> >> The following section has been added: > > [SNIP] > OK. Let's run with that and see how much we get beaten up by the > Security experts. OK, thanks. cheers, JP. > > Cheers, > Adrian --Apple-Mail-54-235550940 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

On = Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote:

Hi JP,

Thanks for addressing the = comments. I have forwarded these to the Routing Directorate and copied = them on this email to let them respond if they want. =

OK

But here are my = comments:
in = line,

1) The Tail-end name field facilitates LSP = identification. Is this
a new form of = LSP identification?
If it is not new, then = there should be a reference to RFC3209 and a
statement of which RFC3209 fields are mapped to this = IGP field.
If it is not new then there is a = significant concern that a new

As indicated in the document the string refers to a = "Tail-end" name,
not an TE LSP name: thus it does = not replace the session name of the

Hmmm, = yes it is not an LSP name, but recall that the LSP is identified by a = combination of Session and Sender Template, and that the Session = includes the destination IP address. In Section 3.2 I see:
=A0 - A = Tail-end name: string used to ease the TE-LSP naming.
and in Section 4.1:
=A0 - A Tail-end name: a variable = length field used to facilitate the TE
=A0 LSP = identification.

Ah I see your point now. = Just bad wording, it should have read "
The idea is not to use that = field for LSP identification per say but to ease the management, = troubleshooting, ...
For example, an implementation could form = the session name based on the strings on these fields.

A Tail-end name: name of = the Tail-end LSR.

+ see = below


These = definitions seem to imply that the tail-end name is used as an = identifier for the LSP. The question that will be asked is: How does = this identification of an LSP differ from the conventional = identification of the LSP?=A0 = Given that you also have:
=A0 - A Tail-end address: an IPv4 = or IPv6 IP address to be used as a
=A0 tail-end TE LSP address by = other LSRs belonging to the same mesh-
=A0 group
it appears that the tail-name is superfluous = information.
Well having the name = definitely helps for management, troubleshooting, = ...

So, perhaps the name is present = for diagnostic purposes? Perhaps it is there to ease OAM? But it does = not seem to play any role in the protocol procedures as it is not = explicitly mentioned later in the I-D (e.g. Section 5).


OK let me try to clarify = adding the following text then:

The aim of the Tail-end = address field is to provide a way to quickly identify the tail-end LSR = originating the TE-MESH-GROUP and could be used for various purposes = such such troubleshooting, management and so on. It does not interfere = by any mean with the TE LSP attributes used to identify a TE = LSP.

Does = that clarify ?

How = would a node behave if it received a mesh group advertisement that = indicated a tail-end address that did not appear to match its record of = the tail-end name?
2) The document mentions that the number of mesh = groups is limited
but potentially (depending on = encoding) provides for binary
encoding for = 2^32-1 groups (although this might be constrained by
OSPF's limit of a TLV size to 2^16 bytes.
The document (and the authors) state that scaling of = these
extensions is not an issue = because only a small number of mesh
groups are = likely to be in existence in a network, and any one
router is unlikely to participate in more than a = very few.
There are two = concerns:
a) Whenever we say that = something in the Internet is limited,
history = usually proves us wrong.

And that's = undoubtedly a good news :-)

Indeed, = there is already a
proposal = (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a
similar mechanism for a problem that would have far = more groups.

Two comments:
- Mesh groups are used to set up TE LSP meshes. If = we consider let
say 10 meshes comprising 100 = routers each, that gives us 99,000 TE
LSPs. = One can easily see that the number of meshes is unlikely to
explode in a foreseeable future. If it turns out to = be the case,
we'll have other scalability = issues to fix before any potential with
the = IGP.
What about 100 meshes comprising = 10 routers each?

Note that would still be = very reasonable ;-)

I make that only 9,000 TE LSPs.

So = clearly the scaling of MPLS-TE is not directly related to the scaling of = automesh.
Well you see my point ... = since these extensions are used to set up TE LSPs, in the vast majority = of the realistic cases you'll end up with scalability concerns with RSVP = before seeing any IGP scalability issue.

What this comes down to is your statement about how = automesh will be used. I think we can all accept that this is the = problem space that you intend to deploy in, and that is great. But the = original point from the Routing Directorate was that there is nothing in = the I-D that imposes this restriction. So how can we say that the = protocol extensions will scale?

And that is true with = pretty much every protocol: one could always come up with a scenario = where a bad usage of the protocol or a broken implementation may be a = concern. Anyway, let me try to propose some text to close on = this:

OLD:

It is expected that the = number of mesh-groups be very limited (to at most 10 or = so).=A0
Moreover, TE mesh-group membership should not change = frequently: each time an LSR joins or leaves a new TE = mesh-group.

NEW:
The aim of = the IGP extensions proposed in this document is to ease the provisioning = of TE meshes, the number of which is generally very limited (10 at most = or so), and should stay of this order of magnitude at least in = a=A0foreseeable future. Furthermore, such TE meshes are not expected to = change frequently and thus the TE mesh-group membership is likely to be = very stable (each time an LSR joins or leaves a new TE mesh-group, which = is a not a frequent). An implementation SHOULD support=A0mechanisms to = control the frequency at which an LSR joins/leaves a particular a TE = mesh group.

Does = that address your concern ?


- More importantly, the dynamics = of joining a TE mesh is such that
IGP updates = are used to advertise to TE mesh group membership change
(join or prune), which are indeed expected to be = very unfrequent.

Again, the concern raised is = that the problem space you intend to deploy in is, indeed, limited in = this way. All good. But how can we say whether the protocol extensions = will be used differently in the future? What controls are there over = constructing a mesh where joins and prunes are frequent?

b) The I-D = does not itself impose any reasonable limits on the
number of groups with the potential for a single = router (by
misconfiguration, design, or = malice) advertising a very large
number of = groups.
Thus, it appears that the = scaling concerns are not properly
addressed in = this I-D.

Not sure to see the point here. = If indeed, a large number of TE MESH
GROUPs were = advertised, this would not impact the other LSRs since
they would not create any new TE LSPs trying to join = the new TE-MESH-
GROUP. In term of amount of = flooded information, this should not be a
concern = either (handled by routing). We clarified this in the
security section.

The = impact on the other LSRs is exactly flooding question. Covering that in = the security section is fine for the misconfiguration and malice = cases.

=
3) The document mentions that "The TE-MESH-GROUP TLV = is OPTIONAL
and must at most appear once in = a OSPF Router Information LSA or
ISIS Router = Capability TLV." but for addition/removal it mentions
"conversely, if the LSR leaves a mesh-group the = corresponding entry
will be removed from the = TE-MESH-GROUP TLV."
What are these "entries" = referring to - that there is a top-level
"No sub-TLV is currently defined = for the TE-mesh-group TLV") ?

AF>> My comment on this is = that the definition of the TLVs seems
AF>> =46rom figure 2, = it appears that some additional information can be
AF>> present in the TLV after the fields = listed, and (reading
AF>> between the = lines) it would appear that this additional
AF>> define multiple mesh = groups.
AF>> This could usefully = be clarified considerably.


You're absolutely right. The = figures have been modified:

(example show below):
=

[SNIP]
Looks good to = me.

=
AF>> But it is now unclear to me whether a = single router can be a
AF>> member of IPv4 = an IPv6 mesh groups. It would seem that
AF>> TLVs (one IPv4 and = one IPv6) are prohibited.

OK the text = requires some clarification. What is prohibited is to
have two IPv4 sub-TLV or two IPv6 sub-TLV but one of = each is
permitted. New proposed text to = clarify:

The TE-MESH-GROUP TLV is OPTIONAL and at most one = IPv4 instance and
one IPv6 instance MUST appear in = a OSPF Router Information LSA or
ISIS Router = Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or
IPv6) occurs more than once within the OSPF Router = Information LSA,
only the first instance is = processed, subsequent TLV(s) will be
silently = ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4
or IPv6) occurs more than once within the ISIS = Router capability TLV,
only the first instance is = processed, subsequent TLV(s) will be
silently = ignored.
OK. That's fine.
I think you want to make a couple of = changes:
- "at most one instance MUST = appear" is ambiguous since it will
=A0be confused with "an instance = MUST appear". I suggest you
=A0reword as "MUST NOT include = more than one of each of"
- "If the = OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs
=A0more = than once" should really be phrased as "If the either the
=A0IPv4 = or IPv6 OSPF TE-MESH-GROUP TLV occurs more
=A0than once".=A0 Ditto for the IS-IS = sub-TLV.
- Two instances of "will be = silently ignored" should read "SHOULD
=A0be silently = ignored"

Fixed, thanks = !


4) Small terminology issue in = section 5.1 it says: "Note that both
operations = can be performed in the context of a single refresh."
This is not a refresh. It is a trigger/update. A = better term for
OSPF would be "LSA = origination".

OK fixed (I used the term = "Update"), thanks.

OK

5) Please state the = applicability to OSPF v2 and or v3. Note that
the Router_Cap document covers both v2 and v3
=

Indeed, Thanks for the comments.=A0 The OSPFv3 aspects have = been
incorporated. Here is the new = text:
[SNIP]
OK
6) The term "fairly static" at the end of section = 5.1 is
meaningless without some = relative context.
Presumably this relates to the = number times an LSR joins or leaves
a mesh group = over time.
Is it intended to be relative to = the IGP refresh period?
Please = clarify in an objective rather than a subjective way.
=


Right, = this requires clarification. Here is the new text: Moreover,
TE mesh-group membership should not change = frequently: each time an
LSR joins or = leaves a new TE mesh-group.

I could live = with this, personally. We'll see whether we get any more = comments.
I think the nub will = be:
1. whether your "should not" can = be "SHOULD NOT"
2. what does "frequently = mean"?
3. what is there in this I-D to = say that an LSR does not join/leave a
=A0 TE mesh-group very = often?
Hopefully I clarified with = the text above.

I guess that this is = sufficiently explicit: it is a well-known fact
that LSRs are infrequently added or removed to a TE = mesh.
:-) Very well known. In fact, my = mother was commenting on it to me only the other day ;-)


ah so she should talk to my = kids then ... we can work this out ;-)))

Consider the case where PE membership of an automesh = is dependent on whether there are C-nodes subscribed to some = service.

Perhaps this well known fact could be noted in the = Introduction to this I-D which is AFAIK the only IETF document on the = subject of automesh.

OK, see the proposed text, = and let me know what you think, I do think that this is sufficient but = let me know.


7) The security section (section = 8) is inadequate and will
undoubtedly = be rejected by the security ADs. At the very least, the
I-D needs a paragraph (i.e. more than one or two = lines) explaining
why there are no new security = considerations. But what would be the
impact = of adding false mesh groups to a TLV? Is there anything
(dangerous) that can be learned about the network by = inspecting
mesh group TLVs?
=

The following section has been added:
=

[SNIP]
OK. Let's run = with that and see how much we get beaten up by the Security = experts.

OK, thanks.

cheers,

JP.


Cheers,
Adrian=A0
=

= --Apple-Mail-54-235550940-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 16:50:37 +0000 Message-ID: <0f3f01c6dd9d$e30e7fa0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "JP Vasseur" Cc: , "Ross Callon" , Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Thu, 21 Sep 2006 17:48:53 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi JP, Thanks for addressing the comments. I have forwarded these to the Routing Directorate and copied them on this email to let them respond if they want. But here are my comments: >> 1) The Tail-end name field facilitates LSP identification. Is this >> a new form of LSP identification? >> If it is not new, then there should be a reference to RFC3209 and a >> statement of which RFC3209 fields are mapped to this IGP field. >> If it is not new then there is a significant concern that a new >> identification is being introduced when it is not needed. > > As indicated in the document the string refers to a "Tail-end" name, > not an TE LSP name: thus it does not replace the session name of the > SESSION-ATTRIBUTE object defined in RFC3209. Hmmm, yes it is not an LSP name, but recall that the LSP is identified by a combination of Session and Sender Template, and that the Session includes the destination IP address. In Section 3.2 I see: - A Tail-end name: string used to ease the TE-LSP naming. and in Section 4.1: - A Tail-end name: a variable length field used to facilitate the TE LSP identification. These definitions seem to imply that the tail-end name is used as an identifier for the LSP. The question that will be asked is: How does this identification of an LSP differ from the conventional identification of the LSP? Given that you also have: - A Tail-end address: an IPv4 or IPv6 IP address to be used as a tail-end TE LSP address by other LSRs belonging to the same mesh- group it appears that the tail-name is superfluous information. So, perhaps the name is present for diagnostic purposes? Perhaps it is there to ease OAM? But it does not seem to play any role in the protocol procedures as it is not explicitly mentioned later in the I-D (e.g. Section 5). How would a node behave if it received a mesh group advertisement that indicated a tail-end address that did not appear to match its record of the tail-end name? >> 2) The document mentions that the number of mesh groups is limited >> but potentially (depending on encoding) provides for binary >> encoding for 2^32-1 groups (although this might be constrained by >> OSPF's limit of a TLV size to 2^16 bytes. >> The document (and the authors) state that scaling of these >> extensions is not an issue because only a small number of mesh >> groups are likely to be in existence in a network, and any one >> router is unlikely to participate in more than a very few. >> There are two concerns: >> a) Whenever we say that something in the Internet is limited, >> history usually proves us wrong. > > And that's undoubtedly a good news :-) > >> Indeed, there is already a >> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >> similar mechanism for a problem that would have far more groups. > > Two comments: >- Mesh groups are used to set up TE LSP meshes. If we consider let > say 10 meshes comprising 100 routers each, that gives us 99,000 TE > LSPs. One can easily see that the number of meshes is unlikely to > explode in a foreseeable future. If it turns out to be the case, > we'll have other scalability issues to fix before any potential with > the IGP. What about 100 meshes comprising 10 routers each? I make that only 9,000 TE LSPs. So clearly the scaling of MPLS-TE is not directly related to the scaling of automesh. What this comes down to is your statement about how automesh will be used. I think we can all accept that this is the problem space that you intend to deploy in, and that is great. But the original point from the Routing Directorate was that there is nothing in the I-D that imposes this restriction. So how can we say that the protocol extensions will scale? > - More importantly, the dynamics of joining a TE mesh is such that > IGP updates are used to advertise to TE mesh group membership change > (join or prune), which are indeed expected to be very unfrequent. Again, the concern raised is that the problem space you intend to deploy in is, indeed, limited in this way. All good. But how can we say whether the protocol extensions will be used differently in the future? What controls are there over constructing a mesh where joins and prunes are frequent? >> b) The I-D does not itself impose any reasonable limits on the >> number of groups with the potential for a single router (by >> misconfiguration, design, or malice) advertising a very large >> number of groups. >> Thus, it appears that the scaling concerns are not properly >> addressed in this I-D. > >Not sure to see the point here. If indeed, a large number of TE MESH >GROUPs were advertised, this would not impact the other LSRs since >they would not create any new TE LSPs trying to join the new TE-MESH- >GROUP. In term of amount of flooded information, this should not be a >concern either (handled by routing). We clarified this in the >security section. The impact on the other LSRs is exactly flooding question. Covering that in the security section is fine for the misconfiguration and malice cases. >> 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL >> and must at most appear once in a OSPF Router Information LSA or >> ISIS Router Capability TLV." but for addition/removal it mentions >> "conversely, if the LSR leaves a mesh-group the corresponding entry >> will be removed from the TE-MESH-GROUP TLV." >> What are these "entries" referring to - that there is a top-level >> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions >> "No sub-TLV is currently defined for the TE-mesh-group TLV") ? >> >> AF>> My comment on this is that the definition of the TLVs seems >> AF>> unclear. >> AF>> From figure 2, it appears that some additional information can be >> AF>> present in the TLV after the fields listed, and (reading >> AF>> between the lines) it would appear that this additional >> AF>> information is a series of repeats of the set of fields to >> AF>> define multiple mesh groups. >> AF>> This could usefully be clarified considerably. > > > You're absolutely right. The figures have been modified: > > (example show below): [SNIP] Looks good to me. >> AF>> But it is now unclear to me whether a single router can be a >> AF>> member of IPv4 an IPv6 mesh groups. It would seem that >> AF>> these cannot be mixed within a single TLV, and multiple >> AF>> TLVs (one IPv4 and one IPv6) are prohibited. > > OK the text requires some clarification. What is prohibited is to > have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is > permitted. New proposed text to clarify: > > The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and > one IPv6 instance MUST appear in a OSPF Router Information LSA or > ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or > IPv6) occurs more than once within the OSPF Router Information LSA, > only the first instance is processed, subsequent TLV(s) will be > silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 > or IPv6) occurs more than once within the ISIS Router capability TLV, > only the first instance is processed, subsequent TLV(s) will be > silently ignored. OK. That's fine. I think you want to make a couple of changes: - "at most one instance MUST appear" is ambiguous since it will be confused with "an instance MUST appear". I suggest you reword as "MUST NOT include more than one of each of" - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs more than once" should really be phrased as "If the either the IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more than once". Ditto for the IS-IS sub-TLV. - Two instances of "will be silently ignored" should read "SHOULD be silently ignored" >> 4) Small terminology issue in section 5.1 it says: "Note that both >> operations can be performed in the context of a single refresh." >> This is not a refresh. It is a trigger/update. A better term for >> OSPF would be "LSA origination". > >OK fixed (I used the term "Update"), thanks. OK >> 5) Please state the applicability to OSPF v2 and or v3. Note that >> the Router_Cap document covers both v2 and v3 > >Indeed, Thanks for the comments. The OSPFv3 aspects have been >incorporated. Here is the new text: [SNIP] OK >> 6) The term "fairly static" at the end of section 5.1 is >> meaningless without some relative context. >> Presumably this relates to the number times an LSR joins or leaves >> a mesh group over time. >> Is it intended to be relative to the IGP refresh period? >> Please clarify in an objective rather than a subjective way. > > > Right, this requires clarification. Here is the new text: Moreover, > TE mesh-group membership should not change frequently: each time an > LSR joins or leaves a new TE mesh-group. I could live with this, personally. We'll see whether we get any more comments. I think the nub will be: 1. whether your "should not" can be "SHOULD NOT" 2. what does "frequently mean"? 3. what is there in this I-D to say that an LSR does not join/leave a TE mesh-group very often? > I guess that this is sufficiently explicit: it is a well-known fact > that LSRs are infrequently added or removed to a TE mesh. :-) Very well known. In fact, my mother was commenting on it to me only the other day ;-) Consider the case where PE membership of an automesh is dependent on whether there are C-nodes subscribed to some service. Perhaps this well known fact could be noted in the Introduction to this I-D which is AFAIK the only IETF document on the subject of automesh. >> 7) The security section (section 8) is inadequate and will >> undoubtedly be rejected by the security ADs. At the very least, the >> I-D needs a paragraph (i.e. more than one or two lines) explaining >> why there are no new security considerations. But what would be the >> impact of adding false mesh groups to a TLV? Is there anything >> (dangerous) that can be learned about the network by inspecting >> mesh group TLVs? > > The following section has been added: [SNIP] OK. Let's run with that and see how much we get beaten up by the Security experts. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 16:11:19 +0000 Message-ID: <0f2701c6dd98$65564d40$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "ccamp" Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Date: Thu, 21 Sep 2006 16:55:29 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="GB2312"; reply-type=original Content-Transfer-Encoding: 8bit Hi Jiang, Yes, I read your I-D when it was published in November last year. It seems to me that you were addressing a very specific sub-case of the graceful restart problem space. If we generalise to a linear network A-B-C-D-E-F with an LSP running from A to F, your draft handles the case where all four nodes B, C, D and E fail, and C and D subsequently recover, but have retained no LSP state. You are asking the question, how do nodes C and D know to exchange Hello messages. The reasons why I limit your draft to such a narrow subset of the problem are: - If any restarting node is adjacent to a node that remained active, the active node will send a Hello message and that will engage the graceful restart procedures - If the restarting node had retained any LSP state, it would know about its neighbours and would be able to send Hello messages. This seems like a very small corner case, and we do not usually design the protocols to optimise for this type of error condition. So long as there is *a* solution, we are usually happy. That said, if this is a problem that is causing you problems in the field, we should address it. I note that your I-D has expired and I wonder what your plans are for this work. Regards, Adrian ----- Original Message ----- From: To: "Olufemi Komolafe" Cc: "ccamp" ; ; ; Sent: Wednesday, September 20, 2006 3:57 AM Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > Hello, everyone! > > We have put forward a mechanism to solve this problem in our > draft "draft-jian-ccamp-multinodes-rsvp-restart-00" last year. > > We think that if multiple adjacent nodes restarted nearly at > the same time, these nodes cannot learn about the GR capability > from each other. > > The key of this problem is that how restarted node actively > inform its GR(Graceful Restart) capability to neighbor nodes, > especially some neighbor nodes are restarted nodes too. > > If you concern our mechanism, please read our draft for detail. > > > > > Regard, > Jiang Weilian > ............................................... > Add: No.68 Zijinghua Rd,Yuhuatai District, > Nanjing. P.R.China. > Zip: 210012 > Tel: 0086-25-52871644 > Mail: jiang.weilian@zte.com.cn > ............................................. > > > > > > "Olufemi Komolafe" > ·¢¼þÈË£º owner-ccamp@ops.ietf.org > > 2006-09-19 20:45 > > ÊÕ¼þÈË£º , > ³­ËÍ£º "ccamp" > Ö÷Ì⣺ RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > > Hi, > > While reading this draft it occurred to me that perhaps it might be more > useful to approach this topic from the perspective of ¡°What can go wrong > during graceful restart, what are the consequences and how can it be > fixed?¡± rather than focusing on the narrower topic of multiple > simultaneous nodal faults. > > For example, Scenario 1 in the draft may be interpreted as ¡°What should > happen if a (non-ingress) restarting node fails to get a RecoveryPath > message from its downstream neighbour?¡±, Scenario 2 is ¡°What should > happen if a (non-ingress) restarting node fails to get a Path message from > its upstream neighbour?¡± and so on. Whether each of these scenarios > arises due to multiple simultaneous nodal faults (as in the draft) or any > other reason (e.g. a subsequent control channel failure, restarting node > being inundated with messages etc.) is, in my opinion, secondary. I think > the key thing is to identify the potential problems and suggest > appropriate remedial actions, where the authors think existing > documentation is insufficient, rather than focusing on 5 different > permutations of multiple node graceful restart. > > Regards, > Femi > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Zafar Ali (zali) > Sent: 10 July 2006 04:04 > To: danli@huawei.com; gjhhit@huawei.com > Cc: ccamp > Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, > > Dear Authors, > > This is Deja-vu to me.... > > Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on > multiple node restart case and was rejected by the WG as addressing > multiple node restart case is NOT a goal (suffers from the law of > diminishing return). In other words the following statement in the ID- > > "[GR-EXT] also extends the Hello message to exchange information about > the ability to support the RecoveryPath message. > The examples and procedures in [GR-EXT] focus on the description of a > single node restart when adjacent network nodes are operative. > Although the procedures are equally applicable to multi-node restarts, > no detailed explanation is provided." > > is not accurate. Please see section 4 on the earlier version of the > [GR-EXT], > http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt > . > > Thanks > > Regards... Zafar > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to > others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the originator of > the message. Any views expressed in this message are those of the > individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to > others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the originator of > the message. Any views expressed in this message are those of the > individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 15:01:09 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 15:59:54 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389188FDB9B@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbddg77yvsiJyJpTXasuZ6O4lOTMwAALwBA From: To: Cc: , , Thanks Loa.....this sounds OK to me and I'll go with the liaison as-is. However, one point we should bear in mind and that has not been stated so far is that the VLAN field assumes a different semantic in a co-ps mode layer network (be this PBT or VLAN-XC swapping) compared to its original cl-ps mode Ethernet layer network semantic. In the co-ps mode case it is either: - part of the trail termination address in PBT that does not get swapped during forwarding, ie the trail sink term address is the combination of DMAC+VCID; - a proxy for the trail termination address in VLAN-XC (BTW - I am not clear what VLAN-XC layer network addresses are here) that could be swapped on each link-connection. AFAI understand the original IEEE intent of a VLAN was to create a restricted broadcast domain within which a certain subset of the total MAC address population reside. These are quite different semantics. So asking for clarification of what IEEE mean by (and the scope of) swapping the VLAN field would still not really be comparable to such an action in a co-ps mode layer network. regards Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Loa Andersson > Sent: 21 September 2006 13:03 > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > Subject: Re: Proposed liaison response to IEEE >=20 >=20 > All, >=20 > there have been a number of correct statements in this short thread. >=20 > Neil is right (given the layered network model) that Ethernet > is a layer network and as such connectionless and packet oriented. >=20 > Nurit is right that if you configure a VLAN on only to parts > of an Ethernet bridge the frame will go through without=20 > looking at the MAC address >=20 > Don is right that the liaison does not capture an earlier > comment he made on the gels-list. Neither does it capture a=20 > comment made by Attila. >=20 > However, if I understand what is happening here is that we > need to clarify a paragraph in the liaison form the IEEE802.1=20 > on translation of S-VIDs. >=20 > I guess that this is something we all need to understand, and > given the answer, it will be possible to follow up with=20 > further more precise questions. >=20 > If for example the answer on S-VID translation is that it is > not supported other than at domain borders, then the question=20 > on whether it needs to be done by taking the MAC-address into=20 > consideration or not will have very different meaning. >=20 > Let agree on getting the liaison out, and then decide on what > we do next depending on the answer. >=20 > /Loa >=20 > Nurit Sprecher wrote: > > Hi Neil, > > Thanks for your clarification. > > Please note that the discussion below relates to the > liaison that the > > IETF wants to send to the IEEE in order to understand the standard=20 > > behavior of the Ethernet forwarding behavior. As I > understand it, Don > > was concerned that S-VID translation does not preclude the > forwarding > > decision which is based on the MAC address. My intention > was to indicate > > that for point-to-point VLAN connection (on a link), MAC > learning is not > > required by the 802.1Qrev-5 spec and the forwarding > decision does not > > rely on the MAC address. This is not a discussion on > networking but on > > the standard behavior of the 802.1Q bridges. > > Regards, > > Nuritl. > >=20 > > ________________________________ > >=20 > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Thursday, September 21, 2006 13:00 > > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > > Subject: RE: Proposed liaison response to IEEE > >=20 > >=20 > > Nurit.....precision is indeed important. In a co mode > layer network > > connections can be p2p or p2mp in nature and each can be > composed of > > multiple concatenated subnetwork-connections (ie nodes in THIS layer > > network) and link-connections......noting that a single p2p > > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > > network is NOT a connection in THAT (ie Ethernet) layer network=20 > > (though it will be supported by a trail which is provided by a=20 > > connection in some lower layer network). > > =20 > > regards, Neil > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On > > Behalf Of Nurit Sprecher > > Sent: 21 September 2006 12:38 > > To: Don Fedyk; Adrian Farrel > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Nurit > > Sprecher > > Subject: RE: Proposed liaison response to IEEE > > =09 > > =09 > >=20 > > Hi, > >=20 > > =20 > >=20 > > I think it is a good idea to send the liaison to the > IEEE and get > > once and for all a clear statement that the s-vid translation is > > supported on each provider bridge port. > >=20 > > =20 > >=20 > > In addition, the IEEE has recognized that MAC learning is not > > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > > already includes this extension in section 8.7. > >=20 > > =20 > >=20 > > " The Learning Process receives the source MAC > Addresses and VIDs of > > received frames from the > >=20 > > Forwarding Process, following the application of the > ingress rules > > (8.6.2). It shall create or update a > >=20 > > Dynamic Filtering Entry (8.8.3) that specifies the > reception Port for > > the frame's source address and VID, if > >=20 > > and only if the source address is an Individual > Address, i.e., is not > > a Group Address, the resulting number of > >=20 > > entries would not exceed the capacity of the Filtering > Database, and > > the filtering utility criteria for the > >=20 > > receiving Bridge Port are met." > >=20 > > The enhanced filtering utility criteria "are satisfied > if at least > > one VLAN that uses the FID includes the reception Port and at least > > one other Port with a Port State of Learning or Forwarding in its=20 > > member set, and: a) The operPointToPointMAC parameter is=20 > false for the > > reception Port; or b) Ingress to the VLAN is permitted > through a third > > Port. NOTE -The third port can, but is not required to be in the > > member set.". > >=20 > > =20 > >=20 > > I think it is clearly stated, but if it is required to > ask the IEEE > > about the context of forwarding based on a destination MAC, > I suggest > > being more precise and specify that we are talking on > point-to-point > > connections. > >=20 > > =20 > >=20 > > Regards, > >=20 > > Nurit. > >=20 > > =20 > >=20 > > -----Original Message----- > > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On > > Behalf Of Don Fedyk > > Sent: Wednesday, September 20, 2006 23:16 > > To: Adrian Farrel; ccamp@ops.ietf.org > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > > Subject: RE: Proposed liaison response to IEEE > >=20 > > =20 > >=20 > > Hi Adrian > >=20 > > =20 > >=20 > > The Liaison looks good however it does not capture a comment I > > made. =20 > >=20 > > =20 > >=20 > > My understanding of the S-VLAN translation in IEEE > documents and the > >=20 > > liaison is that the translation is valid in the context > of forwarding > >=20 > > based on a destination MAC. My interpretation is that V-LAN is > > optional > >=20 > > MAC is not. If I am correct VLAN translation as > specified is not > > equal > >=20 > > to Label switching. The Liaison is clear about not just > the format of > >=20 > > 'packets on the wire' but the relationship to the > entities such as > > MAC > >=20 > > relay as well. > >=20 > > =20 > >=20 > > I think we should also ask in our liaison for > clarification if the > >=20 > > S-VLAN translation can be valid by itself i.e. as a > label agnostic to > >=20 > > the MAC so there is no confusion. > >=20 > > =20 > >=20 > > Thanks, > >=20 > > Don > >=20 > > =20 > >=20 > > =20 > >=20 > > > -----Original Message----- > >=20 > > > From: owner-ccamp@ops.ietf.org > >=20 > > > All, > >=20 > > > > >=20 > > > The IETF received an unsolicited liaison on the subject of > >=20 > > > 802.1 Ethernet > >=20 > > > > >=20 > > > You can see the liaison at > >=20 > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > >=20 > > > > >=20 > > > The participants on the GELS mailing list have requested that > >=20 > > > we respond to this to clarify an issue. > >=20 > > > > >=20 > > > Here is the draft of a liaison that we proposed to send. > >=20 > > > Please shout at once if you have any concerns with this > >=20 > > > liaison. I intend to ask Bert to send it on Monday of > next week. > >=20 > > > > >=20 > > > Thanks, > >=20 > > > Adrian > >=20 > > > =3D=3D=3D > >=20 > > > Subject: Response to your liaison "Use of IEEE 802.1Q > VLAN tags" > >=20 > > > > >=20 > > > Date: Sep 2006 > >=20 > > > To: IEEE802.1 > >=20 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > >=20 > > > > >=20 > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > >=20 > > > Deborah Brungard, IETF CCAMP Working Group co-chair > >=20 > > > > >=20 > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > >=20 > > > Ross Callon rcallon@juniper.net > >=20 > > > Bill Fenner fenner@research.att.com > >=20 > > > CCAMP mailing list ccamp@ops.ietf.org > >=20 > > > GELS mailing list gels@rtg.ietf.org > >=20 > > > > >=20 > > > Thank you for your very informative and clarifying liaison on > >=20 > > > "Use of IEEE 802.1Q VLAN tags". > >=20 > > > > >=20 > > > We have a question arising from this liaison and our reading > >=20 > > > of the relevant standards documents as follows. > >=20 > > > > >=20 > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > >=20 > > > bit VIDs) is supported at S-tagged service interfaces, as an > >=20 > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > >=20 > > > to IEEE Std 802.1Q." > >=20 > > > > >=20 > > > While this text in itself is clear it leaves open the > >=20 > > > question of whether "S-tagged Service interfaces" is the only > >=20 > > > type of interface where Translation of 802.1Q S-VLAN tags is > >=20 > > > supported. > >=20 > > > > >=20 > > > It is our understanding that IEEE Std 802.1ad does not > >=20 > > > preclude the translation of 802.1Q S-VLAN tags at any > >=20 > > > S-tagged interface. Thus, this translation would be allowed > >=20 > > > at Provider Network Ports, not just at Customer Network Ports. > >=20 > > > > >=20 > > > Can you please confirm whether this is the correct > >=20 > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > >=20 > > > Std 802.1Q? > >=20 > > > > >=20 > > > Many thanks, > >=20 > > > > >=20 > > > Bert Wijnen, IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel and Deborah Brungard, CCAMP Working > Group co-chairs > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > =20 > >=20 > > _______________________________________________ > >=20 > > gels mailing list > >=20 > > gels@rtg.ietf.org > >=20 > > https://rtg.ietf.org/mailman/listinfo/gels > >=20 > > =20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > 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 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 13:36:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 16:34:09 +0200 Message-ID: Thread-Topic: Proposed liaison response to IEEE Thread-Index: AcbddldP273KLlRIQzqoEjlyRQM/3gABdK1QAAN6wBA= From: "Nurit Sprecher" To: "Attila Takacs \(IJ/ETH\)" , "Loa Andersson" Cc: , , , "Nurit Sprecher" Out of scope of the discussion of the liaison... In general, I suggest that before statements on what is applicable and what is not, the IEEE standards are carefully learnt ....... (1) the enhanced filtering criteria does apply with S-VID translation.....there is a VLAN classification process at the ingress........the learning process and the forwarding decisions are taken on the internal VLAN to which the coming frame was classified.......the translation operation is performed after the outgoing port is determined........ (2) If that was true, the entire VLAN concept would loose it meaning............can not we support broadcasting of unknown frames correctly with s-vid translation??????????? (3) etc. Nurit. -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Attila Takacs (IJ/ETH) Sent: Thursday, September 21, 2006 14:59 To: Loa Andersson Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com Subject: RE: Proposed liaison response to IEEE Hi all, I also support the liaison as it is.=20 We will anyhow need to clarify a set of other issues later but these would now over complicated this liaison. BTW, I think the enhanced filtering criteria is not applicable if one applies S-VID translation since the ingress and egress VIDs are different. An other note: even when the enhanced filtering criteria is applied the MAC address is considered by forwarding however due to suppressed MAC learning (no entry for the MAC in FDB) the frame will be "broadcasted" over the (in this case) only one available egress VLAN member port. Regards, Attila > -----Original Message----- > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, September 21, 2006 2:03 PM > Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com > Subject: Re: Proposed liaison response to IEEE >=20 > All, >=20 > there have been a number of correct statements in this short thread. >=20 > Neil is right (given the layered network model) that Ethernet is a=20 > layer network and as such connectionless and packet oriented. >=20 > Nurit is right that if you configure a VLAN on only to parts of an=20 > Ethernet bridge the frame will go through without looking at the MAC=20 > address >=20 > Don is right that the liaison does not capture an earlier comment he=20 > made on the gels-list. Neither does it capture a comment made by=20 > Attila. >=20 > However, if I understand what is happening here is that we need to=20 > clarify a paragraph in the liaison form the IEEE802.1 on translation=20 > of S-VIDs. >=20 > I guess that this is something we all need to understand, and given=20 > the answer, it will be possible to follow up with further more precise > questions. >=20 > If for example the answer on S-VID translation is that it is not=20 > supported other than at domain borders, then the question on whether=20 > it needs to be done by taking the MAC-address into consideration or=20 > not will have very different meaning. >=20 > Let agree on getting the liaison out, and then decide on what we do=20 > next depending on the answer. >=20 > /Loa >=20 > Nurit Sprecher wrote: > > Hi Neil, > > Thanks for your clarification.=20 > > Please note that the discussion below relates to the > liaison that the > > IETF wants to send to the IEEE in order to understand the standard=20 > > behavior of the Ethernet forwarding behavior. As I > understand it, Don > > was concerned that S-VID translation does not preclude the > forwarding > > decision which is based on the MAC address. My intention was to=20 > > indicate that for point-to-point VLAN connection (on a link), MAC=20 > > learning is not required by the 802.1Qrev-5 spec and the forwarding=20 > > decision does not rely on the MAC address. This is not a > discussion on > > networking but on the standard behavior of the 802.1Q bridges. > > Regards, > > Nuritl. > >=20 > > ________________________________ > >=20 > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Thursday, September 21, 2006 13:00 > > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > > Subject: RE: Proposed liaison response to IEEE > >=20 > >=20 > > Nurit.....precision is indeed important. In a co mode > layer network > > connections can be p2p or p2mp in nature and each can be > composed of > > multiple concatenated subnetwork-connections (ie nodes in THIS layer > > network) and link-connections......noting that a single p2p=20 > > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > > network is NOT a connection in THAT (ie Ethernet) layer network=20 > > (though it will be supported by a trail which is provided by a=20 > > connection in some lower layer network). > > =20 > > regards, Neil > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On > > Behalf Of Nurit Sprecher > > Sent: 21 September 2006 12:38 > > To: Don Fedyk; Adrian Farrel > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Nurit > > Sprecher > > Subject: RE: Proposed liaison response to IEEE > > =09 > > =09 > >=20 > > Hi, > >=20 > > =20 > >=20 > > I think it is a good idea to send the liaison to the > IEEE and get > > once and for all a clear statement that the s-vid translation is=20 > > supported on each provider bridge port. > >=20 > > =20 > >=20 > > In addition, the IEEE has recognized that MAC learning is not=20 > > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > > already includes this extension in section 8.7. > >=20 > > =20 > >=20 > > " The Learning Process receives the source MAC > Addresses and VIDs of > > received frames from the > >=20 > > Forwarding Process, following the application of the > ingress rules > > (8.6.2). It shall create or update a > >=20 > > Dynamic Filtering Entry (8.8.3) that specifies the > reception Port for > > the frame's source address and VID, if > >=20 > > and only if the source address is an Individual > Address, i.e., is not > > a Group Address, the resulting number of > >=20 > > entries would not exceed the capacity of the Filtering > Database, and > > the filtering utility criteria for the > >=20 > > receiving Bridge Port are met." > >=20 > > The enhanced filtering utility criteria "are satisfied > if at least > > one VLAN that uses the FID includes the reception Port and at least=20 > > one other Port with a Port State of Learning or Forwarding in its=20 > > member set, and: a) The operPointToPointMAC parameter is > false for the > > reception Port; or b) Ingress to the VLAN is permitted > through a third > > Port. NOTE -The third port can, but is not required to be in the=20 > > member set.". > >=20 > > =20 > >=20 > > I think it is clearly stated, but if it is required to > ask the IEEE > > about the context of forwarding based on a destination MAC, > I suggest > > being more precise and specify that we are talking on > point-to-point > > connections. > >=20 > > =20 > >=20 > > Regards, > >=20 > > Nurit. > >=20 > > =20 > >=20 > > -----Original Message----- > > From: gels-bounces@rtg.ietf.org > > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > > Sent: Wednesday, September 20, 2006 23:16 > > To: Adrian Farrel; ccamp@ops.ietf.org > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > > Subject: RE: Proposed liaison response to IEEE > >=20 > > =20 > >=20 > > Hi Adrian > >=20 > > =20 > >=20 > > The Liaison looks good however it does not capture a comment I > > made. =20 > >=20 > > =20 > >=20 > > My understanding of the S-VLAN translation in IEEE > documents and the > >=20 > > liaison is that the translation is valid in the context > of forwarding > >=20 > > based on a destination MAC. My interpretation is that V-LAN is=20 > > optional > >=20 > > MAC is not. If I am correct VLAN translation as > specified is not > > equal > >=20 > > to Label switching. The Liaison is clear about not just > the format of > >=20 > > 'packets on the wire' but the relationship to the > entities such as > > MAC > >=20 > > relay as well. =20 > >=20 > > =20 > >=20 > > I think we should also ask in our liaison for > clarification if the > >=20 > > S-VLAN translation can be valid by itself i.e. as a > label agnostic to > >=20 > > the MAC so there is no confusion. > >=20 > > =20 > >=20 > > Thanks, > >=20 > > Don > >=20 > > =20 > >=20 > > =20 > >=20 > > > -----Original Message----- > >=20 > > > From: owner-ccamp@ops.ietf.org > >=20 > > > All, > >=20 > > > > >=20 > > > The IETF received an unsolicited liaison on the subject of > >=20 > > > 802.1 Ethernet > >=20 > > > > >=20 > > > You can see the liaison at > >=20 > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > >=20 > > > > >=20 > > > The participants on the GELS mailing list have requested that > >=20 > > > we respond to this to clarify an issue. > >=20 > > > > >=20 > > > Here is the draft of a liaison that we proposed to send.=20 > >=20 > > > Please shout at once if you have any concerns with this > >=20 > > > liaison. I intend to ask Bert to send it on Monday of > next week. > >=20 > > > > >=20 > > > Thanks, > >=20 > > > Adrian > >=20 > > > =3D=3D=3D > >=20 > > > Subject: Response to your liaison "Use of IEEE 802.1Q > VLAN tags" > >=20 > > > > >=20 > > > Date: Sep 2006 > >=20 > > > To: IEEE802.1 > >=20 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > >=20 > > > > >=20 > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > >=20 > > > Deborah Brungard, IETF CCAMP Working Group co-chair > >=20 > > > > >=20 > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > >=20 > > > Ross Callon rcallon@juniper.net > >=20 > > > Bill Fenner fenner@research.att.com > >=20 > > > CCAMP mailing list ccamp@ops.ietf.org > >=20 > > > GELS mailing list gels@rtg.ietf.org > >=20 > > > > >=20 > > > Thank you for your very informative and clarifying liaison on > >=20 > > > "Use of IEEE 802.1Q VLAN tags". > >=20 > > > > >=20 > > > We have a question arising from this liaison and our reading > >=20 > > > of the relevant standards documents as follows. > >=20 > > > > >=20 > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > >=20 > > > bit VIDs) is supported at S-tagged service interfaces, as an > >=20 > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > >=20 > > > to IEEE Std 802.1Q." > >=20 > > > > >=20 > > > While this text in itself is clear it leaves open the > >=20 > > > question of whether "S-tagged Service interfaces" is the only > >=20 > > > type of interface where Translation of 802.1Q S-VLAN tags is > >=20 > > > supported. > >=20 > > > > >=20 > > > It is our understanding that IEEE Std 802.1ad does not > >=20 > > > preclude the translation of 802.1Q S-VLAN tags at any > >=20 > > > S-tagged interface. Thus, this translation would be allowed > >=20 > > > at Provider Network Ports, not just at Customer Network Ports. > >=20 > > > > >=20 > > > Can you please confirm whether this is the correct > >=20 > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > >=20 > > > Std 802.1Q? > >=20 > > > > >=20 > > > Many thanks, > >=20 > > > > >=20 > > > Bert Wijnen, IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel and Deborah Brungard, CCAMP Working > Group co-chairs > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > =20 > >=20 > > _______________________________________________ > >=20 > > gels mailing list > >=20 > > gels@rtg.ietf.org > >=20 > > https://rtg.ietf.org/mailman/listinfo/gels > >=20 > > =20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > 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=20 > _______________________________________________ > gels mailing list > gels@rtg.ietf.org > https://rtg.ietf.org/mailman/listinfo/gels >=20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 12:59:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 14:59:15 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D05012D42A2@esealmw116.eemea.ericsson.se> Thread-Topic: Proposed liaison response to IEEE Thread-Index: AcbddldP273KLlRIQzqoEjlyRQM/3gABdK1Q From: "Attila Takacs \(IJ/ETH\)" To: "Loa Andersson" Cc: , , Hi all, I also support the liaison as it is.=20 We will anyhow need to clarify a set of other issues later but these would now over complicated this liaison. BTW, I think the enhanced filtering criteria is not applicable if one applies S-VID translation since the ingress and egress VIDs are different. An other note: even when the enhanced filtering criteria is applied the MAC address is considered by forwarding however due to suppressed MAC learning (no entry for the MAC in FDB) the frame will be "broadcasted" over the (in this case) only one available egress VLAN member port. Regards, Attila > -----Original Message----- > From: gels-bounces@rtg.ietf.org=20 > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, September 21, 2006 2:03 PM > Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com > Subject: Re: Proposed liaison response to IEEE >=20 > All, >=20 > there have been a number of correct statements in this short thread. >=20 > Neil is right (given the layered network model) that Ethernet=20 > is a layer network and as such connectionless and packet oriented. >=20 > Nurit is right that if you configure a VLAN on only to parts=20 > of an Ethernet bridge the frame will go through without=20 > looking at the MAC address >=20 > Don is right that the liaison does not capture an earlier=20 > comment he made on the gels-list. Neither does it capture a=20 > comment made by Attila. >=20 > However, if I understand what is happening here is that we=20 > need to clarify a paragraph in the liaison form the IEEE802.1=20 > on translation of S-VIDs. >=20 > I guess that this is something we all need to understand, and=20 > given the answer, it will be possible to follow up with=20 > further more precise questions. >=20 > If for example the answer on S-VID translation is that it is=20 > not supported other than at domain borders, then the question=20 > on whether it needs to be done by taking the MAC-address into=20 > consideration or not will have very different meaning. >=20 > Let agree on getting the liaison out, and then decide on what=20 > we do next depending on the answer. >=20 > /Loa >=20 > Nurit Sprecher wrote: > > Hi Neil, > > Thanks for your clarification.=20 > > Please note that the discussion below relates to the=20 > liaison that the=20 > > IETF wants to send to the IEEE in order to understand the standard=20 > > behavior of the Ethernet forwarding behavior. As I=20 > understand it, Don=20 > > was concerned that S-VID translation does not preclude the=20 > forwarding=20 > > decision which is based on the MAC address. My intention was to=20 > > indicate that for point-to-point VLAN connection (on a link), MAC=20 > > learning is not required by the 802.1Qrev-5 spec and the forwarding=20 > > decision does not rely on the MAC address. This is not a=20 > discussion on=20 > > networking but on the standard behavior of the 802.1Q bridges. > > Regards, > > Nuritl. > >=20 > > ________________________________ > >=20 > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Thursday, September 21, 2006 13:00 > > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > > Subject: RE: Proposed liaison response to IEEE > >=20 > >=20 > > Nurit.....precision is indeed important. In a co mode=20 > layer network=20 > > connections can be p2p or p2mp in nature and each can be=20 > composed of=20 > > multiple concatenated subnetwork-connections (ie nodes in THIS layer > > network) and link-connections......noting that a single p2p=20 > > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > > network is NOT a connection in THAT (ie Ethernet) layer network=20 > > (though it will be supported by a trail which is provided by a=20 > > connection in some lower layer network). > > =20 > > regards, Neil > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of Nurit Sprecher > > Sent: 21 September 2006 12:38 > > To: Don Fedyk; Adrian Farrel > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert);=20 > ccamp@ops.ietf.org; Nurit=20 > > Sprecher > > Subject: RE: Proposed liaison response to IEEE > > =09 > > =09 > >=20 > > Hi, > >=20 > > =20 > >=20 > > I think it is a good idea to send the liaison to the=20 > IEEE and get=20 > > once and for all a clear statement that the s-vid translation is=20 > > supported on each provider bridge port. > >=20 > > =20 > >=20 > > In addition, the IEEE has recognized that MAC learning is not=20 > > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > > already includes this extension in section 8.7. > >=20 > > =20 > >=20 > > " The Learning Process receives the source MAC=20 > Addresses and VIDs of=20 > > received frames from the > >=20 > > Forwarding Process, following the application of the=20 > ingress rules=20 > > (8.6.2). It shall create or update a > >=20 > > Dynamic Filtering Entry (8.8.3) that specifies the=20 > reception Port for=20 > > the frame's source address and VID, if > >=20 > > and only if the source address is an Individual=20 > Address, i.e., is not=20 > > a Group Address, the resulting number of > >=20 > > entries would not exceed the capacity of the Filtering=20 > Database, and=20 > > the filtering utility criteria for the > >=20 > > receiving Bridge Port are met." > >=20 > > The enhanced filtering utility criteria "are satisfied=20 > if at least=20 > > one VLAN that uses the FID includes the reception Port and at least=20 > > one other Port with a Port State of Learning or Forwarding in its=20 > > member set, and: a) The operPointToPointMAC parameter is=20 > false for the=20 > > reception Port; or b) Ingress to the VLAN is permitted=20 > through a third=20 > > Port. NOTE -The third port can, but is not required to be in the=20 > > member set.". > >=20 > > =20 > >=20 > > I think it is clearly stated, but if it is required to=20 > ask the IEEE=20 > > about the context of forwarding based on a destination MAC,=20 > I suggest=20 > > being more precise and specify that we are talking on=20 > point-to-point=20 > > connections. > >=20 > > =20 > >=20 > > Regards, > >=20 > > Nurit. > >=20 > > =20 > >=20 > > -----Original Message----- > > From: gels-bounces@rtg.ietf.org > > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > > Sent: Wednesday, September 20, 2006 23:16 > > To: Adrian Farrel; ccamp@ops.ietf.org > > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > > Subject: RE: Proposed liaison response to IEEE > >=20 > > =20 > >=20 > > Hi Adrian > >=20 > > =20 > >=20 > > The Liaison looks good however it does not capture a comment I > > made. =20 > >=20 > > =20 > >=20 > > My understanding of the S-VLAN translation in IEEE=20 > documents and the > >=20 > > liaison is that the translation is valid in the context=20 > of forwarding > >=20 > > based on a destination MAC. My interpretation is that V-LAN is=20 > > optional > >=20 > > MAC is not. If I am correct VLAN translation as=20 > specified is not=20 > > equal > >=20 > > to Label switching. The Liaison is clear about not just=20 > the format of > >=20 > > 'packets on the wire' but the relationship to the=20 > entities such as=20 > > MAC > >=20 > > relay as well. =20 > >=20 > > =20 > >=20 > > I think we should also ask in our liaison for=20 > clarification if the > >=20 > > S-VLAN translation can be valid by itself i.e. as a=20 > label agnostic to > >=20 > > the MAC so there is no confusion. > >=20 > > =20 > >=20 > > Thanks, > >=20 > > Don > >=20 > > =20 > >=20 > > =20 > >=20 > > > -----Original Message----- > >=20 > > > From: owner-ccamp@ops.ietf.org > >=20 > > > All, > >=20 > > > > >=20 > > > The IETF received an unsolicited liaison on the subject of > >=20 > > > 802.1 Ethernet > >=20 > > > > >=20 > > > You can see the liaison at > >=20 > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > >=20 > > > > >=20 > > > The participants on the GELS mailing list have requested that > >=20 > > > we respond to this to clarify an issue. > >=20 > > > > >=20 > > > Here is the draft of a liaison that we proposed to send.=20 > >=20 > > > Please shout at once if you have any concerns with this > >=20 > > > liaison. I intend to ask Bert to send it on Monday of=20 > next week. > >=20 > > > > >=20 > > > Thanks, > >=20 > > > Adrian > >=20 > > > =3D=3D=3D > >=20 > > > Subject: Response to your liaison "Use of IEEE 802.1Q=20 > VLAN tags" > >=20 > > > > >=20 > > > Date: Sep 2006 > >=20 > > > To: IEEE802.1 > >=20 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > >=20 > > > > >=20 > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > >=20 > > > Deborah Brungard, IETF CCAMP Working Group co-chair > >=20 > > > > >=20 > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > >=20 > > > Ross Callon rcallon@juniper.net > >=20 > > > Bill Fenner fenner@research.att.com > >=20 > > > CCAMP mailing list ccamp@ops.ietf.org > >=20 > > > GELS mailing list gels@rtg.ietf.org > >=20 > > > > >=20 > > > Thank you for your very informative and clarifying liaison on > >=20 > > > "Use of IEEE 802.1Q VLAN tags". > >=20 > > > > >=20 > > > We have a question arising from this liaison and our reading > >=20 > > > of the relevant standards documents as follows. > >=20 > > > > >=20 > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > >=20 > > > bit VIDs) is supported at S-tagged service interfaces, as an > >=20 > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > >=20 > > > to IEEE Std 802.1Q." > >=20 > > > > >=20 > > > While this text in itself is clear it leaves open the > >=20 > > > question of whether "S-tagged Service interfaces" is the only > >=20 > > > type of interface where Translation of 802.1Q S-VLAN tags is > >=20 > > > supported. > >=20 > > > > >=20 > > > It is our understanding that IEEE Std 802.1ad does not > >=20 > > > preclude the translation of 802.1Q S-VLAN tags at any > >=20 > > > S-tagged interface. Thus, this translation would be allowed > >=20 > > > at Provider Network Ports, not just at Customer Network Ports. > >=20 > > > > >=20 > > > Can you please confirm whether this is the correct > >=20 > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > >=20 > > > Std 802.1Q? > >=20 > > > > >=20 > > > Many thanks, > >=20 > > > > >=20 > > > Bert Wijnen, IETF liaison to IEEE 802.1 > >=20 > > > Adrian Farrel and Deborah Brungard, CCAMP Working=20 > Group co-chairs > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > =20 > >=20 > > _______________________________________________ > >=20 > > gels mailing list > >=20 > > gels@rtg.ietf.org > >=20 > > https://rtg.ietf.org/mailman/listinfo/gels > >=20 > > =20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > 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=20 > _______________________________________________ > gels mailing list > gels@rtg.ietf.org > https://rtg.ietf.org/mailman/listinfo/gels >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 12:32:39 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-36-146102614 Message-Id: Cc: , "Ross Callon" From: JP Vasseur Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Thu, 21 Sep 2006 08:32:08 -0400 To: "Adrian Farrel" DKIM-Signature: a=rsa-sha1; q=dns; l=32785; t=1158841933; x=1159705933; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20Routing=20Directorate=20comments=20on=20draft-ietf-ccamp-automes h-01 |To:=22Adrian=20Farrel=22=20; X=v=3Dcisco.com=3B=20h=3DMEBChjdj4/CIq2s4jZyCacxjCHY=3D; b=sXj5s6poseORm4S1h5YvITMwou/LKpYraejs7ohNNUIhXCNhklGdGcrodhrzcKQ4vJxkPtgd kD8SKBPcfD7rAs1u+sPkPgec9jn8k4gmeMRMQFhNZFSA89AEcESREZE6; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); --Apple-Mail-36-146102614 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi Adrian, On Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote: > Hi, > > We held an additional last call for this draft in the IGP working =20 > groups and received some further comments that JP has just =20 > addressed in a new revision. > > We have also received some comments from a review in the Routing =20 > Directorate that I am pr=E9cising below. JP, authors: please look =20 > through these and let us know your proposals for dealing with them. > Sure, in line. > Thanks, > Adrian > > =3D=3D=3D > > 1) The Tail-end name field facilitates LSP identification. Is this =20 > a new form of LSP identification? > If it is not new, then there should be a reference to RFC3209 and a =20= > statement of which RFC3209 fields are mapped to this IGP field. > If it is not new then there is a significant concern that a new =20 > identification is being introduced when it is not needed. As indicated in the document the string refers to a "Tail-end" name, =20 not an TE LSP name: thus it does not replace the session name of the =20 SESSION-ATTRIBUTE object defined in RFC3209. > > 2) The document mentions that the number of mesh groups is limited =20 > but potentially (depending on encoding) provides for binary =20 > encoding for > 2^32-1 groups (although this might be constrained by OSPF's limit =20 > of a TLV size to 2^16 bytes. > The document (and the authors) state that scaling of these =20 > extensions is not an issue because only a small number of mesh =20 > groups are likely to be in existence in a network, and any one =20 > router is unlikely to participate in more than a very few. > There are two concerns: > a) Whenever we say that something in the Internet is limited, =20 > history usually proves us wrong. And that's undoubtedly a good news :-) > Indeed, there is already a > proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a =20 > similar mechanism for a problem that would have far more groups. Two comments: - Mesh groups are used to set up TE LSP meshes. If we consider let =20 say 10 meshes comprising 100 routers each, that gives us 99,000 TE =20 LSPs. One can easily see that the number of meshes is unlikely to =20 explode in a foreseeable future. If it turns out to be the case, =20 we'll have other scalability issues to fix before any potential with =20 the IGP. - More importantly, the dynamics of joining a TE mesh is such that =20 IGP updates are used to advertise to TE mesh group membership change =20 (join or prune), which are indeed expected to be very unfrequent. > b) The I-D does not itself impose any reasonable limits on the =20 > number of groups with the potential for a single router (by =20 > misconfiguration, design, or malice) advertising a very large =20 > number of groups. > Thus, it appears that the scaling concerns are not properly =20 > addressed in this I-D. > Not sure to see the point here. If indeed, a large number of TE MESH =20 GROUPs were advertised, this would not impact the other LSRs since =20 they would not create any new TE LSPs trying to join the new TE-MESH-=20 GROUP. In term of amount of flooded information, this should not be a =20= concern either (handled by routing). We clarified this in the =20 security section. > 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL =20 > and must at most appear once in a OSPF Router Information LSA or =20 > ISIS Router Capability TLV." but for addition/removal it mentions =20 > "conversely, if the LSR leaves a mesh-group the corresponding entry =20= > will be removed from the TE-MESH-GROUP TLV." > What are these "entries" referring to - that there is a top-level =20 > TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions =20= > "No sub-TLV is currently defined for the TE-mesh-group TLV") ? > > AF>> My comment on this is that the definition of the TLVs seems =20 > unclear. > AF>> =46rom figure 2, it appears that some additional information can = be > AF>> present in the TLV after the fields listed, and (reading =20 > between the > AF>> lines) it would appear that this additional information is a =20 > series of > AF>> repeats of the set of fields to define multiple mesh groups. > AF>> This could usefully be clarified considerably. > You're absolutely right. The figures have been modified: (example show below): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // /=20= / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) > AF>> > AF>> But it is now unclear to me whether a single router can be a =20 > member > AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be > AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one > AF>> IPv6) are prohibited. OK the text requires some clarification. What is prohibited is to =20 have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is =20 permitted. New proposed text to clarify: The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and =20 one IPv6 instance MUST appear in a OSPF Router Information LSA or =20 ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or =20 IPv6) occurs more than once within the OSPF Router Information LSA, =20 only the first instance is processed, subsequent TLV(s) will be =20 silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 =20 or IPv6) occurs more than once within the ISIS Router capability TLV, =20= only the first instance is processed, subsequent TLV(s) will be =20 silently ignored. > > 4) Small terminology issue in section 5.1 it says: "Note that both =20 > operations can be performed in the context of a single refresh." > This is not a refresh. It is a trigger/update. A better term for =20 > OSPF would be "LSA origination". > OK fixed (I used the term "Update"), thanks. > 5) Please state the applicability to OSPF v2 and or v3. Note that =20 > the Router_Cap document covers both v2 and v3 Indeed, Thanks for the comments. The OSPFv3 aspects have been =20 incorporated. Here is the new text: The TE-MESH-GROUP TLV is advertised within an OSPF Router =20 Information opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328]) and within a new LSA (Router Information LSA) for OSPFv3 =20 ([RFC2740]). ... As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the flooding scope of the Router Information LSA is determined by the =20= LSA Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. For OSPFv2 Router Information opaque LSA: - Link-local scope: type 9; - Area-local scope: type 10; - Routing-domain scope: type 11. In this case, the flooding =20 scope is equivalent to the Type 5 LSA flooding scope. For OSPFv3 Router Information LSA: - Link-local scope: OSPFV3 Router Information LSA with the S1 and S2 bits cleared; - Area-local scope: OSPFV3 Router Information LSA with the S1 bit =20= set and the S2 bit cleared; - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit cleared and the S2 bit set. A router may generate multiple OSPF Router Information LSAs with different flooding scopes. The TE-MESH-GROUP TLV may be advertised within an Area-local or Routing-domain scope Router Information LSA depending on the MPLS TE mesh group profile: - If the MPLS TE mesh-group is contained within a single area (all the LSRs of the mesh-group are contained within a single area), the TE-MESH-GROUP TLV MUST be generated within an Area-local Router Information LSA; - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- group TLV MUST be generated within a Routing-domain scope router information LSA. > > 6) The term "fairly static" at the end of section 5.1 is =20 > meaningless without some relative context. > Presumably this relates to the number times an LSR joins or leaves =20 > a mesh group over time. > Is it intended to be relative to the IGP refresh period? > Please clarify in an objective rather than a subjective way. > Right, this requires clarification. Here is the new text: Moreover, =20 TE mesh-group membership should not change frequently: each time an =20 LSR joins or leaves a new TE mesh-group. I guess that this is sufficiently explicit: it is a well-known fact =20 that LSRs are infrequently added or removed to a TE mesh. > 7) The security section (section 8) is inadequate and will =20 > undoubtedly be rejected by the security ADs. At the very least, the =20= > I-D needs a paragraph (i.e. more than one or two lines) explaining =20 > why there are no new security considerations. But what would be the =20= > impact of adding false mesh groups to a TLV? Is there anything =20 > (dangerous) that can be learned about the network by inspecting =20 > mesh group TLVs? > The following section has been added: No new security issues are raised in this document. Any new =20 security issues raised by the procedures in this document depend upon the opportunity for LSAs/LSPs to be snooped, the ease/difficulty of =20 which has not been altered. Security considerations are covered in [RFC2328] and [RFC2740] for the base OSPF protocol and in [RFC1194] for IS-IS. As the LSPs may now contain additional information regarding router capabilities, this new information would also =20 become available. Note that intentional or unintentional advertisement of "fake" TE Mesh Groups by an LSR A does not have any impact on other LSRs since an LSR B would only try to signal a TE LSP torward that advertizing LSR A to join the advertized TE Mesh TE Group if and =20 only if such TE Mesh Group is also locally configured on LSR B. + new references added. Does that address the comments ? Thanks. JP.= --Apple-Mail-36-146102614 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

On = Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote:

Hi,

We held an additional last call = for this draft in the IGP working groups and received some further = comments that JP has just addressed in a new revision.

We have = also received some comments from a review in the Routing Directorate = that I am pr=E9cising below. JP, authors: please look through these and = let us know your proposals for dealing with them.


Sure, in = line.

Thanks,
Adrian

=3D=3D=3D

1) The = Tail-end name field facilitates LSP identification. Is this a new form = of LSP identification?
If it is not new, then = there should be a reference to RFC3209 and a statement of which RFC3209 = fields are mapped to this IGP field.
If it is not = new then there is a significant concern that a new identification is = being introduced when it is not needed.

As indicated in the = document the string refers to a "Tail-end" name, not an TE LSP name: = thus it does not replace the session name of the SESSION-ATTRIBUTE = object defined in RFC3209.=A0


2) The = document mentions that the number of mesh groups is limited but = potentially (depending on encoding) provides for binary encoding = for
2^32-1 groups (although this = might be constrained by OSPF's limit of a TLV size to 2^16 = bytes.
The document (and the authors) = state that scaling of these extensions is not an issue because only a = small number of mesh groups are likely to be in existence in a network, = and any one router is unlikely to participate in more than a very = few.
There are two = concerns:
a) Whenever we say that = something in the Internet is limited, history usually proves us wrong. =

And that's undoubtedly a = good news :-)=A0

Indeed, there is already a
proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) = that uses a similar mechanism for a problem that would have far more = groups.

Two comments:
- = Mesh groups are used to set up TE LSP meshes. If we consider let say 10 = meshes comprising 100 routers each, that gives us 99,000 TE LSPs. One = can easily see that the number of meshes is unlikely to explode in = a=A0foreseeable future. If it turns out to be the case, we'll have other = scalability issues to fix before any potential with the IGP.
- = More importantly, the dynamics of joining a TE mesh is such that IGP = updates are used to advertise to TE mesh group membership change (join = or prune), which are indeed expected to be very = unfrequent.

b) The = I-D does not itself impose any reasonable limits on the number of groups = with the potential for a single router (by misconfiguration, design, or = malice) advertising a very large number of groups.
Thus, it appears that the scaling concerns are not = properly addressed in this I-D.


Not sure to see the point = here. If indeed, a large number of TE MESH GROUPs were advertised, this = would not impact the other LSRs since they would not create any new TE = LSPs trying to join the new TE-MESH-GROUP. In term of amount of flooded = information, this should not be a concern either (handled by routing). = We clarified this in the security section.

3) The document mentions that "The TE-MESH-GROUP TLV = is OPTIONAL and must at most appear once in a OSPF Router Information = LSA or ISIS Router Capability TLV." but for addition/removal it mentions = "conversely, if the LSR leaves a mesh-group the corresponding entry will = be removed from the TE-MESH-GROUP TLV."
What are = these "entries" referring to - that there is a top-level TE-MESH-GROUP = TLV with multiple sub-TLVs (but the document mentions "No sub-TLV is = currently defined for the TE-mesh-group TLV") ?

AF>> =46rom figure 2, it = appears that some additional information can be
AF>> present in the TLV after the fields = listed, and (reading between the
AF>> = lines) it would appear that this additional information is a series = of
AF>> repeats of the set of fields to = define multiple mesh groups.
AF>> = This could usefully be clarified considerably.


You're absolutely right. = The figures have been modified:

(example show = below):

=A0 =A0= =A0=A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = mesh-group-number 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Tail-end IPv4 = address 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 Name length=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = Tail-end name 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0=A0 //=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = //
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = mesh-group-number n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Tail-end IPv4 = address n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0=A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
=A0 =A0 =A0 |=A0 Name length=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = Tail-end name n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0 =A0 =A0 =A0 =A0 = Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)


AF>>
AF>> = But it is now unclear to me whether a single router can be a = member
AF>> of IPv4 an IPv6 mesh = groups. It would seem that these cannot be
AF>> IPv6) are = prohibited.

OK the text requires some = clarification. What is prohibited is to have two IPv4 sub-TLV or two = IPv6 sub-TLV but one of each is permitted. New proposed text to = clarify:

The= TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and one = IPv6 instance MUST appear in a OSPF Router Information LSA or ISIS = Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) = occurs more than once within the OSPF Router Information LSA, only the = first instance is processed, subsequent TLV(s) will be silently ignored. = Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 or IPv6) occurs more = than once within the ISIS Router capability TLV, only the first instance = is processed, subsequent TLV(s) will be silently = ignored.


4) Small = terminology issue in section 5.1 it says: "Note that both operations can = be performed in the context of a single refresh."
This is not a refresh. It is a trigger/update. A = better term for OSPF would be "LSA origination".


OK fixed (I used the term = "Update"), thanks.

5) = Please state the applicability to OSPF v2 and or v3. Note that the = Router_Cap document covers both v2 and v3

Indeed, Thanks for the = comments.=A0 The OSPFv3 aspects have been incorporated. Here is the new = text:

=A0 = =A0The TE-MESH-GROUP TLV is advertised within an OSPF Router = Information
=A0=A0 opaque LSA (opaque type of 4, opaque = ID of 0) for OSPFv2 ([RFC2328])
=A0=A0 and within a new = LSA (Router Information LSA) for OSPFv3 = ([RFC2740]).

...
<= BR class=3D"khtml-block-placeholder">
=A0 =A0As defined = in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, = the
=A0=A0 flooding scope of the Router Information LSA = is determined by the LSA
=A0=A0 Opaque type for OSPFv2 = and the values of the S1/S2 bits for OSPFv3.

=A0=A0 For OSPFv2 = Router Information opaque LSA:

=A0=A0 - Link-local = scope: type 9;

=A0=A0 - Area-local = scope: type 10;

=A0=A0 - = Routing-domain scope: type 11.=A0 In this case, the flooding scope = is
=A0=A0 equivalent to the Type 5 LSA flooding = scope.

=A0=A0 For OSPFv3 = Router Information LSA:

=A0=A0 - Link-local = scope: OSPFV3 Router Information LSA with the S1 and = S2
=A0=A0 bits cleared;

=A0=A0 - Area-local = scope: OSPFV3 Router Information LSA with the S1 bit = set
=A0=A0 and the S2 bit cleared;

=A0=A0 - = Routing-domain scope: OSPFv3 Router Information LSA with S1 = bit
=A0 =A0cleared and the S2 bit = set.

=A0=A0 A router may = generate multiple OSPF Router Information LSAs with
=A0=A0= different flooding scopes.=A0 The TE-MESH-GROUP TLV may be = advertised
=A0=A0 within an Area-local or = Routing-domain scope Router Information LSA
=A0=A0 = depending on the MPLS TE mesh group profile:

=A0=A0 - If the MPLS = TE mesh-group is contained within a single area (all
=A0=A0= the LSRs of the mesh-group are contained within a single area), = the
=A0=A0 TE-MESH-GROUP TLV MUST be generated within = an Area-local Router
=A0=A0 Information = LSA;

=A0=A0 - If the MPLS = TE mesh-group spans multiple OSPF areas, the TE = mesh-
=A0=A0 group TLV MUST be generated within a = Routing-domain scope router
=A0=A0 information = LSA.


6) The = term "fairly static" at the end of section 5.1 is meaningless without = some relative context.
Presumably this relates to = the number times an LSR joins or leaves a mesh group over = time.
Is it intended to be relative to = the IGP refresh period?
Please = clarify in an objective rather than a subjective way.


Right, this requires = clarification. Here is the new text:=A0Moreover, TE mesh-group = membership should not change frequently: each time an LSR joins or = leaves a new TE mesh-group.=A0

I guess that this is = sufficiently explicit: it is a well-known fact that LSRs = are=A0infrequently added or removed to a TE mesh.

7) The security section (section 8) is inadequate = and will undoubtedly be rejected by the security ADs. At the very least, = the I-D needs a paragraph (i.e. more than one or two lines) explaining = why there are no new security considerations. But what would be the = impact of adding false mesh groups to a TLV? Is there anything = (dangerous) that can be learned about the network by inspecting mesh = group TLVs?

=

The following section has been = added:

=A0 =A0No new security issues are raised = in this document.=A0 Any new security
=A0=A0 = issues raised by the procedures in this document depend upon = the
=A0=A0 opportunity for LSAs/LSPs to be snooped, the = ease/difficulty of which
=A0=A0 has not been altered.=A0 = Security considerations are covered in
=A0=A0 [RFC2328] = and [RFC2740] for the base OSPF protocol and in = [RFC1194]
=A0=A0 for IS-IS.=A0 As the LSPs may now = contain additional information
=A0=A0 regarding router = capabilities, this new information would also become
=A0 = =A0available.=A0 Note that intentional or unintentional advertisement = of
=A0=A0 "fake" TE Mesh Groups by an LSR A does not = have any impact on other
=A0=A0 LSRs since an LSR B = would only try to signal a TE LSP torward that
=A0=A0 = advertizing LSR A to join the advertized TE Mesh TE Group if and = only
=A0=A0 if such TE Mesh Group is also locally = configured on LSR B.

+ new references = added.


Does that address the = comments ?

Thanks.

JP.
= --Apple-Mail-36-146102614-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 12:21:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 15:20:02 +0200 Message-ID: Thread-Topic: Proposed liaison response to IEEE Thread-Index: AcbdftFBQ4XXOrHzQmehkQbu8IRfdwAAc4dA From: "Nurit Sprecher" To: "Loa Andersson" Cc: , , I approve the liaison as stated.=20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Loa Andersson Sent: Thursday, September 21, 2006 14:03 Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; bwijnen@lucent.com Subject: Re: Proposed liaison response to IEEE All, there have been a number of correct statements in this short thread. Neil is right (given the layered network model) that Ethernet is a layer network and as such connectionless and packet oriented. Nurit is right that if you configure a VLAN on only to parts of an Ethernet bridge the frame will go through without looking at the MAC address Don is right that the liaison does not capture an earlier comment he made on the gels-list. Neither does it capture a comment made by Attila. However, if I understand what is happening here is that we need to clarify a paragraph in the liaison form the IEEE802.1 on translation of S-VIDs. I guess that this is something we all need to understand, and given the answer, it will be possible to follow up with further more precise questions. If for example the answer on S-VID translation is that it is not supported other than at domain borders, then the question on whether it needs to be done by taking the MAC-address into consideration or not will have very different meaning. Let agree on getting the liaison out, and then decide on what we do next depending on the answer. /Loa Nurit Sprecher wrote: > Hi Neil, > Thanks for your clarification.=20 > Please note that the discussion below relates to the liaison that the=20 > IETF wants to send to the IEEE in order to understand the standard=20 > behavior of the Ethernet forwarding behavior. As I understand it, Don=20 > was concerned that S-VID translation does not preclude the forwarding=20 > decision which is based on the MAC address. My intention was to=20 > indicate that for point-to-point VLAN connection (on a link), MAC=20 > learning is not required by the 802.1Qrev-5 spec and the forwarding=20 > decision does not rely on the MAC address. This is not a discussion on > networking but on the standard behavior of the 802.1Q bridges. > Regards, > Nuritl. >=20 > ________________________________ >=20 > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, September 21, 2006 13:00 > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > Subject: RE: Proposed liaison response to IEEE >=20 >=20 > Nurit.....precision is indeed important. In a co mode layer network=20 > connections can be p2p or p2mp in nature and each can be composed of=20 > multiple concatenated subnetwork-connections (ie nodes in THIS layer > network) and link-connections......noting that a single p2p=20 > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20 > network is NOT a connection in THAT (ie Ethernet) layer network=20 > (though it will be supported by a trail which is provided by a=20 > connection in some lower layer network). > =20 > regards, Neil >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > Behalf Of Nurit Sprecher > Sent: 21 September 2006 12:38 > To: Don Fedyk; Adrian Farrel > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Nurit=20 > Sprecher > Subject: RE: Proposed liaison response to IEEE > =09 > =09 >=20 > Hi, >=20 > =20 >=20 > I think it is a good idea to send the liaison to the IEEE and get=20 > once and for all a clear statement that the s-vid translation is=20 > supported on each provider bridge port. >=20 > =20 >=20 > In addition, the IEEE has recognized that MAC learning is not=20 > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20 > already includes this extension in section 8.7. >=20 > =20 >=20 > " The Learning Process receives the source MAC Addresses and VIDs of=20 > received frames from the >=20 > Forwarding Process, following the application of the ingress rules=20 > (8.6.2). It shall create or update a >=20 > Dynamic Filtering Entry (8.8.3) that specifies the reception Port for=20 > the frame's source address and VID, if >=20 > and only if the source address is an Individual Address, i.e., is not=20 > a Group Address, the resulting number of >=20 > entries would not exceed the capacity of the Filtering Database, and=20 > the filtering utility criteria for the >=20 > receiving Bridge Port are met." >=20 > The enhanced filtering utility criteria "are satisfied if at least=20 > one VLAN that uses the FID includes the reception Port and at least=20 > one other Port with a Port State of Learning or Forwarding in its=20 > member set, and: a) The operPointToPointMAC parameter is false for the > reception Port; or b) Ingress to the VLAN is permitted through a third > Port. NOTE -The third port can, but is not required to be in the=20 > member set.". >=20 > =20 >=20 > I think it is clearly stated, but if it is required to ask the IEEE=20 > about the context of forwarding based on a destination MAC, I suggest=20 > being more precise and specify that we are talking on point-to-point=20 > connections. >=20 > =20 >=20 > Regards, >=20 > Nurit. >=20 > =20 >=20 > -----Original Message----- > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > Sent: Wednesday, September 20, 2006 23:16 > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > Subject: RE: Proposed liaison response to IEEE >=20 > =20 >=20 > Hi Adrian >=20 > =20 >=20 > The Liaison looks good however it does not capture a comment I > made. =20 >=20 > =20 >=20 > My understanding of the S-VLAN translation in IEEE documents and the >=20 > liaison is that the translation is valid in the context of forwarding >=20 > based on a destination MAC. My interpretation is that V-LAN is=20 > optional >=20 > MAC is not. If I am correct VLAN translation as specified is not > equal >=20 > to Label switching. The Liaison is clear about not just the format of >=20 > 'packets on the wire' but the relationship to the entities such as=20 > MAC >=20 > relay as well. =20 >=20 > =20 >=20 > I think we should also ask in our liaison for clarification if the >=20 > S-VLAN translation can be valid by itself i.e. as a label agnostic to >=20 > the MAC so there is no confusion. >=20 > =20 >=20 > Thanks, >=20 > Don >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- >=20 > > From: owner-ccamp@ops.ietf.org >=20 > > All, >=20 > > >=20 > > The IETF received an unsolicited liaison on the subject of >=20 > > 802.1 Ethernet >=20 > > >=20 > > You can see the liaison at >=20 > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > > >=20 > > The participants on the GELS mailing list have requested that >=20 > > we respond to this to clarify an issue. >=20 > > >=20 > > Here is the draft of a liaison that we proposed to send.=20 >=20 > > Please shout at once if you have any concerns with this >=20 > > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > > >=20 > > Thanks, >=20 > > Adrian >=20 > > =3D=3D=3D >=20 > > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > > >=20 > > Date: Sep 2006 >=20 > > To: IEEE802.1 >=20 > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > > >=20 > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 >=20 > > Adrian Farrel, IETF CCAMP Working Group co-chair >=20 > > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > > >=20 > > Cc: Bernard Aboba bernard_aboba@hotmail.com >=20 > > Ross Callon rcallon@juniper.net >=20 > > Bill Fenner fenner@research.att.com >=20 > > CCAMP mailing list ccamp@ops.ietf.org >=20 > > GELS mailing list gels@rtg.ietf.org >=20 > > >=20 > > Thank you for your very informative and clarifying liaison on >=20 > > "Use of IEEE 802.1Q VLAN tags". >=20 > > >=20 > > We have a question arising from this liaison and our reading >=20 > > of the relevant standards documents as follows. >=20 > > >=20 > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 >=20 > > bit VIDs) is supported at S-tagged service interfaces, as an >=20 > > option, by the IEEE Std 802.1ad Provider Bridging amendment >=20 > > to IEEE Std 802.1Q." >=20 > > >=20 > > While this text in itself is clear it leaves open the >=20 > > question of whether "S-tagged Service interfaces" is the only >=20 > > type of interface where Translation of 802.1Q S-VLAN tags is >=20 > > supported. >=20 > > >=20 > > It is our understanding that IEEE Std 802.1ad does not >=20 > > preclude the translation of 802.1Q S-VLAN tags at any >=20 > > S-tagged interface. Thus, this translation would be allowed >=20 > > at Provider Network Ports, not just at Customer Network Ports. >=20 > > >=20 > > Can you please confirm whether this is the correct >=20 > > interpretation of the IEEE Std 802.1ad amendment to the IEEE >=20 > > Std 802.1Q? >=20 > > >=20 > > Many thanks, >=20 > > >=20 > > Bert Wijnen, IETF liaison to IEEE 802.1 >=20 > > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 > > >=20 > > >=20 > > >=20 > > >=20 > =20 >=20 > _______________________________________________ >=20 > gels mailing list >=20 > gels@rtg.ietf.org >=20 > https://rtg.ietf.org/mailman/listinfo/gels >=20 > =20 >=20 >=20 -- 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 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 12:03:54 +0000 Message-ID: <45127F6F.8050907@pi.se> Date: Thu, 21 Sep 2006 14:02:55 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 CC: gels@rtg.ietf.org, bwijnen@lucent.com, ccamp@ops.ietf.org Subject: Re: Proposed liaison response to IEEE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, there have been a number of correct statements in this short thread. Neil is right (given the layered network model) that Ethernet is a layer network and as such connectionless and packet oriented. Nurit is right that if you configure a VLAN on only to parts of an Ethernet bridge the frame will go through without looking at the MAC address Don is right that the liaison does not capture an earlier comment he made on the gels-list. Neither does it capture a comment made by Attila. However, if I understand what is happening here is that we need to clarify a paragraph in the liaison form the IEEE802.1 on translation of S-VIDs. I guess that this is something we all need to understand, and given the answer, it will be possible to follow up with further more precise questions. If for example the answer on S-VID translation is that it is not supported other than at domain borders, then the question on whether it needs to be done by taking the MAC-address into consideration or not will have very different meaning. Let agree on getting the liaison out, and then decide on what we do next depending on the answer. /Loa Nurit Sprecher wrote: > Hi Neil, > Thanks for your clarification. > Please note that the discussion below relates to the liaison that the > IETF wants to send to the IEEE in order to understand the standard > behavior of the Ethernet forwarding behavior. As I understand it, Don > was concerned that S-VID translation does not preclude the forwarding > decision which is based on the MAC address. My intention was to indicate > that for point-to-point VLAN connection (on a link), MAC learning is not > required by the 802.1Qrev-5 spec and the forwarding decision does not > rely on the MAC address. This is not a discussion on networking but on > the standard behavior of the 802.1Q bridges. > Regards, > Nuritl. > > ________________________________ > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, September 21, 2006 13:00 > To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk > Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org > Subject: RE: Proposed liaison response to IEEE > > > Nurit.....precision is indeed important. In a co mode layer network > connections can be p2p or p2mp in nature and each can be composed of > multiple concatenated subnetwork-connections (ie nodes in THIS layer > network) and link-connections......noting that a single p2p > link-connection hop between 2 bridges in a cl-ps Ethernet layer network > is NOT a connection in THAT (ie Ethernet) layer network (though it will > be supported by a trail which is provided by a connection in some lower > layer network). > > regards, Neil > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > On Behalf Of Nurit Sprecher > Sent: 21 September 2006 12:38 > To: Don Fedyk; Adrian Farrel > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; > Nurit Sprecher > Subject: RE: Proposed liaison response to IEEE > > > > Hi, > > > > I think it is a good idea to send the liaison to the IEEE and > get once and for all a clear statement that the s-vid translation is > supported on each provider bridge port. > > > > In addition, the IEEE has recognized that MAC learning is not > required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already > includes this extension in section 8.7. > > > > " The Learning Process receives the source MAC Addresses and > VIDs of received frames from the > > Forwarding Process, following the application of the ingress > rules (8.6.2). It shall create or update a > > Dynamic Filtering Entry (8.8.3) that specifies the reception > Port for the frame's source address and VID, if > > and only if the source address is an Individual Address, i.e., > is not a Group Address, the resulting number of > > entries would not exceed the capacity of the Filtering Database, > and the filtering utility criteria for the > > receiving Bridge Port are met." > > The enhanced filtering utility criteria "are satisfied if at > least one VLAN that uses the FID includes the reception Port and at > least one other Port with a Port State of Learning or Forwarding in its > member set, and: a) The operPointToPointMAC parameter is false for the > reception Port; or b) Ingress to the VLAN is permitted through a third > Port. NOTE -The third port can, but is not required to be in the member > set.". > > > > I think it is clearly stated, but if it is required to ask the > IEEE about the context of forwarding based on a destination MAC, I > suggest being more precise and specify that we are talking on > point-to-point connections. > > > > Regards, > > Nurit. > > > > -----Original Message----- > From: gels-bounces@rtg.ietf.org > [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk > Sent: Wednesday, September 20, 2006 23:16 > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) > Subject: RE: Proposed liaison response to IEEE > > > > Hi Adrian > > > > The Liaison looks good however it does not capture a comment I > made. > > > > My understanding of the S-VLAN translation in IEEE documents and > the > > liaison is that the translation is valid in the context of > forwarding > > based on a destination MAC. My interpretation is that V-LAN is > optional > > MAC is not. If I am correct VLAN translation as specified is not > equal > > to Label switching. The Liaison is clear about not just the > format of > > 'packets on the wire' but the relationship to the entities such > as MAC > > relay as well. > > > > I think we should also ask in our liaison for clarification if > the > > S-VLAN translation can be valid by itself i.e. as a label > agnostic to > > the MAC so there is no confusion. > > > > Thanks, > > Don > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > All, > > > > > > The IETF received an unsolicited liaison on the subject of > > > 802.1 Ethernet > > > > > > You can see the liaison at > > > https://datatracker.ietf.org/documents/LIAISON/file358.pdf > > > > > > The participants on the GELS mailing list have requested that > > > we respond to this to clarify an issue. > > > > > > Here is the draft of a liaison that we proposed to send. > > > Please shout at once if you have any concerns with this > > > liaison. I intend to ask Bert to send it on Monday of next > week. > > > > > > Thanks, > > > Adrian > > > === > > > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN > tags" > > > > > > Date: Sep 2006 > > > To: IEEE802.1 > > > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk > > > > > > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > > > Adrian Farrel, IETF CCAMP Working Group co-chair > > > Deborah Brungard, IETF CCAMP Working Group co-chair > > > > > > Cc: Bernard Aboba bernard_aboba@hotmail.com > > > Ross Callon rcallon@juniper.net > > > Bill Fenner fenner@research.att.com > > > CCAMP mailing list ccamp@ops.ietf.org > > > GELS mailing list gels@rtg.ietf.org > > > > > > Thank you for your very informative and clarifying liaison on > > > "Use of IEEE 802.1Q VLAN tags". > > > > > > We have a question arising from this liaison and our reading > > > of the relevant standards documents as follows. > > > > > > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 > > > bit VIDs) is supported at S-tagged service interfaces, as an > > > option, by the IEEE Std 802.1ad Provider Bridging amendment > > > to IEEE Std 802.1Q." > > > > > > While this text in itself is clear it leaves open the > > > question of whether "S-tagged Service interfaces" is the only > > > type of interface where Translation of 802.1Q S-VLAN tags is > > > supported. > > > > > > It is our understanding that IEEE Std 802.1ad does not > > > preclude the translation of 802.1Q S-VLAN tags at any > > > S-tagged interface. Thus, this translation would be allowed > > > at Provider Network Ports, not just at Customer Network Ports. > > > > > > Can you please confirm whether this is the correct > > > interpretation of the IEEE Std 802.1ad amendment to the IEEE > > > Std 802.1Q? > > > > > > Many thanks, > > > > > > Bert Wijnen, IETF liaison to IEEE 802.1 > > > Adrian Farrel and Deborah Brungard, CCAMP Working Group > co-chairs > > > > > > > > > > > > > > > > _______________________________________________ > > gels mailing list > > gels@rtg.ietf.org > > https://rtg.ietf.org/mailman/listinfo/gels > > > > -- 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 11:16:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD77.8E066949" Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 14:14:57 +0200 Message-ID: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuAAANq2gAABJOyw From: "Nurit Sprecher" To: , , Cc: , , , "Nurit Sprecher" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD77.8E066949 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Neil, Thanks for your clarification.=20 Please note that the discussion below relates to the liaison that the IETF wants to send to the IEEE in order to understand the standard behavior of the Ethernet forwarding behavior. As I understand it, Don was concerned that S-VID translation does not preclude the forwarding decision which is based on the MAC address. My intention was to indicate that for point-to-point VLAN connection (on a link), MAC learning is not required by the 802.1Qrev-5 spec and the forwarding decision does not rely on the MAC address. This is not a discussion on networking but on the standard behavior of the 802.1Q bridges. Regards, Nuritl. ________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Thursday, September 21, 2006 13:00 To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org Subject: RE: Proposed liaison response to IEEE Nurit.....precision is indeed important. In a co mode layer network connections can be p2p or p2mp in nature and each can be composed of multiple concatenated subnetwork-connections (ie nodes in THIS layer network) and link-connections......noting that a single p2p link-connection hop between 2 bridges in a cl-ps Ethernet layer network is NOT a connection in THAT (ie Ethernet) layer network (though it will be supported by a trail which is provided by a connection in some lower layer network). =20 regards, Neil -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: 21 September 2006 12:38 To: Don Fedyk; Adrian Farrel Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Nurit Sprecher Subject: RE: Proposed liaison response to IEEE =09 =09 Hi, =20 I think it is a good idea to send the liaison to the IEEE and get once and for all a clear statement that the s-vid translation is supported on each provider bridge port.=20 =20 In addition, the IEEE has recognized that MAC learning is not required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes this extension in section 8.7.=20 =20 " The Learning Process receives the source MAC Addresses and VIDs of received frames from the Forwarding Process, following the application of the ingress rules (8.6.2). It shall create or update a Dynamic Filtering Entry (8.8.3) that specifies the reception Port for the frame's source address and VID, if and only if the source address is an Individual Address, i.e., is not a Group Address, the resulting number of entries would not exceed the capacity of the Filtering Database, and the filtering utility criteria for the receiving Bridge Port are met." The enhanced filtering utility criteria "are satisfied if at least one VLAN that uses the FID includes the reception Port and at least one other Port with a Port State of Learning or Forwarding in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third Port. NOTE -The third port can, but is not required to be in the member set.".=20 =20 I think it is clearly stated, but if it is required to ask the IEEE about the context of forwarding based on a destination MAC, I suggest being more precise and specify that we are talking on point-to-point connections. =20 Regards, Nurit. =20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk Sent: Wednesday, September 20, 2006 23:16 To: Adrian Farrel; ccamp@ops.ietf.org Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) Subject: RE: Proposed liaison response to IEEE =20 Hi Adrian =20 The Liaison looks good however it does not capture a comment I made. =20 =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. =20 Thanks, Don =20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 =20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels =20 ------_=_NextPart_001_01C6DD77.8E066949 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message=
Hi=20 Neil,
Thanks=20 for your clarification.
Please=20 note that the discussion below relates to the liaison that the IETF = wants to=20 send to the IEEE in order to understand the standard behavior of the = Ethernet=20 forwarding behavior. As I understand it, Don was concerned that S-VID=20 translation does not preclude the forwarding decision which is based on = the MAC=20 address. My intention was to indicate that for point-to-point VLAN=20 connection (on a link), MAC learning is not required by the 802.1Qrev-5 = spec and=20 the forwarding decision does not rely on the MAC address. This is not a=20 discussion on networking but on the standard behavior of the 802.1Q=20 bridges.
Regards,
Nuritl.

From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: Thursday, September 21, = 2006=20 13:00
To: Nurit Sprecher; dwfedyk@nortel.com;=20 adrian@olddog.co.uk
Cc: gels@rtg.ietf.org; bwijnen@lucent.com; = ccamp@ops.ietf.org
Subject: RE: Proposed liaison response to=20 IEEE

Nurit.....precision is indeed important.  In a co mode = layer network=20 connections can be p2p or p2mp in nature and each can be composed of = multiple=20 concatenated subnetwork-connections (ie nodes in THIS layer network) and = link-connections......noting that a single p2p link-connection hop = between 2=20 bridges in a cl-ps Ethernet layer network is NOT a connection in = THAT (ie=20 Ethernet) layer network (though it will be supported by a trail which is = provided by a connection in some lower layer = network).
 
regards, Neil
-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Nurit Sprecher
Sent: 21 September 2006 = 12:38
To: Don=20 Fedyk; Adrian Farrel
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert);=20 ccamp@ops.ietf.org; Nurit Sprecher
Subject: RE: Proposed = liaison=20 response to IEEE

Hi,

 

I think it is a good idea to send the = liaison to the=20 IEEE and get once and for all a clear statement that the s-vid = translation is=20 supported on each provider bridge port.

 

In addition, the IEEE has recognized that = MAC learning is not required for = point-to-point=20 VLANs in a bridge. The = 802.1Q=20 rev-5 already includes this extension in section 8.7.=20

 

" The Learning Process receives the source = MAC=20 Addresses and VIDs of received frames from = the

Forwarding Process, following the = application of the=20 ingress rules (8.6.2). It shall = create or=20 update a

Dynamic Filtering Entry = (8.8.3)=20 that specifies the reception Port for the frame’s = source address and=20 VID, if

and only if = the=20 source address is an Individual Address, i.e., is not a Group Address, = the=20 resulting number of

entries would not exceed the capacity of the = Filtering=20 Database, and the filtering = utility=20 criteria for the

receiving Bridge = Port are = met."

The enhanced filtering utility criteria "are = satisfied=20 if at least one VLAN that uses the FID includes the reception Port and = at=20 least one other Port with a Port State of Learning or Forwarding in = its member=20 set, and: a) The operPointToPointMAC parameter is false for the = reception=20 Port; or b) Ingress to the VLAN is permitted through a third Port. = NOTE —The=20 third port can, but is not required to be in the member set.".=20

 

I think it is clearly stated, but if it is = required to=20 ask the IEEE about the context of forwarding based on a destination = MAC,=20 I suggest being more precise and = specify=20 that we are talking on point-to-point=20 connections.

 

Regards,

Nurit.

 

-----Original Message-----
From:=20 gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf = Of Don=20 Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian = Farrel;=20 ccamp@ops.ietf.org
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert)
Subject:=20 RE: Proposed liaison response to IEEE

 

Hi Adrian

 

The Liaison looks good however it does not = capture a=20 comment I made.  

 

My understanding of the S-VLAN translation = in IEEE=20 documents and the

liaison is that the translation is valid in = the=20 context of forwarding

based on a destination MAC. My = interpretation is that=20 V-LAN is optional

MAC is not. If I am correct VLAN translation = as=20 specified is not equal

to Label switching. The Liaison is clear = about not=20 just the format of

'packets on the wire' but the relationship = to the=20 entities such as MAC

relay as well.  =

 

I think we should also ask in our liaison = for=20 clarification if the

S-VLAN translation can be valid by itself = i.e. as a=20 label agnostic to

the MAC so there is no=20 confusion.

 

Thanks,

Don

 

 

> -----Original=20 Message-----

> From: owner-ccamp@ops.ietf.org=20

> All,

>

> The IETF received an unsolicited = liaison on the=20 subject of

> 802.1 = Ethernet

>

> You can see the liaison=20 at

>=20 = https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>

> The participants on the GELS mailing = list have=20 requested that

> we respond to this to clarify an=20 issue.

>

> Here is the draft of a liaison that we = proposed=20 to send.

> Please shout at once if you have any = concerns=20 with this

> liaison. I intend to ask Bert to send = it on=20 Monday of next week.

>

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison "Use = of IEEE=20 802.1Q VLAN tags"

>

> Date: Sep = 2006

> To: = IEEE802.1

>      Tony = Jeffree, IEEE=20 802.1 WG Chair, tony@jeffree.co.uk

>

> From: Bert Wijnen, IETF liaison to IETF = liaison=20 to IEEE 802.1

>          =20 Adrian Farrel, IETF CCAMP Working Group = co-chair

>          =20 Deborah Brungard, IETF CCAMP Working Group=20 co-chair

>

> Cc: Bernard Aboba=20 bernard_aboba@hotmail.com

>        Ross=20 Callon rcallon@juniper.net

>        Bill=20 Fenner fenner@research.att.com

>        CCAMP=20 mailing list ccamp@ops.ietf.org

>        GELS=20 mailing list  gels@rtg.ietf.org

>

> Thank you for your very informative and = clarifying liaison on

> "Use of IEEE 802.1Q VLAN=20 tags".

>

> We have a question arising from this = liaison and=20 our reading

> of the relevant standards documents as=20 follows.

>

> The liaison says: "Translation of = 802.1Q S-VLAN=20 tags (with 12

> bit VIDs) is supported at S-tagged = service=20 interfaces, as an

> option, by the IEEE Std 802.1ad = Provider Bridging=20 amendment

> to IEEE Std = 802.1Q."

>

> While this text in itself is clear it = leaves open=20 the

> question of whether "S-tagged Service = interfaces"=20 is the only

> type of interface where Translation of = 802.1Q=20 S-VLAN tags is

> supported.

>

> It is our understanding that IEEE Std = 802.1ad=20 does not

> preclude the translation of 802.1Q = S-VLAN tags at=20 any

> S-tagged interface. Thus, this = translation would=20 be allowed

> at Provider Network Ports, not just at = Customer=20 Network Ports.

>

> Can you please confirm whether this is = the=20 correct

> interpretation of the IEEE Std 802.1ad = amendment=20 to the IEEE

> Std = 802.1Q?

>

> Many = thanks,

>

> Bert Wijnen, IETF liaison to IEEE=20 802.1

> Adrian Farrel and Deborah Brungard, = CCAMP Working=20 Group co-chairs

>

>

>

>

 

_______________________________________________

gels mailing = list

gels@rtg.ietf.org

https://rtg.ietf.org/mailman/listinfo/gels=

 

------_=_NextPart_001_01C6DD77.8E066949-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 11:00:34 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD6D.1821739E" Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 12:00:05 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389188A9743@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuAAANq2gA== From: To: , , Cc: , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD6D.1821739E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nurit.....precision is indeed important. In a co mode layer network connections can be p2p or p2mp in nature and each can be composed of multiple concatenated subnetwork-connections (ie nodes in THIS layer network) and link-connections......noting that a single p2p link-connection hop between 2 bridges in a cl-ps Ethernet layer network is NOT a connection in THAT (ie Ethernet) layer network (though it will be supported by a trail which is provided by a connection in some lower layer network). =20 regards, Neil -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: 21 September 2006 12:38 To: Don Fedyk; Adrian Farrel Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Nurit Sprecher Subject: RE: Proposed liaison response to IEEE Hi, =20 I think it is a good idea to send the liaison to the IEEE and get once and for all a clear statement that the s-vid translation is supported on each provider bridge port.=20 =20 In addition, the IEEE has recognized that MAC learning is not required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes this extension in section 8.7.=20 =20 " The Learning Process receives the source MAC Addresses and VIDs of received frames from the Forwarding Process, following the application of the ingress rules (8.6.2). It shall create or update a Dynamic Filtering Entry (8.8.3) that specifies the reception Port for the frame's source address and VID, if and only if the source address is an Individual Address, i.e., is not a Group Address, the resulting number of entries would not exceed the capacity of the Filtering Database, and the filtering utility criteria for the receiving Bridge Port are met." The enhanced filtering utility criteria "are satisfied if at least one VLAN that uses the FID includes the reception Port and at least one other Port with a Port State of Learning or Forwarding in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third Port. NOTE -The third port can, but is not required to be in the member set.".=20 =20 I think it is clearly stated, but if it is required to ask the IEEE about the context of forwarding based on a destination MAC, I suggest being more precise and specify that we are talking on point-to-point connections. =20 Regards, Nurit. =20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk Sent: Wednesday, September 20, 2006 23:16 To: Adrian Farrel; ccamp@ops.ietf.org Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) Subject: RE: Proposed liaison response to IEEE =20 Hi Adrian =20 The Liaison looks good however it does not capture a comment I made. =20 =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. =20 Thanks, Don =20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 =20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels =20 ------_=_NextPart_001_01C6DD6D.1821739E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Nurit.....precision is indeed important.  In a co mode = layer network=20 connections can be p2p or p2mp in nature and each can be composed of = multiple=20 concatenated subnetwork-connections (ie nodes in THIS layer network) and = link-connections......noting that a single p2p link-connection hop = between 2=20 bridges in a cl-ps Ethernet layer network is NOT a connection in = THAT (ie=20 Ethernet) layer network (though it will be supported by a trail which is = provided by a connection in some lower layer = network).
 
regards, Neil
-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Nurit Sprecher
Sent: 21 September 2006 = 12:38
To: Don=20 Fedyk; Adrian Farrel
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert);=20 ccamp@ops.ietf.org; Nurit Sprecher
Subject: RE: Proposed = liaison=20 response to IEEE

Hi,

 

I think it is a good idea to send the = liaison to the=20 IEEE and get once and for all a clear statement that the s-vid = translation is=20 supported on each provider bridge port.

 

In addition, the IEEE has recognized that = MAC learning is not required for = point-to-point=20 VLANs in a bridge. The = 802.1Q=20 rev-5 already includes this extension in section 8.7.=20

 

" The Learning Process receives the source = MAC=20 Addresses and VIDs of received frames from = the

Forwarding Process, following the = application of the=20 ingress rules (8.6.2). It shall = create or=20 update a

Dynamic Filtering Entry = (8.8.3)=20 that specifies the reception Port for the frame’s = source address and=20 VID, if

and only if = the=20 source address is an Individual Address, i.e., is not a Group Address, = the=20 resulting number of

entries would not exceed the capacity of the = Filtering=20 Database, and the filtering = utility=20 criteria for the

receiving Bridge = Port are = met."

The enhanced filtering utility criteria "are = satisfied=20 if at least one VLAN that uses the FID includes the reception Port and = at=20 least one other Port with a Port State of Learning or Forwarding in = its member=20 set, and: a) The operPointToPointMAC parameter is false for the = reception=20 Port; or b) Ingress to the VLAN is permitted through a third Port. = NOTE —The=20 third port can, but is not required to be in the member set.".=20

 

I think it is clearly stated, but if it is = required to=20 ask the IEEE about the context of forwarding based on a destination = MAC,=20 I suggest being more precise and = specify=20 that we are talking on point-to-point=20 connections.

 

Regards,

Nurit.

 

-----Original Message-----
From:=20 gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf = Of Don=20 Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian = Farrel;=20 ccamp@ops.ietf.org
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert)
Subject:=20 RE: Proposed liaison response to IEEE

 

Hi Adrian

 

The Liaison looks good however it does not = capture a=20 comment I made.  

 

My understanding of the S-VLAN translation = in IEEE=20 documents and the

liaison is that the translation is valid in = the=20 context of forwarding

based on a destination MAC. My = interpretation is that=20 V-LAN is optional

MAC is not. If I am correct VLAN translation = as=20 specified is not equal

to Label switching. The Liaison is clear = about not=20 just the format of

'packets on the wire' but the relationship = to the=20 entities such as MAC

relay as well.  =

 

I think we should also ask in our liaison = for=20 clarification if the

S-VLAN translation can be valid by itself = i.e. as a=20 label agnostic to

the MAC so there is no=20 confusion.

 

Thanks,

Don

 

 

> -----Original=20 Message-----

> From: owner-ccamp@ops.ietf.org=20

> All,

>

> The IETF received an unsolicited = liaison on the=20 subject of

> 802.1 = Ethernet

>

> You can see the liaison=20 at

>=20 = https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>

> The participants on the GELS mailing = list have=20 requested that

> we respond to this to clarify an=20 issue.

>

> Here is the draft of a liaison that we = proposed=20 to send.

> Please shout at once if you have any = concerns=20 with this

> liaison. I intend to ask Bert to send = it on=20 Monday of next week.

>

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison "Use = of IEEE=20 802.1Q VLAN tags"

>

> Date: Sep = 2006

> To: = IEEE802.1

>      Tony = Jeffree, IEEE=20 802.1 WG Chair, tony@jeffree.co.uk

>

> From: Bert Wijnen, IETF liaison to IETF = liaison=20 to IEEE 802.1

>          =20 Adrian Farrel, IETF CCAMP Working Group = co-chair

>          =20 Deborah Brungard, IETF CCAMP Working Group=20 co-chair

>

> Cc: Bernard Aboba=20 bernard_aboba@hotmail.com

>        Ross=20 Callon rcallon@juniper.net

>        Bill=20 Fenner fenner@research.att.com

>        CCAMP=20 mailing list ccamp@ops.ietf.org

>        GELS=20 mailing list  gels@rtg.ietf.org

>

> Thank you for your very informative and = clarifying liaison on

> "Use of IEEE 802.1Q VLAN=20 tags".

>

> We have a question arising from this = liaison and=20 our reading

> of the relevant standards documents as=20 follows.

>

> The liaison says: "Translation of = 802.1Q S-VLAN=20 tags (with 12

> bit VIDs) is supported at S-tagged = service=20 interfaces, as an

> option, by the IEEE Std 802.1ad = Provider Bridging=20 amendment

> to IEEE Std = 802.1Q."

>

> While this text in itself is clear it = leaves open=20 the

> question of whether "S-tagged Service = interfaces"=20 is the only

> type of interface where Translation of = 802.1Q=20 S-VLAN tags is

> supported.

>

> It is our understanding that IEEE Std = 802.1ad=20 does not

> preclude the translation of 802.1Q = S-VLAN tags at=20 any

> S-tagged interface. Thus, this = translation would=20 be allowed

> at Provider Network Ports, not just at = Customer=20 Network Ports.

>

> Can you please confirm whether this is = the=20 correct

> interpretation of the IEEE Std 802.1ad = amendment=20 to the IEEE

> Std = 802.1Q?

>

> Many = thanks,

>

> Bert Wijnen, IETF liaison to IEEE=20 802.1

> Adrian Farrel and Deborah Brungard, = CCAMP Working=20 Group co-chairs

>

>

>

>

 

_______________________________________________

gels mailing = list

gels@rtg.ietf.org

https://rtg.ietf.org/mailman/listinfo/gels=

 

------_=_NextPart_001_01C6DD6D.1821739E-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Sep 2006 10:40:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD72.790106C1" Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 13:38:16 +0200 Message-ID: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuA= From: "Nurit Sprecher" To: "Don Fedyk" , "Adrian Farrel" Cc: , "Wijnen, Bert \(Bert\)" , , "Nurit Sprecher" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD72.790106C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I think it is a good idea to send the liaison to the IEEE and get once and for all a clear statement that the s-vid translation is supported on each provider bridge port.=20 =20 In addition, the IEEE has recognized that MAC learning is not required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes this extension in section 8.7.=20 =20 " The Learning Process receives the source MAC Addresses and VIDs of received frames from the Forwarding Process, following the application of the ingress rules (8.6.2). It shall create or update a Dynamic Filtering Entry (8.8.3) that specifies the reception Port for the frame's source address and VID, if and only if the source address is an Individual Address, i.e., is not a Group Address, the resulting number of entries would not exceed the capacity of the Filtering Database, and the filtering utility criteria for the receiving Bridge Port are met." The enhanced filtering utility criteria "are satisfied if at least one VLAN that uses the FID includes the reception Port and at least one other Port with a Port State of Learning or Forwarding in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third Port. NOTE -The third port can, but is not required to be in the member set.".=20 =20 I think it is clearly stated, but if it is required to ask the IEEE about the context of forwarding based on a destination MAC, I suggest being more precise and specify that we are talking on point-to-point connections. =20 Regards, Nurit. =20 -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk Sent: Wednesday, September 20, 2006 23:16 To: Adrian Farrel; ccamp@ops.ietf.org Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert) Subject: RE: Proposed liaison response to IEEE =20 Hi Adrian =20 The Liaison looks good however it does not capture a comment I made. =20 =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. =20 Thanks, Don =20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 =20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels =20 ------_=_NextPart_001_01C6DD72.790106C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think it is a good idea to send the liaison = to the IEEE and get once and for all a clear statement that the s-vid = translation is supported on each provider bridge port.

 

In addition, the IEEE has recognized that = MAC learning is not required for = point-to-point VLANs in a bridge. The 802.1Q = rev-5 already includes this extension in section 8.7. =

 

" The Learning Process receives the = source MAC Addresses and VIDs of received frames from = the

Forwarding Process, following the application = of the ingress rules (8.6.2). It shall = create or update a

Dynamic Filtering Entry = (8.8.3) that specifies the reception Port for the frame’s source address and VID, = if

and only if = the source address is an Individual Address, i.e., is not a Group Address, = the resulting number of

entries would not exceed the capacity of the = Filtering Database, and the filtering utility = criteria for the

receiving Bridge Port are met."

The enhanced filtering utility criteria = "are satisfied if at least one VLAN that uses the FID includes the reception = Port and at least one other Port with a Port State of Learning or Forwarding = in its member set, and: a) The operPointToPointMAC parameter is false for the reception Port; or b) Ingress to the VLAN is permitted through a third = Port. NOTE —The third port can, but is not required to be in the member = set.".

 

I think it is clearly stated, but if it is = required to ask the IEEE about the context of forwarding based on a destination MAC, = I suggest being more precise and specify that = we are talking on point-to-point connections.

 

Regards,

Nurit.

 

-----Original Message-----
From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On = Behalf Of Don Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian Farrel; ccamp@ops.ietf.org
Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert)
Subject: RE: Proposed liaison response to IEEE

 

Hi Adrian

 

The Liaison looks good however it does not = capture a comment I made.  

 

My understanding of the S-VLAN translation in = IEEE documents and the

liaison is that the translation is valid in = the context of forwarding

based on a destination MAC. My interpretation = is that V-LAN is optional

MAC is not. If I am correct VLAN translation = as specified is not equal

to Label switching. The Liaison is clear = about not just the format of

'packets on the wire' but the relationship to = the entities such as MAC

relay as well.  =

 

I think we should also ask in our liaison for clarification if the

S-VLAN translation can be valid by itself = i.e. as a label agnostic to

the MAC so there is no = confusion.

 

Thanks,

Don

 

 

> -----Original = Message-----

> From: owner-ccamp@ops.ietf.org =

> All,

>

> The IETF received an unsolicited liaison = on the subject of

> 802.1 = Ethernet

>

> You can see the liaison = at

> = https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>

> The participants on the GELS mailing = list have requested that

> we respond to this to clarify an = issue.

>

> Here is the draft of a liaison that we = proposed to send.

> Please shout at once if you have any = concerns with this

> liaison. I intend to ask Bert to send it = on Monday of next week.

>

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison = "Use of IEEE 802.1Q VLAN tags"

>

> Date: Sep = 2006

> To: = IEEE802.1

>      Tony = Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk

>

> From: Bert Wijnen, IETF liaison to IETF = liaison to IEEE 802.1

>       =     Adrian Farrel, IETF CCAMP Working Group = co-chair

>       =     Deborah Brungard, IETF CCAMP Working Group = co-chair

>

> Cc: Bernard Aboba = bernard_aboba@hotmail.com

>       = Ross Callon rcallon@juniper.net

>       = Bill Fenner fenner@research.att.com

>       = CCAMP mailing list ccamp@ops.ietf.org

>       = GELS mailing list  gels@rtg.ietf.org

>

> Thank you for your very informative and clarifying liaison on

> "Use of IEEE 802.1Q VLAN = tags".

>

> We have a question arising from this = liaison and our reading

> of the relevant standards documents as = follows.

>

> The liaison says: "Translation of = 802.1Q S-VLAN tags (with 12

> bit VIDs) is supported at S-tagged = service interfaces, as an

> option, by the IEEE Std 802.1ad Provider = Bridging amendment

> to IEEE Std = 802.1Q."

>

> While this text in itself is clear it = leaves open the

> question of whether "S-tagged = Service interfaces" is the only

> type of interface where Translation of = 802.1Q S-VLAN tags is

> supported.

>

> It is our understanding that IEEE Std = 802.1ad does not

> preclude the translation of 802.1Q = S-VLAN tags at any

> S-tagged interface. Thus, this = translation would be allowed

> at Provider Network Ports, not just at = Customer Network Ports.

>

> Can you please confirm whether this is = the correct

> interpretation of the IEEE Std 802.1ad = amendment to the IEEE

> Std 802.1Q?

>

> Many = thanks,

>

> Bert Wijnen, IETF liaison to IEEE = 802.1

> Adrian Farrel and Deborah Brungard, = CCAMP Working Group co-chairs

>

>

>

>

 

______________________________________________= _

gels mailing = list

gels@rtg.ietf.org

=

https://rtg.ietf.org/mailman/listinfo/gels

 

------_=_NextPart_001_01C6DD72.790106C1-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Sep 2006 21:17:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison response to IEEE Date: Wed, 20 Sep 2006 17:15:44 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40AB84A68@zrtphxm2.corp.nortel.com> Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CA From: "Don Fedyk" To: "Adrian Farrel" , Cc: , "Wijnen, Bert \(Bert\)" Hi Adrian The Liaison looks good however it does not capture a comment I made. =20 My understanding of the S-VLAN translation in IEEE documents and the liaison is that the translation is valid in the context of forwarding based on a destination MAC. My interpretation is that V-LAN is optional MAC is not. If I am correct VLAN translation as specified is not equal to Label switching. The Liaison is clear about not just the format of 'packets on the wire' but the relationship to the entities such as MAC relay as well. =20 I think we should also ask in our liaison for clarification if the S-VLAN translation can be valid by itself i.e. as a label agnostic to the MAC so there is no confusion. Thanks, Don > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 > Adrian Farrel, IETF CCAMP Working Group co-chair > Deborah Brungard, IETF CCAMP Working Group co-chair >=20 > Cc: Bernard Aboba bernard_aboba@hotmail.com > Ross Callon rcallon@juniper.net > Bill Fenner fenner@research.att.com > CCAMP mailing list ccamp@ops.ietf.org > GELS mailing list gels@rtg.ietf.org >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Sep 2006 19:39:05 +0000 Message-ID: <0d9701c6dcec$4a9948b0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Wijnen, Bert \(Bert\)" Subject: Proposed liaison response to IEEE Date: Wed, 20 Sep 2006 20:37:49 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit All, The IETF received an unsolicited liaison on the subject of 802.1 Ethernet You can see the liaison at https://datatracker.ietf.org/documents/LIAISON/file358.pdf The participants on the GELS mailing list have requested that we respond to this to clarify an issue. Here is the draft of a liaison that we proposed to send. Please shout at once if you have any concerns with this liaison. I intend to ask Bert to send it on Monday of next week. Thanks, Adrian === Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" Date: Sep 2006 To: IEEE802.1 Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1 Adrian Farrel, IETF CCAMP Working Group co-chair Deborah Brungard, IETF CCAMP Working Group co-chair Cc: Bernard Aboba bernard_aboba@hotmail.com Ross Callon rcallon@juniper.net Bill Fenner fenner@research.att.com CCAMP mailing list ccamp@ops.ietf.org GELS mailing list gels@rtg.ietf.org Thank you for your very informative and clarifying liaison on "Use of IEEE 802.1Q VLAN tags". We have a question arising from this liaison and our reading of the relevant standards documents as follows. The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at S-tagged service interfaces, as an option, by the IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q." While this text in itself is clear it leaves open the question of whether "S-tagged Service interfaces" is the only type of interface where Translation of 802.1Q S-VLAN tags is supported. It is our understanding that IEEE Std 802.1ad does not preclude the translation of 802.1Q S-VLAN tags at any S-tagged interface. Thus, this translation would be allowed at Provider Network Ports, not just at Customer Network Ports. Can you please confirm whether this is the correct interpretation of the IEEE Std 802.1ad amendment to the IEEE Std 802.1Q? Many thanks, Bert Wijnen, IETF liaison to IEEE 802.1 Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Sep 2006 18:17:03 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'GMPLS Based Segment Recovery' to Proposed Standard (draft-ietf-ccamp-gmpls-segment-recovery) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Wed, 20 Sep 2006 14:16:41 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'GMPLS Based Segment Recovery ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Sep 2006 18:16:44 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery' to Proposed Standard (draft-ietf-ccamp-gmpls-recovery-e2e-signaling) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Wed, 20 Sep 2006 14:15:50 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Sep 2006 18:16:35 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership' to Proposed Standard (draft-ietf-ccamp-automesh) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Wed, 20 Sep 2006 14:14:35 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-02.txt Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Sep 2006 03:04:13 +0000 To: "Olufemi Komolafe" Cc: "ccamp" , danli@huawei.com, gjhhit@huawei.com, owner-ccamp@ops.ietf.org Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, MIME-Version: 1.0 Message-ID: From: jiang.weilian@zte.com.cn Date: Wed, 20 Sep 2006 10:57:59 +0800 Content-Type: multipart/mixed; boundary="=_mixed 00109675482571EF_=" --=_mixed 00109675482571EF_= Content-Type: multipart/alternative; boundary="=_alternative 00109677482571EF_=" --=_alternative 00109677482571EF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8sIGV2ZXJ5b25lIQ0KDQpXZSBoYXZlIHB1dCBmb3J3YXJkIGEgbWVjaGFuaXNtIHRvIHNv bHZlIHRoaXMgcHJvYmxlbSBpbiBvdXIgDQpkcmFmdCAiZHJhZnQtamlhbi1jY2FtcC1tdWx0aW5v ZGVzLXJzdnAtcmVzdGFydC0wMCIgbGFzdCB5ZWFyLg0KDQpXZSB0aGluayB0aGF0IGlmIG11bHRp cGxlIGFkamFjZW50IG5vZGVzIHJlc3RhcnRlZCBuZWFybHkgYXQgDQp0aGUgc2FtZSB0aW1lLCB0 aGVzZSBub2RlcyBjYW5ub3QgbGVhcm4gYWJvdXQgdGhlIEdSIGNhcGFiaWxpdHkgDQpmcm9tIGVh Y2ggb3RoZXIuIA0KDQpUaGUga2V5IG9mIHRoaXMgcHJvYmxlbSBpcyB0aGF0IGhvdyByZXN0YXJ0 ZWQgbm9kZSBhY3RpdmVseSANCmluZm9ybSBpdHMgR1IoR3JhY2VmdWwgUmVzdGFydCkgY2FwYWJp bGl0eSB0byBuZWlnaGJvciBub2RlcywgDQplc3BlY2lhbGx5IHNvbWUgbmVpZ2hib3Igbm9kZXMg YXJlIHJlc3RhcnRlZCBub2RlcyB0b28uDQoNCklmIHlvdSBjb25jZXJuIG91ciBtZWNoYW5pc20s IHBsZWFzZSByZWFkIG91ciBkcmFmdCBmb3IgZGV0YWlsLg0KDQoNCg0KDQpSZWdhcmQsDQpKaWFu ZyBXZWlsaWFuDQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Lg0KQWRkOiAgIE5vLjY4IFppamluZ2h1YSBSZCxZdWh1YXRhaSBEaXN0cmljdCwgDQogICAgICAg IE5hbmppbmcuIFAuUi5DaGluYS4gDQpaaXA6ICAgMjEwMDEyIA0KVGVsOiAgIDAwODYtMjUtNTI4 NzE2NDQgDQpNYWlsOiAgamlhbmcud2VpbGlhbkB6dGUuY29tLmNuIA0KLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIA0KDQoNCg0KDQoNCiJPbHVmZW1pIEtvbW9s YWZlIiA8ZmVtaUBkY3MuZ2xhLmFjLnVrPg0Kt6K8/sjLo7ogb3duZXItY2NhbXBAb3BzLmlldGYu b3JnDQoNCjIwMDYtMDktMTkgMjA6NDUNCiANCiAgICAgICAgytW8/sjLo7ogICAgICAgIDxkYW5s aUBodWF3ZWkuY29tPiwgPGdqaGhpdEBodWF3ZWkuY29tPg0KICAgICAgICCzrcvNo7ogICJjY2Ft cCIgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCiAgICAgICAg1vfM4qO6ICBSRTogQ29tbWVudHMgb24g ZHJhZnQtbGktY2NhbXAtbXVsdGlub2Rlcy1nci1wcm9jLTAwLnR4dCwNCg0KDQpIaSwNCiANCldo aWxlIHJlYWRpbmcgdGhpcyBkcmFmdCBpdCBvY2N1cnJlZCB0byBtZSB0aGF0IHBlcmhhcHMgaXQg bWlnaHQgYmUgbW9yZSANCnVzZWZ1bCB0byBhcHByb2FjaCB0aGlzIHRvcGljIGZyb20gdGhlIHBl cnNwZWN0aXZlIG9mIKGwV2hhdCBjYW4gZ28gd3JvbmcgDQpkdXJpbmcgZ3JhY2VmdWwgcmVzdGFy dCwgd2hhdCBhcmUgdGhlIGNvbnNlcXVlbmNlcyBhbmQgaG93IGNhbiBpdCBiZSANCmZpeGVkP6Gx IHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHRoZSBuYXJyb3dlciB0b3BpYyBvZiBtdWx0aXBsZSAN CnNpbXVsdGFuZW91cyBub2RhbCBmYXVsdHMuDQogDQpGb3IgZXhhbXBsZSwgU2NlbmFyaW8gMSBp biB0aGUgZHJhZnQgbWF5IGJlIGludGVycHJldGVkIGFzIKGwV2hhdCBzaG91bGQgDQpoYXBwZW4g aWYgYSAobm9uLWluZ3Jlc3MpIHJlc3RhcnRpbmcgbm9kZSBmYWlscyB0byBnZXQgYSBSZWNvdmVy eVBhdGggDQptZXNzYWdlIGZyb20gaXRzIGRvd25zdHJlYW0gbmVpZ2hib3VyP6GxLCBTY2VuYXJp byAyIGlzIKGwV2hhdCBzaG91bGQgDQpoYXBwZW4gaWYgYSAobm9uLWluZ3Jlc3MpIHJlc3RhcnRp bmcgbm9kZSBmYWlscyB0byBnZXQgYSBQYXRoIG1lc3NhZ2UgZnJvbSANCml0cyB1cHN0cmVhbSBu ZWlnaGJvdXI/obEgYW5kIHNvIG9uLiAgV2hldGhlciBlYWNoIG9mIHRoZXNlIHNjZW5hcmlvcyAN CmFyaXNlcyBkdWUgdG8gbXVsdGlwbGUgc2ltdWx0YW5lb3VzIG5vZGFsIGZhdWx0cyAoYXMgaW4g dGhlIGRyYWZ0KSBvciBhbnkgDQpvdGhlciByZWFzb24gKGUuZy4gYSBzdWJzZXF1ZW50IGNvbnRy b2wgY2hhbm5lbCBmYWlsdXJlLCByZXN0YXJ0aW5nIG5vZGUgDQpiZWluZyBpbnVuZGF0ZWQgd2l0 aCBtZXNzYWdlcyBldGMuKSBpcywgaW4gbXkgb3Bpbmlvbiwgc2Vjb25kYXJ5LiAgSSB0aGluayAN CnRoZSBrZXkgdGhpbmcgaXMgdG8gaWRlbnRpZnkgdGhlIHBvdGVudGlhbCBwcm9ibGVtcyBhbmQg c3VnZ2VzdCANCmFwcHJvcHJpYXRlIHJlbWVkaWFsIGFjdGlvbnMsIHdoZXJlIHRoZSBhdXRob3Jz IHRoaW5rIGV4aXN0aW5nIA0KZG9jdW1lbnRhdGlvbiBpcyBpbnN1ZmZpY2llbnQsIHJhdGhlciB0 aGFuIGZvY3VzaW5nIG9uIDUgZGlmZmVyZW50IA0KcGVybXV0YXRpb25zIG9mIG11bHRpcGxlIG5v ZGUgZ3JhY2VmdWwgcmVzdGFydC4gDQogDQpSZWdhcmRzLA0KRmVtaQ0KIA0KIA0KDQpGcm9tOiBv d25lci1jY2FtcEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmdd IE9uIEJlaGFsZiANCk9mIFphZmFyIEFsaSAoemFsaSkNClNlbnQ6IDEwIEp1bHkgMjAwNiAwNDow NA0KVG86IGRhbmxpQGh1YXdlaS5jb207IGdqaGhpdEBodWF3ZWkuY29tDQpDYzogY2NhbXANClN1 YmplY3Q6IENvbW1lbnRzIG9uIGRyYWZ0LWxpLWNjYW1wLW11bHRpbm9kZXMtZ3ItcHJvYy0wMC50 eHQsIA0KIA0KRGVhciBBdXRob3JzLCANCiANClRoaXMgaXMgRGVqYS12dSB0byBtZS4uLi4gDQog DQpEcmFmdCBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtcmVzdGFydC1leHQtMDUudHh0IGFjdHVhbGx5 IGhhZCBhIHNlY3Rpb24gb24gDQptdWx0aXBsZSBub2RlIHJlc3RhcnQgY2FzZSBhbmQgd2FzIHJl amVjdGVkIGJ5IHRoZSBXRyBhcyBhZGRyZXNzaW5nIA0KbXVsdGlwbGUgbm9kZSByZXN0YXJ0IGNh c2UgaXMgTk9UIGEgZ29hbCAoc3VmZmVycyBmcm9tIHRoZSBsYXcgb2YgDQpkaW1pbmlzaGluZyBy ZXR1cm4pLiBJbiBvdGhlciB3b3JkcyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiB0aGUgSUQt IA0KIA0KICAgIltHUi1FWFRdIGFsc28gZXh0ZW5kcyB0aGUgSGVsbG8gbWVzc2FnZSB0byBleGNo YW5nZSBpbmZvcm1hdGlvbiBhYm91dCANCiAgIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgdGhlIFJl Y292ZXJ5UGF0aCBtZXNzYWdlLiANCiAgIFRoZSBleGFtcGxlcyBhbmQgcHJvY2VkdXJlcyBpbiBb R1ItRVhUXSBmb2N1cyBvbiB0aGUgZGVzY3JpcHRpb24gb2YgYSANCiAgIHNpbmdsZSBub2RlIHJl c3RhcnQgd2hlbiBhZGphY2VudCBuZXR3b3JrIG5vZGVzIGFyZSBvcGVyYXRpdmUuIA0KICAgQWx0 aG91Z2ggdGhlIHByb2NlZHVyZXMgYXJlIGVxdWFsbHkgYXBwbGljYWJsZSB0byBtdWx0aS1ub2Rl IHJlc3RhcnRzLCANCiAgIG5vIGRldGFpbGVkIGV4cGxhbmF0aW9uIGlzIHByb3ZpZGVkLiIgDQog DQppcyBub3QgYWNjdXJhdGUuIFBsZWFzZSBzZWUgc2VjdGlvbiA0IG9uIHRoZSBlYXJsaWVyIHZl cnNpb24gb2YgdGhlIA0KW0dSLUVYVF0sIA0KaHR0cDovL3d3dy5mYXFzLm9yZy9mdHAvcHViL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1yYWhtYW4tY2NhbXAtcnN2cC1yZXN0YXJ0LWV4dGVuc2lvbnMt MDAudHh0DQouIA0KIA0KVGhhbmtzDQogDQpSZWdhcmRzLi4uIFphZmFyIA0KIA0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbSANCnN5c3RlbS4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00109677482571EF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvLCBldmVyeW9uZSE8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGhhdmUgcHV0 IGZvcndhcmQgYSBtZWNoYW5pc20gdG8gc29sdmUNCnRoaXMgcHJvYmxlbSBpbiBvdXIgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5kcmFmdCAmcXVvdDtkcmFmdC1q aWFuLWNjYW1wLW11bHRpbm9kZXMtcnN2cC1yZXN0YXJ0LTAwJnF1b3Q7DQpsYXN0IHllYXIuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSB0aGluayB0 aGF0IGlmIG11bHRpcGxlIGFkamFjZW50IG5vZGVzDQpyZXN0YXJ0ZWQgbmVhcmx5IGF0IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIHNhbWUgdGltZSwgdGhl c2Ugbm9kZXMgY2Fubm90IGxlYXJuDQphYm91dCB0aGUgR1IgY2FwYWJpbGl0eSA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZyb20gZWFjaCBvdGhlci4gPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUga2V5IG9mIHRo aXMgcHJvYmxlbSBpcyB0aGF0IGhvdw0KcmVzdGFydGVkIG5vZGUgYWN0aXZlbHkgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbmZvcm0gaXRzIEdSKEdyYWNlZnVs IFJlc3RhcnQpIGNhcGFiaWxpdHkNCnRvIG5laWdoYm9yIG5vZGVzLCA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmVzcGVjaWFsbHkgc29tZSBuZWlnaGJvciBub2Rl cyBhcmUgcmVzdGFydGVkDQpub2RlcyB0b28uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB5b3UgY29uY2VybiBvdXIgbWVjaGFuaXNtLCBwbGVhc2UN CnJlYWQgb3VyIGRyYWZ0IGZvciBkZXRhaWwuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmQsPGJyPg0KSmlhbmcg V2VpbGlhbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48YnI+DQpBZGQ6ICZuYnNw OyBOby42OCBaaWppbmdodWEgUmQsWXVodWF0YWkgRGlzdHJpY3QsIDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtOYW5qaW5nLiBQLlIuQ2hpbmEuIDxicj4NClppcDogJm5ic3A7IDIx MDAxMiA8YnI+DQpUZWw6ICZuYnNwOyAwMDg2LTI1LTUyODcxNjQ0IDxicj4NCk1haWw6ICZuYnNw O2ppYW5nLndlaWxpYW5AenRlLmNvbS5jbiA8YnI+DQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4gPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7T2x1ZmVtaSBLb21vbGFmZSZxdW90OyAmbHQ7ZmVt aUBkY3MuZ2xhLmFjLnVrJmd0OzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPreivP7Iy6O6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvZm9udD4NCjxicj4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA2LTA5LTE5IDIwOjQ1PC9mb250 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IMrVvP7Iy6O6DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bHQ7ZGFubGlAaHVhd2VpLmNvbSZndDssICZsdDtnamhoaXRAaHVhd2VpLmNvbSZndDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyCzrcvNo7oNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2NjYW1wJnF1 b3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg1vfM4qO6DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRTogQ29tbWVudHMgb24gZHJhZnQtbGktY2NhbXAtbXVs dGlub2Rlcy1nci1wcm9jLTAwLnR4dCw8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5IaSw8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPldoaWxlIHJlYWRpbmcgdGhpcyBkcmFmdCBpdCBv Y2N1cnJlZA0KdG8gbWUgdGhhdCBwZXJoYXBzIGl0IG1pZ2h0IGJlIG1vcmUgdXNlZnVsIHRvIGFw cHJvYWNoIHRoaXMgdG9waWMgZnJvbQ0KdGhlIHBlcnNwZWN0aXZlIG9mIKGwV2hhdCBjYW4gZ28g d3JvbmcgZHVyaW5nIGdyYWNlZnVsIHJlc3RhcnQsIHdoYXQgYXJlDQp0aGUgY29uc2VxdWVuY2Vz IGFuZCBob3cgY2FuIGl0IGJlIGZpeGVkP6GxIHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHRoZQ0K bmFycm93ZXIgdG9waWMgb2YgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIG5vZGFsIGZhdWx0cy48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZvciBleGFtcGxlLCBT Y2VuYXJpbyAxIGluIHRoZQ0KZHJhZnQgbWF5IGJlIGludGVycHJldGVkIGFzIKGwV2hhdCBzaG91 bGQgaGFwcGVuIGlmIGEgKG5vbi1pbmdyZXNzKSByZXN0YXJ0aW5nDQpub2RlIGZhaWxzIHRvIGdl dCBhIFJlY292ZXJ5UGF0aCBtZXNzYWdlIGZyb20gaXRzIGRvd25zdHJlYW0gbmVpZ2hib3VyP6Gx LA0KU2NlbmFyaW8gMiBpcyChsFdoYXQgc2hvdWxkIGhhcHBlbiBpZiBhIChub24taW5ncmVzcykg cmVzdGFydGluZyBub2RlDQpmYWlscyB0byBnZXQgYSBQYXRoIG1lc3NhZ2UgZnJvbSBpdHMgdXBz dHJlYW0gbmVpZ2hib3VyP6GxIGFuZCBzbyBvbi4NCiZuYnNwO1doZXRoZXIgZWFjaCBvZiB0aGVz ZSBzY2VuYXJpb3MgYXJpc2VzIGR1ZSB0byBtdWx0aXBsZSBzaW11bHRhbmVvdXMNCm5vZGFsIGZh dWx0cyAoYXMgaW4gdGhlIGRyYWZ0KSBvciBhbnkgb3RoZXIgcmVhc29uIChlLmcuIGEgc3Vic2Vx dWVudCBjb250cm9sDQpjaGFubmVsIGZhaWx1cmUsIHJlc3RhcnRpbmcgbm9kZSBiZWluZyBpbnVu ZGF0ZWQgd2l0aCBtZXNzYWdlcyBldGMuKSBpcywNCmluIG15IG9waW5pb24sIHNlY29uZGFyeS4g Jm5ic3A7SSB0aGluayB0aGUga2V5IHRoaW5nIGlzIHRvIGlkZW50aWZ5IHRoZQ0KcG90ZW50aWFs IHByb2JsZW1zIGFuZCBzdWdnZXN0IGFwcHJvcHJpYXRlIHJlbWVkaWFsIGFjdGlvbnMsIHdoZXJl IHRoZQ0KYXV0aG9ycyB0aGluayBleGlzdGluZyBkb2N1bWVudGF0aW9uIGlzIGluc3VmZmljaWVu dCwgcmF0aGVyIHRoYW4gZm9jdXNpbmcNCm9uIDUgZGlmZmVyZW50IHBlcm11dGF0aW9ucyBvZiBt dWx0aXBsZSBub2RlIGdyYWNlZnVsIHJlc3RhcnQuICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZlbWk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGRpdiBhbGlnbj1j ZW50ZXI+DQo8YnI+DQo8aHI+PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ PGI+RnJvbTo8L2I+IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1w QG9wcy5pZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WmFmYXIgQWxpICh6YWxpKTxiPjxi cj4NClNlbnQ6PC9iPiAxMCBKdWx5IDIwMDYgMDQ6MDQ8Yj48YnI+DQpUbzo8L2I+IGRhbmxpQGh1 YXdlaS5jb207IGdqaGhpdEBodWF3ZWkuY29tPGI+PGJyPg0KQ2M6PC9iPiBjY2FtcDxiPjxicj4N ClN1YmplY3Q6PC9iPiBDb21tZW50cyBvbiBkcmFmdC1saS1jY2FtcC1tdWx0aW5vZGVzLWdyLXBy b2MtMDAudHh0LCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RGVhciBBdXRo b3JzLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+VGhpcyBpcyBEZWphLXZ1 IHRvIG1lLi4uLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RHJhZnQgPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmRyYWZ0LWlldGYtY2NhbXAt cnN2cC1yZXN0YXJ0LWV4dC0wNS50eHQNCmFjdHVhbGx5IGhhZCBhIHNlY3Rpb24gb24gbXVsdGlw bGUgbm9kZSByZXN0YXJ0IGNhc2UgYW5kIHdhcyByZWplY3RlZCBieQ0KdGhlIFdHIGFzIGFkZHJl c3NpbmcgbXVsdGlwbGUgbm9kZSByZXN0YXJ0IGNhc2UgaXMgTk9UIGEgZ29hbCAoc3VmZmVycw0K ZnJvbSB0aGUgbGF3IG9mIGRpbWluaXNoaW5nIHJldHVybikuIEluIG90aGVyIHdvcmRzIHRoZSBm b2xsb3dpbmcgc3RhdGVtZW50DQppbiB0aGUgSUQtIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7JnF1b3Q7W0dSLUVYVF0gYWxzbyBleHRlbmRzDQp0aGUg SGVsbG8gbWVzc2FnZSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbiBhYm91dCA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7dGhlIGFiaWxpdHkgdG8gc3Vw cG9ydCB0aGUgUmVjb3ZlcnlQYXRoDQptZXNzYWdlLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7VGhlIGV4YW1wbGVzIGFuZCBwcm9jZWR1cmVzDQpp biBbR1ItRVhUXSBmb2N1cyBvbiB0aGUgZGVzY3JpcHRpb24gb2YgYSA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7c2luZ2xlIG5vZGUgcmVzdGFydCB3 aGVuIGFkamFjZW50DQpuZXR3b3JrIG5vZGVzIGFyZSBvcGVyYXRpdmUuIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDtBbHRob3VnaCB0aGUgcHJvY2Vk dXJlcyBhcmUNCmVxdWFsbHkgYXBwbGljYWJsZSB0byBtdWx0aS1ub2RlIHJlc3RhcnRzLCA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7bm8gZGV0YWls ZWQgZXhwbGFuYXRpb24gaXMgcHJvdmlkZWQuJnF1b3Q7DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+aXMgbm90IGFjY3VyYXRlLiBQbGVhc2Ugc2VlIHNlY3Rpb24gNCBvbg0K dGhlIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGUgW0dSLUVYVF0sIDwvZm9udD48YSBocmVmPSJodHRw Oi8vd3d3LmZhcXMub3JnL2Z0cC9wdWIvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJhaG1hbi1jY2Ft cC1yc3ZwLXJlc3RhcnQtZXh0ZW5zaW9ucy0wMC50eHQiPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IkFyaWFsIj48dT5odHRwOi8vd3d3LmZhcXMub3JnL2Z0cC9wdWIvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXJhaG1hbi1jY2FtcC1yc3ZwLXJlc3RhcnQtZXh0ZW5zaW9ucy0wMC50eHQ8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPi4NCjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRzLi4uIFphZmFyIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxi cj48Zm9udCBzaXplPTM+PHR0Pjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwvdHQ+ PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1 cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5l ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3By b3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4m bmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZp ZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZu YnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5k Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZu YnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55 Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZu YnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5i c3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5i c3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25v dGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3Nh Z2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2Jl ZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0m bmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00109677482571EF_=-- --=_mixed 00109675482571EF_= Content-Type: text/plain; name="draft-jian-ccamp-multinodes-rsvp-restart-00.txt" Content-Disposition: attachment; filename="draft-jian-ccamp-multinodes-rsvp-restart-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group JiangWeilian(ZTE Corporation) FengJun(ZTE Corporation) Internet-Draft CuiYing(ZTE Corporation) Expires: May 20, 2006 KongYong(ZTE Corporation) LuoJian(ZTE Corporation) =20 November 20, 2005 =20 =20 Mechanism of multiple adjacent nodes RSVP=20 graceful restart Simultaneously draft-jian-ccamp-multinodes-rsvp-restart-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 5 of RFC3209, Section 9 of RFC3473. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Luojian Expires: May 2006 [Page 1] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 Abstract Based on the RSVP graceful restart defined in the RFC3473, RFC3209,=20 Node ID RSVP Hello:A Clarification Statement (draft-ietf-ccamp-rsvp -node-id-based-hello-02) and the Extensions to GMPLS RSVP Graceful Restart (draft-ietf-ccamp-rsvp-restart-ext-05), this document puts=20 forward extension to solve the problem for the restart node to actively inform RSVP graceful restart to the neighbor, and further provides the relevant mechanism to support recovery processing of RSVP graceful restart at simultaneous restart of multiple adjacent=20 nodes. Table of Contents 1. Conventions used in this document. . . . . . . . . . . . . . 3 2. Terms and abbreviation . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Actively Informing Neighbor=20 of RSVP GR Capability by Restarted Node . . . . . . . . . . . 4 4.1 Adopting Multicast Address . . . . . . . . . . . . . . . . . 4 4.2 Adopting Hot Backup . . . . . . . . . . . . . . . . . . . . . 5 5. RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes . . . . . . . . . . . . . . . . 5 5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel . . . . . . . . . . . . . . . . . . . . . 5 5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node. . . . . . . . . . . . .. . . . . . . . . 7 5.4 Multiple Adjacent Restart Nodes Contain=20 All the Tunnel Nodes. . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . 9 =20 Luojian Expires: May 2006 [Page 2] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in [RFC-2119]. 2 Terms and abbreviation Suppose the reader is familiar with terms defined in [RFC3209],=20 [RFC3473]. 3 Overview In the RSVP Graceful Restart defined in Section 9 of RFC3473, the=20 Hello mechanism defined by RFC3209 is extended to support GR (Graceful Restart) capability informing and fault detection between RSVP neighbors. It aims to define Resatrt=5FCap object for Hello=20 extension to carry GR capability parameter and inform it to the=20 neighbor through Hello message interaction. The Hello mechanism defined by RFC3209 defines the message=20 destination address and source address as the inter-neighbor=20 interface IP address in turn. In draft-ietf-ccamp-rsvp-node-id-based -hello-02, the extension defines that the destination address and=20 source address of Hello message supporting GR are TE RouterID of=20 respective nodes. Then, the restart node is usually at a passive position. Only after=20 it receives the RSVP GR Hello message from the neighbor, will it=20 inform the neighbor of its GR capability b returning the ACK message.=20 For restart of a single node, GR capability informing in the passive=20 mode is also acceptable. If multiple adjacent nodes restart at the same time, however, these=20 nodes cannot learn about the GR capability from each other. This=20 document puts forward the solution of using the multicast address as destination address or adopting the hot backup technology to=20 implement active informing of restarted node RSVP GR capability, and further provides the relevant mechanism to support recovery=20 processing of RSVP GR at simultaneous restart of multiple adjacent=20 nodes. Luojian Expires: May 2006 [Page 3] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 4 Actively Informing Neighbor of RSVP GR Capability by Restarted Node 4.1 Adopting Multicast Address After the node restarts and makes sure it supports RSVP GR Recovery, it can periodically send the GR HELLO message outward in the 1/2=20 RecoveryTime through all the RSVP interfaces to inform its GR=20 capability. Main field data composing the GR HELLO request message: The destination IP address is multicast address (IPv4: 224.0.0.2; IPv6: FF02:0:0:0:0:0:0:2). The source IP address is the local TE RouterID. The source instance value is the created value (the neighbors=20 under different interfaces can be the same). The destination instance value is 0. The Restart time value of Restart=5FCap object is the local=20 configuration value. The Recovery time of Restart=5FCap object is the local configuration value. The R digit value of Capability object is 1 (it indicates the node supports receiving of the RecoveryPath message). The T digit value of Capability object is 1 (it indicates the node supports sending of the RecoveryPath message). The S digit value of Capability object is 0 (it indicates the node does not support abstract refreshing message; for support, it can=20 be set as 1). The Reserved digit value of Capability object is 0. =20 When the neighbor receives the GR HELLO request message with this=20 destination address as multicast address, it can first use the=20 informed source RouterID as the neighbor RouterID and local RouterID to query if the corresponding HELLO instance exists: If the instance does not exist, it will create a corresponding=20 instance, save the GR capability parameter informed by the peer,=20 and confirms restart of the peer node based on the fact that the=20 destination IP address is the multicast address. According to the=20 informed GR capability parameter, it confirms that the peer is in the Recovery stage, replies the ACK message to the restart=20 neighbor based on its GR capability, and then creates the=20 corresponding Recovery Timer. Luojian Expires: May 2006 [Page 4] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 If the instance exists, it will save the GR capability parameter informed by the peer, and reply the ACK message to the restart=20 neighbor based on its GR capability. =20 After receiving the ACK reply message from the neighbor, the restart node can create the corresponding GR Hello instance in accordance=20 with the information in the message. By now, the GR Hello relation=20 between the restart node and neighbor node is reestablished. If the destination IP address of the GR HELLO request message=20 received by the restart node from its neighbor is also the multicast address, it means that the neighbor node is also a restart node. In this case, it similarly creates a corresponding instance, saves the GR capability parameter informed by the peer, confirms that the peer node is restarted and in the Recovery stage, and creates the=20 corresponding Recovery Timer. After 1/2RecoveryTime, the restart node must stop sending of the GR Hello message with the destination IP address as multicast address.=20 In stead, it just implements GR Hello communication according to the created GR Hello instance. 4.2 Adopting Hot Backup If the node conducts hot backup of key data for the established GR HELLO instance, such as the neighbor RouterID, local RouterID, source instance value, destination instance value, outgoing interface and=20 the next-hop address. Then, the restart node, after hot backup switching and restart, can get the hot backup GR HELLO instance data before restart, and=20 actively constitute a GR Hello instance based on these data to send a new GR Hello message to inform the neighbor. Then, it=20 reestablishes the GR HELLO relation with the neighbor node. 5 RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes Suppose Tunnel1 is established along with the LSR1-LSR2-LSR3-LSR4=20 path. LSR1, LSR2, LSR3 and LSR4 all support RSVP GR, and all the=20 nodes support sending and receiving of the Recovery Path message. 5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel Suppose LSR2 and LSR3 start at the same time. LSR1 and LSR4 enter the Restart stage, and they send the GR Hello=20 message to LSR2 and LSR3 in turn. Luojian Expires: May 2006 [Page 5] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 After the LSR2 and LSR3 restart, they will enter the GR Recovery stage according to the configuration. With the method described in Section 4, a GR Hello relation can be set up between LSR2 and LSR3, and they can learn that the peer party is in the GR Recovery stage. At the same time, LSR1 and LSR4 will send the GR Hello request message to LSR2 and LSR3 in turn, and LSR2 and LSR3 will create the corresponding GR HELLO instance, respond to the request messages from LSR1 and LSR4, inform the peer party of support to GR, and then enter the Recovery stage together. After that, LSR1 will send the Path message with Recovery Label=20 object to LSR2. (if sending and receiving of RecoveryPath message are supported, LSR4 will also send the RecoveryPath message to LSR3). =20 After receiving the Path message with Recovery Label object, LSR2=20 will check if the corresponding PSB exists. Suppose it cannot be=20 found, but the corresponding entry is found from the MPLS forwarding=20 table, LSR2 will create the corresponding PSB. However, because the GR Hello relation has been established between LSR2 and LSR3, and they learn that the peer part is in the GR=20 Recovery stage, then LSR2 can send the Path message carrying Recovery Label object to LSR3. Here, the outgoing label and outgoing interface are obtained by query of the forwarding table, and the next-hop=20 address can be obtained through the ERO object of Path message sent=20 upstream. After receiving the Path message carrying Recovery Label object from the restart node LSR2, LSR3 will find out if the corresponding PSB exists according to the received Path message. Suppose it is not=20 found, but the corresponding entry is found from the MPLS forwarding table. Then, LSR3 creates the corresponding PSB, constitutes the=20 Path message containing Suggested Label object and sends it to the downstream LSR4. After receiving the Path refreshing message containing Suggested=20 Label object from the restart node LSR3, LSR4 resolves the incoming label of LSP for recovery through the Suggested=5FLabel object in the Path message. Then, it matches the corresponding RSB, refreshes (clears) the stale flag for the corresponding forwarding table=20 entry, and triggers the corresponding Resv message to send it to=20 LSR3. LSR3 receives the Resv message from LSR4, creates RSB and associates the corresponding PSB. Now, both the incoming label and outgoing label are refreshed. LSR3 clears the stale flag for the corresponding forwarding entry and sends the Resv message to LSR2. Luojian Expires: May 2006 [Page 6] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 LSR2 receives the Resv message from LSR3, creates RSB and associates the corresponding PSB. Now, both the incoming label and outgoing=20 label are refreshed. LSR2 clears the stale flag for the corresponding forwarding entry and sends the Resv message to LSR1. LSR1 receives the Resv message, refreshes RSB, and clears the stale=20 flag of relevant protocol state. Now, Tunnel1 is completely=20 recovered. 5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node Suppose LSR2, LSR3 and LSR4 start at the same time. LSR1 enters the Restart stage, and it sends the GR Hello message to LSR2. After LSR2, LSR3 and LSR4 all restart, they will enter the GR=20 Recovery stage according to the configuration. With the method=20 described in Section 4, a GR Hello relation can be set up between=20 LSR2, LSR3 and LSR4, and they can learn that the peer party is in=20 the GR Recovery stage. At the same time, LSR1 will send the GR Hello request message to=20 LSR2, and LSR2 will create the corresponding GR HELLO instance,=20 respond to the request messages from LSR1, inform the peer party of support to GR, and then enter the Recovery stage together. After that, LSR1 will send the Path message with Recovery Label=20 object to LSR2. The following handing is the same as the description in Section 5.1. The Path message is sent to LSR3. After handing by LSR3, the=20 Path carrying Recovery Label object is sent to LSR4, instead of the Path message carrying Suggested Label object. Then, LSR4 sends the Resv message upstream, and each hop is=20 recovered in turn along with the upstream path till LSR1. Finally,=20 Tunnel1 is completely recovered. 5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node Suppose LSR1, LSR2 and LSR3 start at the same time. =20 LSR4 enters the Restart stage, and it sends the GR Hello message to LSR3. After LSR1, LSR2 and LSR3 all restart, they will enter the GR=20 Recovery stage according to the configuration. With the method=20 described in Section 4, a GR Hello relation can be set up between LSR1, LSR2 and LSR3, and they can learn that the peer party is in=20 the GR Recovery stage. Luojian Expires: May 2006 [Page 7] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 At the same time, LSR4 will send the GR Hello request message to LSR3, and LSR3 will create the corresponding GR HELLO instance,=20 respond to the request messages from LSR4, inform the peer party of=20 support to GR, and then enter the Recovery stage together. After that, only LSR4 will send the Recovery Path message to LSR3. (therefore, we suppose all the nodes support sending and receiving of the Recovery Path message.) When receiving the RecoveryPath message from the assistant node=20 LSR4, LSR3 will find out if the corresponding PSB exists according to the received PATH message. Suppose it is not found, but the corresponding entry is found from the MPLS forwarding table. Then,=20 LSR3 creates the corresponding PSB (possibly the original Path=20 message should have the RRO object, which can be used to get the=20 previous-hop address and recover the ERO containing the previous-hop address), and constitutes the Path message containing Suggested Label object to send it to the downstream LSR4 and wait for the Resv=20 message from LSR4. After receiving the Path refreshing message containing Suggested Label object from the restart node LSR3, LSR4 resolves the incoming label of LSP for recovery through the Suggested=5FLabel object in the=20 Path message. Then, it matches the corresponding RSB, refreshes=20 (clears) the stale mark for the corresponding forwarding table entry,=20 and triggers the corresponding Resv message to send it to LSR3. After receiving the Resv message from LSR4, LSR3 creates the=20 corresponding RSB, and refreshes (clears) the stale flag for the=20 corresponding forwarding table entry. Then, LSR3 will send the=20 Recovery Path message to LSR2. The same as handling of LSR3, LSR2, after receiving the RecoveryPath message from LSR3, will create the corresponding PSB, constitute the=20 Path message containing Suggested Label object to send it to the=20 downstream LSR3 and wait for the Resv message from LSR3. =20 After receiving the Resv message from LSR3, LSR2 creates the=20 corresponding RSB, and refreshes (clears) the stale flag for the corresponding forwarding table entry. Then, LSR2 will send the=20 Recovery Path message to LSR1. Similarly, LSR1 creates the corresponding PSB and RSB, and refreshes (clears) the stale flag for the corresponding forwarding table entry. Now, Tunnel1 is completely recovered. Luojian Expires: May 2006 [Page 8] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 5.4 Multiple Adjacent Restart Nodes Contain All the Tunnel Nodes Suppose LSR1, LSR2, LSR3 and LSR4 start at the same time. After LSR1, LSR2, LSR3 and LSR4 all restart, they will enter the GR Recovery stage according to the configuration. With the method=20 described in Section 4, a GR Hello relation can be set up between=20 LSR1, LSR2, LSR3 and LSR4, and they can learn that the peer party is in the GR Recovery stage. However, none of the four LSRs has the Tunnel1 protocol state data=20 before restart, so they cannot constitute any recovery Path message=20 to be sent to the neighbor. In this case, Tunnel1 can only wait for reestablishment of LSR1 after the GR Recovery stage ends. 6 References [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP=20 Tunnels", December 2001.=20 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation=20 Protocol-Traffic Engineering (RSVP-TE) Extensions",=20 January 2003. [RFC1112] Deering, S., "Host Extensions for IP Multicasting",=20 Stanford University, August 1989. [RFC2375] Hinden, R., et al., "IPv6 Multicast Address Assignments",=20 July 1998. IANA =A1=B0INTERNET MULTICAST ADDRESSES=A1=B1, September 2005 [draft-ietf-ccamp-rsvp-node-id-based-hello-02] Zafar Ali, et al.,"Node ID based RSVP Hello: A=20 Clarification Statement", September 2005. [draft-ietf-ccamp-rsvp-restart-ext-05] =20 Satyanarayana, et al., "Extension to GMPLS RSVP Graceful Restart", September 2005. Luojian Expires: May 2006 [Page 9] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 =20 Authors Addresses=20 JiangWeilian=20 =20 No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871644=20 Email: jiang.weilian@zte.com.cn =20 FengJun No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871631=20 Email: feng.jun99@zte.com.cn CuiYing No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871631=20 Email: cui.ying@zte.com.cn =20 KongYong No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-52871177=20 Email: kong.yong@zte.com.cn =20 LuoJian =20 No.68 Zijinghua Road, Yuhuatai District Nanjing, China=20 Phone: +86-025-51803814=20 Email: luo.jian@zte.com.cn =20 Comments are solicited and should be addressed to the working=20 group's mailing list at ccamp@ops.ietf.org and/or the author(s). Luojian Expires: May 2006 [Page 10] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 Intellectual Property Statement=20 =20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to=20 pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; neither does it represent that it=20 has made any effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track and=20 standards-related documentation can be found in BCP-11. Copies of=20 claims of rights made available for publication and any assurances of=20 licenses to be made available, or the result of an attempt made to=20 obtain a general license or permission for the use of such=20 proprietary rights by implementers or users of this specification can=20 be obtained from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights, which may cover technology that may be required to practice=20 this standard. Please address the information to the IETF Executive=20 Director.=20 Disclaimer of Validity =20 This document and the information contained herein are provided on an=20 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=20 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2005).=20 This document is subject to the rights, licenses and restrictions=20 contained in BCP 78, and except as set forth therein, the authors=20 retain all their rights.=20 Acknowledgments=20 =20 The authors would like to thank XuZhijun, DuKe, ZhuXinhua,=20 ChenJianye and all the other people who have contributed to this=20 draft, and also would like to thank all the future participants for their comments and suggestions.=20 Luojian Expires: May 2006 [Page 11] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 --=_mixed 00109675482571EF_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Sep 2006 12:43:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DBE8.F1529B3A" Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Date: Tue, 19 Sep 2006 13:45:47 +0100 Message-ID: Thread-Topic: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, Thread-Index: AcajzYu3Wna7e+MHRe2xxdCgls5b7A4GVrqQ From: "Olufemi Komolafe" To: , Cc: "ccamp" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DBE8.F1529B3A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 While reading this draft it occurred to me that perhaps it might be more useful to approach this topic from the perspective of "What can go wrong during graceful restart, what are the consequences and how can it be fixed?" rather than focusing on the narrower topic of multiple simultaneous nodal faults. =20 For example, Scenario 1 in the draft may be interpreted as "What should happen if a (non-ingress) restarting node fails to get a RecoveryPath message from its downstream neighbour?", Scenario 2 is "What should happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?" and so on. Whether each of these scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other reason (e.g. a subsequent control channel failure, restarting node being inundated with messages etc.) is, in my opinion, secondary. I think the key thing is to identify the potential problems and suggest appropriate remedial actions, where the authors think existing documentation is insufficient, rather than focusing on 5 different permutations of multiple node graceful restart. =20 =20 Regards, Femi =20 =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Sent: 10 July 2006 04:04 To: danli@huawei.com; gjhhit@huawei.com Cc: ccamp Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,=20 =20 Dear Authors,=20 =20 This is Deja-vu to me....=20 =20 Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by the WG as addressing multiple node restart case is NOT a goal (suffers from the law of diminishing return). In other words the following statement in the ID-=20 =20 "[GR-EXT] also extends the Hello message to exchange information about=20 the ability to support the RecoveryPath message.=20 The examples and procedures in [GR-EXT] focus on the description of a single node restart when adjacent network nodes are operative.=20 Although the procedures are equally applicable to multi-node restarts,=20 no detailed explanation is provided."=20 =20 is not accurate. Please see section 4 on the earlier version of the [GR-EXT], http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-rest art-extensions-00.txt .=20 =20 Thanks =20 Regards... Zafar=20 =20 ------_=_NextPart_001_01C6DBE8.F1529B3A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

While reading this draft it occurred to me that perhaps it might = be more useful to approach this topic from the perspective of “What = can go wrong during graceful restart, what are the consequences and how can it = be fixed?” rather than focusing on the narrower topic of multiple simultaneous nodal faults.

 

For example, Scenario 1 in the draft may be interpreted as = “What should happen if a (non-ingress) restarting node fails to get a = RecoveryPath message from its downstream neighbour?”, Scenario 2 is “What should = happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?” and so on.  Whether each of these = scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other = reason (e.g. a subsequent control channel failure, restarting node being = inundated with messages etc.) is, in my opinion, secondary.  I think the key = thing is to identify the potential problems and suggest appropriate remedial = actions, where the authors think existing documentation is insufficient, rather = than focusing on 5 different permutations of multiple node graceful = restart.   

 

Regards,

Femi

 

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 10 July 2006 = 04:04
To: danli@huawei.com; gjhhit@huawei.com
Cc: ccamp
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,

 

Dear Authors,

 

This is Deja-vu to me.... =

 

Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by = the WG as addressing multiple node restart case is NOT a goal (suffers = from the law of diminishing return). In other words the following statement in = the ID- =

 

   "[GR-EXT] also extends the Hello = message to exchange information about

   the ability to support the RecoveryPath message.

   The examples and procedures in [GR-EXT] = focus on the description of a

   single node restart when adjacent = network nodes are operative.

   Although the procedures are equally = applicable to multi-node restarts,

   no detailed explanation is = provided."

 

is not accurate. Please see section 4 on the earlier = version of the [GR-EXT], http://www.faqs.org/ftp/pub/= internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt<= /font>. =

 

Thanks

 

Regards... Zafar

 

------_=_NextPart_001_01C6DBE8.F1529B3A-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 17 Sep 2006 09:53:39 +0000 Message-ID: <099001c6da3f$19350de0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Pandian, Vijay" , Subject: Re: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Sun, 17 Sep 2006 10:49:33 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Vijay, > What is the rationale behind defining a new C-Type ( C-Type = 2, > suggested value, TBA by IANA) for the PROTECTION Object in > the e2e draft instead of extending C-Type = 1 defined in rfc3473? If you are familiar with the way RSVP has been developed over the years you will notice that this is standard practice. Consider the Session_Attribute object in RFC 3209. You will see two different C-Types here according to the content of the object. Perhaps a better example is the RSVP Hop object. This appears in RFC 2205 with C-Types 1 and 2 (for different uses) and is extended in RFC 3473 with two new C-Types. The C-Type is used to distinguish sub-types of the same object. This is, of course, useful, in normal implementation because it means that we don't have to make assumptions about the object's contents from parsing other fields (like the length). It is particulalry useful when a new variant of an object is introduced because it enables backward compatibility problems to be detected - a legacy implementation that does not support the new C-Type will reject the message (see RFC 2205) and the message sender can then take action to avoid the problem. In the case of draft-ietf-ccamp-gmpls-recovery-e2e-signaling, you'll notice that although the format of the first 8 bytes of the C-Type2 Protection object matches the C-Type1 Protection object in RFC 3473 with the adoption of some of the reserved bits, an extra 32 bit reserved field is added to the end of the object. (As indicated in draft-ietf-ccamp-gmpls-recovery-e2e-signaling, these 32 bits are defined in draft-ietf-ccamp-gmpls-segment-recovery.) So the processing for the two C-Types is different and it is useful to be able to distinction them through a different code point. > Should we consider C-Type = 1 as obsolete? Why? You must interoperate with 3473 implementations (always assuming interop is on your agenda) and any implementation not wanting e2e or segment protection can continue to use C-Type 1. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 17 Sep 2006 09:49:31 +0000 To: "Adrian Farrel" Cc: ccamp@ops.ietf.org, mpls@ietf.org, ospf@ietf.org, "Pandian, Vijay" Subject: Re: RFC3630 - Local and Remote Interface IP address MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 17 Sep 2006 11:48:55 +0200 Content-Type: text/plain; charset="US-ASCII" adrian point is that one can have two different readings of these sentences either one assigns multiple IP addresses and configures a specific map of these addresses to components (e.g. sub-interfaces) or it is meant just to assign multiple IP addresses to an interface independently of this segmentation however, there is no bundling concept in this ref. or equivalently the bundling RFC maps a single (composed) TE link to a TE link (with specific aggregation rules when it comes to TE attributes) that is RFC4201 uses a single value for the link local/remote address/interface associated to the bundle thanks, - d. "Adrian Farrel" 17/09/2006 11:31 Please respond to "Adrian Farrel" To: "Pandian, Vijay" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: , , Subject: Re: RFC3630 - Local and Remote Interface IP address Hi Vijay, OSPF-TE implementers may wish to disagree with me on this, but I think Dimitri's definitive statement does not cover the basic reasoning for this feature. While it is true that one can use multiple link addresses to identify multiple component links, I think that the multiplicity of link addresses is provided in this RFC so that a single TE link may support multiple interfaces. This is an implementation choice, and may be advantageous in some cases. If the multiple link addresses are used to identify multiple component links, then I would expect a 1:1 correspondence between the link ends. If the addresses are used to identify different interfaces to the same link then I would not necessarily expect a 1:1 correspondence. In answer to your most recent questions: > Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link." And so it does. It describes a single TE link. A link bundle is still a single TE link, but it is made up of multiple component links that are not identified as TE links in their own right. > Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV > specifies the IP address(es) of the interface corresponding to this link." > > Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV > specifies the IP address(es) of the neighbor's interface corresponding to > this link." As above > Doesn't this mean the Local and Remote Interface IP Address sub-TLV > corresponds to just ONE TE-Link? Yes, it does. > There is no mention of "components" anywhere in this document. Even in > rfc4201, it is not clear that when multiple (component) TE-Links are > aggregated as a single numbered bundled link, there can be more than one > Interface IP address used for Local and Remote Interface IP Address. > > Could you please provide a reference where this is clarified as the mean > for > advertising multiple components at once. I don't think you will find such a reference. What is clear is that an implementation MAY assign multiple interface IP addresses. Therefore, there is nothing to stop an implementation using the component link identifiers as the set of interface IP addresses. Since each component link is in just one bundle, the use of a component link identifier uniquely identifies the bundle. This mechanism of advertising is, therefore, a clever way of advertising bundle membership information to the neighbor. If you want a more definitive statement of how this can work, you should probably develop an Applicability Statement I-D. Regards, Adrian > Thanks and best regards, > > Vijay > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, July 06, 2006 1:57 AM > To: Pandian, Vijay > Subject: Re: RFC3630 - Local and Remote Interface IP address > > > hi vijay - this was meant for advertizing multiple components at once > > > > > "Pandian, Vijay" > Sent by: owner-ccamp@ops.ietf.org > 06/07/2006 02:56 > > To: ospf@ietf.org > cc: mpls@ietf.org, ccamp@ops.ietf.org > Subject: RFC3630 - Local and Remote Interface IP address > > > Section 2.5.3 indicates that there can be more than one Local Interface IP > address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 > indicates that there can be more than one Remote Interface IP Address > assigned to a (numbered) TE-Link. > > Is there any requirement that the number of Local Interface IP address > assigned to a given TE-link match the number of Remote Interface IP > address. > > Specifically, can a TE-Link have just one Local Interface IP address but > multiple Remote Interface IP Address or vice-versa? > > Best regards, > > Vijay > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 17 Sep 2006 09:34:20 +0000 Message-ID: <097c01c6da3c$1ab832d0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Pandian, Vijay" , Cc: , , Subject: Re: RFC3630 - Local and Remote Interface IP address Date: Sun, 17 Sep 2006 10:31:31 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Vijay, OSPF-TE implementers may wish to disagree with me on this, but I think Dimitri's definitive statement does not cover the basic reasoning for this feature. While it is true that one can use multiple link addresses to identify multiple component links, I think that the multiplicity of link addresses is provided in this RFC so that a single TE link may support multiple interfaces. This is an implementation choice, and may be advantageous in some cases. If the multiple link addresses are used to identify multiple component links, then I would expect a 1:1 correspondence between the link ends. If the addresses are used to identify different interfaces to the same link then I would not necessarily expect a 1:1 correspondence. In answer to your most recent questions: > Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link." And so it does. It describes a single TE link. A link bundle is still a single TE link, but it is made up of multiple component links that are not identified as TE links in their own right. > Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV > specifies the IP address(es) of the interface corresponding to this link." > > Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV > specifies the IP address(es) of the neighbor's interface corresponding to > this link." As above > Doesn't this mean the Local and Remote Interface IP Address sub-TLV > corresponds to just ONE TE-Link? Yes, it does. > There is no mention of "components" anywhere in this document. Even in > rfc4201, it is not clear that when multiple (component) TE-Links are > aggregated as a single numbered bundled link, there can be more than one > Interface IP address used for Local and Remote Interface IP Address. > > Could you please provide a reference where this is clarified as the mean > for > advertising multiple components at once. I don't think you will find such a reference. What is clear is that an implementation MAY assign multiple interface IP addresses. Therefore, there is nothing to stop an implementation using the component link identifiers as the set of interface IP addresses. Since each component link is in just one bundle, the use of a component link identifier uniquely identifies the bundle. This mechanism of advertising is, therefore, a clever way of advertising bundle membership information to the neighbor. If you want a more definitive statement of how this can work, you should probably develop an Applicability Statement I-D. Regards, Adrian > Thanks and best regards, > > Vijay > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, July 06, 2006 1:57 AM > To: Pandian, Vijay > Subject: Re: RFC3630 - Local and Remote Interface IP address > > > hi vijay - this was meant for advertizing multiple components at once > > > > > "Pandian, Vijay" > Sent by: owner-ccamp@ops.ietf.org > 06/07/2006 02:56 > > To: ospf@ietf.org > cc: mpls@ietf.org, ccamp@ops.ietf.org > Subject: RFC3630 - Local and Remote Interface IP address > > > Section 2.5.3 indicates that there can be more than one Local Interface IP > address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 > indicates that there can be more than one Remote Interface IP Address > assigned to a (numbered) TE-Link. > > Is there any requirement that the number of Local Interface IP address > assigned to a given TE-link match the number of Remote Interface IP > address. > > Specifically, can a TE-Link have just one Local Interface IP address but > multiple Remote Interface IP Address or vice-versa? > > Best regards, > > Vijay > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Sep 2006 19:50:31 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-06.txt Message-Id: Date: Fri, 15 Sep 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-06.txt Pages : 20 Date : 2006-9-15 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.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-ccamp-gmpls-alarm-spec-06.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-ccamp-gmpls-alarm-spec-06.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-9-15134032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-15134032.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Sep 2006 18:57:04 +0000 From: "Jim Jones" To: "'Adrian Farrel'" Cc: , "'Brungard, Deborah A, ALABS'" , "'Ross Callon'" , "'Bill Fenner'" Subject: RE: New CCAMP RFC of Interest to OIF Date: Fri, 15 Sep 2006 13:55:54 -0500 Message-ID: <003901c6d8f8$94dabcd0$9c51d18f@ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcbY7YEDw64Nfe3gSs2k719pH0g66gACt7wQ Dear Adrian and Deborah, Thank you for the update. I will make the membership aware of this new RFC. Best Regards, Jim Jones OIF Technical Committee Chair -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 15, 2006 12:33 PM To: Jim Jones Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS; Ross Callon; Bill Fenner Subject: New CCAMP RFC of Interest to OIF Dear Jim, The CCAMP working group of the IETF is pleased to inform you of the publication of RFC 4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. The Abstract to this RFC reads as follows: This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. The RFC can be downloaded free of charge from http://www.ietf.org/rfc/rfc4606.txt RFC 4606 obsoletes RFC 3946 and addresses a minor clarification arising from a question raised by the OIF as a result of interworking tests. Further information about the work of the CCAMP working group can be found at our charter page: http://www.ietf.org/html.charters/ccamp-charter.html Best regards, Adrian Farrel and Deborah Brungard CCAMP Working Group Co-Chairs Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Sep 2006 17:42:29 +0000 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Stephen Trowbridge , Kam Lam , CCAMP Mailing List , Ross Callon , Bill Fenner , Scott Bradner , Deborah Brungard , Adrian Farrel , Adrian Farrel From: Adrian Farrel (IETF CCAMP WG) Subject: New Liaison Statement, "New RFC on GMPLS Extensions for SONET/SDH" Reply-To: Adrian Farrel Message-Id: Date: Fri, 15 Sep 2006 13:42:17 -0400 Title: New RFC on GMPLS Extensions for SONET/SDH Submission Date: 2006-09-15 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=264 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T SG15(Greg Jones ) Cc: Stephen Trowbridge Kam Lam CCAMP Mailing List Ross Callon Bill Fenner Scott Bradner Deborah Brungard Reponse Contact: Adrian Farrel Technical Contact: Adrian Farrel Purpose: For information Body: The CCAMP working group of the IETF is pleased to inform you of the publication of RFC 4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. The Abstract to this RFC reads as follows: This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. The RFC can be downloaded free of charge from http://www.ietf.org/rfc/rfc4606.txt RFC 4606 obsoletes RFC 3946 and addresses a minor clarification. Further information about the work of the CCAMP working group can be found at our charter page http://www.ietf.org/html.charters/ccamp-charter.html Best regards, Adrian Farrel and Deborah Brungard CCAMP Working Group Co-Chairs Attachment(s): No document has been attached Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Sep 2006 17:36:49 +0000 Message-ID: <081c01c6d8ed$5c273540$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Jim Jones" Cc: , "Brungard, Deborah A, ALABS" , "Ross Callon" , "Bill Fenner" Subject: New CCAMP RFC of Interest to OIF Date: Fri, 15 Sep 2006 18:33:15 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Dear Jim, The CCAMP working group of the IETF is pleased to inform you of the publication of RFC 4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. The Abstract to this RFC reads as follows: This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. The RFC can be downloaded free of charge from http://www.ietf.org/rfc/rfc4606.txt RFC 4606 obsoletes RFC 3946 and addresses a minor clarification arising from a question raised by the OIF as a result of interworking tests. Further information about the work of the CCAMP working group can be found at our charter page: http://www.ietf.org/html.charters/ccamp-charter.html Best regards, Adrian Farrel and Deborah Brungard CCAMP Working Group Co-Chairs Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Sep 2006 15:11:26 +0000 Sensitivity: Subject: Re: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt To: "Adrian Farrel" Cc: " Message-ID: From: "Diego Caviglia" Date: Fri, 15 Sep 2006 17:09:14 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Adrian, I'd like to thank you for having done this summary. As an author of the ID I agree with your points. We'll review the ID. Regards Diego "Adrian Farrel" @ops.ietf.org on 15/09/2006 13.52.30 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt Hi, We had a lively debate, and I promised to try to summarise the points to see if we have some form of consensus. draft-caviglia-ccamp-pc-and-sc-reqs-03.txt describes a problem space where the authors say it is desirable to be able to transfer control of an LSP between the management plane and a GMPLS control plane. They support this claim with various scenarios. They then develop a series of requirements on the process. The intention is to specify a process and develop any necessary protocol extensions. Re-reading the thread, I think I see the following points: 1. General agreement that transfer of control from the management plane to the control plane is a realistic scenario as a GMPLS control plane is introduced into an existing network where LSPs have been established using the management plane. 2. Some disagreement about whether point 1 needs to be performed dynamically, but nevertheless agreement that some operators may wish to make the transfer hitlessly (i.e. without a maintenance period) and in a network without sufficient spare capacity to establish a parallel LSP. 3. Considerable disagreement about some of the scenarios (documented and raised on the mailing list) for the transfer of control from the control plane to the management plane. 4. Some understanding that if transfer from the management plane to the control plane is supported, there will be a desire to back-out the process, for example if the operator is not happy with the result. 5. Some debate over whether either of the transfers (but particularly the transfer from control plane to management plane) would result in any extensions to the protocols. 6. Concern that handling failure events, where control of the LSP ends up in some mixed mode, could be very messy. My conclusions, therefore, are: A. There is consensus to work on transfer from the management plane to the control plane. B. There is enough interest to justify work on the transfer from the control plane to the management plane, but this should be scoped as a back-out procedure. C. The requirements should initially state the functional requirements and should not assume that changes to the protocols are necessary. That is, if the requirements draft can be answered with an applicability statement, that would be good all round. Later section of the draft can state current protocol behavior, and point out any gaps that need to be filled. D. The requirements draft must cover the requirements for failure cases in good detail We should encourage the authors to revise their draft along these lines at which time the working group may be more likely to find itself in full consensus. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Sep 2006 14:53:34 +0000 Message-ID: <07b901c6d8d6$62cb9d30$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt Date: Fri, 15 Sep 2006 12:52:30 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We had a lively debate, and I promised to try to summarise the points to see if we have some form of consensus. draft-caviglia-ccamp-pc-and-sc-reqs-03.txt describes a problem space where the authors say it is desirable to be able to transfer control of an LSP between the management plane and a GMPLS control plane. They support this claim with various scenarios. They then develop a series of requirements on the process. The intention is to specify a process and develop any necessary protocol extensions. Re-reading the thread, I think I see the following points: 1. General agreement that transfer of control from the management plane to the control plane is a realistic scenario as a GMPLS control plane is introduced into an existing network where LSPs have been established using the management plane. 2. Some disagreement about whether point 1 needs to be performed dynamically, but nevertheless agreement that some operators may wish to make the transfer hitlessly (i.e. without a maintenance period) and in a network without sufficient spare capacity to establish a parallel LSP. 3. Considerable disagreement about some of the scenarios (documented and raised on the mailing list) for the transfer of control from the control plane to the management plane. 4. Some understanding that if transfer from the management plane to the control plane is supported, there will be a desire to back-out the process, for example if the operator is not happy with the result. 5. Some debate over whether either of the transfers (but particularly the transfer from control plane to management plane) would result in any extensions to the protocols. 6. Concern that handling failure events, where control of the LSP ends up in some mixed mode, could be very messy. My conclusions, therefore, are: A. There is consensus to work on transfer from the management plane to the control plane. B. There is enough interest to justify work on the transfer from the control plane to the management plane, but this should be scoped as a back-out procedure. C. The requirements should initially state the functional requirements and should not assume that changes to the protocols are necessary. That is, if the requirements draft can be answered with an applicability statement, that would be good all round. Later section of the draft can state current protocol behavior, and point out any gaps that need to be filled. D. The requirements draft must cover the requirements for failure cases in good detail We should encourage the authors to revise their draft along these lines at which time the working group may be more likely to find itself in full consensus. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Sep 2006 16:24:36 +0000 To: Greg Jones Cc: IESG , IAB , Steve Trowbridge , Malcolm Betts , Yoichi Maeda , Ghani Abbas , Houlin Zhao , CCAMP mailing list , MPLS mailing list , PWE3 mailing list , Loa Andersson , Scott Bradner , Deborah Brungard , Stewart Bryant , Adrian Farrel , Danny McPherson , statements@ietf.org Cc: swallow@cisco.com Subject: Updated Liaison to ITU-T SG15 From: George Swallow Date: Thu, 14 Sep 2006 12:23:25 -0400 Message-Id: <20060914162325.8C2AF2F38EB@swallow-mini-mac.cisco.com> DKIM-Signature: a=rsa-sha1; q=dns; l=6389; t=1158250987; x=1159114987; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Updated=20Liaison=20to=20ITU-T=20SG15=20 |To:Greg=20Jones=20; X=v=3Dcisco.com=3B=20h=3DucrXgxnUFLBKbA4teKEn31O4ArA=3D; b=AVtUQeQlfzTkT2gno5CFjbk1KeQoncjH7B1B7HiiOKa8R3W2TAPuzFYQEiHUMoXvEny2lXGl 79WhrtW/94LPZZ7JtavtIVosNk2ztuPgQC2ouQPq8GbQQg0b1cPxTxFK; Authentication-Results: rtp-dkim-1.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); All - There is a type-o in the liaison sent yesterday. The second sentence of the third paragraph should have been deleted. An updated copy is attached. ...George ======================================================================== Liaison Statement Submission Date: 2006-09-13 From: Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; loa@pi.se) Scott Bradner (IETF Liaison to ITU-T, sob@harvard.edu) Deborah Brungard (IETF CCAMP WG Chair, dbrungard@att.com) Stewart Bryant (IETF PWE3 WG Chair, stbryant@cisco.com) Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, adrian@olddog.co.uk) Danny McPherson (IETF PWE3 WG Chair, danny@arbor.net) George Swallow (IETF MPLS WG Chair, swallow@cisco.com) To: ITU-T Study Group 15; Greg Jones (greg.jones@itu.int) CC: IESG (iesg@ietf.org) IAB (iab@ietf.org) Steve Trowbridge (sjtrowbridge@lucent.com) Malcolm Betts (betts01@nortel.com) Yoichi Maeda (maeda@ansl.ntt.co.jp) Ghani Abbas (ghani.abbas@marconi.com) Houlin Zhao (houlin.zhao@itu.int) CCAMP mailing list (ccamp@ops.ietf.org) MPLS mailing list (mpls@lists.ietf.org) PWE3 mailing list (pwe3@ietf.org) Re: T-MPLS use of the MPLS Ethertypes Response Contact: George Swallow Technical Contact: George Swallow Purpose: For action Deadline: 2006-10-13 We would like to thank you for your response to our liaison. We feel that through the liaison activity and the Ottawa meeting we have entered into a productive and useful dialogue. We are particularly pleased by your positive reaction to most of our concerns. We do, however, once again, request documentation of the problem that T-MPLS solves. We feel that this documentation is fundamental to a proper review of the T-MPLS architecture, protocol requirements, and any future solutions, and we advise the ITU-T not to present any T-MPLS Recommendations for consent until work on a T-MPLS problem statement is well advanced. Further, a full reference diagram of the interfaces and services of the T-MPLS network would be most useful. We understand that the direct adaptation of an IP/MPLS client over a T-MPLS server is still at a very preliminary stage. However, some understanding of the client/server relationship is necessary in order to adequately evaluate architectural decisions currently being made in G.8110.1. The most immediate concern is the proposed use of the MPLS Ethertypes. First we would like to call your attention to the fact that we are in the process of modifying the semantics of the two Ethertypes used by MPLS. Currently their designations are "MPLS Unicast" (8847) and "MPLS Multicast" (8848). The new semantics will be "Downstream Assigned" (8847) and "Upstream Assigned" (8848)". On a practical level, they will still be used for Unicast and Multicast respectively, however the change has been made to clarify which Label Switch Router (LSR) controls each label space. Each of these label spaces is shared by all MPLS applications. Each space is managed by a label-manager which is responsible for label allocation and reclamation. When a packet is received at the downstream LSR with Ethertype 8847 it is looked up in a table managed by the downstream router. Conversely when a packet is received at the downstream LSR with Ethertype 8848 it is looked up in a table managed by the upstream router. In your liaison to the MFA Forum dated 19-23 June 2006 you say, T-MPLS is intended to be a separate layer network with respect to MPLS. However, T- MPLS will use the same data-link protocol ID (e.g. EtherType), frame format and forwarding semantics for as those defined for MPLS frames. T-MPLS and MPLS cannot coexist on the same "interface" (for example they could not coexist on a single Ethernet VLAN, however they could be multiplexed on to a common Ethernet PHY using separate VLANs). On the face of it, this statement implies that MPLS and T-MPLS are two different things, but that you wish to identify them both using the same Ethertype. The Ethertype is the primary means for multiplexing and distinguishing protocols over Ethernet. The Ethertype identifies the protocol entity that will receive a packet at the layer above. VLANs on the other hand are primarily intended as a service level interface, allowing multiple virtual LANs over a single bridged domain. . If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is in fact a separate layer network, then it should be identified by its own Ethertype(s), Clear and unambiguous identification is in the best interest of all involved. In particular, if T- MPLS is being architected in such a way that would prevent it from acquiring labels by interacting with a shared label manager, then separate Ethertypes would guarantee that there is no confusion as to which label spaces belong to T-MPLS. Note further that if T-MPLS is being architected in such a way that it can (or could) interact with a shared label manager and could co-exist over the same interface sharing the MPLS label spaces with other MPLS applications, then we would welcome use of the MPLS Ethertypes. We believe that a decision to use the MPLS Ethertypes to point to a label space other than as defined by the MPLS RFCs to be architecturally unsound and ultimately will prove to be limiting to the deployment options available in networks which employ both MPLS and T-MPLS. Sincerely, Loa Andersson Scott Bradner Deborah Brungard Stewart Bryant Adrian Farrel Danny McPherson George Swallow Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Sep 2006 20:08:07 +0000 To: Greg Jones Cc: IESG , IAB , Steve Trowbridge , Malcolm Betts , Yoichi Maeda , Ghani Abbas , Houlin Zhao , CCAMP mailing list , MPLS mailing list , PWE3 mailing list Cc: Loa Andersson , Scott Bradner , Deborah Brungard , Stewart Bryant , Adrian Farrel , Danny McPherson , George Swallow , statements@ietf.org From: George Swallow Subject: Liaison to ITU-T SG15 Date: Wed, 13 Sep 2006 16:06:20 -0400 Message-Id: <20060913200620.842742F12BD@swallow-mini-mac.cisco.com> DKIM-Signature: a=rsa-sha1; q=dns; l=6463; t=1158177965; x=1159041965; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Liaison=20to=20ITU-T=20SG15 |To:Greg=20Jones=20; X=v=3Dcisco.com=3B=20h=3DtYerVQOY20ZZEewydYfLbbJbYkE=3D; b=LPj2dIN/WN+Mv0t7Xl2yoM8TMdqB9yc0c6NFkhvBmE4LIPIWDVUIquwfUmja/AgAPJOn+CJs SXmS/PZm/6ThVCESFKLjL6+XljBQyrxlHVMZe7+zSRidtN2F+Of831sB; Authentication-Results: rtp-dkim-2.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); Liaison Statement Submission Date: 2006-09-13 From: Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; loa@pi.se) Scott Bradner (IETF Liaison to ITU-T, sob@harvard.edu) Deborah Brungard (IETF CCAMP WG Chair, dbrungard@att.com) Stewart Bryant (IETF PWE3 WG Chair, stbryant@cisco.com) Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, adrian@olddog.co.uk) Danny McPherson (IETF PWE3 WG Chair, danny@arbor.net) George Swallow (IETF MPLS WG Chair, swallow@cisco.com) To: ITU-T Study Group 15; Greg Jones (greg.jones@itu.int) CC: IESG (iesg@ietf.org) IAB (iab@ietf.org) Steve Trowbridge (sjtrowbridge@lucent.com) Malcolm Betts (betts01@nortel.com) Yoichi Maeda (maeda@ansl.ntt.co.jp) Ghani Abbas (ghani.abbas@marconi.com) Houlin Zhao (houlin.zhao@itu.int) CCAMP mailing list (ccamp@ops.ietf.org) MPLS mailing list (mpls@lists.ietf.org) PWE3 mailing list (pwe3@ietf.org) Re: T-MPLS use of the MPLS Ethertypes Response Contact: George Swallow Technical Contact: George Swallow Purpose: For action Deadline: 2006-10-13 We would like to thank you for your response to our liaison. We feel that through the liaison activity and the Ottawa meeting we have entered into a productive and useful dialogue. We are particularly pleased by your positive reaction to most of our concerns. We do, however, once again, request documentation of the problem that T-MPLS solves. We feel that this documentation is fundamental to a proper review of the T-MPLS architecture, protocol requirements, and any future solutions, and we advise the ITU-T not to present any T-MPLS Recommendations for consent until work on a T-MPLS problem statement is well advanced. Further, a full reference diagram of the interfaces and services of the T-MPLS network would be most useful. We understand that the direct adaptation of an IP/MPLS client over a T-MPLS server is still at a very preliminary stage. However, some understanding of the client/server relationship is necessary in order to adequately evaluate architectural decisions currently being made in G.8110.1. The most immediate concern is the proposed use of the MPLS Ethertypes. In your liaison to the MFA Forum dated 19-23 June 2006 you say, First we would like to call your attention to the fact that we are in the process of modifying the semantics of the two Ethertypes used by MPLS. Currently their designations are "MPLS Unicast" (8847) and "MPLS Multicast" (8848). The new semantics will be "Downstream Assigned" (8847) and "Upstream Assigned" (8848)". On a practical level, they will still be used for Unicast and Multicast respectively, however the change has been made to clarify which Label Switch Router (LSR) controls each label space. Each of these label spaces is shared by all MPLS applications. Each space is managed by a label-manager which is responsible for label allocation and reclamation. When a packet is received at the downstream LSR with Ethertype 8847 it is looked up in a table managed by the downstream router. Conversely when a packet is received at the downstream LSR with Ethertype 8848 it is looked up in a table managed by the upstream router. In your liaison to the MFA Forum dated 19-23 June 2006 you say, T-MPLS is intended to be a separate layer network with respect to MPLS. However, T- MPLS will use the same data-link protocol ID (e.g. EtherType), frame format and forwarding semantics for as those defined for MPLS frames. T-MPLS and MPLS cannot coexist on the same "interface" (for example they could not coexist on a single Ethernet VLAN, however they could be multiplexed on to a common Ethernet PHY using separate VLANs). On the face of it, this statement implies that MPLS and T-MPLS are two different things, but that you wish to identify them both using the same Ethertype. The Ethertype is the primary means for multiplexing and distinguishing protocols over Ethernet. The Ethertype identifies the protocol entity that will receive a packet at the layer above. VLANs on the other hand are primarily intended as a service level interface, allowing multiple virtual LANs over a single bridged domain. . If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is in fact a separate layer network, then it should be identified by its own Ethertype(s), Clear and unambiguous identification is in the best interest of all involved. In particular, if T- MPLS is being architected in such a way that would prevent it from acquiring labels by interacting with a shared label manager, then separate Ethertypes would guarantee that there is no confusion as to which label spaces belong to T-MPLS. Note further that if T-MPLS is being architected in such a way that it can (or could) interact with a shared label manager and could co-exist over the same interface sharing the MPLS label spaces with other MPLS applications, then we would welcome use of the MPLS Ethertypes. We believe that a decision to use the MPLS Ethertypes to point to a label space other than as defined by the MPLS RFCs to be architecturally unsound and ultimately will prove to be limiting to the deployment options available in networks which employ both MPLS and T-MPLS. Sincerely, Loa Andersson Scott Bradner Deborah Brungard Stewart Bryant Adrian Farrel Danny McPherson George Swallow ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Sep 2006 12:41:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D668.70B66A24" Subject: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Tue, 12 Sep 2006 08:39:08 -0400 Message-ID: <0679BA70A2F59E49B186858B47F4595C4E015B@viper.sycamorenet.com> Thread-Topic: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling Thread-Index: AcbWaHExSeMNt+mUQjmXewMnDSPEqg== From: "Pandian, Vijay" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D668.70B66A24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 What is the rationale behind defining a new C-Type ( C-Type =3D 2, = suggested value, TBA by IANA) for the PROTECTION Object in the e2e draft = instead of extending C-Type =3D 1 defined in rfc3473? =20 Should we consider C-Type =3D 1 as obsolete? =20 Regards, =20 Vijay =20 ------_=_NextPart_001_01C6D668.70B66A24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
What = is the=20 rationale behind defining a new C-Type ( C-Type =3D 2, suggested value, = TBA by=20 IANA) for the PROTECTION Object in the e2e draft instead of=20 extending C-Type =3D 1 defined in rfc3473?
 
Should = we consider=20 C-Type =3D 1 as obsolete?
 
Regards,
 
Vijay
 
------_=_NextPart_001_01C6D668.70B66A24-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Sep 2006 14:51:47 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-15.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS)Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-15.txt Pages : 42 Date : 2006-9-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-15.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-ccamp-gmpls-lsr-mib-15.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-ccamp-gmpls-lsr-mib-15.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-9-8053424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8053424.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Sep 2006 14:51:38 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-11.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-tc-mib-11.txt Pages : 9 Date : 2006-9-8 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.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-ccamp-gmpls-tc-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-8053019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8053019.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Sep 2006 14:51:30 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-00.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-gmpls-vcat-lcas-00.txt Pages : 14 Date : 2006-9-8 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to the Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-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-ccamp-gmpls-vcat-lcas-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-ccamp-gmpls-vcat-lcas-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-9-8055726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-vcat-lcas-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8055726.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Sep 2006 14:51:22 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-16.txt Message-Id: Date: Fri, 08 Sep 2006 10:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-16.txt Pages : 59 Date : 2006-9-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-16.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-ccamp-gmpls-te-mib-16.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-ccamp-gmpls-te-mib-16.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-9-8052720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-8052720.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Sep 2006 22:52:03 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-00.txt Message-Id: Date: Thu, 07 Sep 2006 18:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Graceful Shutdown in GMPLS Traffic Engineering Networks Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-00.txt Pages : 9 Date : 2006-9-7 GMPLS-TE Graceful shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. GMPLS-TE graceful shutdown mechanisms are tailored towards addressing the planned outage in the network. This document provides requirements and protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable for both MPLS and its GMPLS extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-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-ccamp-mpls-graceful-shutdown-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-ccamp-mpls-graceful-shutdown-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-9-7152708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-graceful-shutdown-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-7152708.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 19:51:06 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-05.txt Message-Id: Date: Wed, 06 Sep 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-05.txt Pages : 19 Date : 2006-9-6 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-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-ccamp-gmpls-alarm-spec-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-ccamp-gmpls-alarm-spec-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-9-6124138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-6124138.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 17:41:25 +0000 Message-ID: <012601c6d1db$91afd320$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lucy Yong" Cc: , Subject: Potential for liaison *to* IEEE Date: Wed, 6 Sep 2006 18:38:08 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Lucy, > In 66th IETF meeting, there is an intention to send a liaison letter to > IEEE > regarding what control plane could control/manage in Ethernet data plane. I do not recall any intention by CCAMP to send a liaison at this time. The process that we will follow in CCAMP is clearly (I believe) documented in my email of 17th July to the CCAMP and GELS mailing lists. See https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html You will see that a liaison from CCAMP does not show up until step 4 in the process. > This liaison from IEEE clearly states that IEEE has not examined MAC > address > encapsulation in conjunction with VLAN tagging, thus this is not accepted > now. It also clearly states that using two VLAN tags simultaneously is not > allowed. > > Hence, now, standard Ethernet data plane bridge/switch based on MAC or > VLAN only. > Do we still need a liaison to IEEE? Yes, when we get to step 4 in the process we will still need a liaison. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 17:41:17 +0000 Message-ID: <012901c6d1db$a01101f0$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Cross-posting on GELS: STOP AND THINK Date: Wed, 6 Sep 2006 18:40:44 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi all, Stop and think. You are all clever people. Don't just hit reply. Check the recipients before you send. Please limit your postings discussing the GELS data plane to the GELS mailing list. Do not send mail on this topic to the CCAMP list. Thanks. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 17:30:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 20:26:56 +0200 Message-ID: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbR4Nue2GF46UEtSDCxZSR8ObNMcAAAKB8w From: "Nurit Sprecher" To: "Loa Andersson" Cc: "Don Fedyk" , "Lucy Yong" , "Adrian Farrel" , , , "Nurit Sprecher" IMO, it is the same. The 802.1ad defines that "A conformant S-VLAN component may implement any of the options specified for a VLAN-aware bridge component (5.4.1), and may a) allow translation of VIDs through support of a VID Translation Table (6.7) on each Port.".=20 -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: Wednesday, September 06, 2006 19:19 To: Nurit Sprecher Cc: Don Fedyk; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: Re: IEEE 802.1 WG liaison letter to the IETF All, I've been looking at this sentence in the liaison: Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at S-tagged service interfaces, as an option, by the IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q. Could someone explain if there is a difference between a "S-tagged service interface" and a "S-tagged interface"? /Loa Nurit Sprecher wrote: > Hi Don, > I did not say the that liaison says that the IET should focus on the=20 > 12 bit label encoding technique. I said that the IEEE confirmed that=20 > the 12-bit S-VID translation is a standard behavior. > The IETF got a decision not to define the data plane but to get a=20 > confirmation from the IEEE for the standard behavior. This was=20 > achieved regarding the 12-bit label encoding technique and we can go=20 > on with the work already initiated on this. > Regards, > Nurit. >=20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:14 > To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org;=20 > gels@rtg.ietf.org > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Nurit >=20 > Please do not try to interpret the liaison. The Liaison says nothing=20 > about >=20 > "The IETF should now focus on the 12 bit label encoding technique". >=20 > It actually states: >=20 > "The protocol entities that make use of a given Ethertype are=20 > characterized not just by the format of packets 'on the wire' and=20 > rules for their interchange, but also by their defined interfaces to=20 > adjacent entities in the interface stack and the MAC relay entity as=20 > well as by their local management interface interactions" >=20 > In other words just looking like an Ethernet packet with a 12 bit VID=20 > (or not) on the wire is not the only criterion. The behavior an impact > on the Ethernet switch needs to be taken into account. In other words=20 > all schemes including your 12 bit VID still need to be discussed to=20 > the impact on the interfaces as relays on Ethernet hardware. >=20 > Regards, > Don > =20 >=20 >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org >> This liaison was imitated by the IEEE intentionally to address the=20 >> same question that we wanted to ask the IEEE. >> The liaison clearly states that (currently) the only standard=20 >> behavior >=20 >> is the 12-bit VID translation, and the IETF should now focus on the=20 >> 12-bit label encoding technique for GELS. >> Regards, >> Nurit. >> > >=20 >=20 >=20 >=20 -- 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 17:21:55 +0000 Message-ID: <44FF02F0.90807@pi.se> Date: Wed, 06 Sep 2006 19:18:40 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nurit Sprecher CC: Don Fedyk , Lucy Yong , Adrian Farrel , ccamp@ops.ietf.org, gels@rtg.ietf.org Subject: Re: IEEE 802.1 WG liaison letter to the IETF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, I've been looking at this sentence in the liaison: Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at S-tagged service interfaces, as an option, by the IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q. Could someone explain if there is a difference between a "S-tagged service interface" and a "S-tagged interface"? /Loa Nurit Sprecher wrote: > Hi Don, > I did not say the that liaison says that the IET should focus on the 12 > bit label encoding technique. I said that the IEEE confirmed that the > 12-bit S-VID translation is a standard behavior. > The IETF got a decision not to define the data plane but to get a > confirmation from the IEEE for the standard behavior. This was achieved > regarding the 12-bit label encoding technique and we can go on with the > work already initiated on this. > Regards, > Nurit. > > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:14 > To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; > gels@rtg.ietf.org > Subject: RE: IEEE 802.1 WG liaison letter to the IETF > > Nurit > > Please do not try to interpret the liaison. The Liaison says nothing > about > > "The IETF should now focus on the 12 bit label encoding technique". > > It actually states: > > "The protocol entities that make use of a given Ethertype are > characterized not just by the format of packets 'on the wire' and rules > for their interchange, but also by their defined interfaces to adjacent > entities in the interface stack and the MAC relay entity as well as by > their local management interface interactions" > > In other words just looking like an Ethernet packet with a 12 bit VID > (or not) on the wire is not the only criterion. The behavior an impact > on the Ethernet switch needs to be taken into account. In other words > all schemes including your 12 bit VID still need to be discussed to the > impact on the interfaces as relays on Ethernet hardware. > > Regards, > Don > > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org >> This liaison was imitated by the IEEE intentionally to address the >> same question that we wanted to ask the IEEE. >> The liaison clearly states that (currently) the only standard behavior > >> is the 12-bit VID translation, and the IETF should now focus on the >> 12-bit label encoding technique for GELS. >> Regards, >> Nurit. >> > > > > > -- 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 17:01:52 +0000 Date: Wed, 06 Sep 2006 12:01:37 -0500 From: Lucy Yong Subject: RE: IEEE 802.1 WG liaison letter to the IETF To: 'Nurit Sprecher' , 'Don Fedyk' , 'Adrian Farrel' , ccamp@ops.ietf.org, gels@rtg.ietf.org Message-id: <001501c6d1d6$1daa62b0$a5087c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUAAAMTuwAAFyVzA= Nurit&Don, It seems that label encoding technique could relate to the data plane semantics based on your discussions. The question is if IEEE allows and follows other SDO's standardized VLAN label encoding? Regards, Lucy -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Nurit Sprecher Sent: Wednesday, September 06, 2006 12:42 PM To: Don Fedyk; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Cc: Nurit Sprecher Subject: RE: IEEE 802.1 WG liaison letter to the IETF Hi Don, I did not say the that liaison says that the IET should focus on the 12 bit label encoding technique. I said that the IEEE confirmed that the 12-bit S-VID translation is a standard behavior. The IETF got a decision not to define the data plane but to get a confirmation from the IEEE for the standard behavior. This was achieved regarding the 12-bit label encoding technique and we can go on with the work already initiated on this. Regards, Nurit. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com] Sent: Wednesday, September 06, 2006 18:14 To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF Nurit Please do not try to interpret the liaison. The Liaison says nothing about "The IETF should now focus on the 12 bit label encoding technique". It actually states: "The protocol entities that make use of a given Ethertype are characterized not just by the format of packets 'on the wire' and rules for their interchange, but also by their defined interfaces to adjacent entities in the interface stack and the MAC relay entity as well as by their local management interface interactions" In other words just looking like an Ethernet packet with a 12 bit VID (or not) on the wire is not the only criterion. The behavior an impact on the Ethernet switch needs to be taken into account. In other words all schemes including your 12 bit VID still need to be discussed to the impact on the interfaces as relays on Ethernet hardware. Regards, Don > -----Original Message----- > From: owner-ccamp@ops.ietf.org > This liaison was imitated by the IEEE intentionally to address the > same question that we wanted to ask the IEEE. > The liaison clearly states that (currently) the only standard behavior > is the 12-bit VID translation, and the IETF should now focus on the > 12-bit label encoding technique for GELS. > Regards, > Nurit. > _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 16:56:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:52:55 +0200 Message-ID: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAAAAcokkAABdMzg From: "Nurit Sprecher" To: "Don Fedyk" Cc: "Adrian Farrel" , You are right. As I already mentioned, it happened by mistake. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 18:53 To: Nurit Sprecher Cc: Adrian Farrel; ccamp@ops.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF Hi Nurit=20 I believe the Chairs asked us to not to cross post to both GELS and CCAMP as well so the whole discussion of Data Plane goes to GELS only. Regards, Don =20 > -----Original Message----- > From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com] > Sent: Wednesday, September 06, 2006 1:43 PM > To: Fedyk, Don (BL60:1A00) > Cc: Adrian Farrel; ccamp@ops.ietf.org; Nurit Sprecher > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Thanks. I did not realize that the GELS is not Cced.=20 >=20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:26 > To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org > Cc: Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Nurit >=20 > We should not talk about the IEEE data plane on the CCAMP list please=20 > see Adrian's message for a reminder: >=20 > https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html >=20 > So please take your discussion to GELS. You and I can continue to=20 > Disagree there if you like. >=20 > Regards, > Don >=20 > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 16:53:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 12:53:18 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8BB6@zrtphxm2.corp.nortel.com> Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAAAAcokkA== From: "Don Fedyk" To: "Nurit Sprecher" Cc: "Adrian Farrel" , Hi Nurit=20 I believe the Chairs asked us to not to cross post to both GELS and CCAMP as well so the whole discussion of Data Plane goes to GELS only. Regards, Don =20 > -----Original Message----- > From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com]=20 > Sent: Wednesday, September 06, 2006 1:43 PM > To: Fedyk, Don (BL60:1A00) > Cc: Adrian Farrel; ccamp@ops.ietf.org; Nurit Sprecher > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Thanks. I did not realize that the GELS is not Cced.=20 >=20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com] > Sent: Wednesday, September 06, 2006 18:26 > To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org > Cc: Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Nurit >=20 > We should not talk about the IEEE data plane on the CCAMP=20 > list please see Adrian's message for a reminder:=20 >=20 > https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html >=20 > So please take your discussion to GELS. You and I can=20 > continue to Disagree there if you like. =20 >=20 > Regards, > Don=20 >=20 > =20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 16:46:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:43:12 +0200 Message-ID: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAA= From: "Nurit Sprecher" To: "Don Fedyk" Cc: "Adrian Farrel" , , "Nurit Sprecher" Thanks. I did not realize that the GELS is not Cced.=20 -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 18:26 To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org Cc: Dimitri.Papadimitriou@alcatel.be Subject: RE: IEEE 802.1 WG liaison letter to the IETF Nurit We should not talk about the IEEE data plane on the CCAMP list please see Adrian's message for a reminder:=20 https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html So please take your discussion to GELS. You and I can continue to Disagree there if you like. =20 Regards, Don=20 =20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 16:45:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:42:01 +0200 Message-ID: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUAAAMTuw From: "Nurit Sprecher" To: "Don Fedyk" , "Lucy Yong" , "Adrian Farrel" , , Cc: "Nurit Sprecher" Hi Don, I did not say the that liaison says that the IET should focus on the 12 bit label encoding technique. I said that the IEEE confirmed that the 12-bit S-VID translation is a standard behavior.=20 The IETF got a decision not to define the data plane but to get a confirmation from the IEEE for the standard behavior. This was achieved regarding the 12-bit label encoding technique and we can go on with the work already initiated on this. Regards, Nurit. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 18:14 To: Nurit Sprecher; Lucy Yong; Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF Nurit Please do not try to interpret the liaison. The Liaison says nothing about=20 "The IETF should now focus on the 12 bit label encoding technique". It actually states: "The protocol entities that make use of a given Ethertype are characterized not just by the format of packets 'on the wire' and rules for their interchange, but also by their defined interfaces to adjacent entities in the interface stack and the MAC relay entity as well as by their local management interface interactions" In other words just looking like an Ethernet packet with a 12 bit VID (or not) on the wire is not the only criterion. The behavior an impact on the Ethernet switch needs to be taken into account. In other words all schemes including your 12 bit VID still need to be discussed to the impact on the interfaces as relays on Ethernet hardware. Regards, Don=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > This liaison was imitated by the IEEE intentionally to address the=20 > same question that we wanted to ask the IEEE. > The liaison clearly states that (currently) the only standard behavior > is the 12-bit VID translation, and the IETF should now focus on the=20 > 12-bit label encoding technique for GELS. > Regards, > Nurit. >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 16:26:04 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 12:25:31 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8B28@zrtphxm2.corp.nortel.com> Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnw From: "Don Fedyk" To: "Nurit Sprecher" , "Adrian Farrel" , Cc: Nurit We should not talk about the IEEE data plane on the CCAMP list please see Adrian's message for a reminder:=20 https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html So please take your discussion to GELS. You and I can continue to Disagree there if you like. =20 Regards, Don=20 =20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 16:15:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 12:14:28 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8ADE@zrtphxm2.corp.nortel.com> Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUA== From: "Don Fedyk" To: "Nurit Sprecher" , "Lucy Yong" , "Adrian Farrel" , , Nurit Please do not try to interpret the liaison. The Liaison says nothing about=20 "The IETF should now focus on the 12 bit label encoding technique". It actually states: "The protocol entities that make use of a given Ethertype are characterized not just by the format of packets 'on the wire' and rules for their interchange, but also by their defined interfaces to adjacent entities in the interface stack and the MAC relay entity as well as by their local management interface interactions" In other words just looking like an Ethernet packet with a 12 bit VID (or not) on the wire is not the only criterion. The behavior an impact on the Ethernet switch needs to be taken into account. In other words all schemes including your 12 bit VID still need to be discussed to the impact on the interfaces as relays on Ethernet hardware. Regards, Don=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > This liaison was imitated by the IEEE intentionally to=20 > address the same question that we wanted to ask the IEEE.=20 > The liaison clearly states that (currently) the only standard=20 > behavior is the 12-bit VID translation, and the IETF should=20 > now focus on the 12-bit label encoding technique for GELS. > Regards, > Nurit. >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 16:07:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 19:04:12 +0200 Message-ID: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUA== From: "Nurit Sprecher" To: "Don Fedyk" , "Adrian Farrel" , Cc: , "Nurit Sprecher" Hi Don,=20 It is clearly stated in the liaison that "We have not examined the detailed architectural ramifications of MAC address encapsulation in conjunction with VLAN tagging, beyond the uses presently being standardized as P802.1ah Provider Backbone Bridging.". The IEEE should still approve this kind of behavior (turning of broadcast and othe linkages, etc. as you mention below). That was exactly the decision in the last IETF meeting.=20 In the last IETF CCAMP meeting it was decided that any further work on GELS should first be approved by the IEEE 802.1 community. Otherwise, we re-start with the discussion=20 Regards, Nurit. -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 Sent: Wednesday, September 06, 2006 17:55 To: Nurit Sprecher; Adrian Farrel; ccamp@ops.ietf.org Cc: Dimitri.Papadimitriou@alcatel.be Subject: RE: IEEE 802.1 WG liaison letter to the IETF Hi Nurit=20 It is true that the data plane 12-bit S-VID translation is part of standards, but then so is using a VID/MAC as a static configured path known as PBT.=20 However in order to have the above schemes work with the existing Ethernet control plane enabled at a minimum partitioning of the VID space, turning of broadcast and other linkages between the Ethernet control plane still need to be standardized. We have discussed all this before. Regards, Don=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher > Sent: Wednesday, September 06, 2006 12:37 PM > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: Nurit Sprecher; Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, > Please note that according to the liaison from the IEEE, currently the > only standard behavior is the 12-bit S-VID translation. > That means that we can go on with the work done on the 12-bits=20 > Ethernet label encoding technique. We have the certification. > Regards, > Nurit. >=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, September 06, 2006 16:05 > To: ccamp@ops.ietf.org > Subject: Fw: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, >=20 > Those of you working on GELS stuff may find material in this liaison=20 > (which will inevitably also get posted on the IETF site). >=20 > Adrian > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "IESG" ; > Cc: ; ; "Tony Jeffree"=20 > > Sent: Wednesday, September 06, 2006 2:55 PM > Subject: IEEE 802.1 WG liaison letter to the IETF >=20 >=20 >=20 > The IEEE 802.1 Working Group approved the following liaison letter to=20 > the IETF, containing clarifications in response to several queries=20 > related to the use of IEEE 802.1Q VLAN tags. >=20 > http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf >=20 > Please distribute this letter to the interested Working Groups that=20 > are not included in the distribution list. >=20 > Dan > (wearing the hat of IEEE 802.1 WG liaison to the IETF) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 15:55:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 11:54:48 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A6E8A37@zrtphxm2.corp.nortel.com> Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoA= From: "Don Fedyk" To: "Nurit Sprecher" , "Adrian Farrel" , Cc: Hi Nurit=20 It is true that the data plane 12-bit S-VID translation is part of standards, but then so is using a VID/MAC as a static configured path known as PBT.=20 However in order to have the above schemes work with the existing Ethernet control plane enabled at a minimum partitioning of the VID space, turning of broadcast and other linkages between the Ethernet control plane still need to be standardized. We have discussed all this before. Regards, Don=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher > Sent: Wednesday, September 06, 2006 12:37 PM > To: Adrian Farrel; ccamp@ops.ietf.org > Cc: Nurit Sprecher; Dimitri.Papadimitriou@alcatel.be > Subject: RE: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, > Please note that according to the liaison from the IEEE,=20 > currently the only standard behavior is the 12-bit S-VID translation.=20 > That means that we can go on with the work done on the=20 > 12-bits Ethernet label encoding technique. We have the certification. > Regards, > Nurit. >=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, September 06, 2006 16:05 > To: ccamp@ops.ietf.org > Subject: Fw: IEEE 802.1 WG liaison letter to the IETF >=20 > Hi, >=20 > Those of you working on GELS stuff may find material in this=20 > liaison (which will inevitably also get posted on the IETF site). >=20 > Adrian > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "IESG" ; > Cc: ; ; "Tony Jeffree"=20 > > Sent: Wednesday, September 06, 2006 2:55 PM > Subject: IEEE 802.1 WG liaison letter to the IETF >=20 >=20 >=20 > The IEEE 802.1 Working Group approved the following liaison=20 > letter to the IETF, containing clarifications in response to=20 > several queries related to the use of IEEE 802.1Q VLAN tags. >=20 > http://www.ieee802.org/1/files/public/docs2006/liaison-contrib -to-ietf-m > ef-dsl-forum-0706.pdf >=20 > Please distribute this letter to the interested Working=20 > Groups that are not included in the distribution list. >=20 > Dan > (wearing the hat of IEEE 802.1 WG liaison to the IETF) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 15:54:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 18:51:32 +0200 Message-ID: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROA= From: "Nurit Sprecher" To: "Lucy Yong" , "Adrian Farrel" , , Cc: "Nurit Sprecher" This liaison was imitated by the IEEE intentionally to address the same question that we wanted to ask the IEEE.=20 The liaison clearly states that (currently) the only standard behavior is the 12-bit VID translation, and the IETF should now focus on the 12-bit label encoding technique for GELS. Regards, Nurit. -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Lucy Yong Sent: Wednesday, September 06, 2006 17:46 To: 'Adrian Farrel'; ccamp@ops.ietf.org; gels@rtg.ietf.org Subject: RE: IEEE 802.1 WG liaison letter to the IETF All, In 66th IETF meeting, there is an intention to send a liaison letter to IEEE regarding what control plane could control/manage in Ethernet data plane.=20 This liaison from IEEE clearly states that IEEE has not examined MAC address encapsulation in conjunction with VLAN tagging, thus this is not accepted now. It also clearly states that using two VLAN tags simultaneously is not allowed. Hence, now, standard Ethernet data plane bridge/switch based on MAC or VLAN only.=20 Do we still need a liaison to IEEE? Regards, Lucy =20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 06, 2006 9:05 AM To: ccamp@ops.ietf.org Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree"=20 Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 15:45:52 +0000 Date: Wed, 06 Sep 2006 10:45:32 -0500 From: Lucy Yong Subject: RE: IEEE 802.1 WG liaison letter to the IETF To: 'Adrian Farrel' , ccamp@ops.ietf.org, gels@rtg.ietf.org Message-id: <001401c6d1cb$7cccca40$a5087c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpA All, In 66th IETF meeting, there is an intention to send a liaison letter to IEEE regarding what control plane could control/manage in Ethernet data plane. This liaison from IEEE clearly states that IEEE has not examined MAC address encapsulation in conjunction with VLAN tagging, thus this is not accepted now. It also clearly states that using two VLAN tags simultaneously is not allowed. Hence, now, standard Ethernet data plane bridge/switch based on MAC or VLAN only. Do we still need a liaison to IEEE? Regards, Lucy -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 06, 2006 9:05 AM To: ccamp@ops.ietf.org Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree" Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 15:40:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 18:36:46 +0200 Message-ID: Thread-Topic: IEEE 802.1 WG liaison letter to the IETF Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSw From: "Nurit Sprecher" To: "Adrian Farrel" , Cc: "Nurit Sprecher" , Hi, Please note that according to the liaison from the IEEE, currently the only standard behavior is the 12-bit S-VID translation.=20 That means that we can go on with the work done on the 12-bits Ethernet label encoding technique. We have the certification. Regards, Nurit. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 06, 2006 16:05 To: ccamp@ops.ietf.org Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree"=20 Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 14:06:52 +0000 Message-ID: <009401c6d1bd$9cbf88a0$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: IEEE 802.1 WG liaison letter to the IETF Date: Wed, 6 Sep 2006 15:04:31 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Those of you working on GELS stuff may find material in this liaison (which will inevitably also get posted on the IETF site). Adrian ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "IESG" ; Cc: ; ; "Tony Jeffree" Sent: Wednesday, September 06, 2006 2:55 PM Subject: IEEE 802.1 WG liaison letter to the IETF The IEEE 802.1 Working Group approved the following liaison letter to the IETF, containing clarifications in response to several queries related to the use of IEEE 802.1Q VLAN tags. http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m ef-dsl-forum-0706.pdf Please distribute this letter to the interested Working Groups that are not included in the distribution list. Dan (wearing the hat of IEEE 802.1 WG liaison to the IETF) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 13:59:40 +0000 Message-ID: <007d01c6d1bc$90e659b0$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" Subject: draft-ietf-ccamp-gmpls-lsr-mib-15.txt submitted Date: Wed, 6 Sep 2006 14:57:26 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I have updated the GMPLS LSR MIB after IESG review and submitted it. The changes are as follows. Thanks, Adrian === Lars Eggert - Comment > Section 1., paragraph 2: >> Comments should be made directly to the CCAMP mailing list at >> ccamp@ops.ietf.org. > > Remove. Done >Section 1.1., paragraph 2: >> LSRs may be migrated to be modeled and managed using the MIB modules >> in this document in order to migrate the LSRs to GMPLS support, or to >> take advandtage of additional MIB objects defined in these MIB > > Nit: s/advandtage/advantage/ Done >Section 4.2., paragraph 10: >> - Optionally specifying segment traffic parameters in the >> MPLS-LSR-STD-MIB module [RCF3813]. > > Nit: s/[RCF3813]./[RFC3813]./ Done >Section 6., paragraph 10: >> -- RowPointer MUST point to the first accsesible column. > > Nit: s/accsesible/accessible/ Done >Section 7., paragraph 55: >Section 7., paragraph 57: >Section 7., paragraph 72: >Section 7., paragraph 74: >> "The only valid value for unidrectional LSPs is forward(1)." > > Nit: s/unidrectional/unidirectional/ Done >Section 9., paragraph 7: >> if the network itself is secure (for example by using IPSec), even > > Nit: s/IPSec),/IPsec),/ Done >Section 10., paragraph 0: >> 10. Acknowledgments > > Nit: Typically after IANA considerations. No change made. >Section 10., paragraph 2: >> This document extends [RFC3813]. > > "Extends" as in "updates?" If so, must reflect in > headers/abstract/intro. Text changed to "extends the MIB tables in [RFC3813]" >Section 11., paragraph 3: >> New assignments can only be made via a Standards Action as specified >> in >> [RFC2434]. > > Missing Reference: 'RFC2434' is mentioned on line 1867, but not > defined Added === Dan Romascanu - Comment >> DESCRIPTION >> "Initial version issued as part of RFC XXX." >> ::= { mplsStdMIB XXX } >>-- RFC Editor. Please replace XXX above with the correct RFC number and >>-- remove this note. >> >>-- RFC Editor. Please replace YYY above with the OID assigned by IANA >>-- and remove this note > >The intention is I believe: > > ::= { mplsStdMIB YYY } Done >Also: > >> DESCRIPTION >> "Initial version issued as part of RFC XXX." >> ::= { mplsStdMIB XXX } >>-- RFC Editor. Please replace XXX above with the correct RFC number and >>-- remove this note. >> >>-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA >>-- and remove this note > >should rather be: > > ::= { mplsStdMIB ZZZ } Done === IANA - Comment Text updated to reflect IANA's action Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 13:20:23 +0000 Message-ID: <006801c6d1b7$1dd0ee90$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" Subject: draft-ietf-ccamp-gmpls-tc-mib-11.txt submitted Date: Wed, 6 Sep 2006 14:18:49 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I have just submitted a new revision of the GMPLS TC MIB updated after IESG review. The changes are as follows. Thanks, Adrian === Lars Eggert - Comment >Section 1., paragraph 3: >> Comments should be made directly to the CCAMP mailing list at >> ccamp@ops.ietf.org. > > Nit: Remove. Done >Section 3., paragraph 23: >> For manually >> configured bidirecitonal LSPs, an arbitrary decision must be > > Nit: s/bidirecitonal/bidirectional/ Done >Section 5., paragraph 3: >> New assignments can only be made via a Standards Action as specified >> in >> [RFC2434]. > > Nit: Missing Reference: 'RFC2434' is mentioned on line 274, but not > defined Added === IANA - Comment Text updated to reflect IANA's action === Dan Romascanu - Comment >> -- This MIB module is contained in the OID sub-tree >> -- rooted at mplsStdMIB. >> "Initial version published as part of RFC XXX." >> ::= { mplsStdMIB XXX } >> >>-- RFC Editor. Please replace XXX above with the correct RFC number and >>-- remove this note. >> >>-- RFC Editor. Please replace YYY above with the OID assigned by IANA >>-- and remove this note > >should be: > > ::= { mplsStdMIB YYY } Done Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Sep 2006 13:07:19 +0000 Message-ID: <004d01c6d1b4$f77cfd80$08849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Ross Callon" Subject: draft-ietf-ccamp-gmpls-te-mib-16.txt submitted Date: Wed, 6 Sep 2006 14:02:53 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I have submitted this I-D updated after IESG review. The changes are as follows. Thanks, Adrian **************** draft-ietf-ccamp-gmpls-te-mib-15 === Lars Eggert - Comment >Section 1.1., paragraph 2: >> LSRs may be migrated to model and manage their TE LSPs using the MIB >> modules in this document in order to migrate the LSRs to GMPLS >> support, or to take advandtage of additional MIB objects defined in > > Nit: s/advandtage/advantage/ Done >Section 8., paragraph 185: >> If the value of >> gmplsTunnelErrorLastErrorType is protocol (2) the error should >> be interpreted in the context of the signling protocol > > Nit: s/signling/signaling/ Done >Section 8., paragraph 198: >> The notification rate applies to the sum >> of all notificaitons in the MPLS-TE-STD-MIB and > > Nit: s/notificaitons/notifications/ Done >Section 9., paragraph 7: >> if the network itself is secure (for example by using IPSec), even > > Nit: s/IPSec),/IPsec),/ Done >Section 12.1., paragraph 22: >> [GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual >> Conventions for Multiprotocol Label Switching (MPLS) >> Management", draft-ietf-ccamp-gmpls-tc-mib, work in >> progress. > > Nit: 'GMPLSTCMIB' is defined on line 2850, but not referenced Removed === Russ Housley - Discuss > I don't understand gmplsTunnelLinkProtection. I gather it is > described in RFC3471. However it seems like this ought to be > discussed in the security considerations. Explanation in email to Russ resulted in this response. No editorial action taken. >I had a DISCUSS based on this comment. Thank for the explanation. I've >cleared the DISCUSS. > > Russ > > At 12:34 PM 8/29/2006, Adrian Farrel wrote: >>>1. I don't understand the gmplsTunnelLinkProtection whose function is >>>described in RFC3471. Since this document describes the MIB to >>>configure the field it probably shouldn't be an issue for this document. >>>However it would be good to know if the authors considered any >>>additional security considerations associated with this variable. >> >>"Protection" here refers to the establishment of a secondary LSP that can >>be used to carry the traffic in the event of the failure of the primary >>LSP. It is not related to the Security use of the same term. >> >>For more on GMPLS protection terminology you can read RFC4327. === Dan Romascanu - Discuss > ietf-ccamp-gmpls-te-mib-15.txt is requesting assignment of a TC module > under > transmission. That seems weird. By convention, transmission assignments > generally > correspond to ifType values, which would result in a "Relationship to the > Interfaces > MIB" section of the document. If they don't define a new ifType value, I > don't see > why it should be under transmission. If, on the other hand, this is > intended to be the > MIB for ifType = mpls (166), then it should have a "Relationship to the > Interfaces > MIB" section. I think it would be better to put this under the mib-2 tree > or under the > mplsStdMIB tree After discussion, we determine that the module in question is IANA-GMPLS-TC-MIB. We agreed that this module should be under the mib-2 tree. The document has been updated accordingly. === Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Sep 2006 23:17:37 +0000 Message-ID: <0fd801c6d141$3bf4dba0$89849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New WG I-Ds Date: Wed, 6 Sep 2006 00:14:00 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi, I asked about... > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-03.txt > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt generated some constructive comments that the authors can factor into the next revision. There appears to be good consensus for this draft. Authors, please submit draft-ietf-ccamp-gmpls-vcat-lcas-00.txt with no changes except the name and the date. You must wait for the -01 revision to address the comments that you have received. draft-caviglia-ccamp-pc-and-sc-reqs-03.txt generated a huge amount of discussion. While there was a lot of support, there were also quite a lot of concerns raised, and that means I do not see consensus at the moment. However, I think I can see a way forward here, but I need to send a summary of the debate to the list to see if we can reach some consensus. Authors, you must wait before doing anything with this I-D. draft-ali-ccamp-mpls-graceful-shutdown-04.txt received some comments that will need to be addressed. Most of these can be left to the next revision, but one change must be made now, the I-D must go onto the Informational track. Authors, please submit draft-ietf-ccamp-mpls-graceful-shutdown-00.txt changing only the name, date, and intended status of the draft. You must wait for the -01 revision to address the comments you have received. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Sep 2006 14:52:03 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-automesh-02.txt Message-Id: Date: Tue, 05 Sep 2006 10:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-automesh-02.txt Pages : 15 Date : 2006-9-5 The set up of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IGP routing extensions for ISIS and OSPF so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-02.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-ccamp-automesh-02.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-ccamp-automesh-02.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-9-5021218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-automesh-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-automesh-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-5021218.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 03 Sep 2006 18:01:07 +0000 To: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 3 Sep 2006 19:59:00 +0200 Content-Type: text/plain; charset="US-ASCII" question about this doc - section 4 (where the real story starts) "If the loose next-hop is not present in the TED, the following conditions MUST be checked: - If the IP address of the next hop boundary LSR is outside of the current domain, - If the domain is PSC (Packet Switch Capable) and uses in-band control channel If the two conditions above are satisfied then the boundary LSR SHOULD check if the next-hop has IP reachability (via IGP or BGP)." what if one of these condition doesn't hold (?) in the following case X --- [ASBR1 -...- ABR1 -...- ABR2 -...- ASBR2] -- [ASBR3 --..-- ASBR4] ASBR1 receives ASBR4 [loose], the IP address of the so called "next hop boundary LSR" is inside the domain if we refer to the AS but within domain if referring to the Area => the draft says "current" domain ... what does it mean ? ABR1 is locally known to ASBR1, ASBR4 (loose next hop) is outside domain ... does that generate any failure ? i don't think so if authors/others could clarify ? ps: on the structure of this doc - if section 3 could concentrate on working assumptions and put examples (and other tutorial material) in appendix this would be helpful in facilitating reading -d. Internet-Drafts@ietf.org 30/08/2006 21:50 Please respond to internet-drafts To: i-d-announce@ietf.org cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Pages : 21 Date : 2006-8-30 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.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-ccamp-inter-domain-pd-path-comp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 02 Sep 2006 13:30:55 +0000 Message-ID: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Jean Philippe Vasseur'" , "Ross Callon" Subject: Routing Directorate comments on draft-ietf-ccamp-automesh-01 Date: Sat, 2 Sep 2006 14:25:29 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit Hi, We held an additional last call for this draft in the IGP working groups and received some further comments that JP has just addressed in a new revision. We have also received some comments from a review in the Routing Directorate that I am précising below. JP, authors: please look through these and let us know your proposals for dealing with them. Thanks, Adrian === 1) The Tail-end name field facilitates LSP identification. Is this a new form of LSP identification? If it is not new, then there should be a reference to RFC3209 and a statement of which RFC3209 fields are mapped to this IGP field. If it is not new then there is a significant concern that a new identification is being introduced when it is not needed. 2) The document mentions that the number of mesh groups is limited but potentially (depending on encoding) provides for binary encoding for 2^32-1 groups (although this might be constrained by OSPF's limit of a TLV size to 2^16 bytes. The document (and the authors) state that scaling of these extensions is not an issue because only a small number of mesh groups are likely to be in existence in a network, and any one router is unlikely to participate in more than a very few. There are two concerns: a) Whenever we say that something in the Internet is limited, history usually proves us wrong. Indeed, there is already a proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a similar mechanism for a problem that would have far more groups. b) The I-D does not itself impose any reasonable limits on the number of groups with the potential for a single router (by misconfiguration, design, or malice) advertising a very large number of groups. Thus, it appears that the scaling concerns are not properly addressed in this I-D. 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL and must at most appear once in a OSPF Router Information LSA or ISIS Router Capability TLV." but for addition/removal it mentions "conversely, if the LSR leaves a mesh-group the corresponding entry will be removed from the TE-MESH-GROUP TLV." What are these "entries" referring to - that there is a top-level TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions "No sub-TLV is currently defined for the TE-mesh-group TLV") ? AF>> My comment on this is that the definition of the TLVs seems unclear. AF>> From figure 2, it appears that some additional information can be AF>> present in the TLV after the fields listed, and (reading between the AF>> lines) it would appear that this additional information is a series of AF>> repeats of the set of fields to define multiple mesh groups. AF>> This could usefully be clarified considerably. AF>> AF>> But it is now unclear to me whether a single router can be a member AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one AF>> IPv6) are prohibited. 4) Small terminology issue in section 5.1 it says: "Note that both operations can be performed in the context of a single refresh." This is not a refresh. It is a trigger/update. A better term for OSPF would be "LSA origination". 5) Please state the applicability to OSPF v2 and or v3. Note that the Router_Cap document covers both v2 and v3 6) The term "fairly static" at the end of section 5.1 is meaningless without some relative context. Presumably this relates to the number times an LSR joins or leaves a mesh group over time. Is it intended to be relative to the IGP refresh period? Please clarify in an objective rather than a subjective way. 7) The security section (section 8) is inadequate and will undoubtedly be rejected by the security ADs. At the very least, the I-D needs a paragraph (i.e. more than one or two lines) explaining why there are no new security considerations. But what would be the impact of adding false mesh groups to a TLV? Is there anything (dangerous) that can be learned about the network by inspecting mesh group TLVs? Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Sep 2006 07:07:11 +0000 Message-ID: <08ee01c6cd94$fe01e9f0$89849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.txt Date: Fri, 1 Sep 2006 08:04:53 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi CCAMP, This revision addresses further IESG concerns with the security section. At this stage we believe that the I-D will now pass muster at the IESG and go forward to the RFC Editor. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Thursday, August 31, 2006 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > Title : A Framework for Inter-Domain Multiprotocol Label Switching Traffic > Engineering > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-inter-domain-framework-06.txt > Pages : 21 > Date : 2006-8-31 > > This document provides a framework for establishing and controlling > Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain > networks. > > For the purposes of this document, a domain is considered to be any > collection of network elements within a common sphere of address > management or path computational responsibility. Examples of such > domains include Interior Gateway Protocol (IGP) areas and Autonomous > Systems (ASs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.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-ccamp-inter-domain-framework-06.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-ccamp-inter-domain-framework-06.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. >