From l2vpn-bounces@ietf.org Tue Nov 01 09:41:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxKW-0002cY-Bx; Tue, 01 Nov 2005 09:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxKT-0002WR-Hb; Tue, 01 Nov 2005 09:41:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24279; Tue, 1 Nov 2005 09:41:17 -0500 (EST) Received: from napoleon.monoski.com ([63.225.114.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWxYs-0001U8-Do; Tue, 01 Nov 2005 09:56:30 -0500 Received: from [2.0.1.6] (rasputin-gw [2.0.1.6]) (authenticated bits=0) by napoleon.monoski.com (8.13.2/8.13.2) with ESMTP id jA1EeSQQ015487; Tue, 1 Nov 2005 07:40:51 -0700 (MST) Message-ID: <4367308E.1060402@cisco.com> Date: Tue, 01 Nov 2005 02:08:30 -0700 From: Luca Martini User-Agent: Thunderbird 1.4.1 (X11/20051006) MIME-Version: 1.0 To: Huke Hu Chun Zhe References: <001e01c5d9ca$2b7164c0$41666e0a@china.huawei.com> In-Reply-To: <001e01c5d9ca$2b7164c0$41666e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.7 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pwe3 Subject: Re: One issue and its solution in PWE3 draft draft-ietf-pwe3-segmented-pw-00.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Huke Hu Chun, Please note that this is a WG draft in PWE3, not L2VPN. Looping of multi segment PWs which are statically configured , is not a realistic problem. If somebody wants to *configure* a PW in a loop, I do not see any reason why they should be prevented from doing so. This is allowed on ATM VCs , and can also be achieved with ethernet vlans by disabling spanning tree protocol. The specified mode for PWE3 LDP protocol is liberal label retention, hence a label request should not be normally used. However you should note that the LDP messages are not just "forwarded" across segments. If an intermediate router received a label request for a specific PWE3 label mapping, and the previous segment is not setup ( ( ( which means that it does not yet have a label allocated to answer the request ), it simply will not answer nor forward the label request. I do not see any looping of messages in this situation. Luca Huke Hu Chun Zhe wrote: > *_ Dear All: Plz Check following issue found in > draft-ietf-pwe3-segmented-pw-00.txt and solutions we give below , Plz > give your valable comments on it . _* > > *_Looping of Switch VCs_* > > *_ _* > > > > /_Problem Description:_/ > > > > Consider the case as shown in the figure where a loop of SPE [switch VC] > is configured. In this case when a switch VCs are configured in a loop, > we may end up in a situation where our request message are infinitely > looped. > > > > In implementation where we opt to not store the unmatched remote mapping > information, we use the request message to get the information again > from the peers. Implementation that requires this feature to be > enabled/disabled from a command require request to get the mapping > information again. > > > > In the case thus described we end up in looping the request message > infinitely. > > > > SPE1 > > / \ > > / \ > > / \ > > / \ > > / \ > > / \ > > SPE2------------SPE3 > > > > > > Suppose S-PE1 send request to S-PE2 and S-PE3. On receiving this request > at S-PE2, we search and locate the corresponding Switch-VC configured; > the operation now would be to send the request message to the other > segment (PW) of this switch VC i.e. to S-PE3. When S-PE3 receives this > request, find the switch VC and would send the request to the other > segment (PW) i.e. to S-PE1. The S-PE1 would continue to send request > message as described above. Thus the request message would loop around > in this topology for ever. > > > > /_Solutions:_/ > > > > 1) PW Switching point TLV > > 2) Hop Count > > 3) Time To Live (TTL) > > > > > > *PW Switching point TLV* > > The draft /draft-ietf-pwe3-segmented-pw-xx/ [refer section 6.1.4] > mentions the use of PW Switching point TLV in the mapping/notification > message. This can be extended to the request message and the looping can > be avoided. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1|0| PW sw TLV (0x096B) | PW sw TLV Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | Variable Length Value | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Variable Length Value | > > | " | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The Type Values are assigned as follows: > > Type Length Description > > > > 0x00 0 Reserved > > 0x01 4 PW ID of last PW traversed > > 0x02 variable PW Switching Point description string > > 0x03 4 IP address of PW Switching Point (Optional) > > > > We can attach the LSR-ID of S-PE every time we generate / send the > request message, on receiving the request message a check is made to > make sure that the router LSR ID is not present in this TLV. In the > above case S-PE1 would receive the request message with the LSR-ID of > S-PE1, S-PE2 and S-PE3. We discard the request message as S-PE1 LSR ID > is present in the switching point TLV. > > > > In case of request message loop detection we do not send label release > as done in the case of mapping/notification. > > > > > > > > > > > > *Hop Count* > > * * > > Another solution to avoid the looping of request message would be to > append the Hop Count as done in draft /draft-ietf-mpls-rfc3036bis-xx/ > [refer section 3.4.4]. This would calculate the number of hops the > request message propagates. > > > > Type Length Description > > > > 0x04 4 Hop Count of PW Switching Point traversed > > > > Follow the procedure to discard the request message once the Hop Count > reaches a specified maximum value. > > > > *Time to Live [TTL]* > > * * > > Based on the above idea one can use a TTL field to avoid infinite > looping of request messages. As the message traverse through the hop, > the TTL value is thus decremented. The message is discarded when the > field value is zero. > > > > Type Length Description > > > > 0x04 4 TTL field value > > > > The field can be initialized to specified value. > > _ _ > From l2vpn-bounces@ietf.org Tue Nov 01 10:06:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxip-0001ei-Up; Tue, 01 Nov 2005 10:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxio-0001e4-GP for l2vpn@megatron.ietf.org; Tue, 01 Nov 2005 10:06:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25682 for ; Tue, 1 Nov 2005 10:06:26 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWxxB-0003SB-RX for l2vpn@ietf.org; Tue, 01 Nov 2005 10:21:40 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 6FC0464513 for ; Tue, 1 Nov 2005 08:06:10 -0700 (MST) Message-ID: <43678462.3050100@castlepoint.net> Date: Tue, 01 Nov 2005 08:06:10 -0700 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Subject: DRAFT: L2VPN WG Agenda for IETF 64 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, Please see below for the DRAFT Agenda for L2VPN for IETF 64. Please let us know if we missed any requests. -shane & Vach IETF 64: Layer 2 Virtual Private Network WG (l2vpn) Agenda Monday, November 7, 1130-1300 ============================== Chairs: Vach Kompella Shane Amante - Administrivia 10 min Agenda Bashing Minutes Blue Sheets WG Document Status - WG Document Status + draft-ietf-l2vpn-requirements-05 + draft-ietf-l2vpn-ipls-05 + draft-ietf-l2vpn-arp-mediation-04 + draft-ietf-l2vpn-signaling-06 + draft-aissaoui-l2vpn-vpws-iw-oam-04 --> WG Draft + draft-raggarwa-l2vpn-vpls-mcast-01 --> WG Draft Vach - L2VPN OAM Requirements and Framework http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-04.txt Dinesh Mohan 10 min - VPLS Interoperability with CE Bridges http://www.ietf.org/internet-drafts/draft-sajassi-l2vpn-vpls-bridge-interop-02.txt Ali Sajassi 10 min - Requirements for Multicast Support in Virtual Private LAN Services http://www.ietf.org/internet-drafts/draft-kamite-l2vpn-vpls-mcast-reqts-00.txt Yuji Kamite 10 min - PIM Snooping over VPLS http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt Venu Hemige 10 min - Using LDP for VPLS Multicast http://www.ietf.org/internet-drafts/draft-qiu-serbest-l2vpn-vpls-mcast-ldp-00.txt Ray Qiu 10 min - Meeting Closes From l2vpn-bounces@ietf.org Wed Nov 02 05:16:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXFf4-0005kP-6b; Wed, 02 Nov 2005 05:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXFf2-0005kE-E1; Wed, 02 Nov 2005 05:16:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24769; Wed, 2 Nov 2005 05:15:43 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXFta-0001EZ-No; Wed, 02 Nov 2005 05:31:07 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPB00KFCOR56V@szxga02-in.huawei.com>; Wed, 02 Nov 2005 18:21:05 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPB00F8ZOR4K0@szxga02-in.huawei.com>; Wed, 02 Nov 2005 18:21:05 +0800 (CST) Received: from h22280B ([10.110.102.65]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IPB006DCOQUIB@szxml02-in.huawei.com>; Wed, 02 Nov 2005 18:20:58 +0800 (CST) Date: Wed, 02 Nov 2005 18:11:41 +0800 From: Huke Hu Chun Zhe To: Luca Martini Message-id: <00c001c5df95$d4073350$41666e0a@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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <001e01c5d9ca$2b7164c0$41666e0a@china.huawei.com> <4367308E.1060402@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: 7BIT Cc: l2vpn@ietf.org, pwe3 Subject: Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Luca , Please see my in line comments ----- Original Message ----- From: "Luca Martini" To: "Huke Hu Chun Zhe" Cc: ; "pwe3" Sent: Tuesday, November 01, 2005 5:08 PM Subject: Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt > Huke Hu Chun, > > Please note that this is a WG draft in PWE3, not L2VPN. > Looping of multi segment PWs which are statically configured , is not a > realistic problem. If somebody wants to *configure* a PW in a loop, I do > not see any reason why they should be prevented from doing so. This is > allowed on ATM VCs , and can also be achieved with ethernet vlans by > disabling spanning tree protocol. we can not aviod in the real network , by mistake or even old network enhancement can not avoid to have a loop among switch points > The specified mode for PWE3 LDP protocol is liberal label retention, > hence a label request should not be normally used. It is correct in normal PtoP VLL case , but in multi-hop senario, request message can avoid the senario that switch point has lots of mapping but actually there is no configure or less VLL inside switch point. If request message import, there is no need for holding on all the mapping messase , instead, hold on all mapping which can match local configuration. and when new VLL configure, just send request and get it, Since in the switch point, it is not the original point which PW connect AC . > However you should note that the LDP messages are not just "forwarded" > across segments. If an intermediate router received a label request for > a specific PWE3 label mapping, and the previous segment is not setup ( ( > ( which means that it does not yet have a label allocated to answer the > request ), it simply will not answer nor forward the label request. > I do not see any looping of messages in this situation. Consider this senarion CE1---PE1-----SPE1---SPE2---PE2--CE2 PE1 has multi-hop both with SPE1 and SPE2, if request is not forwarded there is no way to let SPE2 know the PE1 exist and give reply . And also we suggest to import " request message " which can give us: Advantage of using Request Message 1) LDP provides us with a request message which can be useful in PWE3 to reduce the memory to store the remote LDP Mapping received. Also once we store less number of LDP Mappings (only the once you actually need right now) we end making the search and event handling much faster; No need to scan mappings that are not needed. 2) In cases where VPLS is also supported, the LDP mapping format for PWE3 and VPLS are the same so when LDP receives such a mapping, it notify it to both PWE3 and VPLS. In such a case the same mapping which is actually used by VPLS maybe stored with PWE3 and would never be used by it. Two copies of same message would end up being stored in the system. In the case where we do not store the mapping which is not matched we reduce the memory and consequently increase our search and event handling speed. > Luca > > > > Huke Hu Chun Zhe wrote: > > *_ Dear All: Plz Check following issue found in > > draft-ietf-pwe3-segmented-pw-00.txt and solutions we give below , Plz > > give your valable comments on it . _* > > > > *_Looping of Switch VCs_* > > > > *_ _* > > > > > > > > /_Problem Description:_/ > > > > > > > > Consider the case as shown in the figure where a loop of SPE [switch VC] > > is configured. In this case when a switch VCs are configured in a loop, > > we may end up in a situation where our request message are infinitely > > looped. > > > > > > > > In implementation where we opt to not store the unmatched remote mapping > > information, we use the request message to get the information again > > from the peers. Implementation that requires this feature to be > > enabled/disabled from a command require request to get the mapping > > information again. > > > > > > > > In the case thus described we end up in looping the request message > > infinitely. > > > > > > > > SPE1 > > > > / \ > > > > / \ > > > > / \ > > > > / \ > > > > / \ > > > > / \ > > > > SPE2------------SPE3 > > > > > > > > > > > > Suppose S-PE1 send request to S-PE2 and S-PE3. On receiving this request > > at S-PE2, we search and locate the corresponding Switch-VC configured; > > the operation now would be to send the request message to the other > > segment (PW) of this switch VC i.e. to S-PE3. When S-PE3 receives this > > request, find the switch VC and would send the request to the other > > segment (PW) i.e. to S-PE1. The S-PE1 would continue to send request > > message as described above. Thus the request message would loop around > > in this topology for ever. > > > > > > > > /_Solutions:_/ > > > > > > > > 1) PW Switching point TLV > > > > 2) Hop Count > > > > 3) Time To Live (TTL) > > > > > > > > > > > > *PW Switching point TLV* > > > > The draft /draft-ietf-pwe3-segmented-pw-xx/ [refer section 6.1.4] > > mentions the use of PW Switching point TLV in the mapping/notification > > message. This can be extended to the request message and the looping can > > be avoided. > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |1|0| PW sw TLV (0x096B) | PW sw TLV Length | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Type | Length | Variable Length Value | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Variable Length Value | > > > > | " | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > The Type Values are assigned as follows: > > > > Type Length Description > > > > > > > > 0x00 0 Reserved > > > > 0x01 4 PW ID of last PW traversed > > > > 0x02 variable PW Switching Point description string > > > > 0x03 4 IP address of PW Switching Point (Optional) > > > > > > > > We can attach the LSR-ID of S-PE every time we generate / send the > > request message, on receiving the request message a check is made to > > make sure that the router LSR ID is not present in this TLV. In the > > above case S-PE1 would receive the request message with the LSR-ID of > > S-PE1, S-PE2 and S-PE3. We discard the request message as S-PE1 LSR ID > > is present in the switching point TLV. > > > > > > > > In case of request message loop detection we do not send label release > > as done in the case of mapping/notification. > > > > > > > > > > > > > > > > > > > > > > > > *Hop Count* > > > > * * > > > > Another solution to avoid the looping of request message would be to > > append the Hop Count as done in draft /draft-ietf-mpls-rfc3036bis-xx/ > > [refer section 3.4.4]. This would calculate the number of hops the > > request message propagates. > > > > > > > > Type Length Description > > > > > > > > 0x04 4 Hop Count of PW Switching Point traversed > > > > > > > > Follow the procedure to discard the request message once the Hop Count > > reaches a specified maximum value. > > > > > > > > *Time to Live [TTL]* > > > > * * > > > > Based on the above idea one can use a TTL field to avoid infinite > > looping of request messages. As the message traverse through the hop, > > the TTL value is thus decremented. The message is discarded when the > > field value is zero. > > > > > > > > Type Length Description > > > > > > > > 0x04 4 TTL field value > > > > > > > > The field can be initialized to specified value. > > > > _ _ > > > > From l2vpn-bounces@ietf.org Wed Nov 02 08:27:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIe1-0000Jg-3d; Wed, 02 Nov 2005 08:27:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIdy-0000IA-HN; Wed, 02 Nov 2005 08:27:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05816; Wed, 2 Nov 2005 08:26:48 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXIsX-00010z-A8; Wed, 02 Nov 2005 08:42:15 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2005 05:26:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,280,1125903600"; d="scan'208"; a="14383673:sNHT124342512" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id jA2DQtcj028083; Wed, 2 Nov 2005 08:26:56 -0500 (EST) In-Reply-To: <00c001c5df95$d4073350$41666e0a@china.huawei.com> References: <001e01c5d9ca$2b7164c0$41666e0a@china.huawei.com> <4367308E.1060402@cisco.com> <00c001c5df95$d4073350$41666e0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Wed, 2 Nov 2005 08:26:49 -0500 To: Huke Hu Chun Zhe X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pwe3 , Luca Martini Subject: Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org On Nov 2, 2005, at 5:11 AM, Huke Hu Chun Zhe wrote: > Luca , > > Please see my in line comments > > ----- Original Message ----- > From: "Luca Martini" > To: "Huke Hu Chun Zhe" > Cc: ; "pwe3" > Sent: Tuesday, November 01, 2005 5:08 PM > Subject: Re: One issue and its solution in PWE3 draftdraft-ietf- > pwe3-segmented-pw-00.txt > > >> Huke Hu Chun, >> >> Please note that this is a WG draft in PWE3, not L2VPN. >> Looping of multi segment PWs which are statically configured , is >> not a >> realistic problem. If somebody wants to *configure* a PW in a >> loop, I do >> not see any reason why they should be prevented from doing so. >> This is >> allowed on ATM VCs , and can also be achieved with ethernet vlans by >> disabling spanning tree protocol. > > we can not aviod in the real network , by mistake > or even old network enhancement can not avoid to have a loop among > switch points I think you are missing Luca's original point. Since the segments are statically configured, the provisioning system should be able to understand (and prevent) loops. This is the same as PVC provisioning in ATM/Frame networks, which is well understood. Certainly there can be 'sticky fingers' cases, but they should be handled by the provisioning system. --Tom >> The specified mode for PWE3 LDP protocol is liberal label retention, >> hence a label request should not be normally used. > It is correct in normal PtoP VLL case , but in multi-hop senario, > request message can avoid the senario that switch point has lots of > mapping but actually there is no configure or less VLL inside > switch point. > If request message import, there is no need for holding on all the > mapping > messase , instead, hold on all mapping which can match local > configuration. > and when new VLL configure, just send request and get it, Since in > the switch > point, it is not the original point which PW connect AC . > >> However you should note that the LDP messages are not just >> "forwarded" >> across segments. If an intermediate router received a label >> request for >> a specific PWE3 label mapping, and the previous segment is not >> setup ( ( >> ( which means that it does not yet have a label allocated to >> answer the >> request ), it simply will not answer nor forward the label request. >> I do not see any looping of messages in this situation. > > Consider this senarion > CE1---PE1-----SPE1---SPE2---PE2--CE2 > PE1 has multi-hop both with SPE1 and SPE2, if request is not forwarded > there is no way to let SPE2 know the PE1 exist and give reply . > > And also we suggest to import " request message " which can give us: > > Advantage of using Request Message > > 1) LDP provides us with a request message which can be useful in > PWE3 to reduce the memory to store the remote LDP Mapping received. > Also once we store less number of LDP Mappings (only the once you > actually need right now) we end making the search and event > handling much faster; No need to scan mappings that are not needed. > > 2) In cases where VPLS is also supported, the LDP mapping format > for PWE3 and VPLS are the same so when LDP receives such a mapping, > it notify it to both PWE3 and VPLS. In such a case the same mapping > which is actually used by VPLS maybe stored with PWE3 and would > never be used by it. Two copies of same message would end up being > stored in the system. In the case where we do not store the mapping > which is not matched we reduce the memory and consequently increase > our search and event handling speed. > > >> Luca >> >> >> >> Huke Hu Chun Zhe wrote: >>> *_ Dear All: Plz Check following issue found in >>> draft-ietf-pwe3-segmented-pw-00.txt and solutions we give >>> below , Plz >>> give your valable comments on it . _* >>> >>> *_Looping of Switch VCs_* >>> >>> *_ _* >>> >>> >>> >>> /_Problem Description:_/ >>> >>> >>> >>> Consider the case as shown in the figure where a loop of SPE >>> [switch VC] >>> is configured. In this case when a switch VCs are configured in a >>> loop, >>> we may end up in a situation where our request message are >>> infinitely >>> looped. >>> >>> >>> >>> In implementation where we opt to not store the unmatched remote >>> mapping >>> information, we use the request message to get the information again >>> from the peers. Implementation that requires this feature to be >>> enabled/disabled from a command require request to get the mapping >>> information again. >>> >>> >>> >>> In the case thus described we end up in looping the request message >>> infinitely. >>> >>> >>> >>> SPE1 >>> >>> / \ >>> >>> / \ >>> >>> / \ >>> >>> / \ >>> >>> / \ >>> >>> / \ >>> >>> SPE2------------SPE3 >>> >>> >>> >>> >>> >>> Suppose S-PE1 send request to S-PE2 and S-PE3. On receiving this >>> request >>> at S-PE2, we search and locate the corresponding Switch-VC >>> configured; >>> the operation now would be to send the request message to the other >>> segment (PW) of this switch VC i.e. to S-PE3. When S-PE3 receives >>> this >>> request, find the switch VC and would send the request to the other >>> segment (PW) i.e. to S-PE1. The S-PE1 would continue to send request >>> message as described above. Thus the request message would loop >>> around >>> in this topology for ever. >>> >>> >>> >>> /_Solutions:_/ >>> >>> >>> >>> 1) PW Switching point TLV >>> >>> 2) Hop Count >>> >>> 3) Time To Live (TTL) >>> >>> >>> >>> >>> >>> *PW Switching point TLV* >>> >>> The draft /draft-ietf-pwe3-segmented-pw-xx/ [refer section 6.1.4] >>> mentions the use of PW Switching point TLV in the mapping/ >>> notification >>> message. This can be extended to the request message and the >>> looping can >>> be avoided. >>> >>> >>> >>> 0 1 2 3 >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> |1|0| PW sw TLV (0x096B) | PW sw TLV Length | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> | Type | Length | Variable Length Value | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> | Variable Length Value | >>> >>> | " | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> >>> >>> The Type Values are assigned as follows: >>> >>> Type Length Description >>> >>> >>> >>> 0x00 0 Reserved >>> >>> 0x01 4 PW ID of last PW traversed >>> >>> 0x02 variable PW Switching Point description string >>> >>> 0x03 4 IP address of PW Switching Point >>> (Optional) >>> >>> >>> >>> We can attach the LSR-ID of S-PE every time we generate / send the >>> request message, on receiving the request message a check is made to >>> make sure that the router LSR ID is not present in this TLV. In the >>> above case S-PE1 would receive the request message with the LSR- >>> ID of >>> S-PE1, S-PE2 and S-PE3. We discard the request message as S-PE1 >>> LSR ID >>> is present in the switching point TLV. >>> >>> >>> >>> In case of request message loop detection we do not send label >>> release >>> as done in the case of mapping/notification. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *Hop Count* >>> >>> * * >>> >>> Another solution to avoid the looping of request message would be to >>> append the Hop Count as done in draft /draft-ietf-mpls-rfc3036bis- >>> xx/ >>> [refer section 3.4.4]. This would calculate the number of hops the >>> request message propagates. >>> >>> >>> >>> Type Length Description >>> >>> >>> >>> 0x04 4 Hop Count of PW Switching Point traversed >>> >>> >>> >>> Follow the procedure to discard the request message once the Hop >>> Count >>> reaches a specified maximum value. >>> >>> >>> >>> *Time to Live [TTL]* >>> >>> * * >>> >>> Based on the above idea one can use a TTL field to avoid infinite >>> looping of request messages. As the message traverse through the >>> hop, >>> the TTL value is thus decremented. The message is discarded when the >>> field value is zero. >>> >>> >>> >>> Type Length Description >>> >>> >>> >>> 0x04 4 TTL field value >>> >>> >>> >>> The field can be initialized to specified value. >>> >>> _ _ >>> >> >> From l2vpn-bounces@ietf.org Wed Nov 02 23:30:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXWju-0001DV-72; Wed, 02 Nov 2005 23:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXWjr-0001BV-Qb for l2vpn@megatron.ietf.org; Wed, 02 Nov 2005 23:30:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00255 for ; Wed, 2 Nov 2005 23:29:50 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXWyZ-0001IF-FM for l2vpn@ietf.org; Wed, 02 Nov 2005 23:45:24 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 002E16450D for ; Wed, 2 Nov 2005 21:29:52 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <5AE53DC8-081C-41E1-A273-18193462693E@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Wed, 2 Nov 2005 21:29:55 -0700 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Subject: FINAL: L2VPN WG Agenda for IETF 64 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, Below is the final L2VPN WG Agenda for IETF 64. There was only one minor correction from the Draft Agenda: a minor change to reflect the proper URL to draft-ietf-l2vpn-vpls-mcast-reqts-00.txt. Since we have an early slot on Monday, Vach & I would appreciate it if you could forward your presentations to us no later than Sunday evening, 11/6, so that we may have them on our laptops for presentation at the meeting, and for archiving in the IETF 64 Meeting Minutes. Thanks, -shane & Vach ---cut here--- IETF 64: Layer 2 Virtual Private Network WG (l2vpn) Agenda Monday, November 7, 1130-1300 ============================== Chairs: Vach Kompella Shane Amante - Administrivia 10 min Agenda Bashing Minutes Blue Sheets WG Document Status - WG Document Status + draft-ietf-l2vpn-requirements-05 + draft-ietf-l2vpn-ipls-05 + draft-ietf-l2vpn-arp-mediation-04 + draft-ietf-l2vpn-signaling-06 + draft-aissaoui-l2vpn-vpws-iw-oam-04 --> WG Draft + draft-raggarwa-l2vpn-vpls-mcast-01 --> WG Draft Vach - L2VPN OAM Requirements and Framework http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-04.txt Dinesh Mohan 10 min - VPLS Interoperability with CE Bridges http://www.ietf.org/internet-drafts/draft-sajassi-l2vpn-vpls-bridge-inte rop-02.txt Ali Sajassi 10 min - Requirements for Multicast Support in Virtual Private LAN Services http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast- reqts-00.txt Yuji Kamite 10 min - PIM Snooping over VPLS http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls-pim- snooping-00.txt Venu Hemige 10 min - Using LDP for VPLS Multicast http://www.ietf.org/internet-drafts/draft-qiu-serbest-l2vpn-vpls-mcast-l dp-00.txt Ray Qiu 10 min - Meeting Closes From l2vpn-bounces@ietf.org Mon Nov 07 03:18:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ2DB-0007Y1-3v; Mon, 07 Nov 2005 03:18:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ2D9-0007Xw-Fl for l2vpn@megatron.ietf.org; Mon, 07 Nov 2005 03:18:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24509 for ; Mon, 7 Nov 2005 03:18:12 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ2Sh-0004HF-JE for l2vpn@ietf.org; Mon, 07 Nov 2005 03:34:44 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id ADB5364388 for ; Mon, 7 Nov 2005 01:18:01 -0700 (MST) Message-ID: <436F0DBC.7010901@castlepoint.net> Date: Mon, 07 Nov 2005 01:18:04 -0700 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: L2VPN Agenda Online X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, The L2VPN Agenda is now online: http://l2vpn.tcb.net/meetings/ietf64/index.html For those who have not submitted materials, please send them ASAP. Thanks, -shane & Vach From l2vpn-bounces@ietf.org Tue Nov 08 20:20:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZeV4-0001oH-Jx; Tue, 08 Nov 2005 20:11:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZeV3-0001mn-7f; Tue, 08 Nov 2005 20:11:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00593; Tue, 8 Nov 2005 20:11:14 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZekn-0002hj-D9; Tue, 08 Nov 2005 20:28:08 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPN00CBNYBNQZ@szxga01-in.huawei.com>; Wed, 09 Nov 2005 09:18:59 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPN00AQJYBMMH@szxga01-in.huawei.com>; Wed, 09 Nov 2005 09:18:58 +0800 (CST) Received: from h22280B ([10.110.102.65]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IPN00GLQYK2WN@szxml01-in.huawei.com>; Wed, 09 Nov 2005 09:24:03 +0800 (CST) Date: Wed, 09 Nov 2005 09:11:15 +0800 From: Huke Hu Chun Zhe To: "Thomas D. Nadeau" Message-id: <000701c5e4ca$7b7b6be0$41666e0a@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: <001e01c5d9ca$2b7164c0$41666e0a@china.huawei.com> <4367308E.1060402@cisco.com> <00c001c5df95$d4073350$41666e0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Content-Transfer-Encoding: 7BIT Cc: l2vpn@ietf.org, Luca Martini , pwe3 Subject: Re: One issue and its solution in PWE3draftdraft-ietf-pwe3-segmented-pw-00.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org To Mike's feedback: In our implementation, signaling messages are routed to the next hop. But the SPEs are misconfigured as the next hop of another one by one, so forms the loop. To Thomas's feedback: The purpose of us is just to provide a way to handle the loop problem in 'sticky fingers' cases, which is to append sw TLV to LDP label request message. To Luca Martini: >> However you should note that the LDP messages are not just >> "forwarded" >> across segments. If an intermediate router received a label >> request for >> a specific PWE3 label mapping, and the previous segment is not >> setup ( ( >> ( which means that it does not yet have a label allocated to >> answer the >> request ), it simply will not answer nor forward the label request. It seems to be another way to resolve the loop problem. When an intermediate router receives a request message and no label is allocated for it, the message is discarded, for the UPE on the other side of this intermediate router must not be setup. It is useless to forward the request message.But in our description, SPE can forward request msg. And , we found to import REQUEST MSG can improve the performance , and keep the useless mapping GONE. ----- Original Message ----- From: "Thomas D. Nadeau" To: "Huke Hu Chun Zhe" Cc: ; "pwe3" ; "Luca Martini" Sent: Wednesday, November 02, 2005 9:26 PM Subject: Re: One issue and its solution in PWE3draftdraft-ietf-pwe3-segmented-pw-00.txt > > On Nov 2, 2005, at 5:11 AM, Huke Hu Chun Zhe wrote: > > > Luca , > > > > Please see my in line comments > > > > ----- Original Message ----- > > From: "Luca Martini" > > To: "Huke Hu Chun Zhe" > > Cc: ; "pwe3" > > Sent: Tuesday, November 01, 2005 5:08 PM > > Subject: Re: One issue and its solution in PWE3 draftdraft-ietf- > > pwe3-segmented-pw-00.txt > > > > > >> Huke Hu Chun, > >> > >> Please note that this is a WG draft in PWE3, not L2VPN. > >> Looping of multi segment PWs which are statically configured , is > >> not a > >> realistic problem. If somebody wants to *configure* a PW in a > >> loop, I do > >> not see any reason why they should be prevented from doing so. > >> This is > >> allowed on ATM VCs , and can also be achieved with ethernet vlans by > >> disabling spanning tree protocol. > > > > we can not aviod in the real network , by mistake > > or even old network enhancement can not avoid to have a loop among > > switch points > > I think you are missing Luca's original point. Since > the segments are statically configured, the provisioning > system should be able to understand (and prevent) > loops. This is the same as PVC provisioning in ATM/Frame > networks, which is well understood. Certainly there > can be 'sticky fingers' cases, but they should be handled > by the provisioning system. > > --Tom > > > >> The specified mode for PWE3 LDP protocol is liberal label retention, > >> hence a label request should not be normally used. > > It is correct in normal PtoP VLL case , but in multi-hop senario, > > request message can avoid the senario that switch point has lots of > > mapping but actually there is no configure or less VLL inside > > switch point. > > If request message import, there is no need for holding on all the > > mapping > > messase , instead, hold on all mapping which can match local > > configuration. > > and when new VLL configure, just send request and get it, Since in > > the switch > > point, it is not the original point which PW connect AC . > > > >> However you should note that the LDP messages are not just > >> "forwarded" > >> across segments. If an intermediate router received a label > >> request for > >> a specific PWE3 label mapping, and the previous segment is not > >> setup ( ( > >> ( which means that it does not yet have a label allocated to > >> answer the > >> request ), it simply will not answer nor forward the label request. > >> I do not see any looping of messages in this situation. > > > > Consider this senarion > > CE1---PE1-----SPE1---SPE2---PE2--CE2 > > PE1 has multi-hop both with SPE1 and SPE2, if request is not forwarded > > there is no way to let SPE2 know the PE1 exist and give reply . > > > > And also we suggest to import " request message " which can give us: > > > > Advantage of using Request Message > > > > 1) LDP provides us with a request message which can be useful in > > PWE3 to reduce the memory to store the remote LDP Mapping received. > > Also once we store less number of LDP Mappings (only the once you > > actually need right now) we end making the search and event > > handling much faster; No need to scan mappings that are not needed. > > > > 2) In cases where VPLS is also supported, the LDP mapping format > > for PWE3 and VPLS are the same so when LDP receives such a mapping, > > it notify it to both PWE3 and VPLS. In such a case the same mapping > > which is actually used by VPLS maybe stored with PWE3 and would > > never be used by it. Two copies of same message would end up being > > stored in the system. In the case where we do not store the mapping > > which is not matched we reduce the memory and consequently increase > > our search and event handling speed. > > > > > >> Luca > >> > >> > >> > >> Huke Hu Chun Zhe wrote: > >>> *_ Dear All: Plz Check following issue found in > >>> draft-ietf-pwe3-segmented-pw-00.txt and solutions we give > >>> below , Plz > >>> give your valable comments on it . _* > >>> > >>> *_Looping of Switch VCs_* > >>> > >>> *_ _* > >>> > >>> > >>> > >>> /_Problem Description:_/ > >>> > >>> > >>> > >>> Consider the case as shown in the figure where a loop of SPE > >>> [switch VC] > >>> is configured. In this case when a switch VCs are configured in a > >>> loop, > >>> we may end up in a situation where our request message are > >>> infinitely > >>> looped. > >>> > >>> > >>> > >>> In implementation where we opt to not store the unmatched remote > >>> mapping > >>> information, we use the request message to get the information again > >>> from the peers. Implementation that requires this feature to be > >>> enabled/disabled from a command require request to get the mapping > >>> information again. > >>> > >>> > >>> > >>> In the case thus described we end up in looping the request message > >>> infinitely. > >>> > >>> > >>> > >>> SPE1 > >>> > >>> / \ > >>> > >>> / \ > >>> > >>> / \ > >>> > >>> / \ > >>> > >>> / \ > >>> > >>> / \ > >>> > >>> SPE2------------SPE3 > >>> > >>> > >>> > >>> > >>> > >>> Suppose S-PE1 send request to S-PE2 and S-PE3. On receiving this > >>> request > >>> at S-PE2, we search and locate the corresponding Switch-VC > >>> configured; > >>> the operation now would be to send the request message to the other > >>> segment (PW) of this switch VC i.e. to S-PE3. When S-PE3 receives > >>> this > >>> request, find the switch VC and would send the request to the other > >>> segment (PW) i.e. to S-PE1. The S-PE1 would continue to send request > >>> message as described above. Thus the request message would loop > >>> around > >>> in this topology for ever. > >>> > >>> > >>> > >>> /_Solutions:_/ > >>> > >>> > >>> > >>> 1) PW Switching point TLV > >>> > >>> 2) Hop Count > >>> > >>> 3) Time To Live (TTL) > >>> > >>> > >>> > >>> > >>> > >>> *PW Switching point TLV* > >>> > >>> The draft /draft-ietf-pwe3-segmented-pw-xx/ [refer section 6.1.4] > >>> mentions the use of PW Switching point TLV in the mapping/ > >>> notification > >>> message. This can be extended to the request message and the > >>> looping can > >>> be avoided. > >>> > >>> > >>> > >>> 0 1 2 3 > >>> > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> |1|0| PW sw TLV (0x096B) | PW sw TLV Length | > >>> > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> | Type | Length | Variable Length Value | > >>> > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> | Variable Length Value | > >>> > >>> | " | > >>> > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> > >>> > >>> > >>> > >>> The Type Values are assigned as follows: > >>> > >>> Type Length Description > >>> > >>> > >>> > >>> 0x00 0 Reserved > >>> > >>> 0x01 4 PW ID of last PW traversed > >>> > >>> 0x02 variable PW Switching Point description string > >>> > >>> 0x03 4 IP address of PW Switching Point > >>> (Optional) > >>> > >>> > >>> > >>> We can attach the LSR-ID of S-PE every time we generate / send the > >>> request message, on receiving the request message a check is made to > >>> make sure that the router LSR ID is not present in this TLV. In the > >>> above case S-PE1 would receive the request message with the LSR- > >>> ID of > >>> S-PE1, S-PE2 and S-PE3. We discard the request message as S-PE1 > >>> LSR ID > >>> is present in the switching point TLV. > >>> > >>> > >>> > >>> In case of request message loop detection we do not send label > >>> release > >>> as done in the case of mapping/notification. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> *Hop Count* > >>> > >>> * * > >>> > >>> Another solution to avoid the looping of request message would be to > >>> append the Hop Count as done in draft /draft-ietf-mpls-rfc3036bis- > >>> xx/ > >>> [refer section 3.4.4]. This would calculate the number of hops the > >>> request message propagates. > >>> > >>> > >>> > >>> Type Length Description > >>> > >>> > >>> > >>> 0x04 4 Hop Count of PW Switching Point traversed > >>> > >>> > >>> > >>> Follow the procedure to discard the request message once the Hop > >>> Count > >>> reaches a specified maximum value. > >>> > >>> > >>> > >>> *Time to Live [TTL]* > >>> > >>> * * > >>> > >>> Based on the above idea one can use a TTL field to avoid infinite > >>> looping of request messages. As the message traverse through the > >>> hop, > >>> the TTL value is thus decremented. The message is discarded when the > >>> field value is zero. > >>> > >>> > >>> > >>> Type Length Description > >>> > >>> > >>> > >>> 0x04 4 TTL field value > >>> > >>> > >>> > >>> The field can be initialized to specified value. > >>> > >>> _ _ > >>> > >> > >> > From l2vpn-bounces@ietf.org Sat Nov 12 20:13:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb6RM-0003TI-HM; Sat, 12 Nov 2005 20:13:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb6RL-0003TD-Pi for l2vpn@megatron.ietf.org; Sat, 12 Nov 2005 20:13:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03935 for ; Sat, 12 Nov 2005 20:13:19 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb6i2-0005fV-4u for l2vpn@ietf.org; Sat, 12 Nov 2005 20:31:07 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 52F9664352 for ; Sat, 12 Nov 2005 18:13:24 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <5579B6D8-916C-4911-A3DE-E32A44245561@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Sat, 12 Nov 2005 18:13:27 -0700 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: L2VPN @ IETF64 Draft Meeting Minutes X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, Draft meeting minutes of the L2VPN WG session at IETF 64 have been uploaded to the IETF Web site. Please see: http://www3.ietf.org/ proceedings/05nov/minutes/l2vpn.txt Thanks to Prakash Jayaraman, Andrew Dolganow and Giles Heron for taking minutes. In addition, the L2VPN agenda, minutes and presentations for L2VPN @ IETF 64 have been uploaded to the IETF datatracker site, as well: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 Please mail to the list if you have any corrections, comments, etc. Any corrections to the minutes must be submitted no later than 12/2/2005, (to give us time to meet the submissions cut-off date of 12/9/2005). -shane & Vach From l2vpn-bounces@ietf.org Mon Nov 14 18:07:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnQ8-0003Uo-TQ; Mon, 14 Nov 2005 18:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKbr-0005lq-Gy; Wed, 02 Nov 2005 10:33:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13480; Wed, 2 Nov 2005 10:32:44 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKqR-00078n-9O; Wed, 02 Nov 2005 10:48:11 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA2FWfG26114; Wed, 2 Nov 2005 10:32:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2005 10:32:41 -0500 Message-ID: <4B7DAC3FEFD35D4A96BDD01169905014788DD6@zrtphxm1.corp.nortel.com> Thread-Topic: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt Thread-Index: AcXflsf7aiICCaS/TU+OtK85ZRwLDgAK2UGg From: "Mike Loomis" To: "Huke Hu Chun Zhe" , "Luca Martini" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Nov 2005 18:07:25 -0500 Cc: l2vpn@ietf.org, pwe3 Subject: RE: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Huke, It appears you may be confusing the case of dynamic setup of MS-PW vs. static setup of MS-PW. Please see draft-balus-bocci-martini-dyn-ms-pwe3-00.txt for procedures on dynamic setup. In this case the signaling messages are not flooded by S-PE, but routed to the next hop. See section 6.2. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Huke Hu Chun Zhe Sent: Wednesday, November 02, 2005 5:12 AM To: Luca Martini Cc: l2vpn@ietf.org; pwe3 Subject: Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt Luca ,=20 Please see my in line comments ----- Original Message -----=20 From: "Luca Martini" To: "Huke Hu Chun Zhe" Cc: ; "pwe3" Sent: Tuesday, November 01, 2005 5:08 PM Subject: Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt > Huke Hu Chun, >=20 > Please note that this is a WG draft in PWE3, not L2VPN. Looping of=20 > multi segment PWs which are statically configured , is not a realistic > problem. If somebody wants to *configure* a PW in a loop, I do not see > any reason why they should be prevented from doing so. This is allowed > on ATM VCs , and can also be achieved with ethernet vlans by disabling > spanning tree protocol. we can not aviod in the real network , by mistake=20 or even old network enhancement can not avoid to have a loop among switch points=20 > The specified mode for PWE3 LDP protocol is liberal label retention,=20 > hence a label request should not be normally used. It is correct in normal PtoP VLL case , but in multi-hop senario, request message can avoid the senario that switch point has lots of=20 mapping but actually there is no configure or less VLL inside switch point. If request message import, there is no need for holding on all the mapping=20 messase , instead, hold on all mapping which can match local configuration. and when new VLL configure, just send request and get it, Since in the switch=20 point, it is not the original point which PW connect AC . > However you should note that the LDP messages are not just "forwarded" > across segments. If an intermediate router received a label request=20 > for a specific PWE3 label mapping, and the previous segment is not=20 > setup ( ( ( which means that it does not yet have a label allocated to > answer the request ), it simply will not answer nor forward the label=20 > request. I do not see any looping of messages in this situation. Consider this senarion=20 CE1---PE1-----SPE1---SPE2---PE2--CE2 PE1 has multi-hop both with SPE1 and SPE2, if request is not forwarded there is no way to let SPE2 know the PE1 exist and give reply . And also we suggest to import " request message " which can give us: Advantage of using Request Message 1) LDP provides us with a request message which can be useful in PWE3 to reduce the memory to store the remote LDP Mapping received. Also once we store less number of LDP Mappings (only the once you actually need right now) we end making the search and event handling much faster; No need to scan mappings that are not needed.=20 2) In cases where VPLS is also supported, the LDP mapping format for PWE3 and VPLS are the same so when LDP receives such a mapping, it notify it to both PWE3 and VPLS. In such a case the same mapping which is actually used by VPLS maybe stored with PWE3 and would never be used by it. Two copies of same message would end up being stored in the system. In the case where we do not store the mapping which is not matched we reduce the memory and consequently increase our search and event handling speed.=20 =20 > Luca >=20 >=20 >=20 > Huke Hu Chun Zhe wrote: > > *_ Dear All: Plz Check following issue found in=20 > > draft-ietf-pwe3-segmented-pw-00.txt and solutions we give below , Plz=20 > > give your valable comments on it . _* > >=20 > > *_Looping of Switch VCs_* > >=20 > > *_ _* > >=20 > > =20 > >=20 > > /_Problem Description:_/ > >=20 > > =20 > >=20 > > Consider the case as shown in the figure where a loop of SPE [switch > > VC] > > is configured. In this case when a switch VCs are configured in a loop,=20 > > we may end up in a situation where our request message are infinitely=20 > > looped. > >=20 > > =20 > >=20 > > In implementation where we opt to not store the unmatched remote=20 > > mapping > > information, we use the request message to get the information again > > from the peers. Implementation that requires this feature to be=20 > > enabled/disabled from a command require request to get the mapping=20 > > information again. > >=20 > > =20 > >=20 > > In the case thus described we end up in looping the request message > > infinitely. > >=20 > > =20 > >=20 > > SPE1 > >=20 > > / \ > >=20 > > / \ > >=20 > > / \ =20 > >=20 > > / \ > >=20 > > / \=20 > >=20 > > / \ > >=20 > > SPE2------------SPE3 > >=20 > > =20 > >=20 > > =20 > >=20 > > Suppose S-PE1 send request to S-PE2 and S-PE3. On receiving this=20 > > request > > at S-PE2, we search and locate the corresponding Switch-VC configured;=20 > > the operation now would be to send the request message to the other=20 > > segment (PW) of this switch VC i.e. to S-PE3. When S-PE3 receives this=20 > > request, find the switch VC and would send the request to the other=20 > > segment (PW) i.e. to S-PE1. The S-PE1 would continue to send request > > message as described above. Thus the request message would loop around=20 > > in this topology for ever. > >=20 > > =20 > >=20 > > /_Solutions:_/ > >=20 > > =20 > >=20 > > 1) PW Switching point TLV > >=20 > > 2) Hop Count > >=20 > > 3) Time To Live (TTL) > >=20 > > =20 > >=20 > > =20 > >=20 > > *PW Switching point TLV* > >=20 > > The draft /draft-ietf-pwe3-segmented-pw-xx/ [refer section 6.1.4] > > mentions the use of PW Switching point TLV in the mapping/notification=20 > > message. This can be extended to the request message and the looping can=20 > > be avoided. > >=20 > > =20 > >=20 > > 0 1 2 3 > >=20 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >=20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > |1|0| PW sw TLV (0x096B) | PW sw TLV Length | > >=20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > | Type | Length | Variable Length Value | > >=20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > | Variable Length Value | > >=20 > > | " | > >=20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > =20 > >=20 > > =20 > >=20 > > The Type Values are assigned as follows: > >=20 > > Type Length Description > >=20 > > =20 > >=20 > > 0x00 0 Reserved > >=20 > > 0x01 4 PW ID of last PW traversed > >=20 > > 0x02 variable PW Switching Point description string > >=20 > > 0x03 4 IP address of PW Switching Point (Optional) > >=20 > > =20 > >=20 > > We can attach the LSR-ID of S-PE every time we generate / send the > > request message, on receiving the request message a check is made to > > make sure that the router LSR ID is not present in this TLV. In the=20 > > above case S-PE1 would receive the request message with the LSR-ID of=20 > > S-PE1, S-PE2 and S-PE3. We discard the request message as S-PE1 LSR ID=20 > > is present in the switching point TLV. > >=20 > > =20 > >=20 > > In case of request message loop detection we do not send label=20 > > release > > as done in the case of mapping/notification. > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > *Hop Count* > >=20 > > * * > >=20 > > Another solution to avoid the looping of request message would be to > > append the Hop Count as done in draft /draft-ietf-mpls-rfc3036bis-xx/=20 > > [refer section 3.4.4]. This would calculate the number of hops the=20 > > request message propagates. > >=20 > > =20 > >=20 > > Type Length Description > >=20 > > =20 > >=20 > > 0x04 4 Hop Count of PW Switching Point traversed > >=20 > > =20 > >=20 > > Follow the procedure to discard the request message once the Hop=20 > > Count > > reaches a specified maximum value. > >=20 > > =20 > >=20 > > *Time to Live [TTL]* > >=20 > > * * > >=20 > > Based on the above idea one can use a TTL field to avoid infinite > > looping of request messages. As the message traverse through the hop,=20 > > the TTL value is thus decremented. The message is discarded when the > > field value is zero. > >=20 > > =20 > >=20 > > Type Length Description > >=20 > > =20 > >=20 > > 0x04 4 TTL field value > >=20 > > =20 > >=20 > > The field can be initialized to specified value. > >=20 > > _ _ > >=20 >=20 >=20 From l2vpn-bounces@ietf.org Tue Nov 15 05:55:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbySw-0001Wj-EX; Tue, 15 Nov 2005 05:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbySv-0001UT-0U for l2vpn@megatron.ietf.org; Tue, 15 Nov 2005 05:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17010 for ; Tue, 15 Nov 2005 05:54:31 -0500 (EST) Received: from www-intern.eantc.de ([130.149.224.52] helo=obelix.eantc.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebyk7-0008MY-F8 for l2vpn@ietf.org; Tue, 15 Nov 2005 06:12:52 -0500 Received: from asterix.eantc.de (asterix [130.149.224.78]) by obelix.eantc.de (8.9.3/8.9.3) with ESMTP id LAA26122 for ; Tue, 15 Nov 2005 11:54:44 +0100 (MET) Received: from localhost (ganbar@localhost) by asterix.eantc.de (8.13.3+Sun/8.13.3/Submit) with ESMTP id jAFAshJS026246 for ; Tue, 15 Nov 2005 11:54:44 +0100 (MET) X-Authentication-Warning: asterix.eantc.de: ganbar owned process doing -bs Date: Tue, 15 Nov 2005 11:54:43 +0100 (MET) From: Jambi Ganbar To: l2vpn@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: pim/igmp snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org hi all, from reading the ietf64 l2vpn wg minutes seems that there is a lot of changes to the various multicast related drafts in the working group. has any vendors implemented any of the PE snooping proposals? i have seen some announcements from Riverstone on the subject but it seems like a moving target... tia jambi From l2vpn-bounces@ietf.org Tue Nov 15 07:53:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0J8-0005Ts-TO; Tue, 15 Nov 2005 07:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0J7-0005Tk-48 for l2vpn@megatron.ietf.org; Tue, 15 Nov 2005 07:53:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21923 for ; Tue, 15 Nov 2005 07:52:31 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec0aI-00033j-Fm for l2vpn@ietf.org; Tue, 15 Nov 2005 08:10:51 -0500 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id EAA11779; Tue, 15 Nov 2005 04:52:24 -0800 (PST) Message-ID: <043d01c5e9e3$5c0d7140$6601a8c0@IBMT41ML> From: "Marc Lasserre" To: "Jambi Ganbar" , References: Date: Tue, 15 Nov 2005 13:51:53 +0100 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-Spam-Score: 2.9 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Subject: Re: pim/igmp snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Jambi, Most of the changes went into splitting the various multicast related drafts into different functional areas and removing sections that are already addressed in separate working groups. Hence the original draft-serbest is now split into two separate drafts: - The PIM snooping draft (draft-hemige-serbest-l2vpn-vpls-pim-snooping) (IGMP snooping is defined in magma) - LDP mcast state distribution draft (draft-qiu-serbest-l2vpn-vpls-mcast-ldp) As far as specific vendor implementations, I am sure that equipement vendors can provide you with the relevant information off list. Cheers, Marc ----- Original Message ----- From: "Jambi Ganbar" To: Sent: Tuesday, November 15, 2005 11:54 AM Subject: pim/igmp snooping > hi all, > from reading the ietf64 l2vpn wg minutes seems that there is a lot of > changes to the various multicast related drafts in the working group. > has any vendors implemented any of the PE snooping proposals? i have seen > some announcements from Riverstone on the subject but it seems like a > moving target... > tia > jambi > > > From l2vpn-bounces@ietf.org Tue Nov 15 08:36:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0ye-0000ZH-PQ; Tue, 15 Nov 2005 08:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0yb-0000Yr-34 for l2vpn@megatron.ietf.org; Tue, 15 Nov 2005 08:35:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24758 for ; Tue, 15 Nov 2005 08:35:25 -0500 (EST) Received: from www-intern.eantc.de ([130.149.224.52] helo=obelix.eantc.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec1Fp-0004Tn-1A for l2vpn@ietf.org; Tue, 15 Nov 2005 08:53:46 -0500 Received: from asterix.eantc.de (asterix [130.149.224.78]) by obelix.eantc.de (8.9.3/8.9.3) with ESMTP id OAA27033; Tue, 15 Nov 2005 14:35:42 +0100 (MET) Received: from localhost (ganbar@localhost) by asterix.eantc.de (8.13.3+Sun/8.13.3/Submit) with ESMTP id jAFDZfFY029094; Tue, 15 Nov 2005 14:35:42 +0100 (MET) X-Authentication-Warning: asterix.eantc.de: ganbar owned process doing -bs Date: Tue, 15 Nov 2005 14:35:41 +0100 (MET) From: Jambi Ganbar To: Marc Lasserre In-Reply-To: <043d01c5e9e3$5c0d7140$6601a8c0@IBMT41ML> Message-ID: References: <043d01c5e9e3$5c0d7140$6601a8c0@IBMT41ML> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: l2vpn@ietf.org Subject: Re: pim/igmp snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Marc, Thanks for the comments. I'm aware of the changes made but from reading the minutes it seemed that there is not a great deal of support for LDP and PIM suppression is also a point of contention. So I'm interested in finding out who has implementations. I'll be happy to see answers off line of course and if people are interested can compile a summary. thanks jambi On Tue, 15 Nov 2005, Marc Lasserre wrote: > Jambi, > > Most of the changes went into splitting the various multicast related drafts > into > different functional areas and removing sections that are already addressed > in > separate working groups. Hence the original draft-serbest is now split into > two > separate drafts: > > - The PIM snooping draft (draft-hemige-serbest-l2vpn-vpls-pim-snooping) > (IGMP snooping is defined in magma) > - LDP mcast state distribution draft (draft-qiu-serbest-l2vpn-vpls-mcast-ldp) > > As far as specific vendor implementations, I am sure that equipement vendors > can provide you with the relevant information off list. > > Cheers, > Marc > > ----- Original Message ----- From: "Jambi Ganbar" > To: > Sent: Tuesday, November 15, 2005 11:54 AM > Subject: pim/igmp snooping > > >> hi all, >> from reading the ietf64 l2vpn wg minutes seems that there is a lot of >> changes to the various multicast related drafts in the working group. >> has any vendors implemented any of the PE snooping proposals? i have seen >> some announcements from Riverstone on the subject but it seems like a >> moving target... >> tia >> jambi >> >> >> > > > From l2vpn-bounces@ietf.org Tue Nov 15 18:50:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAZF-0004Qe-MD; Tue, 15 Nov 2005 18:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAYt-0004K4-3p; Tue, 15 Nov 2005 18:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07545; Tue, 15 Nov 2005 18:49:29 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcAqC-0000OJ-Rs; Tue, 15 Nov 2005 19:07:57 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EcAYr-0001gw-DI; Tue, 15 Nov 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 15 Nov 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-ldp-08.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Virtual Private LAN Services over MPLS Author(s) : M. Lasserre, V. Kompella Filename : draft-ietf-l2vpn-vpls-ldp-08.txt Pages : 26 Date : 2005-11-15 This document describes a Virtual Private LAN Service (VPLS) solution using pseudo-wires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users, i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Multiple VPLS services can be supported from a single PE node. This document describes the control plane functions of signaling pseudo-wire labels using LDP [RFC3036], extending [PWE3-CTRL]. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [PWE3-ETHERNET]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-08.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-l2vpn-vpls-ldp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-ldp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-15165223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-ldp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-ldp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-15165223.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Wed Nov 16 00:05:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcFU7-0002P9-8s; Wed, 16 Nov 2005 00:05:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcFU3-0002ON-IG for l2vpn@megatron.ietf.org; Wed, 16 Nov 2005 00:05:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29328 for ; Wed, 16 Nov 2005 00:04:50 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcFlP-0002ss-Jg for l2vpn@ietf.org; Wed, 16 Nov 2005 00:23:20 -0500 Received: from [192.168.1.2] (c-24-6-40-57.hsd1.ca.comcast.net[24.6.40.57]) by comcast.net (rwcrmhc12) with ESMTP id <2005111605050701400npdk7e>; Wed, 16 Nov 2005 05:05:07 +0000 Message-ID: <437ABE01.9080003@hotpop.com> Date: Tue, 15 Nov 2005 21:05:05 -0800 From: Junaid User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jambi Ganbar References: <043d01c5e9e3$5c0d7140$6601a8c0@IBMT41ML> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Marc Lasserre Subject: Re: pim/igmp snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hmmmmmmm...... I would also like to know if there are any implementaions as such. Offlinne is good food for me. Thanks Junaid Jambi Ganbar wrote: > Marc, > Thanks for the comments. I'm aware of the changes made but from > reading the minutes it seemed that there is not a great deal of support > for LDP and PIM suppression is also a point of contention. > So I'm interested in finding out who has implementations. I'll be happy > to see answers off line of course and if people are interested can > compile a summary. > > thanks > jambi > On Tue, 15 Nov 2005, Marc Lasserre wrote: > >> Jambi, >> >> Most of the changes went into splitting the various multicast related >> drafts into >> different functional areas and removing sections that are already >> addressed in >> separate working groups. Hence the original draft-serbest is now split >> into two >> separate drafts: >> >> - The PIM snooping draft (draft-hemige-serbest-l2vpn-vpls-pim-snooping) >> (IGMP snooping is defined in magma) >> - LDP mcast state distribution draft >> (draft-qiu-serbest-l2vpn-vpls-mcast-ldp) >> >> As far as specific vendor implementations, I am sure that equipement >> vendors >> can provide you with the relevant information off list. >> >> Cheers, >> Marc >> >> ----- Original Message ----- From: "Jambi Ganbar" >> To: >> Sent: Tuesday, November 15, 2005 11:54 AM >> Subject: pim/igmp snooping >> >> >>> hi all, >>> from reading the ietf64 l2vpn wg minutes seems that there is a lot >>> of changes to the various multicast related drafts in the working group. >>> has any vendors implemented any of the PE snooping proposals? i have >>> seen some announcements from Riverstone on the subject but it seems >>> like a moving target... >>> tia >>> jambi >>> >>> >>> >> >> >> > > From l2vpn-bounces@ietf.org Thu Nov 17 05:04:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecgci-0006uP-LN; Thu, 17 Nov 2005 05:04:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecgcg-0006uK-Sl for l2vpn@megatron.ietf.org; Thu, 17 Nov 2005 05:04:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10755 for ; Thu, 17 Nov 2005 05:03:33 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcguH-0002rI-Cf for l2vpn@ietf.org; Thu, 17 Nov 2005 05:22:19 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 17 Nov 2005 02:03:42 -0800 X-IronPort-AV: i="3.97,340,1125903600"; d="txt'?scan'208,217"; a="676098334:sNHT1886646622" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAHA3es2009241 for ; Thu, 17 Nov 2005 02:03:40 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 02:03:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5EB5E.2F1BD5D5" Date: Thu, 17 Nov 2005 02:03:39 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBCA3BCB@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: yes Thread-Topic: VPLS Multicast Congruency Thread-Index: AcXrXi612b4RFiCcTHyJ4JglV0dulA== From: "Ali Sajassi \(sajassi\)" To: X-OriginalArrivalTime: 17 Nov 2005 10:03:40.0127 (UTC) FILETIME=[2F3346F0:01C5EB5E] X-Spam-Score: 0.8 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 Subject: VPLS Multicast Congruency X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB5E.2F1BD5D5 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5EB5E.2F1BD5D5" ------_=_NextPart_002_01C5EB5E.2F1BD5D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During L2VPN session in the last IETF meeting, I went over some of the issues that may result when unicast and multicast paths are different in VPLS (refer to draft-sajassi-l2vpn-vpls-bridge-interop-02.txt). Here is a draft to address these issues. Please review and give us your comments. =20 Thanks, Ali ------_=_NextPart_002_01C5EB5E.2F1BD5D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
During = L2VPN session=20 in the last IETF meeting, I went over some of the issues that may result = when=20 unicast and multicast paths are different in VPLS (refer to=20 draft-sajassi-l2vpn-vpls-bridge-interop-02.txt). Here is a draft to = address=20 these issues. Please review and give us your = comments.
 
