From internet-drafts@ietf.org Wed Oct 2 17:02:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB4321F8427; Wed, 2 Oct 2013 17:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFF+AVgRSfTu; Wed, 2 Oct 2013 17:02:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B93B921F8BE6; Wed, 2 Oct 2013 17:02:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-acceptown-community-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131003000217.20697.63659.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 17:02:17 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 00:02:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : BGP ACCEPT_OWN Community Attribute Author(s) : James Uttaro Pradosh Mohapatra David J. Smith Robert Raszuk John Scudder Filename : draft-ietf-l3vpn-acceptown-community-07.txt Pages : 8 Date : 2013-10-02 Abstract: Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-acceptown-community There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-acceptown-community-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-acceptown-community-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.vigoureux@alcatel-lucent.com Fri Oct 4 02:46:57 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E1E21F90A7 for ; Fri, 4 Oct 2013 02:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffkAPO7pe1y2 for ; Fri, 4 Oct 2013 02:46:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0B69121F96CA for ; Fri, 4 Oct 2013 02:46:34 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r949kWpu025971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Oct 2013 04:46:33 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r949kVOu000564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Oct 2013 11:46:31 +0200 Received: from [172.27.205.225] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 4 Oct 2013 11:46:30 +0200 Message-ID: <524E8E76.8080905@alcatel-lucent.com> Date: Fri, 4 Oct 2013 11:46:30 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: , Subject: Re: Poll for adoption: draft-keyupate-l3vpn-mvpn-pe-ce References: <1504_1378391547_522895FB_1504_6335_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD294@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <1504_1378391547_522895FB_1504_6335_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD294@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 09:46:57 -0000 All, there is support for adopting this document. IPR exists and has been disclosed: https://datatracker.ietf.org/ipr/2192/ Authors, please republish as draft-ietf-l3vpn-mvpn-pe-ce-00 without any other change than for the title, date, and draft name. Thank you Martin (for the L3VPN co-chairs) Le 05/09/2013 16:32, thomas.morin@orange.com a écrit : > Hello working group, > > This email starts a two-week poll on possible adoption of > draft-keyupate-l3vpn-mvpn-pe-ce-00 [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > This poll runs until September 13th. > > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If you are listed as a document author or contributor* please > respond to this email whether or not you are aware of any relevant IPR. > The draft will not be adopted until a response has been received from > each author and contributor. > > If you are on the L3VPN WG mailing list but are not listed as an author > or contributor, then please explicitly respond only if you are aware of > any IPR that has not yet been disclosed in conformance with IETF rules. > > Thank you, > > Martin & Thomas > l3vpn chairs > > [1] http://tools.ietf.org/html/draft-keyupate-l3vpn-mvpn-pe-ce-00 > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From martin.vigoureux@alcatel-lucent.com Fri Oct 4 02:47:19 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF7B21F9A64 for ; Fri, 4 Oct 2013 02:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQSyzQOBom9J for ; Fri, 4 Oct 2013 02:47:07 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1A04321F9A2D for ; Fri, 4 Oct 2013 02:47:06 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r949l2RW009210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Oct 2013 04:47:03 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r949l0dO025145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Oct 2013 11:47:01 +0200 Received: from [172.27.205.225] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 4 Oct 2013 11:47:00 +0200 Message-ID: <524E8E94.8040400@alcatel-lucent.com> Date: Fri, 4 Oct 2013 11:47:00 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 09:47:19 -0000 All, we have not seen a lot of reaction to this adoption poll. We'd like to give it a second try. Please express your opinion (in favour or opposed to). Extension of the poll runs until Oct 11th. Martin (for the L3VPN co-chairs) Le 05/09/2013 16:40, thomas.morin@orange.com a écrit : > Hello working group, > > This email starts a two-week poll on possible adoption of > draft-zzhang-l2l3-vpn-mcast-mib-00 [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > *** Note that what is proposed is that this document becomes a common > foundation for the already adopted L3VPN multicast MIB > (draft-ietf-l3vpn-mvpn-mib) and for an L2VPN multicast MIB. Hence, the > L2VPN will be noticed and asked for feedback on the adoption of this > document. *** > > This poll runs until September 20th. > > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If you are listed as a document author or contributor* please > respond to this email whether or not you are aware of any relevant IPR. > The draft will not be adopted until a response has been received from > each author and contributor. > > If you are on the L3VPN WG mailing list but are not listed as an author > or contributor, then please explicitly respond only if you are aware of > any IPR that has not yet been disclosed in conformance with IETF rules. > > Thank you, > > Martin & Thomas > l3vpn chairs > > [1] http://tools.ietf.org/html/draft-zzhang-l2l3-vpn-mcast-mib-00 > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From internet-drafts@ietf.org Fri Oct 4 11:41:21 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D268121F9D68; Fri, 4 Oct 2013 11:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2clubWgfkJtF; Fri, 4 Oct 2013 11:41:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6137321F9C6C; Fri, 4 Oct 2013 11:41:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-bidir-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131004184121.8835.77159.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 11:41:21 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 18:41:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : MVPN: Using Bidirectional P-Tunnels Author(s) : Eric C. Rosen IJsbrand Wijnands Yiqun Cai Arjen Boers Filename : draft-ietf-l3vpn-mvpn-bidir-06.txt Pages : 32 Date : 2013-10-04 Abstract: A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP "auto- discovery" routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel attribute". Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513 and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-bidir There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-bidir-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-mvpn-bidir-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Oct 5 00:56:57 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94ED21F9A8C; Sat, 5 Oct 2013 00:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlRgrxbEoX3l; Sat, 5 Oct 2013 00:56:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7C421F9A43; Sat, 5 Oct 2013 00:56:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-pe-ce-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131005075654.31033.7566.idtracker@ietfa.amsl.com> Date: Sat, 05 Oct 2013 00:56:54 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 07:56:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : BGP as an MVPN PE-CE Protocol Author(s) : Keyur Patel Yakov Rekhter Eric Rosen Filename : draft-ietf-l3vpn-mvpn-pe-ce-00.txt Pages : 13 Date : 2013-10-04 Abstract: When a Service Provider offers BGP/MPLS IP VPN service to its customers, RFCs 6513 and 6514 describe protocols and procedures that the Service Provider can use in order to carry the customer's IP multicast traffic from one customer site to others. BGP can be used to carry customer multicast routing information from one Provider Edge (PE) router to another, but it is assumed that PIM is running on the interface between a Customer Edge (CE) router and a PE router. This document specifies protocols and procedures that, under certain conditions, allow customer multicast routing information to carried between PE and CE via BGP. This can eliminate the need to run PIM on the PE-CE interfaces, potentially eliminating the need to run PIM on the PE routers at all. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-pe-ce There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-pe-ce-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.vigoureux@alcatel-lucent.com Mon Oct 7 02:30:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3EC21E81BB for ; Mon, 7 Oct 2013 02:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.17 X-Spam-Level: X-Spam-Status: No, score=-110.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5WOUwtDmkap for ; Mon, 7 Oct 2013 02:30:30 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAE221E81C2 for ; Mon, 7 Oct 2013 02:30:22 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r979UFYb023097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Oct 2013 04:30:16 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r979UEEP011003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 11:30:14 +0200 Received: from [172.27.205.225] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 7 Oct 2013 11:30:14 +0200 Message-ID: <52527F25.7030203@alcatel-lucent.com> Date: Mon, 7 Oct 2013 11:30:13 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: Slots requests for L3VPN WG session - IETF 88 - Vancouver Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: 'L3VPN Chairs' X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:30:41 -0000 Dear all, the L3VPN WG will meet in Vancouver. The session (still subject to change) is scheduled Thursday (7th), Morning Session I, 09:00-11:30 This is thus a call for presentation slots. Could you please send us your requests, before the 22nd of October, indicating: draft name, speaker and desired duration (presentation + Q&As). Thank you. Martin for the L3VPN co-chairs From xuxiaohu@huawei.com Mon Oct 7 22:51:11 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0711E8188 for ; Mon, 7 Oct 2013 22:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMUeIh6O1KsP for ; Mon, 7 Oct 2013 22:51:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3544311E818E for ; Mon, 7 Oct 2013 22:51:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR82663; Tue, 08 Oct 2013 05:51:02 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 06:50:39 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 06:50:59 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 13:50:52 +0800 From: Xuxiaohu To: Martin Vigoureux , "l3vpn@ietf.org" Subject: re: Slots requests for L3VPN WG session - IETF 88 - Vancouver Thread-Topic: Slots requests for L3VPN WG session - IETF 88 - Vancouver Thread-Index: AQHOwz/trXh/aKlkE0SudNJx5cejwpnqTGsQ Date: Tue, 8 Oct 2013 05:50:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08213F68@NKGEML512-MBS.china.huawei.com> References: <52527F25.7030203@alcatel-lucent.com> In-Reply-To: <52527F25.7030203@alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'L3VPN Chairs' X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 05:51:11 -0000 SGkgY28tY2hhaXJzLA0KDQpJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIDEwLW1pbiB0aW1lc2xv dCBmb3IgdGhlIGZvbGxvd2luZyBkb2M6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC14dS1sM3Zwbi12aXJ0dWFsLXN1Ym5ldC0wMSwgc3BlYWtlcjogWGlhb2h1IFh1DQoNClhpYW9o dQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwzdnBuLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE1hcnRpbg0KPiBWaWdvdXJl dXgNCj4gt6LLzcqxvOQ6IDIwMTPE6jEw1MI3yNUgMTc6MzANCj4gytW8/sjLOiBsM3ZwbkBpZXRm Lm9yZw0KPiCzrcvNOiAnTDNWUE4gQ2hhaXJzJw0KPiDW98ziOiBTbG90cyByZXF1ZXN0cyBmb3Ig TDNWUE4gV0cgc2Vzc2lvbiAtIElFVEYgODggLSBWYW5jb3V2ZXINCj4gDQo+IERlYXIgYWxsLA0K PiANCj4gdGhlIEwzVlBOIFdHIHdpbGwgbWVldCBpbiBWYW5jb3V2ZXIuIFRoZSBzZXNzaW9uIChz dGlsbCBzdWJqZWN0IHRvDQo+IGNoYW5nZSkgaXMgc2NoZWR1bGVkIFRodXJzZGF5ICg3dGgpLCBN b3JuaW5nIFNlc3Npb24gSSwgMDk6MDAtMTE6MzANCj4gDQo+IFRoaXMgaXMgdGh1cyBhIGNhbGwg Zm9yIHByZXNlbnRhdGlvbiBzbG90cy4NCj4gDQo+IENvdWxkIHlvdSBwbGVhc2Ugc2VuZCB1cyB5 b3VyIHJlcXVlc3RzLCBiZWZvcmUgdGhlIDIybmQgb2YgT2N0b2JlciwNCj4gaW5kaWNhdGluZzoN Cj4gZHJhZnQgbmFtZSwgc3BlYWtlciBhbmQgZGVzaXJlZCBkdXJhdGlvbiAocHJlc2VudGF0aW9u ICsgUSZBcykuDQo+IA0KPiBUaGFuayB5b3UuDQo+IA0KPiBNYXJ0aW4NCj4gZm9yIHRoZSBMM1ZQ TiBjby1jaGFpcnMNCg== From kurtw@juniper.net Tue Oct 8 12:48:33 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EEA21F9C69 for ; Tue, 8 Oct 2013 12:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzIXV2+ivL2f for ; Tue, 8 Oct 2013 12:48:28 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id D022021F9CE8 for ; Tue, 8 Oct 2013 12:48:21 -0700 (PDT) Received: from mail206-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE031.bigfish.com (10.243.66.96) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 19:48:21 +0000 Received: from mail206-co1 (localhost [127.0.0.1]) by mail206-co1-R.bigfish.com (Postfix) with ESMTP id 7E032740168 for ; Tue, 8 Oct 2013 19:48:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zzbb2dI9371Ic89bh542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail206-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kurtw@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(13464003)(189002)(199002)(479174003)(377454003)(85306002)(15975445006)(81816001)(74502001)(81686001)(77096001)(76576001)(56816003)(54356001)(76796001)(83072001)(19580405001)(83322001)(19580395003)(80976001)(74662001)(33646001)(74706001)(74366001)(74876001)(65816001)(47446002)(74316001)(15202345003)(81342001)(80022001)(76482001)(66066001)(46102001)(56776001)(53806001)(54316002)(63696002)(31966008)(59766001)(79102001)(76786001)(51856001)(47736001)(77982001)(69226001)(49866001)(50986001)(81542001)(47976001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB357; H:BN1PR05MB359.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail206-co1 (localhost.localdomain [127.0.0.1]) by mail206-co1 (MessageSwitch) id 1381261661182408_21784; Tue, 8 Oct 2013 19:47:41 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.253]) by mail206-co1.bigfish.com (Postfix) with ESMTP id 1FB7ADC0146 for ; Tue, 8 Oct 2013 19:47:41 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 19:47:40 +0000 Received: from BN1PR05MB357.namprd05.prod.outlook.com (10.141.61.146) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 8 Oct 2013 19:47:40 +0000 Received: from BN1PR05MB359.namprd05.prod.outlook.com (10.141.61.150) by BN1PR05MB357.namprd05.prod.outlook.com (10.141.61.146) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 8 Oct 2013 19:47:38 +0000 Received: from BN1PR05MB359.namprd05.prod.outlook.com ([169.254.3.129]) by BN1PR05MB359.namprd05.prod.outlook.com ([169.254.3.129]) with mapi id 15.00.0785.001; Tue, 8 Oct 2013 19:47:38 +0000 From: Kurt Windisch To: "l3vpn@ietf.org" Subject: RE: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOwObZRQ25gKucq0iskT2GTTIUrpnrPGPw Date: Tue, 8 Oct 2013 19:47:37 +0000 Message-ID: <3f63120561bd437487b5fbf17b96f235@BN1PR05MB359.namprd05.prod.outlook.com> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> In-Reply-To: <524E8E94.8040400@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0993689CD1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 19:48:33 -0000 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQpUaGFua3MNCi0tS3VydA0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVmlnb3VyZXV4 DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMDQsIDIwMTMgMjo0NyBBTQ0KVG86IGwzdnBuQGlldGYu b3JnDQpTdWJqZWN0OiBIZWFkcy11cCBbUmU6IFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16emhh bmctbDJsMy12cG4tbWNhc3QtbWliXQ0KDQpBbGwsDQoNCndlIGhhdmUgbm90IHNlZW4gYSBsb3Qg b2YgcmVhY3Rpb24gdG8gdGhpcyBhZG9wdGlvbiBwb2xsLiBXZSdkIGxpa2UgdG8gDQpnaXZlIGl0 IGEgc2Vjb25kIHRyeS4NCg0KUGxlYXNlIGV4cHJlc3MgeW91ciBvcGluaW9uIChpbiBmYXZvdXIg b3Igb3Bwb3NlZCB0bykuDQoNCkV4dGVuc2lvbiBvZiB0aGUgcG9sbCBydW5zIHVudGlsIE9jdCAx MXRoLg0KDQpNYXJ0aW4NCihmb3IgdGhlIEwzVlBOIGNvLWNoYWlycykNCg0KTGUgMDUvMDkvMjAx MyAxNjo0MCwgdGhvbWFzLm1vcmluQG9yYW5nZS5jb20gYSDDqWNyaXQgOg0KPiBIZWxsbyB3b3Jr aW5nIGdyb3VwLA0KPg0KPiBUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gcG9z c2libGUgYWRvcHRpb24gb2YNCj4gZHJhZnQtenpoYW5nLWwybDMtdnBuLW1jYXN0LW1pYi0wMCBb MV0gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uDQo+DQo+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRv IHRoZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvcg0KPiBub3QgKGlu IHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQo+DQo+ICoq KiBOb3RlIHRoYXQgd2hhdCBpcyBwcm9wb3NlZCBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgYmVjb21l cyBhIGNvbW1vbg0KPiBmb3VuZGF0aW9uIGZvciB0aGUgYWxyZWFkeSBhZG9wdGVkIEwzVlBOIG11 bHRpY2FzdCBNSUINCj4gKGRyYWZ0LWlldGYtbDN2cG4tbXZwbi1taWIpIGFuZCBmb3IgYW4gTDJW UE4gbXVsdGljYXN0IE1JQi4gSGVuY2UsIHRoZQ0KPiBMMlZQTiB3aWxsIGJlIG5vdGljZWQgYW5k IGFza2VkIGZvciBmZWVkYmFjayBvbiB0aGUgYWRvcHRpb24gb2YgdGhpcw0KPiBkb2N1bWVudC4g KioqDQo+DQo+IFRoaXMgcG9sbCBydW5zIHVudGlsIFNlcHRlbWJlciAyMHRoLg0KPg0KPg0KPiAq Q29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55 IElQUiB0aGF0DQo+IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhh cyBiZWVuIGRpc2Nsb3NlZCBpbg0KPiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNl ZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkNCj4gYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo+ DQo+ID09PiAqSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJp YnV0b3IqIHBsZWFzZQ0KPiByZXNwb25kIHRvIHRoaXMgZW1haWwgd2hldGhlciBvciBub3QgeW91 IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KPiBUaGUgZHJhZnQgd2lsbCBub3QgYmUg YWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20NCj4gZWFjaCBh dXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KPg0KPiBJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQTiBXRyBt YWlsaW5nIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcg0KPiBvciBjb250cmli dXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2Fy ZSBvZg0KPiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9y bWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPg0KPiBUaGFuayB5b3UsDQo+DQo+IE1hcnRpbiAmIFRo b21hcw0KPiBsM3ZwbiBjaGFpcnMNCj4NCj4gWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1taWItMDANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN Cj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwNCj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0K Pg0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Ow0KPiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPg0KDQoNCg== From yakov@juniper.net Tue Oct 8 15:35:12 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0655221F9B92 for ; Tue, 8 Oct 2013 15:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.524 X-Spam-Level: X-Spam-Status: No, score=-101.524 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_DELETE=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+Pkj2pP1gKH for ; Tue, 8 Oct 2013 15:35:03 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7352B21F9344 for ; Tue, 8 Oct 2013 15:34:29 -0700 (PDT) Received: from mail178-db9-R.bigfish.com (10.174.16.234) by DB9EHSOBE004.bigfish.com (10.174.14.67) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 22:34:28 +0000 Received: from mail178-db9 (localhost [127.0.0.1]) by mail178-db9-R.bigfish.com (Postfix) with ESMTP id 7A605840195 for ; Tue, 8 Oct 2013 22:34:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI9371Ic89bh542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail178-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail178-db9 (localhost.localdomain [127.0.0.1]) by mail178-db9 (MessageSwitch) id 1381271666251996_23634; Tue, 8 Oct 2013 22:34:26 +0000 (UTC) Received: from DB9EHSMHS015.bigfish.com (unknown [10.174.16.250]) by mail178-db9.bigfish.com (Postfix) with ESMTP id 388C2460041 for ; Tue, 8 Oct 2013 22:34:26 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.52) by DB9EHSMHS015.bigfish.com (10.174.14.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 22:34:25 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 15:34:23 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r98MYGL03268; Tue, 8 Oct 2013 15:34:16 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201310082234.r98MYGL03268@magenta.juniper.net> To: Kurt Windisch Subject: Re: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] In-Reply-To: <3f63120561bd437487b5fbf17b96f235@BN1PR05MB359.namprd05.prod.outlook.com> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> <3f63120561bd437487b5fbf17b96f235@BN1PR05MB359.namprd05.prod.outlook.com> X-MH-In-Reply-To: Kurt Windisch message dated "Tue, 08 Oct 2013 19:47:37 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <43933.1381271656.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Oct 2013 15:34:16 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: yakov@juniper.net, "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:35:12 -0000 +1 > I support adoption of this draft. > Thanks > --Kurt > = > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf O= f Mar tin Vigoureux > Sent: Friday, October 04, 2013 2:47 AM > To: l3vpn@ietf.org > Subject: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mi= b] > = > All, > = > we have not seen a lot of reaction to this adoption poll. We'd like to = > give it a second try. > = > Please express your opinion (in favour or opposed to). > = > Extension of the poll runs until Oct 11th. > = > Martin > (for the L3VPN co-chairs) > = > Le 05/09/2013 16:40, thomas.morin@orange.com a =C3=A9crit : > > Hello working group, > > > > This email starts a two-week poll on possible adoption of > > draft-zzhang-l2l3-vpn-mcast-mib-00 [1] as a working group item. > > > > Please send comments to the list and state if you support adoption or > > not (in the later case, please also state the reasons). > > > > *** Note that what is proposed is that this document becomes a common > > foundation for the already adopted L3VPN multicast MIB > > (draft-ietf-l3vpn-mvpn-mib) and for an L2VPN multicast MIB. Hence, the > > L2VPN will be noticed and asked for feedback on the adoption of this > > document. *** > > > > This poll runs until September 20th. > > > > > > *Coincidentally*, we are also polling for knowledge of any IPR that > > applies to this draft, to ensure that IPR has been disclosed in > > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > > and 5378 for more details). > > > > =3D=3D> *If you are listed as a document author or contributor* please > > respond to this email whether or not you are aware of any relevant IPR= . > > The draft will not be adopted until a response has been received from > > each author and contributor. > > > > If you are on the L3VPN WG mailing list but are not listed as an autho= r > > or contributor, then please explicitly respond only if you are aware o= f > > any IPR that has not yet been disclosed in conformance with IETF rules= . > > > > Thank you, > > > > Martin & Thomas > > l3vpn chairs > > > > [1] http://tools.ietf.org/html/draft-zzhang-l2l3-vpn-mcast-mib-00 > > ______________________________________________________________________= _____ ______________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations con= fiden tielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messag= es el ectroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deform= e ou = falsifie. Merci. > > > > This message and its attachments may contain confidential or privilege= d inf ormation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and= dele te this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have = been = modified, changed or falsified. > > Thank you. > > > = > = > = From thomas.morin@orange.com Wed Oct 9 01:07:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5CE21E80F8 for ; Wed, 9 Oct 2013 01:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPrTI2Bar+Zu for ; Wed, 9 Oct 2013 01:07:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 079F721E80FA for ; Wed, 9 Oct 2013 01:07:32 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 46CCD1B857D for ; Wed, 9 Oct 2013 10:07:31 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 2FC5D18004B for ; Wed, 9 Oct 2013 10:07:31 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 10:07:30 +0200 From: To: "l3vpn@ietf.org" Subject: Re: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOxMaZCzRpHqJQHUSQGkVp5X0yvg== Date: Wed, 9 Oct 2013 08:07:30 +0000 Message-ID: <8822_1381306051_52550EC3_8822_2124_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D07643CFB@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> In-Reply-To: <524E8E94.8040400@alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="utf-8" Content-ID: <4D64DB1CCCFD664295ACDCFA797ADD7F@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.8.130016 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 08:07:41 -0000 SGkgYWxsLA0KDQooV2l0aG91dCBteSBjby1jaGFpciBoYXQ6KSBJIHN1cHBvcnQgYWRvcHRpb24g b2YgdGhpcyBkcmFmdC4NCg0KSXQgaXMgZGVmaW5pdGVseSBhIGdvb2QgaWRlYSB0byBmYWN0b3Ig b3V0IHdoYXQgaXMgY29tbW9uIGJldHdlZW4gTDJWUE4gDQphbmQgTDNWUE4gTUlCLCB3aGljaCBz aGFyZSBhIGxhcmdlIHBhcnQgaW4gdGVybXMgb2YgcHJvdG9jb2wgDQphcmNoaXRlY3R1cmUgZm9y IG11bHRpY2FzdCBzdXBwb3J0Lg0KDQotVGhvbWFzDQoNCg0KTWFydGluIFZpZ291cmV1eDoNCj4g QWxsLA0KPg0KPiB3ZSBoYXZlIG5vdCBzZWVuIGEgbG90IG9mIHJlYWN0aW9uIHRvIHRoaXMgYWRv cHRpb24gcG9sbC4gV2UnZCBsaWtlIHRvIA0KPiBnaXZlIGl0IGEgc2Vjb25kIHRyeS4NCj4NCj4g UGxlYXNlIGV4cHJlc3MgeW91ciBvcGluaW9uIChpbiBmYXZvdXIgb3Igb3Bwb3NlZCB0bykuDQo+ DQo+IEV4dGVuc2lvbiBvZiB0aGUgcG9sbCBydW5zIHVudGlsIE9jdCAxMXRoLg0KPg0KPiBNYXJ0 aW4NCj4gKGZvciB0aGUgTDNWUE4gY28tY2hhaXJzKQ0KPg0KPiBMZSAwNS8wOS8yMDEzIDE2OjQw LCB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSBhIMOpY3JpdCA6DQo+PiBIZWxsbyB3b3JraW5nIGdy b3VwLA0KPj4NCj4+IFRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBwb3NzaWJs ZSBhZG9wdGlvbiBvZg0KPj4gZHJhZnQtenpoYW5nLWwybDMtdnBuLW1jYXN0LW1pYi0wMCBbMV0g YXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uDQo+Pg0KPj4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8g dGhlIGxpc3QgYW5kIHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yDQo+PiBub3QgKGlu IHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQo+Pg0KPj4g KioqIE5vdGUgdGhhdCB3aGF0IGlzIHByb3Bvc2VkIGlzIHRoYXQgdGhpcyBkb2N1bWVudCBiZWNv bWVzIGEgY29tbW9uDQo+PiBmb3VuZGF0aW9uIGZvciB0aGUgYWxyZWFkeSBhZG9wdGVkIEwzVlBO IG11bHRpY2FzdCBNSUINCj4+IChkcmFmdC1pZXRmLWwzdnBuLW12cG4tbWliKSBhbmQgZm9yIGFu IEwyVlBOIG11bHRpY2FzdCBNSUIuIEhlbmNlLCB0aGUNCj4+IEwyVlBOIHdpbGwgYmUgbm90aWNl ZCBhbmQgYXNrZWQgZm9yIGZlZWRiYWNrIG9uIHRoZSBhZG9wdGlvbiBvZiB0aGlzDQo+PiBkb2N1 bWVudC4gKioqDQo+Pg0KPj4gVGhpcyBwb2xsIHJ1bnMgdW50aWwgU2VwdGVtYmVyIDIwdGguDQo+ Pg0KPj4NCj4+ICpDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3ds ZWRnZSBvZiBhbnkgSVBSIHRoYXQNCj4+IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJl IHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbg0KPj4gY29tcGxpYW5jZSB3aXRoIElFVEYg SVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5DQo+PiBhbmQgNTM3OCBmb3IgbW9y ZSBkZXRhaWxzKS4NCj4+DQo+PiA9PT4gKklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQg YXV0aG9yIG9yIGNvbnRyaWJ1dG9yKiBwbGVhc2UNCj4+IHJlc3BvbmQgdG8gdGhpcyBlbWFpbCB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQo+PiBUaGUg ZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2Vp dmVkIGZyb20NCj4+IGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4+DQo+PiBJZiB5b3Ug YXJlIG9uIHRoZSBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFu IGF1dGhvcg0KPj4gb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9u ZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YNCj4+IGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBi ZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQo+Pg0KPj4gVGhh bmsgeW91LA0KPj4NCj4+IE1hcnRpbiAmIFRob21hcw0KPj4gbDN2cG4gY2hhaXJzDQo+Pg0KPj4g WzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2Fz dC1taWItMDANCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From andy.da.green@bt.com Wed Oct 9 04:04:48 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8699321F9FF3 for ; Wed, 9 Oct 2013 04:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ1470b9+q29 for ; Wed, 9 Oct 2013 04:04:44 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09C21F8E51 for ; Wed, 9 Oct 2013 04:04:35 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 9 Oct 2013 12:04:33 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.25]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 9 Oct 2013 12:04:33 +0100 From: To: Date: Wed, 9 Oct 2013 12:04:33 +0100 Subject: RE: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOwTSq6vWWJWrwMEe8ehw7Q7WosZnk7qjQgAABqUCABskNwIAARJJw Message-ID: <464C9090B4F1624C9174D50D456B13EF5DC9FE4C95@EMV65-UKRD.domain1.systemhost.net> References: <0AE6584056494741966D3375421AA5FA0A8EBEDF@MISOUT7MSGUSR9N.ITServices.sbc.com> <0f76b24df0414a9cae23833cf6a8ac72@BN1PR05MB073.namprd05.prod.outlook.com> In-Reply-To: <0f76b24df0414a9cae23833cf6a8ac72@BN1PR05MB073.namprd05.prod.outlook.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: zzhang@juniper.net X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:04:48 -0000 DQpTdXBwb3J0DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmVmZnJl eSAoWmhhb2h1aSkgWmhhbmcgW21haWx0bzp6emhhbmdAanVuaXBlci5uZXRdDQo+IFNlbnQ6IEZy aWRheSwgT2N0b2JlciAwNCwgMjAxMyAzOjM2IFBNDQo+IFRvOiBKYWluLCBQcmFkZWVwIEcgKFBy YWRlZXApOyBTYW1lZXIgR3VscmFqYW5pOyBBbmR5IEdyZWVuOyBBU0lGLCANCj4gU0FVRA0KPiBD YzogTWFyY28gUm9kcmlndWVzOyBQYXZhbiBLdXJhcGF0aTsgUm9iZXJ0IEtlYmxlcjsgS3VydCBX aW5kaXNjaA0KPiBTdWJqZWN0OiBGVzogSGVhZHMtdXAgW1JlOiBQb2xsIGZvciBhZG9wdGlvbjog ZHJhZnQtenpoYW5nLWwybDMtdnBuLSANCj4gbWNhc3QtbWliXQ0KPiANCj4gUGxlYXNlIHJvdW5k IHVwIHNvbWUgc3VwcG9ydCBmb3IgdGhlIGZvbGxvd2luZyBhZG9wdGlvbiBjYWxsLg0KPiANCj4g VGhlIE1WUE4gTUlCIGRlcGVuZHMgb24gaXQgLSBpdCBoYXMgc29tZSBvYmplY3RzIHB1bGxlZCBv dXQgb2YgdGhlIA0KPiBNVlBOIE1JQiBzbyB0aGF0IHRoZXkgY2FuIGJlIHVzZWQgZm9yIGJvdGgg TVZQTiBNSUIgYW5kIFZQTFMgTUNBU1QgTUlCLg0KPiANCj4gV2UgbmVlZCBpdCB0byBiZSBhZG9w dGVkIGJlZm9yZSB3ZSBjYW4gbW92ZSBNVlBOIE1JQiBmb3J3YXJkLg0KPiANCj4gVGhhbmtzLg0K PiBKZWZmcmV5DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0 aW4gVmlnb3VyZXV4IFttYWlsdG86bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb21d DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAwNCwgMjAxMyA1OjQ3IEFNDQo+IFRvOiBsM3ZwbkBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBIZWFkcy11cCBbUmU6IFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFm dC16emhhbmctbDJsMy12cG4tbWNhc3QtIA0KPiBtaWJdDQo+IA0KPiBBbGwsDQo+IA0KPiB3ZSBo YXZlIG5vdCBzZWVuIGEgbG90IG9mIHJlYWN0aW9uIHRvIHRoaXMgYWRvcHRpb24gcG9sbC4gV2Un ZCBsaWtlIHRvIA0KPiBnaXZlIGl0IGEgc2Vjb25kIHRyeS4NCj4gDQo+IFBsZWFzZSBleHByZXNz IHlvdXIgb3BpbmlvbiAoaW4gZmF2b3VyIG9yIG9wcG9zZWQgdG8pLg0KPiANCj4gRXh0ZW5zaW9u IG9mIHRoZSBwb2xsIHJ1bnMgdW50aWwgT2N0IDExdGguDQo+IA0KPiBNYXJ0aW4NCj4gKGZvciB0 aGUgTDNWUE4gY28tY2hhaXJzKQ0KPiANCj4gTGUgMDUvMDkvMjAxMyAxNjo0MCwgdGhvbWFzLm1v cmluQG9yYW5nZS5jb20gYSDDqWNyaXQgOg0KPiA+IEhlbGxvIHdvcmtpbmcgZ3JvdXAsDQo+ID4N Cj4gPiBUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gcG9zc2libGUgYWRvcHRp b24gb2YNCj4gPiBkcmFmdC16emhhbmctbDJsMy12cG4tbWNhc3QtbWliLTAwIFsxXSBhcyBhIHdv cmtpbmcgZ3JvdXAgaXRlbS4NCj4gPg0KPiA+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBs aXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiANCj4gPiBvciBub3QgKGluIHRo ZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQo+ID4NCj4gPiAq KiogTm90ZSB0aGF0IHdoYXQgaXMgcHJvcG9zZWQgaXMgdGhhdCB0aGlzIGRvY3VtZW50IGJlY29t ZXMgYSANCj4gPiBjb21tb24gZm91bmRhdGlvbiBmb3IgdGhlIGFscmVhZHkgYWRvcHRlZCBMM1ZQ TiBtdWx0aWNhc3QgTUlCDQo+ID4gKGRyYWZ0LWlldGYtbDN2cG4tbXZwbi1taWIpIGFuZCBmb3Ig YW4gTDJWUE4gbXVsdGljYXN0IE1JQi4gSGVuY2UsDQo+IHRoZQ0KPiA+IEwyVlBOIHdpbGwgYmUg bm90aWNlZCBhbmQgYXNrZWQgZm9yIGZlZWRiYWNrIG9uIHRoZSBhZG9wdGlvbiBvZiB0aGlzIA0K PiA+IGRvY3VtZW50LiAqKioNCj4gPg0KPiA+IFRoaXMgcG9sbCBydW5zIHVudGlsIFNlcHRlbWJl ciAyMHRoLg0KPiA+DQo+ID4NCj4gPiAqQ29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xs aW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IA0KPiA+IGFwcGxpZXMgdG8gdGhpcyBk cmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiANCj4gPiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggDQo+ID4gZm9yIG1vcmUgZGV0YWlscykuDQo+ID4NCj4gPiA9PT4gKklmIHlvdSBhcmUg bGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yKiBwbGVhc2UgDQo+ID4g cmVzcG9uZCB0byB0aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55 IHJlbGV2YW50DQo+IElQUi4NCj4gPiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRp bCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIA0KPiA+IGZyb20gZWFjaCBhdXRob3IgYW5k IGNvbnRyaWJ1dG9yLg0KPiA+DQo+ID4gSWYgeW91IGFyZSBvbiB0aGUgTDNWUE4gV0cgbWFpbGlu ZyBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbg0KPiBhdXRob3INCj4gPiBvciBjb250cmli dXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2Fy ZQ0KPiBvZg0KPiA+IGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBj b25mb3JtYW5jZSB3aXRoIElFVEYNCj4gcnVsZXMuDQo+ID4NCj4gPiBUaGFuayB5b3UsDQo+ID4N Cj4gPiBNYXJ0aW4gJiBUaG9tYXMNCj4gPiBsM3ZwbiBjaGFpcnMNCj4gPg0KPiA+IFsxXSBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16emhhbmctbDJsMy12cG4tbWNhc3QtbWliLTAw DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBfIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gPiBwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cw0KPiBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiA+ IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcw0KPiBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sDQo+ID4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsDQo+IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+ DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yDQo+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsNCj4gPiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPiBBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IA0KPiA+IGhhdmUN Cj4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4gVGhhbmsgeW91Lg0K PiA+DQoNCg== From giles.heron@gmail.com Wed Oct 9 04:23:19 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2A21E8149 for ; Wed, 9 Oct 2013 04:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvNjPoPFOwq6 for ; Wed, 9 Oct 2013 04:23:18 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1850F21E8140 for ; Wed, 9 Oct 2013 04:23:16 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n4so424481qcx.41 for ; Wed, 09 Oct 2013 04:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xXlWzvwrt83v5JF3Sq/3o9kpHnx3tydBPHAwtf485r8=; b=1F80LRnAcM6TZf6c04CfxT1frbihIr8MO6c8wUlFOgYqHM8zJZidl0n0f4PiyB0kvY WS7HaLpU1a09vX/B7+JNr9XuJxIMPfj90yai+usMDdK/JHr89INJ94E6/eiuvFsi6Auq 1C9y7L/u7miaVP7B98RZlefzrY1+Qs49XQ/Dp8MB3yZvgI4Fo/EMVFqi3FrxXb2RQXUR HH1KHFKXDtyFKE2raQaAi3oxtUUicA4Fkt0xKlHkRNJCAwIISDdVmrPzF2vdtTvbR1na QiF19awVnlhML0sXuJFHAbIAX+sqMWU8+JQ+/dNIGuik0sU3Gstxq5OOUOHNHxKfnylx kmDw== X-Received: by 10.224.54.129 with SMTP id q1mr10215301qag.19.1381317796397; Wed, 09 Oct 2013 04:23:16 -0700 (PDT) Received: from dhcp-lon06-vla300-10-148-88-253.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id u3sm15270528qej.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 04:23:15 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] From: Giles Heron In-Reply-To: <8822_1381306051_52550EC3_8822_2124_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D07643CFB@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Wed, 9 Oct 2013 12:23:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> <8822_1381306051_52550EC3_8822_2124_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D07643CFB@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: thomas.morin@orange.com X-Mailer: Apple Mail (2.1510) Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:23:19 -0000 Agreed (and likewise without my co-chair hat...) Giles On 9 Oct 2013, at 09:07, thomas.morin@orange.com wrote: > Hi all, >=20 > (Without my co-chair hat:) I support adoption of this draft. >=20 > It is definitely a good idea to factor out what is common between = L2VPN=20 > and L3VPN MIB, which share a large part in terms of protocol=20 > architecture for multicast support. >=20 > -Thomas >=20 >=20 > Martin Vigoureux: >> All, >>=20 >> we have not seen a lot of reaction to this adoption poll. We'd like = to=20 >> give it a second try. >>=20 >> Please express your opinion (in favour or opposed to). >>=20 >> Extension of the poll runs until Oct 11th. >>=20 >> Martin >> (for the L3VPN co-chairs) >>=20 >> Le 05/09/2013 16:40, thomas.morin@orange.com a =E9crit : >>> Hello working group, >>>=20 >>> This email starts a two-week poll on possible adoption of >>> draft-zzhang-l2l3-vpn-mcast-mib-00 [1] as a working group item. >>>=20 >>> Please send comments to the list and state if you support adoption = or >>> not (in the later case, please also state the reasons). >>>=20 >>> *** Note that what is proposed is that this document becomes a = common >>> foundation for the already adopted L3VPN multicast MIB >>> (draft-ietf-l3vpn-mvpn-mib) and for an L2VPN multicast MIB. Hence, = the >>> L2VPN will be noticed and asked for feedback on the adoption of this >>> document. *** >>>=20 >>> This poll runs until September 20th. >>>=20 >>>=20 >>> *Coincidentally*, we are also polling for knowledge of any IPR that >>> applies to this draft, to ensure that IPR has been disclosed in >>> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >>> and 5378 for more details). >>>=20 >>> =3D=3D> *If you are listed as a document author or contributor* = please >>> respond to this email whether or not you are aware of any relevant = IPR. >>> The draft will not be adopted until a response has been received = from >>> each author and contributor. >>>=20 >>> If you are on the L3VPN WG mailing list but are not listed as an = author >>> or contributor, then please explicitly respond only if you are aware = of >>> any IPR that has not yet been disclosed in conformance with IETF = rules. >>>=20 >>> Thank you, >>>=20 >>> Martin & Thomas >>> l3vpn chairs >>>=20 >>> [1] http://tools.ietf.org/html/draft-zzhang-l2l3-vpn-mcast-mib-00 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From sa9362@att.com Wed Oct 9 04:28:33 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089BF11E8163 for ; Wed, 9 Oct 2013 04:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpPyiB7mGX+U for ; Wed, 9 Oct 2013 04:28:27 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD9E21F8CB4 for ; Wed, 9 Oct 2013 04:28:26 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9dd35525.0.5393422.00-113.14976640.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 09 Oct 2013 11:28:26 +0000 (UTC) X-MXL-Hash: 52553dda0786be18-82c768f03f9757e900e89aac107799be81d97273 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r99BSP4A024913; Wed, 9 Oct 2013 07:28:25 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r99BSIkf024872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Oct 2013 07:28:20 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 9 Oct 2013 11:28:10 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0158.001; Wed, 9 Oct 2013 07:28:10 -0400 From: "ASIF, SAUD" To: "thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: RE: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib Thread-Topic: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib Thread-Index: AQHOqkXjN8FWyazdykmKzrXPyhzW/Jnr+kGQ Date: Wed, 9 Oct 2013 11:28:09 +0000 Message-ID: <0AE6584056494741966D3375421AA5FA0A8EF4B1@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.6.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=IPW1/HTG c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zGNzcsqV0aUA:10 a=uxzZmZYZmd8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=nTVsdK6fRlwA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=tiJ45ezSf4wguSwscooA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=oAXR_kdF8uMA:10 a=CRWz1FZMEdsUIf6i:21 a=YyeB-Ivq1FN-] X-AnalysisOut: [PIAQ:21] Cc: "draft-zzhang-l2l3-vpn-mcast-mib@tools.ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:28:33 -0000 U3VwcG9ydC4NCg0KU2F1ZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDN2 cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbQ0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJl ciAwNSwgMjAxMyAxMDo0MSBBTQ0KVG86IGwzdnBuQGlldGYub3JnDQpDYzogZHJhZnQtenpoYW5n LWwybDMtdnBuLW1jYXN0LW1pYkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUG9sbCBmb3IgYWRv cHRpb246IGRyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1taWINCg0KSGVsbG8gd29ya2luZyBn cm91cCwNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xsIG9uIHBvc3NpYmxlIGFk b3B0aW9uIG9mDQpkcmFmdC16emhhbmctbDJsMy12cG4tbWNhc3QtbWliLTAwIFsxXSBhcyBhIHdv cmtpbmcgZ3JvdXAgaXRlbS4NCg0KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5k IHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yDQpub3QgKGluIHRoZSBsYXRlciBjYXNl LCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQoNCioqKiBOb3RlIHRoYXQgd2hhdCBp cyBwcm9wb3NlZCBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgYmVjb21lcyBhIGNvbW1vbg0KZm91bmRh dGlvbiBmb3IgdGhlIGFscmVhZHkgYWRvcHRlZCBMM1ZQTiBtdWx0aWNhc3QgTUlCDQooZHJhZnQt aWV0Zi1sM3Zwbi1tdnBuLW1pYikgYW5kIGZvciBhbiBMMlZQTiBtdWx0aWNhc3QgTUlCLiBIZW5j ZSwgdGhlDQpMMlZQTiB3aWxsIGJlIG5vdGljZWQgYW5kIGFza2VkIGZvciBmZWVkYmFjayBvbiB0 aGUgYWRvcHRpb24gb2YgdGhpcw0KZG9jdW1lbnQuICoqKg0KDQpUaGlzIHBvbGwgcnVucyB1bnRp bCBTZXB0ZW1iZXIgMjB0aC4NCg0KDQoqQ29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xs aW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0DQphcHBsaWVzIHRvIHRoaXMgZHJhZnQs IHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4NCmNvbXBsaWFuY2Ugd2l0 aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OQ0KYW5kIDUzNzggZm9y IG1vcmUgZGV0YWlscykuDQoNCj09PiAqSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3Igb3IgY29udHJpYnV0b3IqIHBsZWFzZQ0KcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdoZXRo ZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NClRoZSBkcmFmdCB3 aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJv bQ0KZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQ TiBXRyBtYWlsaW5nIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcg0Kb3IgY29u dHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUg YXdhcmUgb2YNCmFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25m b3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rIHlvdSwNCg0KTWFydGluICYgVGhvbWFz DQpsM3ZwbiBjaGFpcnMNCg0KWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp6 aGFuZy1sMmwzLXZwbi1tY2FzdC1taWItMDANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwN Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3Uu DQoNCg== From kurapati@juniper.net Wed Oct 9 04:37:26 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A89E11E8163 for ; Wed, 9 Oct 2013 04:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C36lvsNctdSw for ; Wed, 9 Oct 2013 04:37:21 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27821F8D12 for ; Wed, 9 Oct 2013 04:37:19 -0700 (PDT) Received: from mail213-db9-R.bigfish.com (10.174.16.249) by DB9EHSOBE034.bigfish.com (10.174.14.97) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 11:37:18 +0000 Received: from mail213-db9 (localhost [127.0.0.1]) by mail213-db9-R.bigfish.com (Postfix) with ESMTP id A48F31600FC; Wed, 9 Oct 2013 11:37:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail213-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kurapati@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(164054003)(199002)(189002)(377454003)(77096001)(76482001)(15202345003)(66066001)(56776001)(54316002)(74366001)(4396001)(47736001)(49866001)(80976001)(63696002)(15975445006)(19580395003)(19580405001)(83322001)(80022001)(65816001)(81816001)(81686001)(85306002)(83072001)(33646001)(74876001)(74316001)(79102001)(74662001)(47446002)(74502001)(53806001)(56816003)(59766001)(76786001)(51856001)(76796001)(77982001)(46102001)(76576001)(69226001)(50986001)(47976001)(54356001)(31966008)(81542001)(81342001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB440; H:BN1PR05MB440.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail213-db9 (localhost.localdomain [127.0.0.1]) by mail213-db9 (MessageSwitch) id 138131863739511_7341; Wed, 9 Oct 2013 11:37:17 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.235]) by mail213-db9.bigfish.com (Postfix) with ESMTP id EFE0914006E; Wed, 9 Oct 2013 11:37:16 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 11:37:16 +0000 Received: from BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 11:37:10 +0000 Received: from BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 9 Oct 2013 11:37:09 +0000 Received: from BN1PR05MB440.namprd05.prod.outlook.com ([169.254.3.84]) by BN1PR05MB440.namprd05.prod.outlook.com ([169.254.3.84]) with mapi id 15.00.0785.001; Wed, 9 Oct 2013 11:37:09 +0000 From: Pavan Kurapati To: "EXT - thomas.morin@orange.com" , "l3vpn@ietf.org" Subject: RE: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib Thread-Topic: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib Thread-Index: AQHOqkXjN8FWyazdykmKzrXPyhzW/Jnscx7A Date: Wed, 9 Oct 2013 11:37:08 +0000 Message-ID: References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0994F5E0C5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "draft-zzhang-l2l3-vpn-mcast-mib@tools.ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:37:26 -0000 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQoNClRoYW5rcywNClBhdmFuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHRob21hcy5tb3JpbkBv cmFuZ2UuY29tDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA1LCAyMDEzIDEwOjQxIEFNDQpU bzogbDN2cG5AaWV0Zi5vcmcNCkNjOiBkcmFmdC16emhhbmctbDJsMy12cG4tbWNhc3QtbWliQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtenpoYW5nLWwy bDMtdnBuLW1jYXN0LW1pYg0KDQpIZWxsbyB3b3JraW5nIGdyb3VwLA0KDQpUaGlzIGVtYWlsIHN0 YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gcG9zc2libGUgYWRvcHRpb24gb2YNCmRyYWZ0LXp6aGFu Zy1sMmwzLXZwbi1tY2FzdC1taWItMDAgWzFdIGFzIGEgd29ya2luZyBncm91cCBpdGVtLg0KDQpQ bGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1cHBvcnQg YWRvcHRpb24gb3Igbm90IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3RhdGUgdGhl IHJlYXNvbnMpLg0KDQoqKiogTm90ZSB0aGF0IHdoYXQgaXMgcHJvcG9zZWQgaXMgdGhhdCB0aGlz IGRvY3VtZW50IGJlY29tZXMgYSBjb21tb24gZm91bmRhdGlvbiBmb3IgdGhlIGFscmVhZHkgYWRv cHRlZCBMM1ZQTiBtdWx0aWNhc3QgTUlCDQooZHJhZnQtaWV0Zi1sM3Zwbi1tdnBuLW1pYikgYW5k IGZvciBhbiBMMlZQTiBtdWx0aWNhc3QgTUlCLiBIZW5jZSwgdGhlIEwyVlBOIHdpbGwgYmUgbm90 aWNlZCBhbmQgYXNrZWQgZm9yIGZlZWRiYWNrIG9uIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3Vt ZW50LiAqKioNCg0KVGhpcyBwb2xsIHJ1bnMgdW50aWwgU2VwdGVtYmVyIDIwdGguDQoNCg0KKkNv aW5jaWRlbnRhbGx5Kiwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJ UFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVl biBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAz OTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQo9PT4gKklmIHlv dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yKiBwbGVhc2Ug cmVzcG9uZCB0byB0aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55 IHJlbGV2YW50IElQUi4NClRoZSBkcmFmdCB3aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEgcmVz cG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3Iu DQoNCklmIHlvdSBhcmUgb24gdGhlIEwzVlBOIFdHIG1haWxpbmcgbGlzdCBidXQgYXJlIG5vdCBs aXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5 IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHll dCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5r IHlvdSwNCg0KTWFydGluICYgVGhvbWFzDQpsM3ZwbiBjaGFpcnMNCg0KWzFdIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1taWItMDANCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4N Cg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4NClRoYW5rIHlvdS4NCg0K From marco@juniper.net Wed Oct 9 04:45:55 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B997E11E8174 for ; Wed, 9 Oct 2013 04:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CihG4DLbN1wc for ; Wed, 9 Oct 2013 04:45:49 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id A44BA11E8178 for ; Wed, 9 Oct 2013 04:45:43 -0700 (PDT) Received: from mail111-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 11:45:38 +0000 Received: from mail111-co1 (localhost [127.0.0.1]) by mail111-co1-R.bigfish.com (Postfix) with ESMTP id 74D095C0178; Wed, 9 Oct 2013 11:45:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic89bh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail111-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=marco@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(479174003)(199002)(189002)(377454003)(36756003)(77982001)(63696002)(54316002)(54356001)(59766001)(76176001)(56776001)(53806001)(85306002)(47446002)(83322001)(19580405001)(19580395003)(81816001)(74502001)(51856001)(76796001)(76786001)(46102001)(4396001)(49866001)(69226001)(50986001)(47976001)(74876001)(81686001)(47736001)(74366001)(65816001)(76482001)(74706001)(15975445006)(81342001)(81542001)(15202345003)(79102001)(66066001)(80022001)(56816003)(77096001)(74662001)(83506001)(31966008)(83072001)(80976001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB071; H:BLUPR05MB072.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail111-co1 (localhost.localdomain [127.0.0.1]) by mail111-co1 (MessageSwitch) id 1381319136892088_15063; Wed, 9 Oct 2013 11:45:36 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.231]) by mail111-co1.bigfish.com (Postfix) with ESMTP id CBF6D4C006B; Wed, 9 Oct 2013 11:45:36 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 11:45:36 +0000 Received: from BLUPR05MB071.namprd05.prod.outlook.com (10.255.214.24) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 11:45:35 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) by BLUPR05MB071.namprd05.prod.outlook.com (10.255.214.24) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 9 Oct 2013 11:45:34 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com ([169.254.16.168]) by BLUPR05MB072.namprd05.prod.outlook.com ([169.254.16.168]) with mapi id 15.00.0785.001; Wed, 9 Oct 2013 11:45:33 +0000 From: Marco Rodrigues To: "l3vpn@ietf.org" , Martin Vigoureux Subject: Re: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOxOUP5D47bpuRcUiBR2j/6vZhOg== Date: Wed, 9 Oct 2013 11:45:33 +0000 Message-ID: In-Reply-To: <524E8E94.8040400@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.232.2] x-forefront-prvs: 0994F5E0C5 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <769D0CD84C99CF43AE496650C85B0994@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:45:55 -0000 Support.=20 Marco. On 10/4/13 5:47 AM, "Martin Vigoureux" wrote: >All, > >we have not seen a lot of reaction to this adoption poll. We'd like to >give it a second try. > >Please express your opinion (in favour or opposed to). > >Extension of the poll runs until Oct 11th. > >Martin >(for the L3VPN co-chairs) > >Le 05/09/2013 16:40, thomas.morin@orange.com a =E9crit : >> Hello working group, >> >> This email starts a two-week poll on possible adoption of >> draft-zzhang-l2l3-vpn-mcast-mib-00 [1] as a working group item. >> >> Please send comments to the list and state if you support adoption or >> not (in the later case, please also state the reasons). >> >> *** Note that what is proposed is that this document becomes a common >> foundation for the already adopted L3VPN multicast MIB >> (draft-ietf-l3vpn-mvpn-mib) and for an L2VPN multicast MIB. Hence, the >> L2VPN will be noticed and asked for feedback on the adoption of this >> document. *** >> >> This poll runs until September 20th. >> >> >> *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to this draft, to ensure that IPR has been disclosed in >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >> and 5378 for more details). >> >> =3D=3D> *If you are listed as a document author or contributor* please >> respond to this email whether or not you are aware of any relevant IPR. >> The draft will not be adopted until a response has been received from >> each author and contributor. >> >> If you are on the L3VPN WG mailing list but are not listed as an author >> or contributor, then please explicitly respond only if you are aware of >> any IPR that has not yet been disclosed in conformance with IETF rules. >> >> Thank you, >> >> Martin & Thomas >> l3vpn chairs >> >> [1] http://tools.ietf.org/html/draft-zzhang-l2l3-vpn-mcast-mib-00 >>=20 >>_________________________________________________________________________ >>________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >>confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >>ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >>information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >>delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been modified, changed or falsified. >> Thank you. >> > > From ss2539@att.com Wed Oct 9 07:21:13 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDDE21E809C for ; Wed, 9 Oct 2013 07:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f31ugZUcT9N7 for ; Wed, 9 Oct 2013 07:21:07 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAE221E805F for ; Wed, 9 Oct 2013 07:21:06 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 25665525.50bd7940.654451.00-529.1699878.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Oct 2013 14:21:06 +0000 (UTC) X-MXL-Hash: 5255665275013757-6619cd7613ce55c91cc8e9f98edc32b4f0a60ccb Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e4665525.0.654425.00-473.1699791.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Oct 2013 14:21:03 +0000 (UTC) X-MXL-Hash: 5255664f27ddb5d1-f9055366ed6e37392a98e6e922bb7be82d4fae19 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r99EL1tZ019169; Wed, 9 Oct 2013 10:21:01 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r99EKscJ019115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Oct 2013 10:20:57 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 9 Oct 2013 14:20:45 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0158.001; Wed, 9 Oct 2013 10:20:44 -0400 From: "SAAD, SAMIR S" To: "l3vpn@ietf.org" Subject: RE: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOwOa+HMwDeHRT6UuSXHzX19ilcZnsc0pw Date: Wed, 9 Oct 2013 14:20:43 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA0B4AA9DF@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> In-Reply-To: <524E8E94.8040400@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.113.220] Content-Type: multipart/alternative; boundary="_000_438B11A5EC21D347A63ACB77E58C78BA0B4AA9DFMISOUT7MSGUSR9N_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=arcF/1lV c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=X6YCEIPal0cA:10 a=7VeKEW76uU8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=TcVmvIbfN] X-AnalysisOut: [iMA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=N_kDzBCTD4Llzup] X-AnalysisOut: [EN2wA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA] X-AnalysisOut: [:10 a=egRO8Zjk8ZETddKU:21 a=MoyUHhFiMldeq1QG:21 a=_W_S_7Ve] X-AnalysisOut: [coQA:10 a=frz4AuCg-hUA:10 a=-vGNmeTkztnjLAhe:21 a=BReFD_8o] X-AnalysisOut: [t0mm_H2w:21 a=mX6-xxxN9no6c23H:21] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:21:13 -0000 X-List-Received-Date: Wed, 09 Oct 2013 14:21:13 -0000 --_000_438B11A5EC21D347A63ACB77E58C78BA0B4AA9DFMISOUT7MSGUSR9N_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBmb3IgYWRvcHRpb24NCg0KU2FtaXIgU2FhZA0KQVQmVCBMYWJzDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiBWaWdvdXJldXgNClNl bnQ6IEZyaWRheSwgT2N0b2JlciAwNCwgMjAxMyA1OjQ3IEFNDQpUbzogbDN2cG5AaWV0Zi5vcmcN ClN1YmplY3Q6IEhlYWRzLXVwIFtSZTogUG9sbCBmb3IgYWRvcHRpb246IGRyYWZ0LXp6aGFuZy1s MmwzLXZwbi1tY2FzdC1taWJdDQoNCkFsbCwNCg0Kd2UgaGF2ZSBub3Qgc2VlbiBhIGxvdCBvZiBy ZWFjdGlvbiB0byB0aGlzIGFkb3B0aW9uIHBvbGwuIFdlJ2QgbGlrZSB0bw0KZ2l2ZSBpdCBhIHNl Y29uZCB0cnkuDQoNClBsZWFzZSBleHByZXNzIHlvdXIgb3BpbmlvbiAoaW4gZmF2b3VyIG9yIG9w cG9zZWQgdG8pLg0KDQpFeHRlbnNpb24gb2YgdGhlIHBvbGwgcnVucyB1bnRpbCBPY3QgMTF0aC4N Cg0KTWFydGluDQooZm9yIHRoZSBMM1ZQTiBjby1jaGFpcnMpDQoNCkxlIDA1LzA5LzIwMTMgMTY6 NDAsIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPG1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNv bT4gYSDDqWNyaXQgOg0KPiBIZWxsbyB3b3JraW5nIGdyb3VwLA0KPg0KPiBUaGlzIGVtYWlsIHN0 YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gcG9zc2libGUgYWRvcHRpb24gb2YNCj4gZHJhZnQtenpo YW5nLWwybDMtdnBuLW1jYXN0LW1pYi0wMCBbMV0gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uDQo+ DQo+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3Vw cG9ydCBhZG9wdGlvbiBvcg0KPiBub3QgKGluIHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBz dGF0ZSB0aGUgcmVhc29ucykuDQo+DQo+ICoqKiBOb3RlIHRoYXQgd2hhdCBpcyBwcm9wb3NlZCBp cyB0aGF0IHRoaXMgZG9jdW1lbnQgYmVjb21lcyBhIGNvbW1vbg0KPiBmb3VuZGF0aW9uIGZvciB0 aGUgYWxyZWFkeSBhZG9wdGVkIEwzVlBOIG11bHRpY2FzdCBNSUINCj4gKGRyYWZ0LWlldGYtbDN2 cG4tbXZwbi1taWIpIGFuZCBmb3IgYW4gTDJWUE4gbXVsdGljYXN0IE1JQi4gSGVuY2UsIHRoZQ0K PiBMMlZQTiB3aWxsIGJlIG5vdGljZWQgYW5kIGFza2VkIGZvciBmZWVkYmFjayBvbiB0aGUgYWRv cHRpb24gb2YgdGhpcw0KPiBkb2N1bWVudC4gKioqDQo+DQo+IFRoaXMgcG9sbCBydW5zIHVudGls IFNlcHRlbWJlciAyMHRoLg0KPg0KPg0KPiAqQ29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBw b2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0DQo+IGFwcGxpZXMgdG8gdGhpcyBk cmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbg0KPiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkNCj4gYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo+DQo+ID09PiAqSWYgeW91IGFyZSBsaXN0ZWQgYXMg YSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IqIHBsZWFzZQ0KPiByZXNwb25kIHRvIHRo aXMgZW1haWwgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBS Lg0KPiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBi ZWVuIHJlY2VpdmVkIGZyb20NCj4gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KPg0KPiBJ ZiB5b3UgYXJlIG9uIHRoZSBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVk IGFzIGFuIGF1dGhvcg0KPiBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSBy ZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZg0KPiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5 ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPg0KPiBU aGFuayB5b3UsDQo+DQo+IE1hcnRpbiAmIFRob21hcw0KPiBsM3ZwbiBjaGFpcnMNCj4NCj4gWzFd IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1t aWItMDANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPg0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPg0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiB0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91 Lg0KPg0KDQo= --_000_438B11A5EC21D347A63ACB77E58C78BA0B4AA9DFMISOUT7MSGUSR9N_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2Pjxmb250IGNvbG9yPSJibHVlIj48Yj5TdXBwb3J0IGZv ciBhZG9wdGlvbjwvYj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSJibHVlIj4mbmJz cDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSJibHVlIj48Yj5TYW1pciBTYWFkPC9i PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9ImJsdWUiPjxiPkFUJmFtcDtUIExhYnM8 L2I+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQ7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCg0KRnJvbTogbDN2cG4tYm91bmNl c0BpZXRmLm9yZyBbPGEgaHJlZj0ibWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcnRpbiBWaWdvdXJl dXg8YnI+DQoNClNlbnQ6IEZyaWRheSwgT2N0b2JlciAwNCwgMjAxMyA1OjQ3IEFNPGJyPg0KDQpU bzogbDN2cG5AaWV0Zi5vcmc8YnI+DQoNClN1YmplY3Q6IEhlYWRzLXVwIFtSZTogUG9sbCBmb3Ig YWRvcHRpb246IGRyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1taWJdPC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMXB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+QWxsLDwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTFwdDsiPndlIGhhdmUgbm90IHNlZW4gYSBsb3Qgb2YgcmVhY3Rpb24gdG8gdGhpcyBhZG9wdGlv biBwb2xsLiBXZSdkIGxpa2UgdG8gPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Z2l2ZSBp dCBhIHNlY29uZCB0cnkuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jm5ic3A7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+UGxlYXNlIGV4cHJlc3MgeW91ciBvcGluaW9uIChpbiBm YXZvdXIgb3Igb3Bwb3NlZCB0bykuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+RXh0ZW5zaW9uIG9mIHRoZSBwb2xsIHJ1bnMg dW50aWwgT2N0IDExdGguPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jm5ic3A7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+TWFydGluPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0 OyI+KGZvciB0aGUgTDNWUE4gY28tY2hhaXJzKTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPkxlIDA1LzA5LzIwMTMgMTY6NDAs IDxhIGhyZWY9Im1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9y YW5nZS5jb208L2E+IGEgw6ljcml0IDo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7 IEhlbGxvIHdvcmtpbmcgZ3JvdXAsPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0Ozwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgVGhpcyBlbWFpbCBzdGFydHMgYSB0d28t d2VlayBwb2xsIG9uIHBvc3NpYmxlIGFkb3B0aW9uIG9mPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MXB0OyI+Jmd0OyBkcmFmdC16emhhbmctbDJsMy12cG4tbWNhc3QtbWliLTAwIFsxXSBhcyBhIHdv cmtpbmcgZ3JvdXAgaXRlbS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyBQbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUg bGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3I8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExcHQ7Ij4mZ3Q7IG5vdCAoaW4gdGhlIGxhdGVyIGNhc2UsIHBsZWFzZSBhbHNvIHN0 YXRlIHRoZSByZWFzb25zKS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyAqKiogTm90ZSB0aGF0IHdoYXQgaXMgcHJvcG9z ZWQgaXMgdGhhdCB0aGlzIGRvY3VtZW50IGJlY29tZXMgYSBjb21tb248L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExcHQ7Ij4mZ3Q7IGZvdW5kYXRpb24gZm9yIHRoZSBhbHJlYWR5IGFkb3B0ZWQgTDNW UE4gbXVsdGljYXN0IE1JQjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgKGRyYWZ0 LWlldGYtbDN2cG4tbXZwbi1taWIpIGFuZCBmb3IgYW4gTDJWUE4gbXVsdGljYXN0IE1JQi4gSGVu Y2UsIHRoZTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgTDJWUE4gd2lsbCBiZSBu b3RpY2VkIGFuZCBhc2tlZCBmb3IgZmVlZGJhY2sgb24gdGhlIGFkb3B0aW9uIG9mIHRoaXM8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7IGRvY3VtZW50LiAqKio8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQ7Ij4mZ3Q7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyBU aGlzIHBvbGwgcnVucyB1bnRpbCBTZXB0ZW1iZXIgMjB0aC48L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExcHQ7Ij4mZ3Q7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0Ozwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTFwdDsiPiZndDsgKkNvaW5jaWRlbnRhbGx5Kiwgd2UgYXJlIGFsc28gcG9s bGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTFwdDsiPiZndDsgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFz IGJlZW4gZGlzY2xvc2VkIGluPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njk8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMp Ljwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDs8L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExcHQ7Ij4mZ3Q7ID09Jmd0OyAqSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo b3Igb3IgY29udHJpYnV0b3IqIHBsZWFzZTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZn dDsgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2Yg YW55IHJlbGV2YW50IElQUi48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7IFRoZSBk cmFmdCB3aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2 ZWQgZnJvbTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgZWFjaCBhdXRob3IgYW5k IGNvbnRyaWJ1dG9yLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDs8L3NwYW4+PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7IElmIHlvdSBhcmUgb24gdGhlIEwzVlBOIFdHIG1haWxp bmcgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yPC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMXB0OyI+Jmd0OyBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSBy ZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFw dDsiPiZndDsgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZv cm1hbmNlIHdpdGggSUVURiBydWxlcy48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7 PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyBUaGFuayB5b3UsPC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMXB0OyI+Jmd0Ozwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsg TWFydGluICZhbXA7IFRob21hczwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgbDN2 cG4gY2hhaXJzPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIg c2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0Ozwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTFwdDsiPiZndDsgWzFdIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1taWItMDAiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1taWItMDA8L2E+PC9zcGFuPjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MXB0OyI+Jmd0Ozwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFw dDsiPiZndDsgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiw8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7IE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4m Z3Q7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jmd0OyBUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozwvc3Bhbj48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTFwdDsiPiZndDsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+ Jmd0OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7IEFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7 Ij4mZ3Q7IFRoYW5rIHlvdS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mZ3Q7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvc3Bh bj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_438B11A5EC21D347A63ACB77E58C78BA0B4AA9DFMISOUT7MSGUSR9N_-- From rkebler@juniper.net Wed Oct 9 07:58:50 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A5911E80DC for ; Wed, 9 Oct 2013 07:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DGdLCkKop5a for ; Wed, 9 Oct 2013 07:58:45 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id A350711E8199 for ; Wed, 9 Oct 2013 07:58:39 -0700 (PDT) Received: from mail8-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE021.bigfish.com (10.3.207.143) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 14:58:38 +0000 Received: from mail8-am1 (localhost [127.0.0.1]) by mail8-am1-R.bigfish.com (Postfix) with ESMTP id 441791C004F; Wed, 9 Oct 2013 14:58:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI9371Ic89bh542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail8-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rkebler@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(479174003)(199002)(189002)(377454003)(164054003)(13464003)(77982001)(63696002)(54316002)(54356001)(59766001)(33646001)(56776001)(53806001)(85306002)(47446002)(83322001)(19580405001)(19580395003)(81816001)(74502001)(51856001)(76796001)(76786001)(74316001)(46102001)(76576001)(4396001)(49866001)(69226001)(50986001)(47976001)(74876001)(81686001)(47736001)(74366001)(65816001)(76482001)(74706001)(15975445006)(81342001)(81542001)(15202345003)(79102001)(66066001)(80022001)(56816003)(77096001)(74662001)(31966008)(83072001)(80976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB244; H:BL2PR05MB242.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail8-am1 (localhost.localdomain [127.0.0.1]) by mail8-am1 (MessageSwitch) id 1381330716414227_13012; Wed, 9 Oct 2013 14:58:36 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.246]) by mail8-am1.bigfish.com (Postfix) with ESMTP id 57CA04C00F2; Wed, 9 Oct 2013 14:58:36 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 14:58:25 +0000 Received: from BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 14:58:23 +0000 Received: from BL2PR05MB242.namprd05.prod.outlook.com (10.242.198.141) by BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 9 Oct 2013 14:58:21 +0000 Received: from BL2PR05MB242.namprd05.prod.outlook.com ([169.254.9.89]) by BL2PR05MB242.namprd05.prod.outlook.com ([169.254.9.89]) with mapi id 15.00.0785.001; Wed, 9 Oct 2013 14:58:21 +0000 From: Robert Kebler To: Martin Vigoureux , "l3vpn@ietf.org" Subject: [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOxP/+neyv83SMvUyHTFhlN+LqSg== Date: Wed, 9 Oct 2013 14:58:21 +0000 Message-ID: <567fe1005ae34175a11a3d6492742714@BL2PR05MB242.namprd05.prod.outlook.com> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> In-Reply-To: <524E8E94.8040400@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0994F5E0C5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:58:50 -0000 SSBzdXBwb3J0Lg0KDQpUaGFua3MsDQotQm9iDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBNYXJ0aW4gVmlnb3VyZXV4DQo+IFNlbnQ6IEZyaWRh eSwgT2N0b2JlciAwNCwgMjAxMyA1OjQ3IEFNDQo+IFRvOiBsM3ZwbkBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBIZWFkcy11cCBbUmU6IFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16emhhbmctbDJsMy12 cG4tbWNhc3QtDQo+IG1pYl0NCj4gDQo+IEFsbCwNCj4gDQo+IHdlIGhhdmUgbm90IHNlZW4gYSBs b3Qgb2YgcmVhY3Rpb24gdG8gdGhpcyBhZG9wdGlvbiBwb2xsLiBXZSdkIGxpa2UgdG8NCj4gZ2l2 ZSBpdCBhIHNlY29uZCB0cnkuDQo+IA0KPiBQbGVhc2UgZXhwcmVzcyB5b3VyIG9waW5pb24gKGlu IGZhdm91ciBvciBvcHBvc2VkIHRvKS4NCj4gDQo+IEV4dGVuc2lvbiBvZiB0aGUgcG9sbCBydW5z IHVudGlsIE9jdCAxMXRoLg0KPiANCj4gTWFydGluDQo+IChmb3IgdGhlIEwzVlBOIGNvLWNoYWly cykNCj4gDQo+IExlIDA1LzA5LzIwMTMgMTY6NDAsIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tIGEg w6ljcml0IDoNCj4gPiBIZWxsbyB3b3JraW5nIGdyb3VwLA0KPiA+DQo+ID4gVGhpcyBlbWFpbCBz dGFydHMgYSB0d28td2VlayBwb2xsIG9uIHBvc3NpYmxlIGFkb3B0aW9uIG9mDQo+ID4gZHJhZnQt enpoYW5nLWwybDMtdnBuLW1jYXN0LW1pYi0wMCBbMV0gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0u DQo+ID4NCj4gPiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYg eW91IHN1cHBvcnQgYWRvcHRpb24gb3INCj4gPiBub3QgKGluIHRoZSBsYXRlciBjYXNlLCBwbGVh c2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQo+ID4NCj4gPiAqKiogTm90ZSB0aGF0IHdoYXQg aXMgcHJvcG9zZWQgaXMgdGhhdCB0aGlzIGRvY3VtZW50IGJlY29tZXMgYSBjb21tb24NCj4gPiBm b3VuZGF0aW9uIGZvciB0aGUgYWxyZWFkeSBhZG9wdGVkIEwzVlBOIG11bHRpY2FzdCBNSUINCj4g PiAoZHJhZnQtaWV0Zi1sM3Zwbi1tdnBuLW1pYikgYW5kIGZvciBhbiBMMlZQTiBtdWx0aWNhc3Qg TUlCLiBIZW5jZSwNCj4gdGhlDQo+ID4gTDJWUE4gd2lsbCBiZSBub3RpY2VkIGFuZCBhc2tlZCBm b3IgZmVlZGJhY2sgb24gdGhlIGFkb3B0aW9uIG9mIHRoaXMNCj4gPiBkb2N1bWVudC4gKioqDQo+ ID4NCj4gPiBUaGlzIHBvbGwgcnVucyB1bnRpbCBTZXB0ZW1iZXIgMjB0aC4NCj4gPg0KPiA+DQo+ ID4gKkNvaW5jaWRlbnRhbGx5Kiwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9m IGFueSBJUFIgdGhhdA0KPiA+IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQg SVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbg0KPiA+IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OA0KPiBmb3INCj4gPiBtb3Jl IGRldGFpbHMpLg0KPiA+DQo+ID4gPT0+ICpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50 IGF1dGhvciBvciBjb250cmlidXRvciogcGxlYXNlDQo+ID4gcmVzcG9uZCB0byB0aGlzIGVtYWls IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50DQo+IElQUi4NCj4g PiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVu IHJlY2VpdmVkIGZyb20NCj4gPiBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQo+ID4NCj4g PiBJZiB5b3UgYXJlIG9uIHRoZSBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QgYnV0IGFyZSBub3QgbGlz dGVkIGFzIGFuDQo+ID4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNp dGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlDQo+ID4gYXdhcmUgb2YgYW55IElQUiB0aGF0IGhh cyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGgNCj4gSUVURiBydWxl cy4NCj4gPg0KPiA+IFRoYW5rIHlvdSwNCj4gPg0KPiA+IE1hcnRpbiAmIFRob21hcw0KPiA+IGwz dnBuIGNoYWlycw0KPiA+DQo+ID4gWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXp6aGFuZy1sMmwzLXZwbi1tY2FzdC1taWItMDANCj4gPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4N Cj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMNCj4gPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywNCj4gPiBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlDQo+ID4gcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kNCj4gcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPiBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4g YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4g PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXINCj4gYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCj4gPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQo+ID4gVGhhbmsgeW91Lg0KPiA+DQo+IA0KDQo= From jeff.tantsura@ericsson.com Wed Oct 9 08:00:44 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0E821F9BD3 for ; Wed, 9 Oct 2013 08:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThCTl8y6cG+e for ; Wed, 9 Oct 2013 08:00:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4763411E81B6 for ; Wed, 9 Oct 2013 08:00:19 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-7d-52556f769809 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CF.4D.09414.67F65525; Wed, 9 Oct 2013 17:00:06 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 11:00:06 -0400 From: Jeff Tantsura To: Martin Vigoureux , "l3vpn@ietf.org" Subject: Re: [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOxQAV1ogHR4J3zUyVQUiTTQ5wTZnsRC0A Date: Wed, 9 Oct 2013 15:00:05 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748399540E6@eusaamb109.ericsson.se> In-Reply-To: <567fe1005ae34175a11a3d6492742714@BL2PR05MB242.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXSPt25ZfmiQwe/5FhZn5/tb3Nn1hdWB yaP12V5WjyVLfjIFMEVx2aSk5mSWpRbp2yVwZRy/8pGp4Jtgxf6Pe1kaGCfwdTFycEgImEjs fBLVxcgJZIpJXLi3nq2LkYtDSOAoo8Sz55uYIJxljBIXbrWxglSxCRhI/P92nAXEFhGIl7h6 7juYLSzgKjH751ZmiLibxJWmM2wQtpHEpTu7GEFsFgEViaYd/ewgNq+At8Tp/l4wm1MgTGLz 0d9g9YxAV3w/tYYJxGYWEJe49WQ+E8R1AhJL9pxnhrBFJV4+/gd2j6iAnkTbsTPsEHFlie9z HrFA9OpJ3Jg6hQ3CtpZ4MO0y1ExtiWULXzND3CAocXLmE5YJjGKzkKybhaR9FpL2WUjaZyFp X8DIuoqRo7Q4tSw33chgEyMwdo5JsOnuYNzz0vIQozQHi5I475e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGGWkXynt22iZdP3f/y1pWY/bHkYcZ06ax15Sw7nJufhtJF/P7mlxMwsb ea7vevHoO7PWFKMzgvuEFvkUXjv6y4jr9I+P++x4GGJl0xvnXUjKur/l8AJl339cZdbFD1wK j+RlJpl6KZ5W1jgYUvd7fuzb+ZbaWRt4q4Nqvyme97DYz8l0t/dAjBJLcUaioRZzUXEiAIob zuVrAgAA X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:00:44 -0000 Yes/support Cheers, Jeff > >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >> Of Martin Vigoureux >> Sent: Friday, October 04, 2013 5:47 AM >> To: l3vpn@ietf.org >> Subject: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast- >> mib] >>=20 >> All, >>=20 >> we have not seen a lot of reaction to this adoption poll. We'd like to >> give it a second try. >>=20 >> Please express your opinion (in favour or opposed to). >>=20 >> Extension of the poll runs until Oct 11th. >>=20 >> Martin >> (for the L3VPN co-chairs) >>=20 >> Le 05/09/2013 16:40, thomas.morin@orange.com a =E9crit : >> > Hello working group, >> > >> > This email starts a two-week poll on possible adoption of >> > draft-zzhang-l2l3-vpn-mcast-mib-00 [1] as a working group item. >> > >> > Please send comments to the list and state if you support adoption or >> > not (in the later case, please also state the reasons). >> > >> > *** Note that what is proposed is that this document becomes a common >> > foundation for the already adopted L3VPN multicast MIB >> > (draft-ietf-l3vpn-mvpn-mib) and for an L2VPN multicast MIB. Hence, >> the >> > L2VPN will be noticed and asked for feedback on the adoption of this >> > document. *** >> > >> > This poll runs until September 20th. >> > >> > >> > *Coincidentally*, we are also polling for knowledge of any IPR that >> > applies to this draft, to ensure that IPR has been disclosed in >> > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 >> for >> > more details). >> > >> > =3D=3D> *If you are listed as a document author or contributor* please >> > respond to this email whether or not you are aware of any relevant >> IPR. >> > The draft will not be adopted until a response has been received from >> > each author and contributor. >> > >> > If you are on the L3VPN WG mailing list but are not listed as an >> > author or contributor, then please explicitly respond only if you are >> > aware of any IPR that has not yet been disclosed in conformance with >> IETF rules. >> > >> > Thank you, >> > >> > Martin & Thomas >> > l3vpn chairs >> > >> > [1] http://tools.ietf.org/html/draft-zzhang-l2l3-vpn-mcast-mib-00 >> > From wwwrun@rfc-editor.org Wed Oct 9 09:20:08 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD1B11E81E6; Wed, 9 Oct 2013 09:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6SKTyxB8Mkl; Wed, 9 Oct 2013 09:20:07 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3EA11E81E8; Wed, 9 Oct 2013 09:19:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7495FB1E013; Wed, 9 Oct 2013 09:12:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7024 on Virtual Hub-and-Spoke in BGP/MPLS VPNs From: rfc-editor@rfc-editor.org Message-Id: <20131009161213.7495FB1E013@rfc-editor.org> Date: Wed, 9 Oct 2013 09:12:13 -0700 (PDT) Cc: drafts-update-ref@iana.org, l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:20:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7024 Title: Virtual Hub-and-Spoke in BGP/MPLS VPNs Author: H. Jeng, J. Uttaro, L. Jalil, B. Decraene, Y. Rekhter, R. Aggarwal Status: Standards Track Stream: IETF Date: October 2013 Mailbox: hj2387@att.com, ju1738@att.com, luay.jalil@verizon.com, bruno.decraene@orange.com, yakov@juniper.net, raggarwa_1@yahoo.com Pages: 25 Characters: 62926 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-virtual-hub-08.txt URL: http://www.rfc-editor.org/rfc/rfc7024.txt With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers. This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From lenny@juniper.net Thu Oct 10 07:57:06 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B66811E8189 for ; Thu, 10 Oct 2013 07:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QooASaElTvF0 for ; Thu, 10 Oct 2013 07:57:01 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 49A8421F9C4C for ; Thu, 10 Oct 2013 07:56:50 -0700 (PDT) Received: from mail56-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE006.bigfish.com (10.174.4.69) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 14:56:48 +0000 Received: from mail56-db8 (localhost [127.0.0.1]) by mail56-db8-R.bigfish.com (Postfix) with ESMTP id 78080BC0156; Thu, 10 Oct 2013 14:56:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zzbb2dI98dIc89bhc857hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839hd25hf0ah11b5h121eh1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h16a6h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1fe8h1ff5h20f0h1155h) Received-SPF: pass (mail56-db8: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=lenny@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail56-db8 (localhost.localdomain [127.0.0.1]) by mail56-db8 (MessageSwitch) id 1381417007107691_30196; Thu, 10 Oct 2013 14:56:47 +0000 (UTC) Received: from DB8EHSMHS011.bigfish.com (unknown [10.174.8.227]) by mail56-db8.bigfish.com (Postfix) with ESMTP id 1579C880041; Thu, 10 Oct 2013 14:56:47 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by DB8EHSMHS011.bigfish.com (10.174.4.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 14:56:46 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 07:56:44 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r9AEGZL21549; Thu, 10 Oct 2013 07:16:43 -0700 (PDT) (envelope-from lenny@juniper.net) Received: by eng-mail01.juniper.net (Postfix, from userid 1709) id 27B4D1144F; Thu, 10 Oct 2013 07:16:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 1CCBC11446; Thu, 10 Oct 2013 07:16:30 -0700 (PDT) Date: Thu, 10 Oct 2013 07:16:30 -0700 From: Leonard Giuliano To: Martin Vigoureux Subject: Re: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] In-Reply-To: <524E8E94.8040400@alcatel-lucent.com> Message-ID: <20131010071617.Q98047@eng-mail01.juniper.net> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1138694369-1381414590=:98047" X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:57:06 -0000 --0-1138694369-1381414590=:98047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: QUOTED-PRINTABLE Support On Fri, 4 Oct 2013, Martin Vigoureux wrote: -) All, -)=20 -) we have not seen a lot of reaction to this adoption poll. We'd like to g= ive -) it a second try. -)=20 -) Please express your opinion (in favour or opposed to). -)=20 -) Extension of the poll runs until Oct 11th. -)=20 -) Martin -) (for the L3VPN co-chairs) -)=20 -) Le 05/09/2013 16:40, thomas.morin@orange.com a =C3=A9crit : -) > Hello working group, -) >=20 -) > This email starts a two-week poll on possible adoption of -) > draft-zzhang-l2l3-vpn-mcast-mib-00 [1] as a working group item. -) >=20 -) > Please send comments to the list and state if you support adoption or -) > not (in the later case, please also state the reasons). -) >=20 -) > *** Note that what is proposed is that this document becomes a common -) > foundation for the already adopted L3VPN multicast MIB -) > (draft-ietf-l3vpn-mvpn-mib) and for an L2VPN multicast MIB. Hence, the -) > L2VPN will be noticed and asked for feedback on the adoption of this -) > document. *** -) >=20 -) > This poll runs until September 20th. -) >=20 -) >=20 -) > *Coincidentally*, we are also polling for knowledge of any IPR that -) > applies to this draft, to ensure that IPR has been disclosed in -) > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 -) > and 5378 for more details). -) >=20 -) > =3D=3D> *If you are listed as a document author or contributor* please -) > respond to this email whether or not you are aware of any relevant IPR= =2E -) > The draft will not be adopted until a response has been received from -) > each author and contributor. -) >=20 -) > If you are on the L3VPN WG mailing list but are not listed as an autho= r -) > or contributor, then please explicitly respond only if you are aware o= f -) > any IPR that has not yet been disclosed in conformance with IETF rules= =2E -) >=20 -) > Thank you, -) >=20 -) > Martin & Thomas -) > l3vpn chairs -) >=20 -) > [1] http://tools.ietf.org/html/draft-zzhang-l2l3-vpn-mcast-mib-00 -) > ______________________________________________________________________= ___________________________________________________ -) >=20 -) > Ce message et ses pieces jointes peuvent contenir des informations -) > confidentielles ou privilegiees et ne doivent donc -) > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= recu -) > ce message par erreur, veuillez le signaler -) > a l'expediteur et le detruire ainsi que les pieces jointes. Les messag= es -) > electroniques etant susceptibles d'alteration, -) > Orange decline toute responsabilite si ce message a ete altere, deform= e ou -) > falsifie. Merci. -) >=20 -) > This message and its attachments may contain confidential or privilege= d -) > information that may be protected by law; -) > they should not be distributed, used or copied without authorisation. -) > If you have received this email in error, please notify the sender and -) > delete this message and its attachments. -) > As emails may be altered, Orange is not liable for messages that have = been -) > modified, changed or falsified. -) > Thank you. -) >=20 -)=20 --0-1138694369-1381414590=:98047-- From wang.cui1@zte.com.cn Fri Oct 11 01:24:37 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC57221F8459; Fri, 11 Oct 2013 01:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.197 X-Spam-Level: X-Spam-Status: No, score=-100.197 tagged_above=-999 required=5 tests=[AWL=1.801, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr1PVzw2PwZ7; Fri, 11 Oct 2013 01:24:31 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E00AC21E809C; Fri, 11 Oct 2013 01:24:20 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 63E2212B5AD4; Fri, 11 Oct 2013 16:24:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r9B8NxhC022791; Fri, 11 Oct 2013 16:23:59 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) To: zzhang@juniper.net Subject: RE: New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Fri, 11 Oct 2013 16:23:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-10-11 16:23:53, Serialize complete at 2013-10-11 16:23:53 Content-Type: multipart/alternative; boundary="=_alternative 002E345B48257C01_=" X-MAIL: mse02.zte.com.cn r9B8NxhC022791 Cc: mboned@ietf.org, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 08:24:37 -0000 This is a multipart message in MIME format. --=_alternative 002E345B48257C01_= Content-Type: text/plain; charset="US-ASCII" Hi,Jeffrey Section 3 said: RFC 6514 specifies that MCAST-VPN routes carry a Route Distinguisher (RD). For GTM, it SHOULD be possible to configure an RD that is used only for MCAST-VPN A-D routes for the global table. The RD can be defaulted to a special 64-bit all-zero value (denoted as RD 0:0). This means we can configure the RD when GTM is enable, right? Here is a question: In a large network, there are many different administrators,what if admin1 configures the value 1:1 in his manage area(area1), and admin2 configures the valure 2:2 in another area(area2)? If I miss something please point out.Thanks! BRs Linda Wang > Hi, > > This is an update to draft-zzhang-mboned-mvpn-global-table-mcast-00. > > We have re-homed it to l3vpn, and hopefully addressed most comments > that Eric had. > > Your review and comments are appreciated. > > Thanks. > Jeffrey > > -----Original Message----- > From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org] > Sent: Friday, July 12, 2013 3:55 PM > To: Dante J.Pacella; Lenny Giuliano; Jason Schiller; Lenny Giuliano; > Jeffrey (Zhaohui) Zhang > Subject: New Version Notification for draft-zzhang-l3vpn-mvpn- > global-table-mcast-00.txt > > > A new version of I-D, draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt > has been successfully submitted by Jeffrey Zhang and posted to the > IETF repository. > > Filename: draft-zzhang-l3vpn-mvpn-global-table-mcast > Revision: 00 > Title: Global Table Multicast with BGP-MVPN Procedures > Creation date: 2013-07-12 > Group: Individual Submission > Number of pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-zzhang- > l3vpn-mvpn-global-table-mcast-00.txt > Status: http://datatracker.ietf.org/doc/draft-zzhang-l3vpn- > mvpn-global-table-mcast > Htmlized: http://tools.ietf.org/html/draft-zzhang-l3vpn-mvpn- > global-table-mcast-00 > > > Abstract: > This document describes a way to implement Global Table Multicast, > aka Internet Multicast, using BGP encodings and procedures for MVPN > as specified in [RFC6514]. > > No protocol modification/extension is required. This is purely for > informational and clarifying purposes only. > > > > > The IETF Secretariat > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 002E345B48257C01_= Content-Type: text/html; charset="US-ASCII"
Hi,Jeffrey

  Section 3 said:
   RFC 6514 specifies that MCAST-VPN routes carry a Route Distinguisher
  (RD).  For GTM, it SHOULD be possible to configure an RD that is used
  only for MCAST-VPN A-D routes for the global table.  The RD can be
  defaulted to a special 64-bit all-zero value (denoted as RD 0:0).
 
This means we can configure the RD when GTM is enable, right?
Here is a question: In a large network, there are many different administrators,what if admin1 configures the value 1:1 in his manage area(area1), and admin2 configures the valure 2:2 in another area(area2)?

If I miss something please point out.Thanks!

BRs
Linda Wang





> Hi,
>
> This is an update to draft-zzhang-mboned-mvpn-global-table-mcast-00.
>
> We have re-homed it to l3vpn, and hopefully addressed most comments
> that Eric had.
>
> Your review and comments are appreciated.
>
> Thanks.
> Jeffrey
>
> -----Original Message-----
> From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]
> Sent: Friday, July 12, 2013 3:55 PM
> To: Dante J.Pacella; Lenny Giuliano; Jason Schiller; Lenny Giuliano;
> Jeffrey (Zhaohui) Zhang
> Subject: New Version Notification for draft-zzhang-l3vpn-mvpn-
> global-table-mcast-00.txt
>
>
> A new version of I-D, draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt
> has been successfully submitted by Jeffrey Zhang and posted to the
> IETF repository.
>
> Filename:    draft-zzhang-l3vpn-mvpn-global-table-mcast
> Revision:    00
> Title:       Global Table Multicast with BGP-MVPN Procedures
> Creation date:    2013-07-12
> Group:       Individual Submission
> Number of pages: 14
> URL:             http://www.ietf.org/internet-drafts/draft-zzhang-
> l3vpn-mvpn-global-table-mcast-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-zzhang-l3vpn-
> mvpn-global-table-mcast
> Htmlized:        http://tools.ietf.org/html/draft-zzhang-l3vpn-mvpn-
> global-table-mcast-00
>
>
> Abstract:
>    This document describes a way to implement Global Table Multicast,
>    aka Internet Multicast, using BGP encodings and procedures for MVPN
>    as specified in [RFC6514].
>
>    No protocol modification/extension is required.  This is purely for
>    informational and clarifying purposes only.
>
>                                                                              
>
>
> The IETF Secretariat
>
>
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 002E345B48257C01_=-- From zzhang@juniper.net Fri Oct 11 07:05:08 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ACF21E8239; Fri, 11 Oct 2013 07:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVNb8WVbiYEK; Fri, 11 Oct 2013 07:05:03 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2311E8141; Fri, 11 Oct 2013 07:03:45 -0700 (PDT) Received: from mail101-db8-R.bigfish.com (10.174.8.240) by DB8EHSOBE030.bigfish.com (10.174.4.93) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 14:03:44 +0000 Received: from mail101-db8 (localhost [127.0.0.1]) by mail101-db8-R.bigfish.com (Postfix) with ESMTP id B7AAF240085; Fri, 11 Oct 2013 14:03:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz9371I936eIc85fh103dK542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL6d524h17326ah18c673h1c8fb4h1de097h186068h18de19h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail101-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377424004)(189002)(51704005)(377454003)(13464003)(41574002)(199002)(46102001)(80022001)(81542001)(65816001)(56776001)(80976001)(54316002)(74366001)(56816003)(81342001)(74502001)(81816001)(47446002)(53806001)(54356001)(15975445006)(19580395003)(15202345003)(33646001)(74706001)(66066001)(74662001)(81686001)(74876001)(19580405001)(83322001)(69226001)(85306002)(76786001)(4396001)(59766001)(77982001)(74316001)(19300405004)(76796001)(83072001)(63696002)(77096001)(51856001)(16236675002)(47736001)(49866001)(50986001)(47976001)(18717965001)(31966008)(79102001)(76482001)(76576001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB077; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail101-db8 (localhost.localdomain [127.0.0.1]) by mail101-db8 (MessageSwitch) id 1381500170761509_22722; Fri, 11 Oct 2013 14:02:50 +0000 (UTC) Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.245]) by mail101-db8.bigfish.com (Postfix) with ESMTP id B4F1188004A; Fri, 11 Oct 2013 14:02:50 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 14:02:48 +0000 Received: from BY2PR05MB077.namprd05.prod.outlook.com (10.242.38.11) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 11 Oct 2013 14:02:47 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB077.namprd05.prod.outlook.com (10.242.38.11) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 11 Oct 2013 14:02:43 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.179]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.173]) with mapi id 15.00.0785.001; Fri, 11 Oct 2013 14:02:43 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "wang.cui1@zte.com.cn" Subject: RE: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt Thread-Topic: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt Thread-Index: AQHOxoqNBqBW1TxfPE2/cDOKCCsJ/g== Date: Fri, 11 Oct 2013 14:02:42 +0000 Message-ID: <4832730c91be489281cb9b44941b45dd@BY2PR05MB079.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0996D1900D Content-Type: multipart/alternative; boundary="_000_4832730c91be489281cb9b44941b45ddBY2PR05MB079namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mboned@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 14:05:08 -0000 --_000_4832730c91be489281cb9b44941b45ddBY2PR05MB079namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, Base MVPN protocol allows to have different RDs and same is here. In a newer revision of the draft (to be submitted), we have actually remove= d that wording, because while it is ok to use non-zero RDs it does not add = any obvious value. The original text was to show that existing MVPN procedu= res can be used as is (well, with some minor excepts that were spelled out)= . Thanks. Jeffrey From: wang.cui1@zte.com.cn [mailto:wang.cui1@zte.com.cn] Sent: Friday, October 11, 2013 4:24 AM To: Jeffrey (Zhaohui) Zhang Cc: mboned@ietf.org; l3vpn@ietf.org Subject: Re: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-= global-table-mcast-00.txt Hi,Jeffrey Section 3 said: RFC 6514 specifies that MCAST-VPN routes carry a Route Distinguisher (RD). For GTM, it SHOULD be possible to configure an RD that is used only for MCAST-VPN A-D routes for the global table. The RD can be defaulted to a special 64-bit all-zero value (denoted as RD 0:0). This means we can configure the RD when GTM is enable, right? Here is a question: In a large network, there are many different administra= tors,what if admin1 configures the value 1:1 in his manage area(area1), and= admin2 configures the valure 2:2 in another area(area2)? If I miss something please point out.Thanks! BRs Linda Wang > Hi, > > This is an update to draft-zzhang-mboned-mvpn-global-table-mcast-00. > > We have re-homed it to l3vpn, and hopefully addressed most comments > that Eric had. > > Your review and comments are appreciated. > > Thanks. > Jeffrey > > -----Original Message----- > From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org] > Sent: Friday, July 12, 2013 3:55 PM > To: Dante J.Pacella; Lenny Giuliano; Jason Schiller; Lenny Giuliano; > Jeffrey (Zhaohui) Zhang > Subject: New Version Notification for draft-zzhang-l3vpn-mvpn- > global-table-mcast-00.txt > > > A new version of I-D, draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt > has been successfully submitted by Jeffrey Zhang and posted to the > IETF repository. > > Filename: draft-zzhang-l3vpn-mvpn-global-table-mcast > Revision: 00 > Title: Global Table Multicast with BGP-MVPN Procedures > Creation date: 2013-07-12 > Group: Individual Submission > Number of pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-zzhang- > l3vpn-mvpn-global-table-mcast-00.txt > Status: http://datatracker.ietf.org/doc/draft-zzhang-l3vpn- > mvpn-global-table-mcast > Htmlized: http://tools.ietf.org/html/draft-zzhang-l3vpn-mvpn- > global-table-mcast-00 > > > Abstract: > This document describes a way to implement Global Table Multicast, > aka Internet Multicast, using BGP encodings and procedures for MVPN > as specified in [RFC6514]. > > No protocol modification/extension is required. This is purely for > informational and clarifying purposes only. > > > > > The IETF Secretariat > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an in= tended recipient, any disclosure, reproduction, distribution or other disse= mination or use of the information contained is strictly prohibited. If yo= u have received this mail in error, please delete it and notify us immediat= ely. --_000_4832730c91be489281cb9b44941b45ddBY2PR05MB079namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,<= /p>

 <= /p>

Base MVPN protocol allows= to have different RDs and same is here.

In a newer revision of th= e draft (to be submitted), we have actually removed that wording, because w= hile it is ok to use non-zero RDs it does not add any obvious value. The original text was to show that existing MVPN procedures can be = used as is (well, with some minor excepts that were spelled out).

 <= /p>

Thanks.=

Jeffrey=

 

From: wang.cui= 1@zte.com.cn [mailto:wang.cui1@zte.com.cn]
Sent: Friday, October 11, 2013 4:24 AM
To: Jeffrey (Zhaohui) Zhang
Cc: mboned@ietf.org; l3vpn@ietf.org
Subject: Re: [MBONED] New Version Notification for draft-zzhang-l3vp= n-mvpn-global-table-mcast-00.txt

 


Hi,J= effrey

&nbs= p; Section 3 said:

   RFC 6514 specifies that MCAST-VPN routes carry a = Route Distinguisher
  (RD).  For GTM, it SHOULD be possible to configure an RD that i= s used
  only for MCAST-VPN A-D routes for the global table.  The RD can= be
  defaulted to a special 64-bit all-zero value (denoted as RD 0:0).  
This= means we can configure the RD when GTM is enable, right?
Here= is a question: In a large network, there are many different administrators= ,what if admin1 configures the value 1:1 in his manage area(area1), and adm= in2 configures the valure 2:2 in another area(area2)?

If I= miss something please point out.Thanks!

BRs<= /span>
Lind= a Wang





> Hi,
>
> This is an update to draft-zzhang-mboned-mvpn-global-table-mcast-0= 0.
>
> We have re-homed it to l3vpn, and hopefully addressed most comment= s
> that Eric had.
>
> Your review and comments are appreciated.
>
> Thanks.
> Jeffrey
>
> -----Original Message-----
> From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.= org]
> Sent: Friday, July 12, 2013 3:55 PM
> To: Dante J.Pacella; Lenny Giuliano; Jason Schiller; Lenny Giulian= o;
> Jeffrey (Zhaohui) Zhang
> Subject: New Version Notification for draft-zzhang-l3vpn-mvpn-
> global-table-mcast-00.txt
>
>
> A new version of I-D, draft-zzhang-l3vpn-mvpn-global-table-mcast-0= 0.txt
> has been successfully submitted by Jeffrey Zhang and posted to the=
> IETF repository.
>
> Filename:    draft-zzhang-l3vpn-mvpn-global-table-mcast<= /tt>
> Revision:    00
> Title:       Global Table Multicast with BGP-MVPN P= rocedures
> Creation date:    2013-07-12
> Group:       Individual Submission
> Number of pages: 14
> URL:             http://www.ietf.org/internet-drafts/draft-zzhang-
> l3vpn-mvpn-global-table-mcast-00.txt
> Status:          http://datatracker.ietf.org/doc/dra= ft-zzhang-l3vpn-
> mvpn-global-table-mcast
> Htmlized:        http://tools.ietf.org/html/draft-zzhang-= l3vpn-mvpn-
> global-table-mcast-00
>
>
> Abstract:
>    This document describes a way to implement Global Tab= le Multicast,
>    aka Internet Multicast, using BGP encodings and proce= dures for MVPN
>    as specified in [RFC6514].
>
>    No protocol modification/extension is required.  = ;This is purely for
>    informational and clarifying purposes only.
>
>                   &nb= sp;                     &= nbsp;                    =                
>
>
> The IETF Secretariat
>
>
> 

 
-------------------------------------------=
-------------
ZTE Information Security Notice: The inform=
ation contained in this mail (and any attachment transmitted herewith) is p=
rivileged and confidential and is intended for the exclusive use of the add=
ressee(s).  If you are not an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or use of the information con=
tained is strictly prohibited.  If you have received this mail in erro=
r, please delete it and notify us immediately.
 

 

--_000_4832730c91be489281cb9b44941b45ddBY2PR05MB079namprd05pro_-- From simon.challinor@bt.com Fri Oct 11 09:36:58 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A5921E81E3 for ; Fri, 11 Oct 2013 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgVA2T6KDZIl for ; Fri, 11 Oct 2013 09:36:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 65DFD21E81F1 for ; Fri, 11 Oct 2013 09:36:30 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 11 Oct 2013 17:36:26 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.25]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 11 Oct 2013 17:36:26 +0100 From: To: Date: Fri, 11 Oct 2013 17:36:25 +0100 Subject: Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib Thread-Topic: Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib Thread-Index: Ac7GoAcFseXuMM4tReSxDneZaulpZg== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_B94F2EB812CACC4AA3F4D7E73918A5D95D228FA2C2EMV65UKRDdoma_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 11 Oct 2013 09:58:08 -0700 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:38:56 -0000 --_000_B94F2EB812CACC4AA3F4D7E73918A5D95D228FA2C2EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this draft. Simon Challinor IP&Data Architect BT Technology, Service and Operations Desk: +44 (0)1473 629383 Mobile: +44 (0)7917 024849 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 --_000_B94F2EB812CACC4AA3F4D7E73918A5D95D228FA2C2EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support this draft.
Simon Challinor
IP&Data Architect
BT Technology, Service and Operations
Desk: +44 (0)1473 629383  Mobile: +44 (0)7917 024849

This email contains BT informat= ion, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not = the intended
recipient, note that disclosing, copying, distributing or using this inform= ation
is prohibited. If you've received this email in error, please let me know i= mmediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.

British Telecommunica= tions plc
Registered office: 81= Newgate Street London EC1A 7AJ
Registered in England= no. 1800000 =
 
 
 
 --_000_B94F2EB812CACC4AA3F4D7E73918A5D95D228FA2C2EMV65UKRDdoma_-- From internet-drafts@ietf.org Fri Oct 11 13:42:37 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C918F21F9CF3; Fri, 11 Oct 2013 13:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OKZYDXhfJ6L; Fri, 11 Oct 2013 13:42:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0027511E80E8; Fri, 11 Oct 2013 13:42:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-mib-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131011204235.15979.76197.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 13:42:35 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 20:42:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : MPLS/BGP Layer 3 VPN Multicast Management Information Ba= se Author(s) : Saud Asif Andy Green Sameer Gulrajani Pradeep G. Jain Jeffrey (Zhaohui) Zhang Filename : draft-ietf-l3vpn-mvpn-mib-04.txt Pages : 32 Date : 2013-10-11 Abstract: This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor multicast in MPLS/BGP-based Layer-3 VPN (MVPN) on an MVPN router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-mvpn-mib-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rraszuk@gmail.com Fri Oct 11 14:18:17 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6250321F9B92 for ; Fri, 11 Oct 2013 14:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdzHeozcZ5X2 for ; Fri, 11 Oct 2013 14:18:16 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BB41521F9D23 for ; Fri, 11 Oct 2013 14:18:15 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so9688445ief.15 for ; Fri, 11 Oct 2013 14:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RKPVebrUAV1PRQR9NB+E9U5fcXwvmPlvt34mJVej/fY=; b=HFiOu1T4pd9emqVz7oM9hvEJz08zMIcMtxwnkxGlkamlCn7YYCuxBHQTtbIih7+/8d rbmxkOR78knLfHAWFAue9EnyowH0bQN473OjjqagXv1EM8QI001PqIiBJe4uddUIwnSf 9R5cq+kQPij/5i++oxxpEzExCWJXw+phAQ13fpIA3pe7gRzSn+EXC/qRqH8ySqNWvatB M1TsDAB3XvxzWHusPYt1BHAOrNN7tQoGE0pjjHoT2d/qiSE5nBc7Znn7FYPNClXin1yK fsw/39ULk+u8KrrbnxeOagZg9x0QfckWrEhJcU6rBolmeSk0rUTNWJaBhVYCqBVDw89o JfjQ== MIME-Version: 1.0 X-Received: by 10.50.107.102 with SMTP id hb6mr4276508igb.55.1381526288519; Fri, 11 Oct 2013 14:18:08 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 11 Oct 2013 14:18:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Oct 2013 23:18:08 +0200 X-Google-Sender-Auth: u2j9xLwtIPBc4wGbrZfYuCyuiXE Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Ronald Bonica Content-Type: text/plain; charset=ISO-8859-1 Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 21:18:17 -0000 Hi Ron, I have reviewed the proposed draft. I think it is very well written document. Maybe this is just my own observation, but during digesting it I have struggled to understand why authors have decided to extend ORF rather then update RFC4684. Maybe if the draft will progress a bit of clarification would be nice as in general 4684 is preferred over ORF in VPN context. But this is sort of minor detail. Much more important is to observe that major advantage of RFC7024 is that by default it works with currently deployed PEs and RRs. This draft however requires upgrade of both spoke PEs as well as RRs serving such spoke PEs. Such upgrade may or may not be always feasible. It appears however that there is possibility of addressing the problem with alternative approach fully controlled by the V-hub. Such V-hub alone is capable of observing the flow patterns among it's V-spokes and based on the set threshold locally injecting into any VPN optimal route for heavy flows with RT-RED-FROM-HUB extended community. That as such will allow for optimal data flows within given VPN bypassing the V-hub. The question arises how would we remove such more specific routes from V-spokes when the flow terminates ... while there is number of possible solutions in this space - simplest seems to be time driven. V-hub could start timer of x minutes (configurable) after injecting more specific and upon expiration withdraw such more specific routes. At most if the flow still continues customer VPN would experience transient sub-optimality - no drops and no significant impact as V-hub would re-advertise the active more specifics again. The major advantage of such proposal is that it is readily deployable into any of the today's L3VPN network by only activating V-hub which could be a single upgraded PE or new box in the network. Moreover this procedure does not require any protocol extension nor additional features like new RT insertion on the VPNv4/v6 route reflectors which your draft requires. I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will evaluate such alternative. Best regards, R. On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica wrote: > > Please review this draft and provide comments. > > Ron > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, September 16, 2013 10:15 AM >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >> Subject: New Version Notification for draft-bonica-l3vpn-orf-covering- >> prefixes-00.txt >> >> >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes-00.txt >> has been successfully submitted by Huajin Jeng and posted to the IETF >> repository. >> >> Filename: draft-bonica-l3vpn-orf-covering-prefixes >> Revision: 00 >> Title: Covering Prefixes Outbound Route Filter for BGP-4 >> Creation date: 2013-09-15 >> Group: Individual Submission >> Number of pages: 10 >> URL: http://www.ietf.org/internet-drafts/draft-bonica- >> l3vpn-orf-covering-prefixes-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >> orf-covering-prefixes >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >> covering-prefixes-00 >> >> >> Abstract: >> This document defines a new ORF-type, called the "Covering Prefixes >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual >> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN >> environments. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> > From lucy.yong@huawei.com Sun Oct 13 18:52:05 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86EC11E81CD for ; Sun, 13 Oct 2013 18:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmvJ-fCg0ujP for ; Sun, 13 Oct 2013 18:51:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA8AE11E816F for ; Sun, 13 Oct 2013 18:51:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZB12555; Mon, 14 Oct 2013 01:51:42 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 02:50:55 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 02:51:40 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Sun, 13 Oct 2013 18:51:33 -0700 From: Lucy yong To: Robert Raszuk , Ronald Bonica Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOsucoCsp4xS6OLEOK6Acq9aZqT5nIaNjggCg1dQCAAlfasA== Date: Mon, 14 Oct 2013 01:51:28 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D54CB@dfweml509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 01:52:06 -0000 Hi Robert, I am not a co-author of the draft but am interested in the problem. In fact= , the problem was discussed year ago in nvo3 mailing list. BGP RTs are used for controlling route distribution and BGP route distribut= ion specified in rfc4364 is the pure "push" mechanism. This draft intention= is to implement a "pull" capability in BGP/VPN. The solution you proposed = can solve the v-spoke/v-hub use case described in the draft but, IMHO, it s= till uses "push" mode, i.e. under v-hub solo control. So it may not apply t= o other "pull" scenarios. I am not sure yet that implementing "pull" capability by BGP RT and rfc4684= is the right way and like to hear your opinion on it. IMO: ORF has the nat= ive "pull" characteristic. Regards, Lucy -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of R= obert Raszuk Sent: Friday, October 11, 2013 4:18 PM To: Ronald Bonica Cc: l3vpn@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-coveri= ng-prefixes-00.txt Hi Ron, I have reviewed the proposed draft. I think it is very well written documen= t. Maybe this is just my own observation, but during digesting it I have st= ruggled to understand why authors have decided to extend ORF rather then up= date RFC4684. Maybe if the draft will progress a bit of clarification would= be nice as in general 4684 is preferred over ORF in VPN context. But this is sort of minor detail. Much more important is to observe that ma= jor advantage of RFC7024 is that by default it works with currently deploye= d PEs and RRs. This draft however requires upgrade of both spoke PEs as wel= l as RRs serving such spoke PEs. Such upgrade may or may not be always feas= ible. It appears however that there is possibility of addressing the problem with= alternative approach fully controlled by the V-hub. Such V-hub alone is ca= pable of observing the flow patterns among it's V-spokes and based on the s= et threshold locally injecting into any VPN optimal route for heavy flows w= ith RT-RED-FROM-HUB extended community. That as such will allow for optimal= data flows within given VPN bypassing the V-hub. The question arises how would we remove such more specific routes from V-sp= okes when the flow terminates ... while there is number of possible solutio= ns in this space - simplest seems to be time driven. V-hub could start timer of x minutes (configurable) after injecting more sp= ecific and upon expiration withdraw such more specific routes. At most if the flow still continues customer VPN would experience transient= sub-optimality - no drops and no significant impact as V-hub would re-adve= rtise the active more specifics again. The major advantage of such proposal is that it is readily deployable into = any of the today's L3VPN network by only activating V-hub which could be a = single upgraded PE or new box in the network. Moreover this procedure does = not require any protocol extension nor additional features like new RT inse= rtion on the VPNv4/v6 route reflectors which your draft requires. I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will evaluate su= ch alternative. Best regards, R. On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica wrote: > > Please review this draft and provide comments. > > Ron > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, September 16, 2013 10:15 AM >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >> Subject: New Version Notification for=20 >> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >> >> >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes-00.txt >> has been successfully submitted by Huajin Jeng and posted to the IETF=20 >> repository. >> >> Filename: draft-bonica-l3vpn-orf-covering-prefixes >> Revision: 00 >> Title: Covering Prefixes Outbound Route Filter for BGP-4 >> Creation date: 2013-09-15 >> Group: Individual Submission >> Number of pages: 10 >> URL: http://www.ietf.org/internet-drafts/draft-bonica- >> l3vpn-orf-covering-prefixes-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >> orf-covering-prefixes >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >> covering-prefixes-00 >> >> >> Abstract: >> This document defines a new ORF-type, called the "Covering Prefixes >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual >> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN >> environments. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >> >> The IETF Secretariat >> >> > From rraszuk@gmail.com Mon Oct 14 01:27:42 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC28921E80F0 for ; Mon, 14 Oct 2013 01:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izxEMVK8npAa for ; Mon, 14 Oct 2013 01:27:40 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A791921E80F3 for ; Mon, 14 Oct 2013 01:27:31 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so10007353iec.6 for ; Mon, 14 Oct 2013 01:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vRSY43d437N+jOggSg6chMZv4TNbwdH6kc3jSUmnH3E=; b=SD+jq4pY5Hn+v2JFYRG4j+4DRUYhBQAiSLlPYNFpPu0XGsDu5hIRM4EziYHp7LH/tE 6c+rhyoo2FjHdENETKJvTqTr6QQDd9zujH87lmLI+o39iCNzeuYCwspKWeCha6A4kiyY iva93KBKGnSVmQ5yllj6GKS/w2W/OhZ9s60rXk5Yk6czuvTYXkIn0e4deB/mWeCiEpna /V2afRQYoVL5UlUZ1tTjMUNWUlQPtFQbIsUaaqhAs/cDQ98LoUDcCRJBQNPo3ApGpALL uki2Q4gQkGOxv1tJzPB5pY0cegWBimyv1J05IBGJ+LWGqIDoDis6RXZaZDhO8UZi7H+b DFjg== MIME-Version: 1.0 X-Received: by 10.50.107.102 with SMTP id hb6mr11958639igb.55.1381739249486; Mon, 14 Oct 2013 01:27:29 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Mon, 14 Oct 2013 01:27:29 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D54CB@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452D54CB@dfweml509-mbx.china.huawei.com> Date: Mon, 14 Oct 2013 10:27:29 +0200 X-Google-Sender-Auth: L7LirhJe4MwCg3ezDtNT_Es9uNE Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:27:42 -0000 Hi Lucy, "Pull" model is well described in RFC4684 and ORF brings zero advantage over it as far as RT based trigger. The approach the above draft took requires more then just RT based "pull" hence the dillema - to extend RFC4684 or run over ORF. Authors took the latter while one may argue for the former. The solution I proposed however (and now reading my l3vpn backlog I see that also Xuxiaohu mentioned however without discussing state removal) has major advantage that it works fine without any protocol extension and upgrade of existing boxes. It is much simpler one. The practical difference of my proposal vs draft-bonica-l3vpn-orf-covering-prefixes is that in my scheme prefixes of significant flows will be distributed to all v-spokes vs only those which indicate the need for them like described in the draft. That to me seems as acceptable tradeoff avoiding added complexity and deployment obstacles. Best regards, R. On Mon, Oct 14, 2013 at 3:51 AM, Lucy yong wrote: > Hi Robert, > > I am not a co-author of the draft but am interested in the problem. In fa= ct, the problem was discussed year ago in nvo3 mailing list. > > BGP RTs are used for controlling route distribution and BGP route distrib= ution specified in rfc4364 is the pure "push" mechanism. This draft intenti= on is to implement a "pull" capability in BGP/VPN. The solution you propose= d can solve the v-spoke/v-hub use case described in the draft but, IMHO, it= still uses "push" mode, i.e. under v-hub solo control. So it may not apply= to other "pull" scenarios. > > I am not sure yet that implementing "pull" capability by BGP RT and rfc46= 84 is the right way and like to hear your opinion on it. IMO: ORF has the n= ative "pull" characteristic. > > Regards, > Lucy > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of= Robert Raszuk > Sent: Friday, October 11, 2013 4:18 PM > To: Ronald Bonica > Cc: l3vpn@ietf.org > Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-cove= ring-prefixes-00.txt > > Hi Ron, > > I have reviewed the proposed draft. I think it is very well written docum= ent. Maybe this is just my own observation, but during digesting it I have = struggled to understand why authors have decided to extend ORF rather then = update RFC4684. Maybe if the draft will progress a bit of clarification wou= ld be nice as in general 4684 is preferred over ORF in VPN context. > > But this is sort of minor detail. Much more important is to observe that = major advantage of RFC7024 is that by default it works with currently deplo= yed PEs and RRs. This draft however requires upgrade of both spoke PEs as w= ell as RRs serving such spoke PEs. Such upgrade may or may not be always fe= asible. > > It appears however that there is possibility of addressing the problem wi= th alternative approach fully controlled by the V-hub. Such V-hub alone is = capable of observing the flow patterns among it's V-spokes and based on the= set threshold locally injecting into any VPN optimal route for heavy flows= with RT-RED-FROM-HUB extended community. That as such will allow for optim= al data flows within given VPN bypassing the V-hub. > > The question arises how would we remove such more specific routes from V-= spokes when the flow terminates ... while there is number of possible solut= ions in this space - simplest seems to be time driven. > V-hub could start timer of x minutes (configurable) after injecting more = specific and upon expiration withdraw such more specific routes. > At most if the flow still continues customer VPN would experience transie= nt sub-optimality - no drops and no significant impact as V-hub would re-ad= vertise the active more specifics again. > > The major advantage of such proposal is that it is readily deployable int= o any of the today's L3VPN network by only activating V-hub which could be = a single upgraded PE or new box in the network. Moreover this procedure doe= s not require any protocol extension nor additional features like new RT in= sertion on the VPNv4/v6 route reflectors which your draft requires. > > I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will evaluate = such alternative. > > Best regards, > R. > > > On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica wrot= e: >> >> Please review this draft and provide comments. >> >> Ron >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, September 16, 2013 10:15 AM >>> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >>> Subject: New Version Notification for >>> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >>> >>> >>> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes-00.txt >>> has been successfully submitted by Huajin Jeng and posted to the IETF >>> repository. >>> >>> Filename: draft-bonica-l3vpn-orf-covering-prefixes >>> Revision: 00 >>> Title: Covering Prefixes Outbound Route Filter for BGP-= 4 >>> Creation date: 2013-09-15 >>> Group: Individual Submission >>> Number of pages: 10 >>> URL: http://www.ietf.org/internet-drafts/draft-bonica- >>> l3vpn-orf-covering-prefixes-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >>> orf-covering-prefixes >>> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >>> covering-prefixes-00 >>> >>> >>> Abstract: >>> This document defines a new ORF-type, called the "Covering Prefixes >>> ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual >>> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN >>> environments. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >> From martin.vigoureux@alcatel-lucent.com Mon Oct 14 04:48:57 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A559E21F97C7 for ; Mon, 14 Oct 2013 04:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cxH39H0YtlV for ; Mon, 14 Oct 2013 04:48:52 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EB2EE21F92B8 for ; Mon, 14 Oct 2013 04:48:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9EBmm2V018132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2013 06:48:49 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9EBmlQQ009722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 13:48:47 +0200 Received: from [172.27.205.168] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Oct 2013 13:48:48 +0200 Message-ID: <525BDA1F.4090807@alcatel-lucent.com> Date: Mon, 14 Oct 2013 13:48:47 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: , "Jeffrey (Zhaohui) Zhang" Subject: Re: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> In-Reply-To: <524E8E94.8040400@alcatel-lucent.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:48:57 -0000 All, there is support for adopting this document. There is no IPR disclosure against this document and the author has indicated not being aware of any relevant IPR relating to it. Jeffrey, please republish as draft-ietf-l3vpn-l2l3-vpn-mcast-mib-00 without any other change than for the file name and date. Thanks Martin, for the L3VPN co-chairs Le 04/10/2013 11:47, Martin Vigoureux a écrit : > All, > > we have not seen a lot of reaction to this adoption poll. We'd like to > give it a second try. > > Please express your opinion (in favour or opposed to). > > Extension of the poll runs until Oct 11th. > > Martin > (for the L3VPN co-chairs) > > Le 05/09/2013 16:40, thomas.morin@orange.com a écrit : >> Hello working group, >> >> This email starts a two-week poll on possible adoption of >> draft-zzhang-l2l3-vpn-mcast-mib-00 [1] as a working group item. >> >> Please send comments to the list and state if you support adoption or >> not (in the later case, please also state the reasons). >> >> *** Note that what is proposed is that this document becomes a common >> foundation for the already adopted L3VPN multicast MIB >> (draft-ietf-l3vpn-mvpn-mib) and for an L2VPN multicast MIB. Hence, the >> L2VPN will be noticed and asked for feedback on the adoption of this >> document. *** >> >> This poll runs until September 20th. >> >> >> *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to this draft, to ensure that IPR has been disclosed in >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >> and 5378 for more details). >> >> ==> *If you are listed as a document author or contributor* please >> respond to this email whether or not you are aware of any relevant IPR. >> The draft will not be adopted until a response has been received from >> each author and contributor. >> >> If you are on the L3VPN WG mailing list but are not listed as an author >> or contributor, then please explicitly respond only if you are aware of >> any IPR that has not yet been disclosed in conformance with IETF rules. >> >> Thank you, >> >> Martin & Thomas >> l3vpn chairs >> >> [1] http://tools.ietf.org/html/draft-zzhang-l2l3-vpn-mcast-mib-00 >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> > > From internet-drafts@ietf.org Mon Oct 14 07:56:16 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A328C21E80AF; Mon, 14 Oct 2013 07:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJpfeLH+k0nm; Mon, 14 Oct 2013 07:56:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8A021E80C1; Mon, 14 Oct 2013 07:56:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-l2l3-vpn-mcast-mib-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014145611.11479.99732.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 07:56:11 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:56:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : L2L3 VPN Multicast MIB Author(s) : Juniper Networks Filename : draft-ietf-l3vpn-l2l3-vpn-mcast-mib-00.txt Pages : 10 Date : 2013-10-14 Abstract: This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects common to both VPLS and VPN Multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-l2l3-vpn-mcast-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-l2l3-vpn-mcast-mib-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zzhang@juniper.net Mon Oct 14 08:01:00 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24421F9C53 for ; Mon, 14 Oct 2013 08:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yqP-SziIC2L for ; Mon, 14 Oct 2013 08:00:53 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFEF21E8186 for ; Mon, 14 Oct 2013 08:00:46 -0700 (PDT) Received: from mail16-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE029.bigfish.com (10.243.66.94) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 15:00:44 +0000 Received: from mail16-co1 (localhost [127.0.0.1]) by mail16-co1-R.bigfish.com (Postfix) with ESMTP id 8A1EE6C01DB; Mon, 14 Oct 2013 15:00:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI9371Ic89bh103dK542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail16-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(479174003)(377454003)(199002)(189002)(41574002)(13464003)(65816001)(63696002)(66066001)(80022001)(81816001)(74706001)(54316002)(76482001)(56776001)(56816003)(81342001)(81542001)(74366001)(15975445006)(53806001)(81686001)(85306002)(54356001)(51856001)(50986001)(59766001)(77982001)(74876001)(46102001)(49866001)(47976001)(47736001)(79102001)(4396001)(31966008)(74662001)(47446002)(74502001)(33646001)(74316001)(80976001)(76576001)(83072001)(83322001)(19580405001)(76786001)(76796001)(19580395003)(77096001)(15202345003)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB079; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail16-co1 (localhost.localdomain [127.0.0.1]) by mail16-co1 (MessageSwitch) id 138176284362994_15297; Mon, 14 Oct 2013 15:00:43 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.229]) by mail16-co1.bigfish.com (Postfix) with ESMTP id 04B9AAC0057; Mon, 14 Oct 2013 15:00:43 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 15:00:42 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 14 Oct 2013 15:00:34 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 14 Oct 2013 15:00:31 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.179]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.173]) with mapi id 15.00.0785.001; Mon, 14 Oct 2013 15:00:31 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Martin Vigoureux , "l3vpn@ietf.org" Subject: RE: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Topic: Heads-up [Re: Poll for adoption: draft-zzhang-l2l3-vpn-mcast-mib] Thread-Index: AQHOyNNq/MYOuH6MTU6MSSHbUm/VOJn0Sfhg Date: Mon, 14 Oct 2013 15:00:30 +0000 Message-ID: <1a37c52e58184fd19bed49d15b1bd5e6@BY2PR05MB079.namprd05.prod.outlook.com> References: <2890_1378392038_522897E6_2890_1207_10_AC1ADC68A92CF94FA8CFCB406C1CBE3D075AD36A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <524E8E94.8040400@alcatel-lucent.com> <525BDA1F.4090807@alcatel-lucent.com> In-Reply-To: <525BDA1F.4090807@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0999136621 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:01:00 -0000 TWFydGluLA0KDQpBIFdHIHZlcnNpb24gLTAwIHdpdGggb25seSBmaWxlL2RhdGUgY2hhbmdlIGhh cyBiZWVuIHBvc3RlZDoNCg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWwzdnBuLWwybDMtdnBuLW1jYXN0LW1pYi0wMC50eHQN ClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWwzdnBuLWwybDMtdnBuLW1jYXN0LW1pYg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWwzdnBuLWwybDMtdnBuLW1jYXN0LW1pYi0wMA0K DQpUaGFua3MhIA0KSmVmZnJleQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IE1hcnRpbiBWaWdvdXJldXggW21haWx0bzptYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVj ZW50LmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE0LCAyMDEzIDc6NDkgQU0NCj4gVG86 IGwzdnBuQGlldGYub3JnOyBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZw0KPiBTdWJqZWN0OiBSZTog SGVhZHMtdXAgW1JlOiBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtenpoYW5nLWwybDMtdnBuLQ0K PiBtY2FzdC1taWJdDQo+IA0KPiBBbGwsDQo+IA0KPiB0aGVyZSBpcyBzdXBwb3J0IGZvciBhZG9w dGluZyB0aGlzIGRvY3VtZW50Lg0KPiBUaGVyZSBpcyBubyBJUFIgZGlzY2xvc3VyZSBhZ2FpbnN0 IHRoaXMgZG9jdW1lbnQgYW5kIHRoZSBhdXRob3IgaGFzDQo+IGluZGljYXRlZCBub3QgYmVpbmcg YXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiByZWxhdGluZyB0byBpdC4NCj4gDQo+IEplZmZyZXks IHBsZWFzZSByZXB1Ymxpc2ggYXMgZHJhZnQtaWV0Zi1sM3Zwbi1sMmwzLXZwbi1tY2FzdC1taWIt MDANCj4gd2l0aG91dCBhbnkgb3RoZXIgY2hhbmdlIHRoYW4gZm9yIHRoZSBmaWxlIG5hbWUgYW5k IGRhdGUuDQo+IA0KPiBUaGFua3MNCj4gDQo+IE1hcnRpbiwgZm9yIHRoZSBMM1ZQTiBjby1jaGFp cnMNCj4gDQo+IExlIDA0LzEwLzIwMTMgMTE6NDcsIE1hcnRpbiBWaWdvdXJldXggYSDDqWNyaXQg Og0KPiA+IEFsbCwNCj4gPg0KPiA+IHdlIGhhdmUgbm90IHNlZW4gYSBsb3Qgb2YgcmVhY3Rpb24g dG8gdGhpcyBhZG9wdGlvbiBwb2xsLiBXZSdkIGxpa2UNCj4gdG8NCj4gPiBnaXZlIGl0IGEgc2Vj b25kIHRyeS4NCj4gPg0KPiA+IFBsZWFzZSBleHByZXNzIHlvdXIgb3BpbmlvbiAoaW4gZmF2b3Vy IG9yIG9wcG9zZWQgdG8pLg0KPiA+DQo+ID4gRXh0ZW5zaW9uIG9mIHRoZSBwb2xsIHJ1bnMgdW50 aWwgT2N0IDExdGguDQo+ID4NCj4gPiBNYXJ0aW4NCj4gPiAoZm9yIHRoZSBMM1ZQTiBjby1jaGFp cnMpDQo+ID4NCj4gPiBMZSAwNS8wOS8yMDEzIDE2OjQwLCB0aG9tYXMubW9yaW5Ab3JhbmdlLmNv bSBhIMOpY3JpdCA6DQo+ID4+IEhlbGxvIHdvcmtpbmcgZ3JvdXAsDQo+ID4+DQo+ID4+IFRoaXMg ZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBwb3NzaWJsZSBhZG9wdGlvbiBvZg0KPiA+ PiBkcmFmdC16emhhbmctbDJsMy12cG4tbWNhc3QtbWliLTAwIFsxXSBhcyBhIHdvcmtpbmcgZ3Jv dXAgaXRlbS4NCj4gPj4NCj4gPj4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5k IHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uDQo+IG9yDQo+ID4+IG5vdCAoaW4gdGhlIGxh dGVyIGNhc2UsIHBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS4NCj4gPj4NCj4gPj4gKioq IE5vdGUgdGhhdCB3aGF0IGlzIHByb3Bvc2VkIGlzIHRoYXQgdGhpcyBkb2N1bWVudCBiZWNvbWVz IGENCj4gY29tbW9uDQo+ID4+IGZvdW5kYXRpb24gZm9yIHRoZSBhbHJlYWR5IGFkb3B0ZWQgTDNW UE4gbXVsdGljYXN0IE1JQg0KPiA+PiAoZHJhZnQtaWV0Zi1sM3Zwbi1tdnBuLW1pYikgYW5kIGZv ciBhbiBMMlZQTiBtdWx0aWNhc3QgTUlCLiBIZW5jZSwNCj4gdGhlDQo+ID4+IEwyVlBOIHdpbGwg YmUgbm90aWNlZCBhbmQgYXNrZWQgZm9yIGZlZWRiYWNrIG9uIHRoZSBhZG9wdGlvbiBvZiB0aGlz DQo+ID4+IGRvY3VtZW50LiAqKioNCj4gPj4NCj4gPj4gVGhpcyBwb2xsIHJ1bnMgdW50aWwgU2Vw dGVtYmVyIDIwdGguDQo+ID4+DQo+ID4+DQo+ID4+ICpDb2luY2lkZW50YWxseSosIHdlIGFyZSBh bHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQNCj4gPj4gYXBwbGllcyB0 byB0aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluDQo+ ID4+IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwg MzY2OQ0KPiA+PiBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCj4gPj4NCj4gPj4gPT0+ICpJ ZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciogcGxl YXNlDQo+ID4+IHJlc3BvbmQgdG8gdGhpcyBlbWFpbCB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3 YXJlIG9mIGFueSByZWxldmFudA0KPiBJUFIuDQo+ID4+IFRoZSBkcmFmdCB3aWxsIG5vdCBiZSBh ZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQNCj4gZnJvbQ0KPiA+PiBl YWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQo+ID4+DQo+ID4+IElmIHlvdSBhcmUgb24gdGhl IEwzVlBOIFdHIG1haWxpbmcgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4NCj4gYXV0aG9y DQo+ID4+IG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25s eSBpZiB5b3UgYXJlIGF3YXJlDQo+IG9mDQo+ID4+IGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBi ZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYNCj4gcnVsZXMuDQo+ID4+DQo+ ID4+IFRoYW5rIHlvdSwNCj4gPj4NCj4gPj4gTWFydGluICYgVGhvbWFzDQo+ID4+IGwzdnBuIGNo YWlycw0KPiA+Pg0KPiA+PiBbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtenpo YW5nLWwybDMtdnBuLW1jYXN0LW1pYi0wMA0KPiA+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pg0KPiA+ Pg0KPiA+PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMNCj4gPj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCj4gPj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMNCj4gYXZleg0KPiA+PiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gPj4gYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzDQo+ID4+ IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwN Cj4gPj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsDQo+ID4+IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+Pg0KPiA+ PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3INCj4gPj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Ow0KPiA+PiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGFuZA0KPiA+PiBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4+IEFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4g aGF2ZQ0KPiA+PiBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPj4gVGhh bmsgeW91Lg0KPiA+Pg0KPiA+DQo+ID4NCj4gDQoNCg== From lucy.yong@huawei.com Mon Oct 14 09:19:48 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E8121F9FA7 for ; Mon, 14 Oct 2013 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wipQ3KywKTN for ; Mon, 14 Oct 2013 09:19:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC7111E8153 for ; Mon, 14 Oct 2013 09:19:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWU44433; Mon, 14 Oct 2013 16:19:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 17:19:01 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 17:19:39 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Mon, 14 Oct 2013 09:19:35 -0700 From: Lucy yong To: Robert Raszuk Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOyLc9W/JQAheSKUGBeIA4HFtwrZn0V+dA Date: Mon, 14 Oct 2013 16:19:34 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D57F2@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452D54CB@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:19:48 -0000 Hi Robert, Thanks. Please see inline. -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Monday, October 14, 2013 3:27 AM To: Lucy yong Cc: Ronald Bonica; l3vpn@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-coveri= ng-prefixes-00.txt Hi Lucy, "Pull" model is well described in RFC4684 and ORF brings zero advantage ove= r it as far as RT based trigger. [Lucy] To me, this "pull" model is quite complex and properly only works in= static way. (I may be wrong) The mechanism requires pre-assigned all the r= oute targets by an administrator. There is no explicit mapping between rout= e target and route prefix. The mapping between route target and route are i= mplicitly done by the mapping between VPN site and route at the site via op= erator configuration of export and import route target on each PE. Thus, im= port Route Target mainly means to accept the route from some VPN sites. The= re is no way for BGP speaker to express interested route to peers and a pee= r only sends the route to the speaker. This is my understanding.=20 The approach the above draft took requires more then just RT based "pull" h= ence the dillema - to extend RFC4684 or run over ORF. Authors took the latt= er while one may argue for the former. [Lucy] The proposed solution in above draft enables a BGP speaker to expres= s the interested route and creates a route target on fly as well as the map= ping. The peer that has this route automatically exports this route target = when sending NRLI. IMO: it contains some capability that rfc4684 does not h= ave and the capability is important in supporting the endpoint mobility. I = may be wrong, like to hear your opinion. Note that I am not saying that thi= s solution is perfect, but it is a good start point. =20 The solution I proposed however (and now reading my l3vpn backlog I see tha= t also Xuxiaohu mentioned however without discussing state removal) has major advantage that it works fine without any protocol extens= ion and upgrade of existing boxes. It is much simpler one. [Lucy] Agree. But it is the "push" model. Route path switching may have an = issue for some applications. The practical difference of my proposal vs draft-bonica-l3vpn-orf-covering-= prefixes is that in my scheme prefixes of significant flows will be distrib= uted to all v-spokes vs only those which indicate the need for them like de= scribed in the draft. That to me seems as acceptable tradeoff avoiding add= ed complexity and deployment obstacles. [Lucy] The difference, I see, is "off-load" mechanism via BGP "pull model" = mechanism although it can apply to the same use case. Regards, Lucy Best regards, R. On Mon, Oct 14, 2013 at 3:51 AM, Lucy yong wrote: > Hi Robert, > > I am not a co-author of the draft but am interested in the problem. In fa= ct, the problem was discussed year ago in nvo3 mailing list. > > BGP RTs are used for controlling route distribution and BGP route distrib= ution specified in rfc4364 is the pure "push" mechanism. This draft intenti= on is to implement a "pull" capability in BGP/VPN. The solution you propose= d can solve the v-spoke/v-hub use case described in the draft but, IMHO, it= still uses "push" mode, i.e. under v-hub solo control. So it may not apply= to other "pull" scenarios. > > I am not sure yet that implementing "pull" capability by BGP RT and rfc46= 84 is the right way and like to hear your opinion on it. IMO: ORF has the n= ative "pull" characteristic. > > Regards, > Lucy > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf=20 > Of Robert Raszuk > Sent: Friday, October 11, 2013 4:18 PM > To: Ronald Bonica > Cc: l3vpn@ietf.org > Subject: Re: FW: New Version Notification for=20 > draft-bonica-l3vpn-orf-covering-prefixes-00.txt > > Hi Ron, > > I have reviewed the proposed draft. I think it is very well written docum= ent. Maybe this is just my own observation, but during digesting it I have = struggled to understand why authors have decided to extend ORF rather then = update RFC4684. Maybe if the draft will progress a bit of clarification wou= ld be nice as in general 4684 is preferred over ORF in VPN context. > > But this is sort of minor detail. Much more important is to observe that = major advantage of RFC7024 is that by default it works with currently deplo= yed PEs and RRs. This draft however requires upgrade of both spoke PEs as w= ell as RRs serving such spoke PEs. Such upgrade may or may not be always fe= asible. > > It appears however that there is possibility of addressing the problem wi= th alternative approach fully controlled by the V-hub. Such V-hub alone is = capable of observing the flow patterns among it's V-spokes and based on the= set threshold locally injecting into any VPN optimal route for heavy flows= with RT-RED-FROM-HUB extended community. That as such will allow for optim= al data flows within given VPN bypassing the V-hub. > > The question arises how would we remove such more specific routes from V-= spokes when the flow terminates ... while there is number of possible solut= ions in this space - simplest seems to be time driven. > V-hub could start timer of x minutes (configurable) after injecting more = specific and upon expiration withdraw such more specific routes. > At most if the flow still continues customer VPN would experience transie= nt sub-optimality - no drops and no significant impact as V-hub would re-ad= vertise the active more specifics again. > > The major advantage of such proposal is that it is readily deployable int= o any of the today's L3VPN network by only activating V-hub which could be = a single upgraded PE or new box in the network. Moreover this procedure doe= s not require any protocol extension nor additional features like new RT in= sertion on the VPNv4/v6 route reflectors which your draft requires. > > I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will evaluate = such alternative. > > Best regards, > R. > > > On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica wrot= e: >> >> Please review this draft and provide comments. >> >> Ron >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, September 16, 2013 10:15 AM >>> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >>> Subject: New Version Notification for >>> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >>> >>> >>> A new version of I-D,=20 >>> draft-bonica-l3vpn-orf-covering-prefixes-00.txt >>> has been successfully submitted by Huajin Jeng and posted to the=20 >>> IETF repository. >>> >>> Filename: draft-bonica-l3vpn-orf-covering-prefixes >>> Revision: 00 >>> Title: Covering Prefixes Outbound Route Filter for BGP-= 4 >>> Creation date: 2013-09-15 >>> Group: Individual Submission >>> Number of pages: 10 >>> URL: http://www.ietf.org/internet-drafts/draft-bonica- >>> l3vpn-orf-covering-prefixes-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >>> orf-covering-prefixes >>> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >>> covering-prefixes-00 >>> >>> >>> Abstract: >>> This document defines a new ORF-type, called the "Covering Prefixes >>> ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual >>> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN >>> environments. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at=20 >>> tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >> From rraszuk@gmail.com Mon Oct 14 09:30:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9DB21E80D0 for ; Mon, 14 Oct 2013 09:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdZuDZis30jc for ; Mon, 14 Oct 2013 09:30:40 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9176011E8137 for ; Mon, 14 Oct 2013 09:30:38 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so5581185iet.7 for ; Mon, 14 Oct 2013 09:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ESXh0djBkbFNHpWfD4TGRgvdwg4t31uzOMAs1jHWi2k=; b=y4QvGtrZxb8kcjz8UrkbrlsF+Fut6VGz0WM/0yBReGHjrr9SmBr7vU3rdnpY6928tq 8T4MX2VCu6MK58ec1ad5Zd2suT6b6beIjQVsTw1BbgkRmGQUKgX0DkfopnU+QIDFIdiV bavFS2UEd/v8QPBWsQeD4RUKLNFFOdhOq6OBD+kw6KJ6KufXmvtt2eYoXi1km0+/Ybyr NhSN5cB5WmBp9YXA7ZPdj8ZUMfPFq4AXgB5OhipOiQUPVxPhhwhDW4pFkrpKWnNDOph+ lNd5+mDtO1OVEnvoui0QgTQ8jQbRVsRMELaelV1RnDOkenvdy3A6dNSKnaxkxkvCJE5Y 87qQ== MIME-Version: 1.0 X-Received: by 10.50.97.35 with SMTP id dx3mr13680493igb.55.1381768237941; Mon, 14 Oct 2013 09:30:37 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Mon, 14 Oct 2013 09:30:37 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D57F2@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452D54CB@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452D57F2@dfweml509-mbx.china.huawei.com> Date: Mon, 14 Oct 2013 18:30:37 +0200 X-Google-Sender-Auth: Aaohd7A0Jugxrp_OOWIkc_0247I Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:30:41 -0000 Lucy, > [Lucy] The proposed solution in above draft enables a BGP speaker to > express the interested route and creates a route target on fly as well as > the mapping. The proposed draft does not create any RT "on the fly" It asks RR to color selected prefixes with the normal already pre-provisioned RT namely "RT-RED-FROM-HUB1". Here is the quote: "As it advertises those routes, it adds the CP-ORF Import Route Target to the list of route targets that they carry. The advertised routes may specify either V-hub1 or any other node as the NEXT-HOP. V-spoke1 subjects the advertised routes to its import policy and accepts them because they carry the route target RT-RED-FROM-HUB1." Best, R. On Mon, Oct 14, 2013 at 6:19 PM, Lucy yong wrote: > Hi Robert, > > Thanks. Please see inline. > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Ra= szuk > Sent: Monday, October 14, 2013 3:27 AM > To: Lucy yong > Cc: Ronald Bonica; l3vpn@ietf.org > Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-cove= ring-prefixes-00.txt > > Hi Lucy, > > "Pull" model is well described in RFC4684 and ORF brings zero advantage o= ver it as far as RT based trigger. > [Lucy] To me, this "pull" model is quite complex and properly only works = in static way. (I may be wrong) The mechanism requires pre-assigned all the= route targets by an administrator. There is no explicit mapping between ro= ute target and route prefix. The mapping between route target and route are= implicitly done by the mapping between VPN site and route at the site via = operator configuration of export and import route target on each PE. Thus, = import Route Target mainly means to accept the route from some VPN sites. T= here is no way for BGP speaker to express interested route to peers and a p= eer only sends the route to the speaker. This is my understanding. > > The approach the above draft took requires more then just RT based "pull"= hence the dillema - to extend RFC4684 or run over ORF. Authors took the la= tter while one may argue for the former. > [Lucy] The proposed solution in above draft enables a BGP speaker to expr= ess the interested route and creates a route target on fly as well as the m= apping. The peer that has this route automatically exports this route targe= t when sending NRLI. IMO: it contains some capability that rfc4684 does not= have and the capability is important in supporting the endpoint mobility. = I may be wrong, like to hear your opinion. Note that I am not saying that t= his solution is perfect, but it is a good start point. > > The solution I proposed however (and now reading my l3vpn backlog I see t= hat also Xuxiaohu mentioned however without discussing state > removal) has major advantage that it works fine without any protocol exte= nsion and upgrade of existing boxes. It is much simpler one. > [Lucy] Agree. But it is the "push" model. Route path switching may have a= n issue for some applications. > > The practical difference of my proposal vs draft-bonica-l3vpn-orf-coverin= g-prefixes is that in my scheme prefixes of significant flows will be distr= ibuted to all v-spokes vs only those which indicate the need for them like = described in the draft. That to me seems as acceptable tradeoff avoiding a= dded complexity and deployment obstacles. > [Lucy] The difference, I see, is "off-load" mechanism via BGP "pull model= " mechanism although it can apply to the same use case. > > Regards, > Lucy > > Best regards, > R. > > > > > On Mon, Oct 14, 2013 at 3:51 AM, Lucy yong wrote: >> Hi Robert, >> >> I am not a co-author of the draft but am interested in the problem. In f= act, the problem was discussed year ago in nvo3 mailing list. >> >> BGP RTs are used for controlling route distribution and BGP route distri= bution specified in rfc4364 is the pure "push" mechanism. This draft intent= ion is to implement a "pull" capability in BGP/VPN. The solution you propos= ed can solve the v-spoke/v-hub use case described in the draft but, IMHO, i= t still uses "push" mode, i.e. under v-hub solo control. So it may not appl= y to other "pull" scenarios. >> >> I am not sure yet that implementing "pull" capability by BGP RT and rfc4= 684 is the right way and like to hear your opinion on it. IMO: ORF has the = native "pull" characteristic. >> >> Regards, >> Lucy >> >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >> Of Robert Raszuk >> Sent: Friday, October 11, 2013 4:18 PM >> To: Ronald Bonica >> Cc: l3vpn@ietf.org >> Subject: Re: FW: New Version Notification for >> draft-bonica-l3vpn-orf-covering-prefixes-00.txt >> >> Hi Ron, >> >> I have reviewed the proposed draft. I think it is very well written docu= ment. Maybe this is just my own observation, but during digesting it I have= struggled to understand why authors have decided to extend ORF rather then= update RFC4684. Maybe if the draft will progress a bit of clarification wo= uld be nice as in general 4684 is preferred over ORF in VPN context. >> >> But this is sort of minor detail. Much more important is to observe that= major advantage of RFC7024 is that by default it works with currently depl= oyed PEs and RRs. This draft however requires upgrade of both spoke PEs as = well as RRs serving such spoke PEs. Such upgrade may or may not be always f= easible. >> >> It appears however that there is possibility of addressing the problem w= ith alternative approach fully controlled by the V-hub. Such V-hub alone is= capable of observing the flow patterns among it's V-spokes and based on th= e set threshold locally injecting into any VPN optimal route for heavy flow= s with RT-RED-FROM-HUB extended community. That as such will allow for opti= mal data flows within given VPN bypassing the V-hub. >> >> The question arises how would we remove such more specific routes from V= -spokes when the flow terminates ... while there is number of possible solu= tions in this space - simplest seems to be time driven. >> V-hub could start timer of x minutes (configurable) after injecting more= specific and upon expiration withdraw such more specific routes. >> At most if the flow still continues customer VPN would experience transi= ent sub-optimality - no drops and no significant impact as V-hub would re-a= dvertise the active more specifics again. >> >> The major advantage of such proposal is that it is readily deployable in= to any of the today's L3VPN network by only activating V-hub which could be= a single upgraded PE or new box in the network. Moreover this procedure do= es not require any protocol extension nor additional features like new RT i= nsertion on the VPNv4/v6 route reflectors which your draft requires. >> >> I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will evaluate= such alternative. >> >> Best regards, >> R. >> >> >> On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica wro= te: >>> >>> Please review this draft and provide comments. >>> >>> Ron >>> >>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Monday, September 16, 2013 10:15 AM >>>> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >>>> Subject: New Version Notification for >>>> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >>>> >>>> >>>> A new version of I-D, >>>> draft-bonica-l3vpn-orf-covering-prefixes-00.txt >>>> has been successfully submitted by Huajin Jeng and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-bonica-l3vpn-orf-covering-prefixes >>>> Revision: 00 >>>> Title: Covering Prefixes Outbound Route Filter for BGP= -4 >>>> Creation date: 2013-09-15 >>>> Group: Individual Submission >>>> Number of pages: 10 >>>> URL: http://www.ietf.org/internet-drafts/draft-bonica- >>>> l3vpn-orf-covering-prefixes-00.txt >>>> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >>>> orf-covering-prefixes >>>> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >>>> covering-prefixes-00 >>>> >>>> >>>> Abstract: >>>> This document defines a new ORF-type, called the "Covering Prefixes >>>> ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtua= l >>>> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN >>>> environments. >>>> >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >>>> tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>> From lucy.yong@huawei.com Mon Oct 14 09:50:16 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E27411E8137 for ; Mon, 14 Oct 2013 09:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIJ09Qrg+uCw for ; Mon, 14 Oct 2013 09:50:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C74021E80EB for ; Mon, 14 Oct 2013 09:50:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWU46102; Mon, 14 Oct 2013 16:50:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 17:49:10 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 17:49:58 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Mon, 14 Oct 2013 09:49:54 -0700 From: Lucy yong To: Robert Raszuk Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOyLc9W/JQAheSKUGBeIA4HFtwrZn0V+dAgACBcID//48kQA== Date: Mon, 14 Oct 2013 16:49:53 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D5864@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452D54CB@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452D57F2@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:50:16 -0000 Robert, As I said, the proposed solution is a start point, not perfect yet. Whether V-spoke1 can create a route target automatically or operator config= ured is local action. The mechanism allows both. I don't see the following = statement excludes that. Lucy -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Monday, October 14, 2013 11:31 AM To: Lucy yong Cc: Ronald Bonica; l3vpn@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-coveri= ng-prefixes-00.txt Lucy, > [Lucy] The proposed solution in above draft enables a BGP speaker to=20 > express the interested route and creates a route target on fly as well=20 > as the mapping. The proposed draft does not create any RT "on the fly" It asks RR to color = selected prefixes with the normal already pre-provisioned RT namely "RT-RED= -FROM-HUB1". Here is the quote: "As it advertises those routes, it adds the CP-ORF Import Route Target to t= he list of route targets that they carry. The advertised routes may specif= y either V-hub1 or any other node as the NEXT-HOP. V-spoke1 subjects the advertised routes to its import policy and accepts th= em because they carry the route target RT-RED-FROM-HUB1." Best, R. On Mon, Oct 14, 2013 at 6:19 PM, Lucy yong wrote: > Hi Robert, > > Thanks. Please see inline. > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert=20 > Raszuk > Sent: Monday, October 14, 2013 3:27 AM > To: Lucy yong > Cc: Ronald Bonica; l3vpn@ietf.org > Subject: Re: FW: New Version Notification for=20 > draft-bonica-l3vpn-orf-covering-prefixes-00.txt > > Hi Lucy, > > "Pull" model is well described in RFC4684 and ORF brings zero advantage o= ver it as far as RT based trigger. > [Lucy] To me, this "pull" model is quite complex and properly only works = in static way. (I may be wrong) The mechanism requires pre-assigned all the= route targets by an administrator. There is no explicit mapping between ro= ute target and route prefix. The mapping between route target and route are= implicitly done by the mapping between VPN site and route at the site via = operator configuration of export and import route target on each PE. Thus, = import Route Target mainly means to accept the route from some VPN sites. T= here is no way for BGP speaker to express interested route to peers and a p= eer only sends the route to the speaker. This is my understanding. > > The approach the above draft took requires more then just RT based "pull"= hence the dillema - to extend RFC4684 or run over ORF. Authors took the la= tter while one may argue for the former. > [Lucy] The proposed solution in above draft enables a BGP speaker to expr= ess the interested route and creates a route target on fly as well as the m= apping. The peer that has this route automatically exports this route targe= t when sending NRLI. IMO: it contains some capability that rfc4684 does not= have and the capability is important in supporting the endpoint mobility. = I may be wrong, like to hear your opinion. Note that I am not saying that t= his solution is perfect, but it is a good start point. > > The solution I proposed however (and now reading my l3vpn backlog I=20 > see that also Xuxiaohu mentioned however without discussing state > removal) has major advantage that it works fine without any protocol exte= nsion and upgrade of existing boxes. It is much simpler one. > [Lucy] Agree. But it is the "push" model. Route path switching may have a= n issue for some applications. > > The practical difference of my proposal vs draft-bonica-l3vpn-orf-coverin= g-prefixes is that in my scheme prefixes of significant flows will be distr= ibuted to all v-spokes vs only those which indicate the need for them like = described in the draft. That to me seems as acceptable tradeoff avoiding a= dded complexity and deployment obstacles. > [Lucy] The difference, I see, is "off-load" mechanism via BGP "pull model= " mechanism although it can apply to the same use case. > > Regards, > Lucy > > Best regards, > R. > > > > > On Mon, Oct 14, 2013 at 3:51 AM, Lucy yong wrote: >> Hi Robert, >> >> I am not a co-author of the draft but am interested in the problem. In f= act, the problem was discussed year ago in nvo3 mailing list. >> >> BGP RTs are used for controlling route distribution and BGP route distri= bution specified in rfc4364 is the pure "push" mechanism. This draft intent= ion is to implement a "pull" capability in BGP/VPN. The solution you propos= ed can solve the v-spoke/v-hub use case described in the draft but, IMHO, i= t still uses "push" mode, i.e. under v-hub solo control. So it may not appl= y to other "pull" scenarios. >> >> I am not sure yet that implementing "pull" capability by BGP RT and rfc4= 684 is the right way and like to hear your opinion on it. IMO: ORF has the = native "pull" characteristic. >> >> Regards, >> Lucy >> >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On=20 >> Behalf Of Robert Raszuk >> Sent: Friday, October 11, 2013 4:18 PM >> To: Ronald Bonica >> Cc: l3vpn@ietf.org >> Subject: Re: FW: New Version Notification for=20 >> draft-bonica-l3vpn-orf-covering-prefixes-00.txt >> >> Hi Ron, >> >> I have reviewed the proposed draft. I think it is very well written docu= ment. Maybe this is just my own observation, but during digesting it I have= struggled to understand why authors have decided to extend ORF rather then= update RFC4684. Maybe if the draft will progress a bit of clarification wo= uld be nice as in general 4684 is preferred over ORF in VPN context. >> >> But this is sort of minor detail. Much more important is to observe that= major advantage of RFC7024 is that by default it works with currently depl= oyed PEs and RRs. This draft however requires upgrade of both spoke PEs as = well as RRs serving such spoke PEs. Such upgrade may or may not be always f= easible. >> >> It appears however that there is possibility of addressing the problem w= ith alternative approach fully controlled by the V-hub. Such V-hub alone is= capable of observing the flow patterns among it's V-spokes and based on th= e set threshold locally injecting into any VPN optimal route for heavy flow= s with RT-RED-FROM-HUB extended community. That as such will allow for opti= mal data flows within given VPN bypassing the V-hub. >> >> The question arises how would we remove such more specific routes from V= -spokes when the flow terminates ... while there is number of possible solu= tions in this space - simplest seems to be time driven. >> V-hub could start timer of x minutes (configurable) after injecting more= specific and upon expiration withdraw such more specific routes. >> At most if the flow still continues customer VPN would experience transi= ent sub-optimality - no drops and no significant impact as V-hub would re-a= dvertise the active more specifics again. >> >> The major advantage of such proposal is that it is readily deployable in= to any of the today's L3VPN network by only activating V-hub which could be= a single upgraded PE or new box in the network. Moreover this procedure do= es not require any protocol extension nor additional features like new RT i= nsertion on the VPNv4/v6 route reflectors which your draft requires. >> >> I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will evaluate= such alternative. >> >> Best regards, >> R. >> >> >> On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica wro= te: >>> >>> Please review this draft and provide comments. >>> >>> Ron >>> >>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Monday, September 16, 2013 10:15 AM >>>> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >>>> Subject: New Version Notification for >>>> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >>>> >>>> >>>> A new version of I-D, >>>> draft-bonica-l3vpn-orf-covering-prefixes-00.txt >>>> has been successfully submitted by Huajin Jeng and posted to the=20 >>>> IETF repository. >>>> >>>> Filename: draft-bonica-l3vpn-orf-covering-prefixes >>>> Revision: 00 >>>> Title: Covering Prefixes Outbound Route Filter for BGP= -4 >>>> Creation date: 2013-09-15 >>>> Group: Individual Submission >>>> Number of pages: 10 >>>> URL: http://www.ietf.org/internet-drafts/draft-bonica- >>>> l3vpn-orf-covering-prefixes-00.txt >>>> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >>>> orf-covering-prefixes >>>> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >>>> covering-prefixes-00 >>>> >>>> >>>> Abstract: >>>> This document defines a new ORF-type, called the "Covering Prefixes >>>> ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtua= l >>>> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN >>>> environments. >>>> >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of=20 >>>> submission until the htmlized version and diff are available at=20 >>>> tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>> From internet-drafts@ietf.org Mon Oct 14 10:16:49 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27FD21E8199; Mon, 14 Oct 2013 10:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-lEvJc7NBkS; Mon, 14 Oct 2013 10:16:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6011921E80DF; Mon, 14 Oct 2013 10:16:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-l2l3-vpn-mcast-mib-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014171649.11527.42010.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 10:16:49 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 17:16:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : L2L3 VPN Multicast MIB Author(s) : Zhaohui Zhang Filename : draft-ietf-l3vpn-l2l3-vpn-mcast-mib-01.txt Pages : 10 Date : 2013-10-14 Abstract: This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects common to both VPLS and VPN Multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-l2l3-vpn-mcast-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-l2l3-vpn-mcast-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-l2l3-vpn-mcast-mib-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.vigoureux@alcatel-lucent.com Tue Oct 15 07:26:27 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A961221F9EE9 for ; Tue, 15 Oct 2013 07:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.119 X-Spam-Level: X-Spam-Status: No, score=-110.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZR7MwQjdkKr for ; Tue, 15 Oct 2013 07:26:22 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 28CB721E80F1 for ; Tue, 15 Oct 2013 07:26:03 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9FEPxJP011721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Oct 2013 09:26:00 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9FEPwWt009783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 16:25:58 +0200 Received: from [172.27.205.168] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Oct 2013 16:25:58 +0200 Message-ID: <525D5075.8070301@alcatel-lucent.com> Date: Tue, 15 Oct 2013 16:25:57 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: Please read and comment [Re: WG Last Call for draft-ietf-l3vpn-mldp-vrf-in-band-signaling] References: <14292_1377096453_5214D305_14292_2376_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D07570795@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <14292_1377096453_5214D305_14292_2376_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D07570795@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: 'L3VPN Chairs' X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:26:27 -0000 Working Group, we did not formally close this WG LC. There are few reasons to that. * We are expecting an IPR disclosure, which would come quite late but which on the other hand had been communicated by Ice at the time of WG adoption. * No comments were expressed during this LC. While I am fine with not seeing comments requiring (substantial) changes, I am not satisfied with complete silence. We have asked for a review of the document to be performed by a member of the Routing Directorate, but we are encouraging you to review and comment on the document until the 25th of October. Thank you Martin, for the L3VPN Chairs Le 21/08/2013 16:47, thomas.morin@orange.com a écrit : > Hello working group, > > This email starts a two-week Working Group Last Call on > draft-ietf-l3vpn-mldp-vrf-in-band-signaling, which is considered mature > and ready for a working group review. > > http://tools.ietf.org/html/draft-ietf-l3vpn-mldp-vrf-in-band-signaling > > Please read the document if you haven't read the most recent version, > and send your comments to the list, no later than Wednesday September 4th. > > Thank you, > > -Thomas & Martin > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From wang.cui1@zte.com.cn Wed Oct 16 01:17:27 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3810111E81B2; Wed, 16 Oct 2013 01:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.373 X-Spam-Level: X-Spam-Status: No, score=-95.373 tagged_above=-999 required=5 tests=[AWL=-4.823, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAfu5FfS4GPE; Wed, 16 Oct 2013 01:17:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7421F9A6A; Wed, 16 Oct 2013 01:17:14 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 8187712E43A2; Wed, 16 Oct 2013 16:16:58 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id A87EC70B5E2; Wed, 16 Oct 2013 16:16:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r9G8H0XY042643; Wed, 16 Oct 2013 16:17:00 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <4832730c91be489281cb9b44941b45dd@BY2PR05MB079.namprd05.prod.outlook.com> To: "Jeffrey (Zhaohui) Zhang" Subject: =?GB2312?B?tPC4tDogUkU6IFtNQk9ORURdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbg==?= =?GB2312?B?IGZvcglkcmFmdC16emhhbmctbDN2cG4tbXZwbi1nbG9iYWwtdGFibGUt?= =?GB2312?B?bWNhc3QtMDAudHh0?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Wed, 16 Oct 2013 16:16:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-10-16 16:16:44, Serialize complete at 2013-10-16 16:16:44 Content-Type: multipart/alternative; boundary="=_alternative 002D8EDF48257C06_=" X-MAIL: mse02.zte.com.cn r9G8H0XY042643 Cc: "mboned@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:17:27 -0000 This is a multipart message in MIME format. --=_alternative 002D8EDF48257C06_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksSmVmZnJleQ0KDQogIFNlZSBiZWxvdyBpbmxpbmUuDQoNCiAgSWYgSSBtaXNzIHNvbWV0aGlu ZyBwbGVhc2UgcG9pbnQgb3V0LlRoYW5rcyENCg0KQlJzLA0KTGluZGEgV2FuZw0KDQoNCiJKZWZm cmV5IChaaGFvaHVpKSBaaGFuZyIgPHp6aGFuZ0BqdW5pcGVyLm5ldD4g0LTT2iAyMDEzLTEwLTEx IDIyOjAyOjQyOg0KDQo+IExpbmRhLA0KPiANCj4gQmFzZSBNVlBOIHByb3RvY29sIGFsbG93cyB0 byBoYXZlIGRpZmZlcmVudCBSRHMgYW5kIHNhbWUgaXMgaGVyZS4NCi8vTGluZGE6IFNvcnJ5IGZv ciBtaXN0YWtpbmcgUkQgdG8gUlQuDQo+IEluIGEgbmV3ZXIgcmV2aXNpb24gb2YgdGhlIGRyYWZ0 ICh0byBiZSBzdWJtaXR0ZWQpLCB3ZSBoYXZlIGFjdHVhbGx5DQo+IHJlbW92ZWQgdGhhdCB3b3Jk aW5nLCBiZWNhdXNlIHdoaWxlIGl0IGlzIG9rIHRvIHVzZSBub24temVybyBSRHMgaXQgDQo+IGRv ZXMgbm90IGFkZCBhbnkgb2J2aW91cyB2YWx1ZS4gVGhlIG9yaWdpbmFsIHRleHQgd2FzIHRvIHNo b3cgdGhhdCANCj4gZXhpc3RpbmcgTVZQTiBwcm9jZWR1cmVzIGNhbiBiZSB1c2VkIGFzIGlzICh3 ZWxsLCB3aXRoIHNvbWUgbWlub3IgDQo+IGV4Y2VwdHMgdGhhdCB3ZXJlIHNwZWxsZWQgb3V0KS4N Ci8vTGluZGGjunlvdSdsbCByZW1vdmUgUkQgd29yZGluZz8gWWVzLGFncmVlIGZvciByZW1vdmUg UkQgZmllbGQgaW4gYWxsIA0KQS1EIFJvdXRlcyBpbiB0aGUgY29udGV4dCBvZiBHVE0uIEJ1dCB3 aGF0IGFib3V0IFJUPyBEbyB5b3Ugc3RpbGwgd2FudCB0byANCnJlbWFpbiBSVD8gSWYgd2UgcmVt b3ZlIFJULHRoZXJlIGFyZSBubyB0aGUgcXVlc3Rpb25zIHlvdSBtZW50aW9uZWQgaW4gDQpTZWN0 aW9uIDMuMy4NCg0KLy9MaW5kYTogQWxzbywgSSBzYXcgTUJSKE1QTFMgQm9yZGVyIFJvdXRlcikg aXMgY2FsbGVkIGluIHlvdXIgZHJhZnQsIGRvZXMgDQppdCBtZWFuIHRoZSBjb3JlIG5ldHdvcmsg bXVzdCBiZSBNUExTLWVuYWJsZT8gDQoNCj4gVGhhbmtzLg0KPiBKZWZmcmV5DQo+IA0KPiBGcm9t OiB3YW5nLmN1aTFAenRlLmNvbS5jbiBbbWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuXSANCj4g U2VudDogRnJpZGF5LCBPY3RvYmVyIDExLCAyMDEzIDQ6MjQgQU0NCj4gVG86IEplZmZyZXkgKFpo YW9odWkpIFpoYW5nDQo+IENjOiBtYm9uZWRAaWV0Zi5vcmc7IGwzdnBuQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbTUJPTkVEXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp6 aGFuZy0NCj4gbDN2cG4tbXZwbi1nbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0DQo+IA0KPiANCj4g SGksSmVmZnJleSANCj4gDQo+ICAgU2VjdGlvbiAzIHNhaWQ6IA0KPiANCj4gICAgUkZDIDY1MTQg c3BlY2lmaWVzIHRoYXQgTUNBU1QtVlBOIHJvdXRlcyBjYXJyeSBhIFJvdXRlIERpc3Rpbmd1aXNo ZXINCj4gICAoUkQpLiAgRm9yIEdUTSwgaXQgU0hPVUxEIGJlIHBvc3NpYmxlIHRvIGNvbmZpZ3Vy ZSBhbiBSRCB0aGF0IGlzIHVzZWQNCj4gICBvbmx5IGZvciBNQ0FTVC1WUE4gQS1EIHJvdXRlcyBm b3IgdGhlIGdsb2JhbCB0YWJsZS4gIFRoZSBSRCBjYW4gYmUNCj4gICBkZWZhdWx0ZWQgdG8gYSBz cGVjaWFsIDY0LWJpdCBhbGwtemVybyB2YWx1ZSAoZGVub3RlZCBhcyBSRCAwOjApLg0KPiANCj4g VGhpcyBtZWFucyB3ZSBjYW4gY29uZmlndXJlIHRoZSBSRCB3aGVuIEdUTSBpcyBlbmFibGUsIHJp Z2h0PyANCj4gSGVyZSBpcyBhIHF1ZXN0aW9uOiBJbiBhIGxhcmdlIG5ldHdvcmssIHRoZXJlIGFy ZSBtYW55IGRpZmZlcmVudCANCj4gYWRtaW5pc3RyYXRvcnMsd2hhdCBpZiBhZG1pbjEgY29uZmln dXJlcyB0aGUgdmFsdWUgMToxIGluIGhpcyBtYW5hZ2UNCj4gYXJlYShhcmVhMSksIGFuZCBhZG1p bjIgY29uZmlndXJlcyB0aGUgdmFsdXJlIDI6MiBpbiBhbm90aGVyIA0KYXJlYShhcmVhMik/IA0K PiANCj4gSWYgSSBtaXNzIHNvbWV0aGluZyBwbGVhc2UgcG9pbnQgb3V0LlRoYW5rcyEgDQo+IA0K PiBCUnMgDQo+IExpbmRhIFdhbmcNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiA+IEhpLA0KPiA+IA0K PiA+IFRoaXMgaXMgYW4gdXBkYXRlIHRvIGRyYWZ0LXp6aGFuZy1tYm9uZWQtbXZwbi1nbG9iYWwt dGFibGUtbWNhc3QtMDAuDQo+ID4gDQo+ID4gV2UgaGF2ZSByZS1ob21lZCBpdCB0byBsM3Zwbiwg YW5kIGhvcGVmdWxseSBhZGRyZXNzZWQgbW9zdCBjb21tZW50cyANCj4gPiB0aGF0IEVyaWMgaGFk Lg0KPiA+IA0KPiA+IFlvdXIgcmV2aWV3IGFuZCBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQo+ ID4gDQo+ID4gVGhhbmtzLg0KPiA+IEplZmZyZXkNCj4gPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9yZ10gDQoNCj4gPiBTZW50OiBGcmlkYXksIEp1bHkg MTIsIDIwMTMgMzo1NSBQTQ0KPiA+IFRvOiBEYW50ZSBKLlBhY2VsbGE7IExlbm55IEdpdWxpYW5v OyBKYXNvbiBTY2hpbGxlcjsgTGVubnkgR2l1bGlhbm87DQo+ID4gSmVmZnJleSAoWmhhb2h1aSkg WmhhbmcNCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp6 aGFuZy1sM3Zwbi1tdnBuLQ0KPiA+IGdsb2JhbC10YWJsZS1tY2FzdC0wMC50eHQNCj4gPiANCj4g PiANCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgDQpkcmFmdC16emhhbmctbDN2cG4tbXZwbi1n bG9iYWwtdGFibGUtbWNhc3QtMDAudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBKZWZmcmV5IFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4gSUVURiByZXBvc2l0 b3J5Lg0KPiA+IA0KPiA+IEZpbGVuYW1lOiAgICBkcmFmdC16emhhbmctbDN2cG4tbXZwbi1nbG9i YWwtdGFibGUtbWNhc3QNCj4gPiBSZXZpc2lvbjogICAgMDANCj4gPiBUaXRsZTogICAgICAgR2xv YmFsIFRhYmxlIE11bHRpY2FzdCB3aXRoIEJHUC1NVlBOIFByb2NlZHVyZXMNCj4gPiBDcmVhdGlv biBkYXRlOiAgICAyMDEzLTA3LTEyDQo+ID4gR3JvdXA6ICAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPiA+IE51bWJlciBvZiBwYWdlczogMTQNCj4gPiBVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXp6aGFuZy0NCj4gPiBsM3Zwbi1t dnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC50eHQNCj4gPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtenpoYW5nLWwzdnBuLQ0KPiA+IG12cG4t Z2xvYmFsLXRhYmxlLW1jYXN0DQo+ID4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC16emhhbmctbDN2cG4tbXZwbi0NCj4gPiBnbG9iYWwtdGFibGUtbWNh c3QtMDANCj4gPiANCj4gPiANCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhIHdheSB0byBpbXBsZW1lbnQgR2xvYmFsIFRhYmxlIE11bHRpY2FzdCwNCj4gPiAg ICBha2EgSW50ZXJuZXQgTXVsdGljYXN0LCB1c2luZyBCR1AgZW5jb2RpbmdzIGFuZCBwcm9jZWR1 cmVzIGZvciBNVlBODQo+ID4gICAgYXMgc3BlY2lmaWVkIGluIFtSRkM2NTE0XS4NCj4gPiANCj4g PiAgICBObyBwcm90b2NvbCBtb2RpZmljYXRpb24vZXh0ZW5zaW9uIGlzIHJlcXVpcmVkLiAgVGhp cyBpcyBwdXJlbHkgZm9yDQo+ID4gICAgaW5mb3JtYXRpb25hbCBhbmQgY2xhcmlmeWluZyBwdXJw b3NlcyBvbmx5Lg0KPiA+IA0KPiA+ICANCj4gPiANCj4gPiANCj4gPiBUaGUgSUVURiBTZWNyZXRh cmlhdA0KPiA+IA0KPiA+IA0KPiA+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIA0KPiBtYWlsIChhbmQg YW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0K PiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUgDQo+IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVu dCwgYW55IGRpc2Nsb3N1cmUsDQo+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVy IGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gaW5mb3JtYXRpb24gY29udGFpbmVkIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCj4gdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ IA0KPiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhl cmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZv ciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0 cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRp YXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBo ZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBm b3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90 IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlz dHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVk aWF0ZWx5Lg0K --=_alternative 002D8EDF48257C06_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLEplZmZyZXk8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBTZWUgYmVsb3cg aW5saW5lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7IElmIEkgbWlzcyBzb21ldGhpbmcgcGxlYXNlIHBvaW50DQpvdXQuVGhhbmtzITwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlJzLDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TGluZGEgV2FuZzwvZm9udD4NCjxi cj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O0plZmZyZXkgKFpoYW9odWkpIFpo YW5nJnF1b3Q7ICZsdDt6emhhbmdAanVuaXBlci5uZXQmZ3Q7DQrQtNPaIDIwMTMtMTAtMTEgMjI6 MDI6NDI6PGJyPg0KPGJyPg0KJmd0OyBMaW5kYSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IEJhc2UgTVZQTiBwcm90b2NvbCBhbGxvd3MgdG8gaGF2ZSBkaWZmZXJlbnQgUkRzDQphbmQgc2Ft ZSBpcyBoZXJlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGI+Ly9MaW5kYTo8 L2I+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxiPg0KU29ycnkg Zm9yIG1pc3Rha2luZyBSRCB0byBSVC48L2I+PC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBJbiBhIG5ld2VyIHJldmlzaW9uIG9mIHRoZSBkcmFmdCAodG8gYmUgc3VibWl0dGVkKSwN CndlIGhhdmUgYWN0dWFsbHk8YnI+DQomZ3Q7IHJlbW92ZWQgdGhhdCB3b3JkaW5nLCBiZWNhdXNl IHdoaWxlIGl0IGlzIG9rIHRvIHVzZSBub24temVybyBSRHMgaXQNCjxicj4NCiZndDsgZG9lcyBu b3QgYWRkIGFueSBvYnZpb3VzIHZhbHVlLiBUaGUgb3JpZ2luYWwgdGV4dCB3YXMgdG8gc2hvdyB0 aGF0DQo8YnI+DQomZ3Q7IGV4aXN0aW5nIE1WUE4gcHJvY2VkdXJlcyBjYW4gYmUgdXNlZCBhcyBp cyAod2VsbCwgd2l0aCBzb21lIG1pbm9yDQo8YnI+DQomZ3Q7IGV4Y2VwdHMgdGhhdCB3ZXJlIHNw ZWxsZWQgb3V0KS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxiPi8vTGluZGGj unlvdSdsbCByZW1vdmUgUkQgd29yZGluZz8gWWVzLGFncmVlIGZvcg0KcmVtb3ZlIFJEIGZpZWxk IGluIGFsbCBBLUQgUm91dGVzIGluIHRoZSBjb250ZXh0IG9mIEdUTS4gQnV0IHdoYXQgYWJvdXQN ClJUPyBEbyB5b3Ugc3RpbGwgd2FudCB0byByZW1haW4gUlQ/IElmIHdlIHJlbW92ZSBSVCx0aGVy ZSBhcmUgbm8gdGhlIHF1ZXN0aW9ucw0KeW91IG1lbnRpb25lZCBpbiBTZWN0aW9uIDMuMy48L2I+ PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48Yj4vL0xpbmRhOiBBbHNv LCA8L2I+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxiPkkNCnNh dyBNQlIoTVBMUyBCb3JkZXIgUm91dGVyKSBpcyBjYWxsZWQgaW4geW91ciBkcmFmdCwgZG9lcyBp dCBtZWFuIHRoZSBjb3JlDQpuZXR3b3JrIG11c3QgYmUgTVBMUy1lbmFibGU/IDwvYj48L2ZvbnQ+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoYW5rcy48L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSmVmZnJleTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgRnJvbTogd2FuZy5jdWkxQHp0ZS5jb20uY24gW21haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5j bl0NCjxicj4NCiZndDsgU2VudDogRnJpZGF5LCBPY3RvYmVyIDExLCAyMDEzIDQ6MjQgQU08YnI+ DQomZ3Q7IFRvOiBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZzxicj4NCiZndDsgQ2M6IG1ib25lZEBp ZXRmLm9yZzsgbDN2cG5AaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbTUJPTkVEXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp6aGFuZy08YnI+DQomZ3Q7IGwzdnBu LW12cG4tZ2xvYmFsLXRhYmxlLW1jYXN0LTAwLnR4dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyBIaSxKZWZmcmV5IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgU2Vj dGlvbiAzIHNhaWQ6IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDtSRkMgNjUxNCBzcGVjaWZpZXMgdGhhdCBNQ0FTVC1WUE4gcm91 dGVzIGNhcnJ5IGEgUm91dGUNCkRpc3Rpbmd1aXNoZXI8YnI+DQomZ3Q7ICZuYnNwOyAoUkQpLiAm bmJzcDtGb3IgR1RNLCBpdCBTSE9VTEQgYmUgcG9zc2libGUgdG8gY29uZmlndXJlIGFuDQpSRCB0 aGF0IGlzIHVzZWQ8YnI+DQomZ3Q7ICZuYnNwOyBvbmx5IGZvciBNQ0FTVC1WUE4gQS1EIHJvdXRl cyBmb3IgdGhlIGdsb2JhbCB0YWJsZS4gJm5ic3A7VGhlDQpSRCBjYW4gYmU8YnI+DQomZ3Q7ICZu YnNwOyBkZWZhdWx0ZWQgdG8gYSBzcGVjaWFsIDY0LWJpdCBhbGwtemVybyB2YWx1ZSAoZGVub3Rl ZCBhcyBSRA0KMDowKS48YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IFRoaXMgbWVhbnMgd2Ug Y2FuIGNvbmZpZ3VyZSB0aGUgUkQgd2hlbiBHVE0gaXMgZW5hYmxlLCByaWdodD8gPGJyPg0KJmd0 OyBIZXJlIGlzIGEgcXVlc3Rpb246IEluIGEgbGFyZ2UgbmV0d29yaywgdGhlcmUgYXJlIG1hbnkg ZGlmZmVyZW50IDxicj4NCiZndDsgYWRtaW5pc3RyYXRvcnMsd2hhdCBpZiBhZG1pbjEgY29uZmln dXJlcyB0aGUgdmFsdWUgMToxIGluIGhpcyBtYW5hZ2U8YnI+DQomZ3Q7IGFyZWEoYXJlYTEpLCBh bmQgYWRtaW4yIGNvbmZpZ3VyZXMgdGhlIHZhbHVyZSAyOjIgaW4gYW5vdGhlciBhcmVhKGFyZWEy KT8NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBJIG1pc3Mgc29tZXRoaW5nIHBsZWFzZSBwb2lu dCBvdXQuVGhhbmtzISA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQlJzIDxicj4NCiZndDsgTGluZGEg V2FuZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSw8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgaXMgYW4gdXBkYXRlIHRvIGRyYWZ0LXp6aGFu Zy1tYm9uZWQtbXZwbi1nbG9iYWwtdGFibGUtbWNhc3QtMDAuPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBXZSBoYXZlIHJlLWhvbWVkIGl0IHRvIGwzdnBuLCBhbmQgaG9wZWZ1bGx5IGFk ZHJlc3NlZCBtb3N0IGNvbW1lbnRzDQo8YnI+DQomZ3Q7ICZndDsgdGhhdCBFcmljIGhhZC48YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFlvdXIgcmV2aWV3IGFuZCBjb21tZW50cyBhcmUg YXBwcmVjaWF0ZWQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MuPGJyPg0K Jmd0OyAmZ3Q7IEplZmZyZXk8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IGludGVybmV0LWRyYWZ0cyBh dCBpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0cyBhdA0KaWV0Zi5vcmddIDxicj4NCiZn dDsgJmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTIsIDIwMTMgMzo1NSBQTTxicj4NCiZndDsgJmd0 OyBUbzogRGFudGUgSi5QYWNlbGxhOyBMZW5ueSBHaXVsaWFubzsgSmFzb24gU2NoaWxsZXI7IExl bm55IEdpdWxpYW5vOzxicj4NCiZndDsgJmd0OyBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZzxicj4N CiZndDsgJmd0OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp6 aGFuZy1sM3Zwbi1tdnBuLTxicj4NCiZndDsgJmd0OyBnbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0 PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdC0w MC50eHQ8YnI+DQomZ3Q7ICZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBK ZWZmcmV5IFpoYW5nIGFuZCBwb3N0ZWQgdG8NCnRoZTxicj4NCiZndDsgJmd0OyBJRVRGIHJlcG9z aXRvcnkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBGaWxlbmFtZTogJm5ic3A7ICZu YnNwO2RyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdDxicj4NCiZndDsg Jmd0OyBSZXZpc2lvbjogJm5ic3A7ICZuYnNwOzAwPGJyPg0KJmd0OyAmZ3Q7IFRpdGxlOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyBHbG9iYWwgVGFibGUgTXVsdGljYXN0IHdpdGggQkdQLU1WUE4NClBy b2NlZHVyZXM8YnI+DQomZ3Q7ICZndDsgQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNwOzIwMTMt MDctMTI8YnI+DQomZ3Q7ICZndDsgR3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1 YWwgU3VibWlzc2lvbjxicj4NCiZndDsgJmd0OyBOdW1iZXIgb2YgcGFnZXM6IDE0PGJyPg0KJmd0 OyAmZ3Q7IFVSTDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtenpoYW5nLTxicj4NCiZndDsg Jmd0OyBsM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC50eHQ8YnI+DQomZ3Q7ICZndDsg U3RhdHVzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC16emhhbmctbDN2cG4tPGJyPg0KJmd0OyAmZ3Q7IG12cG4t Z2xvYmFsLXRhYmxlLW1jYXN0PGJyPg0KJmd0OyAmZ3Q7IEh0bWxpemVkOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16emhhbmctbDN2 cG4tbXZwbi08YnI+DQomZ3Q7ICZndDsgZ2xvYmFsLXRhYmxlLW1jYXN0LTAwPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHdheSB0byBpbXBsZW1l bnQgR2xvYmFsDQpUYWJsZSBNdWx0aWNhc3QsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDth a2EgSW50ZXJuZXQgTXVsdGljYXN0LCB1c2luZyBCR1AgZW5jb2RpbmdzIGFuZA0KcHJvY2VkdXJl cyBmb3IgTVZQTjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YXMgc3BlY2lmaWVkIGluIFtS RkM2NTE0XS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtObyBw cm90b2NvbCBtb2RpZmljYXRpb24vZXh0ZW5zaW9uIGlzIHJlcXVpcmVkLg0KJm5ic3A7VGhpcyBp cyBwdXJlbHkgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtpbmZvcm1hdGlvbmFsIGFu ZCBjbGFyaWZ5aW5nIHB1cnBvc2VzIG9ubHkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbg0KY29udGFpbmVk IGluIHRoaXMgPGJyPg0KJmd0OyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIDxicj4NCiZndDsgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIDxicj4NCiZndDsgYWRkcmVz c2VlKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk aXNjbG9zdXJlLDxicj4NCiZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIg ZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZndDsgaW5mb3JtYXRpb24gY29udGFp bmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkDQo8 YnI+DQomZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5 IHVzIGltbWVkaWF0ZWx5LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250 PjwvdHQ+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAo YW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBh bnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2Vt aW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVh c2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48 YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5k IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUg YWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h dGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2Ug ZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+ DQo= --=_alternative 002D8EDF48257C06_=-- From zzhang@juniper.net Wed Oct 16 06:14:07 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AD511E82A3; Wed, 16 Oct 2013 06:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=-3.735, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aDERpMVkww9; Wed, 16 Oct 2013 06:14:02 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 423FE11E82A7; Wed, 16 Oct 2013 06:14:01 -0700 (PDT) Received: from mail174-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE038.bigfish.com (10.243.66.103) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Oct 2013 13:14:00 +0000 Received: from mail174-co1 (localhost [127.0.0.1]) by mail174-co1-R.bigfish.com (Postfix) with ESMTP id 71530700069; Wed, 16 Oct 2013 13:14:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz9371Ic89bh936eI103dKc85bh542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL18c58eh6d524h17326ah8275dh18c673h1c8fb4h1de097h186068h18de19h8275bhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail174-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377424004)(13464003)(199002)(189002)(51704005)(377454003)(41574002)(74876001)(77096001)(56816003)(53806001)(50986001)(33646001)(76576001)(15202345003)(49866001)(47736001)(79102001)(85306002)(4396001)(15975445006)(31966008)(19300405004)(47976001)(74706001)(54356001)(69226001)(59766001)(19609705001)(81686001)(74662001)(47446002)(16234385003)(16236675002)(76796001)(76786001)(51856001)(74502001)(83072001)(80976001)(18717965001)(81816001)(77982001)(19580395003)(66066001)(19580405001)(65816001)(83322001)(74316001)(81342001)(76482001)(74366001)(80022001)(81542001)(46102001)(63696002)(56776001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB079; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail174-co1 (localhost.localdomain [127.0.0.1]) by mail174-co1 (MessageSwitch) id 1381929238106399_28428; Wed, 16 Oct 2013 13:13:58 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.251]) by mail174-co1.bigfish.com (Postfix) with ESMTP id 0C92BBC004C; Wed, 16 Oct 2013 13:13:58 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 16 Oct 2013 13:13:56 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 16 Oct 2013 13:13:56 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 16 Oct 2013 13:13:52 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.179]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.173]) with mapi id 15.00.0785.001; Wed, 16 Oct 2013 13:13:52 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "wang.cui1@zte.com.cn" Subject: RE: RE: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt Thread-Topic: RE: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt Thread-Index: AQHOxoqNBqBW1TxfPE2/cDOKCCsJ/pn3AxUAgABSQJA= Date: Wed, 16 Oct 2013 13:13:51 +0000 Message-ID: <6082e0ed1c734c9e9e7c1f2ffe31f0a4@BY2PR05MB079.namprd05.prod.outlook.com> References: <4832730c91be489281cb9b44941b45dd@BY2PR05MB079.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0001227049 Content-Type: multipart/alternative; boundary="_000_6082e0ed1c734c9e9e7c1f2ffe31f0a4BY2PR05MB079namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mboned@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:14:07 -0000 --_000_6082e0ed1c734c9e9e7c1f2ffe31f0a4BY2PR05MB079namprd05pro_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TGluZGEsDQoNClJEIGlzIHN0aWxsIHVzZWQsIGJ1dCBpdKGvcyBhbGwtMC4gSSBtZWFudCB0aGF0 IHRoZSB3b3JkaW5nIGFib3V0IHVzaW5nIGFueSB2YWx1ZSBmb3IgdGhlIFJEIGlzIHJlbW92ZWQu DQpSVCBpcyBzdGlsbCB1c2VkIChvcHRpb25hbCBpbiBjZXJ0YWluIGNhc2UpIKhDIHlvdaGvbGwg c2VlIHRoZSBkZXRhaWxzIG9uY2UgdGhlIG5ldyByZXZpc2lvbiBpcyBwb3N0ZWQgKHNvb24pLg0K DQpJbml0aWFsbHkgd2UgdXNlZCChsE1QTFMgQm9yZGVyIFJvdXRlcqGxIHdoaWNoIGltcGxpZXMg TVBMUyBjb3JlOyBidXQgdGhhdCBoYXMgYWxzbyBiZWVuIHJlbmFtZWQgKGFuZCBNUExTIGNvcmUg aXMgbm90IHJlcXVpcmVkKS4NCg0KSmVmZnJleQ0KDQpGcm9tOiB3YW5nLmN1aTFAenRlLmNvbS5j biBbbWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuXQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVy IDE2LCAyMDEzIDQ6MTcgQU0NClRvOiBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZw0KQ2M6IG1ib25l ZEBpZXRmLm9yZzsgbDN2cG5AaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6IFJFOiBbTUJPTkVEXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLWdsb2Jh bC10YWJsZS1tY2FzdC0wMC50eHQNCg0KDQpIaSxKZWZmcmV5DQoNCiAgU2VlIGJlbG93IGlubGlu ZS4NCg0KICBJZiBJIG1pc3Mgc29tZXRoaW5nIHBsZWFzZSBwb2ludCBvdXQuVGhhbmtzIQ0KDQpC UnMsDQpMaW5kYSBXYW5nDQoNCg0KIkplZmZyZXkgKFpoYW9odWkpIFpoYW5nIiA8enpoYW5nQGp1 bmlwZXIubmV0PG1haWx0bzp6emhhbmdAanVuaXBlci5uZXQ+PiDQtNPaIDIwMTMtMTAtMTEgMjI6 MDI6NDI6DQoNCj4gTGluZGEsDQo+DQo+IEJhc2UgTVZQTiBwcm90b2NvbCBhbGxvd3MgdG8gaGF2 ZSBkaWZmZXJlbnQgUkRzIGFuZCBzYW1lIGlzIGhlcmUuDQovL0xpbmRhOiBTb3JyeSBmb3IgbWlz dGFraW5nIFJEIHRvIFJULg0KPiBJbiBhIG5ld2VyIHJldmlzaW9uIG9mIHRoZSBkcmFmdCAodG8g YmUgc3VibWl0dGVkKSwgd2UgaGF2ZSBhY3R1YWxseQ0KPiByZW1vdmVkIHRoYXQgd29yZGluZywg YmVjYXVzZSB3aGlsZSBpdCBpcyBvayB0byB1c2Ugbm9uLXplcm8gUkRzIGl0DQo+IGRvZXMgbm90 IGFkZCBhbnkgb2J2aW91cyB2YWx1ZS4gVGhlIG9yaWdpbmFsIHRleHQgd2FzIHRvIHNob3cgdGhh dA0KPiBleGlzdGluZyBNVlBOIHByb2NlZHVyZXMgY2FuIGJlIHVzZWQgYXMgaXMgKHdlbGwsIHdp dGggc29tZSBtaW5vcg0KPiBleGNlcHRzIHRoYXQgd2VyZSBzcGVsbGVkIG91dCkuDQovL0xpbmRh o7p5b3UnbGwgcmVtb3ZlIFJEIHdvcmRpbmc/IFllcyxhZ3JlZSBmb3IgcmVtb3ZlIFJEIGZpZWxk IGluIGFsbCBBLUQgUm91dGVzIGluIHRoZSBjb250ZXh0IG9mIEdUTS4gQnV0IHdoYXQgYWJvdXQg UlQ/IERvIHlvdSBzdGlsbCB3YW50IHRvIHJlbWFpbiBSVD8gSWYgd2UgcmVtb3ZlIFJULHRoZXJl IGFyZSBubyB0aGUgcXVlc3Rpb25zIHlvdSBtZW50aW9uZWQgaW4gU2VjdGlvbiAzLjMuDQoNCi8v TGluZGE6IEFsc28sIEkgc2F3IE1CUihNUExTIEJvcmRlciBSb3V0ZXIpIGlzIGNhbGxlZCBpbiB5 b3VyIGRyYWZ0LCBkb2VzIGl0IG1lYW4gdGhlIGNvcmUgbmV0d29yayBtdXN0IGJlIE1QTFMtZW5h YmxlPw0KDQo+IFRoYW5rcy4NCj4gSmVmZnJleQ0KPg0KPiBGcm9tOiB3YW5nLmN1aTFAenRlLmNv bS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+IFttYWlsdG86d2FuZy5jdWkxQHp0ZS5j b20uY25dDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxMSwgMjAxMyA0OjI0IEFNDQo+IFRvOiBK ZWZmcmV5IChaaGFvaHVpKSBaaGFuZw0KPiBDYzogbWJvbmVkQGlldGYub3JnPG1haWx0bzptYm9u ZWRAaWV0Zi5vcmc+OyBsM3ZwbkBpZXRmLm9yZzxtYWlsdG86bDN2cG5AaWV0Zi5vcmc+DQo+IFN1 YmplY3Q6IFJlOiBbTUJPTkVEXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp6 aGFuZy0NCj4gbDN2cG4tbXZwbi1nbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0DQo+DQo+DQo+IEhp LEplZmZyZXkNCj4NCj4gICBTZWN0aW9uIDMgc2FpZDoNCj4NCj4gICAgUkZDIDY1MTQgc3BlY2lm aWVzIHRoYXQgTUNBU1QtVlBOIHJvdXRlcyBjYXJyeSBhIFJvdXRlIERpc3Rpbmd1aXNoZXINCj4g ICAoUkQpLiAgRm9yIEdUTSwgaXQgU0hPVUxEIGJlIHBvc3NpYmxlIHRvIGNvbmZpZ3VyZSBhbiBS RCB0aGF0IGlzIHVzZWQNCj4gICBvbmx5IGZvciBNQ0FTVC1WUE4gQS1EIHJvdXRlcyBmb3IgdGhl IGdsb2JhbCB0YWJsZS4gIFRoZSBSRCBjYW4gYmUNCj4gICBkZWZhdWx0ZWQgdG8gYSBzcGVjaWFs IDY0LWJpdCBhbGwtemVybyB2YWx1ZSAoZGVub3RlZCBhcyBSRCAwOjApLg0KPg0KPiBUaGlzIG1l YW5zIHdlIGNhbiBjb25maWd1cmUgdGhlIFJEIHdoZW4gR1RNIGlzIGVuYWJsZSwgcmlnaHQ/DQo+ IEhlcmUgaXMgYSBxdWVzdGlvbjogSW4gYSBsYXJnZSBuZXR3b3JrLCB0aGVyZSBhcmUgbWFueSBk aWZmZXJlbnQNCj4gYWRtaW5pc3RyYXRvcnMsd2hhdCBpZiBhZG1pbjEgY29uZmlndXJlcyB0aGUg dmFsdWUgMToxIGluIGhpcyBtYW5hZ2UNCj4gYXJlYShhcmVhMSksIGFuZCBhZG1pbjIgY29uZmln dXJlcyB0aGUgdmFsdXJlIDI6MiBpbiBhbm90aGVyIGFyZWEoYXJlYTIpPw0KPg0KPiBJZiBJIG1p c3Mgc29tZXRoaW5nIHBsZWFzZSBwb2ludCBvdXQuVGhhbmtzIQ0KPg0KPiBCUnMNCj4gTGluZGEg V2FuZw0KPg0KPg0KPg0KPg0KPg0KPiA+IEhpLA0KPiA+DQo+ID4gVGhpcyBpcyBhbiB1cGRhdGUg dG8gZHJhZnQtenpoYW5nLW1ib25lZC1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC4NCj4gPg0K PiA+IFdlIGhhdmUgcmUtaG9tZWQgaXQgdG8gbDN2cG4sIGFuZCBob3BlZnVsbHkgYWRkcmVzc2Vk IG1vc3QgY29tbWVudHMNCj4gPiB0aGF0IEVyaWMgaGFkLg0KPiA+DQo+ID4gWW91ciByZXZpZXcg YW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IFRoYW5rcy4NCj4gPiBKZWZm cmV5DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGludGVy bmV0LWRyYWZ0cyBhdCBpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9y Z10NCj4gPiBTZW50OiBGcmlkYXksIEp1bHkgMTIsIDIwMTMgMzo1NSBQTQ0KPiA+IFRvOiBEYW50 ZSBKLlBhY2VsbGE7IExlbm55IEdpdWxpYW5vOyBKYXNvbiBTY2hpbGxlcjsgTGVubnkgR2l1bGlh bm87DQo+ID4gSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcNCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLQ0KPiA+IGdsb2JhbC10 YWJsZS1tY2FzdC0wMC50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC50eHQNCj4gPiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEplZmZyZXkgWmhhbmcgYW5kIHBvc3RlZCB0 byB0aGUNCj4gPiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBGaWxlbmFtZTogICAgZHJhZnQt enpoYW5nLWwzdnBuLW12cG4tZ2xvYmFsLXRhYmxlLW1jYXN0DQo+ID4gUmV2aXNpb246ICAgIDAw DQo+ID4gVGl0bGU6ICAgICAgIEdsb2JhbCBUYWJsZSBNdWx0aWNhc3Qgd2l0aCBCR1AtTVZQTiBQ cm9jZWR1cmVzDQo+ID4gQ3JlYXRpb24gZGF0ZTogICAgMjAxMy0wNy0xMg0KPiA+IEdyb3VwOiAg ICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBOdW1iZXIgb2YgcGFnZXM6IDE0DQo+ID4g VVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC16emhhbmctDQo+ID4gbDN2cG4tbXZwbi1nbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0DQo+ID4g U3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXp6 aGFuZy1sM3Zwbi0NCj4gPiBtdnBuLWdsb2JhbC10YWJsZS1tY2FzdA0KPiA+IEh0bWxpemVkOiAg ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtenpoYW5nLWwzdnBuLW12cG4t DQo+ID4gZ2xvYmFsLXRhYmxlLW1jYXN0LTAwDQo+ID4NCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgd2F5IHRvIGltcGxlbWVudCBHbG9iYWwgVGFi bGUgTXVsdGljYXN0LA0KPiA+ICAgIGFrYSBJbnRlcm5ldCBNdWx0aWNhc3QsIHVzaW5nIEJHUCBl bmNvZGluZ3MgYW5kIHByb2NlZHVyZXMgZm9yIE1WUE4NCj4gPiAgICBhcyBzcGVjaWZpZWQgaW4g W1JGQzY1MTRdLg0KPiA+DQo+ID4gICAgTm8gcHJvdG9jb2wgbW9kaWZpY2F0aW9uL2V4dGVuc2lv biBpcyByZXF1aXJlZC4gIFRoaXMgaXMgcHVyZWx5IGZvcg0KPiA+ICAgIGluZm9ybWF0aW9uYWwg YW5kIGNsYXJpZnlpbmcgcHVycG9zZXMgb25seS4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRo ZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4NCj4gPg0KPiA+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPiBt YWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVn ZWQgYW5kDQo+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUg dXNlIG9mIHRoZQ0KPiBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLA0KPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBv ciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUNCj4gaW5mb3JtYXRpb24gY29udGFp bmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPiB0aGlz IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVs eS4NCj4NCj4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMg aW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5 b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlm eSB1cyBpbW1lZGlhdGVseS4NCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55 IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZp ZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRy ZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNj bG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9u IG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxl dGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KDQoNCg== --_000_6082e0ed1c734c9e9e7c1f2ffe31f0a4BY2PR05MB079namprd05pro_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Linda,<= /p>

 <= /p>

RD is still used, but it= =A1=AFs all-0. I meant that the wording about using any value for the RD is= removed.

RT is still used (optiona= l in certain case) =A8C you=A1=AFll see the details once the new revision i= s posted (soon).

 <= /p>

Initially we used =A1=B0M= PLS Border Router=A1=B1 which implies MPLS core; but that has also been ren= amed (and MPLS core is not required).

 <= /p>

Jeffrey=

 <= /p>

From: wang.cui= 1@zte.com.cn [mailto:wang.cui1@zte.com.cn]
Sent: Wednesday, October 16, 2013 4:17 AM
To: Jeffrey (Zhaohui) Zhang
Cc: mboned@ietf.org; l3vpn@ietf.org
Subject: =B4= =F0=B8=B4: RE: [MBONED] New Version Notification for dra= ft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt

 


Hi,Jeffrey

  See below inline.

  If I miss something please point out.Thanks!

BRs,
Linda Wang


"Jeffrey (Zhaohui) Zhang" &l= t;zzhang@juniper.net> =D0=B4=D3=DA 2013-10-11 22:02:42:

> Linda,
>  
> Base MVPN protocol allows to have= different RDs and same is here.
//Linda: Sorry for mistaking RD to RT.
> In a newer revision of the draft = (to be submitted), we have actually
> removed that wording, because while it is ok to use non-zero RDs i= t
> does not add any obvious value. The original text was to show that=
> existing MVPN procedures can be used as is (well, with some minor =
> excepts that were spelled out).
//Linda=A3=BA<= /span>you'll remove RD wording? Yes,agree for remove RD field in all A-D Ro= utes in the context of GTM. But what about RT? Do you still want to remain = RT? If we remove RT,there are no the questions you mentioned in Section 3.3.

//Linda: Also, <= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if"">I saw MBR(MPLS Border Router) is called in your draft, does it me= an the core network must be MPLS-enable?

> Thanks.
> Jeffrey
>  
> From: wang.cui1@zte.com.cn [mailto:wa= ng.cui1@zte.com.cn]
> Sent: Friday, October 11, 2013 4:24 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: mboned@ietf.org; l3vpn@ietf.org
> Subject: Re: [MBONED] New Version Notification for draft-zzhang-
> l3vpn-mvpn-global-table-mcast-00.txt
>  
>
> Hi,Jeffrey
>
>   Section 3 said:
>
>    RFC 6514 specifies that MCAST-VPN routes carry a Rout= e Distinguisher
>   (RD).  For GTM, it SHOULD be possible to configure an = RD that is used
>   only for MCAST-VPN A-D routes for the global table.  T= he RD can be
>   defaulted to a special 64-bit all-zero value (denoted as RD= 0:0).
>  
> This means we can configure the RD when GTM is enable, right?
> Here is a question: In a large network, there are many different <= /tt>
> administrators,what if admin1 configures the value 1:1 in his mana= ge
> area(area1), and admin2 configures the valure 2:2 in another area(= area2)?
>
> If I miss something please point out.Thanks!
>
> BRs
> Linda Wang
>
>
>
>
>
> > Hi,
> >
> > This is an update to draft-zzhang-mboned-mvpn-global-table-mc= ast-00.
> >
> > We have re-homed it to l3vpn, and hopefully addressed most co= mments
> > that Eric had.
> >
> > Your review and comments are appreciated.
> >
> > Thanks.
> > Jeffrey
> >
> > -----Original Message-----
> > From: internet-drafts at ietf.org [mailto:internet-drafts at = ietf.org]
> > Sent: Friday, July 12, 2013 3:55 PM
> > To: Dante J.Pacella; Lenny Giuliano; Jason Schiller; Lenny Gi= uliano;
> > Jeffrey (Zhaohui) Zhang
> > Subject: New Version Notification for draft-zzhang-l3vpn-mvpn= -
> > global-table-mcast-00.txt
> >
> >
> > A new version of I-D, draft-zzhang-l3vpn-mvpn-global-table-mc= ast-00.txt
> > has been successfully submitted by Jeffrey Zhang and posted t= o the
> > IETF repository.
> >
> > Filename:    draft-zzhang-l3vpn-mvpn-global-table-m= cast
> > Revision:    00
> > Title:       Global Table Multicast with BGP-M= VPN Procedures
> > Creation date:    2013-07-12
> > Group:       Individual Submission
> > Number of pages: 14
> > URL:             http://www.ietf.org/internet-drafts/draft-zzhang-
> > l3vpn-mvpn-global-table-mcast-00.txt
> > Status:          http://datatracker.ietf.org/do= c/draft-zzhang-l3vpn-
> > mvpn-global-table-mcast
> > Htmlized:        http://tools.ietf.org/html/draft-zz= hang-l3vpn-mvpn-
> > global-table-mcast-00
> >
> >
> > Abstract:
> >    This document describes a way to implement Globa= l Table Multicast,
> >    aka Internet Multicast, using BGP encodings and = procedures for MVPN
> >    as specified in [RFC6514].
> >
> >    No protocol modification/extension is required. =  This is purely for
> >    informational and clarifying purposes only.=
> >
> >                  = ;                     &nb= sp;                     &= nbsp;              
> >
> >
> > The IETF Secretariat
> >
> >
> >
>  
> ---------------------------------= -----------------------
> ZTE Information Security Notice: = The information contained in this
> mail (and any attachment transmitted herewith) is privileged and <= /tt>
> confidential and is intended for the exclusive use of the > addressee(s).  If you are not an intended recipient, any disc= losure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have re= ceived
> this mail in error, please delete it and notify us immediately.
>  
>   

 
-------------------------------------------=
-------------
ZTE Information Security Notice: The inform=
ation contained in this mail (and any attachment transmitted herewith) is p=
rivileged and confidential and is intended for the exclusive use of the add=
ressee(s).  If you are not an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or use of the information con=
tained is strictly prohibited.  If you have received this mail in erro=
r, please delete it and notify us immediately.
 

 

 
-------------------------------------------=
-------------
ZTE Information Security Notice: The inform=
ation contained in this mail (and any attachment transmitted herewith) is p=
rivileged and confidential and is intended for the exclusive use of the add=
ressee(s).  If you are not an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or use of the information con=
tained is strictly prohibited.  If you have received this mail in erro=
r, please delete it and notify us immediately.
 

 

--_000_6082e0ed1c734c9e9e7c1f2ffe31f0a4BY2PR05MB079namprd05pro_-- From wang.cui1@zte.com.cn Wed Oct 16 18:45:27 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8076811E80F1; Wed, 16 Oct 2013 18:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.166 X-Spam-Level: X-Spam-Status: No, score=-93.166 tagged_above=-999 required=5 tests=[AWL=-3.816, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4MCjotSUpzI; Wed, 16 Oct 2013 18:45:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2089B11E8216; Wed, 16 Oct 2013 18:45:02 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 9DB241297A70; Thu, 17 Oct 2013 09:44:52 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 8D33270F2E7; Thu, 17 Oct 2013 09:44:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r9H1ikJB017084; Thu, 17 Oct 2013 09:44:46 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <6082e0ed1c734c9e9e7c1f2ffe31f0a4@BY2PR05MB079.namprd05.prod.outlook.com> To: "Jeffrey (Zhaohui) Zhang" Subject: =?GB2312?B?tPC4tDogUkU6IFJFOiBbTUJPTkVEXSBOZXcgVmVyc2lvbg==?= =?GB2312?B?IE5vdGlmaWNhdGlvbiBmb3IJZHJhZnQtenpoYW5nLWwzdnBuLW12cG4t?= =?GB2312?B?Z2xvYmFsLXRhYmxlLW1jYXN0LTAwLnR4dA==?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Thu, 17 Oct 2013 09:44:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-10-17 09:44:27, Serialize complete at 2013-10-17 09:44:27 Content-Type: multipart/alternative; boundary="=_alternative 0009A4A848257C07_=" X-MAIL: mse01.zte.com.cn r9H1ikJB017084 Cc: "mboned@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 01:45:33 -0000 This is a multipart message in MIME format. --=_alternative 0009A4A848257C07_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksSmVmZnJleQ0KDQogIEV4cGVjdGluZyBmb3IgeW91ciB1cGRhdGVkIHZlcnNpb24uDQoNCiAg QnV0IEkgc3RpbGwgaW5zaXN0IHRvIHJlbW92ZSBSRCZSVCwgbGlrZSBpbiBteSBkcmFmdCANCmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1tYm9uZWQtZ2xvLWlwdjYt bWNhc3QtcmVhY2hhYmlsaXR5LyxpbiANCndoaWNoIHdlIGRlZmluZSBhIG5ldyBOTFJJLiANCiAg VGhlIGFkdmFudGFnZSBmb3IgZGVmaW5pbmcgYSBuZXcgTkxSSSBpcyBvYnZpb3VzIGFzIGZvbGxv dzoNCg0KICAxLldpdGhvdXQgUkQ6DQogICAgYS4gQWxsIHRoZSBBLUQgcm91dGUgaXMgbW9yZSBz aW1wZXIgaW4gZW5jb2RpbmcuDQogICAgYi4gUkQgc2V0IDA6MCBkb2Vzbid0IGFkZCBhbnkgb2J2 aW91cyB2YWx1ZSwgb24gdGhlIGNvbnRyYXJ5LCBpdCBzZXQgDQowOjAgb2NjdXB5cyBhIGxpdHRs ZSBzcGFjZSBvZiBWUkYgUkQuIA0KDQogIDIuV2l0aG91dCBSVDoNCiAgICBhLiBUaGVyZSBhcmUg bm8gcXVlc3Rpb25zIHlvdSBtZW50aW9uZWQgaW4gc2VjdGlvbiAzLjMuDQogICAgYi4gV2UgY2Fu IHJlbW92ZSBWUkYgUm91dGUgSW1wb3J0IEV4dGVuZGVkIENvbW11bml0eSBhcyB3ZSBkZWZpbmUg YSANCm5ldyBOTFJJIHdpdGhvdXQgUkQmUlQgY29uY2VwdGlvbi4NCg0KICAzLkdsb2JhbCBtdWx0 aWNhc3QgcmVhY2hhYmlsaXR5IGlzIG5vdCBnb2luZyB0byBhZ2dyZWdhdGUsc28gd2UgY2FuIA0K cmVtb3ZlIHRoZSBNUExTIExhYmVsIGZpZWxkIGluIFBNU0kgVHVubmVsIEF0dHJpYnV0ZSB0byBz aW1wbGUgdGhlIA0KZW5jb2RpbmcuDQoNCiAgNC5JZiBwcm92aWRlcnMganVzdCB3YW50IHRvIGVu YWJsZSBHbG9iYWwgTXVsdGljYXN0IFJlYWNoYWJsaXR5IG9ubHksIA0KdGhleSBqdXN0IG5lZWQg ZW5hYmxlIE1DQVNULUlQdjYoZGVmaW5lIGluIA0KZHJhZnQtd2FuZy1tYm9uZWQtZ2xvLWlwdjYt bWNhc3QtcmVhY2hhYmlsaXR5KSBhZGRyZXNzIGZhbWlseSBvbmx5IHdpdGhvdXQgDQplbmFibGUg TUNBU1QtVlBOIGFkZHJlc3MgZmFtaWx5IHdoaWNoIG1heSBjYXVzZSB1bm5lY2Vzc2FyeSByb3V0 ZSANCmFkdmVydGlzZW1lbnRzLg0KDQogIEV4cGVjdGluZyBmdXJ0aGVyIGNvbW11bmljYXRpb24g aW4gdGhlIGNvbWluZyBtZWV0aW5nLlRoYW5rcyENCg0KQlJzLA0KTGluZGEgV2FuZw0KDQoiSmVm ZnJleSAoWmhhb2h1aSkgWmhhbmciIDx6emhhbmdAanVuaXBlci5uZXQ+INC009ogMjAxMy0xMC0x NiAyMToxMzo1MToNCg0KPiBMaW5kYSwNCj4gDQo+IFJEIGlzIHN0aWxsIHVzZWQsIGJ1dCBpdKGv cyBhbGwtMC4gSSBtZWFudCB0aGF0IHRoZSB3b3JkaW5nIGFib3V0IA0KPiB1c2luZyBhbnkgdmFs dWUgZm9yIHRoZSBSRCBpcyByZW1vdmVkLg0KPiBSVCBpcyBzdGlsbCB1c2VkIChvcHRpb25hbCBp biBjZXJ0YWluIGNhc2UpIKhDIHlvdaGvbGwgc2VlIHRoZSBkZXRhaWxzDQo+IG9uY2UgdGhlIG5l dyByZXZpc2lvbiBpcyBwb3N0ZWQgKHNvb24pLg0KPiANCj4gSW5pdGlhbGx5IHdlIHVzZWQgobBN UExTIEJvcmRlciBSb3V0ZXKhsSB3aGljaCBpbXBsaWVzIE1QTFMgY29yZTsgYnV0IA0KPiB0aGF0 IGhhcyBhbHNvIGJlZW4gcmVuYW1lZCAoYW5kIE1QTFMgY29yZSBpcyBub3QgcmVxdWlyZWQpLg0K PiANCj4gSmVmZnJleQ0KPiANCj4gRnJvbTogd2FuZy5jdWkxQHp0ZS5jb20uY24gW21haWx0bzp3 YW5nLmN1aTFAenRlLmNvbS5jbl0gDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNiwgMjAx MyA0OjE3IEFNDQo+IFRvOiBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZw0KPiBDYzogbWJvbmVkQGll dGYub3JnOyBsM3ZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiC08Li0OiBSRTogW01CT05FRF0gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC0NCj4genpoYW5nLWwzdnBuLW12cG4tZ2xv YmFsLXRhYmxlLW1jYXN0LTAwLnR4dA0KPiANCj4gDQo+IEhpLEplZmZyZXkgDQo+IA0KPiAgIFNl ZSBiZWxvdyBpbmxpbmUuIA0KPiANCj4gICBJZiBJIG1pc3Mgc29tZXRoaW5nIHBsZWFzZSBwb2lu dCBvdXQuVGhhbmtzISANCj4gDQo+IEJScywgDQo+IExpbmRhIFdhbmcgDQo+IA0KPiANCj4gIkpl ZmZyZXkgKFpoYW9odWkpIFpoYW5nIiA8enpoYW5nQGp1bmlwZXIubmV0PiDQtNPaIDIwMTMtMTAt MTEgMjI6MDI6NDI6DQo+IA0KPiA+IExpbmRhLCANCj4gPiANCj4gPiBCYXNlIE1WUE4gcHJvdG9j b2wgYWxsb3dzIHRvIGhhdmUgZGlmZmVyZW50IFJEcyBhbmQgc2FtZSBpcyBoZXJlLiANCj4gLy9M aW5kYTogU29ycnkgZm9yIG1pc3Rha2luZyBSRCB0byBSVC4gDQo+ID4gSW4gYSBuZXdlciByZXZp c2lvbiBvZiB0aGUgZHJhZnQgKHRvIGJlIHN1Ym1pdHRlZCksIHdlIGhhdmUgYWN0dWFsbHkNCj4g PiByZW1vdmVkIHRoYXQgd29yZGluZywgYmVjYXVzZSB3aGlsZSBpdCBpcyBvayB0byB1c2Ugbm9u LXplcm8gUkRzIGl0IA0KPiA+IGRvZXMgbm90IGFkZCBhbnkgb2J2aW91cyB2YWx1ZS4gVGhlIG9y aWdpbmFsIHRleHQgd2FzIHRvIHNob3cgdGhhdCANCj4gPiBleGlzdGluZyBNVlBOIHByb2NlZHVy ZXMgY2FuIGJlIHVzZWQgYXMgaXMgKHdlbGwsIHdpdGggc29tZSBtaW5vciANCj4gPiBleGNlcHRz IHRoYXQgd2VyZSBzcGVsbGVkIG91dCkuIA0KPiAvL0xpbmRho7p5b3UnbGwgcmVtb3ZlIFJEIHdv cmRpbmc/IFllcyxhZ3JlZSBmb3IgcmVtb3ZlIFJEIGZpZWxkIGluIA0KPiBhbGwgQS1EIFJvdXRl cyBpbiB0aGUgY29udGV4dCBvZiBHVE0uIEJ1dCB3aGF0IGFib3V0IFJUPyBEbyB5b3UgDQo+IHN0 aWxsIHdhbnQgdG8gcmVtYWluIFJUPyBJZiB3ZSByZW1vdmUgUlQsdGhlcmUgYXJlIG5vIHRoZSBx dWVzdGlvbnMgDQo+IHlvdSBtZW50aW9uZWQgaW4gU2VjdGlvbiAzLjMuIA0KPiANCj4gLy9MaW5k YTogQWxzbywgSSBzYXcgTUJSKE1QTFMgQm9yZGVyIFJvdXRlcikgaXMgY2FsbGVkIGluIHlvdXIg DQo+IGRyYWZ0LCBkb2VzIGl0IG1lYW4gdGhlIGNvcmUgbmV0d29yayBtdXN0IGJlIE1QTFMtZW5h YmxlPyANCj4gDQo+ID4gVGhhbmtzLiANCj4gPiBKZWZmcmV5IA0KPiA+IA0KPiA+IEZyb206IHdh bmcuY3VpMUB6dGUuY29tLmNuIFttYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY25dIA0KPiA+IFNl bnQ6IEZyaWRheSwgT2N0b2JlciAxMSwgMjAxMyA0OjI0IEFNDQo+ID4gVG86IEplZmZyZXkgKFpo YW9odWkpIFpoYW5nDQo+ID4gQ2M6IG1ib25lZEBpZXRmLm9yZzsgbDN2cG5AaWV0Zi5vcmcNCj4g PiBTdWJqZWN0OiBSZTogW01CT05FRF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC16emhhbmctDQo+ID4gbDN2cG4tbXZwbi1nbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0IA0KPiA+ IA0KPiA+IA0KPiA+IEhpLEplZmZyZXkgDQo+ID4gDQo+ID4gICBTZWN0aW9uIDMgc2FpZDogDQo+ ID4gDQo+ID4gICAgUkZDIDY1MTQgc3BlY2lmaWVzIHRoYXQgTUNBU1QtVlBOIHJvdXRlcyBjYXJy eSBhIFJvdXRlIA0KRGlzdGluZ3Vpc2hlcg0KPiA+ICAgKFJEKS4gIEZvciBHVE0sIGl0IFNIT1VM RCBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUgYW4gUkQgdGhhdCBpcyANCnVzZWQNCj4gPiAgIG9u bHkgZm9yIE1DQVNULVZQTiBBLUQgcm91dGVzIGZvciB0aGUgZ2xvYmFsIHRhYmxlLiAgVGhlIFJE IGNhbiBiZQ0KPiA+ICAgZGVmYXVsdGVkIHRvIGEgc3BlY2lhbCA2NC1iaXQgYWxsLXplcm8gdmFs dWUgKGRlbm90ZWQgYXMgUkQgMDowKS4NCj4gPiANCj4gPiBUaGlzIG1lYW5zIHdlIGNhbiBjb25m aWd1cmUgdGhlIFJEIHdoZW4gR1RNIGlzIGVuYWJsZSwgcmlnaHQ/IA0KPiA+IEhlcmUgaXMgYSBx dWVzdGlvbjogSW4gYSBsYXJnZSBuZXR3b3JrLCB0aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgDQo+ ID4gYWRtaW5pc3RyYXRvcnMsd2hhdCBpZiBhZG1pbjEgY29uZmlndXJlcyB0aGUgdmFsdWUgMTox IGluIGhpcyBtYW5hZ2UNCj4gPiBhcmVhKGFyZWExKSwgYW5kIGFkbWluMiBjb25maWd1cmVzIHRo ZSB2YWx1cmUgMjoyIGluIGFub3RoZXIgDQphcmVhKGFyZWEyKT8gDQo+ID4gDQo+ID4gSWYgSSBt aXNzIHNvbWV0aGluZyBwbGVhc2UgcG9pbnQgb3V0LlRoYW5rcyEgDQo+ID4gDQo+ID4gQlJzIA0K PiA+IExpbmRhIFdhbmcgDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gPiBIaSwN Cj4gPiA+IA0KPiA+ID4gVGhpcyBpcyBhbiB1cGRhdGUgdG8gZHJhZnQtenpoYW5nLW1ib25lZC1t dnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC4NCj4gPiA+IA0KPiA+ID4gV2UgaGF2ZSByZS1ob21l ZCBpdCB0byBsM3ZwbiwgYW5kIGhvcGVmdWxseSBhZGRyZXNzZWQgbW9zdCBjb21tZW50cyANCj4g PiA+IHRoYXQgRXJpYyBoYWQuDQo+ID4gPiANCj4gPiA+IFlvdXIgcmV2aWV3IGFuZCBjb21tZW50 cyBhcmUgYXBwcmVjaWF0ZWQuDQo+ID4gPiANCj4gPiA+IFRoYW5rcy4NCj4gPiA+IEplZmZyZXkN Cj4gPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGlu dGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0cyBhdCANCmll dGYub3JnXSANCj4gPiA+IFNlbnQ6IEZyaWRheSwgSnVseSAxMiwgMjAxMyAzOjU1IFBNDQo+ID4g PiBUbzogRGFudGUgSi5QYWNlbGxhOyBMZW5ueSBHaXVsaWFubzsgSmFzb24gU2NoaWxsZXI7IExl bm55IEdpdWxpYW5vOw0KPiA+ID4gSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcNCj4gPiA+IFN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtenpoYW5nLWwzdnBuLW12cG4t DQo+ID4gPiBnbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KZHJhZnQtenpoYW5nLWwzdnBuLW12cG4tZ2xvYmFsLXRh YmxlLW1jYXN0LTAwLnR4dA0KPiA+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBKZWZmcmV5IFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4gPiBJRVRGIHJlcG9zaXRvcnku DQo+ID4gPiANCj4gPiA+IEZpbGVuYW1lOiAgICBkcmFmdC16emhhbmctbDN2cG4tbXZwbi1nbG9i YWwtdGFibGUtbWNhc3QNCj4gPiA+IFJldmlzaW9uOiAgICAwMA0KPiA+ID4gVGl0bGU6ICAgICAg IEdsb2JhbCBUYWJsZSBNdWx0aWNhc3Qgd2l0aCBCR1AtTVZQTiBQcm9jZWR1cmVzDQo+ID4gPiBD cmVhdGlvbiBkYXRlOiAgICAyMDEzLTA3LTEyDQo+ID4gPiBHcm91cDogICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+ID4gPiBOdW1iZXIgb2YgcGFnZXM6IDE0DQo+ID4gPiBVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXp6aGFuZy0N Cj4gPiA+IGwzdnBuLW12cG4tZ2xvYmFsLXRhYmxlLW1jYXN0LTAwLnR4dA0KPiA+ID4gU3RhdHVz OiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXp6aGFuZy1s M3Zwbi0NCj4gPiA+IG12cG4tZ2xvYmFsLXRhYmxlLW1jYXN0DQo+ID4gPiBIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLQ0K PiA+ID4gZ2xvYmFsLXRhYmxlLW1jYXN0LTAwDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gQWJzdHJh Y3Q6DQo+ID4gPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHdheSB0byBpbXBsZW1lbnQg R2xvYmFsIFRhYmxlIA0KTXVsdGljYXN0LA0KPiA+ID4gICAgYWthIEludGVybmV0IE11bHRpY2Fz dCwgdXNpbmcgQkdQIGVuY29kaW5ncyBhbmQgcHJvY2VkdXJlcyBmb3IgDQpNVlBODQo+ID4gPiAg ICBhcyBzcGVjaWZpZWQgaW4gW1JGQzY1MTRdLg0KPiA+ID4gDQo+ID4gPiAgICBObyBwcm90b2Nv bCBtb2RpZmljYXRpb24vZXh0ZW5zaW9uIGlzIHJlcXVpcmVkLiAgVGhpcyBpcyBwdXJlbHkgDQpm b3INCj4gPiA+ICAgIGluZm9ybWF0aW9uYWwgYW5kIGNsYXJpZnlpbmcgcHVycG9zZXMgb25seS4N Cj4gPiA+IA0KPiA+ID4gIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IFRoZSBJRVRGIFNlY3JldGFy aWF0DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQo+ID4gWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIA0K PiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp dmlsZWdlZCBhbmQgDQo+ID4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIA0KPiA+IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFu IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsDQo+ID4gcmVwcm9kdWN0aW9uLCBk aXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiA+IGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgDQo+ID4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBu b3RpZnkgdXMgaW1tZWRpYXRlbHkuIA0KPiA+IA0KPiA+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIA0K PiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp bGVnZWQgYW5kIA0KPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVz aXZlIHVzZSBvZiB0aGUgDQo+IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsDQo+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCAN Cj4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1t ZWRpYXRlbHkuDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyANCj4gbWFpbCAoYW5kIGFueSBh dHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gY29u ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIA0K PiBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLA0KPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNz ZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgDQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+IHRoaXMgbWFpbCBpbiBl cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiANCj4g DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGlu dGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5 Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdp dGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBp bnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1 dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVs eS4NCg== --=_alternative 0009A4A848257C07_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLEplZmZyZXk8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBFeHBlY3Rpbmcg Zm9yIHlvdXIgdXBkYXRlZCB2ZXJzaW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEJ1dCBJIHN0aWxsIGluc2lzdCB0byByZW1vdmUNClJE JmFtcDtSVCwgbGlrZSBpbiBteSBkcmFmdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXdhbmctbWJvbmVkLWdsby1pcHY2LW1jYXN0LXJlYWNoYWJpbGl0eS8saW4NCndoaWNo IHdlIGRlZmluZSBhIG5ldyBOTFJJLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyBUaGUgYWR2YW50YWdlIGZvciBkZWZpbmluZyBhDQpuZXcgTkxSSSBp cyBvYnZpb3VzIGFzIGZvbGxvdzo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAxLldpdGhvdXQgUkQ6PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IGEuIEFsbCB0aGUgQS1EIHJvdXRlIGlz DQptb3JlIHNpbXBlciBpbiBlbmNvZGluZy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgYi4gUkQgc2V0IDA6MCBkb2Vzbid0DQphZGQgYW55 IG9idmlvdXMgdmFsdWUsIG9uIHRoZSBjb250cmFyeSwgaXQgc2V0IDA6MCBvY2N1cHlzIGEgbGl0 dGxlIHNwYWNlDQpvZiBWUkYgUkQuICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDIuV2l0aG91dCBSVDo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgYS4gVGhlcmUgYXJlIG5v IHF1ZXN0aW9ucw0KeW91IG1lbnRpb25lZCBpbiBzZWN0aW9uIDMuMy48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgYi4gV2UgY2FuIHJlbW92 ZSBWUkYgUm91dGUNCkltcG9ydCBFeHRlbmRlZCBDb21tdW5pdHkgYXMgd2UgZGVmaW5lIGEgbmV3 IE5MUkkgd2l0aG91dCBSRCZhbXA7UlQgY29uY2VwdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAzLkdsb2JhbCBtdWx0aWNhc3QgcmVh Y2hhYmlsaXR5DQppcyBub3QgZ29pbmcgdG8gYWdncmVnYXRlLHNvIHdlIGNhbiByZW1vdmUgdGhl IE1QTFMgTGFiZWwgZmllbGQgaW4gUE1TSQ0KVHVubmVsIEF0dHJpYnV0ZSB0byBzaW1wbGUgdGhl IGVuY29kaW5nLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7IDQuSWYgcHJvdmlkZXJzIGp1c3Qgd2FudCB0byBlbmFibGUNCkdsb2JhbCBNdWx0 aWNhc3QgUmVhY2hhYmxpdHkgb25seSwgdGhleSBqdXN0IG5lZWQgZW5hYmxlIE1DQVNULUlQdjYo ZGVmaW5lDQppbiBkcmFmdC13YW5nLW1ib25lZC1nbG8taXB2Ni1tY2FzdC1yZWFjaGFiaWxpdHkp IGFkZHJlc3MgZmFtaWx5IG9ubHkgd2l0aG91dA0KZW5hYmxlIE1DQVNULVZQTiBhZGRyZXNzIGZh bWlseSB3aGljaCBtYXkgY2F1c2UgdW5uZWNlc3Nhcnkgcm91dGUgYWR2ZXJ0aXNlbWVudHMuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgRXhw ZWN0aW5nIGZ1cnRoZXIgY29tbXVuaWNhdGlvbg0KaW4gdGhlIGNvbWluZyBtZWV0aW5nLlRoYW5r cyE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJScyw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpbmRhIFdhbmc8L2Zv bnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtKZWZmcmV5IChaaGFvaHVpKSBa aGFuZyZxdW90OyAmbHQ7enpoYW5nQGp1bmlwZXIubmV0Jmd0Ow0K0LTT2iAyMDEzLTEwLTE2IDIx OjEzOjUxOjxicj4NCjxicj4NCiZndDsgTGluZGEsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBSRCBpcyBzdGlsbCB1c2VkLCBidXQgaXShr3MgYWxsLTAuIEkgbWVhbnQgdGhhdA0KdGhlIHdv cmRpbmcgYWJvdXQgPGJyPg0KJmd0OyB1c2luZyBhbnkgdmFsdWUgZm9yIHRoZSBSRCBpcyByZW1v dmVkLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBSVCBpcyBzdGlsbCB1 c2VkIChvcHRpb25hbCBpbiBjZXJ0YWluIGNhc2UpIKhDDQp5b3Whr2xsIHNlZSB0aGUgZGV0YWls czxicj4NCiZndDsgb25jZSB0aGUgbmV3IHJldmlzaW9uIGlzIHBvc3RlZCAoc29vbikuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJbml0aWFsbHkgd2UgdXNlZCChsE1QTFMgQm9yZGVyIFJv dXRlcqGxIHdoaWNoDQppbXBsaWVzIE1QTFMgY29yZTsgYnV0IDxicj4NCiZndDsgdGhhdCBoYXMg YWxzbyBiZWVuIHJlbmFtZWQgKGFuZCBNUExTIGNvcmUgaXMgbm90IHJlcXVpcmVkKS48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEplZmZyZXk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IEZyb206IHdhbmcuY3VpMUB6dGUuY29tLmNuIFttYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY25d DQo8YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNiwgMjAxMyA0OjE3IEFNPGJy Pg0KJmd0OyBUbzogSmVmZnJleSAoWmhhb2h1aSkgWmhhbmc8YnI+DQomZ3Q7IENjOiBtYm9uZWRA aWV0Zi5vcmc7IGwzdnBuQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiC08Li0OiBSRTogW01C T05FRF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC08YnI+DQomZ3Q7IHp6aGFu Zy1sM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC50eHQ8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsgSGksSmVmZnJleSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5i c3A7IFNlZSBiZWxvdyBpbmxpbmUuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgSWYgSSBt aXNzIHNvbWV0aGluZyBwbGVhc2UgcG9pbnQgb3V0LlRoYW5rcyEgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEJScywgPGJyPg0KJmd0OyBMaW5kYSBXYW5nIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZxdW90O0plZmZyZXkgKFpoYW9odWkpIFpoYW5nJnF1b3Q7ICZsdDt6emhhbmdAanVu aXBlci5uZXQmZ3Q7INC009oNCjIwMTMtMTAtMTEgMjI6MDI6NDI6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZndDsgTGluZGEsIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEJh c2UgTVZQTiBwcm90b2NvbCBhbGxvd3MgdG8gaGF2ZSBkaWZmZXJlbnQgUkRzIGFuZCBzYW1lIGlz IGhlcmUuDQo8YnI+DQomZ3Q7IC8vTGluZGE6IFNvcnJ5IGZvciBtaXN0YWtpbmcgUkQgdG8gUlQu IDxicj4NCiZndDsgJmd0OyBJbiBhIG5ld2VyIHJldmlzaW9uIG9mIHRoZSBkcmFmdCAodG8gYmUg c3VibWl0dGVkKSwgd2UgaGF2ZSBhY3R1YWxseTxicj4NCiZndDsgJmd0OyByZW1vdmVkIHRoYXQg d29yZGluZywgYmVjYXVzZSB3aGlsZSBpdCBpcyBvayB0byB1c2Ugbm9uLXplcm8NClJEcyBpdCA8 YnI+DQomZ3Q7ICZndDsgZG9lcyBub3QgYWRkIGFueSBvYnZpb3VzIHZhbHVlLiBUaGUgb3JpZ2lu YWwgdGV4dCB3YXMgdG8gc2hvdw0KdGhhdCA8YnI+DQomZ3Q7ICZndDsgZXhpc3RpbmcgTVZQTiBw cm9jZWR1cmVzIGNhbiBiZSB1c2VkIGFzIGlzICh3ZWxsLCB3aXRoIHNvbWUgbWlub3INCjxicj4N CiZndDsgJmd0OyBleGNlcHRzIHRoYXQgd2VyZSBzcGVsbGVkIG91dCkuIDxicj4NCiZndDsgLy9M aW5kYaO6eW91J2xsIHJlbW92ZSBSRCB3b3JkaW5nPyBZZXMsYWdyZWUgZm9yIHJlbW92ZSBSRCBm aWVsZA0KaW4gPGJyPg0KJmd0OyBhbGwgQS1EIFJvdXRlcyBpbiB0aGUgY29udGV4dCBvZiBHVE0u IEJ1dCB3aGF0IGFib3V0IFJUPyBEbyB5b3UgPGJyPg0KJmd0OyBzdGlsbCB3YW50IHRvIHJlbWFp biBSVD8gSWYgd2UgcmVtb3ZlIFJULHRoZXJlIGFyZSBubyB0aGUgcXVlc3Rpb25zDQo8YnI+DQom Z3Q7IHlvdSBtZW50aW9uZWQgaW4gU2VjdGlvbiAzLjMuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAv L0xpbmRhOiBBbHNvLCBJIHNhdyBNQlIoTVBMUyBCb3JkZXIgUm91dGVyKSBpcyBjYWxsZWQgaW4g eW91ciA8YnI+DQomZ3Q7IGRyYWZ0LCBkb2VzIGl0IG1lYW4gdGhlIGNvcmUgbmV0d29yayBtdXN0 IGJlIE1QTFMtZW5hYmxlPyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MuIDxicj4N CiZndDsgJmd0OyBKZWZmcmV5IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7 IEZyb206IHdhbmcuY3VpMUB6dGUuY29tLmNuIFttYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY25d IDxicj4NCiZndDsgJmd0OyBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTEsIDIwMTMgNDoyNCBBTTxi cj4NCiZndDsgJmd0OyBUbzogSmVmZnJleSAoWmhhb2h1aSkgWmhhbmc8YnI+DQomZ3Q7ICZndDsg Q2M6IG1ib25lZEBpZXRmLm9yZzsgbDN2cG5AaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgU3ViamVj dDogUmU6IFtNQk9ORURdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtenpoYW5n LTxicj4NCiZndDsgJmd0OyBsM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC50eHQgPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpLEpl ZmZyZXkgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgU2VjdGlvbiAzIHNh aWQ6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1JGQyA2NTE0 IHNwZWNpZmllcyB0aGF0IE1DQVNULVZQTiByb3V0ZXMgY2FycnkgYQ0KUm91dGUgRGlzdGluZ3Vp c2hlcjxicj4NCiZndDsgJmd0OyAmbmJzcDsgKFJEKS4gJm5ic3A7Rm9yIEdUTSwgaXQgU0hPVUxE IGJlIHBvc3NpYmxlIHRvIGNvbmZpZ3VyZQ0KYW4gUkQgdGhhdCBpcyB1c2VkPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyBvbmx5IGZvciBNQ0FTVC1WUE4gQS1EIHJvdXRlcyBmb3IgdGhlIGdsb2JhbCB0 YWJsZS4gJm5ic3A7VGhlDQpSRCBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IGRlZmF1bHRl ZCB0byBhIHNwZWNpYWwgNjQtYml0IGFsbC16ZXJvIHZhbHVlIChkZW5vdGVkDQphcyBSRCAwOjAp Ljxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgbWVhbnMgd2UgY2Fu IGNvbmZpZ3VyZSB0aGUgUkQgd2hlbiBHVE0gaXMgZW5hYmxlLCByaWdodD8NCjxicj4NCiZndDsg Jmd0OyBIZXJlIGlzIGEgcXVlc3Rpb246IEluIGEgbGFyZ2UgbmV0d29yaywgdGhlcmUgYXJlIG1h bnkgZGlmZmVyZW50DQo8YnI+DQomZ3Q7ICZndDsgYWRtaW5pc3RyYXRvcnMsd2hhdCBpZiBhZG1p bjEgY29uZmlndXJlcyB0aGUgdmFsdWUgMToxIGluIGhpcw0KbWFuYWdlPGJyPg0KJmd0OyAmZ3Q7 IGFyZWEoYXJlYTEpLCBhbmQgYWRtaW4yIGNvbmZpZ3VyZXMgdGhlIHZhbHVyZSAyOjIgaW4gYW5v dGhlcg0KYXJlYShhcmVhMik/IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSWYgSSBt aXNzIHNvbWV0aGluZyBwbGVhc2UgcG9pbnQgb3V0LlRoYW5rcyEgPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBCUnMgPGJyPg0KJmd0OyAmZ3Q7IExpbmRhIFdhbmcgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGlzIGlzIGFuIHVwZGF0ZSB0byBkcmFmdC16emhhbmctbWJv bmVkLW12cG4tZ2xvYmFsLXRhYmxlLW1jYXN0LTAwLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IFdlIGhhdmUgcmUtaG9tZWQgaXQgdG8gbDN2cG4sIGFuZCBob3BlZnVs bHkgYWRkcmVzc2VkIG1vc3QNCmNvbW1lbnRzIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoYXQgRXJp YyBoYWQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgWW91ciByZXZp ZXcgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBUaGFua3MuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSmVmZnJleTxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogaW50ZXJuZXQtZHJhZnRzIGF0IGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzDQphdCBpZXRmLm9yZ10gPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgU2VudDogRnJpZGF5LCBKdWx5IDEyLCAyMDEzIDM6NTUgUE08YnI+DQomZ3Q7ICZndDsg Jmd0OyBUbzogRGFudGUgSi5QYWNlbGxhOyBMZW5ueSBHaXVsaWFubzsgSmFzb24gU2NoaWxsZXI7 IExlbm55DQpHaXVsaWFubzs8YnI+DQomZ3Q7ICZndDsgJmd0OyBKZWZmcmV5IChaaGFvaHVpKSBa aGFuZzxicj4NCiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtenpoYW5nLWwzdnBuLW12cG4tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZ2xvYmFs LXRhYmxlLW1jYXN0LTAwLnR4dDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16emhh bmctbDN2cG4tbXZwbi1nbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKZWZmcmV5IFpoYW5nIGFuZCBw b3N0ZWQNCnRvIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IElFVEYgcmVwb3NpdG9yeS48YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBGaWxlbmFtZTogJm5ic3A7ICZuYnNw O2RyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdDxicj4NCiZndDsgJmd0 OyAmZ3Q7IFJldmlzaW9uOiAmbmJzcDsgJm5ic3A7MDA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaXRs ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgR2xvYmFsIFRhYmxlIE11bHRpY2FzdCB3aXRoDQpCR1At TVZQTiBQcm9jZWR1cmVzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ3JlYXRpb24gZGF0ZTogJm5ic3A7 ICZuYnNwOzIwMTMtMDctMTI8YnI+DQomZ3Q7ICZndDsgJmd0OyBHcm91cDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTnVtYmVy IG9mIHBhZ2VzOiAxNDxicj4NCiZndDsgJmd0OyAmZ3Q7IFVSTDogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtenpoYW5nLTxicj4NCiZndDsgJmd0OyAmZ3Q7IGwzdnBuLW12cG4tZ2xvYmFsLXRh YmxlLW1jYXN0LTAwLnR4dDxicj4NCiZndDsgJmd0OyAmZ3Q7IFN0YXR1czogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtenpoYW5nLWwzdnBuLTxicj4NCiZndDsgJmd0OyAmZ3Q7IG12cG4tZ2xvYmFsLXRhYmxlLW1j YXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLTxi cj4NCiZndDsgJmd0OyAmZ3Q7IGdsb2JhbC10YWJsZS1tY2FzdC0wMDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFic3RyYWN0Ojxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IHdheSB0byBpbXBsZW1lbnQNCkdsb2JhbCBUYWJsZSBNdWx0aWNhc3QsPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwO2FrYSBJbnRlcm5ldCBNdWx0aWNhc3QsIHVzaW5nIEJHUCBlbmNv ZGluZ3MNCmFuZCBwcm9jZWR1cmVzIGZvciBNVlBOPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwO2FzIHNwZWNpZmllZCBpbiBbUkZDNjUxNF0uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO05vIHByb3RvY29sIG1vZGlmaWNhdGlvbi9l eHRlbnNpb24gaXMgcmVxdWlyZWQuDQombmJzcDtUaGlzIGlzIHB1cmVseSBmb3I8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7aW5mb3JtYXRpb25hbCBhbmQgY2xhcmlmeWluZyBwdXJw b3NlcyBvbmx5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KJmd0OyAmZ3Q7 IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4NCnRoaXMgPGJyPg0KJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0OyBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgPGJy Pg0KJmd0OyAmZ3Q7IGFkZHJlc3NlZShzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5k ZWQgcmVjaXBpZW50LCBhbnkNCmRpc2Nsb3N1cmUsPGJyPg0KJmd0OyAmZ3Q7IHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZQ0KPGJy Pg0KJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk LiAmbmJzcDtJZiB5b3UgaGF2ZQ0KcmVjZWl2ZWQgPGJyPg0KJmd0OyAmZ3Q7IHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uDQpjb250YWluZWQg aW4gdGhpcyA8YnI+DQomZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBo ZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0OyBjb25maWRlbnRpYWwgYW5kIGlz IGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBhZGRyZXNz ZWUocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRp c2Nsb3N1cmUsPGJyPg0KJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBk aXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxi cj4NCiZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dXMgaW1tZWRpYXRlbHkuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZu YnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbg0KY29u dGFpbmVkIGluIHRoaXMgPGJyPg0KJmd0OyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNt aXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIDxicj4NCiZndDsgY29uZmlkZW50aWFs IGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIDxicj4NCiZndDsg YWRkcmVzc2VlKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNjbG9zdXJlLDxicj4NCiZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Ig b3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZndDsgaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlIHJlY2Vp dmVkDQo8YnI+DQomZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg bm90aWZ5IHVzIGltbWVkaWF0ZWx5LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxl Z2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVz ZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBp ZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIg ZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9y LCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48 L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2Vk IGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBv ZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50 LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlz c2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBw bGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3By ZT48YnI+DQo= --=_alternative 0009A4A848257C07_=-- From jeff.tantsura@ericsson.com Thu Oct 17 03:12:13 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2615D11E8283 for ; Thu, 17 Oct 2013 03:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps0TQAsNZ4Bu for ; Thu, 17 Oct 2013 03:12:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A2DC011E8285 for ; Thu, 17 Oct 2013 03:12:04 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-14-525fb7f3357c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 94.33.03458.3F7BF525; Thu, 17 Oct 2013 12:12:03 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Thu, 17 Oct 2013 06:12:03 -0400 From: Jeff Tantsura To: Martin Vigoureux , "l3vpn@ietf.org" Subject: RE: Please read and comment [Re: WG Last Call for draft-ietf-l3vpn-mldp-vrf-in-band-signaling] Thread-Topic: Please read and comment [Re: WG Last Call for draft-ietf-l3vpn-mldp-vrf-in-band-signaling] Thread-Index: AQHOyne20OEnf7Ny/ECyIFefPmkAMZn4e2mA Date: Thu, 17 Oct 2013 10:12:03 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839963447@eusaamb109.ericsson.se> In-Reply-To: <6B94C2A0-14BB-4D1E-9650-29B22433E493@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <35EA614502B83C4DABDAD117CFF1CF74@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPrO7n7fFBBhMvGlqcne9vcWfXF1YH Jo/WZ3tZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXH36CKWggfiFSv7TrA0MN4U7mLk5JAQMJHY +mQqE4QtJnHh3nq2LkYuDiGBo4wSyx51skA4yxklnvy6xAJSxSZgIPH/23EwW0QgXuLque9g trBApkTj8k/sEPEsiR1nlrNC2EYSB/5eAKthEVCVuLhpKhuIzSvgLfHq8zWwzZwCthL/rr4B 62UEuuL7qTVgcWYBcYlbT+ZDXScgsWTPeWYIW1Ti5eN/YPNFBfQk2o6dYYeIK0ssebKfBaJX T+LG1ClAuziAbGuJ1jmpEGFtiWULXzNDnCAocXLmE5YJjGKzkGybhaR7FkL3LCTds5B0L2Bk XcXIUVqcWpabbmS4iREYOcck2Bx3MC74ZHmIUZqDRUmc98tb5yAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjOJ1LMdzera6zc2zWc9mtuyQzWK/uw/fu/2bxj3rvcG3V1nHI/vdXrx2VLuh IJuuHdPSPa+mkufidd1HrHIu9Rv99t7gzxfV9Fqwb9uPF8umKRSsrU8rSJQQybp8qcGqiGmj de9/5Sve3kJLJ7yc3KmrH+/xc9VLva39L/M0dNcuCjOZqz6RTYmlOCPRUIu5qDgRABLPhKpq AgAA X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 10:12:13 -0000 Hi, After publishing RFC6826 draft-ietf-l3vpn-mldp-vrf-in-band-signaling is a logical and very much needed addition to cover specific mVPN cases. References to draft-ietf-mpls-mldp-in-band-signaling should be updated to refer to RFC6826 The draft is well written, mature and ready for wglc. Cheers, Jeff > >> From: Martin Vigoureux >> Subject: Please read and comment [Re: WG Last Call for >>draft-ietf-l3vpn-mldp-vrf-in-band-signaling] >> Date: 15 Oct 2013 16:25:57 GMT+02:00 >> To: >> Cc: 'L3VPN Chairs' >>=20 >> Working Group, >>=20 >> we did not formally close this WG LC. There are few reasons to that. >>=20 >> * We are expecting an IPR disclosure, which would come quite late but >>which on the other hand had been communicated by Ice at the time of WG >>adoption. >>=20 >> * No comments were expressed during this LC. While I am fine with not >>seeing comments requiring (substantial) changes, I am not satisfied with >>complete silence. >> We have asked for a review of the document to be performed by a member >>of the Routing Directorate, but we are encouraging you to review and >>comment on the document until the 25th of October. >>=20 >> Thank you >>=20 >> Martin, for the L3VPN Chairs >>=20 >>=20 >> Le 21/08/2013 16:47, thomas.morin@orange.com a =E9crit : >>> Hello working group, >>>=20 >>> This email starts a two-week Working Group Last Call on >>> draft-ietf-l3vpn-mldp-vrf-in-band-signaling, which is considered mature >>> and ready for a working group review. >>>=20 >>> http://tools.ietf.org/html/draft-ietf-l3vpn-mldp-vrf-in-band-signaling >>>=20 >>> Please read the document if you haven't read the most recent version, >>> and send your comments to the list, no later than Wednesday September >>>4th. >>>=20 >>> Thank you, >>>=20 >>> -Thomas & Martin >>>=20 >>>=20 >>>________________________________________________________________________ >>>_________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>>confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>messages electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, >>>deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>>privileged information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>>delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>>been modified, changed or falsified. >>> Thank you. >>>=20 > From lucy.yong@huawei.com Thu Oct 17 09:32:49 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF3011E8298; Thu, 17 Oct 2013 09:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB1HOnOUbm2B; Thu, 17 Oct 2013 09:32:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9176E11E8291; Thu, 17 Oct 2013 09:32:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZE35666; Thu, 17 Oct 2013 16:32:26 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 17:31:29 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 17:32:25 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Thu, 17 Oct 2013 09:32:22 -0700 From: Lucy yong To: "l3vpn@ietf.org" , "nvo3@ietf.org" Subject: FW: New Version Notification for draft-yong-l3vpn-nvgre-vxlan-encap-03.txt Thread-Topic: New Version Notification for draft-yong-l3vpn-nvgre-vxlan-encap-03.txt Thread-Index: AQHOy1VmA9VX7+R39EKMpPQKtszUk5n5FYnQ Date: Thu, 17 Oct 2013 16:32:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D7757@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:32:49 -0000 RllJLiBXZSB1cGRhdGVkIHRoaXMgZHJhZnQgYW5kIGxpa2UgdG8gcHJlc2VudCBpdCBpbiBib3Ro IGwzdnBuIGFuZCBudm8zIFdHcyBpbiBJRVRGODguDQpZb3VyIGNvbW1lbnRzIGFyZSB3ZWxjb21l Lg0KDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDog VGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTMgMTE6MjQgQU0NClRvOiBMdWN5IHlvbmc7IFh1eGlh b2h1OyBYdXhpYW9odQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC15b25nLWwzdnBuLW52Z3JlLXZ4bGFuLWVuY2FwLTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC15b25nLWwzdnBuLW52Z3JlLXZ4bGFuLWVuY2FwLTAzLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWN5IFlvbmcgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXlvbmctbDN2cG4tbnZncmUtdnhs YW4tZW5jYXANClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIE5WR1JFIGFuZCBWWExBTiBFbmNhcHN1 bGF0aW9uIEV4dGVuc2lvbiBmb3IgTDMgT3ZlcmxheQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAt MTcNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA1DQpV Ukw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXlvbmctbDN2cG4tbnZncmUtdnhsYW4tZW5jYXAtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteW9uZy1sM3Zwbi1udmdyZS12eGxh bi1lbmNhcA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC15b25nLWwzdnBuLW52Z3JlLXZ4bGFuLWVuY2FwLTAzDQpEaWZmOiAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXlvbmctbDN2cG4tbnZncmUtdnhsYW4t ZW5jYXAtMDMNCg0KQWJzdHJhY3Q6DQogICBCb3RoIE5WR1JFIGFuZCBWWExBTiBlbmNhcHN1bGF0 aW9ucyB3ZXJlIG9yaWdpbmFsbHkgZGVzaWduZWQgZm9yIEwyDQogICBvdmVybGF5IG9ubHkuIFRo aXMgZHJhZnQgcHJvcG9zZXMgdGhlIGVuaGFuY2VtZW50IG9uIGJvdGggdG8gc3VwcG9ydA0KICAg TDMgb3ZlcmxheSBhcyB3ZWxsLiBUaGUgcHJvcG9zZWQgbWV0aG9kIGNvbXBsZXRlbHkgZGVjb3Vw bGVzIHRoZSBMMw0KICAgb3ZlcmxheSBmcm9tIHRoZSBMMiBvdmVybGF5IGluIHRlcm1zIG9mIGVu Y29kaW5nIHNjaGVtYSBhbmQgZGF0YQ0KICAgcHJvY2Vzc2luZy4NCg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From ietf-ipr@ietf.org Thu Oct 17 10:14:09 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B763311E829C; Thu, 17 Oct 2013 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRBenPjt0saX; Thu, 17 Oct 2013 10:14:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F6111E82A2; Thu, 17 Oct 2013 10:14:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ice@cisco.com, paul.hitchen@bt.com, n.leymann@telekom.de, wim.henderickx@alcatel-lucent.com, arkadiy.gulko@thomsonreuters.com Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01 X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017171408.20817.38127.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 10:14:08 -0700 Cc: l3vpn@ietf.org, adrian@olddog.co.uk, thomas.morin@orange.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:14:09 -0000 Dear IJsbrand Wijnands, Paul Hitchen, Nicolai Leymann, Wim Henderickx, arka= diy.gulko@thomsonreuters.com: An IPR disclosure that pertains to your Internet-Draft entitled "Multipoint Label Distribution Protocol In-Band Signaling in a VRF Context" (draft-ietf- l3vpn-mldp-vrf-in-band-signaling) was submitted to the IETF Secretariat on 2013-10-17 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/2216/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-l3vpn-mldp-vr= f-in- band-signaling-01.""); The IETF Secretariat From rbonica@juniper.net Fri Oct 18 08:42:26 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA45A11E81CB for ; Fri, 18 Oct 2013 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj8ahnkyiXjE for ; Fri, 18 Oct 2013 08:42:21 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8F11E810F for ; Fri, 18 Oct 2013 08:42:18 -0700 (PDT) Received: from mail45-db9-R.bigfish.com (10.174.16.237) by DB9EHSOBE036.bigfish.com (10.174.14.99) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Oct 2013 15:42:17 +0000 Received: from mail45-db9 (localhost [127.0.0.1]) by mail45-db9-R.bigfish.com (Postfix) with ESMTP id 397AC480160; Fri, 18 Oct 2013 15:42:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzdb82h98dI9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068h8275bhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail45-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(51704005)(199002)(377424004)(13464003)(24454002)(377454003)(46102001)(56816003)(69226001)(77096001)(53806001)(54316002)(63696002)(74876001)(66066001)(65816001)(15975445006)(80022001)(561944002)(76482001)(83072001)(51856001)(54356001)(81816001)(15202345003)(74706001)(56776001)(4396001)(74502001)(81686001)(74662001)(47446002)(59766001)(79102001)(81542001)(77982001)(47976001)(50986001)(49866001)(85306002)(47736001)(31966008)(81342001)(74366001)(33646001)(74316001)(83322001)(76786001)(80976001)(19580395003)(76576001)(76796001)(19580405001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail45-db9 (localhost.localdomain [127.0.0.1]) by mail45-db9 (MessageSwitch) id 1382110934716561_8314; Fri, 18 Oct 2013 15:42:14 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.245]) by mail45-db9.bigfish.com (Postfix) with ESMTP id A0A41780040; Fri, 18 Oct 2013 15:42:14 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Oct 2013 15:42:14 +0000 Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 18 Oct 2013 15:42:14 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 18 Oct 2013 15:42:12 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.14]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.251]) with mapi id 15.00.0785.001; Fri, 18 Oct 2013 15:42:11 +0000 From: Ronald Bonica To: Robert Raszuk Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOxsd0xoF9xf3u3USD7KAUj6WJjJn6epxg Date: Fri, 18 Oct 2013 15:42:10 +0000 Message-ID: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 00032065B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 15:42:27 -0000 Robert, Thanks for your thoughtful review and comments! For the purposes of this me= ssage, we will call the solution that you propose below, the "V-Hub Solutio= n".=20 We considered the V-hub solution and agreed that it might fulfill some oper= ators' requirements. However, in some deployment scenarios, the CP-ORF solu= tion is required. Specifically, it is required when the following factors a= re significant: - Sometimes, the V-Spoke can determine when a more direct route is required= , but the V-Hub cannot. For example, the operator may want to use more dire= ct routes only when the V-Spoke's interface to the V-hub exceeds a specifie= d utilization level. - The V-Hub is never well-positioned to determine when a more direct route = is no longer required and should be withdrawn. This is because once the V-S= poke begins to use the more direct route, the V-Hub doesn't see the flow an= y more. So, as you suggest, the V-Hub could withdraw the route based upon t= imer expiration. However, if the timer is too long, the result is excessive= state. If the timer is too short, the result is churn and packet reorderin= g. - Sometimes, the operator wants a more direct route to be advertised to exa= ctly one V-Spoke, not all V-Spokes associated with a V-Hub. Additionally, I am not sure that the V-Hub solution would work in the follo= wing scenario. Assume the following: - RR is a route reflector - PE1, V-Hub1, V-Hub2, V-Spoke1 and V-Spoke2 are clients of RR - V-Spoke1 is a spoke to V-Hub1 - V-Spoke2 is a spoke to V-Hub2 - PE1, V-Spoke1 and V-Spoke2 all serve RED-VPN sites - PE1 advertises the prefix RD-RED:10.1.1.0/24, carrying RT RED-VPN, to RR - V-Spoke1 sends a large flow through V-Hub1 to 10.1.1.1 (in the RED-VPN) - V-Spoke2 sends a large flow through V-Hub2 to 10.1.1.1 (in the RED-VPN) As I understand the V-Hub proposal, the following will occur: - V-Hub1 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This advertise= ment has next-hop equal to PE1 and carries RT-RED-FROM-HUB1 - V-Hub2 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This advertise= ment has next-hop equal to PE1 and carries RT-RED-FROM-HUB2 So, the RR has received three advertisements for RD-RED:10.1.1.0/24, all wi= th next-hop of PE1. Only the RTs vary. How does RR know which one to install? Which to advertise to its clients? Ron > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Friday, October 11, 2013 5:18 PM > To: Ronald Bonica > Cc: l3vpn@ietf.org > Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf- > covering-prefixes-00.txt >=20 > Hi Ron, >=20 > I have reviewed the proposed draft. I think it is very well written > document. Maybe this is just my own observation, but during digesting > it I have struggled to understand why authors have decided to extend > ORF rather then update RFC4684. Maybe if the draft will progress a bit > of clarification would be nice as in general 4684 is preferred over ORF > in VPN context. >=20 > But this is sort of minor detail. Much more important is to observe > that major advantage of RFC7024 is that by default it works with > currently deployed PEs and RRs. This draft however requires upgrade of > both spoke PEs as well as RRs serving such spoke PEs. Such upgrade may > or may not be always feasible. >=20 > It appears however that there is possibility of addressing the problem > with alternative approach fully controlled by the V-hub. Such V-hub > alone is capable of observing the flow patterns among it's V-spokes and > based on the set threshold locally injecting into any VPN optimal route > for heavy flows with RT-RED-FROM-HUB extended community. That as such > will allow for optimal data flows within given VPN bypassing the V-hub. >=20 > The question arises how would we remove such more specific routes from > V-spokes when the flow terminates ... while there is number of possible > solutions in this space - simplest seems to be time driven. > V-hub could start timer of x minutes (configurable) after injecting > more specific and upon expiration withdraw such more specific routes. > At most if the flow still continues customer VPN would experience > transient sub-optimality - no drops and no significant impact as V-hub > would re-advertise the active more specifics again. >=20 > The major advantage of such proposal is that it is readily deployable > into any of the today's L3VPN network by only activating V-hub which > could be a single upgraded PE or new box in the network. Moreover this > procedure does not require any protocol extension nor additional > features like new RT insertion on the VPNv4/v6 route reflectors which > your draft requires. >=20 > I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will > evaluate such alternative. >=20 > Best regards, > R. >=20 >=20 > On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica > wrote: > > > > Please review this draft and provide comments. > > > > Ron > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, September 16, 2013 10:15 AM > >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng > >> Subject: New Version Notification for > >> draft-bonica-l3vpn-orf-covering- prefixes-00.txt > >> > >> > >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes- > 00.txt > >> has been successfully submitted by Huajin Jeng and posted to the > IETF > >> repository. > >> > >> Filename: draft-bonica-l3vpn-orf-covering-prefixes > >> Revision: 00 > >> Title: Covering Prefixes Outbound Route Filter for > BGP-4 > >> Creation date: 2013-09-15 > >> Group: Individual Submission > >> Number of pages: 10 > >> URL: http://www.ietf.org/internet-drafts/draft-bonica- > >> l3vpn-orf-covering-prefixes-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- > >> orf-covering-prefixes > >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- > >> covering-prefixes-00 > >> > >> > >> Abstract: > >> This document defines a new ORF-type, called the "Covering > Prefixes > >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a > Virtual > >> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS > VPN > >> environments. > >> > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > >> The IETF Secretariat > >> > >> > > >=20 From rraszuk@gmail.com Fri Oct 18 09:05:20 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D0B11E8257 for ; Fri, 18 Oct 2013 09:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drz++8Knb-Ik for ; Fri, 18 Oct 2013 09:05:06 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2311E8263 for ; Fri, 18 Oct 2013 09:05:05 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id u16so6738923iet.4 for ; Fri, 18 Oct 2013 09:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=XvR5eLrXrCFrY3H4Ujx50iiF7RAOQIPp4J19ti4rFY8=; b=KJ4pvMBTI4050mBhUgwjQQKUnO63CKyNN6O1XJo1U5StWPRl5Eumw6Yy7n+yFPvgk1 NkJg28hEW8+OWzrjnyJ8PlNLO3uKShisXyibZdKTD7UzpaC4TPzIrZD+IMFXmwYM6wOL vLMsDn6/RNvSqsulMNhmNI7zd9ZAG3jKEDZp+M4H5jWBqI3oacEfwwlhkKP42IW5c4il GnKC4SYOMnDcVSjlJWUMJxmB7UJlieT42wM1Dxy/9xSyNnBJ5RSI96qEm5eYEt24n4gu EjqD47VYUtvK0fhxJEKVDGu2SEkgH/pXmLlj/0STTRtVacDJkTGjagEyJS3Q7e8qcEiU tqFA== MIME-Version: 1.0 X-Received: by 10.50.117.103 with SMTP id kd7mr91066igb.4.1382112303975; Fri, 18 Oct 2013 09:05:03 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 18 Oct 2013 09:05:03 -0700 (PDT) In-Reply-To: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> Date: Fri, 18 Oct 2013 18:05:03 +0200 X-Google-Sender-Auth: vHKfP87D9AnDqcfDFzKn0zrUiHA Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Ronald Bonica Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:05:20 -0000 Hello Ron, As you noted the first three tradeoffs characteristics of "V-hub solution" are just factors in functionality vs complexity equation. My objective was to provide an alternative to accomplish optimal paths on demand in the environment where RFC7024 is used. I am not making here any judgments if those will be acceptable in all cases or not. Now let me reply to your question ... > So, the RR has received three advertisements for RD-RED:10.1.1.0/24, > all with next-hop of PE1. Only the RTs vary. > > How does RR know which one to install? Which to advertise to its clients? RR does not need to know which one to choose as best. Paths advertised from hubs will have unique RD hence will not be subject to compete in BGP best path selection with paths advertised from PEs for respective vpnv4 or vpnv6 prefixes. As result v-spokes will get all necessary routes and will be able to use optimal routing till those more specific routes are not withdrawn. No changes on RRs or V-spokes are necessary (in fact no changes for entire RFC7024 are necessary on those network elements vastly simplifying it's deployment). Best regards, R. On Fri, Oct 18, 2013 at 5:42 PM, Ronald Bonica wrote: > Robert, > > Thanks for your thoughtful review and comments! For the purposes of this = message, we will call the solution that you propose below, the "V-Hub Solut= ion". > > We considered the V-hub solution and agreed that it might fulfill some op= erators' requirements. However, in some deployment scenarios, the CP-ORF so= lution is required. Specifically, it is required when the following factors= are significant: > > - Sometimes, the V-Spoke can determine when a more direct route is requir= ed, but the V-Hub cannot. For example, the operator may want to use more di= rect routes only when the V-Spoke's interface to the V-hub exceeds a specif= ied utilization level. > > - The V-Hub is never well-positioned to determine when a more direct rout= e is no longer required and should be withdrawn. This is because once the V= -Spoke begins to use the more direct route, the V-Hub doesn't see the flow = any more. So, as you suggest, the V-Hub could withdraw the route based upon= timer expiration. However, if the timer is too long, the result is excessi= ve state. If the timer is too short, the result is churn and packet reorder= ing. > > - Sometimes, the operator wants a more direct route to be advertised to e= xactly one V-Spoke, not all V-Spokes associated with a V-Hub. > > > Additionally, I am not sure that the V-Hub solution would work in the fol= lowing scenario. Assume the following: > > - RR is a route reflector > - PE1, V-Hub1, V-Hub2, V-Spoke1 and V-Spoke2 are clients of RR > - V-Spoke1 is a spoke to V-Hub1 > - V-Spoke2 is a spoke to V-Hub2 > - PE1, V-Spoke1 and V-Spoke2 all serve RED-VPN sites > - PE1 advertises the prefix RD-RED:10.1.1.0/24, carrying RT RED-VPN, to R= R > - V-Spoke1 sends a large flow through V-Hub1 to 10.1.1.1 (in the RED-VPN) > - V-Spoke2 sends a large flow through V-Hub2 to 10.1.1.1 (in the RED-VPN) > > As I understand the V-Hub proposal, the following will occur: > > - V-Hub1 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This adverti= sement has next-hop equal to PE1 and carries RT-RED-FROM-HUB1 > - V-Hub2 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This adverti= sement has next-hop equal to PE1 and carries RT-RED-FROM-HUB2 > > So, the RR has received three advertisements for RD-RED:10.1.1.0/24, all = with next-hop of PE1. Only the RTs vary. > > How does RR know which one to install? Which to advertise to its clients? > > Ro= n > > >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Friday, October 11, 2013 5:18 PM >> To: Ronald Bonica >> Cc: l3vpn@ietf.org >> Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf- >> covering-prefixes-00.txt >> >> Hi Ron, >> >> I have reviewed the proposed draft. I think it is very well written >> document. Maybe this is just my own observation, but during digesting >> it I have struggled to understand why authors have decided to extend >> ORF rather then update RFC4684. Maybe if the draft will progress a bit >> of clarification would be nice as in general 4684 is preferred over ORF >> in VPN context. >> >> But this is sort of minor detail. Much more important is to observe >> that major advantage of RFC7024 is that by default it works with >> currently deployed PEs and RRs. This draft however requires upgrade of >> both spoke PEs as well as RRs serving such spoke PEs. Such upgrade may >> or may not be always feasible. >> >> It appears however that there is possibility of addressing the problem >> with alternative approach fully controlled by the V-hub. Such V-hub >> alone is capable of observing the flow patterns among it's V-spokes and >> based on the set threshold locally injecting into any VPN optimal route >> for heavy flows with RT-RED-FROM-HUB extended community. That as such >> will allow for optimal data flows within given VPN bypassing the V-hub. >> >> The question arises how would we remove such more specific routes from >> V-spokes when the flow terminates ... while there is number of possible >> solutions in this space - simplest seems to be time driven. >> V-hub could start timer of x minutes (configurable) after injecting >> more specific and upon expiration withdraw such more specific routes. >> At most if the flow still continues customer VPN would experience >> transient sub-optimality - no drops and no significant impact as V-hub >> would re-advertise the active more specifics again. >> >> The major advantage of such proposal is that it is readily deployable >> into any of the today's L3VPN network by only activating V-hub which >> could be a single upgraded PE or new box in the network. Moreover this >> procedure does not require any protocol extension nor additional >> features like new RT insertion on the VPNv4/v6 route reflectors which >> your draft requires. >> >> I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will >> evaluate such alternative. >> >> Best regards, >> R. >> >> >> On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica >> wrote: >> > >> > Please review this draft and provide comments. >> > >> > Ron >> > >> > >> >> -----Original Message----- >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> >> Sent: Monday, September 16, 2013 10:15 AM >> >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >> >> Subject: New Version Notification for >> >> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >> >> >> >> >> >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes- >> 00.txt >> >> has been successfully submitted by Huajin Jeng and posted to the >> IETF >> >> repository. >> >> >> >> Filename: draft-bonica-l3vpn-orf-covering-prefixes >> >> Revision: 00 >> >> Title: Covering Prefixes Outbound Route Filter for >> BGP-4 >> >> Creation date: 2013-09-15 >> >> Group: Individual Submission >> >> Number of pages: 10 >> >> URL: http://www.ietf.org/internet-drafts/draft-bonica- >> >> l3vpn-orf-covering-prefixes-00.txt >> >> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >> >> orf-covering-prefixes >> >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >> >> covering-prefixes-00 >> >> >> >> >> >> Abstract: >> >> This document defines a new ORF-type, called the "Covering >> Prefixes >> >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a >> Virtual >> >> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS >> VPN >> >> environments. >> >> >> >> >> >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> >> submission until the htmlized version and diff are available at >> >> tools.ietf.org. >> >> >> >> The IETF Secretariat >> >> >> >> >> > >> > > From rraszuk@gmail.com Fri Oct 18 09:32:46 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6701F11E820A for ; Fri, 18 Oct 2013 09:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QygMtt62fuCO for ; Fri, 18 Oct 2013 09:32:45 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0005011E826E for ; Fri, 18 Oct 2013 09:32:44 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so6946432iej.36 for ; Fri, 18 Oct 2013 09:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=o1sg8GRktGjxcYEEKNcCkrP4VGiAVukZCCHn06+aYoE=; b=Moi//Io5I35J+3Ogn4ZK73/p1GFtwzKL4oAd8Lw/xHUl/9DFvb63U5EkZGgy/9VV+d 5+yq0xq4ly3A9iKrSxAQJw+y8MlBUvD1Dv/euYjQNJDV4X56boRaJAKvrI2cbo/Ux9am x07YbexABmYYQd3zxvUXgRxPQoi0RFWeAtSstwOK9D5wo4ZandT97UJe7+WLYMIzZ5bI UpTvUd8bgXkKVjG2j4Xj83CYUqJQLe3lfeZIXJTU3bagmzzc8nAHWFk8+kAdsoTKzJ4Z cQxIdPVZ+FHoRz1asI0cwu5SEk8fO9JDrVuxL92FrpqE9bqaqfOcX7jzuzVGyW8dEDJ4 2+FQ== MIME-Version: 1.0 X-Received: by 10.43.73.197 with SMTP id yt5mr2451220icb.0.1382113964383; Fri, 18 Oct 2013 09:32:44 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 18 Oct 2013 09:32:44 -0700 (PDT) In-Reply-To: References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> Date: Fri, 18 Oct 2013 18:32:44 +0200 X-Google-Sender-Auth: 3oO690L1oN6zGd9FxGTZz-Oh-54 Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Ronald Bonica Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:32:46 -0000 Hi Ron, Just to add provided the three points may be an issue there is possible alternative still without any requirement to upgrade any of the existing v-spokes or RRs. It is normal today for PEs to enable netflow statistics. It seems feasible to me to have additional logic in the controller associated with netflow collector to analyse traffic patterns for any VPN interface of v-spokes and based on such analysis trigger advertisement of more specific routes on v-hubs or their withdraw. Such trigger would be "out of band" as far as routing protocols namely BGP. There are various alternatives possible anywhere from snmp, cli, xml script or I2RS protocol to accomplish such triggers for this application. Note also that in this case and one extra RT per spoke pre-provisioned normally at spoke creation the potential desire for avoiding unnecessary state on those spokes (even transient) where it is not required can be easily accomplished. Best regards, R. On Fri, Oct 18, 2013 at 6:05 PM, Robert Raszuk wrote: > Hello Ron, > > As you noted the first three tradeoffs characteristics of "V-hub > solution" are just factors in functionality vs complexity equation. > My objective was to provide an alternative to accomplish optimal paths > on demand in the environment where RFC7024 is used. > > I am not making here any judgments if those will be acceptable in all > cases or not. > > Now let me reply to your question ... > >> So, the RR has received three advertisements for RD-RED:10.1.1.0/24, >> all with next-hop of PE1. Only the RTs vary. >> >> How does RR know which one to install? Which to advertise to its clients= ? > > RR does not need to know which one to choose as best. Paths advertised > from hubs will have unique RD hence will not be subject to compete in > BGP best path selection with paths advertised from PEs for respective > vpnv4 or vpnv6 prefixes. > > As result v-spokes will get all necessary routes and will be able to > use optimal routing till those more specific routes are not withdrawn. > No changes on RRs or V-spokes are necessary (in fact no changes for > entire RFC7024 are necessary on those network elements vastly > simplifying it's deployment). > > Best regards, > R. > > > > On Fri, Oct 18, 2013 at 5:42 PM, Ronald Bonica wrot= e: >> Robert, >> >> Thanks for your thoughtful review and comments! For the purposes of this= message, we will call the solution that you propose below, the "V-Hub Solu= tion". >> >> We considered the V-hub solution and agreed that it might fulfill some o= perators' requirements. However, in some deployment scenarios, the CP-ORF s= olution is required. Specifically, it is required when the following factor= s are significant: >> >> - Sometimes, the V-Spoke can determine when a more direct route is requi= red, but the V-Hub cannot. For example, the operator may want to use more d= irect routes only when the V-Spoke's interface to the V-hub exceeds a speci= fied utilization level. >> >> - The V-Hub is never well-positioned to determine when a more direct rou= te is no longer required and should be withdrawn. This is because once the = V-Spoke begins to use the more direct route, the V-Hub doesn't see the flow= any more. So, as you suggest, the V-Hub could withdraw the route based upo= n timer expiration. However, if the timer is too long, the result is excess= ive state. If the timer is too short, the result is churn and packet reorde= ring. >> >> - Sometimes, the operator wants a more direct route to be advertised to = exactly one V-Spoke, not all V-Spokes associated with a V-Hub. >> >> >> Additionally, I am not sure that the V-Hub solution would work in the fo= llowing scenario. Assume the following: >> >> - RR is a route reflector >> - PE1, V-Hub1, V-Hub2, V-Spoke1 and V-Spoke2 are clients of RR >> - V-Spoke1 is a spoke to V-Hub1 >> - V-Spoke2 is a spoke to V-Hub2 >> - PE1, V-Spoke1 and V-Spoke2 all serve RED-VPN sites >> - PE1 advertises the prefix RD-RED:10.1.1.0/24, carrying RT RED-VPN, to = RR >> - V-Spoke1 sends a large flow through V-Hub1 to 10.1.1.1 (in the RED-VPN= ) >> - V-Spoke2 sends a large flow through V-Hub2 to 10.1.1.1 (in the RED-VPN= ) >> >> As I understand the V-Hub proposal, the following will occur: >> >> - V-Hub1 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This advert= isement has next-hop equal to PE1 and carries RT-RED-FROM-HUB1 >> - V-Hub2 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This advert= isement has next-hop equal to PE1 and carries RT-RED-FROM-HUB2 >> >> So, the RR has received three advertisements for RD-RED:10.1.1.0/24, all= with next-hop of PE1. Only the RTs vary. >> >> How does RR know which one to install? Which to advertise to its clients= ? >> >> R= on >> >> >>> -----Original Message----- >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>> Raszuk >>> Sent: Friday, October 11, 2013 5:18 PM >>> To: Ronald Bonica >>> Cc: l3vpn@ietf.org >>> Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf- >>> covering-prefixes-00.txt >>> >>> Hi Ron, >>> >>> I have reviewed the proposed draft. I think it is very well written >>> document. Maybe this is just my own observation, but during digesting >>> it I have struggled to understand why authors have decided to extend >>> ORF rather then update RFC4684. Maybe if the draft will progress a bit >>> of clarification would be nice as in general 4684 is preferred over ORF >>> in VPN context. >>> >>> But this is sort of minor detail. Much more important is to observe >>> that major advantage of RFC7024 is that by default it works with >>> currently deployed PEs and RRs. This draft however requires upgrade of >>> both spoke PEs as well as RRs serving such spoke PEs. Such upgrade may >>> or may not be always feasible. >>> >>> It appears however that there is possibility of addressing the problem >>> with alternative approach fully controlled by the V-hub. Such V-hub >>> alone is capable of observing the flow patterns among it's V-spokes and >>> based on the set threshold locally injecting into any VPN optimal route >>> for heavy flows with RT-RED-FROM-HUB extended community. That as such >>> will allow for optimal data flows within given VPN bypassing the V-hub. >>> >>> The question arises how would we remove such more specific routes from >>> V-spokes when the flow terminates ... while there is number of possible >>> solutions in this space - simplest seems to be time driven. >>> V-hub could start timer of x minutes (configurable) after injecting >>> more specific and upon expiration withdraw such more specific routes. >>> At most if the flow still continues customer VPN would experience >>> transient sub-optimality - no drops and no significant impact as V-hub >>> would re-advertise the active more specifics again. >>> >>> The major advantage of such proposal is that it is readily deployable >>> into any of the today's L3VPN network by only activating V-hub which >>> could be a single upgraded PE or new box in the network. Moreover this >>> procedure does not require any protocol extension nor additional >>> features like new RT insertion on the VPNv4/v6 route reflectors which >>> your draft requires. >>> >>> I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will >>> evaluate such alternative. >>> >>> Best regards, >>> R. >>> >>> >>> On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica >>> wrote: >>> > >>> > Please review this draft and provide comments. >>> > >>> > Ron >>> > >>> > >>> >> -----Original Message----- >>> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> >> Sent: Monday, September 16, 2013 10:15 AM >>> >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >>> >> Subject: New Version Notification for >>> >> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >>> >> >>> >> >>> >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes- >>> 00.txt >>> >> has been successfully submitted by Huajin Jeng and posted to the >>> IETF >>> >> repository. >>> >> >>> >> Filename: draft-bonica-l3vpn-orf-covering-prefixes >>> >> Revision: 00 >>> >> Title: Covering Prefixes Outbound Route Filter for >>> BGP-4 >>> >> Creation date: 2013-09-15 >>> >> Group: Individual Submission >>> >> Number of pages: 10 >>> >> URL: http://www.ietf.org/internet-drafts/draft-bonica- >>> >> l3vpn-orf-covering-prefixes-00.txt >>> >> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >>> >> orf-covering-prefixes >>> >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >>> >> covering-prefixes-00 >>> >> >>> >> >>> >> Abstract: >>> >> This document defines a new ORF-type, called the "Covering >>> Prefixes >>> >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a >>> Virtual >>> >> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS >>> VPN >>> >> environments. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Please note that it may take a couple of minutes from the time of >>> >> submission until the htmlized version and diff are available at >>> >> tools.ietf.org. >>> >> >>> >> The IETF Secretariat >>> >> >>> >> >>> > >>> >> >> From lucy.yong@huawei.com Fri Oct 18 10:04:51 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419DF11E8321 for ; Fri, 18 Oct 2013 10:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwOo0TrlWpWV for ; Fri, 18 Oct 2013 10:04:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF4611E8320 for ; Fri, 18 Oct 2013 10:04:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZF24653; Fri, 18 Oct 2013 17:04:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 18:03:24 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 18:04:01 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 10:03:55 -0700 From: Lucy yong To: Robert Raszuk , Ronald Bonica Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOzB+zg5Nbnsb+pEGZSs3dAVYWEJn6rX1Q Date: Fri, 18 Oct 2013 17:03:53 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:04:51 -0000 Please see inline. -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of R= obert Raszuk Sent: Friday, October 18, 2013 11:33 AM To: Ronald Bonica Cc: l3vpn@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-coveri= ng-prefixes-00.txt Hi Ron, Just to add provided the three points may be an issue there is possible alt= ernative still without any requirement to upgrade any of the existing v-spo= kes or RRs. It is normal today for PEs to enable netflow statistics. It seems feasible = to me to have additional logic in the controller associated with netflow co= llector to analyse traffic patterns for any VPN interface of v-spokes and b= ased on such analysis trigger advertisement of more specific routes on v-hu= bs or their withdraw. Such trigger would be "out of band" as far as routing protocols namely BGP. [Lucy] why do you think that this mechanism is simpler than the one propose= d in the draft? To me, it just shifts the request capability outside BGP. I= t makes BGP simple, but not necessary mean the solution simpler. Lucy There are various alternatives possible anywhere from snmp, cli, xml script= or I2RS protocol to accomplish such triggers for this application. Note also that in this case and one extra RT per spoke pre-provisioned norm= ally at spoke creation the potential desire for avoiding unnecessary state = on those spokes (even transient) where it is not required can be easily acc= omplished. Best regards, R. On Fri, Oct 18, 2013 at 6:05 PM, Robert Raszuk wrote: > Hello Ron, > > As you noted the first three tradeoffs characteristics of "V-hub=20 > solution" are just factors in functionality vs complexity equation. > My objective was to provide an alternative to accomplish optimal paths=20 > on demand in the environment where RFC7024 is used. > > I am not making here any judgments if those will be acceptable in all=20 > cases or not. > > Now let me reply to your question ... > >> So, the RR has received three advertisements for RD-RED:10.1.1.0/24,=20 >> all with next-hop of PE1. Only the RTs vary. >> >> How does RR know which one to install? Which to advertise to its clients= ? > > RR does not need to know which one to choose as best. Paths advertised=20 > from hubs will have unique RD hence will not be subject to compete in=20 > BGP best path selection with paths advertised from PEs for respective > vpnv4 or vpnv6 prefixes. > > As result v-spokes will get all necessary routes and will be able to=20 > use optimal routing till those more specific routes are not withdrawn. > No changes on RRs or V-spokes are necessary (in fact no changes for=20 > entire RFC7024 are necessary on those network elements vastly=20 > simplifying it's deployment). > > Best regards, > R. > > > > On Fri, Oct 18, 2013 at 5:42 PM, Ronald Bonica wrot= e: >> Robert, >> >> Thanks for your thoughtful review and comments! For the purposes of this= message, we will call the solution that you propose below, the "V-Hub Solu= tion". >> >> We considered the V-hub solution and agreed that it might fulfill some o= perators' requirements. However, in some deployment scenarios, the CP-ORF s= olution is required. Specifically, it is required when the following factor= s are significant: >> >> - Sometimes, the V-Spoke can determine when a more direct route is requi= red, but the V-Hub cannot. For example, the operator may want to use more d= irect routes only when the V-Spoke's interface to the V-hub exceeds a speci= fied utilization level. >> >> - The V-Hub is never well-positioned to determine when a more direct rou= te is no longer required and should be withdrawn. This is because once the = V-Spoke begins to use the more direct route, the V-Hub doesn't see the flow= any more. So, as you suggest, the V-Hub could withdraw the route based upo= n timer expiration. However, if the timer is too long, the result is excess= ive state. If the timer is too short, the result is churn and packet reorde= ring. >> >> - Sometimes, the operator wants a more direct route to be advertised to = exactly one V-Spoke, not all V-Spokes associated with a V-Hub. >> >> >> Additionally, I am not sure that the V-Hub solution would work in the fo= llowing scenario. Assume the following: >> >> - RR is a route reflector >> - PE1, V-Hub1, V-Hub2, V-Spoke1 and V-Spoke2 are clients of RR >> - V-Spoke1 is a spoke to V-Hub1 >> - V-Spoke2 is a spoke to V-Hub2 >> - PE1, V-Spoke1 and V-Spoke2 all serve RED-VPN sites >> - PE1 advertises the prefix RD-RED:10.1.1.0/24, carrying RT RED-VPN,=20 >> to RR >> - V-Spoke1 sends a large flow through V-Hub1 to 10.1.1.1 (in the=20 >> RED-VPN) >> - V-Spoke2 sends a large flow through V-Hub2 to 10.1.1.1 (in the=20 >> RED-VPN) >> >> As I understand the V-Hub proposal, the following will occur: >> >> - V-Hub1 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This=20 >> advertisement has next-hop equal to PE1 and carries RT-RED-FROM-HUB1 >> - V-Hub2 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This=20 >> advertisement has next-hop equal to PE1 and carries RT-RED-FROM-HUB2 >> >> So, the RR has received three advertisements for RD-RED:10.1.1.0/24, all= with next-hop of PE1. Only the RTs vary. >> >> How does RR know which one to install? Which to advertise to its clients= ? >> >> =20 >> Ron >> >> >>> -----Original Message----- >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of=20 >>> Robert Raszuk >>> Sent: Friday, October 11, 2013 5:18 PM >>> To: Ronald Bonica >>> Cc: l3vpn@ietf.org >>> Subject: Re: FW: New Version Notification for=20 >>> draft-bonica-l3vpn-orf- covering-prefixes-00.txt >>> >>> Hi Ron, >>> >>> I have reviewed the proposed draft. I think it is very well written=20 >>> document. Maybe this is just my own observation, but during=20 >>> digesting it I have struggled to understand why authors have decided=20 >>> to extend ORF rather then update RFC4684. Maybe if the draft will=20 >>> progress a bit of clarification would be nice as in general 4684 is=20 >>> preferred over ORF in VPN context. >>> >>> But this is sort of minor detail. Much more important is to observe=20 >>> that major advantage of RFC7024 is that by default it works with=20 >>> currently deployed PEs and RRs. This draft however requires upgrade=20 >>> of both spoke PEs as well as RRs serving such spoke PEs. Such=20 >>> upgrade may or may not be always feasible. >>> >>> It appears however that there is possibility of addressing the=20 >>> problem with alternative approach fully controlled by the V-hub.=20 >>> Such V-hub alone is capable of observing the flow patterns among=20 >>> it's V-spokes and based on the set threshold locally injecting into=20 >>> any VPN optimal route for heavy flows with RT-RED-FROM-HUB extended=20 >>> community. That as such will allow for optimal data flows within given = VPN bypassing the V-hub. >>> >>> The question arises how would we remove such more specific routes=20 >>> from V-spokes when the flow terminates ... while there is number of=20 >>> possible solutions in this space - simplest seems to be time driven. >>> V-hub could start timer of x minutes (configurable) after injecting=20 >>> more specific and upon expiration withdraw such more specific routes. >>> At most if the flow still continues customer VPN would experience=20 >>> transient sub-optimality - no drops and no significant impact as=20 >>> V-hub would re-advertise the active more specifics again. >>> >>> The major advantage of such proposal is that it is readily=20 >>> deployable into any of the today's L3VPN network by only activating=20 >>> V-hub which could be a single upgraded PE or new box in the network.=20 >>> Moreover this procedure does not require any protocol extension nor=20 >>> additional features like new RT insertion on the VPNv4/v6 route=20 >>> reflectors which your draft requires. >>> >>> I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will=20 >>> evaluate such alternative. >>> >>> Best regards, >>> R. >>> >>> >>> On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica >>> wrote: >>> > >>> > Please review this draft and provide comments. >>> > >>> > Ron >>> > >>> > >>> >> -----Original Message----- >>> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> >> Sent: Monday, September 16, 2013 10:15 AM >>> >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >>> >> Subject: New Version Notification for >>> >> draft-bonica-l3vpn-orf-covering- prefixes-00.txt >>> >> >>> >> >>> >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes- >>> 00.txt >>> >> has been successfully submitted by Huajin Jeng and posted to the >>> IETF >>> >> repository. >>> >> >>> >> Filename: draft-bonica-l3vpn-orf-covering-prefixes >>> >> Revision: 00 >>> >> Title: Covering Prefixes Outbound Route Filter for >>> BGP-4 >>> >> Creation date: 2013-09-15 >>> >> Group: Individual Submission >>> >> Number of pages: 10 >>> >> URL: http://www.ietf.org/internet-drafts/draft-bonica- >>> >> l3vpn-orf-covering-prefixes-00.txt >>> >> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >>> >> orf-covering-prefixes >>> >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >>> >> covering-prefixes-00 >>> >> >>> >> >>> >> Abstract: >>> >> This document defines a new ORF-type, called the "Covering >>> Prefixes >>> >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a >>> Virtual >>> >> Hub-and-Spoke VPN. It may also be applicable in other=20 >>> >> BGP/MPLS >>> VPN >>> >> environments. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Please note that it may take a couple of minutes from the time of=20 >>> >> submission until the htmlized version and diff are available at=20 >>> >> tools.ietf.org. >>> >> >>> >> The IETF Secretariat >>> >> >>> >> >>> > >>> >> >> From rraszuk@gmail.com Fri Oct 18 11:39:38 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8A011E826F for ; Fri, 18 Oct 2013 11:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoFSRbC5FewX for ; Fri, 18 Oct 2013 11:39:37 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D554411E81B8 for ; Fri, 18 Oct 2013 11:39:30 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so7003073iec.6 for ; Fri, 18 Oct 2013 11:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7MivTJsOtLmLlmWdvZ4h9krdT68MUYhKRBHviJTNseY=; b=YPGUFECmNrcvF7SR444gnrF/0UEuYCP1B5lNZbmeSY38y4l8K5pvW2ywnl2O8Tbkzu MuO3EqFQqb5vn5Hiod+PQwxVVimcW1stZqkXkwY0MY0dqreAfKJDNWJe4P8FT94QcWZU +bT3KtJD2uqOIdnQrkyPV20sjd1GvC1W68fUVOvCLuDxkB2NMAfFymnwjEKi8WJ1lrfH d744AV3iWbY2o59ENH/EaMuz4SGs6BB00BKQEIKr5ixuZnoOMh6FruXNtby3okg0Urwv 8o28QZRDrKh4zrk86vr6mzdLvaue9ccdtzR09nfXZDM/jW7OkY8Um1hNf9+sTPk8QuuC nbKg== MIME-Version: 1.0 X-Received: by 10.43.138.8 with SMTP id iq8mr2747200icc.37.1382121570244; Fri, 18 Oct 2013 11:39:30 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 18 Oct 2013 11:39:30 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> Date: Fri, 18 Oct 2013 20:39:30 +0200 X-Google-Sender-Auth: UEaUEneil1l2K1GOqWJXpK938yw Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:39:39 -0000 Lucy, > [Lucy] why do you think that this mechanism is simpler than the one > proposed in the draft? To me, it just shifts the request capability outside > BGP. It makes BGP simple, but not necessary mean the solution simpler. The main point is not about using BGP or not. Here if anything industry and in particular this WG has been converging to use RT Constrain for controlling VPN route distribution. This draft however now proposed ORF which runs over Route Refresh. That means that at least one benefit of RTC is lost - incremental updates. In fact I would say this is a grey area how to run RTC and ORF together for the same set of VRFs. My focus was not to debate about using BGP rather the focus is to use right tool for the task. Imagine I have deployed another L3VPN WG document namely: draft-ietf-l3vpn-end-system-01 In such architecture I have decoupled for a number of good reasons data plane and control plane to completely different physical boxes. Note also that in such design I already have on the complete system a stats collector where it is really trivial to trigger a message to v-hub in order to inject more specifics. Contrary if I am to use proposed solution I need to modify XMPP as well as number of other system wide components to achieve the goal. Best regards, R. From rbonica@juniper.net Fri Oct 18 11:49:27 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F411E81B8 for ; Fri, 18 Oct 2013 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.766 X-Spam-Level: X-Spam-Status: No, score=-104.766 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jORmukdO1Jk for ; Fri, 18 Oct 2013 11:49:22 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 243DD11E82E9 for ; Fri, 18 Oct 2013 11:49:19 -0700 (PDT) Received: from mail210-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Oct 2013 18:49:18 +0000 Received: from mail210-tx2 (localhost [127.0.0.1]) by mail210-tx2-R.bigfish.com (Postfix) with ESMTP id 7A912D80264; Fri, 18 Oct 2013 18:49:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzdb82h98dI9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068h8275bhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail210-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377424004)(24454002)(51704005)(189002)(199002)(377454003)(80022001)(15202345003)(66066001)(79102001)(56816003)(561944002)(74662001)(77096001)(74706001)(76482001)(81542001)(15975445006)(81342001)(31966008)(80976001)(19580395003)(74366001)(83072001)(83322001)(65816001)(74502001)(81816001)(63696002)(54316002)(54356001)(77982001)(85306002)(53806001)(56776001)(59766001)(33646001)(69226001)(49866001)(50986001)(4396001)(74876001)(81686001)(47446002)(47976001)(47736001)(74316001)(19580405001)(76796001)(51856001)(46102001)(76576001)(76786001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail210-tx2 (localhost.localdomain [127.0.0.1]) by mail210-tx2 (MessageSwitch) id 1382122138842788_24911; Fri, 18 Oct 2013 18:48:58 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.243]) by mail210-tx2.bigfish.com (Postfix) with ESMTP id C0907780031; Fri, 18 Oct 2013 18:48:58 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Oct 2013 18:48:58 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 18 Oct 2013 18:48:57 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 18 Oct 2013 18:48:54 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.14]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.251]) with mapi id 15.00.0785.001; Fri, 18 Oct 2013 18:48:54 +0000 From: Ronald Bonica To: Robert Raszuk Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOxsd0xoF9xf3u3USD7KAUj6WJjJn6epxggAAvcICAAAZpIA== Date: Fri, 18 Oct 2013 18:48:54 +0000 Message-ID: References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 00032065B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:49:27 -0000 Robert, If I read you correctly, V-Hub1 receives an advertisement for RT-RED:10.1.1= .0/24 and originates an advertisement for RT-RED-FROM-V-HUB1:10.1.1.0/24. S= omehow, V-Hub1 has to tie the two advertisements together, because if PE1 w= ithdraws RT-RED:10.1.1.0/24, V-Hub1 must withdraw RT-RED-FROM-V-HUB1:10.1.1= .0/24. Am I reading this correctly? Ron > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Friday, October 18, 2013 12:05 PM > To: Ronald Bonica > Cc: l3vpn@ietf.org > Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf- > covering-prefixes-00.txt >=20 > Hello Ron, >=20 > As you noted the first three tradeoffs characteristics of "V-hub > solution" are just factors in functionality vs complexity equation. > My objective was to provide an alternative to accomplish optimal paths > on demand in the environment where RFC7024 is used. >=20 > I am not making here any judgments if those will be acceptable in all > cases or not. >=20 > Now let me reply to your question ... >=20 > > So, the RR has received three advertisements for RD-RED:10.1.1.0/24, > > all with next-hop of PE1. Only the RTs vary. > > > > How does RR know which one to install? Which to advertise to its > clients? >=20 > RR does not need to know which one to choose as best. Paths advertised > from hubs will have unique RD hence will not be subject to compete in > BGP best path selection with paths advertised from PEs for respective > vpnv4 or vpnv6 prefixes. >=20 > As result v-spokes will get all necessary routes and will be able to > use optimal routing till those more specific routes are not withdrawn. > No changes on RRs or V-spokes are necessary (in fact no changes for > entire RFC7024 are necessary on those network elements vastly > simplifying it's deployment). >=20 > Best regards, > R. >=20 >=20 >=20 > On Fri, Oct 18, 2013 at 5:42 PM, Ronald Bonica > wrote: > > Robert, > > > > Thanks for your thoughtful review and comments! For the purposes of > this message, we will call the solution that you propose below, the "V- > Hub Solution". > > > > We considered the V-hub solution and agreed that it might fulfill > some operators' requirements. However, in some deployment scenarios, > the CP-ORF solution is required. Specifically, it is required when the > following factors are significant: > > > > - Sometimes, the V-Spoke can determine when a more direct route is > required, but the V-Hub cannot. For example, the operator may want to > use more direct routes only when the V-Spoke's interface to the V-hub > exceeds a specified utilization level. > > > > - The V-Hub is never well-positioned to determine when a more direct > route is no longer required and should be withdrawn. This is because > once the V-Spoke begins to use the more direct route, the V-Hub doesn't > see the flow any more. So, as you suggest, the V-Hub could withdraw the > route based upon timer expiration. However, if the timer is too long, > the result is excessive state. If the timer is too short, the result is > churn and packet reordering. > > > > - Sometimes, the operator wants a more direct route to be advertised > to exactly one V-Spoke, not all V-Spokes associated with a V-Hub. > > > > > > Additionally, I am not sure that the V-Hub solution would work in the > following scenario. Assume the following: > > > > - RR is a route reflector > > - PE1, V-Hub1, V-Hub2, V-Spoke1 and V-Spoke2 are clients of RR > > - V-Spoke1 is a spoke to V-Hub1 > > - V-Spoke2 is a spoke to V-Hub2 > > - PE1, V-Spoke1 and V-Spoke2 all serve RED-VPN sites > > - PE1 advertises the prefix RD-RED:10.1.1.0/24, carrying RT RED-VPN, > > to RR > > - V-Spoke1 sends a large flow through V-Hub1 to 10.1.1.1 (in the > > RED-VPN) > > - V-Spoke2 sends a large flow through V-Hub2 to 10.1.1.1 (in the > > RED-VPN) > > > > As I understand the V-Hub proposal, the following will occur: > > > > - V-Hub1 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This > > advertisement has next-hop equal to PE1 and carries RT-RED-FROM-HUB1 > > - V-Hub2 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This > > advertisement has next-hop equal to PE1 and carries RT-RED-FROM-HUB2 > > > > So, the RR has received three advertisements for RD-RED:10.1.1.0/24, > all with next-hop of PE1. Only the RTs vary. > > > > How does RR know which one to install? Which to advertise to its > clients? > > > > > > Ron > > > > > >> -----Original Message----- > >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of > >> Robert Raszuk > >> Sent: Friday, October 11, 2013 5:18 PM > >> To: Ronald Bonica > >> Cc: l3vpn@ietf.org > >> Subject: Re: FW: New Version Notification for draft-bonica-l3vpn- > orf- > >> covering-prefixes-00.txt > >> > >> Hi Ron, > >> > >> I have reviewed the proposed draft. I think it is very well written > >> document. Maybe this is just my own observation, but during > digesting > >> it I have struggled to understand why authors have decided to extend > >> ORF rather then update RFC4684. Maybe if the draft will progress a > >> bit of clarification would be nice as in general 4684 is preferred > >> over ORF in VPN context. > >> > >> But this is sort of minor detail. Much more important is to observe > >> that major advantage of RFC7024 is that by default it works with > >> currently deployed PEs and RRs. This draft however requires upgrade > >> of both spoke PEs as well as RRs serving such spoke PEs. Such > upgrade > >> may or may not be always feasible. > >> > >> It appears however that there is possibility of addressing the > >> problem with alternative approach fully controlled by the V-hub. > Such > >> V-hub alone is capable of observing the flow patterns among it's > >> V-spokes and based on the set threshold locally injecting into any > >> VPN optimal route for heavy flows with RT-RED-FROM-HUB extended > >> community. That as such will allow for optimal data flows within > given VPN bypassing the V-hub. > >> > >> The question arises how would we remove such more specific routes > >> from V-spokes when the flow terminates ... while there is number of > >> possible solutions in this space - simplest seems to be time driven. > >> V-hub could start timer of x minutes (configurable) after injecting > >> more specific and upon expiration withdraw such more specific > routes. > >> At most if the flow still continues customer VPN would experience > >> transient sub-optimality - no drops and no significant impact as > >> V-hub would re-advertise the active more specifics again. > >> > >> The major advantage of such proposal is that it is readily > deployable > >> into any of the today's L3VPN network by only activating V-hub which > >> could be a single upgraded PE or new box in the network. Moreover > >> this procedure does not require any protocol extension nor > additional > >> features like new RT insertion on the VPNv4/v6 route reflectors > which > >> your draft requires. > >> > >> I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will > >> evaluate such alternative. > >> > >> Best regards, > >> R. > >> > >> > >> On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica > >> wrote: > >> > > >> > Please review this draft and provide comments. > >> > > >> > Ron > >> > > >> > > >> >> -----Original Message----- > >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> >> Sent: Monday, September 16, 2013 10:15 AM > >> >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng > >> >> Subject: New Version Notification for > >> >> draft-bonica-l3vpn-orf-covering- prefixes-00.txt > >> >> > >> >> > >> >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes- > >> 00.txt > >> >> has been successfully submitted by Huajin Jeng and posted to the > >> IETF > >> >> repository. > >> >> > >> >> Filename: draft-bonica-l3vpn-orf-covering-prefixes > >> >> Revision: 00 > >> >> Title: Covering Prefixes Outbound Route Filter > for > >> BGP-4 > >> >> Creation date: 2013-09-15 > >> >> Group: Individual Submission > >> >> Number of pages: 10 > >> >> URL: http://www.ietf.org/internet-drafts/draft- > bonica- > >> >> l3vpn-orf-covering-prefixes-00.txt > >> >> Status: http://datatracker.ietf.org/doc/draft-bonica- > l3vpn- > >> >> orf-covering-prefixes > >> >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn- > orf- > >> >> covering-prefixes-00 > >> >> > >> >> > >> >> Abstract: > >> >> This document defines a new ORF-type, called the "Covering > >> Prefixes > >> >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a > >> Virtual > >> >> Hub-and-Spoke VPN. It may also be applicable in other > BGP/MPLS > >> VPN > >> >> environments. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Please note that it may take a couple of minutes from the time of > >> >> submission until the htmlized version and diff are available at > >> >> tools.ietf.org. > >> >> > >> >> The IETF Secretariat > >> >> > >> >> > >> > > >> > > > > >=20 From lucy.yong@huawei.com Fri Oct 18 12:48:13 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D5811E8330 for ; Fri, 18 Oct 2013 12:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIv1gHHdq+Uy for ; Fri, 18 Oct 2013 12:48:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B909611E82A9 for ; Fri, 18 Oct 2013 12:48:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWX93705; Fri, 18 Oct 2013 19:47:58 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 20:46:57 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 20:47:57 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 12:47:54 -0700 From: Lucy yong To: Robert Raszuk Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOzDFlpgjt5ilTGkWV0g0rTlhDuJn61/7A Date: Fri, 18 Oct 2013 19:47:54 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D7D52@dfweml509-mbx.china.huawei.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:48:13 -0000 Hi Robert, If we have applications that need "pull" capability, we can develop a BGP "= out-of-band" mechanism and/or BGP based mechanism. I agree that the use of = Route Refresh to convey this request is not very good approach. How about t= his approach? We can define a new extended community, say route-request. A BGP speaker ca= n distribute NLRI with a requested address/prefix and this extended communi= ty that encodes the route target associated to this route. When a peer plac= es the route into the Adj-RIB-Out, it applies the following rules: o all BGP attributes except for Route Targets are unchanged o The Route Target specified by the CP-ORF Import Route Target is added to the list or Route Targets that the route already carries Of course, this extended community MUST mutual exclusive with Route Target = extended community, i.e. separate "pull" and "push" action in NLRI. Regards, Lucy -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Friday, October 18, 2013 1:40 PM To: Lucy yong Cc: Ronald Bonica; l3vpn@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-coveri= ng-prefixes-00.txt Lucy, > [Lucy] why do you think that this mechanism is simpler than the one=20 > proposed in the draft? To me, it just shifts the request capability=20 > outside BGP. It makes BGP simple, but not necessary mean the solution sim= pler. The main point is not about using BGP or not. Here if anything industry and= in particular this WG has been converging to use RT Constrain for controll= ing VPN route distribution. This draft however now proposed ORF which runs = over Route Refresh. That means that at least one benefit of RTC is lost - i= ncremental updates. In fact I would say this is a grey area how to run RTC and ORF together for= the same set of VRFs. My focus was not to debate about using BGP rather the focus is to use right= tool for the task. Imagine I have deployed another L3VPN WG document namely: draft-ietf-l3vpn-end-system-01 In such architecture I have decoupled for a number of good reasons data pla= ne and control plane to completely different physical boxes. Note also that in such design I already have on the complete system a stats= collector where it is really trivial to trigger a message to v-hub in orde= r to inject more specifics. Contrary if I am to use proposed solution I need to modify XMPP as well as = number of other system wide components to achieve the goal. Best regards, R. From lucy.yong@huawei.com Fri Oct 18 12:50:47 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE06A11E8339 for ; Fri, 18 Oct 2013 12:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaqm9siR6g-j for ; Fri, 18 Oct 2013 12:50:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21D0D11E826B for ; Fri, 18 Oct 2013 12:50:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZF31718; Fri, 18 Oct 2013 19:50:41 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 20:49:49 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 20:50:38 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 12:50:29 -0700 From: Lucy yong To: Lucy yong , Robert Raszuk Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOzDFlpgjt5ilTGkWV0g0rTlhDuJn61/7AgAAFtHA= Date: Fri, 18 Oct 2013 19:50:29 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D7D60@dfweml509-mbx.china.huawei.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:50:48 -0000 Sorry for the rush. The second ballot should be: o The Route Target specified in the new extended community is added to the list or Route Targets that the route already carries Lucy -----Original Message----- From: Lucy yong=20 Sent: Friday, October 18, 2013 2:48 PM To: 'Robert Raszuk' Cc: Ronald Bonica; l3vpn@ietf.org Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-coveri= ng-prefixes-00.txt Hi Robert, If we have applications that need "pull" capability, we can develop a BGP "= out-of-band" mechanism and/or BGP based mechanism. I agree that the use of = Route Refresh to convey this request is not very good approach. How about t= his approach? We can define a new extended community, say route-request. A BGP speaker ca= n distribute NLRI with a requested address/prefix and this extended communi= ty that encodes the route target associated to this route. When a peer plac= es the route into the Adj-RIB-Out, it applies the following rules: o all BGP attributes except for Route Targets are unchanged o The Route Target specified by the CP-ORF Import Route Target is added to the list or Route Targets that the route already carries Of course, this extended community MUST mutual exclusive with Route Target = extended community, i.e. separate "pull" and "push" action in NLRI. Regards, Lucy -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Friday, October 18, 2013 1:40 PM To: Lucy yong Cc: Ronald Bonica; l3vpn@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-coveri= ng-prefixes-00.txt Lucy, > [Lucy] why do you think that this mechanism is simpler than the one=20 > proposed in the draft? To me, it just shifts the request capability=20 > outside BGP. It makes BGP simple, but not necessary mean the solution sim= pler. The main point is not about using BGP or not. Here if anything industry and= in particular this WG has been converging to use RT Constrain for controll= ing VPN route distribution. This draft however now proposed ORF which runs = over Route Refresh. That means that at least one benefit of RTC is lost - i= ncremental updates. In fact I would say this is a grey area how to run RTC and ORF together for= the same set of VRFs. My focus was not to debate about using BGP rather the focus is to use right= tool for the task. Imagine I have deployed another L3VPN WG document namely: draft-ietf-l3vpn-end-system-01 In such architecture I have decoupled for a number of good reasons data pla= ne and control plane to completely different physical boxes. Note also that in such design I already have on the complete system a stats= collector where it is really trivial to trigger a message to v-hub in orde= r to inject more specifics. Contrary if I am to use proposed solution I need to modify XMPP as well as = number of other system wide components to achieve the goal. Best regards, R. From rraszuk@gmail.com Fri Oct 18 12:57:49 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E573C11E8141 for ; Fri, 18 Oct 2013 12:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEr0uBRj2XFL for ; Fri, 18 Oct 2013 12:57:49 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 279DF11E82B9 for ; Fri, 18 Oct 2013 12:57:49 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so7417404ieb.16 for ; Fri, 18 Oct 2013 12:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JZKZtefRBXq2kHUajG1lhfjFI8Sy4dQJblYqNN722DU=; b=TNSrX+hV2Selx03VocNrK74K0LN024IWG6vJu0M128lq/T4Ksmc6vEJBnPhV5CEuWc pv+AX89T+yB+CP8YmxKn2jGoGGcEqxwCVPR9CPjM87wjTx0mh+eTEa/TZQv/p/lp8vhG CNrPcxpkKHgKjETL6ds8mNhWtwL7XsGR5voVwW2oNTDzqVhszK/4w7NT7RaI1bNwDv/0 0jEwY4dp7klxeQwJ3QpdwWLi/SaPg63Jzfn5YQlv2TCyXCkEERMFs60o+rk4LSBUFhJJ B/OSdYzuc7BGWeXs5fwgh7dVyZG+HUYyb+GwjCn+vNP4jj/HDeG9EI9ZngmJDIrXhHos s0zg== MIME-Version: 1.0 X-Received: by 10.50.117.103 with SMTP id kd7mr859246igb.4.1382126267794; Fri, 18 Oct 2013 12:57:47 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 18 Oct 2013 12:57:47 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D7D52@dfweml509-mbx.china.huawei.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452D7D52@dfweml509-mbx.china.huawei.com> Date: Fri, 18 Oct 2013 21:57:47 +0200 X-Google-Sender-Auth: A8GRulM2aL5lXGKDgWIwOZaTcAA Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:57:50 -0000 Extended community will not cut it. My original reaction was why not to define the new BGP attribute and use it within RTC SAFI ? But before I suggested that I wanted to better understand the genesis of extending ORF. That could also be encoded in BGP Wide Communities which we are (I hope) close to re-publish soon. Many thx, R. On Fri, Oct 18, 2013 at 9:47 PM, Lucy yong wrote: > Hi Robert, > > If we have applications that need "pull" capability, we can develop a BGP= "out-of-band" mechanism and/or BGP based mechanism. I agree that the use o= f Route Refresh to convey this request is not very good approach. How about= this approach? > > We can define a new extended community, say route-request. A BGP speaker = can distribute NLRI with a requested address/prefix and this extended commu= nity that encodes the route target associated to this route. When a peer pl= aces the route into the Adj-RIB-Out, it applies the following rules: > > o all BGP attributes except for Route Targets are unchanged > > o The Route Target specified by the CP-ORF Import Route Target is > added to the list or Route Targets that the route already carries > > Of course, this extended community MUST mutual exclusive with Route Targe= t extended community, i.e. separate "pull" and "push" action in NLRI. > > Regards, > Lucy > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Ra= szuk > Sent: Friday, October 18, 2013 1:40 PM > To: Lucy yong > Cc: Ronald Bonica; l3vpn@ietf.org > Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-cove= ring-prefixes-00.txt > > Lucy, > >> [Lucy] why do you think that this mechanism is simpler than the one >> proposed in the draft? To me, it just shifts the request capability >> outside BGP. It makes BGP simple, but not necessary mean the solution si= mpler. > > The main point is not about using BGP or not. Here if anything industry a= nd in particular this WG has been converging to use RT Constrain for contro= lling VPN route distribution. This draft however now proposed ORF which run= s over Route Refresh. That means that at least one benefit of RTC is lost -= incremental updates. > > In fact I would say this is a grey area how to run RTC and ORF together f= or the same set of VRFs. > > My focus was not to debate about using BGP rather the focus is to use rig= ht tool for the task. > > Imagine I have deployed another L3VPN WG document namely: > draft-ietf-l3vpn-end-system-01 > > In such architecture I have decoupled for a number of good reasons data p= lane and control plane to completely different physical boxes. > Note also that in such design I already have on the complete system a sta= ts collector where it is really trivial to trigger a message to v-hub in or= der to inject more specifics. > > Contrary if I am to use proposed solution I need to modify XMPP as well a= s number of other system wide components to achieve the goal. > > Best regards, > R. From lucy.yong@huawei.com Fri Oct 18 13:04:20 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9C11E8141 for ; Fri, 18 Oct 2013 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHstdbyCLfnF for ; Fri, 18 Oct 2013 13:04:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3A11E819E for ; Fri, 18 Oct 2013 13:04:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWX94329; Fri, 18 Oct 2013 20:04:13 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 21:03:23 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 21:04:12 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 13:04:08 -0700 From: Lucy yong To: Robert Raszuk Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt Thread-Index: AQHOzDFlpgjt5ilTGkWV0g0rTlhDuJn61/7AgAB9moD//4tqoA== Date: Fri, 18 Oct 2013 20:04:06 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D7D9D@dfweml509-mbx.china.huawei.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452D7D52@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 20:04:20 -0000 My original reaction was why not to define the new BGP attribute and use it= within RTC SAFI ? [Lucy] Extended community is a new attribute, isn't it? I don't get the sec= ond part. Thanks, Lucy On Fri, Oct 18, 2013 at 9:47 PM, Lucy yong wrote: > Hi Robert, > > If we have applications that need "pull" capability, we can develop a BGP= "out-of-band" mechanism and/or BGP based mechanism. I agree that the use o= f Route Refresh to convey this request is not very good approach. How about= this approach? > > We can define a new extended community, say route-request. A BGP speaker = can distribute NLRI with a requested address/prefix and this extended commu= nity that encodes the route target associated to this route. When a peer pl= aces the route into the Adj-RIB-Out, it applies the following rules: > > o all BGP attributes except for Route Targets are unchanged > > o The Route Target specified by the CP-ORF Import Route Target is > added to the list or Route Targets that the route already=20 > carries > > Of course, this extended community MUST mutual exclusive with Route Targe= t extended community, i.e. separate "pull" and "push" action in NLRI. > > Regards, > Lucy > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert=20 > Raszuk > Sent: Friday, October 18, 2013 1:40 PM > To: Lucy yong > Cc: Ronald Bonica; l3vpn@ietf.org > Subject: Re: FW: New Version Notification for=20 > draft-bonica-l3vpn-orf-covering-prefixes-00.txt > > Lucy, > >> [Lucy] why do you think that this mechanism is simpler than the one=20 >> proposed in the draft? To me, it just shifts the request capability=20 >> outside BGP. It makes BGP simple, but not necessary mean the solution si= mpler. > > The main point is not about using BGP or not. Here if anything industry a= nd in particular this WG has been converging to use RT Constrain for contro= lling VPN route distribution. This draft however now proposed ORF which run= s over Route Refresh. That means that at least one benefit of RTC is lost -= incremental updates. > > In fact I would say this is a grey area how to run RTC and ORF together f= or the same set of VRFs. > > My focus was not to debate about using BGP rather the focus is to use rig= ht tool for the task. > > Imagine I have deployed another L3VPN WG document namely: > draft-ietf-l3vpn-end-system-01 > > In such architecture I have decoupled for a number of good reasons data p= lane and control plane to completely different physical boxes. > Note also that in such design I already have on the complete system a sta= ts collector where it is really trivial to trigger a message to v-hub in or= der to inject more specifics. > > Contrary if I am to use proposed solution I need to modify XMPP as well a= s number of other system wide components to achieve the goal. > > Best regards, > R. From rraszuk@gmail.com Fri Oct 18 13:17:36 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530EC11E8150 for ; Fri, 18 Oct 2013 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1nDL5UADzCg for ; Fri, 18 Oct 2013 13:17:35 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5560D11E819E for ; Fri, 18 Oct 2013 13:17:31 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so7193417iec.6 for ; Fri, 18 Oct 2013 13:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wYZwbQNC9itqrMd0K+x0KhbgGh57JR+FdyCdFG37HL0=; b=KQe5krw4/h8rLcTfvl9tx9IqXXCv+ksfSIUwTuvPgvmvNE2CdvKB1MOBjRrpL+6bA5 MMWskqdJHrmd+XkDAX1uUTe45wUl/Jfroz/GoNLuT18ruH8Ixrc8cBUUgp63curGnErL +NeuZU40UJvwmp4X2sKu2dghEEc31t3x1AAzducIRM3obyTcu3DYECXXEsOqckVYwK9v ehWJsFLRFYbMQab6PbzlhJ8tfvG7wh7+Pmm6/+EEJyon3U6QVp1lgJl1XvmVOT/PQvr0 XY6SIp6GZ5MLOv4xjal8Hl7IdH8UFj8S/TRkuGalclcTdjK+EzRH/z8j39rSOm/agPS9 mkyQ== MIME-Version: 1.0 X-Received: by 10.42.63.194 with SMTP id d2mr2952257ici.10.1382127450753; Fri, 18 Oct 2013 13:17:30 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 18 Oct 2013 13:17:30 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D7D9D@dfweml509-mbx.china.huawei.com> References: <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452D7D52@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452D7D9D@dfweml509-mbx.china.huawei.com> Date: Fri, 18 Oct 2013 22:17:30 +0200 X-Google-Sender-Auth: dNYCXmJ4R_TGoqKCZvRD3DGM6ZQ Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 20:17:36 -0000 No :) New extended community is not a new attribute. r. On Fri, Oct 18, 2013 at 10:04 PM, Lucy yong wrote: > > My original reaction was why not to define the new BGP attribute and use = it within RTC SAFI ? > [Lucy] Extended community is a new attribute, isn't it? I don't get the s= econd part. > > Thanks, > Lucy > > > > > On Fri, Oct 18, 2013 at 9:47 PM, Lucy yong wrote: >> Hi Robert, >> >> If we have applications that need "pull" capability, we can develop a BG= P "out-of-band" mechanism and/or BGP based mechanism. I agree that the use = of Route Refresh to convey this request is not very good approach. How abou= t this approach? >> >> We can define a new extended community, say route-request. A BGP speaker= can distribute NLRI with a requested address/prefix and this extended comm= unity that encodes the route target associated to this route. When a peer p= laces the route into the Adj-RIB-Out, it applies the following rules: >> >> o all BGP attributes except for Route Targets are unchanged >> >> o The Route Target specified by the CP-ORF Import Route Target is >> added to the list or Route Targets that the route already >> carries >> >> Of course, this extended community MUST mutual exclusive with Route Targ= et extended community, i.e. separate "pull" and "push" action in NLRI. >> >> Regards, >> Lucy >> >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Friday, October 18, 2013 1:40 PM >> To: Lucy yong >> Cc: Ronald Bonica; l3vpn@ietf.org >> Subject: Re: FW: New Version Notification for >> draft-bonica-l3vpn-orf-covering-prefixes-00.txt >> >> Lucy, >> >>> [Lucy] why do you think that this mechanism is simpler than the one >>> proposed in the draft? To me, it just shifts the request capability >>> outside BGP. It makes BGP simple, but not necessary mean the solution s= impler. >> >> The main point is not about using BGP or not. Here if anything industry = and in particular this WG has been converging to use RT Constrain for contr= olling VPN route distribution. This draft however now proposed ORF which ru= ns over Route Refresh. That means that at least one benefit of RTC is lost = - incremental updates. >> >> In fact I would say this is a grey area how to run RTC and ORF together = for the same set of VRFs. >> >> My focus was not to debate about using BGP rather the focus is to use ri= ght tool for the task. >> >> Imagine I have deployed another L3VPN WG document namely: >> draft-ietf-l3vpn-end-system-01 >> >> In such architecture I have decoupled for a number of good reasons data = plane and control plane to completely different physical boxes. >> Note also that in such design I already have on the complete system a st= ats collector where it is really trivial to trigger a message to v-hub in o= rder to inject more specifics. >> >> Contrary if I am to use proposed solution I need to modify XMPP as well = as number of other system wide components to achieve the goal. >> >> Best regards, >> R. From internet-drafts@ietf.org Mon Oct 21 16:08:04 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928B211E87AF; Mon, 21 Oct 2013 16:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIl0cB7XSQWm; Mon, 21 Oct 2013 16:08:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABAE11E827C; Mon, 21 Oct 2013 16:07:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-end-system-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021230724.32534.96629.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 16:07:24 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:08:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : BGP-signaled end-system IP/VPNs. Author(s) : Pedro Marques Luyuan Fang Ping Pan Amit Shukla Maria Napierala Nabil Bitar Filename : draft-ietf-l3vpn-end-system-02.txt Pages : 24 Date : 2013-10-21 Abstract: This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide a Virtual Network service to end-systems. These end-systems may be used to provide network services or may directly host end-to-end applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-end-system-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.vigoureux@alcatel-lucent.com Wed Oct 23 02:11:08 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC4A11E8352 for ; Wed, 23 Oct 2013 02:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.124 X-Spam-Level: X-Spam-Status: No, score=-110.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhpLmMrDSVp3 for ; Wed, 23 Oct 2013 02:10:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6367D11E8345 for ; Wed, 23 Oct 2013 02:10:55 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9N9Arc8018390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Oct 2013 04:10:54 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9N9Aq3B010882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Oct 2013 11:10:52 +0200 Received: from [172.27.205.127] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 Oct 2013 11:10:52 +0200 Message-ID: <5267929B.5050403@alcatel-lucent.com> Date: Wed, 23 Oct 2013 11:10:51 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: IETF88 - L3VPN - Agenda available - Please send your presentation material Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:11:09 -0000 All, the draft agenda is on-line: http://www.ietf.org/proceedings/88/agenda/agenda-88-l3vpn In case we have missed anything please let us know, but as you'll see, we already nearly fill the 2.5h. Speakers, please start sending your presentation material, and please do so before November the 6th. Martin, for the L3VPN Chairs. From erosen@cisco.com Thu Oct 24 06:54:24 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5D011E83C6; Thu, 24 Oct 2013 06:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWpdY-AZ14Ah; Thu, 24 Oct 2013 06:54:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4721F9005; Thu, 24 Oct 2013 06:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4342; q=dns/txt; s=iport; t=1382622855; x=1383832455; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=PIzvoLwA0C6/UWXzkDaJqw77BNjEjdZL/EGFdSOwUBs=; b=Vf9RrRbUZV2QNQrAQRoXdX24bgEioUlB+7SndVy13+CzYLbt2Iep+iZI K1qN7Ayje/0mR8qdjYt02Agkgqzx1g5IwI7Zmt9PqcjhnoI5fVBeq6eH8 6AFxVsGjALy04K/mPsUMqBl6OH+xbwp5DcJ/U0aBRStWhmHS1qOiKK1T4 c=; X-IronPort-AV: E=Sophos;i="4.93,562,1378857600"; d="scan'208";a="273130267" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 24 Oct 2013 13:54:14 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9ODsDtk000367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 13:54:14 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r9ODsCse002188; Thu, 24 Oct 2013 09:54:12 -0400 From: Eric Rosen To: wang.cui1@zte.com.cn Subject: Re: Global Table Multicast In-reply-to: Your message of Thu, 17 Oct 2013 09:44:41 +0800. Date: Thu, 24 Oct 2013 09:54:12 -0400 Message-ID: <2187.1382622852@erosen-linux> Cc: "Jeffrey \(Zhaohui\) Zhang" , "mboned@ietf.org" , erosen@cisco.com, "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 13:54:24 -0000 > If providers just want to enable Global Multicast Reachablity only, they > just need enable MCAST-IPv6(define in > draft-wang-mboned-glo-ipv6-mcast-reachability) address family only without > enable MCAST-VPN address family which may cause unnecessary route > advertisements. I really don't understand this line of reasoning. Suppose a provider wants to use his backbone network to support both VPN Multicast (MVPN) and and Global Table Multicast (GTM), and wants to use protocols and procedures based on RFC6514 for both. Perhaps, e.g., the provider is already supporting MVPN and now wants to add GTM support, using, as much as possible, the same set of protocols and procedures. Following the procedures of draft-zzhang-l3vpn-mvpn-global-table-mcast, the MVPN C-multicast and A-D routes use the same AFI/SAFI (MCAST-VPN) as the GTM C-multicast and A-D routes. Existing procedures and tools continue to apply. If draft-wang is used, then the provider needs to use two different AFI/SAFIs, one for MVPN and one for GTM. What is the point of using the additional AFI/SAFI? It's just a complication for no benefit; every additional AFI/SAFI brings some operational overhead. If a provider only wants to use his backbone for GTM, the MCAST-VPN SAFI is still fine. I don't know why you think it causes unnecessary route advertisement. You just have to set the RD field in the NLRI to zero, so that the NLRI identifies the global table rather than a VRF. It isn't worth introducing a new SAFI just to shorten the NLRI by a few octets. > 1.Without RD: > a. All the A-D route is more simpler in encoding. Setting the RD to zero is not much of a complication. It's a lot simpler than having a new SAFI. > 2.Without RT No, it's not possible to eliminate the RTs. RTs are absolutely required on the C-multicast Join routes and the Leaf A-D routes. These route types are always "targeted" to a single upstream node, and that node is identified by the RT. Not only is that important for constraining the distribution of the routes, it is also needed so that the upstream node can tell that it is the target of a particular C-multicast Join or Leaf A-D route. I also think it would be unwise to distribute the other route types without RTs, as that would eliminate the ability to constrain the distribution of those routes. It would also eliminate the ability to create extranets that contain both VRFs and global tables. > We can remove VRF Route Import Extended Community No you can't, as that is needed, in general, to identify the "Upstream PE" for a given multicast source or RP. The MVPN procedures depend on being able to identify the Upstream PE ("Upstream PBR" in the draft-zzhang-...-01 terminology). Without the VRF Route Import Extended Community, the MVPN/GTM procedures will only work within a single AS. >.Global multicast reachability is not going to aggregate,so we can remove > the MPLS Label field in PMSI Tunnel Attribute The MPLS Label field in the PMSI Tunnel Attribute of a Leaf A-D route is needed to support Ingress Replication, so it cannot be eliminated. Also, one may wish to aggregate GTM and MVPN traffic in the same tunnel, in which case one would want to use the MPLS label field of the PMSI Tunnel Attribute in an I/S-PMSI A-D route to distinguish the MVPN traffic from the GTM traffic. For cases where the label is not needed, RFC6514 already specifies a way to encode "no label", i.e., set the label field to zero. There is no need to add another yet another attribute just so that one can omit the label field instead of setting it to zero. >From draft-wang: the 6MPE routers convey the IPv4 address of 6MPE Router-ID as the BGP Next Hop for the advertised A-D routes. And the IPv4 address MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. This encoding is consistent with the definition of an IPv4-mapped IPv6 address in [RFC4291]. I was surprised to see this; if one objects to carrying eight octets of RD=0 and/or three octets of label=0, surely one will object to encoding a four-octet IPv4 address in a 16-octet field ;-) Note that this method of encoding the next hop is not consistent with the MVPN standards; please see RFC 6515 for details. From martin.vigoureux@alcatel-lucent.com Thu Oct 24 07:57:39 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9213811E8354 for ; Thu, 24 Oct 2013 07:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.128 X-Spam-Level: X-Spam-Status: No, score=-110.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSDUBauyVQdW for ; Thu, 24 Oct 2013 07:57:31 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C3B8B11E835D for ; Thu, 24 Oct 2013 07:54:55 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9OEsUZr022589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Oct 2013 09:54:35 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9OEsUmp026393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Oct 2013 16:54:30 +0200 Received: from [172.27.205.127] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 24 Oct 2013 16:54:29 +0200 Message-ID: <526934A4.1020708@alcatel-lucent.com> Date: Thu, 24 Oct 2013 16:54:28 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: Re: Please read and comment [Re: WG Last Call for draft-ietf-l3vpn-mldp-vrf-in-band-signaling] References: <14292_1377096453_5214D305_14292_2376_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D07570795@PEXCVZYM13.corporate.adroot.infra.ftgroup> <525D5075.8070301@alcatel-lucent.com> In-Reply-To: <525D5075.8070301@alcatel-lucent.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:57:40 -0000 All, regarding the IPR. As you might have seen it has now been disclosed: https://datatracker.ietf.org/ipr/2216/ Please let the chairs know if you have discussion points about it. Martin Le 15/10/2013 16:25, Martin Vigoureux a écrit : > Working Group, > > we did not formally close this WG LC. There are few reasons to that. > > * We are expecting an IPR disclosure, which would come quite late but > which on the other hand had been communicated by Ice at the time of WG > adoption. > > * No comments were expressed during this LC. While I am fine with not > seeing comments requiring (substantial) changes, I am not satisfied with > complete silence. > We have asked for a review of the document to be performed by a member > of the Routing Directorate, but we are encouraging you to review and > comment on the document until the 25th of October. > > Thank you > > Martin, for the L3VPN Chairs > > > Le 21/08/2013 16:47, thomas.morin@orange.com a écrit : >> Hello working group, >> >> This email starts a two-week Working Group Last Call on >> draft-ietf-l3vpn-mldp-vrf-in-band-signaling, which is considered mature >> and ready for a working group review. >> >> http://tools.ietf.org/html/draft-ietf-l3vpn-mldp-vrf-in-band-signaling >> >> Please read the document if you haven't read the most recent version, >> and send your comments to the list, no later than Wednesday September >> 4th. >> >> Thank you, >> >> -Thomas & Martin >> >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> > > From zhangmingui@huawei.com Fri Oct 25 02:05:53 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A6911E8353; Fri, 25 Oct 2013 02:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiECyg3QL+yL; Fri, 25 Oct 2013 02:05:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAFC821E80AD; Fri, 25 Oct 2013 02:05:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZL47505; Fri, 25 Oct 2013 09:05:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 10:05:33 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 10:05:39 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.234]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Fri, 25 Oct 2013 17:05:32 +0800 From: Mingui Zhang To: "l3vpn@ietf.org" Subject: FW: I-D Action: draft-zhang-l3vpn-label-sharing-01.txt Thread-Topic: I-D Action: draft-zhang-l3vpn-label-sharing-01.txt Thread-Index: AQHOzjs12GcUazYvVk2zdJUUGhGnEZoE/3hA Date: Fri, 25 Oct 2013 09:05:31 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E733643454@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pwe3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:05:53 -0000 Hi, We received lots of comments on the initial version. The draft was updated = and we included a new author. This draft tries to bring up a simple solution for egress PE protection. It= is easily to be deployed and brings no big change. Welcome your comments o= n the mailing list and at the Vancouver meeting. Thanks, Mingui PS: I copied this email to the pwe3 mailing list since there is a companion= draft: ICCP Application TLVs for VPN Route Label Sharing, http://tools.iet= f.org/html/draft-zhang-pwe3-iccp-label-sharing-00 >-----Original Message----- >From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >On Behalf Of internet-drafts@ietf.org >Sent: Monday, October 21, 2013 4:42 PM >To: i-d-announce@ietf.org >Subject: I-D Action: draft-zhang-l3vpn-label-sharing-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > > Title : Label Sharing for Fast PE Protection > Author(s) : Mingui Zhang > Peng Zhou > Russ White > Filename : draft-zhang-l3vpn-label-sharing-01.txt > Pages : 13 > Date : 2013-10-21 > >Abstract: > This document describes a method to be used by Service Providers to > provide fast protection of VPN connections for a CE. Egress PEs in a > redundant group always assign the same label for VPN routes from a > VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the > domain of the IP/MPLS backbone network as an agent of the CE router. > Primary and backup tunnels terminated at the vNH are set up by the > BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, the > backup egress PEs can recognize the "shared" VPN route label, so that > the failure affected traffic can be smoothly switched to the backup > PE for delivery without changing its VPN route label. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-zhang-l3vpn-label-sharing > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l3vpn-label-sharing-01 > > >Please note that it may take a couple of minutes from the time of submissi= on >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From zzhang@juniper.net Mon Oct 28 20:13:57 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5611E8200 for ; Mon, 28 Oct 2013 20:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1jvz5g8JJer for ; Mon, 28 Oct 2013 20:13:51 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 91AAA11E81F7 for ; Mon, 28 Oct 2013 20:13:47 -0700 (PDT) Received: from mail173-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE003.bigfish.com (10.236.130.66) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Oct 2013 03:13:47 +0000 Received: from mail173-co9 (localhost [127.0.0.1]) by mail173-co9-R.bigfish.com (Postfix) with ESMTP id DDA901400A4; Tue, 29 Oct 2013 03:13:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail173-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(69226001)(85306002)(76786001)(76796001)(76576001)(77096001)(76176001)(56816003)(77982001)(59766001)(56776001)(54316002)(76482001)(83322001)(79102001)(81542001)(63696002)(65816001)(66066001)(80022001)(33646001)(4396001)(47976001)(46102001)(54356001)(50986001)(51856001)(47736001)(74876001)(49866001)(81342001)(81686001)(81816001)(80976001)(53806001)(74706001)(74316001)(31966008)(74366001)(74662001)(74502001)(47446002)(83072001)(87266001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB080; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail173-co9 (localhost.localdomain [127.0.0.1]) by mail173-co9 (MessageSwitch) id 1383016424782814_2359; Tue, 29 Oct 2013 03:13:44 +0000 (UTC) Received: from CO9EHSMHS008.bigfish.com (unknown [10.236.132.226]) by mail173-co9.bigfish.com (Postfix) with ESMTP id BA571540040; Tue, 29 Oct 2013 03:13:44 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS008.bigfish.com (10.236.130.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 29 Oct 2013 03:13:44 +0000 Received: from BY2PR05MB080.namprd05.prod.outlook.com (10.242.38.17) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 29 Oct 2013 03:13:42 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB080.namprd05.prod.outlook.com (10.242.38.17) with Microsoft SMTP Server (TLS) id 15.0.810.5; Tue, 29 Oct 2013 03:13:39 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.16]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.16]) with mapi id 15.00.0810.005; Tue, 29 Oct 2013 03:13:39 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "erosen@cisco.com" , "l3vpn@ietf.org" Subject: Comments on draft-ietf-l3vpn-mvpn-bidir-06 Thread-Topic: Comments on draft-ietf-l3vpn-mvpn-bidir-06 Thread-Index: AQHOz1fRlVM+2THqI0majVHgpF2oog== Date: Tue, 29 Oct 2013 03:13:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 0014E2CF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 03:13:57 -0000 Eric, Please see comments below. Some are just editorial nits. 1.2.2. Reasons for Using Bidirectional P-tunnels (It must be noted though that this particular use of bidirectional P-tunnels is not compatible with the duplicate prevention scheme of [MVPN] section 9.1.1, and thus would only be used if the duplication prevision schemes of [MVPN] sections 9.1.2 or 9.1.3 are suitable.) The concept of using PE Distinguisher label to create an inner tunnel that = is on top of the outer bidir tunnel is introduced later in the sections. Be= fore then, it is better not to say the above, because with the PE Distingui= sher label it can use [MVPN] section 9.1.1 to discard duplicate traffic. These two reasons for using bidirectional P-tunnels are somewhat in conflict with each other, since ... s/are/seem to be/ ? They are not really conflicting, for the reason you gav= e. An SP may decide to use bidirectional P-tunnels for either or both of these reasons. ... Note that even if the reason for using bidirectional P-tunnels is to provide C-BIDIR support, the same P-tunnels can also be used to carry unidirectional C-flows, if that is the choice of the SP. The above two separate paragraphs would go better if together. The Partitioned Method is a pre-requisite for implementing the "Partitioned Sets of PEs" technique of supporting C-BIDIR, as discussed in [MVPN] section 11.2. The Flat Partitioned Method is a pre-requisite for implementing the "Partial Mesh of MP2MP P-tunnels" technique for carrying customer bidirectional (C-BIDIR) traffic, as discussed in [MVPN] Section 11.2.3. Perhaps add the following two paragraphs to between the above two paragraph= s? The Partitioned Method is a pre-requisite for implementing the "Discarding Packets from Wrong PE" technique as discussed in [MVPN] Section 9.1.1. The Hierarchical Partitioned Method is a pre-requisite for Implementing the "Using PE Distinguisher Labels" technique for carry= ing customer bidirectional (C-BIDIR) traffic, as discussed in [MVPN] Section 11.2.2. ---------------- The Flat Partitioned Method may be used to instantiate the following types of PMSI: I-PMSI, (C-*,C-*) S-PMSI, (C-*,C-BIDIR) S-PMSI, or (C-*,C-G) S-PMSI where C-G is a bidirectional C-group. Why not (C-*,C-G) where C-G is unidir? Why not (C-S,C-G) and (C-S,C-*) S-PM= SIs? Imagine a provider that only uses PIM-Bidir in its core? I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one if its VRF interfaces is the next hop interface on its best path to the C-RPA of any bidirectional C-group of the MVPN. s/one if/one of/ Perhaps it is good to define a (C-*,C-G-BIDR) term. Currently you say "(C-*= ,C-G) S-PMSI where C-G is a bidirectional C-group" but the "where..." part = is not always included, even when it should be. For example: When the Flat Partitioned Method is used to instantiate a (C-*,C-*) S-PMSI, a (C-*,C-BIDIR) S-PMSI, or a (C-*,C-G) S-PMSI, a PE that originates the corresponding S-PMSI A-D route MUST include in that route a PTA specifying a bidirectional P-tunnel. Per the procedures of [MVPN] and [MVPN-BGP], a PE will originate such an S-PMSI A-D route only if one of the PE's VRF interfaces is the next hop interface of the PE's best path to the C-RPA of a C-BIDIR group that is to be carried on the specified S-PMSI. It would be easier to simply say (C-*,C-G-BIDR). 3.2.1.2. When an I-PMSI is a 'Match for Transmission' ... Note that if a VRF is configured to provide C-BIDIR support using the Flat Partitioned Method, but there is no matching S-PMSI A-D route (according to section 3.2.1.1) and there is no such I-PMSI A-D route meeting the conditions of this section, then a provisioning error has occurred, and the C-flow will not be transmitted. Maybe the above paragraph can be simplified as: If there is no I-PMSI A-D route meeting the above conditions, the C-flow must not be transmitted. The reason are the following: - The omitted text is basically the context here. Listing them explicitly a= ctually adds burden for people to digest/correlate. - it may not be a provisioning error but simply that such I-PMSI A-D route = has not been received (transient condition). Same with the last paragraph of 3.2.2.3. 3.2.1.3. When an S-PMSI is a 'Match for Reception' ... If there is an S-PMSI A-D route matching (C-*,C-G), according to these rules, its PTA must specify a bidirectional P-tunnel. Does the "must" in the above paragraph indicates a fact or a requirement? I= f it's a fact, maybe change "must specify" to "must have specified". If it'= s a requirement, it should be put into the individual rules like in the tra= nsmit case, so that we don't pick a route that does not specify a bidir tun= nel. 3.2.1.4 seems to be just an add-on situation after failing to find a (C-*,C= -*) S-PMSI A-D route. Separating into two sections instead of just doing a = single "When a PMSI is a match for reception" adds burden for people to fol= low. Same question on the transmission side (3.2.1.1 and 3.2.1.2). 3.2.2. Hierarchical Partitioning ... The PEs that are required to originate the routes mentioned in the previous paragraph are those that satisfy one of the following conditions: ... - The PE might have to transmit customer multicast traffic on the PMSI identified in the route, s/multicast traffic/unidirectional multicast traffic/ The Hierarchical Partitioned Method may be used to instantiate an I-PMSI, a (C-*,C-*) S-PMSI, or a (C-*,C-BIDIR) S-PMSI. ... If (and only if) C-G is a C-BIDIR group, the Hierarchical Partitioned method may be used to instantiate the (C-*,C-G) S-PMSI. In this case, when a (C-*,C-G) S-PMSI A-D route is originated, it is originated only by a PE whose best path to the C-RPA for C-G is via a VRF interface, and that PE MUST be the root node of the MP2MP LSP identified in the PTA of the A-D route. (C-*,C-BIDIR) and (C-*,C-G-BIDIR) should be the same, but why are they sepa= rated in the text? The text before the above paragraph allows that a differ= ent PE could be the root of the mp2mp tunnel, but why is the same not allow= ed for (C-*,C-G-BIDIR)? In fact, 3.2.2.4 seems to allow that. Why can't (C-*,C-G-UNIDIR) PMSI be instantiated with Hierarchical Partition= ed method? As in [MVPN] and [MVPN-BGP], an S-PMSI A-D route does not need to be originated by a particular PE, say PE1, until PE1 has received a "join" indicating that some other PE is interested in receiving customer multicast traffic forwarded from PE1. In bidir case, traffic may not be from PE1 at all, so may be rewording the = last two lines of the above paragraph to the following: "join" from some other PE. -------------- The Hierarchical Partitioned method MUST NOT be used to instantiate a (C-S,C-G) or a (C-S,C-*) S-PMSI. Why is the above restriction put in place? If there is a bidirectional tunn= el whose leave set happen to match (or just slightly over cover) the (C-S,C= -G) or (C-S,C-*) receiver PEs, why can't that tunnel be used? If the "partitioned sets of PEs" method of supporting C-BIDIR is used, as discussed in section 11.2 of [MVPN] and section 3.6 of [RFC6517], C-BIDIR flows MUST NOT be carried on a P-tunnel specified in the PTA of a (C-S,C-G) or a (C-S,C-*) S-PMSI. This should be moved out of this section (hierarchical partitioned) because= it applies to both partitioned method. I also wonder if the restriction ap= plies to unpartitioned method - the spec does not say. Is it because C-BIDI= R forwarding is never based on source (hence the restriction applies to unp= artitioned method as well) or does it have anything to do with the methods? The PE Distinguisher Labels attribute specifies a set of bindings. Each IP address is the IP address of a PE router that is expected to receive the route that contains the attribute. It really is that "Each IP address is that of a PE router that may be a Dis= tinguished PE", right? When a PE Distinguisher Labels attribute is included in a given I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address of each of the following sets of PEs: - The root node of the MP2MP LSP identified in the PTA of the route, - Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP LSP identified in the PTA of the route. This requirement can be met by assigning a label to every PE that has originated an Intra-AS I-PMSI A-D route. However, if it is known apriori that all the non-C-BIDIR sources are in sites attached to only a subset of the PEs, PE Distinguisher labels can be specified for that subset alone. What about the Upstream PEs wrt C-BIDIR C-RPAs, especially in the case of (= C-*,C-BIDIR) S-PMSI? 3.2.2.3. When an I-PMSI is a 'Match for Transmission' For c-bidir, in S-PMSI case, a matching S-PMSI originated by any PE can be = used; in I-PMSI case, only the one advertised by the upstream PE wrt C-RPA = can be used. Why? I think S-PMSI should also require that the one from the = upstream PE is used - otherwise an S-PMSI from a different partition may be= picked. 3.2.2.5. When an I-PMSI is a 'Match for Reception" ... When the Hierarchical Partitioned Method is used, each Intra-AS I-PMSI A-D routes of the MVPN will have a PTA, and all such PTAs will specify the same bidirectional P-tunnel. The above text should be moved to section 3.2.2 (before the subsections), a= nd change "will" to SHOULD/MUST. Or could we delete it entirely? We discussed before that all such PTAs SHOU= LD specify the same tunnel to simplify the forwarding logic on the receivin= g PEs. But now I don't even see how it complicates forwarding logic if they= don't specify the same tunnel. For a particular unidir c-flow we use the t= unnel advertised in the upstream PE's I-PMSI and program the forwarding log= ic accordingly; for a particular c-g-bidir we use the tunnel advertised in = the I-PMSI from the upstream PE wrt the C-RPA and program the forwarding lo= gic accordingly (this matches 3.2.2.3) - no multiple choices. 3.2.3.1. When an S-PMSI is a 'Match for Transmission' ... - Otherwise, if there is an S-PMSI A-D route currently originated by PE1, whose NLRI contains (C-*,C-BIDIR), and if C-G is a BIDIR group, the (C-S,C-G) C-flow matches that route. For a C-G-BIDIR, an implementation may not know about C-S at all, so saying= (C-S,C-G) is not accurate. Additionally, the rules require that the S-PMSI A-D route originated by the= transmitting PE is used. I don't see why a route originated by another PE = cannot be used for C-G-BIDIR, especially when we're using procedures of [MV= PN] section 11.1? In fact, the rules for 'Match for Reception', which are t= he rules in 3.2.2 of [MVPN-WILDCARD] with the last paragraph modified, show= that any (C-*,C-G-BIDIR) S-PMSI A-D route can be used, and that may not be= the transmitting PE. 3.2.3.2. When an S-PMSI is a 'Match for Reception' ... This is changed to: "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2, but C-G is a BIDIR group and PE1 has an installed (C-*,C-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that route. ... This also shows that any (C-*,C-BIDIR) S-PMSI A-D route can be a match. Thanks. Jeffrey From lucy.yong@huawei.com Thu Oct 31 09:57:47 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DA21E8114 for ; Thu, 31 Oct 2013 09:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4zlRA1J763C for ; Thu, 31 Oct 2013 09:57:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4C921E8105 for ; Thu, 31 Oct 2013 09:57:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXK73596; Thu, 31 Oct 2013 16:57:36 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Oct 2013 16:57:06 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Oct 2013 16:57:27 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Thu, 31 Oct 2013 09:56:31 -0700 From: Lucy yong To: "draft-ietf-l3vpn-end-system@tools.ietf.org" Subject: comments on draft-ietf-l3vpn-end-system Thread-Topic: comments on draft-ietf-l3vpn-end-system Thread-Index: Ac7WWjPqAwkeR9HnTKCUhMHnuaNSfA== Date: Thu, 31 Oct 2013 16:56:30 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452E97B8@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.26] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452E97B8dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 16:57:47 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452E97B8dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Petro and other co-authors, Here are some comments. The draft provides an IP VPN service solution to end-system virtual interfa= ce. But, IMHO, it is not a network virtualization solution. The network vir= tualization in NVO3 or industry has more ingredients besides providing IP V= N. Do you have a plan to extend this solution for the network virtualizatio= n? If not, suggest distinguishing two. This solution essential is having network-based access control, which could= make VM mobility solution very hard. Because the network has to give the a= ccess permission first to the new site first. Using VPN/Route Target concep= t provides VPN route path control also results in quite complex import/expo= rt RT policies configuration. People may not realize that yet. The solutio= n further pretty relies on egress assigned local label for VN traffic segre= gation in data plane and facilities egress local forwarding process. IMO: t= his solution principal is quite different from industry vision on cloud app= lications, virtualization, enabling a cloud application in a full virtualiz= ed environment although it may fit some cloud applications. Like to hear yo= ur opinion on this. Text: BGP also optimizes the route distribution for sparse events. The Route Target Constraint [RFC4684] extension, builds an optimal distribution tree for message propagation based on VPN membership. Comments: This method optimized the route distribution for interested VPN s= ites, not interested end-system virtual network interface. In a virtualizat= ion environment, caching interested virtual network interfaces at the forwa= rder is valuable for the scalability. What is the point in the given example? "As an example consider a topology= in which 100 End-System Route Servers are deployed in a network each servi= ng a subset of the VPN forwarding elements...". It is obvious if using mor= e End-System Route Servers, each server will serve less number of clients? Text: From an IP address assignment point of view, a virtual network interface is addressed out of the virtual IP topology and associated with a "closed user group" or VPN, while the physical interface of the machine is addressed in the network infrastructure topology. The statement is not clear to me. Does it mean that IP address separation b= etween the VN and physical network? Text: Both static and dynamic IP address allocation can be supported. The later assumes that the VPN Forwarder implements a DHCP relay or DHCP proxy functionality. Does this mean to assign an IP address to virtual network interface? The so= lution also require IP configuration on the client side of the interface. T= his means that the solution requires the special configuration on guest OS,= is that right? Have any end-system vender implemented this solution? Do you also plan to address multicast support in the solution? The draft uses both virtual interface and virtual network interface, sugges= t making the consistency. The draft should define the end-system in the terminology. Look forward to discussing with you more on the solution in YVR. Regards, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D452E97B8dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Petro and other co-authors,

 

Here are some comments.

 

The draft provides an IP VPN service solution to end-syste= m virtual interface. But, IMHO, it is not a network virtualization solution= . The network virtualization in NVO3 or industry has more ingredients besides providing IP VN. Do you have a plan to extend= this solution for the network virtualization? If not, suggest distinguishi= ng two.

 

This solution essential is having network-based access con= trol, which could make VM mobility solution very hard. Because the network = has to give the access permission first to the new site first. Using VPN/Route Target concept provides VPN route path con= trol also results in quite complex import/export RT policies configuration.=  People may not realize that yet. The solution further pretty relies = on egress assigned local label for VN traffic segregation in data plane and facilities egress local forwarding p= rocess. IMO: this solution principal is quite different from industry visio= n on cloud applications, virtualization, enabling a cloud application in a = full virtualized environment although it may fit some cloud applications. Like to hear your opinion on this.

 

Text:

   BGP also optimi= zes the route distribution for sparse events.

   The Route Targe= t Constraint [RFC4684] extension, builds an optimal

   distribution tree for message propagation bas= ed on VPN membership.

 

Comments: This method optimized the route distribution for= interested VPN sites, not interested end-system virtual network interface.= In a virtualization environment, caching interested virtual network interfaces at the forwarder is valuable for the scalabilit= y.

 

What is the point in the giv= en example?  “As an example consider a topology in which 100 End= -System Route Servers are deployed in a network each serving a subset of the VPN forwarding elements…”.  It is obvious if using more End-System Route Servers, e= ach server will serve less number of clients?

 

Text:

   From an IP addr= ess assignment point of view, a virtual network

   interface is ad= dressed out of the virtual IP topology and associated

   with a "cl= osed user group" or VPN, while the physical interface of

   the machine is addressed in the network infra= structure topology.

 

The statement is not clear to me. Does it mean that IP add= ress separation between the VN and physical network?

 

Text:

   Both static and= dynamic IP address allocation can be supported.  The

   later assumes t= hat the VPN Forwarder implements a DHCP relay or DHCP

   proxy functionality.

Does this mean to assign an IP address to virtual network = interface? The solution also require IP configuration on the client side of= the interface. This means that the solution requires the special configuration on guest OS, is that right?

 

Have any end-system vender implemented this solution?=

 

Do you also plan to address multicast support in the solut= ion?

 

The draft uses both virtual interface and virtual network = interface, suggest making the consistency.  

 

The draft should define the end-system in the terminology.=

 

Look forward to discussing with you more on the solution i= n YVR.

 

Regards,

Lucy

 

--_000_2691CE0099834E4A9C5044EEC662BB9D452E97B8dfweml509mbxchi_-- From pedro.r.marques@gmail.com Thu Oct 31 11:28:27 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E69411E822D for ; Thu, 31 Oct 2013 11:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RkvW42h57rq for ; Thu, 31 Oct 2013 11:28:26 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 28A6F11E8275 for ; Thu, 31 Oct 2013 11:28:17 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so2770439pde.29 for ; Thu, 31 Oct 2013 11:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2A+srDv+0Uz2JUuKSwVUz9iWgsl8VJ6TqYnVHgDaFjI=; b=GtKqAiOxKqtRXNFp67s9HgXI0PSYN4tXQh3StuMsLyziHi4lXF23PbxpXaP7E8o2FE 3SafwN/BJQlLXSK1CVxTqd07TWbL7A6wyUitg1/Uqg94sQgB9/Q1xUnKGagl9Yh7D/HS lAwtaHdugpzIvdZgd8egJxAFWDlK/f+x8vJPOFtLMBwE1wBg1gYCjoeCLDv86s3gIORT 5+FYotSwNpcMn1Kscw9gxTFCu2d6YePzMtHW00VoY0IDFiDIlJzGa41+2Oz2ysQTFWYg WeBdoky9mNiq6P7jjpP9Sm6SfnlYbFN7UETX5uPz3yeqKiX7+JknV11lZyg5aQIKITTf qISg== X-Received: by 10.68.12.100 with SMTP id x4mr4541145pbb.7.1383244096651; Thu, 31 Oct 2013 11:28:16 -0700 (PDT) Received: from pedros-mbp.jnpr.net (natint3.juniper.net. [66.129.224.36]) by mx.google.com with ESMTPSA id og5sm5696393pbb.10.2013.10.31.11.28.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 11:28:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DEB85721-4B58-4562-BD9D-5E415221CE2F" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: comments on draft-ietf-l3vpn-end-system From: Pedro Roque Marques In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452E97B8@dfweml509-mbx.china.huawei.com> Date: Thu, 31 Oct 2013 11:28:13 -0700 Message-Id: References: <2691CE0099834E4A9C5044EEC662BB9D452E97B8@dfweml509-mbx.china.huawei.com> To: Lucy yong X-Mailer: Apple Mail (2.1816) Cc: "draft-ietf-l3vpn-end-system@tools.ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:28:27 -0000 --Apple-Mail=_DEB85721-4B58-4562-BD9D-5E415221CE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 31, 2013, at 9:56 AM, Lucy yong wrote: > Hi Petro and other co-authors, > =20 > Here are some comments. > =20 > The draft provides an IP VPN service solution to end-system virtual = interface. But, IMHO, it is not a network virtualization solution. Can you please elaborate ? There is one implementation based on this = document that provides a network virtualization solution. You can find = additional information at http://opencontrail.org. To my knowledge there = is no functionality missing in that solution. It uses additional = specifications but when it comes to IP unicast it does follow this = document. > The network virtualization in NVO3 or industry has more ingredients = besides providing IP VN. Do you have a plan to extend this solution for = the network virtualization? If not, suggest distinguishing two. Solution is different from ingredients. When it comes to the solution, = the OpenContrail solution uses a set of published documents to provide: = ip unicast, ip broadcast/multicast, EVPN and service enablement across = virtual networks (i.e. automatically managing the connectivity of = virtual appliances). To my knowledge, the solution fulfills the needs a = self-service data-center offering for both private and public = data-centers. It may be that we use less ingredients... if that is the case i would = take that as an advantage. > =20 > This solution essential is having network-based access control, which = could make VM mobility solution very hard. I don't understand why you connected both. But the solution i describe = above provides both NAC and VM mobility. Can you please clarify the = point you trying to make. > Because the network has to give the access permission first to the new = site first. Using VPN/Route Target concept provides VPN route path = control also results in quite complex import/export RT policies = configuration. By complexity are you referring to computational complexity = (http://en.wikipedia.org/wiki/Computational_complexity_theory) ? Or are = you referring to any sort of manual process ? When it comes to computation complexity, you can inspect the source code = here: = https://github.com/Juniper/contrail-controller/blob/master/src/config/sche= ma-transformer/to_bgp.py As far as i can tell, the algorithmic complexity of calculating the RT = policies seems to be O(n) where n is the number of virtual-networks a = specific network is connected to. There is no manual process involved. > People may not realize that yet. The solution further pretty relies = on egress assigned local label for VN traffic segregation in data plane = and facilities egress local forwarding process. IMO: this solution = principal is quite different from industry vision on cloud applications, = virtualization, enabling a cloud application in a full virtualized = environment although it may fit some cloud applications. Like to hear = your opinion on this. Egress assigned labels are incredibly powerful. MPLS has proven this. = The fact that the semantics of the label are assigned by the egress has = enabled many applications that are not possible with a global label = assignment such as a VLAN tag. When it comes to the "industry vision" part of your statement i think = this is just a question of personal opinion.=20 > =20 > Text: > BGP also optimizes the route distribution for sparse events. > The Route Target Constraint [RFC4684] extension, builds an optimal > distribution tree for message propagation based on VPN membership. > =20 > Comments: This method optimized the route distribution for interested = VPN sites, not interested end-system virtual network interface. In a = virtualization environment, caching interested virtual network = interfaces at the forwarder is valuable for the scalability. I'm not sure what you mean. If you are talking about having the full = reachability information vs a local cache of the destinations that are = currently being used then this is a tradeoff that can be reasoned about: - By pre-populating all reachability information one consumes memory. = e.g. a really large routing table may be 20/30M... modern servers tend = to start at 128G. Pre-populating the routing information reduces latency = of new communications and provides a more predictable environment by = having the networking state being control driven rather than = data-driven. Previous experience with networking technologies point to clear = advantages on the side of technologies that pre-populate routing = information at control plane time vs data-driven approaches. BGP/MPLS = L3VPNs being a clear example of this. > =20 > What is the point in the given example? =93As an example consider a = topology in which 100 End-System Route Servers are deployed in a network = each serving a subset of the VPN forwarding elements=85=94. It is = obvious if using more End-System Route Servers, each server will serve = less number of clients? Yes. Horizontal scalability of the control plane. It is a feature = missing from the "industry vision" in many cases. > =20 > Text: > =46rom an IP address assignment point of view, a virtual network > interface is addressed out of the virtual IP topology and = associated > with a "closed user group" or VPN, while the physical interface of > the machine is addressed in the network infrastructure topology. > =20 > The statement is not clear to me. Does it mean that IP address = separation between the VN and physical network? Yes. That is correct. > =20 > Text: > Both static and dynamic IP address allocation can be supported. = The > later assumes that the VPN Forwarder implements a DHCP relay or = DHCP > proxy functionality. > Does this mean to assign an IP address to virtual network interface? Yes. The discussion is whether virtual network interface addresses are = statically or dynamically assigned from the perspective of the guest. > The solution also require IP configuration on the client side of the = interface. This means that the solution requires the special = configuration on guest OS, is that right? No. Guest use 3 common methods of acquiring IP addresses: 1. Config file injection from the hypervisor. 2. metadata service: = http://docs.openstack.org/grizzly/openstack-compute/admin/content//metadat= a-service.html 3. DHCP. My personal observation is that deployments are mostly gravitating = torwards DHCP. > =20 > Have any end-system vender implemented this solution? Juniper Networks. This solution is also included as part of other = vendors: http://www.cloudscaling.com/blog/press-releases/ocs-2-5-ga/ = http://thoughtsoncloud.com/index.php/2013/09/more-advances-in-open-cloud-a= rchitecture/ > =20 > Do you also plan to address multicast support in the solution? It is included. The document is = http://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01. Unfortunately i've not updated it in a while. it is on my TODO list. > =20 > The draft uses both virtual interface and virtual network interface, = suggest making the consistency. Good point . > =20 > =20 > The draft should define the end-system in the terminology. Agree. Pedro.= --Apple-Mail=_DEB85721-4B58-4562-BD9D-5E415221CE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Oct = 31, 2013, at 9:56 AM, Lucy yong <lucy.yong@huawei.com> = wrote:

Hi Petro and = other co-authors,
 
Here are some = comments.
 
The draft = provides an IP VPN service solution to end-system virtual interface. = But, IMHO, it is not a network virtualization solution. =

Can you please = elaborate ? There is one implementation based on this document that = provides a network virtualization solution. You can find additional = information at http://opencontrail.org. To my = knowledge there is no functionality missing in that solution. It uses = additional specifications but when it comes to IP unicast it does follow = this document.

The network virtualization in NVO3 or industry has more = ingredients besides providing IP VN. Do you have a plan to extend this = solution for the network virtualization? If not, suggest distinguishing = two.

Solution = is different from ingredients. When it comes to the solution, the = OpenContrail solution uses a set of published documents to provide: ip = unicast, ip broadcast/multicast, EVPN and service enablement across = virtual networks (i.e. automatically managing the connectivity of = virtual appliances). To my knowledge, the solution fulfills the needs a = self-service data-center offering for both private and public = data-centers.

It may be that we use less = ingredients... if that is the case i would take that as an = advantage.

 
This solution = essential is having network-based access control, which could make VM = mobility solution very = hard.

I don't = understand why you connected both. But the solution i describe above = provides both NAC and VM mobility. Can you please clarify the point you = trying to make.

Because the network has to give the access permission = first to the new site first. Using VPN/Route Target concept provides VPN = route path control also results in quite complex import/export RT = policies = configuration.

By= complexity are you referring to computational complexity (http= ://en.wikipedia.org/wiki/Computational_complexity_theory) ? Or are = you referring to any sort of manual process =  ?

When it comes to computation = complexity, you can inspect the source code here:
<= br>
As far as i can tell, the algorithmic complexity of = calculating the RT policies seems to be O(n) where n is the number of = virtual-networks a specific network is connected to. There is no manual = process involved.

 People may not realize that yet. The solution = further pretty relies on egress assigned local label for VN traffic = segregation in data plane and facilities egress local forwarding = process. IMO: this solution principal is quite different from industry = vision on cloud applications, virtualization, enabling a cloud = application in a full virtualized environment although it may fit some = cloud applications. Like to hear your opinion on = this.

Egress = assigned labels are incredibly powerful. MPLS has proven this. The fact = that the semantics of the label are assigned by the egress has enabled = many applications that are not possible with a global label assignment = such as a VLAN tag.

When it comes to the = "industry vision" part of your statement i think this is just a question = of personal opinion. 

 
Text:
   BGP = also optimizes the route distribution for sparse = events.
   The = Route Target Constraint [RFC4684] extension, builds an = optimal
   = distribution tree for message propagation based on VPN = membership.
 
Comments: This = method optimized the route distribution for interested VPN sites, not = interested end-system virtual network interface. In a virtualization = environment, caching interested virtual network interfaces at the = forwarder is valuable for the = scalability.

I'm = not sure what you mean. If you are talking about having the full = reachability information vs a local cache of the destinations that are = currently being used then this is a tradeoff that can be reasoned = about:
- By pre-populating all reachability information one = consumes memory. e.g. a really large routing table may be 20/30M... = modern servers tend to start at 128G. Pre-populating the routing = information reduces latency of new communications and provides a more = predictable environment by having the networking state being control = driven rather than data-driven.

Previous = experience with networking technologies point to clear advantages on the = side of technologies that pre-populate routing information at control = plane time vs data-driven approaches. BGP/MPLS L3VPNs being a clear = example of this.


 
What is the point = in the given example?  =93As an example consider a topology in = which 100 End-System Route Servers are deployed in a network each = serving a subset of the VPN forwarding elements=85=94.  It is obvious = if using more End-System Route Servers, each server will serve less = number of = clients?

Yes. = Horizontal scalability of the control plane. It is a feature missing = from the "industry vision" in many cases.

 
Text:
   =46rom= an IP address assignment point of view, a virtual = network
   = interface is addressed out of the virtual IP topology and = associated
   with = a "closed user group" or VPN, while the physical = interface of
   the = machine is addressed in the network infrastructure = topology.
 
The statement is = not clear to me. Does it mean that IP address separation between the VN = and physical = network?

Yes. That = is correct.

 
Text:
   Both = static and dynamic IP address allocation can be supported.  = The
   = later assumes that the VPN Forwarder implements a DHCP relay or = DHCP
   = proxy functionality.
Does this mean to = assign an IP address to virtual network = interface?

Yes. = The discussion is whether virtual network interface addresses are = statically or dynamically assigned from the perspective of the = guest.

The solution also require IP configuration on the = client side of the interface. This means that the solution requires the = special configuration on guest OS, is that = right?

No. Guest use = 3 common methods of acquiring IP addresses:
1. Config file = injection from the hypervisor.
3. = DHCP.

My personal observation is that = deployments are mostly gravitating torwards = DHCP.

 
Have any = end-system vender implemented this = solution?

Juniper = Networks. This solution is also included as part of other = vendors:

 
Do you also plan = to address multicast support in the = solution?

It is = included. The document is http= ://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01.
Un= fortunately i've not updated it in a while. it is on my TODO = list.

 
The draft uses = both virtual interface and virtual network interface, suggest making the = consistency.
Good point = .

 
 
The draft should = define the end-system in the = terminology.
Agree.

  Pedro.
= --Apple-Mail=_DEB85721-4B58-4562-BD9D-5E415221CE2F-- From wang.cui1@zte.com.cn Thu Oct 31 19:52:06 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D509A11E82B2; Thu, 31 Oct 2013 19:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.512 X-Spam-Level: X-Spam-Status: No, score=-92.512 tagged_above=-999 required=5 tests=[AWL=-2.562, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbtgonNXdNpD; Thu, 31 Oct 2013 19:52:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5016D11E82AF; Thu, 31 Oct 2013 19:51:59 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 92CC31290295; Fri, 1 Nov 2013 10:51:50 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B35ED706BC3; Fri, 1 Nov 2013 10:51:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id rA12piub091139; Fri, 1 Nov 2013 10:51:44 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <2187.1382622852@erosen-linux> To: erosen@cisco.com Subject: =?GB2312?B?tPC4tDogUmU6IEdsb2JhbCBUYWJsZSBNdWx0aWNhc3Q=?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Fri, 1 Nov 2013 10:51:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-11-01 10:51:46, Serialize complete at 2013-11-01 10:51:46 Content-Type: multipart/alternative; boundary="=_alternative 000FBE2D48257C16_=" X-MAIL: mse01.zte.com.cn rA12piub091139 Cc: "mboned@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 02:52:07 -0000 This is a multipart message in MIME format. --=_alternative 000FBE2D48257C16_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrEVyaWOjrA0KDQogIFRvZGF5IGlzIGEgc3BlY2lhbCBkYXksIHNvLCBmaXJzdCwgSGFwcHkg SGFsbG93ZWVuIDopIA0KDQogIFRoZW4gdGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJIHN0aWxsIGhh dmUgc29tZSBxdWVzdGlvbnMgc2VlaW5nIGlubGluZSANCmJlbG93LiBXb3VsZCB5b3UgcGxlYXNl IGV4cGxhaW4gZm9yIG1lPyANCg0KICBUaGFua3M6KQ0KDQpCUnMsDQpMaW5kYSBXYW5nDQoNCkVy aWMgUm9zZW4gPGVyb3NlbkBjaXNjby5jb20+INC009ogMjAxMy0xMC0yNCAyMTo1NDoxMjoNCg0K PiA+IElmIHByb3ZpZGVycyBqdXN0IHdhbnQgdG8gZW5hYmxlIEdsb2JhbCBNdWx0aWNhc3QgUmVh Y2hhYmxpdHkgb25seSwgDQp0aGV5DQo+ID4ganVzdCBuZWVkIGVuYWJsZSBNQ0FTVC1JUHY2KGRl ZmluZSBpbg0KPiA+IGRyYWZ0LXdhbmctbWJvbmVkLWdsby1pcHY2LW1jYXN0LXJlYWNoYWJpbGl0 eSkgYWRkcmVzcyBmYW1pbHkgb25seSANCndpdGhvdXQNCj4gPiBlbmFibGUgTUNBU1QtVlBOIGFk ZHJlc3MgZmFtaWx5IHdoaWNoIG1heSBjYXVzZSB1bm5lY2Vzc2FyeSByb3V0ZQ0KPiA+IGFkdmVy dGlzZW1lbnRzLg0KPiANCj4gSSByZWFsbHkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGxpbmUgb2Yg cmVhc29uaW5nLg0KPiANCj4gU3VwcG9zZSBhIHByb3ZpZGVyIHdhbnRzIHRvIHVzZSBoaXMgYmFj a2JvbmUgbmV0d29yayB0byBzdXBwb3J0IGJvdGggVlBODQo+IE11bHRpY2FzdCAoTVZQTikgYW5k IGFuZCBHbG9iYWwgVGFibGUgTXVsdGljYXN0IChHVE0pLCBhbmQgd2FudHMgdG8gdXNlDQo+IHBy b3RvY29scyBhbmQgcHJvY2VkdXJlcyBiYXNlZCBvbiBSRkM2NTE0IGZvciBib3RoLiAgUGVyaGFw cywgZS5nLiwgdGhlDQo+IHByb3ZpZGVyIGlzIGFscmVhZHkgc3VwcG9ydGluZyBNVlBOIGFuZCBu b3cgd2FudHMgdG8gYWRkIEdUTSBzdXBwb3J0LCANCnVzaW5nLA0KPiBhcyBtdWNoIGFzIHBvc3Np YmxlLCB0aGUgc2FtZSBzZXQgb2YgcHJvdG9jb2xzIGFuZCBwcm9jZWR1cmVzLg0KLy9MaW5kYTpT dXBwb3NlIGEgcHJvdmlkZXIgZW5hYmxlcyBNQ0FTVC1WUE4gYWJpbGl0eSBpbiBoaXMgYmFja2Jv bmUgDQpuZXR3b3JrIGZvciANCm9ubHkgc3VwcG9ydCBWUE4gTXVsdGljYXN0LCBleGNlcHQgYWxs IE1WUE4gSS1QTVNJIHR1bm5lbHMgYXJlIGJ1aWxkaW5nIA0KZm9yIGV2ZXJ5IFZSRiAsDQpldmVy eSBQRSB3b3VsZCBhZGRpdGlvbmFsbHkgYnVpbHQgYSBkZWZhdWx0IHR1bm5lbCBmb3IgR1RNIGFu ZCBhbGwgdGhlIA0KcHJvY2VkdXJlcyANCnVzaW5nIGZvciBidWlsZGluZyB0aGUgR1RNIHR1bm5l bCBhcmUgcmVkdW5kYW50Lg0KQW5kIG9uIHRoZSBvdGhlciBoYW5kLCBhIHByb3ZpZGVyIGVuYWJs ZXMgTUNBU1QtVlBOIGFiaWxpdHkgaW4gaGlzIA0KYmFja2JvbmUgbmV0d29yayANCmZvciBvbmx5 IHN1cHBvcnQgR1RNLCBleGNlcHQgR1RNIHR1bm5lbHMgYXJlIGJ1aWxkaW5nLCBldmVyeSBQRSB3 b3VsZCANCmFkZGl0aW9uYWxseSANCmJ1aWx0IGRlZmF1bHQgdHVubmVscyBmb3IgZXZlcnkgVlJG IGFuZCBhbGwgdGhlIHByb2NlZHVyZXMgZm9yIGJ1aWxkaW5nIA0KdGhlIE1WUE4gSS1QTVNJIA0K dHVubmVscyBhcmUgcmVkdW5kYW50LlNvIGRyYWZ0LXdhbmcgY2FuIGF2b2lkIHRoZSB1bm5lY2Nl cnkgdHVubmVsIA0KYnVpbGRpbmcuIEFtIEkgcmlnaHQ/IA0KSWYgSSBtaXNzaW5nIGFueXRoaW5n LCBwbGVhc2UgcG9pbnQgb3V0OikgDQogDQo+IA0KPiBGb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMg b2YgZHJhZnQtenpoYW5nLWwzdnBuLW12cG4tZ2xvYmFsLXRhYmxlLW1jYXN0LCANCnRoZQ0KPiBN VlBOIEMtbXVsdGljYXN0IGFuZCBBLUQgcm91dGVzIHVzZSB0aGUgc2FtZSBBRkkvU0FGSSAoTUNB U1QtVlBOKSBhcyB0aGUgDQpHVE0NCj4gQy1tdWx0aWNhc3QgYW5kIEEtRCByb3V0ZXMuICBFeGlz dGluZyBwcm9jZWR1cmVzIGFuZCB0b29scyBjb250aW51ZSB0bw0KPiBhcHBseS4gIElmIGRyYWZ0 LXdhbmcgaXMgdXNlZCwgdGhlbiB0aGUgcHJvdmlkZXIgbmVlZHMgdG8gdXNlIHR3byANCmRpZmZl cmVudA0KPiBBRkkvU0FGSXMsIG9uZSBmb3IgTVZQTiBhbmQgb25lIGZvciBHVE0uICBXaGF0IGlz IHRoZSBwb2ludCBvZiB1c2luZyB0aGUNCj4gYWRkaXRpb25hbCBBRkkvU0FGST8gIEl0J3MganVz dCBhIGNvbXBsaWNhdGlvbiBmb3Igbm8gYmVuZWZpdDsgZXZlcnkNCj4gYWRkaXRpb25hbCBBRkkv U0FGSSBicmluZ3Mgc29tZSBvcGVyYXRpb25hbCBvdmVyaGVhZC4NCi8vTGluZGE6IFllcyxmcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiBjb2RpbmcsIHR3byBkaWZmZXJlbnQgQUZJL1NBRklzIGxlYWQg DQp0byB0d28gDQpraW5kcyBvZiBjb2RlYyxidXQgZXhjZXB0IGNvZGVjLCBHVE0gY2FuIHJldXNl IG1hbnkgaW50ZXJhY3Rpb24gcHJvY2VkdXJlcyANCnRoYXQgDQpNVlBOIGlzIHVzaW5nIDopIA0K DQo+IA0KPiBJZiBhIHByb3ZpZGVyIG9ubHkgd2FudHMgdG8gdXNlIGhpcyBiYWNrYm9uZSBmb3Ig R1RNLCB0aGUgTUNBU1QtVlBOIFNBRkkgDQppcw0KPiBzdGlsbCBmaW5lLiAgSSBkb24ndCBrbm93 IHdoeSB5b3UgdGhpbmsgaXQgY2F1c2VzIHVubmVjZXNzYXJ5IHJvdXRlDQo+IGFkdmVydGlzZW1l bnQuICBZb3UganVzdCBoYXZlIHRvIHNldCB0aGUgUkQgZmllbGQgaW4gdGhlIE5MUkkgdG8gemVy bywgDQpzbw0KPiB0aGF0IHRoZSBOTFJJIGlkZW50aWZpZXMgdGhlIGdsb2JhbCB0YWJsZSByYXRo ZXIgdGhhbiBhIFZSRi4NCi8vTGluZGE6IFNvcnJ5IGZvciBtaXN1bmRlcnN0YW5kaW5nIHRoZXJl IGFyZSB1bm5lY2Vzc2FyeSByb3V0ZSANCmFkdmVydGlzZW1lbnRzLg0KIFllcyx5b3UncmUgcmln aHQuVGhhbmtzIGZvciBwb2ludGluZyBpdCBvdXQ6KQ0KPiBJdCBpc24ndCB3b3J0aCBpbnRyb2R1 Y2luZyBhIG5ldyBTQUZJIGp1c3QgdG8gc2hvcnRlbiB0aGUgTkxSSSBieSBhIGZldw0KPiBvY3Rl dHMuDQo+IA0KPiA+IDEuV2l0aG91dCBSRDoNCj4gDQo+ID4gYS4gQWxsIHRoZSBBLUQgcm91dGUg aXMgbW9yZSBzaW1wbGVyIGluIGVuY29kaW5nLg0KPiANCj4gU2V0dGluZyB0aGUgUkQgdG8gemVy byBpcyBub3QgbXVjaCBvZiBhIGNvbXBsaWNhdGlvbi4gIEl0J3MgYSBsb3QgDQpzaW1wbGVyDQo+ IHRoYW4gaGF2aW5nIGEgbmV3IFNBRkkuDQovL0xpbmRho7pSRCAwOjAgaXMgcmVzZXJ2ZWQgYnkg R1RNLHdoaWNoIG1lYW5zIFZQTiBWUkYgY2FuJ3QgdXNlIFJEIA0KMDowLHJpZ2h0Pw0KPiA+IDIu V2l0aG91dCBSVA0KPiANCj4gTm8sIGl0J3Mgbm90IHBvc3NpYmxlIHRvIGVsaW1pbmF0ZSB0aGUg UlRzLiAgUlRzIGFyZSBhYnNvbHV0ZWx5IHJlcXVpcmVkIA0Kb24NCj4gdGhlIEMtbXVsdGljYXN0 IEpvaW4gcm91dGVzIGFuZCB0aGUgTGVhZiBBLUQgcm91dGVzLiAgVGhlc2Ugcm91dGUgdHlwZXMg DQphcmUNCj4gYWx3YXlzICJ0YXJnZXRlZCIgdG8gYSBzaW5nbGUgdXBzdHJlYW0gbm9kZSwgYW5k IHRoYXQgbm9kZSBpcyBpZGVudGlmaWVkIA0KYnkNCj4gdGhlIFJULiAgTm90IG9ubHkgaXMgdGhh dCBpbXBvcnRhbnQgZm9yIGNvbnN0cmFpbmluZyB0aGUgZGlzdHJpYnV0aW9uIG9mDQo+IHRoZSBy b3V0ZXMsIGl0IGlzIGFsc28gbmVlZGVkIHNvIHRoYXQgdGhlIHVwc3RyZWFtIG5vZGUgY2FuIHRl bGwgdGhhdCBpdCANCmlzDQo+IHRoZSB0YXJnZXQgb2YgYSBwYXJ0aWN1bGFyIEMtbXVsdGljYXN0 IEpvaW4gb3IgTGVhZiBBLUQgcm91dGUuDQovL0xpbmRhOiBJIHRoaW5rIHRoZSB1cHN0cmVhbSBu b2RlIGlzIGlkZW50aWZpZWQgYnkgdGhlIHVuaWNhc3Qgcm91dGUgYW5kIA0KdGhlIHNlbGVjdGVk IHJvdXRlIHBvbGljeSwNCiBvbmNlIHRoZSBDLW11bHRpY2FzdCBKb2luIHJvdXRlcyByZWNlaXZl ZCBieSB0aGUgdXBzdHJlYW0gbm9kZSx0aGVuIFJUIA0KZGVjaWRlcyB3aGljaCBWUkYgaW1wb3J0 IHRoZQ0KIEMtbXVsdGljYXN0IHJvdXRlcy5JbiB0aGUgY29udGV4dCBvZiBHVE0sIHRoZXJlIGlz IG5vIGNvbnNpZGVyYXRpb24gd2hpY2ggDQpWUkYgaW1wb3J0IHRoZSBjLW11bGl0Y2FzdCANCiBy b3V0ZXMgYnV0IHRoZSBnbG9iYWwgbXV0aWNhc3Qgcm91dGUgdGFibGUuU28gaSBkb3V0ZSB3aGVy ZSBuZWVkIFJUIGluIA0KR1RNID8gIA0KPiANCj4gSSBhbHNvIHRoaW5rIGl0IHdvdWxkIGJlIHVu d2lzZSB0byBkaXN0cmlidXRlIHRoZSBvdGhlciByb3V0ZSB0eXBlcyANCndpdGhvdXQNCj4gUlRz LCBhcyB0aGF0IHdvdWxkIGVsaW1pbmF0ZSB0aGUgYWJpbGl0eSB0byBjb25zdHJhaW4gdGhlIGRp c3RyaWJ1dGlvbiANCm9mDQo+IHRob3NlIHJvdXRlcy4gIEl0IHdvdWxkIGFsc28gZWxpbWluYXRl IHRoZSBhYmlsaXR5IHRvIGNyZWF0ZSBleHRyYW5ldHMgDQp0aGF0DQo+IGNvbnRhaW4gYm90aCBW UkZzIGFuZCBnbG9iYWwgdGFibGVzLg0KPiANCj4gPiBXZSBjYW4gcmVtb3ZlIFZSRiBSb3V0ZSBJ bXBvcnQgRXh0ZW5kZWQgQ29tbXVuaXR5DQo+IA0KPiBObyB5b3UgY2FuJ3QsIGFzIHRoYXQgaXMg bmVlZGVkLCBpbiBnZW5lcmFsLCB0byBpZGVudGlmeSB0aGUgIlVwc3RyZWFtIA0KUEUiDQo+IGZv ciBhIGdpdmVuIG11bHRpY2FzdCBzb3VyY2Ugb3IgUlAuICBUaGUgTVZQTiBwcm9jZWR1cmVzIGRl cGVuZCBvbiBiZWluZw0KPiBhYmxlIHRvIGlkZW50aWZ5IHRoZSBVcHN0cmVhbSBQRSAoIlVwc3Ry ZWFtIFBCUiIgaW4gdGhlIA0KZHJhZnQtenpoYW5nLS4uLi0wMQ0KPiB0ZXJtaW5vbG9neSkuICBX aXRob3V0IHRoZSBWUkYgUm91dGUgSW1wb3J0IEV4dGVuZGVkIENvbW11bml0eSwgdGhlIA0KTVZQ Ti9HVE0NCj4gcHJvY2VkdXJlcyB3aWxsIG9ubHkgd29yayB3aXRoaW4gYSBzaW5nbGUgQVMuDQo+ IA0KPiA+Lkdsb2JhbCBtdWx0aWNhc3QgcmVhY2hhYmlsaXR5IGlzIG5vdCBnb2luZyB0byBhZ2dy ZWdhdGUsc28gd2UgY2FuIA0KcmVtb3ZlDQo+ID4gdGhlIE1QTFMgTGFiZWwgZmllbGQgaW4gUE1T SSBUdW5uZWwgQXR0cmlidXRlDQo+IA0KPiBUaGUgTVBMUyBMYWJlbCBmaWVsZCBpbiB0aGUgUE1T SSBUdW5uZWwgQXR0cmlidXRlIG9mIGEgTGVhZiBBLUQgcm91dGUgaXMNCj4gbmVlZGVkIHRvIHN1 cHBvcnQgSW5ncmVzcyBSZXBsaWNhdGlvbiwgc28gaXQgY2Fubm90IGJlIGVsaW1pbmF0ZWQuDQo+ IA0KPiBBbHNvLCBvbmUgbWF5IHdpc2ggdG8gYWdncmVnYXRlIEdUTSBhbmQgTVZQTiB0cmFmZmlj IGluIHRoZSBzYW1lIHR1bm5lbCwgDQppbg0KPiB3aGljaCBjYXNlIG9uZSB3b3VsZCB3YW50IHRv IHVzZSB0aGUgTVBMUyBsYWJlbCBmaWVsZCBvZiB0aGUgUE1TSSBUdW5uZWwNCj4gQXR0cmlidXRl IGluIGFuIEkvUy1QTVNJIEEtRCByb3V0ZSB0byBkaXN0aW5ndWlzaCB0aGUgTVZQTiB0cmFmZmlj IGZyb20gDQp0aGUNCj4gR1RNIHRyYWZmaWMuDQo+IA0KPiBGb3IgY2FzZXMgd2hlcmUgdGhlIGxh YmVsIGlzIG5vdCBuZWVkZWQsIFJGQzY1MTQgYWxyZWFkeSBzcGVjaWZpZXMgYSB3YXkgDQp0bw0K PiBlbmNvZGUgIm5vIGxhYmVsIiwgaS5lLiwgc2V0IHRoZSBsYWJlbCBmaWVsZCB0byB6ZXJvLiAg VGhlcmUgaXMgbm8gbmVlZCANCnRvDQo+IGFkZCBhbm90aGVyIHlldCBhbm90aGVyIGF0dHJpYnV0 ZSBqdXN0IHNvIHRoYXQgb25lIGNhbiBvbWl0IHRoZSBsYWJlbCANCmZpZWxkDQo+IGluc3RlYWQg b2Ygc2V0dGluZyBpdCB0byB6ZXJvLg0KPiANCj4gRnJvbSBkcmFmdC13YW5nOg0KPiANCj4gICAg dGhlIDZNUEUgcm91dGVycyBjb252ZXkgdGhlIElQdjQgYWRkcmVzcyBvZg0KPiAgICA2TVBFIFJv dXRlci1JRCBhcyB0aGUgQkdQIE5leHQgSG9wIGZvciB0aGUgYWR2ZXJ0aXNlZCBBLUQgcm91dGVz Lg0KPiAgICBBbmQgdGhlIElQdjQgYWRkcmVzcyBNVVNUIGJlIGVuY29kZWQgYXMgYW4gSVB2NC1t YXBwZWQgSVB2NiBhZGRyZXNzDQo+ICAgIGluIHRoZSBCR1AgTmV4dCBIb3AgZmllbGQuICBUaGlz IGVuY29kaW5nIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUNCj4gICAgZGVmaW5pdGlvbiBvZiBhbiBJ UHY0LW1hcHBlZCBJUHY2IGFkZHJlc3MgaW4gW1JGQzQyOTFdLg0KPiANCj4gSSB3YXMgc3VycHJp c2VkIHRvIHNlZSB0aGlzOyBpZiBvbmUgb2JqZWN0cyB0byBjYXJyeWluZyBlaWdodCBvY3RldHMg b2YgDQpSRD0wDQo+IGFuZC9vciB0aHJlZSBvY3RldHMgb2YgbGFiZWw9MCwgc3VyZWx5IG9uZSB3 aWxsIG9iamVjdCB0byBlbmNvZGluZyBhDQo+IGZvdXItb2N0ZXQgSVB2NCBhZGRyZXNzIGluIGEg MTYtb2N0ZXQgZmllbGQgOy0pDQovL0xpbmRhOiBUaGFua3MgZm9yIHlvdXIgaHVtb3JvdXM6KSBU aGlzIHNlY3Rpb24gaXMgb25seSB1c2VkIGZvciA2LTQtNiANCnNjZW5hcmlvLg0KICBJIHNob3Vs ZCBjbGVhcmx5IGRlc2NyaWJlIHRoaXMgc2VjdGlvbiBpbiBuZXh0IHZlcnNpb246KQ0KPiANCj4g Tm90ZSB0aGF0IHRoaXMgbWV0aG9kIG9mIGVuY29kaW5nIHRoZSBuZXh0IGhvcCBpcyBub3QgY29u c2lzdGVudCB3aXRoIA0KdGhlIE1WUE4NCj4gc3RhbmRhcmRzOyBwbGVhc2Ugc2VlIFJGQyA2NTE1 IGZvciBkZXRhaWxzLiANCj4gDQo+IA0KPiANCj4gDQo+IA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFu ZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQg Y29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55 IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWlu YXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 000FBE2D48257C16_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6xFcmljo6w8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2Zv bnQ+PGZvbnQgc2l6ZT0yPlRvZGF5IGlzDQphIHNwZWNpYWwgZGF5LCBzbywgZmlyc3QsIEhhcHB5 IEhhbGxvd2VlbiA6KSA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyBUaGVu IHRoYW5rcyBmb3IgeW91ciByZXBseS4gSSBzdGlsbCBoYXZlIHNvbWUgcXVlc3Rpb25zDQpzZWVp bmcgaW5saW5lIGJlbG93LiBXb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gZm9yIG1lPyA8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyBUaGFua3M6KTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTI+QlJzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+TGluZGEgV2FuZzwv Zm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkVyaWMgUm9zZW4gJmx0O2Vyb3NlbkBj aXNjby5jb20mZ3Q7INC009ogMjAxMy0xMC0yNA0KMjE6NTQ6MTI6PGJyPg0KPGJyPg0KJmd0OyAm Z3Q7IElmIHByb3ZpZGVycyBqdXN0IHdhbnQgdG8gZW5hYmxlIEdsb2JhbCBNdWx0aWNhc3QgUmVh Y2hhYmxpdHkNCm9ubHksIHRoZXk8YnI+DQomZ3Q7ICZndDsganVzdCBuZWVkIGVuYWJsZSBNQ0FT VC1JUHY2KGRlZmluZSBpbjxicj4NCiZndDsgJmd0OyBkcmFmdC13YW5nLW1ib25lZC1nbG8taXB2 Ni1tY2FzdC1yZWFjaGFiaWxpdHkpIGFkZHJlc3MgZmFtaWx5DQpvbmx5IHdpdGhvdXQ8YnI+DQom Z3Q7ICZndDsgZW5hYmxlIE1DQVNULVZQTiBhZGRyZXNzIGZhbWlseSB3aGljaCBtYXkgY2F1c2Ug dW5uZWNlc3Nhcnkgcm91dGU8YnI+DQomZ3Q7ICZndDsgYWR2ZXJ0aXNlbWVudHMuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEkgcmVhbGx5IGRvbid0IHVuZGVyc3RhbmQgdGhpcyBsaW5lIG9mIHJlYXNv bmluZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgU3VwcG9zZSBhIHByb3ZpZGVyIHdhbnRzIHRvIHVz ZSBoaXMgYmFja2JvbmUgbmV0d29yayB0byBzdXBwb3J0IGJvdGgNClZQTjxicj4NCiZndDsgTXVs dGljYXN0IChNVlBOKSBhbmQgYW5kIEdsb2JhbCBUYWJsZSBNdWx0aWNhc3QgKEdUTSksIGFuZCB3 YW50cyB0bw0KdXNlPGJyPg0KJmd0OyBwcm90b2NvbHMgYW5kIHByb2NlZHVyZXMgYmFzZWQgb24g UkZDNjUxNCBmb3IgYm90aC4gJm5ic3A7UGVyaGFwcywNCmUuZy4sIHRoZTxicj4NCiZndDsgcHJv dmlkZXIgaXMgYWxyZWFkeSBzdXBwb3J0aW5nIE1WUE4gYW5kIG5vdyB3YW50cyB0byBhZGQgR1RN IHN1cHBvcnQsDQp1c2luZyw8YnI+DQomZ3Q7IGFzIG11Y2ggYXMgcG9zc2libGUsIHRoZSBzYW1l IHNldCBvZiBwcm90b2NvbHMgYW5kIHByb2NlZHVyZXMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9MiBjb2xvcj1ibHVlPi8vTGluZGE6U3VwcG9zZSBhIHByb3ZpZGVyIGVuYWJsZXMg TUNBU1QtVlBODQphYmlsaXR5IGluIGhpcyBiYWNrYm9uZSBuZXR3b3JrIGZvciA8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+b25seSBzdXBwb3J0IFZQTiBNdWx0 aWNhc3QsIGV4Y2VwdCBhbGwNCk1WUE4gSS1QTVNJIHR1bm5lbHMgYXJlIGJ1aWxkaW5nIGZvciBl dmVyeSBWUkYgLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5l dmVyeSBQRSB3b3VsZCBhZGRpdGlvbmFsbHkgYnVpbHQgYSBkZWZhdWx0DQp0dW5uZWwgZm9yIEdU TSBhbmQgYWxsIHRoZSBwcm9jZWR1cmVzIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZT51c2luZyBmb3IgYnVpbGRpbmcgdGhlIEdUTSB0dW5uZWwgYXJlIHJlZHVu ZGFudC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+QW5kIG9u IHRoZSBvdGhlciBoYW5kLCBhIHByb3ZpZGVyIGVuYWJsZXMNCk1DQVNULVZQTiBhYmlsaXR5IGlu IGhpcyBiYWNrYm9uZSBuZXR3b3JrIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZT5mb3Igb25seSBzdXBwb3J0IEdUTSwgZXhjZXB0IEdUTSB0dW5uZWxzDQphcmUg YnVpbGRpbmcsIGV2ZXJ5IFBFIHdvdWxkIGFkZGl0aW9uYWxseSA8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+YnVpbHQgZGVmYXVsdCB0dW5uZWxzIGZvciBldmVy eSBWUkYgYW5kDQphbGwgdGhlIHByb2NlZHVyZXMgZm9yIGJ1aWxkaW5nIHRoZSBNVlBOIEktUE1T SSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+dHVubmVscyBh cmUgcmVkdW5kYW50LlNvIGRyYWZ0LXdhbmcgY2FuDQphdm9pZCB0aGUgdW5uZWNjZXJ5IHR1bm5l bCBidWlsZGluZy4gQW0gSSByaWdodD8gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 MiBjb2xvcj1ibHVlPklmIEkgbWlzc2luZyBhbnl0aGluZywgcGxlYXNlIHBvaW50IG91dDopDQo8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOzxicj4NCiZndDsgPGJyPg0K Jmd0OyBGb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgb2YgZHJhZnQtenpoYW5nLWwzdnBuLW12cG4t Z2xvYmFsLXRhYmxlLW1jYXN0LA0KdGhlPGJyPg0KJmd0OyBNVlBOIEMtbXVsdGljYXN0IGFuZCBB LUQgcm91dGVzIHVzZSB0aGUgc2FtZSBBRkkvU0FGSSAoTUNBU1QtVlBOKQ0KYXMgdGhlIEdUTTxi cj4NCiZndDsgQy1tdWx0aWNhc3QgYW5kIEEtRCByb3V0ZXMuICZuYnNwO0V4aXN0aW5nIHByb2Nl ZHVyZXMgYW5kIHRvb2xzIGNvbnRpbnVlDQp0bzxicj4NCiZndDsgYXBwbHkuICZuYnNwO0lmIGRy YWZ0LXdhbmcgaXMgdXNlZCwgdGhlbiB0aGUgcHJvdmlkZXIgbmVlZHMgdG8gdXNlDQp0d28gZGlm ZmVyZW50PGJyPg0KJmd0OyBBRkkvU0FGSXMsIG9uZSBmb3IgTVZQTiBhbmQgb25lIGZvciBHVE0u ICZuYnNwO1doYXQgaXMgdGhlIHBvaW50IG9mDQp1c2luZyB0aGU8YnI+DQomZ3Q7IGFkZGl0aW9u YWwgQUZJL1NBRkk/ICZuYnNwO0l0J3MganVzdCBhIGNvbXBsaWNhdGlvbiBmb3Igbm8gYmVuZWZp dDsNCmV2ZXJ5PGJyPg0KJmd0OyBhZGRpdGlvbmFsIEFGSS9TQUZJIGJyaW5ncyBzb21lIG9wZXJh dGlvbmFsIG92ZXJoZWFkLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZT4vL0xpbmRhOiBZZXMsZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgY29kaW5nLA0KdHdvIGRp ZmZlcmVudCBBRkkvU0FGSXMgbGVhZCB0byB0d28gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9MiBjb2xvcj1ibHVlPmtpbmRzIG9mIGNvZGVjLGJ1dCBleGNlcHQgY29kZWMsIEdUTSBj YW4NCnJldXNlIG1hbnkgaW50ZXJhY3Rpb24gcHJvY2VkdXJlcyB0aGF0IDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5NVlBOIGlzIHVzaW5nIDopPC9mb250Pjwv dHQ+PHR0Pjxmb250IHNpemU9Mj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIGEgcHJvdmlkZXIgb25seSB3YW50cyB0byB1c2UgaGlz IGJhY2tib25lIGZvciBHVE0sIHRoZSBNQ0FTVC1WUE4NClNBRkkgaXM8YnI+DQomZ3Q7IHN0aWxs IGZpbmUuICZuYnNwO0kgZG9uJ3Qga25vdyB3aHkgeW91IHRoaW5rIGl0IGNhdXNlcyB1bm5lY2Vz c2FyeQ0Kcm91dGU8YnI+DQomZ3Q7IGFkdmVydGlzZW1lbnQuICZuYnNwO1lvdSBqdXN0IGhhdmUg dG8gc2V0IHRoZSBSRCBmaWVsZCBpbiB0aGUgTkxSSQ0KdG8gemVybywgc288YnI+DQomZ3Q7IHRo YXQgdGhlIE5MUkkgaWRlbnRpZmllcyB0aGUgZ2xvYmFsIHRhYmxlIHJhdGhlciB0aGFuIGEgVlJG Ljxicj4NCjwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT4vL0xpbmRhOiBT b3JyeSBmb3IgbWlzdW5kZXJzdGFuZGluZw0KdGhlcmUgYXJlIHVubmVjZXNzYXJ5IHJvdXRlIGFk dmVydGlzZW1lbnRzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZT4mbmJzcDtZZXMseW91J3JlIHJpZ2h0LlRoYW5rcyBmb3IgcG9pbnRpbmcNCml0IG91dDopPC9m b250PjwvdHQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IEl0IGlzbid0IHdvcnRoIGludHJv ZHVjaW5nIGEgbmV3IFNBRkkganVzdCB0byBzaG9ydGVuIHRoZSBOTFJJIGJ5DQphIGZldzxicj4N CiZndDsgb2N0ZXRzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDEuV2l0aG91dCBSRDo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBhLiBBbGwgdGhlIEEtRCByb3V0ZSBpcyBtb3JlIHNpbXBs ZXIgaW4gZW5jb2RpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNldHRpbmcgdGhlIFJEIHRvIHpl cm8gaXMgbm90IG11Y2ggb2YgYSBjb21wbGljYXRpb24uICZuYnNwO0l0J3MgYQ0KbG90IHNpbXBs ZXI8YnI+DQomZ3Q7IHRoYW4gaGF2aW5nIGEgbmV3IFNBRkkuPGJyPg0KPC9mb250PjwvdHQ+PHR0 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPi8vTGluZGGjulJEIDA6MCBpcyByZXNlcnZlZCBieQ0K R1RNLHdoaWNoIG1lYW5zIFZQTiBWUkYgY2FuJ3QgdXNlIFJEIDA6MCxyaWdodD88L2ZvbnQ+PC90 dD48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyAyLldpdGhvdXQgUlQ8YnI+DQomZ3Q7 IDxicj4NCiZndDsgTm8sIGl0J3Mgbm90IHBvc3NpYmxlIHRvIGVsaW1pbmF0ZSB0aGUgUlRzLiAm bmJzcDtSVHMgYXJlIGFic29sdXRlbHkNCnJlcXVpcmVkIG9uPGJyPg0KJmd0OyB0aGUgQy1tdWx0 aWNhc3QgSm9pbiByb3V0ZXMgYW5kIHRoZSBMZWFmIEEtRCByb3V0ZXMuICZuYnNwO1RoZXNlIHJv dXRlDQp0eXBlcyBhcmU8YnI+DQomZ3Q7IGFsd2F5cyAmcXVvdDt0YXJnZXRlZCZxdW90OyB0byBh IHNpbmdsZSB1cHN0cmVhbSBub2RlLCBhbmQgdGhhdCBub2RlDQppcyBpZGVudGlmaWVkIGJ5PGJy Pg0KJmd0OyB0aGUgUlQuICZuYnNwO05vdCBvbmx5IGlzIHRoYXQgaW1wb3J0YW50IGZvciBjb25z dHJhaW5pbmcgdGhlIGRpc3RyaWJ1dGlvbg0Kb2Y8YnI+DQomZ3Q7IHRoZSByb3V0ZXMsIGl0IGlz IGFsc28gbmVlZGVkIHNvIHRoYXQgdGhlIHVwc3RyZWFtIG5vZGUgY2FuIHRlbGwgdGhhdA0KaXQg aXM8YnI+DQomZ3Q7IHRoZSB0YXJnZXQgb2YgYSBwYXJ0aWN1bGFyIEMtbXVsdGljYXN0IEpvaW4g b3IgTGVhZiBBLUQgcm91dGUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xv cj1ibHVlPi8vTGluZGE6IEkgdGhpbmsgdGhlIHVwc3RyZWFtIG5vZGUgaXMgaWRlbnRpZmllZA0K YnkgdGhlIHVuaWNhc3Qgcm91dGUgYW5kIHRoZSBzZWxlY3RlZCByb3V0ZSBwb2xpY3ksPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPiZuYnNwO29uY2UgdGhlIEMt bXVsdGljYXN0IEpvaW4gcm91dGVzDQpyZWNlaXZlZCBieSB0aGUgdXBzdHJlYW0gbm9kZSx0aGVu IFJUIGRlY2lkZXMgd2hpY2ggVlJGIGltcG9ydCB0aGU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWU+Jm5ic3A7Qy1tdWx0aWNhc3Qgcm91dGVzLkluIHRoZSBjb250 ZXh0DQpvZiBHVE0sIHRoZXJlIGlzIG5vIGNvbnNpZGVyYXRpb24gd2hpY2ggVlJGIGltcG9ydCB0 aGUgYy1tdWxpdGNhc3QgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1i bHVlPiZuYnNwO3JvdXRlcyBidXQgdGhlIGdsb2JhbCBtdXRpY2FzdCByb3V0ZQ0KdGFibGUuU28g aSBkb3V0ZSB3aGVyZSBuZWVkIFJUIGluIEdUTSA/ICZuYnNwOzwvZm9udD48L3R0Pjx0dD48Zm9u dCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYWxzbyB0aGluayBpdCB3b3VsZCBiZSB1 bndpc2UgdG8gZGlzdHJpYnV0ZSB0aGUgb3RoZXIgcm91dGUgdHlwZXMNCndpdGhvdXQ8YnI+DQom Z3Q7IFJUcywgYXMgdGhhdCB3b3VsZCBlbGltaW5hdGUgdGhlIGFiaWxpdHkgdG8gY29uc3RyYWlu IHRoZSBkaXN0cmlidXRpb24NCm9mPGJyPg0KJmd0OyB0aG9zZSByb3V0ZXMuICZuYnNwO0l0IHdv dWxkIGFsc28gZWxpbWluYXRlIHRoZSBhYmlsaXR5IHRvIGNyZWF0ZQ0KZXh0cmFuZXRzIHRoYXQ8 YnI+DQomZ3Q7IGNvbnRhaW4gYm90aCBWUkZzIGFuZCBnbG9iYWwgdGFibGVzLjxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7IFdlIGNhbiByZW1vdmUgVlJGIFJvdXRlIEltcG9ydCBFeHRlbmRlZCBD b21tdW5pdHk8YnI+DQomZ3Q7IDxicj4NCiZndDsgTm8geW91IGNhbid0LCBhcyB0aGF0IGlzIG5l ZWRlZCwgaW4gZ2VuZXJhbCwgdG8gaWRlbnRpZnkgdGhlICZxdW90O1Vwc3RyZWFtDQpQRSZxdW90 Ozxicj4NCiZndDsgZm9yIGEgZ2l2ZW4gbXVsdGljYXN0IHNvdXJjZSBvciBSUC4gJm5ic3A7VGhl IE1WUE4gcHJvY2VkdXJlcyBkZXBlbmQNCm9uIGJlaW5nPGJyPg0KJmd0OyBhYmxlIHRvIGlkZW50 aWZ5IHRoZSBVcHN0cmVhbSBQRSAoJnF1b3Q7VXBzdHJlYW0gUEJSJnF1b3Q7IGluIHRoZQ0KZHJh ZnQtenpoYW5nLS4uLi0wMTxicj4NCiZndDsgdGVybWlub2xvZ3kpLiAmbmJzcDtXaXRob3V0IHRo ZSBWUkYgUm91dGUgSW1wb3J0IEV4dGVuZGVkIENvbW11bml0eSwNCnRoZSBNVlBOL0dUTTxicj4N CiZndDsgcHJvY2VkdXJlcyB3aWxsIG9ubHkgd29yayB3aXRoaW4gYSBzaW5nbGUgQVMuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsuR2xvYmFsIG11bHRpY2FzdCByZWFjaGFiaWxpdHkgaXMgbm90 IGdvaW5nIHRvIGFnZ3JlZ2F0ZSxzbyB3ZQ0KY2FuIHJlbW92ZTxicj4NCiZndDsgJmd0OyB0aGUg TVBMUyBMYWJlbCBmaWVsZCBpbiBQTVNJIFR1bm5lbCBBdHRyaWJ1dGU8YnI+DQomZ3Q7IDxicj4N CiZndDsgVGhlIE1QTFMgTGFiZWwgZmllbGQgaW4gdGhlIFBNU0kgVHVubmVsIEF0dHJpYnV0ZSBv ZiBhIExlYWYgQS1EIHJvdXRlDQppczxicj4NCiZndDsgbmVlZGVkIHRvIHN1cHBvcnQgSW5ncmVz cyBSZXBsaWNhdGlvbiwgc28gaXQgY2Fubm90IGJlIGVsaW1pbmF0ZWQuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEFsc28sIG9uZSBtYXkgd2lzaCB0byBhZ2dyZWdhdGUgR1RNIGFuZCBNVlBOIHRyYWZm aWMgaW4gdGhlIHNhbWUgdHVubmVsLA0KaW48YnI+DQomZ3Q7IHdoaWNoIGNhc2Ugb25lIHdvdWxk IHdhbnQgdG8gdXNlIHRoZSBNUExTIGxhYmVsIGZpZWxkIG9mIHRoZSBQTVNJDQpUdW5uZWw8YnI+ DQomZ3Q7IEF0dHJpYnV0ZSBpbiBhbiBJL1MtUE1TSSBBLUQgcm91dGUgdG8gZGlzdGluZ3Vpc2gg dGhlIE1WUE4gdHJhZmZpYw0KZnJvbSB0aGU8YnI+DQomZ3Q7IEdUTSB0cmFmZmljLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBGb3IgY2FzZXMgd2hlcmUgdGhlIGxhYmVsIGlzIG5vdCBuZWVkZWQsIFJG QzY1MTQgYWxyZWFkeSBzcGVjaWZpZXMNCmEgd2F5IHRvPGJyPg0KJmd0OyBlbmNvZGUgJnF1b3Q7 bm8gbGFiZWwmcXVvdDssIGkuZS4sIHNldCB0aGUgbGFiZWwgZmllbGQgdG8gemVyby4gJm5ic3A7 VGhlcmUNCmlzIG5vIG5lZWQgdG88YnI+DQomZ3Q7IGFkZCBhbm90aGVyIHlldCBhbm90aGVyIGF0 dHJpYnV0ZSBqdXN0IHNvIHRoYXQgb25lIGNhbiBvbWl0IHRoZSBsYWJlbA0KZmllbGQ8YnI+DQom Z3Q7IGluc3RlYWQgb2Ygc2V0dGluZyBpdCB0byB6ZXJvLjxicj4NCiZndDsgPGJyPg0KJmd0OyBG cm9tIGRyYWZ0LXdhbmc6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0aGUgNk1Q RSByb3V0ZXJzIGNvbnZleSB0aGUgSVB2NCBhZGRyZXNzIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7Nk1QRSBSb3V0ZXItSUQgYXMgdGhlIEJHUCBOZXh0IEhvcCBmb3IgdGhlIGFkdmVydGlzZWQN CkEtRCByb3V0ZXMuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7QW5kIHRoZSBJUHY0IGFkZHJlc3Mg TVVTVCBiZSBlbmNvZGVkIGFzIGFuIElQdjQtbWFwcGVkDQpJUHY2IGFkZHJlc3M8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDtpbiB0aGUgQkdQIE5leHQgSG9wIGZpZWxkLiAmbmJzcDtUaGlzIGVuY29k aW5nIGlzIGNvbnNpc3RlbnQNCndpdGggdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ZGVmaW5p dGlvbiBvZiBhbiBJUHY0LW1hcHBlZCBJUHY2IGFkZHJlc3MgaW4gW1JGQzQyOTFdLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBJIHdhcyBzdXJwcmlzZWQgdG8gc2VlIHRoaXM7IGlmIG9uZSBvYmplY3Rz IHRvIGNhcnJ5aW5nIGVpZ2h0IG9jdGV0cw0Kb2YgUkQ9MDxicj4NCiZndDsgYW5kL29yIHRocmVl IG9jdGV0cyBvZiBsYWJlbD0wLCBzdXJlbHkgb25lIHdpbGwgb2JqZWN0IHRvIGVuY29kaW5nDQph PGJyPg0KJmd0OyBmb3VyLW9jdGV0IElQdjQgYWRkcmVzcyBpbiBhIDE2LW9jdGV0IGZpZWxkIDst KTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT4vL0xpbmRhOiBU aGFua3MgZm9yIHlvdXIgaHVtb3JvdXM8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yPjopDQo8 L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+VGhpcyBzZWN0aW9uIGlzIG9u bHkgdXNlZCBmb3IgNi00LTYNCnNjZW5hcmlvLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZT4mbmJzcDsgSSBzaG91bGQgY2xlYXJseSBkZXNjcmliZSB0aGlzIHNl Y3Rpb24NCmluIG5leHQgdmVyc2lvbjopPC9mb250PjwvdHQ+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQomZ3Q7IDxicj4NCiZndDsgTm90ZSB0aGF0IHRoaXMgbWV0aG9kIG9mIGVuY29kaW5nIHRoZSBu ZXh0IGhvcCBpcyBub3QgY29uc2lzdGVudCB3aXRoDQp0aGUgTVZQTjxicj4NCiZndDsgc3RhbmRh cmRzOyBwbGVhc2Ugc2VlIFJGQyA2NTE1IGZvciBkZXRhaWxzLiAmbmJzcDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPC9mb250Pjwv dHQ+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5k IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUg YWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h dGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2Ug ZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+ DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFu eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz Y2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 000FBE2D48257C16_=--