Thanks,
Ali
------_=_NextPart_002_01C5EB5E.2F1BD5D5-- ------_=_NextPart_001_01C5EB5E.2F1BD5D5 Content-Type: text/plain; name="draft-sajassi-l2vpn-vpls-multicast-congruency-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-sajassi-l2vpn-vpls-multicast-congruency-00.txt Content-Disposition: attachment; filename="draft-sajassi-l2vpn-vpls-multicast-congruency-00.txt" Content-Transfer-Encoding: base64 DQoNCiAgIE5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBbGkgU2FqYXNzaSANCiAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcyANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOYWJpbCBC aXRhciANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVmVyaXpvbiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZdWppIEthbWl0ZSANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5UVCBDb21tdW5p Y2F0aW9ucyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgIEV4cGlyZXM6IE1heSAyMDA2ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNSANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICANCiAgICAgICAgICAgICAgQ29uZ3J1ZW5jeSBmb3IgVlBMUyBNdWx0aWNhc3QgYW5kIFVu aWNhc3QgUGF0aHMgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgZHJhZnQtc2FqYXNzaS1sMnZwbi12cGxzLW11bHRpY2FzdC1jb25ncnVlbmN5LTAw LnR4dCANCiAgICANCiAgIFN0YXR1cyBvZiB0aGlzIE1lbW8gDQogICAgDQogICBCeSBzdWJtaXR0 aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkg DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9y IHNoZSBpcyBhd2FyZSANCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFu eSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcyANCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2Vk LCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4gDQogICAgDQogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuIE5vdGUgdGhhdCBvdGhlciANCiAgIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gDQogICAgDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMgDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueSANCiAgIHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0KICAgIA0KICAgVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANCiAgICANCiAgIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQg DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiANCiAgICANCiAgICANCiAgIEFi c3RyYWN0IA0KICAgIA0KICAgVGhlIGN1cnJlbnQgVlBMUyBtdWx0aWNhc3QgcHJvcG9zYWxzIGJh c2VkIG9uIG11bHRpY2FzdCB0cmVlIGhhcyAgDQogICBzZXZlcmFsIGlzc3VlcyB0aGF0IGFyZSBv dXRsaW5lZCBpbiBbQlJJREdFLUlOVEVST1BdLiBUaGVzZSBpc3N1ZXMgDQogICBzdGVtcyBmcm9t IHRoZSBkaXZlcmdlbmNlIG9mIHRoZSBtdWx0aWNhc3QgYW5kIHVuaWNhc3QgcGF0aHMgZm9yIGEg DQogICBnaXZlbiBWUExTIGluc3RhbmNlIGluIHRoZSBNUExTL0lQIG5ldHdvcmsuIFRoaXMgZHJh ZnQgZGVzY3JpYmVzIGEgDQogICBtZWNoYW5pc20gZm9yIGJ1aWxkaW5nIG11bHRpY2FzdCBhbmQg dW5pY2FzdCBwYXRocyB0aGF0IGFyZSBjb25ncnVlbnQgDQogICBpbiBvcmRlciB0byBhZGRyZXNz IHRoZXNlIGlzc3Vlcy4gICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAg ICAgDQogICBTYWphc3NpLCBCaXRhciAmIEthbWl0ZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDFdIA0KICAgIAwNCiAgICANCiAgIGRyYWZ0LXNhamFzc2ktbDJ2cG4t dnBscy1tdWx0aWNhc3QtY29uZ3J1ZW5jeS50eHQgICAgIE5vdmVtYmVyIDIwMDUgDQogICAgDQog ICBUYWJsZSBvZiBDb250ZW50cyANCiAgICANCiAgIDEuIENvbnZlbnRpb25zLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gVGVybWlu b2xvZ3kuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjIgDQogICAzLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMiANCiAgIDQuIE5vbi1jb25ncnVlbmN5IElzc3Vlcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIA0KICAgNS4gTXVsdGljYXN0IFRy ZWUgVHlwZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQog ICA2LiBDb25ncnVlbnQgVW5pY2FzdCBhbmQgTXVsdGljYXN0IFBhdGhzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNSANCiAgIDYuMS4gTXVsdGljYXN0IFBhdGggQWxpZ25tZW50IGFsb25nIHRo ZSBVbmljYXN0IFBhdGguLi4uLi4uLi4uLi4uLi41IA0KICAgNi4yLiBVbmljYXN0IFBhdGggQWxp Z25tZW50IGFsb25nIHRoZSBNdWx0aWNhc3QgUGF0aC4uLi4uLi4uLi4uLi4uLjYgDQogICA3LiBC dWlsZGluZyBNdWx0aWNhc3QgVHJlZXMgYW5kIFVuaWNhc3QgVHVubmVscy4uLi4uLi4uLi4uLi4u Li4uLi4uNyANCiAgIDcuMS4gUElNLWJhc2VkIFRyZWVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi43IA0KICAgNy4yLiBQMk1QIExTUC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICA3LjMuIFAyTVAg VEUgTFNQLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u OCANCiAgIDguIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi44IA0KICAgOS4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAxMC4gTm9ybWF0aXZlIFJl ZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAg IDExLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi45IA0KICAgMTIuIEF1dGhvcnMnIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkgDQogICAxMy4gRnVsbCBDb3B5cmlnaHQgU3Rh dGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCANCiAgIDE0LiBJ bnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjEwIA0KICAgIA0KICAgIA0KICAgMS4gIENvbnZlbnRpb25zIA0KICAgIA0KICAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBO T1QiLCANCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVk IGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uIA0KICAgIA0KICAgMi4gIFRlcm1pbm9sb2d5IA0K ICAgVGhpcyBkb2N1bWVudCB1c2VzIHRlcm1pbm9sb2d5IGRlc2NyaWJlZCBpbiBbTDJWUE4tRlJX S10gYW5kIFtWUExTLQ0KICAgTERQXS4gDQogICAgDQogICAzLiAgSW50cm9kdWN0aW9uIA0KICAg IA0KICAgQXMgc3RhdGVkIGluIFtWUExTLU1DQVNULVJFUV0sIGV4aXN0aW5nIFZQTFMgbWVjaGFu aXNtcyBoYXZlIA0KICAgY2hhbGxlbmdlcyBpbiBoYW5kbGluZyBtdWx0aWNhc3QgdHJhZmZpYyBl ZmZpY2llbnRseS4gIEZvciBzb2x1dGlvbnMgDQogICB0byBpdCwgdGhlcmUgYXJlIHNvbWUgVlBM UyBtdWx0aWNhc3QgcHJvcG9zYWxzIHRvZGF5LCB3aGljaCBmYWxsIGludG8gDQogICB0d28gY2F0 ZWdvcmllczogDQogICAgIGkpIHVzaW5nIGluZ3Jlc3MgcmVwbGljYXRpb24gb3ZlciB1bmljYXN0 IFBXcyANCiAgICAgaWkpIGF2b2lkaW5nIGluZ3Jlc3MgcmVwbGljYXRpb24gYnkgdXNpbmcgbXVs dGljYXN0IHRyZWUgDQogICAgICANCiAgIFRoZSBmb3JtZXIgbWV0aG9kIGd1YXJhbnRlZXMgY29u Z3J1ZW5jeSBiZXR3ZWVuIFZQTFMgdW5pY2FzdCBhbmQgDQogICBtdWx0aWNhc3QgZGF0YSBwYXRo cyBiZWNhdXNlIGJvdGggZGF0YSB0eXBlcyB1c2UgdGhlIHNhbWUgc2V0IG9mIFBXcyANCiAgIChh bmQgdGh1cyBzYW1lIHBhdGhzKSBpbiB0aGUgbmV0d29yayBldmVuIGluIHRoZSBwcmVzZW5jZSBv ZiBFQ01Qcy4gDQogICBIb3dldmVyLCB0aGlzIG1ldGhvZCBtYXkgbm90IGJlIHN1aXRhYmxlIGlu IGFwcGxpY2F0aW9ucyB3aGVyZSB0aGUgDQogICBudW1iZXIgb2YgUEUgcmVjZWl2ZXJzIGluIGEg bXVsdGljYXN0IGdyb3VwIGFyZSBsYXJnZSBvciBmb3IgaGlnaCANCiAgICANCiAgICAgDQogICBT YWphc3NpLCBCaXRhciAmIEthbWl0ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDJdIA0KICAgIAwNCiAgICANCiAgIGRyYWZ0LXNhamFzc2ktbDJ2cG4tdnBscy1tdWx0 aWNhc3QtY29uZ3J1ZW5jeS50eHQgICAgIE5vdmVtYmVyIDIwMDUgDQogICAgDQogICBiYW5kd2lk dGggbXVsdGljYXN0IGFwcGxpY2F0aW9ucyB3aGVyZSBpbmdyZXNzIHJlcGxpY2F0aW9uIG1heSBy ZXN1bHQgDQogICBpbiBleGNlZWRpbmcgcGh5c2ljYWwgcG9ydCBiYW5kd2lkdGggb24gdGhlIFBF IGZhY2luZyB0aGUgY29yZSwgZm9yIA0KICAgaW5zdGFuY2UuIA0KICAgIA0KICAgVGhlIGxhdGVy IG1ldGhvZCBoYW5kbGVzIFZQTFMgbXVsdGljYXN0IGRhdGEgZWZmaWNpZW50bHkuIEl0IHJlc3Vs dHMgDQogICBpbiBmb3J3YXJkaW5nIHRoZSBWUExTIG11bHRpY2FzdCB0cmFmZmljIGluIHRoZSBi YWNrYm9uZSBzdWNoIHRoYXQgbm8gDQogICBtb3JlIHRoYW4gb25lIGNvcHkgb2YgdGhlIHBhY2tl dCBldmVyIHRyYXZlcnNlcyBhbnkgbGluay4gSXQgYWxzbyANCiAgIG1haW50YWlucyBzaG9ydGVz dCBwYXRocyAobGVhc3QgY29zdCBwYXRocykgYmV0d2VlbiB0aGUgcmVjZWl2ZXIgUEVzIA0KICAg YW5kIHRoZSBzb3VyY2UgUEUuIEhvd2V2ZXIsIHRoZSBWUExTIG11bHRpY2FzdCBhbmQgdW5pY2Fz dCBwYXRocyBjYW4gDQogICBkaXZlcmdlIGluIHRoaXMgbWV0aG9kIGZvciBzZXZlcmFsIHJlYXNv bnMuIEZvciBleGFtcGxlLCBpbiB0aGUgY2FzZSANCiAgIG9mIGFuIElQIG5ldHdvcmssIHRoZSBt dWx0aWNhc3QgdHJlZSAodXNpbmcgUElNIHByb2NlZHVyZXMpIGlzIGJ1aWx0IA0KICAgZnJvbSB0 aGUgcmVjZWl2ZXIgUEVzIHRvIHRoZSBzb3VyY2U7IHdoZXJlYXMsIHRoZSB1bmljYXN0IHRyYWZm aWMgaXMgDQogICByb3V0ZWQgZnJvbSB0aGUgc291cmNlIHRvIHRoZSByZWNlaXZlciBQRS4gRXZl biBpbiB0aGUgYWJzZW5jZSBvZiANCiAgIEVDTVAsIHRoZSB1bmljYXN0IGFuZCBtdWx0aWNhc3Qg dHJhZmZpYyBjYW4gdGFrZSBkaWZmZXJlbnQgcGF0aHMgDQogICBiZWNhdXNlIG9mIGFzeW1tZXRy aWNhbCBwYXRoIGNvc3QuIEluIGNhc2Ugb2YgTVBMUyBuZXR3b3JrIHdoZXJlIHRoZSANCiAgIG11 bHRpY2FzdCB0cmVlIGlzIGJ1aWx0IHVzaW5nIFtQMk1QLUxEUF0sIHRoZSBtdWx0aWNhc3QgYW5k IHVuaWNhc3QgDQogICBwYXRocyBjYW4gYmUgZGlmZmVyZW50IGJlY2F1c2Ugb2YgYXN5bW1ldHJp Y2FsIHBhdGggY29zdCBvciBiZWNhdXNlIA0KICAgb2YgRUNNUC4gRXZlbiB3aGVuIHRoZSBwYXRo IGNvc3QgaXMgc3ltbWV0cmljYWwsIHRoZSBFQ01QIGZvciANCiAgIGJ1aWxkaW5nIFAyTVAgTFNQ IHR1bm5lbCAodXNlZCBieSBtdWx0aWNhc3QgdHJhZmZpYykgaXMgcGVyZm9ybWVkIA0KICAgZnJv bSB0aGUgcmVjZWl2ZXIgUEUgdG93YXJkIHRoZSBzb3VyY2UgUEU7IHdoZXJlYXMsIGZvciB1bmlj YXN0IA0KICAgdHJhZmZpYywgdGhlIEVDTVAgaXMgcGVyZm9ybWVkIGluIHRoZSBvcHBvc2l0ZSBk aXJlY3Rpb24gZnJvbSB0aGUgDQogICBzb3VyY2UgUEUgdG93YXJkIHRoZSByZWNlaXZlciBQRS4g IA0KICAgIA0KICAgVGhlIG5leHQgc2VjdGlvbiByZXZpZXdzIHRoZSBpc3N1ZXMgYXNzb2NpYXRl ZCB3aXRoIG5vbi1jb25ncnVlbnQgDQogICBtdWx0aWNhc3QgYW5kIHVuaWNhc3QgcGF0aHMgZm9y IFZQTFMgYXBwbGljYXRpb25zIGFuZCBzZWN0aW9uIDUgDQogICBkaXNjdXNzZXMgdGhlIHByb3Bv c2FsIHRvIGFjaGlldmUgY29uZ3J1ZW5jeSBmb3IgdW5pY2FzdCBwYXRocyBhbmQgDQogICBtdWx0 aWNhc3QgdHJlZXMgaW4gYSBWUExTIG5ldHdvcmsuIA0KICAgIA0KICAgIA0KICAgNC4gIE5vbi1j b25ncnVlbmN5IElzc3VlcyANCiAgICANCiAgIElzc3VlcyByZXN1bHRpbmcgZnJvbSBub24tY29u Z3J1ZW50IHVuaWNhc3QgYW5kIG11bHRpY2FzdCBwYXRocyBoYXZlIA0KICAgYmVlbiBkZXNjcmli ZWQgaW4gW2JyaWRnZS1pbnRlcm9wXSBhbmQgYXJlIHJldmlld2VkIGluIHRoaXMgc2VjdGlvbi4g DQogICBCZWZvcmUgZ29pbmcgb3ZlciB0aGVzZSBpc3N1ZXMsIGl0IHNob3VsZCBiZSBub3RlZCB0 aGF0IGEgVlBMUyANCiAgIGluc3RhbmNlIGFzIGRlc2NyaWJlZCBpbiBbVlBMUy1MRFBdIGFuZCBb VlBMUy1pbnRlcm9wXSBjYW4gcHJvdmlkZSBhIA0KICAgTEFOIGVtdWxhdGlvbiBzZXJ2aWNlIG5v dCBvbmx5IGFtb25nIHNpdGVzIG9mIGEgZ2l2ZW4gZW50ZXJwcmlzZSANCiAgIGN1c3RvbWVyIGJ1 dCBhbHNvIGl0IGNhbiBwcm92aWRlIHN1Y2ggc2VydmljZSBhbW9uZyB0aGUgc2VydmljZSANCiAg IHByb3ZpZGVyIGJyaWRnZWQgTEFOIG5ldHdvcmtzIChlLmcuLCA4MDIuMWFkIG9yIDgwMi4xYWgg bmV0d29ya3MpLiANCiAgIFRoZXJlZm9yZSwgdGhlIGZvbGxvd2luZyBpc3N1ZXMgd2lsbCBoYXZl IGEgbW9yZSBwcm9ub3VuY2VkIGVmZmVjdCBpbiANCiAgIHRoZSBsYXR0ZXIgY2FzZSB0aGFuIHRo ZSBmb3JtZXIgb25lIGJlY2F1c2UgYSBwcm9ibGVtIGluIHNlcnZpY2UgDQogICBwcm92aWRlciBi cmlkZ2VkIExBTiBuZXR3b3JrIGNhbiBpbXBhY3QgbWFueSBlbmQtY3VzdG9tZXJzLiAgDQogICAg DQogICAgIGkpIExvb3BzIGFuZCBCbGFjay1ob2xpbmc6IElmIFZQTFMgaXMgdXNlZCB0byBjb25u ZWN0IGN1c3RvbWVyIG9yIA0KICAgICAgICBwcm92aWRlciBicmlkZ2VzLCB0aGVuIHRoZXJlIGFy ZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHNlbmRpbmcgDQogICAgICAgIEJQRFUgZnJhbWVzIG92ZXIg VlBMUyB3aXRoIG11bHRpY2FzdCB0cmVlOiBhKSBvdmVyIHVuaWNhc3QgUFdzIA0KICAgICAgICBv ciBiKSBvdmVyIG11bHRpY2FzdCB0cmVlLiBSZWdhcmRsZXNzIG9mIHdoaWNoIGFsdGVybmF0aXZl IGlzIA0KICAgICAgICB1c2VkLCBhIGZhaWx1cmUgYWxvbmcgdGhlIG5vbi1CUERVIHBhdGggKHdo aWNoIGlzIGRpZmZlcmVudCBmcm9tIA0KICAgICAgICBCUERVIHBhdGgpIHdpbGwgcmVzdWx0IGlu IGJsYWNrIGhvbGluZyBvZiB0aGUgdHJhZmZpYyBvbiB0aGUgDQogICAgICAgIG5vbi1CUERVIHBh dGggc2luY2UgaXQgd29uknQgYmUgZGV0ZWN0ZWQgYnkgdGhlIENFIGJyaWRnZXMuIA0KICAgIA0K ICAgICANCiAgIFNhamFzc2ksIEJpdGFyICYgS2FtaXRlICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgDA0KICAgIA0KICAgZHJhZnQtc2FqYXNzaS1sMnZw bi12cGxzLW11bHRpY2FzdC1jb25ncnVlbmN5LnR4dCAgICAgTm92ZW1iZXIgMjAwNSANCiAgICAN CiAgICAgICAgRnVydGhlcm1vcmUsIGEgZmFpbHVyZSBhbG9uZyB0aGUgQlBEVSBwYXRoICh3aGlj aCBpcyBkaWZmZXJlbnQgDQogICAgICAgIGZyb20gbm9uLUJQRFUgcGF0aCkgd2lsbCByZXN1bHQg aW4gbG9vcCB3aXRoaW4gdGhlIGN1c3RvbWVyIA0KICAgICAgICBuZXR3b3JrIGJlY2F1c2UgdGhl IENFIEJyaWRnZSB3aWxsIHB1dCBpdHMgYmxvY2tlZCBwb3J0IGludG8gdGhlIA0KICAgICAgICBm b3J3YXJkaW5nIHN0YXRlIGFuZCB0aHVzIGNhdXNpbmcgbG9vcCB3aXRoaW4gaXRzIGJyaWRnZWQg DQogICAgICAgIG5ldHdvcmsgKGFuZCB0aHJvdWdoIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdv cmspLiANCiAgICAgIA0KICAgICBpaSkgT3V0IG9mIG9yZGVyIGRlbGl2ZXJ5OiBJZiB1bmtub3du IHVuaWNhc3QgZnJhbWVzIGFyZSBmbG9vZGVkIA0KICAgICAgICBvdmVyIG11bHRpY2FzdCB0cmVl LCB0aGVuIGl0IG1heSByZXN1bHQgaW4gYW4gb3V0LW9mLW9yZGVyIGZyYW1lIA0KICAgICAgICBk ZWxpdmVyeSBhdCB0aGUgcmVjZWl2aW5nIFBFIGJlY2F1c2UgdGhlIG11bHRpY2FzdCBhbmQgdW5p Y2FzdCANCiAgICAgICAgcGF0aHMgY2FuIGJlIGRpZmZlcmVudCBhbmQgdGh1cyB0d28gY29uc2Vj dXRpdmUgZnJhbWVzIGF0IHRoZSANCiAgICAgICAgaW5ncmVzcyBQRSBjYW4gdGFrZSB0d28gZGlm ZmVyZW50IHBhdGhzIHRocm91Z2ggdGhlIFZQTFMgbmV0d29yayANCiAgICAgICAgYW5kIHRoZSBz ZWNvbmQgZnJhbWUgdGhhdCB0YWtlcyB0aGUgdW5pY2FzdCBwYXRoIG1heSBhcnJpdmUgDQogICAg ICAgIGFoZWFkIG9mIHRoZSBmaXJzdCBmcmFtZSB0aGF0IHRha2VzIHRoZSBtdWx0aWNhc3QgcGF0 aC4gDQogICAgICANCiAgICAgaWlpKSBDRk0gcHJvY2VkdXJlczogSUVFRSA4MDIuMWFnIGRlc2Ny aWJlcyBmYXVsdCBtYW5hZ2VtZW50IA0KICAgICAgICBwcm9jZWR1cmVzIGZvciBjdXN0b21lciBh bmQgcHJvdmlkZXIgYnJpZGdlZCBuZXR3b3Jrcy4gSW4gYSANCiAgICAgICAgdHlwaWNhbCBicmlk Z2VkIG5ldHdvcmssIHRoZSB1bmljYXN0IGFuZCBtdWx0aWNhc3QgcGF0aHMgYXJlIHRoZSANCiAg ICAgICAgc2FtZSBhbmQgdGh1cyB3aGVuIHRoZXJlIGlzIGEgZmFpbHVyZSBhbG9uZyB0aGUgZGF0 YSBwYXRoIA0KICAgICAgICAoZWl0aGVyIHVuaWNhc3Qgb3IgbXVsdGljYXN0KSBmb3IgYSBnaXZl biBzZXJ2aWNlIGluc3RhbmNlLCBpdCANCiAgICAgICAgd2lsbCBiZSBkZXRlY3RlZCBieSBDRk0g Q29ubmVjdGl2aXR5IENoZWNrIHByb2NlZHVyZXMuIEhvd2V2ZXIsIA0KICAgICAgICB3aGVuIHRo ZSB1bmljYXN0IGFuZCBtdWx0aWNhc3QgcGF0aHMgYXJlIGRpZmZlcmVudCBpbiB0aGUgVlBMUyAN CiAgICAgICAgbmV0d29yaywgdGhlbiByZWdhcmRsZXNzIHdoaWNoIHBhdGggaXMgY2hvc2VuIGJ5 IHRoZSBDRk0gDQogICAgICAgIENvbm5lY3Rpdml0eSBDaGVjayBwcm9jZWR1cmUsIHRoZSBvdGhl ciBvbmUgaXMgbm90IGNvdmVyZWQgYW5kIA0KICAgICAgICB0aHVzIGEgZmFpbHVyZSBvbiB0aGF0 IHBhdGggY2Fubm90IGJlIGRldGVjdGVkIGJ5IHRoZSBDRk0gQ0MgDQogICAgICAgIHByb2NlZHVy ZS4gDQogDQogICAgDQogICA1LiAgTXVsdGljYXN0IFRyZWUgVHlwZXMgDQogICAgDQogICBbTDNW UE4tTUNBU1RdIGRlZmluZXMgdGhlIGZvbGxvd2luZyBtdWx0aWNhc3QgdHJlZSB0eXBlcyB0aGF0 IGFyZSANCiAgIGFsc28gbGV2ZXJhZ2VkIGJ5IFtWUExTLU1DQVNUXTogDQogICAgDQogICAgIGkp IEluY2x1c2l2ZSBUcmVlOiBBIHRyZWUgdGhhdCBjYXJyaWVzIGFsbCB0aGUgbXVsdGljYXN0IHRy YWZmaWMgDQogICAgICAgIGZvciBhIHNpbmdsZSBWUExTIGluc3RhbmNlLiAgDQogICAgIGlpKSBB Z2dyZWdhdGUgSW5jbHVzaXZlIFRyZWU6IEEgdHJlZSB0aGF0IGNhcnJpZXMgYWxsIHRoZSBtdWx0 aWNhc3QgDQogICAgICAgIHRyYWZmaWMgZm9yIHNldmVyYWwgVlBMUyBpbnN0YW5jZXMuICANCiAg ICAgaWlpKSBTZWxlY3RpdmUgVHJlZTogQSB0cmVlIHRoYXQgY2FycmllcyBvbmUgb3IgbW9yZSBt dWx0aWNhc3QgDQogICAgICAgIHN0cmVhbXMgYmVsb25naW5nIHRvIHRoZSBzYW1lIFZQTFMgaW5z dGFuY2UuIA0KICAgICBpdikgQWdncmVnYXRlIFNlbGVjdGl2ZSBUcmVlOiBBIHRyZWUgdGhhdCBj YXJyaWVzIHNldmVyYWwgbXVsdGljYXN0IA0KICAgICAgICBzdHJlYW1zIGJlbG9uZ2luZyB0byBz ZXZlcmFsIFZQTFMgaW5zdGFuY2VzLiANCiAgICANCiAgIFRvIHN1cHBvcnQgVlBMUyBtdWx0aWNh c3QgdXNpbmcgTXVsdGljYXN0IFRyZWUsIHRoZSBmb2xsb3dpbmcgDQogICBjb21wb25lbnRzIGFy ZSByZXF1aXJlZC4gIA0KICAgIA0KICAgICAuIElHTVAvUElNIHNub29waW5nIG92ZXIgQXR0YWNo bWVudCBDaXJjdWl0cyANCiAgICANCiAgICAgDQogICBTYWphc3NpLCBCaXRhciAmIEthbWl0ZSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdIA0KICAgIAwNCiAgICAN CiAgIGRyYWZ0LXNhamFzc2ktbDJ2cG4tdnBscy1tdWx0aWNhc3QtY29uZ3J1ZW5jeS50eHQgICAg IE5vdmVtYmVyIDIwMDUgDQogICAgDQogICAgIC4gRGlzY292ZXJ5ICYgZGlzdHJpYnV0aW9uIG9m IGdyb3VwIG1lbWJlcnNoaXAgaW5mbyANCiAgICAgLiBDb25zdHJ1Y3Rpb24gb2YgbXVsdGljYXN0 IHRyZWUgDQogICAgDQogICBJR01QL1BJTSBzbm9vcGluZyBvdmVyIEF0dGFjaG1lbnQgQ2lyY3Vp dHMgYXJlIG9ubHkgbmVlZGVkIGZvciANCiAgIChBZ2dyZWdhdGUpIFNlbGVjdGl2ZSBUcmVlLiBE aXNjb3ZlcnkgYW5kIGRpc3RyaWJ1dGlvbiBvZiBncm91cCANCiAgIG1lbWJlcnNoaXAgaW5mbyBp cyByZXF1aXJlZCBmb3IgYW55IG9mIHRoZSBhYm92ZSB0cmVlIHR5cGVzIGFuZCB0aGVyZSANCiAg IGFyZSBzZXZlcmFsIGRpZmZlcmVudCBzY2hlbWVzIGZvciBwZXJmb3JtaW5nIHRoaXMgdGFzay4g T25jZSB0aGUgDQogICBzb3VyY2UgYW5kIHJlY2VpdmVyIFBFcyBhcmUgZGlzY292ZXJlZCwgdGhl biB0aGUgdHJlZSBjYW4gYmUgDQogICBjb25zdHJ1Y3RlZCB1c2luZyB0cmFuc3BvcnQgZGVwZW5k ZW50IHNpZ25hbGluZyBtZWNoYW5pc20gKGUuZy4sIFBJTSANCiAgIGZvciBJUCB0cmFuc3BvcnQs IG1MRFAgZm9yIE1QTFMgTFNQLCBhbmQgUlNWUC1URSBmb3IgVEUgTFNQKS4gDQogICAgDQogICBU aGlzIGRyYWZ0IG9ubHkgY29uY2VudHJhdGVzIG9uIHRoZSBsYXN0IGNvbXBvbmVudCCWIG5hbWVs eSANCiAgIGNvbnN0cnVjdGluZyBtdWx0aWNhc3QgdHJlZSB3aXRoIGNvbmdydWVuY3kgd2l0aCB1 bmljYXN0IHBhdGggYW5kIGl0IA0KICAgYXNzdW1lcyB0aGF0IGdyb3VwIG1lbWJlcnNoaXAgaW5m b3JtYXRpb24gaGF2ZSBhbHJlYWR5IGJlZW4gDQogICBkaXNjb3ZlcmVkLiBGdXJ0aGVybW9yZSwg dGhpcyBkcmFmdCBhc3N1bWVzIHRoYXQgc291cmNlIHNwZWNpZmljIA0KICAgbXVsdGljYXN0IHRy ZWUgaXMgdXNlZCBmb3IgdGhlIGFib3ZlIHRyZWUgdHlwZXMgYW5kIHRoZSBhcHBsaWNhdGlvbiAN CiAgIG9mIHNoYXJlZCB0cmVlIGlzIGZvciBmdXR1cmUgc3R1ZHkuIA0KICAgIA0KICAgVGhlIGNv bmdydWVuY3kgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCBhcmUgaW5kZXBlbmRl bnQgDQogICBmcm9tIHRoZSB0cmVlIHR5cGUgYW5kIHRoZXkgYXJlIGVxdWFsbHkgYXBwbGljYWJs ZSB0byBlYWNoIG9mIHRoZSANCiAgIGFib3ZlIHRyZWUgdHlwZXMuIEFzIG5vdGVkIGluIFtMM1ZQ Ti1NQ0FTVF0sIHRoZSBhYm92ZSB0cmVlIHR5cGVzIGFyZSANCiAgIGFsc28gaW5kZXBlbmRlbnQg ZnJvbSB0aGUgdHJhbnNwb3J0IHR5cGUgliBlLmcuLCBlYWNoIG9mIHRoZSBhYm92ZSANCiAgIHRy ZWUgdHlwZXMgY2FuIGJlIGJ1aWx0IHVzaW5nIGFueSBvZiB0aGUgdHJhbnNwb3J0IHR1bm5lbCBt ZWNoYW5pc21zIA0KICAgKHN1Y2ggYXMgW1BJTV0sIFtQMk1QLVJTVlAtVEVdLCBvciBbUDJNUC1M RFBdKS4gSG93ZXZlciwgdGhlIA0KICAgY29uZ3J1ZW5jeSBwcm9jZWR1cmVzLCBhcyB3aWxsIGJl IHNlZW4sIGFyZSBkZXBlbmRlbnQgb24gdHJhbnNwb3J0IA0KICAgdHVubmVsIG1lY2hhbmlzbXMu IA0KICAgIA0KICAgIA0KICAgNi4gIENvbmdydWVudCBVbmljYXN0IGFuZCBNdWx0aWNhc3QgUGF0 aHMgDQogICAgDQogICBJbiBnZW5lcmFsLCB0aGVyZSBhcmUgdHdvIGdlbmVyYWwgYXBwcm9hY2hl cyBmb3IgaGF2aW5nIGNvbmdydWVudCANCiAgIG11bHRpY2FzdCBhbmQgdW5pY2FzdCBwYXRocyBh cyBmb2xsb3c6IA0KICAgIA0KICAgICBpKSBBbGlnbiB0aGUgbXVsdGljYXN0IHBhdGggYWxvbmcg dGhlIHVuaWNhc3QgcGF0aCANCiAgICAgaWkpIEFsaWduIHRoZSB1bmljYXN0IHBhdGggYWxvbmcg dGhlIG11bHRpY2FzdCBwYXRoIA0KICAgICAgDQogICA2LjEuICBNdWx0aWNhc3QgUGF0aCBBbGln bm1lbnQgYWxvbmcgdGhlIFVuaWNhc3QgUGF0aCANCiAgICANCiAgIEluIHRoaXMgYXBwcm9hY2gs IHRoZSBtdWx0aWNhc3QgdHJlZSBpcyBidWlsdCBhbG9uZyB0aGUgdW5pY2FzdCBwYXRoIA0KICAg YW5kIHRoZXJlIGFyZSB0d28gZGlmZmVyZW50IHdheXMgb2YgYWNoaWV2aW5nIGl0LCBjb25zaWRl cmluZyB0aGF0IA0KICAgdGhlIHVuaWNhc3QgcGF0aCBpcyBlc3RhYmxpc2hlZCBmcm9tIHRoZSBz b3VyY2UgdG93YXJkIHRoZSByZWNlaXZlcjogDQogICBhKSBidWlsZCBhIG11bHRpY2FzdCB0cmVl IGZyb20gdGhlIHNvdXJjZSB0b3dhcmQgdGhlIHJlY2VpdmVycyBhbmQgYikgDQogICBwZXJmb3Jt IHRoZSB0cmFjZSByb3V0ZSBvZiB1bmljYXN0IHBhdGggdG8gaWRlbnRpZnkgdGhlIG5vZGVzIGFs b25nIA0KICAgdGhlIHVuaWNhc3QgcGF0aCAoZXZlbiBpbiB0aGUgcHJlc2VuY2Ugb2YgRUNNUCkg YW5kIHRoZW4gYnVpbGQgYSANCiAgIHJlY2VpdmVyIGluaXRpYXRlZCBtdWx0aWNhc3QgdHJlZSBm cm9tIHRoZSByZWNlaXZlciBQRXMgdG93YXJkIHRoZSANCiAgIHNvdXJjZSB1c2luZyB1bmljYXN0 IHRyYWNlIHJvdXRlIGluZm8uIA0KICAgIA0KICAgTWV0aG9kIChhKSB3b3VsZCByZXF1aXJlIHN1 YnN0YW50aWFsIGNoYW5nZXMgdG8gW1BJTV0gcHJvY2VkdXJlcyBmb3IgDQogICBidWlsZGluZyBt dWx0aWNhc3QgdHJlZXMgYW5kIGV2ZW4gaWYgdGhlc2UgY2hhbmdlcyB3ZXJlIGZlYXNpYmxlLCBp dCANCiAgICANCiAgICAgDQogICBTYWphc3NpLCBCaXRhciAmIEthbWl0ZSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdIA0KICAgIAwNCiAgICANCiAgIGRyYWZ0LXNh amFzc2ktbDJ2cG4tdnBscy1tdWx0aWNhc3QtY29uZ3J1ZW5jeS50eHQgICAgIE5vdmVtYmVyIDIw MDUgDQogICAgDQogICB3b3VsZCBub3QgcmVuZGVyIGFuIG9wdGltdW0gdHJlZSBiZWNhdXNlIGRp ZmZlcmVudCB0cmVlIGJyYW5jaGVzIA0KICAgdG93YXJkIHRoZSByZWNlaXZlcnMgd291bGQgaGF2 ZSBvcmlnaW5hdGVkIGVhcmx5IGZyb20gdGhlIHJvb3QgKGUuZy4sIA0KICAgcGFja2V0IHJlcGxp Y2F0aW9uIHdvdWxkIGhhdmUgb2NjdXJyZWQgc29vbmVyIGFuZCBjbG9zZXIgdG8gdGhlIHJvb3Qg DQogICB0aGFuIG90aGVyd2lzZSB3b3VsZCBoYXZlIG9jY3VycmVkIGlmIHRoZSB0cmVlIHdhcyBi dWlsdCBmcm9tIHRoZSANCiAgIHJlY2VpdmVyIHRvd2FyZCB0aGUgcm9vdCkuIFRoZXJlZm9yZSwg dGhlIG1ldGhvZCAoYSkgaXMgbm90IA0KICAgY29uc2lkZXJlZCBmdXJ0aGVyIGV4Y2VwdCB3aGVu IFJTVlAtVEUgaXMgdXNlZCBmb3Igc2V0dGluZyB1cCBib3RoIA0KICAgUDJNUCBhbmQgUDJQIExT UHMuIA0KICAgIA0KICAgTWV0aG9kIChiKSB3b3VsZCByZXF1aXJlIChzb2Z0d2FyZSkgY2hhbmdl cyB0byBvbmx5IHRoZSBQSU0gcHJvdG9jb2wgDQogICBpbiBvcmRlciB0byBpbmNvcnBvcmF0ZSB0 cmFjZSByb3V0ZSBpbmZvIGludG8gdGhlIFBJTSBqb2luIHJlcXVlc3QgDQogICBzdWNoIHRoYXQg dGhlIGpvaW4gY2FuIGZvbGxvdyBleGFjdGx5IHRoZSBzYW1lIHJvdXRlIGFzIHRoZSB1bmljYXN0 IA0KICAgcm91dGUuIEhvd2V2ZXIsIGl0IHdvdWxkIGFmZmVjdCB0aGUgcmUtY29uc3RydWN0aW9u IG9mIHRoZSBtdWx0aWNhc3QgDQogICB0cmVlIHVwb24gYSBuZXR3b3JrIGZhaWx1cmUgYmVjYXVz ZSBiZXNpZGVzIElHUCBjb252ZXJnZW5jZSwgbWV0aG9kIA0KICAgKGIpIHdvdWxkIHJlcXVpcmUg dGhlIHVuaWNhc3QgcGF0aHMgdGhyb3VnaCB0aGUgbmV0d29yayB0byBiZSByZS0NCiAgIHRyYWNl ZCBiZWZvcmUgcmUtY29uc3RydWN0aW5nIHRoZSBtdWx0aWNhc3QgdHJlZS4gQmVjYXVzZSBvZiB0 aGUgDQogICBkZWxheSBhc3NvY2lhdGVkIHdpdGggcmUtdHJhY2luZyBhbmQgcmUtY29uc3RydWN0 aW5nIHRoZSBtdWx0aWNhc3QgDQogICB0cmVlLCB0aGUgbWV0aG9kIChiKSBpcyBmb3IgZnV0dXJl IHN0dWR5LiANCiAgICANCiAgICANCiAgIDYuMi4gIFVuaWNhc3QgUGF0aCBBbGlnbm1lbnQgYWxv bmcgdGhlIE11bHRpY2FzdCBQYXRoIA0KICAgIA0KICAgSW4gdGhpcyBhcHByb2FjaCwgdGhlIHVu aWNhc3QgcGF0aHMgYXJlIGJ1aWx0IGFsb25nIHRoZSBtdWx0aWNhc3QgDQogICB0cmVlLiBUaGlz IGNhbiBiZSBkb25lIGVhc2lseSBieSB1c2luZyB0aGUgc2FtZSBtdWx0aWNhc3QtdHJlZS0NCiAg IGJ1aWxkaW5nIHByb2NlZHVyZXMgZm9yIHNldHRpbmcgdXAgdGhlIHVuaWNhc3QgdHVubmVscyCW IGUuZy4sIGJ1aWxkIA0KICAgYSB1bmljYXN0IHR1bm5lbCBhcyBhIG11bHRpY2FzdCB0cmVlIHdp dGggYSBzaW5nbGUgcm9vdCBhbmQgYSBzaW5nbGUgDQogICByZWNlaXZlci4gU2luY2UgdGhlIHNh bWUgcHJvY2VkdXJlIGlzIHVzZWQgZm9yIGJ1aWxkaW5nIGJvdGggdW5pY2FzdCANCiAgIHR1bm5l bHMgYW5kIG11bHRpY2FzdCB0cmVlLCBjb25ncnVlbmN5IGJldHdlZW4gdGhlIHR3byBjYW4gYmUg DQogICBhY2hpZXZlZCBzaW1wbHkgYnkgdXNpbmcgdGhlIHNhbWUgaWRlbnRpZmllciB3aGVuIEVD TVAgcGF0aHMgYXJlIA0KICAgZW5jb3VudGVyZWQgc28gdGhhdCB0aGUgc2FtZSBwYXRoIHRvd2Fy ZCB0aGUgc291cmNlIGlzIHNlbGVjdGVkIGluIA0KICAgYm90aCBjYXNlcy4gDQogICBUaGVyZSBh cmUgdHdvIHdheXMgZm9yIHVzaW5nIHN1Y2ggaWRlbnRpZmllci4gRmlyc3QsIHRoZSBtdWx0aWNh c3QgDQogICB0cmVlIGNhbiBiZSBidWlsdCBhcyBiZWZvcmUgd2l0aG91dCBhbnkgY2hhbmdlcyB0 byBpdHMgcHJvY2VkdXJlcy4gDQogICBIb3dldmVyLCB3aGVuIGJ1aWxkaW5nIHRoZSB1bmljYXN0 IHR1bm5lbCB1c2luZyBtdWx0aWNhc3QgcHJvY2VkdXJlcywgDQogICB0aGUgbXVsdGljYXN0LXRy ZWUgaWRlbnRpZmllciBpcyBwYXNzZWQgaW4gdGhlIJNqb2lulCBtZXNzYWdlLiBUaGlzIA0KICAg aWRlbnRpZmllciBpcyB0aGVuIHVzZWQgdG8gc2VsZWN0IHRoZSBzYW1lIHBhdGggKGFzIG11bHRp Y2FzdCB0cmVlKSANCiAgIHRvd2FyZCB0aGUgc291cmNlIGluIGNhc2UgRUNNUHMgaXMgZW5jb3Vu dGVyZWQgYWxvbmcgdGhlIHBhdGguIA0KICAgIA0KICAgVGhlIHNlY29uZCB3YXkgZm9yIHVzaW5n IHN1Y2ggaWRlbnRpZmllciBpcyB0byBoYXZlIGFuIGlkZW50aWZpZXIgDQogICB0aGF0IGlzIHVz ZWQgZm9yIEVDTVAgcGF0aCBzZWxlY3Rpb24gZm9yIGJvdGggbXVsdGljYXN0IHRyZWUgYW5kIA0K ICAgdW5pY2FzdCB0dW5uZWxzLiBUaGUgcmVjZWl2ZXIgaW5pdGlhdGVkIJNqb2lulCBtZXNzYWdl IGZyb20gZWdyZXNzIFBFIA0KICAgKGZvciBib3RoIG11bHRpY2FzdCBhbmQgdW5pY2FzdCB0cmVl cyBvZiBhIGdpdmVuIFZQTFMgaW5zdGFuY2UpIA0KICAgY29udGFpbnMgdGhlIHNhbWUgaWRlbnRp Zmllci4gR2l2ZW4gdGhhdCB0aGUgc2FtZSBpZGVudGlmaWVyIGlzIHVzZWQsIA0KICAgdGhlIHNh bWUgcGF0aCBpcyBzZWxlY3RlZCBmb3IgYm90aCBtdWx0aWNhc3QgYW5kIHVuaWNhc3QgdHJlZXMg d2hlbiANCiAgIEVDTVAgaXMgZW5jb3VudGVyZWQuIFRoZSBhZHZhbnRhZ2Ugb2YgdGhpcyBpZGVu dGlmaWVyIGlzIHRoYXQgaXQgDQogICBhbGxvd3MgdGhlIGRlY291cGxpbmcgb2YgbXVsdGljYXN0 IGFuZCB1bmljYXN0IHRyZWVzIGZyb20gb25lIGFub3RoZXIgDQogICBzdWNoIHRoYXQgYW55IG51 bWJlciBvZiBtdWx0aWNhc3QgdHJlZXMgY2FuIGJlIGFsaWduZWQgd2l0aCBhbnkgDQogICBudW1i ZXIgb2YgdW5pY2FzdCB0dW5uZWxzIGJhc2VkIG9uIHRoZSB1c2Ugb2YgdGhpcyBjb21tb24gaWRl bnRpZmllci4gDQogICBUaGVyZWZvcmUsIHRoZSBhcHBsaWNhdGlvbiBvZiBzdWNoIGlkZW50aWZp ZXIgaXMgcmVjb21tZW5kZWQgYW5kIGluIA0KICAgdGhlIHN1YnNlcXVlbnQgZGlzY3Vzc2lvbnMs IGl0IGlzIGFzc3VtZWQgdGhhdCB0aGlzIG1ldGhvZCBpcyB1c2VkIA0KICAgdW5sZXNzIHN0YXRl ZCBvdGhlcndpc2UuICANCiAgICANCiAgICANCiAgICAgDQogICBTYWphc3NpLCBCaXRhciAmIEth bWl0ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdIA0KICAgIAwN CiAgICANCiAgIGRyYWZ0LXNhamFzc2ktbDJ2cG4tdnBscy1tdWx0aWNhc3QtY29uZ3J1ZW5jeS50 eHQgICAgIE5vdmVtYmVyIDIwMDUgDQogICAgDQogICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0 aGVyZSBpcyBhIGNvc3QgYXNzb2NpYXRlZCBpbiBhY2hpZXZpbmcgDQogICBjb25ncnVlbmN5IGFz IGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBoIGFuZCBpdCBpcyByZWxhdGVkIA0K ICAgdG8gdGhlIG51bWJlciBvZiBtdWx0aWNhc3Qgc3RhdGVzIG5lZWRlZCB0byBiZSBtYWludGFp bmVkIGluIHRoZSBQIA0KICAgbm9kZXMuIFNpbmNlIGVhY2ggdW5pY2FzdCB0dW5uZWwgaXMgcmVw cmVzZW50ZWQgYnkgYSBtdWx0aWNhc3QgdHJlZSwgDQogICB0aGUgbnVtYmVyIG9mIG11bHRpY2Fz dCBzdGF0ZXMgaW4gdGhlIGNvcmUgaW5jcmVhc2VzIHByb3BvcnRpb25hbGx5IA0KICAgdG8gdGhl IG51bWJlciBvZiB1bmljYXN0IHR1bm5lbHMuIEhvd2V2ZXIsIHRoZSBpbmNyZWFzZSBpbiBudW1i ZXIgb2YgDQogICBzdGF0ZXMsIGFzIHRoZSByZXN1bHQgb2YgdW5pY2FzdCB0dW5uZWxzLCBkb2Vz IG5vdCBuZWVkIHRvIGJlIA0KICAgcHJvcG9ydGlvbmFsIHRvIG51bWJlciBvZiBWUExTIGluc3Rh bmNlcyBvciBudW1iZXIgb2YgbXVsdGljYXN0IA0KICAgZ3JvdXBzIGJ1dCBpbnN0ZWFkIGl0IG9u bHkgbmVlZHMgdG8gYmUgcHJvcG9ydGlvbmFsIHRvIHRoZSBudW1iZXIgb2YgDQogICBFQ01QIHBh dGhzIGluIG9yZGVyIHRvIHBlcmZvcm0gcHJvcGVyIGxvYWQgYmFsYW5jaW5nIGluIHRoZSBjb3Jl LiBGb3IgDQogICBleGFtcGxlIGlmIHRoZSBtYXhpbXVtIG51bWJlciBvZiBFQ01QIHBhdGhzIGlu IHRoZSBjb3JlIG5ldHdvcmsgDQogICBiZXR3ZWVuIGFueSBwYWlyIG9mIFBFcyBhcmUgTiwgdGhl biB0aGUgbWF4aW11bSBudW1iZXIgb2YgdW5pY2FzdCANCiAgIHR1bm5lbHMgbmVlZGVkIChiZXR3 ZWVuIGFueSBwYWlyIG9mIFBFcykgd2lsbCBiZSBOIGFuZCB0aGUgVlBMUyANCiAgIGluc3RhbmNl cyB3aWxsIGJlIGRpc3RyaWJ1dGVkIChlLmcuLCBsb2FkIGJhbGFuY2VkKSBhbW9uZyB0aGVzZSBO IA0KICAgdHVubmVscy4gIA0KICAgIA0KICAgIA0KICAgRm9yIGJvdGggb2YgdGhlc2UgYXBwcm9h Y2hlcyBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb25zLCB0aGUgDQogICBhZHZhbnRh Z2Ugb2YgYWNoaWV2aW5nIHN1Y2ggY29uZ3J1ZW5jeSBmb3IgVlBMUyBtdWx0aWNhc3QgYW5kIHVu aWNhc3QgDQogICBkYXRhIG92ZXIgYW4gTVBMUy9JUCBuZXR3b3JrIGlzIHRoYXQgaXQgcHV0cyB0 aGUgTEFOIGVtdWxhdGlvbiANCiAgIHNlcnZpY2UgaW4gcGFyIHdpdGggdGhlIGJyaWRnZWQgTEFO IHNlcnZpY2UgYW5kIGF0IHRoZSBzYW1lIHRpbWUgaXQgDQogICBwcm92aWRlcyBhbiBlZmZpY2ll bnQgbWVjaGFuaXNtIGZvciBtdWx0aWNhc3QgZGF0YSBoYW5kbGluZy4gV2hlbiB0aGUgDQogICBp bmdyZXNzIFBFIGlzIGFsc28gdGhlIHJvb3Qgb2YgaXRzIG11bHRpY2FzdCB0cmVlLCB0aGVuIG9u ZSBjYW4gDQogICBhY2hpZXZlIHNob3J0ZXN0IHBhdGggKG9yIGxlYXN0IGNvc3QpIGJyaWRnZWQg TEFOIHNlcnZpY2Ugd2hlbiB0aGUgDQogICBWUExTIGluc3RhbmNlIGlzIHN1cHBvcnRlZCB0aGlz IHdheSBiZWNhdXNlIGJvdGggdW5pY2FzdCBhbmQgDQogICBtdWx0aWNhc3QgZGF0YSBmb3IgdGhh dCBWUExTIGluc3RhbmNlIGlzIGZvcndhcmRlZCBhbG9uZyB0aGUgc2hvcnRlc3QgDQogICBwYXRo IGJldHdlZW4gdGhlIFBFcyBhbmQgYXQgdGhlIHNhbWUgdGltZSBoYXZlIGNvbmdydWVuY3kgd2l0 aCBlYWNoIA0KICAgb3RoZXIgdG8gc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzIG9mIGEgYnJpZGdl ZCBMQU4gbmV0d29yay4gDQogICAgDQogICAgDQogICA3LiAgQnVpbGRpbmcgTXVsdGljYXN0IFRy ZWVzIGFuZCBVbmljYXN0IFR1bm5lbHMgIA0KICAgIA0KICAgQXMgbWVudGlvbmVkIHByZXZpb3Vz bHksIHRoZSBwcm9jZWR1cmVzIGZvciBidWlsZGluZyBjb25ncnVlbnQgDQogICB1bmljYXN0IGFu ZCBtdWx0aWNhc3QgcGF0aHMgYXJlIGRlcGVuZGVudCBvbiB0aGUgdHJhbnNwb3J0IG1lY2hhbmlz bS4gDQogICBUaGUgZm9sbG93aW5nIHN1Yi1zZWN0aW9ucyBkZXNjcmliZSB3aGF0IGNoYW5nZXMg dG8gdGhlIGV4aXN0aW5nIA0KICAgcHJvY2VkdXJlcyBhcmUgcmVxdWlyZWQgZm9yIGVhY2ggb2Yg dGhlIGZvbGxvd2luZyB0cmFuc3BvcnQgDQogICBtZWNoYW5pc21zLiAgDQogICAgDQogICAgDQog ICA3LjEuICBQSU0tYmFzZWQgVHJlZXMgDQogICAgDQogICBbUElNXSB1c2VzIHJlY2VpdmVyIGlu aXRpYXRlZCBqb2luIHJlcXVlc3QgZm9yIGJ1aWxkaW5nIGEgdHJlZSBmcm9tIA0KICAgdGhlIHJl Y2VpdmVyIFBFKHMpIHRvd2FyZCB0aGUgc291cmNlIFBFLiBJbiB0aGlzIHNjZW5hcmlvLCB0aGUg c2FtZSANCiAgIHByb2NlZHVyZSBpcyB1c2VkIGZvciBjb25zdHJ1Y3RpbmcgYm90aCBtdWx0aWNh c3QgYW5kIHVuaWNhc3QgdHJlZXMuIA0KICAgVGhlIGpvaW50IHJlcXVlc3QgZm9yIGJvdGggbXVs dGljYXN0IGFuZCB1bmljYXN0IHRyZWUgaXMgbW9kaWZpZWQgdG8gDQogICBpbmNsdWRlIGFuIEVD TVAgaWRlbnRpZmllci4gVGhlIHNhbWUgaWRlbnRpZmllciBpcyB1c2VkIGZvciBib3RoIA0KICAg dW5pY2FzdCBhbmQgbXVsdGljYXN0IHRyZWUgYmVsb25naW5nIHRvIHRoZSBzYW1lIFZQTFMgaW5z dGFuY2UuIFRoaXMgDQogICBpZGVudGlmaWVyIGlzIHVzZWQgdG8gc2VsZWN0IHRoZSBzYW1lIHBh dGggYW1vbmcgbXVsdGlwbGUgZXF1YWwgY29zdCANCiAgIHBhdGhzIHdoZW4gYnVpbGRpbmcgdW5p Y2FzdCBhbmQgbXVsdGljYXN0IHRyZWVzIGluIG9yZGVyIHRvIGFjaGlldmUgDQogICBjb25ncnVl bmN5IGJldHdlZW4gdGhlbS4gVGhlbiBlbmNvZGluZyBvZiB0aGlzIGZpZWxkIHdpbGwgYmUgDQog ICBkZXNjcmliZWQgaW4gdGhlIGZ1dHVyZS4gICANCiAgICANCiAgICAgDQogICBTYWphc3NpLCBC aXRhciAmIEthbWl0ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDdd IA0KICAgIAwNCiAgICANCiAgIGRyYWZ0LXNhamFzc2ktbDJ2cG4tdnBscy1tdWx0aWNhc3QtY29u Z3J1ZW5jeS50eHQgICAgIE5vdmVtYmVyIDIwMDUgDQogICAgDQogICAgDQogICA3LjIuICBQMk1Q IExTUCANCiAgICANCiAgIFNpbWlsYXIgdG8gW1BJTV0gcHJvY2VkdXJlcywgdGhpcyBwcm9jZWR1 cmUgdXNlcyByZWNlaXZlciBpbml0aWF0ZWQgDQogICCTam9pbpQgbWVzc2FnZSBmb3IgYnVpbGRp bmcgYm90aCBhIFAyTVAgTFNQIGFuZCBhIFAyUCBMU1AgZnJvbSB0aGUgDQogICByZWNlaXZlciBQ RShzKSB0b3dhcmQgdGhlIHNvdXJjZSBQRS4gRWFjaCByZWNlaXZlciBQRSCTam9pbnOUIHRoZSAN CiAgIFAyTVAgb3IgUDJQIHRyZWUgYnkgc2VuZGluZyBMRFAgbGFiZWwgbWFwcGluZyBtZXNzYWdl LiBUaGUgbGFiZWwgDQogICBtYXBwaW5nIG1lc3NhZ2UgZm9yIGJvdGggUDJNUCBhbmQgUDJQIHRy ZWUgaXMgbW9kaWZpZWQgdG8gaW5jbHVkZSBhbiANCiAgIEVDTVAgaWRlbnRpZmllci4gVGhlIHNh bWUgaWRlbnRpZmllciBpcyB1c2VkIGZvciBib3RoIFAyTVAgYW5kIFAyUCANCiAgIExTUHMgZm9y IHRoZSBzYW1lIFZQTFMgaW5zdGFuY2UuIFRoaXMgaWRlbnRpZmllciBpcyB1c2VkIHRvIHNlbGVj dCANCiAgIHRoZSBzYW1lIHBhdGggYW1vbmcgbXVsdGlwbGUgZXF1YWwgY29zdCBwYXRocyB3aGVu IGJ1aWxkaW5nIHRoZSANCiAgIHVuaWNhc3QgYW5kIG11bHRpY2FzdCB0cmVlcyBpbiBvcmRlciB0 byBhY2hpZXZlIGNvbmdydWVuY3kgYmV0d2VlbiANCiAgIHRoZW0uIFRoZW4gZW5jb2Rpbmcgb2Yg dGhpcyBmaWVsZCB3aWxsIGJlIGRlc2NyaWJlZCBpbiB0aGUgZnV0dXJlLiANCiAgICAgDQogICAg IA0KICAgNy4zLiAgUDJNUCBURSBMU1AgDQogICBDb250cmFyeSB0byB0aGUgcHJldmlvdXMgdHdv IHByb2NlZHVyZXMsIHRoaXMgcHJvY2VkdXJlIGlzIGluaXRpYXRlZCANCiAgIGZyb20gdGhlIHNv dXJjZSBQRSB0b3dhcmQgdGhlIHJlY2VpdmVyIFBFcy4gU2luY2UgdGhlIG5ldHdvcmsgbm9kZXMg DQogICBhbG9uZyB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBzb3VyY2UgYW5kIHRoZSByZWNlaXZlciBQ RXMgaW4gdGhpcyBzY2hlbWUgDQogICBhcmUgaWRlbnRpZmllZCBhIHByaW9yeSwgYm90aCBtdWx0 aWNhc3QgdHJlZSBhbmQgdW5pY2FzdCB0dW5uZWxzIGNhbiANCiAgIGJlIGVzdGFibGlzaGVkIGFs b25nIHRoZSBzYW1lIHBhdGggdXNpbmcgZXhpc3RpbmcgUDJNUCBhbmQgUDJQIExTUCBURSANCiAg IHByb2NlZHVyZXMuIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgOC4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIA0KICAgIA0KICAgU2VjdXJpdHkgYXNwZWN0cyBvZiB0aGlzIGRyYWZ0IHdp bGwgYmUgZGlzY3Vzc2VkIGF0IGEgbGF0ZXIgcG9pbnQuIA0KICAgIA0KICAgIA0KICAgOS4gIEFj a25vd2xlZGdtZW50cyANCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgRGlubyBG YXJpbmFjY2ksIEpvaG4gWndpZWJlbCwgRGFuaWVsIA0KICAgQWx2YXJleiBmb3IgdGhlaXIgY29t bWVudHMgYW5kIGZlZWRiYWNrcy4gDQogICAgDQogICAgDQogICAxMC4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzIA0KICAgIA0KICAgW1JGQzIxMTldICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv IEluZGljYXRlIFJlcXVpcmVtZW50IA0KICAgTGV2ZWxzLiIsIEJyYWRuZXIsIE1hcmNoIDE5OTcg DQogICAgDQogICBbVlBMUy1MRFBdIExhc3NlcnJlLCBNLiBhbmQgZXQgYWwsICJWaXJ0dWFsIFBy aXZhdGUgTEFOIFNlcnZpY2VzIG92ZXIgDQogICBNUExTIiwgd29yayBpbiBwcm9ncmVzcyANCiAg ICANCiAgIFtQODAyLjFhZ10gSUVFRSBEcmFmdCBQODAyLjFhZy9EMC4xIJNWaXJ0dWFsIEJyaWRn ZSBMb2NhbCBBcmVhIA0KICAgTmV0d29ya3M6IENvbm5lY3Rpdml0eSBGYXVsdCBNYW5hZ2VtZW50 lCwgV29yayBpbiBQcm9ncmVzcywgT2N0b2JlciANCiAgIDIwMDQgDQogICAgDQogICAgDQogICAg DQogICAgDQogICAgIA0KICAgU2FqYXNzaSwgQml0YXIgJiBLYW1pdGUgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSA4XSANCiAgICAMDQogICAgDQogICBkcmFmdC1zYWph c3NpLWwydnBuLXZwbHMtbXVsdGljYXN0LWNvbmdydWVuY3kudHh0ICAgICBOb3ZlbWJlciAyMDA1 IA0KICAgIA0KICAgMTEuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgIA0KICAgWzgwMi4x RC1SRVZdIElFRUUgU3RkLiA4MDIuMUQtMjAwMyCTTWVkaWEgQWNjZXNzIENvbnRyb2wgKE1BQykg DQogICBCcmlkZ2VzlC4gDQogICAgDQogICBbODAyLjFRXSBJRUVFIFN0ZC4gODAyLjFRLTIwMDMg IlZpcnR1YWwgQnJpZGdlZCBMb2NhbCBBcmVhIE5ldHdvcmtzIi4gDQogICAgDQogICBbUDgwMi4x YWRdIElFRUUgRHJhZnQgUDgwMi4xYWQvRDIuNCCTVmlydHVhbCBCcmlkZ2VkIExvY2FsIEFyZWEg DQogICBOZXR3b3JrczogUHJvdmlkZXIgQnJpZGdlc5QsIFdvcmsgaW4gcHJvZ3Jlc3MsIFNlcHRl bWJlciAyMDA0IA0KICAgIA0KICAgW0JSSURHRS1JTlRFUk9QXSBBLiBTYWphc3NpLCBldC4gYWws ICJWUExTIEludGVyb3BlcmFiaWxpdHkgd2l0aCBDRSANCiAgIEJyaWRlcyIsIGRyYWZ0LXNhamFz c2ktbDJ2cG4tdnBscy1icmlkZ2UtaW50ZXJvcC0wMi50eHQsIFdvcmsgaW4gDQogICBwcm9ncmVz cy4gDQogICAgDQogICBbSUdNUC1TTk9PUF0gQ2hyaXN0ZW5zZW4sIE0uIGFuZCBldCBhbCwgk0Nv bnNpZGVyYXRpb25zIGZvciBJR01QIGFuZCANCiAgIE1MRCBTbm9vcGluZyBTd2l0Y2hlc5QsIFdv cmsgaW4gcHJvZ3Jlc3MsIE1heSAyMDA0IA0KICAgIA0KICAgW1AyTVAtUlNWUC1URV0gUi4gQWdn YXJ3YWwsIEQuIFBhcGFkaW1pdHJpb3UsIFMuIFlhc3VrYXdhLCBldC4gYWwsIA0KICAgIkV4dGVu c2lvbnMgdG8gUlNWUC1URSBmb3IgUG9pbnQgdG8gTXVsdGlwb2ludCBURSBMU1BzIiwgZHJhZnQt aWV0Zi0gDQogICBtcGxzLXJzdnAtdGUtcDJtcCwgV29yayBpbiBwcm9ncmVzcy4gDQogICAgDQog ICBbUDJNUC1MRFBdIE1pbmVpLCBJLiwgSS4gV2lqbmFuZHMsIGV0LiBhbCwgIkxhYmVsIERpc3Ry aWJ1dGlvbiANCiAgIFByb3RvY29sIEV4dGVuc2lvbnMgZm9yIFBvaW50LXRvLU11bHRpcG9pbnQg YW5kIE11bHRpcG9pbnQtdG8tDQogICBNdWx0aXBvaW50IExhYmVsIFN3aXRjaGVkIFBhdGhzlCwg ZHJhZnQtbWluZWktd2lqbmFuZHMtbXBscy1sZHAtcDJtcCwgDQogICBXb3JrIGluIHByb2dyZXNz LiANCiAgICANCiAgIFtQSU1dIEVzdHJpbiwgRC4sIEZhcmluYWNjaSwgRC4sIEhlbG15LCBBLiwg VGhhbGVyLCBELiwgRGVlcmluZywgUy4sIA0KICAgSGFuZGxleSwgTS4sIGFuZCBWLiBKYWNvYnNv biwgIlByb3RvY29sIEluZGVwZW5kZW50IE11bHRpY2FzdC1TcGFyc2UgDQogICBNb2RlIChQSU0t U00pOiBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIiwgUkZDIDIzNjIsIEp1bmUgMTk5OC4gDQogICAg DQogICBbVlBMUy1NQ0FTVC1SRVFdIFkuIEthbWl0ZSBldCBhbCwgIlJlcXVpcmVtZW50cyBmb3Ig TXVsdGljYXN0IFN1cHBvcnQgDQogICBpbiBWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZpY2VzIiwg ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLW1jYXN0LXJlcXRzLCANCiAgIFdvcmsgaW4gcHJvZ3Jlc3Mu IA0KICAgIA0KICAgW0wzVlBOLU1DQVNUXSBSb3NlbiwgRS4gYW5kIFIuIEFnZ2Fyd2FsLCAiTXVs dGljYXN0IGluIE1QTFMvQkdQIElQIA0KICAgVlBOcyIsIGRyYWZ0LWlldGYtbDN2cG4tMjU0N2Jp cy1tY2FzdC0wMCwgV29yayBpbiBwcm9ncmVzcy4gDQogICAgDQogICAgDQogICAxMi4gIEF1dGhv cnMnIEFkZHJlc3NlcyANCiAgICANCiAgIEFsaSBTYWphc3NpIA0KICAgQ2lzY28gU3lzdGVtcywg SW5jLiANCiAgIDE3MCBXZXN0IFRhc21hbiBEcml2ZSANCiAgIFNhbiBKb3NlLCBDQSAgOTUxMzQg DQogICBFbWFpbDogc2FqYXNzaUBjaXNjby5jb20gDQogICAgDQogICBOYWJpbCBCaXRhciANCiAg IFZlcml6b24gQ29tbXVuaWNhdGlvbnMgDQogICA0MCBTeWx2YW4gUmQuLCBXYWx0aGFtLCBNQSAw MjQ1MSANCiAgIEVtYWlsOiBuYWJpbC5iaXRhckB2ZXJpem9uLmNvbSANCiAgICANCiAgICANCiAg ICAgDQogICBTYWphc3NpLCBCaXRhciAmIEthbWl0ZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDldIA0KICAgIAwNCiAgICANCiAgIGRyYWZ0LXNhamFzc2ktbDJ2cG4t dnBscy1tdWx0aWNhc3QtY29uZ3J1ZW5jeS50eHQgICAgIE5vdmVtYmVyIDIwMDUgDQogICAgDQog ICAgDQogICBZdWppIEthbWl0ZSANCiAgIE5UVCBDb21tdW5pY2F0aW9ucyBDb3Jwb3JhdGlvbiAN CiAgIFRva3lvIE9wZXJhIENpdHkgVG93ZXIgDQogICAzLTIwLTIgTmlzaGkgU2hpbmp1a3UsIFNo aW5qdWt1LWt1LCANCiAgIFRva3lvIDE2My0xNDIxLCANCiAgIEphcGFuIA0KICAgRW1haWw6IHku a2FtaXRlQG50dC5jb20gDQogICAgDQogICAxMy4gIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudCAN CiAgICANCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiANCiAg ICANCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBh bmQgcmVzdHJpY3Rpb25zIA0KICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBz ZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0 cy4gDQogICAgDQogICCTVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIA0KICAgYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFIENP TlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSANCiAgIFJFUFJFU0VOVFMgT1IgSVMg U1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIA0KICAg SU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywg RVhQUkVTUyBPUiANCiAgIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiANCiAgIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lM TCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCANCiAgIFdBUlJBTlRJRVMg T0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLpQg DQogICAgDQogICAgDQogICAxNC4gIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQgDQog ICAgDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5 IG9yIHNjb3BlIG9mIGFueSANCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3Ro ZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0byANCiAgIHBlcnRhaW4gdG8gdGhlIGlt cGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gDQogICB0 aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3Vj aCByaWdodHMgDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBp dCByZXByZXNlbnQgdGhhdCBpdCBoYXMgDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQg dG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbiANCiAgIG9uIHRoZSBwcm9j ZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUgDQog ICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4gDQogICAgDQogICBDb3BpZXMgb2YgSVBSIGRp c2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueSANCiAgIGFzc3Vy YW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2Yg YW4gDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1p c3Npb24gZm9yIHRoZSB1c2Ugb2YgDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBs ZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcyANCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFp bmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdCANCiAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaXByLiANCiAgICANCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0 ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkgDQogICBjb3B5cmlnaHRzLCBw YXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5IA0KICAg cmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8g aW1wbGVtZW50IA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1h dGlvbiB0byB0aGUgSUVURiBhdCBpZXRmIA0KICAgaXByQGlldGYub3JnLiANCiAgICANCiAgICAg DQogICBTYWphc3NpLCBCaXRhciAmIEthbWl0ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMTBdIA0KICAgIAw= ------_=_NextPart_001_01C5EB5E.2F1BD5D5-- From l2vpn-bounces@ietf.org Mon Nov 28 15:26:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgpaS-0000P0-FV; Mon, 28 Nov 2005 15:26:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgpaQ-0000Ol-Na for l2vpn@megatron.ietf.org; Mon, 28 Nov 2005 15:26:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00915 for ; Mon, 28 Nov 2005 15:26:10 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgpuK-0005Wq-OG for l2vpn@ietf.org; Mon, 28 Nov 2005 15:47:31 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 66553644B3 for ; Mon, 28 Nov 2005 13:26:33 -0700 (MST) Message-ID: <438B67FD.8070808@castlepoint.net> Date: Mon, 28 Nov 2005 13:26:37 -0700 From: Shane Amante User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, At IETF 64, in Vancouver, there was substantial concerns[1] raised wrt Join Suppression in latest PIM snooping draft[2]. Specfically, the current draft has defined that CE PIM routers MUST disable Join Suppression, in order that receivers will not suppress their own Joins so they can receive multicast traffic through a VPLS instance. The [sole?] advantage of disabling Join Suppression at the CE's is: 1) PE's would remain relatively simple PIM snooping/forwarding devices, allowing a VPLS instance to [continue to] transparently forward all traffic. The disadvantages are: 2) Not all CE's support disabling Join Suppression; 3) It requires on-going coordination between SP's and their customers to disable Join Suppression on CE's, (CE's which may/will not be under the SP's control); and, finally, 4) It inhibits scalability of PIM in a VPLS instance. Since there was little, if any, consensus in Vancouver as to the best direction forward with the PIM snooping work, we would like to hear from the WG: A) Should we require disabling Join Suppression on CE's? B) Should we NOT require disabling Join Suppression on CE's, thereby making the PE a more active element in PIM procedures in a VPLS? C) Other, more palatable, suggestions? Please answer the above questions and feel free to add color commentary as to other issues or concerns not identified above. Thanks, -shane & Vach [1] http://www3.ietf.org/proceedings/05nov/minutes/l2vpn.txt [2] draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt From l2vpn-bounces@ietf.org Mon Nov 28 16:03:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egq9x-0004iw-RE; Mon, 28 Nov 2005 16:03:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egq9v-0004iA-0H for l2vpn@megatron.ietf.org; Mon, 28 Nov 2005 16:03:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07888 for ; Mon, 28 Nov 2005 16:02:49 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgqTp-0007qO-MU for l2vpn@ietf.org; Mon, 28 Nov 2005 16:24:10 -0500 Received: by zproxy.gmail.com with SMTP id 34so2284722nzf for ; Mon, 28 Nov 2005 13:03:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=q7M4EnEeV1BufTts+QhR6/sWvzgx7or3qmeCFev6VWh8Z8aXPxpTiyfV84O+8PsfsKJgeng+xtL8f7I13JIRrXoTqUfgHuRifyVl+hdg4NtpSxW7m5UUuWuIWp7HnPBuoZ0YGVKr/X2xZDxq4/A2rDHJuGxNd8DoH1822WJYJ6Q= Received: by 10.65.160.3 with SMTP id m3mr2397203qbo; Mon, 28 Nov 2005 13:03:24 -0800 (PST) Received: by 10.65.157.7 with HTTP; Mon, 28 Nov 2005 13:03:24 -0800 (PST) Message-ID: Date: Mon, 28 Nov 2005 13:03:24 -0800 From: Ray Qiu To: Shane Amante In-Reply-To: <438B67FD.8070808@castlepoint.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30168_32204772.1133211804732" References: <438B67FD.8070808@castlepoint.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: l2vpn@ietf.org Subject: Re: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org ------=_Part_30168_32204772.1133211804732 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi folks, Thanks to Shane and Vach for initiating a discussion on PIM snooping. I would like to initiate a discussion on the LDP multicast state distribution draft as well, since it is directly related to this topic. Dino pointed out in the meeting that this proposal would require explicit tracking in LDP. As we clarified earlier, LDP is only used as a vehicle to carry the multicast state information. LDP doesn't need to understand any multicast related states, because the PIM snooping component is responsible for handling multicast states. Multicast state distribution between L2VPN PE routers is an important issue to solve. We would like to hear your comments and ideas. Thanks. --Ray On 11/28/05, Shane Amante wrote: > > Folks, > > At IETF 64, in Vancouver, there was substantial concerns[1] raised wrt > Join Suppression in latest PIM snooping draft[2]. Specfically, the > current draft has defined that CE PIM routers MUST disable Join > Suppression, in order that receivers will not suppress their own Joins > so they can receive multicast traffic through a VPLS instance. The > [sole?] advantage of disabling Join Suppression at the CE's is: > 1) PE's would remain relatively simple PIM snooping/forwarding devices, > allowing a VPLS instance to [continue to] transparently forward all > traffic. > > The disadvantages are: > 2) Not all CE's support disabling Join Suppression; > 3) It requires on-going coordination between SP's and their customers to > disable Join Suppression on CE's, (CE's which may/will not be under the > SP's control); and, finally, > 4) It inhibits scalability of PIM in a VPLS instance. > > Since there was little, if any, consensus in Vancouver as to the best > direction forward with the PIM snooping work, we would like to hear from > the WG: > A) Should we require disabling Join Suppression on CE's? > B) Should we NOT require disabling Join Suppression on CE's, thereby > making the PE a more active element in PIM procedures in a VPLS? > C) Other, more palatable, suggestions? > > Please answer the above questions and feel free to add color commentary > as to other issues or concerns not identified above. > > Thanks, > > -shane & Vach > > [1] http://www3.ietf.org/proceedings/05nov/minutes/l2vpn.txt > [2] draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt > > ------=_Part_30168_32204772.1133211804732 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi folks,

Thanks to Shane and Vach for initiating a discussion on PIM snooping. I would like to initiate a discussion on the LDP multicast state distribution draft as well, since it is directly related to this topic.

Dino pointed out in the meeting that this proposal would require explicit tracking in LDP. As we clarified earlier, LDP is only used as a vehicle to carry the multicast state information. LDP doesn't need to understand any multicast related states, because the PIM snooping component is responsible for handling multicast states.

Multicast state distribution between L2VPN PE routers is an important issue to solve. We would like to hear your comments and ideas.

Thanks.

--Ray

On 11/28/05, Shane Amante <shane@castlepoint.net> wrote:
Folks,

At IETF 64, in Vancouver, there was substantial concerns[1] r= aised wrt
Join Suppression in latest PIM snooping draft[2].  S= pecfically, the
current draft has defined that CE PIM routers MUST disab= le Join
Suppression, in order that receivers will not suppress their own Joins<= br>so they can receive multicast traffic through a VPLS instance. &nbs= p;The
[sole?] advantage of disabling Join Suppression at the CE's is:1) PE's would remain relatively simple PIM snooping/forwarding devices,
allowing a VPLS instance to [continue to] transparently forward all tra= ffic.

The disadvantages are:
2) Not all CE's support disabling Jo= in Suppression;
3) It requires on-going coordination between SP's and th= eir customers to
disable Join Suppression on CE's, (CE's which may/will not be under the=
SP's control); and, finally,
4) It inhibits scalability of PIM in a = VPLS instance.

Since there was little, if any, consensus in Vancouve= r as to the best
direction forward with the PIM snooping work, we would like to hear fro= m
the WG:
A) Should we require disabling Join Suppression on CE's?B) Should we NOT require disabling Join Suppression on CE's, thereby
making the PE a more active element in PIM procedures in a VPLS?
C) Othe= r, more palatable, suggestions?

Please answer the above questions an= d feel free to add color commentary
as to other issues or concerns not i= dentified above.

Thanks,

-shane & Vach

[1] http://www3.ietf.org/proceedi= ngs/05nov/minutes/l2vpn.txt
[2] draft-hemige-serbest-l2vpn-vpls-pim-= snooping-00.txt


------=_Part_30168_32204772.1133211804732-- From l2vpn-bounces@ietf.org Mon Nov 28 21:01:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eguns-0002Sw-O8; Mon, 28 Nov 2005 21:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egunq-0002Sr-8M for l2vpn@megatron.ietf.org; Mon, 28 Nov 2005 21:01:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24532 for ; Mon, 28 Nov 2005 21:00:22 -0500 (EST) Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egv7m-0006Qx-4n for l2vpn@ietf.org; Mon, 28 Nov 2005 21:21:45 -0500 Received: from mop1.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id jAT20F76027901; Tue, 29 Nov 2005 11:00:25 +0900 (JST) Received: from mip2.noc.ntt.com (mvi2.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0IQP00GR71KOWD@ntt.com>; Tue, 29 Nov 2005 11:00:25 +0900 (JST) Date: Tue, 29 Nov 2005 11:00:24 +0900 From: "Yuji KAMITE" To: "'Shane Amante'" , l2vpn@ietf.org Message-id: <0IQP009N01KO95@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcX0WlWVOhSi5DEtTum9EJMJm5cepQAKWO1wAAAFirA= X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Subject: RE: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi folks, > Since there was little, if any, consensus in Vancouver as to the best > direction forward with the PIM snooping work, we would like to hear > from the WG: > A) Should we require disabling Join Suppression on CE's? > B) Should we NOT require disabling Join Suppression on CE's, thereby > making the PE a more active element in PIM procedures in a VPLS? > C) Other, more palatable, suggestions? > Currently, the authors of the requirement document have an opinion neutral between (A) and (B) above. As stated in 5.1.2 of draft-ietf-l2vpn-vpls-mcast-reqts-00.txt, A solution MUST NOT require any special packet processing about Layer-3 multicast protocol by the end users. It MAY require some configuration change for minimum necessity though (e.g., turning explicit tracking on/off in PIM). IMHO Ideally, a solution should be capable regardless of whether or not CEs are running suppresion. If it requires some special configuration changes, it cannot be easily used for unspecified majority. However, I also have a concern that (B)'s active PE element possibly requires operational complexity which has not existed so far in the existing VPLS. Thus intermediate between (A) and (B). However, if there should be a serious issue clarified from the solution point of view, I think it can be incorporated into the requirement consideration as well. Regards, -Yuji From l2vpn-bounces@ietf.org Tue Nov 29 13:00:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9mO-0006gU-Hc; Tue, 29 Nov 2005 13:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9mM-0006g6-NS for l2vpn@megatron.ietf.org; Tue, 29 Nov 2005 13:00:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12803 for ; Tue, 29 Nov 2005 12:59:48 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhA6T-0005eK-5a for l2vpn@ietf.org; Tue, 29 Nov 2005 13:21:22 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2005 10:00:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,389,1125903600"; d="scan'208"; a="16171603:sNHT20207940" Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jATI0Lln003077; Tue, 29 Nov 2005 13:00:21 -0500 (EST) Message-Id: <200511291800.jATI0Lln003077@rtp-core-1.cisco.com> To: Shane Amante In-reply-to: Your message of Mon, 28 Nov 2005 13:26:37 -0700. <438B67FD.8070808@castlepoint.net> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Nov 2005 13:00:20 -0500 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: l2vpn@ietf.org Subject: Re: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org > Should we require disabling Join Suppression on CE's? Oh, it's worse than that. We'd also have to prohibit CEs from ever implementing PIM refresh reduction (if such a thing ever comes to be), from ever running PIM over TCP (if such a thing ever comes to be), etc. Well, it's a good thing the customer has bought an L2 service, to which all the L3 protocols are transparent ;-) And remember, it's not just CEs that are "directly" connected to PEs, it's all routers on a LAN which is bridged to a PE. > Should we NOT require disabling Join Suppression on CE's, thereby making > the PE a more active element in PIM procedures in a VPLS? At least the PE would only have to understand the customer's multicast routing, it wouldn't have to understand anything really complicated, like the customer's unicast routing ;-) Maybe we should step back and look at what we're doing here. From l2vpn-bounces@ietf.org Tue Nov 29 23:11:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhJJ8-0006UM-RM; Tue, 29 Nov 2005 23:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhJJ7-0006UG-G0 for l2vpn@megatron.ietf.org; Tue, 29 Nov 2005 23:11:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21030 for ; Tue, 29 Nov 2005 23:10:15 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhJdI-0002BB-Kb for l2vpn@ietf.org; Tue, 29 Nov 2005 23:31:53 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 57A1A64351 for ; Tue, 29 Nov 2005 21:10:22 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Tue, 29 Nov 2005 21:10:26 -0700 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: Call for Volunteers: VPLS/VPWS MIB's X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi folks, According to the L2VPN WG charter, it appears we are almost 2-years behind in getting MIB's (started, let alone) sent to the IESG for VPLS & VPWS: Feb 04 Submit MIB for VPLS to IESG Feb 04 Submit MIB for VPWS to IESG Are there any intrepid volunteers that would like to step up to the task? (The next time we ask, we'll be asking for people to "volunteer" someone, so it could be you anyway! :-) If one or more people can take on the MIB work, could you please e-mail the list or respond to Vach and/or I privately? Thanks! -shane & Vach From l2vpn-bounces@ietf.org Wed Nov 30 09:51:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTJP-0002Uj-Il; Wed, 30 Nov 2005 09:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTJN-0002Ue-Fx for l2vpn@megatron.ietf.org; Wed, 30 Nov 2005 09:51:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25915 for ; Wed, 30 Nov 2005 09:51:12 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhTdf-0005o7-3u for l2vpn@ietf.org; Wed, 30 Nov 2005 10:12:56 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id jAUEpjBm098700; Wed, 30 Nov 2005 06:51:45 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jAUEpj506611; Wed, 30 Nov 2005 06:51:45 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200511301451.jAUEpj506611@merlot.juniper.net> To: Shane Amante In-Reply-To: Your message of "Mon, 28 Nov 2005 13:26:37 MST." <438B67FD.8070808@castlepoint.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41114.1133362305.1@juniper.net> Date: Wed, 30 Nov 2005 06:51:45 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: l2vpn@ietf.org Subject: Re: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, > Folks, > > At IETF 64, in Vancouver, there was substantial concerns[1] raised wrt > Join Suppression in latest PIM snooping draft[2]. Specfically, the > current draft has defined that CE PIM routers MUST disable Join > Suppression, in order that receivers will not suppress their own Joins > so they can receive multicast traffic through a VPLS instance. The > [sole?] advantage of disabling Join Suppression at the CE's is: > 1) PE's would remain relatively simple PIM snooping/forwarding devices, > allowing a VPLS instance to [continue to] transparently forward all traffic. > > The disadvantages are: > 2) Not all CE's support disabling Join Suppression; > 3) It requires on-going coordination between SP's and their customers to > disable Join Suppression on CE's, (CE's which may/will not be under the > SP's control); and, finally, > 4) It inhibits scalability of PIM in a VPLS instance. > > Since there was little, if any, consensus in Vancouver as to the best > direction forward with the PIM snooping work, we would like to hear from > the WG: > A) Should we require disabling Join Suppression on CE's? > B) Should we NOT require disabling Join Suppression on CE's, thereby > making the PE a more active element in PIM procedures in a VPLS? > C) Other, more palatable, suggestions? > > Please answer the above questions and feel free to add color commentary > as to other issues or concerns not identified above. Wrt (B) what are the implications of making the PE a "more active element" on the externally visible behavior (where by "externall visible" I mean visible to a VPLS customer) ? Specifically would a VPLS customer be able to distinguish between the cases where a PE operates as specified today, and making the PE "a more active element in PIM procedures in a VPLS" ? And if yes, then what are the differences ? Yakov. From l2vpn-bounces@ietf.org Wed Nov 30 10:07:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTY1-0003gj-CW; Wed, 30 Nov 2005 10:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTXz-0003gb-H5; Wed, 30 Nov 2005 10:07:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27902; Wed, 30 Nov 2005 10:06:18 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhTsH-0006Lc-AB; Wed, 30 Nov 2005 10:28:02 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jAUF6r014112; Wed, 30 Nov 2005 07:06:53 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jAUF6m511766; Wed, 30 Nov 2005 07:06:48 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200511301506.jAUF6m511766@merlot.juniper.net> To: erosen@cisco.com In-Reply-To: Your message of "Tue, 29 Nov 2005 13:00:20 EST." <200511291800.jATI0Lln003077@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41810.1133363207.1@juniper.net> Date: Wed, 30 Nov 2005 07:06:48 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: l2vpn@ietf.org, Shane Amante , pim@ietf.org Subject: Re: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Eric, > > Should we require disabling Join Suppression on CE's? > > Oh, it's worse than that. We'd also have to prohibit CEs from ever > implementing PIM refresh reduction (if such a thing ever comes to be), from > ever running PIM over TCP (if such a thing ever comes to be), etc. Well, > it's a good thing the customer has bought an L2 service, to which all the L3 > protocols are transparent ;-) It is just that some L3 protocols are more transparent than others :-) On a more serious note the interaction with PIM refresh reduction and/or running PIM over TCP applies not just to VPLS, but to any ethernet switch that does PIM snooping. Therefore, while this is a valid issue, it goes well beyond VPLS. With this in mind I added PIM to the cc: list, as I think that the PIM WG would be more appropriate place to discuss the impact of PIM refresh reduction and/or running PIM over TCP on ethernet switches that do PIM snooping. > And remember, it's not just CEs that are "directly" connected to PEs, it's > all routers on a LAN which is bridged to a PE. > > > Should we NOT require disabling Join Suppression on CE's, thereby making > the PE a more active element in PIM procedures in a VPLS? > > At least the PE would only have to understand the customer's multicast > routing, it wouldn't have to understand anything really complicated, like > the customer's unicast routing ;-) > > Maybe we should step back and look at what we're doing here. Yakov.