From nobody Mon Oct 3 05:12:01 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DB912B1C5; Mon, 3 Oct 2016 05:11:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147549671906.29656.2561289135714944430.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 05:11:59 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-proxy-arp-nd-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 12:11:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Operational Aspects of Proxy-ARP/ND in EVPN Networks Authors : Jorge Rabadan Senthil Sathappan Kiran Nagaraj Wim Henderickx Greg Hankins Thomas King Daniel Melzer Erik Nordmark Filename : draft-ietf-bess-evpn-proxy-arp-nd-01.txt Pages : 22 Date : 2016-10-03 Abstract: The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast- forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs, as explained in [RFC6820]. This document describes how the [RFC7432] EVPN proxy- ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy-arp-nd-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-proxy-arp-nd-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 nobody Mon Oct 3 09:41:54 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7966412940C; Mon, 3 Oct 2016 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaqQfEAtVW_R; Mon, 3 Oct 2016 09:41:45 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD5712940A; Mon, 3 Oct 2016 09:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34021; q=dns/txt; s=iport; t=1475512904; x=1476722504; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=FAxBk8MmzxTnlUKTzKDqGfBMpEYU3DY7dmY3PbZIUrY=; b=NxC8fsDHlgmq4M1b6Od0EZG6zzAITEdVlJCsvl5U9VzhfZMTCFywm5OJ o/ehZRziIG3+1ve2vSFAS55RjfdJKE5Uc8+V1M4xuvEWk1fZfLTyYM9VD tlDXPj9q3N/xZ8LStpCW7OV4iS4IsWkGC0+6yWf5Vq8jZS78ozBf6RtZx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQDMiPJX/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9AQEBAQF1KlKNMpZ/jB+IBIIDAxkNhXgCgh0UAQIBAQEBAQE?= =?us-ascii?q?BXieEYQEBAQMBAQEBFwEIFTYLDAQLEQQBAQECAiMDAgInHwkIBgEMBgIBAQULi?= =?us-ascii?q?DEIDq1/jGMBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQeFMYF9gliEHQMBBgEBGyy?= =?us-ascii?q?CWII9HQEEiDeRQYYniUqBbk6EGIMUI4VnhwuCE4NQg34eNoMgBReBUjw0AYUlA?= =?us-ascii?q?QENFweCAgEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,438,1473120000"; d="scan'208";a="646112028" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2016 16:41:40 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u93GfegT023864; Mon, 3 Oct 2016 16:41:40 GMT To: Glenn Mansfield Keeni , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <93a5d459-3271-b7ad-fadc-156576c60b65@cysols.com> From: Benoit Claise Message-ID: <37e5086d-ce25-6b14-56d9-b53d46f863e2@cisco.com> Date: Mon, 3 Oct 2016 18:41:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <93a5d459-3271-b7ad-fadc-156576c60b65@cysols.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , draft-ietf-bess-l2l3-vpn-mcast-mib.all@ietf.org, "ops-ads@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 16:41:49 -0000 Authors, Can you please finalize this draft. Glenn provided the first MIB doctor review in April! Regards, Benoit > Hi, > Any update on the MIB drafts? > Glenn > > On 2016/07/17 23:44, Glenn Mansfield Keeni wrote: >> Jeffrey and team, >> Any progress on the MIB matters >> (draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt, >> draft-ietf-bess-mvpn-mib-03.txt )? >> >> Glenn >> On 2016/06/07 18:39, Glenn Mansfield Keeni wrote: >>> Hi Jeffrey, >>> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >>> document. It took me some time to do this review. But now here it >>> is. A (near complete) review of >>> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is attached. Hope this helps. >>> I understand that the Security Considerations section is TBD. >>> >>> Glenn >>> >>> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>>> Hi Glenn, >>>> >>>>> -----Original Message----- >>>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>>>> Sent: Sunday, May 08, 2016 11:02 AM >>>>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>>>> ; EXT - thomas.morin@orange.com >>>>> >>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>> Vigoureux >>>>> ; bess@ietf.org; mib-doctors@ietf.org >>>>> Subject: Re: [bess] MIBDoc review of >>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>>> 02.txt >>>>> >>>>> Jeffrey, >>>>> > Thanks for your comments. I've addressed most of your comments >>>>> > in the new revision: >>>>> Thanks for your cooperation. I will need at least one more revision >>>>> with the following comments/recommendations addressed before I will >>>>> be able to complete the detailed review. In the following the numbers >>>>> refer to the issue numbers in the initial review. The issues that are >>>>> addressed and closed are not listed. For brevity, the issue >>>>> descriptions have been trimmed. In case of doubts please look at the >>>>> response mail appended below. >>>>> Hope this helps. >>>> >>>> Thanks for your detailed comments/suggestions. I posted a new revision >>>> with the following issues addressed. >>>> >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>> >>>> >>>> >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>> Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>> >>>> >>>> Please see some notes below. >>>> >>>>> >>>>> Glenn >>>>> >>>>> ------------------------------------------------------------------- >>>>> >>>>> Comments: >>>>> >>>>> 1.1 >>>>> > I had thought this would be standard/obvious for all MIB >>>>> objects - >>>>> We will comeback to this time and again, whereever possible make >>>>> matters explicit and clear. That will help. >>>>> > Is it enough to say something similar? For example: >>>>> > In particular, it describes common managed objects used >>>>> > to configure and/or monitor both L2 and L3 VPN Multicast. >>>>> That is better. >>>> >>>> I take it that this is already closed in -03 revision. >>>> >>>>> >>>>> 2.2 >>>>> > Having said that, I'll explain PMSI a bit further. >>>>> PMSI explanation is good. >>>>> Please use the same style/format for I-PMSI and S-PMSI. >>>> >>>> I think -03 revision already use the same style/format for I-PMSI and >>>> S-PMSI? >>>> >>>>> >>>>> 2.3 >>>>> > No difference. I was using "Layer 3" or "L3" but it was >>>>> pointed out >>>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs >>>>> and I >>>>> > was advised to change it accordingly. Looks like I did not change >>>>> all >>>>> > the cases. >>>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 >>>>> VPN" so >>>>> > I'll change it back. >>>>> No problems. just make sure that the same expression/notation is used >>>>> uniformly. >>>> >>>> I take it that this is also addressed in -03 already. >>>> >>>>> 3. >>>>> > > > 3. Summary of MIB Module. >>>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>> > > > structure of the MIB, short descriptions of the table(s) >>>>> > > > including usage of the table(s) for management and/or by >>>>> > > > other MIB(s). >>>>> > >>>>> > I had that, but have added one sentence about the only table. >>>>> A sentence or two about the textual convention will be good. >>>> >>>> Added in -04. >>>> >>>>> > > > 4. MIB syntax checking: >>>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>> > >>>>> > I used simpleweb's validation tool but looks like I did not >>>>> use the >>>>> > strictest level of validation. I've now fixed the following issues >>>>> and >>>>> > verified. >>>>> Good. >>>>> 5. >>>>> > > > >>>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>> > > > Wherever possible, provide references for objects used in >>>>> > > > the MIB. The references will point to specific sections/ >>>>> > > > sub-sections of the RFCs defining the protocol for >>>>> which the >>>>> > > > MIB is being designed. It will greatly improve the >>>>> readability >>>>> > > > of the document. >>>>> > >>>>> > Added. >>>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>>> improve on it. >>>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>>> clause move it to a separate REFERENCE clause. The addition of the >>>>> section number is an improvement. It is friendlier to the reader. >>>>> Note. Same comment for other OBJECTs too. >>>> >>>> Oh I missed that. All fixed. >>>> >>>>> 7.1 >>>>> > > > 7.1 CONTACT-INFO >>>>> > > > Following the conventions (including indentation style) >>>>> will >>>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>>> > > > Will be good if it does not overflow into the next page. >>>>> > >>>>> > Fixed. >>>>> The format is OK. The Postal address etc., need not have been >>>>> deleted. Please put the complete contact information as in the >>>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>>> >>>> Fixed. >>>> >>>>> 7.3 >>>>> > I kept "experimental 99" so that I could continue to use mib >>>>> tools >>>>> > to validate; but I added notes for the editor to replace them >>>>> as you >>>>> > indicated. >>>>> Use of "experimental 99" is not recommended. >>>> >>>> Do you mean 99 is not a good number? What about 9999? As I explained, >>>> I kept it so that we can use mib tools to validate, and I've added >>>> detailed notes for the editor. >>>> >>>>> 8 >>>>> > > > 8. Specific MO and TC related comments. >>>>> > Are spaces allowed? I don't know so I used hyphen. For now I >>>>> replace >>>>> > with things like rsvpP2mp. >>>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>>> >>>> Ok this is closed already then. >>>> >>>>> 8.2 >>>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>> > The intent is to simply return the octet value of the flags >>>>> > field, w/o listing individual bits like "Leaf Information >>>>> Required". >>>>> > More bits could be defined in the future but the MIB would not >>>>> change. >>>>> > >>>>> > Is that OK? >>>>> As far as possible, the meaning of the objects must be made clear. >>>>> That will help implementors and operators- users of the MIB. >>>> >>>> I added the definition for one existing bit and reference to the IANA >>>> registry being created for this flag field. >>>> >>>>> >>>>> 8.3 >>>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>> > Depending on the tunnel type, there could be different sizes. >>>>> > Future tunnel types could have other sizes that not specified >>>>> > today. I was thinking to just give a size >>>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>>>> > Is that ok? >>>>> I see that you have changed the size upper limit to 50. >>>>> If the size varies continuously from 0 to 50 the above description >>>>> is correct. >>>>> Please confirm, explain and cite appropriate reference. If the size >>>>> may change in the future that must be stated too. >>>> >>>> I changed to discrete sizes for currently defined tunnel types. >>>> >>>>> >>>>> 8.4 >>>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>> > > > SYNTAX RowPointer >>>>> > > > MAX-ACCESS read-only >>>>> > > > STATUS current >>>>> > > > DESCRIPTION >>>>> > > > "If the tunnel has a corresponding interface, >>>>> > > > this is the row pointer to the ifName table." >>>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>>> > > > want to say this object points to the corresponding >>>>> > > > row in the ifTable? >>>>> > >>>>> > Yes. Fixed. >>>>> Not quite. >>>>> What is ifName table ? ifName is a columnar object in the >>>>> ifXTable. >>>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row in >>>>> the >>>>> ifXTable table ? Please fix accordingly. >>>> >>>> You're right. Fixed. >>>> >>>>> >>>>> 9. >>>>> > > > 9. The Security Considerations section does not follow >>>>> > > > the Security Guidelines for IETF MIB Modules >>>>> > > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>> > > > Please fix. >>>>> > >>>>> > I was really hoping that it would not have to be that >>>>> > tedious. SNMP/MIB secur >>>>> ity should be no different from the >>>>> > CLI security - once you secure the infrastructure >>>>> > then what's more to do? >>>>> > >>>>> > I'll need more time to work on this. Let me try to address >>>>> > the issues in the other mib first and come back to this. >>>>> >>>>> Please take your time. Looking at examples will help. And let me >>>>> know where I can help. >>>> >>>> I will need to work on that later. >>>> >>>>> >>>>> 10.1 >>>>> > > > 10.1 Checking nits according to >>>>> > > > http://www.ietf.org/id-info/checklist : >>>>> > Should I break them into different lines or just keep them >>>>> > as is? Any example of expected indentation if I break the >>>>> > lines? >>>>> No problems at all to break lines. >>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>>> ::= {l2L3VpnMcastConformance 1} >>>>> Should do. >>>> >>>> Done. >>>> >>>>> >>>>> 10.2 >>>>> > > > 10.2 Checking references for intended status: Proposed >>>>> Standard >>>>> > > > == Missing Reference: 'RFC 7117' is mentioned on line >>>>> 76, >>>>> > > > but not defined >>>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and other >>>>> > I hope I understood and fixed it (removing the space in "RFC >>>>> 7117"). >>>>> I would recommend that you put it as [RFC6513], [RFC6514], [RFC7117] >>>>> That is simpler to parse. >>>> >>>> I see some other documents do not have comma between multiple >>>> references so I followed that. >>>> >>>>> >>>>> > > > 11. There is another WIP MVPN-MIB in >>>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>> > > > Is there a good reason for not merging the 2 documents? >>>>> > > > I have not seen any discussion or explanation on this. >>>>> > > > I may have missed it. >>>>> > > > Please clarify or, give some pointers. >>>>> > >>>>> > As mentioned in the introduction: >>>>> > >>>>> > this memo describes managed objects common to both VPLS >>>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>>> > in the work and both would reference common >>>>> >>>>> > objects defined in this MIB. >>>>> >>>>> OK. So you are saying that this MIB contains core objects that >>>>> will be used to manage implementations of various multicast VPN >>>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>>> you spell it out at the beginning. >>>> >>>> Yes. I thought I did it already: >>>> >>>> 1. Introduction >>>> >>>> ... and this memo describes managed objects common to both VPLS >>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>> >>>> Thanks! >>>> Jeffrey >>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>>> Glenn, >>>>>> >>>>>> Thanks for your comments. I've addressed most of your comments in >>>>>> the >>>>> new revision: >>>>>> >>>>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>>> l2l3-vpn-mcast-mib-03.txt >>>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>>> vpn-mcast-mib/ >>>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>>> mcast-mib-03 >>>>>> Diff: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>>>> vpn-mcast-mib-03 >>>>>> >>>>>> Please see below. >>>>>> >>>>>>> 1. Abstract: >>>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>>> applications for operations, monitoring and management >>>>>>> would be good. >>>>>> >>>>>> I had thought this would be standard/obvious for all MIB objects >>>>>> - the >>>>> read-write ones are used to control how a device works, and the >>>>> read-only >>>>> ones are used for monitoring. Do I really need to say it explicitly? >>>>>> >>>>>> I see RFC 4382 has the following: >>>>>> >>>>>> This memo defines a portion of the Management Information Base >>>>>> (MIB) >>>>>> for use with network management protocols in the Internet >>>>>> community. >>>>>> In particular, it describes managed objects to configure and/or >>>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>>> Networks on a Multiprotocol Label Switching (MPLS) Label >>>>>> Switching >>>>>> Router (LSR) supporting this feature. >>>>>> >>>>>> Is it enough to say something similar? For example: >>>>>> >>>>>> In particular, it describes common managed objects used to >>>>> configure >>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>> >>>>>>> >>>>>>> 2. Introduction >>>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>>> appearing for the first time. (PE, VPLS,..) >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>>> terms that are used, nicely with reference to the protocol >>>>>>> documents will improve readability. >>>>>>> e.g. >>>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>>> >>>>>> As the paragraph alluded to, this MIB needs to be understood in the >>>>> general context of L2/L3 multicast VPN and providing good >>>>> explanation of >>>>> the terms is not attempted. The references for the terms are the the >>>>> RFCs >>>>> for the relevant technologies. >>>>>> >>>>>> Having said that, I'll explain PMSI a bit further. >>>>>> >>>>>>> 2.3 Is there a difference between >>>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>>> RFC 7117 and RFC 6513/6514" >>>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>>> and >>>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>>> If these are the same, it will be helpful to stick to the >>>>>>> same expression. If these are not the same, the dictinction >>>>>>> should be clarified. >>>>>> >>>>>> No difference. I was using "Layer 3" or "L3" but it was pointed out >>>>>> that >>>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>>>> advised to change it accordingly. Looks like I did not change all the >>>>> cases. >>>>>> >>>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>>>> I'll change it back. >>>>>> >>>>>>> >>>>>>> >>>>>>> 3. Summary of MIB Module. >>>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>> structure of the MIB, short descriptions of the table(s) >>>>>>> including usage of the table(s) for management and/or by >>>>>>> other MIB(s). >>>>>> >>>>>> I had that, but have added one sentence about the only table. >>>>>> >>>>>>> >>>>>>> MIB definitions: >>>>>>> 4. MIB syntax checking: >>>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>> >>>>>> I used simpleweb's validation tool but looks like I did not use the >>>>> strictest level of validation. I've now fixed the following issues >>>>> and >>>>> verified. >>>>>> >>>>>>> >>>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named >>>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: named >>>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: named >>>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: named >>>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: named >>>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: named >>>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: named >>>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>>> >>>>>> See later question/comments below. >>>>>> >>>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: current >>>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: >>>>>>> identifier >>>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: >>>>>>> identifier >>>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: >>>>>>> identifier >>>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>> identifier >>>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>> identifier >>>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>> identifier >>>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>> identifier >>>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: >>>>>>> identifier >>>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never >>>>> used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>> identifier >>>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>> identifier >>>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never >>>>> used >>>>>> >>>>>> Removed the above unused imports. >>>>>> >>>>>>> >>>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>>> Wherever possible, provide references for objects used in >>>>>>> the MIB. The references will point to specific sections/ >>>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>>> MIB is being designed. It will greatly improve the readability >>>>>>> of the document. >>>>>> >>>>>> Added. >>>>>> >>>>>>> >>>>>>> 6. IMPORTS clause >>>>>>> MIB modules from which items are imported must be cited and >>>>>>> included in the normative references. >>>>>>> The conventional style is >>>>>>> mplsStdMIB >>>>>>> FROM MPLS-TC-STD-MIB -- [RFC3811] >>>>>> >>>>>> Added. >>>>>> >>>>>>> >>>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic >>>>>>> errors.) >>>>>>> 7.1 CONTACT-INFO >>>>>>> Following the conventions (including indentation style) will >>>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>>> Will be good if it does not overflow into the next page. >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>>>> sec 4.5 >>>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this >>>>>>> note: >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>>>> sec 4.5 i >>>>>>> replace >>>>>>> ::= { experimental 99 } -- number to be assigned >>>>>>> by >>>>>>> ::= { XXX } >>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this >>>>>>> note >>>>>>> will be the subtree under which the module will be >>>>>>> registered. >>>>>>> >>>>>> >>>>>> I kept "experimental 99" so that I could continue to use mib >>>>>> tools to >>>>> validate; but I added notes for the editor to replace them as you >>>>> indicated. >>>>>> >>>>>>> >>>>>>> 8. Specific MO and TC related comments. >>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "Types of provider tunnels used for multicast in >>>>>>> BGP/MPLS L2 or IP VPN." >>>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>>> rsvp-p2mp (1), >>>>>>> ldp-p2mp (2), >>>>>>> pim-asm (3), >>>>>>> pim-ssm (4), >>>>>>> pim-bidir (5), >>>>>>> ingress-replication (6), >>>>>>> ldp-mp2mp (7) >>>>>>> >>>>>>> o Would be nice to align the enumeration labels with the >>>>>>> labels in the protocol document RFC 6514 unless there is >>>>>>> a good reason for not doing so. (You will have to take >>>>>>> care of the smi compilation errors too; '-' is not allowed ). >>>>>> >>>>>> Are spaces allowed? I don't know so I used hyphen. For now I replace >>>>> with things like rsvpP2mp. >>>>>> Or could/should I just remove the definitions, so that if a new >>>>>> type is >>>>> defined in the future there is no need to update the MIB? >>>>>> >>>>>>> >>>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>> MAX-ACCESS not-accessible >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "An entry in this table corresponds to an PMSI >>>>>>> attribute >>>>>>> that is advertised/received on this router. >>>>>>> For BGP-based signaling (for I-PMSI via >>>>>>> auto-discovery >>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>> they are just as signaled by BGP (RFC 6514 section 5, >>>>>>> 'PMSI Tunnel attribute'). >>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>> they're derived from S-PMSI Join Message >>>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>>> >>>>>>> Note that BGP-based signaling may be used for >>>>>>> PIM-MVPN as well." >>>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>>> o Please give the reference for this Table. >>>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>>> both? >>>>>>> Any other pointers? >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>>> MAX-ACCESS not-accessible >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this >>>>>>> is 0. >>>>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>> I/S-PMSI A-D route." >>>>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>>> o Please confirm that the above is a complete enumeration >>>>>>> of the >>>>>>> types of signalling. >>>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>>> "Leaf Information Required". That is useful information. >>>>>>> Please include in the description. >>>>>> >>>>>> The intent is to simply return the octet value of the flags >>>>>> field, w/o >>>>> listing individual bits like "Leaf Information Required". More bits >>>>> could >>>>> be defined in the future but the MIB would not change. >>>>>> >>>>>> Is that OK? >>>>>> >>>>>>> >>>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>>> MAX-ACCESS not-accessible >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the >>>>>>> first >>>>>>> four or sixteen octets of this attribute are filled >>>>>>> with >>>>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>> Identifier >>>>>>> Field in PMSI Tunnel Attribute of the corresponding >>>>>>> I/S- >>>>> PMSI >>>>>>> A-D route." >>>>>>> o Check the size specifications. The specs above say it can be >>>>>>> all sizes 0..37. That is not clear from the DESCRIPTION >>>>>>> clause. >>>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>>> Identifiers >>>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress >>>>>>> Replication,MP2MP. >>>>>>> It appears that the sizes (range) for each case will be >>>>>>> different. >>>>>>> Please clarify that, and if there are discrete sizes, specify >>>>>>> accordingly. >>>>>> >>>>>> Depending on the tunnel type, there could be different sizes. Future >>>>> tunnel types could have other sizes that not specified today. I was >>>>> thinking to just give a size range so that it is flexible. Is that >>>>> ok? >>>>>> >>>>>>> >>>>>>> >>>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>> SYNTAX RowPointer >>>>>>> MAX-ACCESS read-only >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "If the tunnel exists in some MIB table, this is the >>>>>>> row pointer to it." >>>>>>> o "some MIB table" : specify which MIB table. >>>>>> >>>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could be >>>>> whatever table that a tunnel may be put into. >>>>>> >>>>>>> o In what case will the tunnel exist and in what case will it >>>>>>> not? >>>>>> >>>>>> If a device supports mplsTunnelTable and the tunnel is represented >>>>>> there, >>>>> then it exists. >>>>>> >>>>>>> o What will be the behaviour if the above condition is not >>>>> satisfied? >>>>>> >>>>>> A null pointer should be given. >>>>>> >>>>>>> >>>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>> SYNTAX RowPointer >>>>>>> MAX-ACCESS read-only >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "If the tunnel has a corresponding interface, this >>>>>>> is the >>>>>>> row pointer to the ifName table." >>>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want >>>>>>> to say >>>>>>> this object points to the corresponding row in the ifTable? >>>>>> >>>>>> Yes. Fixed. >>>>>> >>>>>>> o In what case does the TunnelIf exist and in what case >>>>>>> will it >>>>> not? >>>>>> >>>>>> Some tunnels may not have a corresponding interface. >>>>>> >>>>>>> o What will be expected if the tunnel does not have a >>>>> corresponding >>>>>>> interface? >>>>>> >>>>>> Null row pointer. >>>>>> >>>>>>> >>>>>>> 9. The Security Considerations section does not follow the Security >>>>>>> Guidelines for IETF MIB Modules >>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>> Please fix. >>>>>> >>>>>> I was really hoping that it would not have to be that tedious. >>>>>> SNMP/MIB >>>>> security should be no different from the CLI security - once you >>>>> secure >>>>> the infrastructure then what's more to do? >>>>>> >>>>>> I'll need more time to work on this. Let me try to address the >>>>>> issues in >>>>> the other mib first and come back to this. >>>>>> >>>>>>> >>>>>>> >>>>>>> 10.ID-nits >>>>>>> 10.1 Checking nits according to >>>>>>> http://www.ietf.org/id-info/checklist : >>>>>>> >>>>>>> ------------------------------------------------------------------ >>>>> --------- >>>>>>> >>>>>>> ** There are 4 instances of too long lines in the document, >>>>>>> the >>>>> longest one >>>>>>> being 3 characters in excess of 72. >>>>>> >>>>>> I fixed some but there still three too long lines: >>>>>> >>>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>>> L2L3VpnMcastProviderTunnelType, >>>>>> >>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= >>>>>> {l2L3VpnMcastConformance >>>>> 1} >>>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= >>>>>> {l2L3VpnMcastConformance >>>>> 2} >>>>>> >>>>>> Should I break them into different lines or just keep them as is? >>>>>> Any >>>>> example of expected indentation if I break the lines? >>>>>> >>>>>>> >>>>>>> 10.2 Checking references for intended status: Proposed Standard >>>>>>> >>>>>>> ------------------------------------------------------------------ >>>>> --------- >>>>>>> >>>>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, but >>>>>>> not >>>>>>> defined >>>>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other >>>>>>> documents >>>>> tha...' >>>>>> >>>>>> I hope I understood and fixed it (removing the space in "RFC 7117"). >>>>>> >>>>>>> >>>>>>> 11. There is another WIP MVPN-MIB in >>>>>>> draft-ietf-bess-mvpn-mib-02.txt >>>>>>> MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>>>> Is there a good reason for not merging the 2 documents? I have >>>>>>> not >>>>> seen >>>>>>> any discussion or explanation on this. I may have missed it. >>>>> Please >>>>>>> clarify or, give some pointers. >>>>>> >>>>>> As mentioned in the introduction: >>>>>> >>>>>> this memo describes managed objects common to both VPLS >>>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>> >>>>>> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the >>>>>> work >>>>> and both would reference common objects defined in this MIB. >>>>>> >>>>>> Thanks! >>>>>> Jeffrey >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Glenn >>>>>>> Mansfield >>>>>>> Keeni >>>>>>> Sent: Tuesday, April 12, 2016 2:28 AM >>>>>>> To: Benoit Claise ; EXT - >>>>>>> thomas.morin@orange.com >>>>>>> >>>>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>>>> Martin >>>>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>>>> >>>>>>> Subject: [bess] MIBDoc review of >>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>>> 02.txt >>>>>>> >>>>>>> Hi, >>>>>>> I have been asked to do a MIB Doctors review of >>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt. >>>>>>> My knowledge of L2L3VPN Multicast is limited to the reading >>>>>>> of this document and browsing through the documents referred >>>>>>> to in the draft and bess-wg mailing list archives.( read >>>>>>> "shallow"). >>>>>>> So some of the doubts and questions may sound trivial or >>>>>>> strange. Please bear with me and help me help you make >>>>>>> this into a better document :-) >>>>>>> >>>>>>> The comments are attached. >>>>>>> >>>>>>> Glenn >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> BESS mailing list >>>>>> BESS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > > . > From nobody Mon Oct 3 11:43:24 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1645A1294A2; Mon, 3 Oct 2016 11:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xmMg_T617cY; Mon, 3 Oct 2016 11:43:12 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0120.outbound.protection.outlook.com [104.47.42.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783F912949F; Mon, 3 Oct 2016 11:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gzPFtNyrk8DGC61paCikGZ3/rvZsEEgwQw7VZSneQxE=; b=XyB2qQVIo1Cz8iuMNiIRrq2g4tB8R38R84nGMl4PXGAPjAj+9oB7vb715Z3Zyjkw6CepsC3AvFoOyfCmZm6uusYNdTNv9Ah60cS0aifh2OnHzEHzKJ9NtjOOn8Eu4OGqu+wO8gb2owWO8DgcEaBR/BTzYYmp9hx+HzlxElmLiyk= Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by DM5PR05MB3147.namprd05.prod.outlook.com (10.173.219.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8; Mon, 3 Oct 2016 18:43:00 +0000 Received: from DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) by DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) with mapi id 15.01.0659.009; Mon, 3 Oct 2016 18:43:00 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Benoit Claise , Glenn Mansfield Keeni , "EXT - thomas.morin@orange.com" Thread-Topic: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt Thread-Index: AQHRwKCAxDexyEwkMUuqurSvHMHV1KAc8kwAgGqQeYCAECYAgIAAIFEA Date: Mon, 3 Oct 2016 18:42:59 +0000 Message-ID: References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <93a5d459-3271-b7ad-fadc-156576c60b65@cysols.com> <37e5086d-ce25-6b14-56d9-b53d46f863e2@cisco.com> In-Reply-To: <37e5086d-ce25-6b14-56d9-b53d46f863e2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 79d02c43-6ace-4ff6-21fc-08d3ebbd19a4 x-microsoft-exchange-diagnostics: 1; DM5PR05MB3147; 6:nZKqYMHWUr7/GZjGCjVWiOC/tVQawm10ZWrsXKj5Xp0AieaoF/66CQtNvLQzYbwjoriiF+rhw9U/yGU2NX6HAcfdGFxd6iJjSVdsx8P84N+lhxjrzYcOnKe+1/aDOzZYfDa0MfsQc+YlmRVWs4DNBf4WTaZssoeOVzT/qn7UlTrOqIwAshALWMc2WE9tBG4jBYruUlFfAKX8aYj/v1t8sYKuuw8ovs5e7aTbIXdH2k2xG8ZKx0IufAbdBTIB7LfqAN7mxVpBR2sCxcWB3p6510jYJmxiYsoDF/3avzhz00lY7bMcZ62VDDiQSGa2KAfeDYAgNFXieKniOGJ8OXf8Ih6WQbjRmLhE3X78qGjjU88=; 5:0pd4n/9IGobzZ5Msq1UbymkuimniIW+rlC/8QIRrb/xFkB62t10Ju5NtpMAR+ZZRV/MQPr8a46gxkk6+IpIaB3tUFGxAvFcrXirbvceXj/spLI+wK/Dl5sEgQyQSF4Llw4tll0KEjBTcwJgApdMyIQ==; 24:ELJce4K7v1ly2o9gaJlykNxqGQplNaQcelZURun0RJ49UGBF48UOTHGQKaY+XT0tHA/PGguPHH55sULbx8/wW+/4u2EQlE3RiiRQaBoe4xM=; 7:oxLQASULZ8cRaHSf1WkmVDGSs25+BSc3JUnD2kKwloGmEbX98qgzuyXnUP1zooxtfedSGgGdxnkX/VvWUTeZaEHFWR/QXUzm4vy+rNiVpyAphXLpIENfCIGUTq9/23P2ABdQK3mvnbAefwKj0v3j1I1I9AwNlTkPxxZvXuJN0772JmMkxvhts34SPkedEWixHKtT3Z0foXXVFO0d7D5js0D/pNYTH6YL4GSEPfnHw/wYIb2lTXMCJpnzBgRHJHr0ojeGAUQnNCru3LQVU3t8H6v1NjTOo6kxH0SJiDKOEizYKUBiivzcaPrhqx69p/Xj x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR05MB3147; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(120809045254105)(192374486261705)(138986009662008)(82608151540597)(788757137089)(95692535739014)(18271650672692)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM5PR05MB3147; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3147; x-forefront-prvs: 008421A8FF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(51914003)(13464003)(129404003)(24454002)(230783001)(68736007)(74316002)(4326007)(122556002)(10400500002)(102836003)(5890100001)(77096005)(76576001)(33656002)(1720100001)(5660300001)(7736002)(7696004)(305945005)(2900100001)(3846002)(92566002)(6116002)(87936001)(586003)(2950100002)(7846002)(93886004)(15975445007)(81166006)(81156014)(11100500001)(8936002)(101416001)(97736004)(8676002)(5001770100001)(50986999)(76176999)(54356999)(19580405001)(19580395003)(86362001)(5002640100001)(2906002)(3660700001)(189998001)(99286002)(106116001)(106356001)(105586002)(66066001)(3280700002)(9686002)(21314002)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3147; H:DM5PR05MB3145.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2016 18:42:59.8613 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3147 Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , "draft-ietf-bess-l2l3-vpn-mcast-mib.all@ietf.org" , "ops-ads@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 18:43:19 -0000 R2Vsbm4sIEJlbm9pdCwNCg0KU29ycnkgZm9yIHRoZSBsYXRlIGFjdGlvbiBhbmQgcmVzcG9uc2Ug YWZ0ZXIgdGhlIGluaXRpYWwgcm91bmQgb2YgcmV2aWV3IGFuZCByZXZpc2lvbiAtIEkgaGF2ZSBi ZWVuIHNpZGUgdHJhY2tlZCBieSBtYW55IG90aGVyIHRoaW5ncy4NCg0KSSB3aWxsIHRyeSB0byBn ZXQgdGhpcyBkb25lIHdpdGhpbiBuZXh0IHR3byB3ZWVrcy4NCg0KVGhhbmtzLg0KSmVmZnJleQ0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbm9pdCBDbGFpc2UgW21h aWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDAzLCAyMDE2 IDEyOjQyIFBNDQo+IFRvOiBHbGVubiBNYW5zZmllbGQgS2Vlbmk7IEplZmZyZXkgKFpoYW9odWkp IFpoYW5nOyBFWFQgLQ0KPiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbQ0KPiBDYzogbWliLWRvY3Rv cnNAaWV0Zi5vcmc7IG9wcy1hZHNAaWV0Zi5vcmc7IE1hY2ggQ2hlbjsgTWFydGluIFZpZ291cmV1 eDsNCj4gYmVzc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1iZXNzLWwybDMtdnBuLW1jYXN0LW1pYi5h bGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtiZXNzXSBNSUJEb2MgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtYmVzcy1sMmwzLXZwbi1tY2FzdC1taWItDQo+IDA0LnR4dA0KPiANCj4gQXV0aG9ycywN Cj4gDQo+IENhbiB5b3UgcGxlYXNlIGZpbmFsaXplIHRoaXMgZHJhZnQuDQo+IEdsZW5uIHByb3Zp ZGVkIHRoZSBmaXJzdCBNSUIgZG9jdG9yIHJldmlldyBpbiBBcHJpbCENCj4gDQo+IFJlZ2FyZHMs IEJlbm9pdA0KPiA+IEhpLA0KPiA+ICAgQW55IHVwZGF0ZSBvbiB0aGUgTUlCIGRyYWZ0cz8NCj4g PiBHbGVubg0KPiA+DQo+ID4gT24gMjAxNi8wNy8xNyAyMzo0NCwgR2xlbm4gTWFuc2ZpZWxkIEtl ZW5pIHdyb3RlOg0KPiA+PiBKZWZmcmV5IGFuZCB0ZWFtLA0KPiA+PiAgICAgIEFueSBwcm9ncmVz cyBvbiB0aGUgTUlCIG1hdHRlcnMNCj4gPj4gKGRyYWZ0LWlldGYtYmVzcy1sMmwzLXZwbi1tY2Fz dC1taWItMDUudHh0LA0KPiA+PiAgZHJhZnQtaWV0Zi1iZXNzLW12cG4tbWliLTAzLnR4dCApPw0K PiA+Pg0KPiA+PiBHbGVubg0KPiA+PiBPbiAyMDE2LzA2LzA3IDE4OjM5LCBHbGVubiBNYW5zZmll bGQgS2Vlbmkgd3JvdGU6DQo+ID4+PiBIaSBKZWZmcmV5LA0KPiA+Pj4gICAgVGhhbmtzIGZvciB0 aGUgZ29vZCB3b3JrIG9uIGRyYWZ0LWlldGYtYmVzcy1sMmwzLXZwbi1tY2FzdC1taWINCj4gPj4+ IGRvY3VtZW50LiBJdCB0b29rIG1lIHNvbWUgdGltZSB0byBkbyB0aGlzIHJldmlldy4gQnV0IG5v dyBoZXJlIGl0DQo+ID4+PiBpcy4gQSAobmVhciBjb21wbGV0ZSkgcmV2aWV3IG9mDQo+ID4+PiBk cmFmdC1pZXRmLWJlc3MtbDJsMy12cG4tbWNhc3QtbWliLTA0LnR4dCBpcyBhdHRhY2hlZC4gSG9w ZSB0aGlzIGhlbHBzLg0KPiA+Pj4gICAgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgVEJELg0KPiA+Pj4NCj4gPj4+ICAgIEdsZW5uDQo+ID4+ Pg0KPiA+Pj4gT24gMjAxNi8wNS8xOSA0OjQ4LCBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZyB3cm90 ZToNCj4gPj4+PiBIaSBHbGVubiwNCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+Pj4+PiBGcm9tOiBHbGVubiBNYW5zZmllbGQgS2VlbmkgW21haWx0bzpnbGVu bkBjeXNvbHMuY29tXQ0KPiA+Pj4+PiBTZW50OiBTdW5kYXksIE1heSAwOCwgMjAxNiAxMTowMiBB TQ0KPiA+Pj4+PiBUbzogSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcgPHp6aGFuZ0BqdW5pcGVyLm5l dD47IEJlbm9pdCBDbGFpc2UNCj4gPj4+Pj4gPGJjbGFpc2VAY2lzY28uY29tPjsgRVhUIC0gdGhv bWFzLm1vcmluQG9yYW5nZS5jb20NCj4gPj4+Pj4gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPg0K PiA+Pj4+PiBDYzogTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT47IG9wcy1hZHNAaWV0 Zi5vcmc7IE1hcnRpbg0KPiA+Pj4+PiBWaWdvdXJldXgNCj4gPj4+Pj4gPG1hcnRpbi52aWdvdXJl dXhAbm9raWEuY29tPjsgYmVzc0BpZXRmLm9yZzsgbWliLWRvY3RvcnNAaWV0Zi5vcmcNCj4gPj4+ Pj4gU3ViamVjdDogUmU6IFtiZXNzXSBNSUJEb2MgcmV2aWV3IG9mDQo+ID4+Pj4+IGRyYWZ0LWll dGYtYmVzcy1sMmwzLXZwbi1tY2FzdC1taWItDQo+ID4+Pj4+IDAyLnR4dA0KPiA+Pj4+Pg0KPiA+ Pj4+PiBKZWZmcmV5LA0KPiA+Pj4+PiAgPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIEkndmUg YWRkcmVzc2VkIG1vc3Qgb2YgeW91ciBjb21tZW50cw0KPiA+Pj4+PiAgPiBpbiB0aGUgbmV3IHJl dmlzaW9uOg0KPiA+Pj4+PiBUaGFua3MgZm9yIHlvdXIgY29vcGVyYXRpb24uIEkgd2lsbCBuZWVk IGF0IGxlYXN0IG9uZSBtb3JlIHJldmlzaW9uDQo+ID4+Pj4+IHdpdGggdGhlIGZvbGxvd2luZyBj b21tZW50cy9yZWNvbW1lbmRhdGlvbnMgYWRkcmVzc2VkIGJlZm9yZSBJIHdpbGwNCj4gPj4+Pj4g YmUgYWJsZSB0byBjb21wbGV0ZSB0aGUgZGV0YWlsZWQgcmV2aWV3LiBJbiB0aGUgZm9sbG93aW5n IHRoZQ0KPiBudW1iZXJzDQo+ID4+Pj4+IHJlZmVyIHRvIHRoZSBpc3N1ZSBudW1iZXJzIGluIHRo ZSBpbml0aWFsIHJldmlldy4gVGhlIGlzc3VlcyB0aGF0DQo+IGFyZQ0KPiA+Pj4+PiBhZGRyZXNz ZWQgYW5kIGNsb3NlZCBhcmUgbm90IGxpc3RlZC4gRm9yIGJyZXZpdHksIHRoZSBpc3N1ZQ0KPiA+ Pj4+PiBkZXNjcmlwdGlvbnMgaGF2ZSBiZWVuIHRyaW1tZWQuIEluIGNhc2Ugb2YgZG91YnRzIHBs ZWFzZSBsb29rIGF0IHRoZQ0KPiA+Pj4+PiByZXNwb25zZSBtYWlsIGFwcGVuZGVkIGJlbG93Lg0K PiA+Pj4+PiBIb3BlIHRoaXMgaGVscHMuDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MgZm9yIHlvdXIg ZGV0YWlsZWQgY29tbWVudHMvc3VnZ2VzdGlvbnMuIEkgcG9zdGVkIGEgbmV3DQo+IHJldmlzaW9u DQo+ID4+Pj4gd2l0aCB0aGUgZm9sbG93aW5nIGlzc3VlcyBhZGRyZXNzZWQuDQo+ID4+Pj4NCj4g Pj4+PiBVUkw6DQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtYmVzcy1sMmwzLXZwbi1tY2FzdC0NCj4gbWliLTA0LnR4dA0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IFN0YXR1czoNCj4gPj4+PiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWJlc3MtbDJsMy12cG4tbWNhc3QtbWliLw0KPiA+Pj4+IEh0 bWxpemVkOg0KPiA+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJl c3MtbDJsMy12cG4tbWNhc3QtbWliLTA0DQo+ID4+Pj4gRGlmZjoNCj4gPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZXNzLWwybDMtdnBuLW1jYXN0LW1p Yi0NCj4gMDQNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gUGxlYXNlIHNlZSBzb21lIG5vdGVzIGJl bG93Lg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IEdsZW5uDQo+ID4+Pj4+DQo+ID4+Pj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+Pj4NCj4gPj4+Pj4gQ29tbWVudHM6DQo+ID4+Pj4+DQo+ID4+Pj4+IDEu MQ0KPiA+Pj4+PiAgPiAgSSBoYWQgdGhvdWdodCB0aGlzIHdvdWxkIGJlIHN0YW5kYXJkL29idmlv dXMgZm9yIGFsbCBNSUINCj4gPj4+Pj4gb2JqZWN0cyAtDQo+ID4+Pj4+IFdlIHdpbGwgY29tZWJh Y2sgdG8gdGhpcyB0aW1lIGFuZCBhZ2Fpbiwgd2hlcmVldmVyIHBvc3NpYmxlIG1ha2UNCj4gPj4+ Pj4gbWF0dGVycyBleHBsaWNpdCBhbmQgY2xlYXIuIFRoYXQgd2lsbCBoZWxwLg0KPiA+Pj4+PiAg PiAgSXMgaXQgZW5vdWdoIHRvIHNheSBzb21ldGhpbmcgc2ltaWxhcj8gRm9yIGV4YW1wbGU6DQo+ ID4+Pj4+ICA+ICAgICAgICAgIEluIHBhcnRpY3VsYXIsIGl0IGRlc2NyaWJlcyBjb21tb24gbWFu YWdlZCBvYmplY3RzIHVzZWQNCj4gPj4+Pj4gID4gICAgICAgICAgdG8gY29uZmlndXJlIGFuZC9v ciBtb25pdG9yIGJvdGggTDIgYW5kIEwzIFZQTiBNdWx0aWNhc3QuDQo+ID4+Pj4+IFRoYXQgaXMg YmV0dGVyLg0KPiA+Pj4+DQo+ID4+Pj4gSSB0YWtlIGl0IHRoYXQgdGhpcyBpcyBhbHJlYWR5IGNs b3NlZCBpbiAtMDMgcmV2aXNpb24uDQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gMi4yDQo+ID4+ Pj4+ICA+ICBIYXZpbmcgc2FpZCB0aGF0LCBJJ2xsIGV4cGxhaW4gUE1TSSBhIGJpdCBmdXJ0aGVy Lg0KPiA+Pj4+PiBQTVNJIGV4cGxhbmF0aW9uIGlzIGdvb2QuDQo+ID4+Pj4+IFBsZWFzZSB1c2Ug dGhlIHNhbWUgc3R5bGUvZm9ybWF0IGZvciBJLVBNU0kgYW5kIFMtUE1TSS4NCj4gPj4+Pg0KPiA+ Pj4+IEkgdGhpbmsgLTAzIHJldmlzaW9uIGFscmVhZHkgdXNlIHRoZSBzYW1lIHN0eWxlL2Zvcm1h dCBmb3IgSS1QTVNJIGFuZA0KPiA+Pj4+IFMtUE1TST8NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+ PiAyLjMNCj4gPj4+Pj4gID4gIE5vIGRpZmZlcmVuY2UuIEkgd2FzIHVzaW5nICJMYXllciAzIiBv ciAiTDMiIGJ1dCBpdCB3YXMNCj4gPj4+Pj4gcG9pbnRlZCBvdXQNCj4gPj4+Pj4gID4gdGhhdCB0 aGUgbGF5ZXIgMyBWUE4gaXMgb2Z0ZW4gcmVmZXJyZWQgdG8gSVAgVlBOIGluIG90aGVyIFJGQ3MN Cj4gPj4+Pj4gYW5kIEkNCj4gPj4+Pj4gID4gd2FzIGFkdmlzZWQgdG8gY2hhbmdlIGl0IGFjY29y ZGluZ2x5LiBMb29rcyBsaWtlIEkgZGlkIG5vdCBjaGFuZ2UNCj4gPj4+Pj4gYWxsDQo+ID4+Pj4+ ICA+IHRoZSBjYXNlcy4NCj4gPj4+Pj4gID4gIE9uIHRoZSBvdGhlciBoYW5kLCBJIG5vdGljZWQg dGhhdCBSRkMgNDM4MiBkb2VzIHVzZSAiTGF5ZXIgMw0KPiA+Pj4+PiBWUE4iIHNvDQo+ID4+Pj4+ ICA+IEknbGwgY2hhbmdlIGl0IGJhY2suDQo+ID4+Pj4+IE5vIHByb2JsZW1zLiBqdXN0IG1ha2Ug c3VyZSB0aGF0IHRoZSBzYW1lIGV4cHJlc3Npb24vbm90YXRpb24gaXMNCj4gdXNlZA0KPiA+Pj4+ PiB1bmlmb3JtbHkuDQo+ID4+Pj4NCj4gPj4+PiBJIHRha2UgaXQgdGhhdCB0aGlzIGlzIGFsc28g YWRkcmVzc2VkIGluIC0wMyBhbHJlYWR5Lg0KPiA+Pj4+DQo+ID4+Pj4+IDMuDQo+ID4+Pj4+ICA+ ICA+ID4gMy4gIFN1bW1hcnkgb2YgTUlCIE1vZHVsZS4NCj4gPj4+Pj4gID4gID4gPiAgICAgQW4g b3ZlcnZpZXcgb2YgdGhlIEwyTDMtVlBOLU1DQVNULU1JQiB3aWxsIGJlIGdvb2QtIHRoZQ0KPiA+ Pj4+PiAgPiAgPiA+ICAgICBzdHJ1Y3R1cmUgb2YgdGhlIE1JQiwgc2hvcnQgZGVzY3JpcHRpb25z IG9mIHRoZSB0YWJsZShzKQ0KPiA+Pj4+PiAgPiAgPiA+ICAgICBpbmNsdWRpbmcgdXNhZ2Ugb2Yg dGhlIHRhYmxlKHMpIGZvciBtYW5hZ2VtZW50IGFuZC9vciBieQ0KPiA+Pj4+PiAgPiAgPiA+ICAg ICBvdGhlciBNSUIocykuDQo+ID4+Pj4+ICA+DQo+ID4+Pj4+ICA+ICBJIGhhZCB0aGF0LCBidXQg aGF2ZSBhZGRlZCBvbmUgc2VudGVuY2UgYWJvdXQgdGhlIG9ubHkgdGFibGUuDQo+ID4+Pj4+IEEg c2VudGVuY2Ugb3IgdHdvIGFib3V0IHRoZSB0ZXh0dWFsIGNvbnZlbnRpb24gd2lsbCBiZSBnb29k Lg0KPiA+Pj4+DQo+ID4+Pj4gQWRkZWQgaW4gLTA0Lg0KPiA+Pj4+DQo+ID4+Pj4+ICA+ICA+ID4g NC4gTUlCIHN5bnRheCBjaGVja2luZzoNCj4gPj4+Pj4gID4gID4gPiAgICBzbWlsaW50IC1zIC1l IC1sIDUgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUINCj4gPj4+Pj4gMj5MMkwzLVZQTi1NQ0FTVC1N SUIudHh0DQo+ID4+Pj4+ICA+DQo+ID4+Pj4+ICA+ICBJIHVzZWQgc2ltcGxld2ViJ3MgdmFsaWRh dGlvbiB0b29sIGJ1dCBsb29rcyBsaWtlIEkgZGlkIG5vdA0KPiA+Pj4+PiB1c2UgdGhlDQo+ID4+ Pj4+ICA+IHN0cmljdGVzdCBsZXZlbCBvZiB2YWxpZGF0aW9uLiBJJ3ZlIG5vdyBmaXhlZCB0aGUg Zm9sbG93aW5nDQo+IGlzc3Vlcw0KPiA+Pj4+PiBhbmQNCj4gPj4+Pj4gID4gdmVyaWZpZWQuDQo+ ID4+Pj4+IEdvb2QuDQo+ID4+Pj4+IDUuDQo+ID4+Pj4+ICA+ICA+ID4NCj4gPj4+Pj4gID4gID4g PiA1LiBSRUZFUkVOQ0UgY2xhdXNlczogUGxlYXNlIHVzZSBSRUZFUkVOQ0UgY2xhdXNlcyBsaWJl cmFsbHkuDQo+ID4+Pj4+ICA+ICA+ID4gICAgV2hlcmV2ZXIgcG9zc2libGUsIHByb3ZpZGUgcmVm ZXJlbmNlcyBmb3Igb2JqZWN0cyB1c2VkIGluDQo+ID4+Pj4+ICA+ICA+ID4gICAgdGhlIE1JQi4g VGhlIHJlZmVyZW5jZXMgd2lsbCBwb2ludCB0byBzcGVjaWZpYyBzZWN0aW9ucy8NCj4gPj4+Pj4g ID4gID4gPiAgICBzdWItc2VjdGlvbnMgb2YgdGhlIFJGQ3MgZGVmaW5pbmcgdGhlIHByb3RvY29s IGZvcg0KPiA+Pj4+PiB3aGljaCB0aGUNCj4gPj4+Pj4gID4gID4gPiAgICBNSUIgaXMgYmVpbmcg ZGVzaWduZWQuIEl0IHdpbGwgZ3JlYXRseSBpbXByb3ZlIHRoZQ0KPiA+Pj4+PiByZWFkYWJpbGl0 eQ0KPiA+Pj4+PiAgPiAgPiA+ICAgIG9mIHRoZSBkb2N1bWVudC4NCj4gPj4+Pj4gID4NCj4gPj4+ Pj4gID4gIEFkZGVkLg0KPiA+Pj4+PiBJIHdvdWxkIHJlY29tbWVuZCB1c2luZyB0aGUgUkVGRVJF TkNFIGNsYXVzZSBhcyBpbiByZnM0MzgyIGFuZA0KPiA+Pj4+PiBpbXByb3ZlIG9uIGl0Lg0KPiA+ Pj4+PiBTcGVjaWZpY2FsbHksIGluc3RlYWQgb2Yga2VlcGluZyB0aGUgcmVmZXJlbmNlIGluIHRo ZSBERVNDUklQVElPTg0KPiA+Pj4+PiBjbGF1c2UgbW92ZSBpdCB0byBhIHNlcGFyYXRlIFJFRkVS RU5DRSBjbGF1c2UuIFRoZSBhZGRpdGlvbiBvZiB0aGUNCj4gPj4+Pj4gc2VjdGlvbiBudW1iZXIg aXMgYW4gaW1wcm92ZW1lbnQuIEl0IGlzIGZyaWVuZGxpZXIgdG8gdGhlIHJlYWRlci4NCj4gPj4+ Pj4gTm90ZS4gU2FtZSBjb21tZW50IGZvciBvdGhlciBPQkpFQ1RzIHRvby4NCj4gPj4+Pg0KPiA+ Pj4+IE9oIEkgbWlzc2VkIHRoYXQuIEFsbCBmaXhlZC4NCj4gPj4+Pg0KPiA+Pj4+PiA3LjENCj4g Pj4+Pj4gID4gID4gPiA3LjEgQ09OVEFDVC1JTkZPDQo+ID4+Pj4+ICA+ICA+ID4gICAgIEZvbGxv d2luZyB0aGUgY29udmVudGlvbnMgKGluY2x1ZGluZyBpbmRlbnRhdGlvbiBzdHlsZSkNCj4gPj4+ Pj4gd2lsbA0KPiA+Pj4+PiAgPiAgPiA+ICAgICBpbXByb3ZlIHRoZSByZWFkYWJpbGl0eS4gKGUu Zy4gUkZDNDM4MiwgUkZDNTEzMikuDQo+ID4+Pj4+ICA+ICA+ID4gICAgIFdpbGwgYmUgZ29vZCBp ZiBpdCBkb2VzIG5vdCBvdmVyZmxvdyBpbnRvIHRoZSBuZXh0IHBhZ2UuDQo+ID4+Pj4+ICA+DQo+ ID4+Pj4+ICA+ICBGaXhlZC4NCj4gPj4+Pj4gVGhlIGZvcm1hdCBpcyBPSy4gVGhlIFBvc3RhbCBh ZGRyZXNzIGV0Yy4sIG5lZWQgbm90IGhhdmUgYmVlbg0KPiA+Pj4+PiBkZWxldGVkLiBQbGVhc2Ug cHV0IHRoZSBjb21wbGV0ZSBjb250YWN0IGluZm9ybWF0aW9uIGFzIGluIHRoZQ0KPiA+Pj4+PiBB dXRob3IncyBBZGRyZXNzLiAoUkZDIDI1Nzggc2VjdGlvbiA1LjcgZ2l2ZXMgYSB1c2FnZSBleGFt cGxlKS4NCj4gPj4+Pg0KPiA+Pj4+IEZpeGVkLg0KPiA+Pj4+DQo+ID4+Pj4+IDcuMw0KPiA+Pj4+ PiAgPiAgSSBrZXB0ICJleHBlcmltZW50YWwgOTkiIHNvIHRoYXQgSSBjb3VsZCBjb250aW51ZSB0 byB1c2UgbWliDQo+ID4+Pj4+IHRvb2xzDQo+ID4+Pj4+ICA+IHRvIHZhbGlkYXRlOyBidXQgSSBh ZGRlZCBub3RlcyBmb3IgdGhlIGVkaXRvciB0byByZXBsYWNlIHRoZW0NCj4gPj4+Pj4gYXMgeW91 DQo+ID4+Pj4+ICA+IGluZGljYXRlZC4NCj4gPj4+Pj4gVXNlIG9mICJleHBlcmltZW50YWwgOTki IGlzIG5vdCByZWNvbW1lbmRlZC4NCj4gPj4+Pg0KPiA+Pj4+IERvIHlvdSBtZWFuIDk5IGlzIG5v dCBhIGdvb2QgbnVtYmVyPyBXaGF0IGFib3V0IDk5OTk/IEFzIEkgZXhwbGFpbmVkLA0KPiA+Pj4+ IEkga2VwdCBpdCBzbyB0aGF0IHdlIGNhbiB1c2UgbWliIHRvb2xzIHRvIHZhbGlkYXRlLCBhbmQg SSd2ZSBhZGRlZA0KPiA+Pj4+IGRldGFpbGVkIG5vdGVzIGZvciB0aGUgZWRpdG9yLg0KPiA+Pj4+ DQo+ID4+Pj4+IDgNCj4gPj4+Pj4gID4gID4gPiA4LiBTcGVjaWZpYyBNTyBhbmQgVEMgcmVsYXRl ZCBjb21tZW50cy4NCj4gPj4+Pj4gID4gIEFyZSBzcGFjZXMgYWxsb3dlZD8gSSBkb24ndCBrbm93 IHNvIEkgdXNlZCBoeXBoZW4uIEZvciBub3cgSQ0KPiA+Pj4+PiByZXBsYWNlDQo+ID4+Pj4+ICA+ IHdpdGggdGhpbmdzIGxpa2UgcnN2cFAybXAuDQo+ID4+Pj4+IFllcy4gQ2FtZWxjYXNlIGlzIGFu IGFsbG93ZWQgcHJhY3RpY2UuIFNNSSBkb2VzIG5vdCBtaW5kIGl0Lg0KPiA+Pj4+DQo+ID4+Pj4g T2sgdGhpcyBpcyBjbG9zZWQgYWxyZWFkeSB0aGVuLg0KPiA+Pj4+DQo+ID4+Pj4+IDguMg0KPiA+ Pj4+PiAgPiAgPiA+IDguMiBsMkwzVnBuTWNhc3RQbXNpVHVubmVsQXR0cmlidXRlRmxhZ3MgT0JK RUNULVRZUEUNCj4gPj4+Pj4gID4gIFRoZSBpbnRlbnQgaXMgdG8gc2ltcGx5IHJldHVybiB0aGUg b2N0ZXQgdmFsdWUgb2YgdGhlIGZsYWdzDQo+ID4+Pj4+ICA+IGZpZWxkLCB3L28gbGlzdGluZyBp bmRpdmlkdWFsIGJpdHMgbGlrZSAiTGVhZiBJbmZvcm1hdGlvbg0KPiA+Pj4+PiBSZXF1aXJlZCIu DQo+ID4+Pj4+ICA+IE1vcmUgYml0cyBjb3VsZCBiZSBkZWZpbmVkIGluIHRoZSBmdXR1cmUgYnV0 IHRoZSBNSUIgd291bGQgbm90DQo+ID4+Pj4+IGNoYW5nZS4NCj4gPj4+Pj4gID4NCj4gPj4+Pj4g ID4gIElzIHRoYXQgT0s/DQo+ID4+Pj4+IEFzIGZhciBhcyBwb3NzaWJsZSwgdGhlIG1lYW5pbmcg b2YgdGhlIG9iamVjdHMgbXVzdCBiZSBtYWRlIGNsZWFyLg0KPiA+Pj4+PiBUaGF0IHdpbGwgaGVs cCBpbXBsZW1lbnRvcnMgYW5kIG9wZXJhdG9ycy0gdXNlcnMgb2YgdGhlIE1JQi4NCj4gPj4+Pg0K PiA+Pj4+IEkgYWRkZWQgdGhlIGRlZmluaXRpb24gZm9yIG9uZSBleGlzdGluZyBiaXQgYW5kIHJl ZmVyZW5jZSB0byB0aGUgSUFOQQ0KPiA+Pj4+IHJlZ2lzdHJ5IGJlaW5nIGNyZWF0ZWQgZm9yIHRo aXMgZmxhZyBmaWVsZC4NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiA4LjMNCj4gPj4+Pj4gID4g ID4gPiA4LjMgICBsMkwzVnBuTWNhc3RQbXNpVHVubmVsQXR0cmlidXRlSWQgT0JKRUNULVRZUEUN Cj4gPj4+Pj4gID4gIERlcGVuZGluZyBvbiB0aGUgdHVubmVsIHR5cGUsIHRoZXJlIGNvdWxkIGJl IGRpZmZlcmVudCBzaXplcy4NCj4gPj4+Pj4gID4gRnV0dXJlIHR1bm5lbCB0eXBlcyBjb3VsZCBo YXZlIG90aGVyIHNpemVzIHRoYXQgbm90IHNwZWNpZmllZA0KPiA+Pj4+PiAgPiB0b2RheS4gSSB3 YXMgdGhpbmtpbmcgdG8ganVzdCBnaXZlIGEgc2l6ZQ0KPiA+Pj4+PiAgPiB0UG1zaVR1bm5lbEF0 dHJpYnV0ZUlkIE9CSkVDVC1UWVBFIHJhbmdlIHNvIHRoYXQgaXQgaXMgZmxleGlibGUuDQo+ID4+ Pj4+ICA+IElzIHRoYXQgb2s/DQo+ID4+Pj4+IEkgc2VlIHRoYXQgeW91IGhhdmUgY2hhbmdlZCB0 aGUgc2l6ZSB1cHBlciBsaW1pdCB0byA1MC4NCj4gPj4+Pj4gSWYgdGhlIHNpemUgdmFyaWVzIGNv bnRpbnVvdXNseSBmcm9tIDAgdG8gNTAgdGhlIGFib3ZlIGRlc2NyaXB0aW9uDQo+ID4+Pj4+IGlz IGNvcnJlY3QuDQo+ID4+Pj4+IFBsZWFzZSBjb25maXJtLCBleHBsYWluIGFuZCBjaXRlIGFwcHJv cHJpYXRlIHJlZmVyZW5jZS4gSWYgdGhlIHNpemUNCj4gPj4+Pj4gbWF5IGNoYW5nZSBpbiB0aGUg ZnV0dXJlIHRoYXQgbXVzdCBiZSBzdGF0ZWQgdG9vLg0KPiA+Pj4+DQo+ID4+Pj4gSSBjaGFuZ2Vk IHRvIGRpc2NyZXRlIHNpemVzIGZvciBjdXJyZW50bHkgZGVmaW5lZCB0dW5uZWwgdHlwZXMuDQo+ ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gOC40DQo+ID4+Pj4+ICA+ICA+ID4gOC40ICBsMkwzVnBu TWNhc3RQbXNpVHVubmVsSWYgT0JKRUNULVRZUEUNCj4gPj4+Pj4gID4gID4gPiAgICAgICAgIFNZ TlRBWCAgICAgICAgUm93UG9pbnRlcg0KPiA+Pj4+PiAgPiAgPiA+ICAgICAgICAgTUFYLUFDQ0VT UyAgICByZWFkLW9ubHkNCj4gPj4+Pj4gID4gID4gPiAgICAgICAgIFNUQVRVUyAgICAgICAgY3Vy cmVudA0KPiA+Pj4+PiAgPiAgPiA+ICAgICAgICAgREVTQ1JJUFRJT04NCj4gPj4+Pj4gID4gID4g PiAgICAgICAgICAgICAiSWYgdGhlIHR1bm5lbCBoYXMgYSBjb3JyZXNwb25kaW5nIGludGVyZmFj ZSwNCj4gPj4+Pj4gID4gID4gPiAgICAgICAgICAgICAgdGhpcyBpcyB0aGUgcm93IHBvaW50ZXIg dG8gdGhlIGlmTmFtZSB0YWJsZS4iDQo+ID4+Pj4+ICA+ICA+ID4gICAgICBvIERFU0NSSVBUSU9O IGxvb2tzIGluY29ycmVjdC4gUGxlYXNlIGZpeCBpdC4gRG8geW91DQo+ID4+Pj4+ICA+ICA+ID4g ICAgICAgIHdhbnQgdG8gc2F5IHRoaXMgb2JqZWN0IHBvaW50cyB0byB0aGUgY29ycmVzcG9uZGlu Zw0KPiA+Pj4+PiAgPiAgPiA+ICAgICAgICByb3cgaW4gdGhlIGlmVGFibGU/DQo+ID4+Pj4+ICA+ DQo+ID4+Pj4+ICA+ICBZZXMuIEZpeGVkLg0KPiA+Pj4+PiBOb3QgcXVpdGUuDQo+ID4+Pj4+ICAg ICBXaGF0IGlzIGlmTmFtZSB0YWJsZSA/IGlmTmFtZSBpcyBhIGNvbHVtbmFyIG9iamVjdCBpbiB0 aGUNCj4gPj4+Pj4gaWZYVGFibGUuDQo+ID4+Pj4+ICAgICBJcyBsMkwzVnBuTWNhc3RQbXNpVHVu bmVsSWYgYSBwb2ludGVyIHRvIHRoZSBjb3JyZXNwb25kaW5nIHJvdw0KPiBpbg0KPiA+Pj4+PiB0 aGUNCj4gPj4+Pj4gICAgIGlmWFRhYmxlIHRhYmxlID8gUGxlYXNlIGZpeCBhY2NvcmRpbmdseS4N Cj4gPj4+Pg0KPiA+Pj4+IFlvdSdyZSByaWdodC4gRml4ZWQuDQo+ID4+Pj4NCj4gPj4+Pj4NCj4g Pj4+Pj4gOS4NCj4gPj4+Pj4gID4gID4gPiA5LiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg c2VjdGlvbiBkb2VzIG5vdCBmb2xsb3cNCj4gPj4+Pj4gID4gID4gPiAgICB0aGUgU2VjdXJpdHkg R3VpZGVsaW5lcyBmb3IgSUVURiBNSUIgTW9kdWxlcw0KPiA+Pj4+PiAgPiAgPiA+IGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvb3BzL3RyYWMvd2lraS9taWItc2VjdXJpdHkuDQo+ID4+ Pj4+ICA+ICA+ID4gICAgUGxlYXNlIGZpeC4NCj4gPj4+Pj4gID4NCj4gPj4+Pj4gID4gIEkgd2Fz IHJlYWxseSBob3BpbmcgdGhhdCBpdCB3b3VsZCBub3QgaGF2ZSB0byBiZSB0aGF0DQo+ID4+Pj4+ ICA+IHRlZGlvdXMuIFNOTVAvTUlCIHNlY3VyDQo+ID4+Pj4+IGl0eSBzaG91bGQgYmUgbm8gZGlm ZmVyZW50IGZyb20gdGhlDQo+ID4+Pj4+ICA+IENMSSBzZWN1cml0eSAtIG9uY2UgeW91IHNlY3Vy ZSB0aGUgaW5mcmFzdHJ1Y3R1cmUNCj4gPj4+Pj4gID4gdGhlbiB3aGF0J3MgbW9yZSB0byBkbz8N Cj4gPj4+Pj4gID4NCj4gPj4+Pj4gID4gIEknbGwgbmVlZCBtb3JlIHRpbWUgdG8gd29yayBvbiB0 aGlzLiBMZXQgbWUgdHJ5IHRvIGFkZHJlc3MNCj4gPj4+Pj4gID4gdGhlIGlzc3VlcyBpbiB0aGUg b3RoZXIgbWliIGZpcnN0IGFuZCBjb21lIGJhY2sgdG8gdGhpcy4NCj4gPj4+Pj4NCj4gPj4+Pj4g UGxlYXNlIHRha2UgeW91ciB0aW1lLiBMb29raW5nIGF0IGV4YW1wbGVzIHdpbGwgaGVscC4gQW5k IGxldCBtZQ0KPiA+Pj4+PiBrbm93IHdoZXJlIEkgY2FuIGhlbHAuDQo+ID4+Pj4NCj4gPj4+PiBJ IHdpbGwgbmVlZCB0byB3b3JrIG9uIHRoYXQgbGF0ZXIuDQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+ Pj4gMTAuMQ0KPiA+Pj4+PiAgPiAgPiA+IDEwLjEgQ2hlY2tpbmcgbml0cyBhY2NvcmRpbmcgdG8N Cj4gPj4+Pj4gID4gID4gPiBodHRwOi8vd3d3LmlldGYub3JnL2lkLWluZm8vY2hlY2tsaXN0IDoN Cj4gPj4+Pj4gID4gIFNob3VsZCBJIGJyZWFrIHRoZW0gaW50byBkaWZmZXJlbnQgbGluZXMgb3Ig anVzdCBrZWVwIHRoZW0NCj4gPj4+Pj4gID4gIGFzIGlzPyBBbnkgZXhhbXBsZSBvZiBleHBlY3Rl ZCBpbmRlbnRhdGlvbiBpZiBJIGJyZWFrIHRoZQ0KPiA+Pj4+PiAgPiAgbGluZXM/DQo+ID4+Pj4+ IE5vIHByb2JsZW1zIGF0IGFsbCB0byAgYnJlYWsgbGluZXMuDQo+ID4+Pj4+ICAgICAgIGwyTDNW cG5NY2FzdEdyb3VwcyAgICAgIE9CSkVDVCBJREVOVElGSUVSDQo+ID4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDo6PSB7bDJMM1Zwbk1jYXN0Q29uZm9ybWFuY2UgMX0NCj4gPj4+ Pj4gU2hvdWxkIGRvLg0KPiA+Pj4+DQo+ID4+Pj4gRG9uZS4NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+ Pj4+PiAxMC4yDQo+ID4+Pj4+ICA+ICA+ID4gMTAuMiBDaGVja2luZyByZWZlcmVuY2VzIGZvciBp bnRlbmRlZCBzdGF0dXM6IFByb3Bvc2VkDQo+ID4+Pj4+IFN0YW5kYXJkDQo+ID4+Pj4+ICA+ICA+ ID4gICAgICA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ1JGQyA3MTE3JyBpcyBtZW50aW9uZWQgb24g bGluZQ0KPiA+Pj4+PiA3NiwNCj4gPj4+Pj4gID4gID4gPiAgICAgICAgICBidXQgbm90IGRlZmlu ZWQNCj4gPj4+Pj4gID4gID4gPiAgICAgICAgICdkZXNjcmliZWQgaW4gW1JGQzY1MTMsIFJGQzY1 MTQsIFJGQyA3MTE3XSBhbmQgb3RoZXINCj4gPj4+Pj4gID4gIEkgaG9wZSBJIHVuZGVyc3Rvb2Qg YW5kIGZpeGVkIGl0IChyZW1vdmluZyB0aGUgc3BhY2UgaW4gIlJGQw0KPiA+Pj4+PiA3MTE3Iiku DQo+ID4+Pj4+IEkgd291bGQgcmVjb21tZW5kIHRoYXQgeW91IHB1dCBpdCBhcyBbUkZDNjUxM10s IFtSRkM2NTE0XSwgW1JGQzcxMTddDQo+ID4+Pj4+IFRoYXQgaXMgc2ltcGxlciB0byBwYXJzZS4N Cj4gPj4+Pg0KPiA+Pj4+IEkgc2VlIHNvbWUgb3RoZXIgZG9jdW1lbnRzIGRvIG5vdCBoYXZlIGNv bW1hIGJldHdlZW4gbXVsdGlwbGUNCj4gPj4+PiByZWZlcmVuY2VzIHNvIEkgZm9sbG93ZWQgdGhh dC4NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgPiAgPiA+IDExLiAgVGhlcmUgaXMgYW5vdGhl ciBXSVAgTVZQTi1NSUIgaW4NCj4gPj4+Pj4gID4gID4gPiAgICAgIGRyYWZ0LWlldGYtYmVzcy1t dnBuLW1pYi0wMi50eHQNCj4gPj4+Pj4gID4gID4gPiAgICAgIE1WUE4tTUlCIGhhcyBvYmplY3Rz IHRoYXQgcmVmZXIgdG8gTDJMMy1WUE4tTUNBU1QtTUlCLg0KPiA+Pj4+PiAgPiAgPiA+ICAgICAg SXMgdGhlcmUgYSBnb29kIHJlYXNvbiBmb3Igbm90IG1lcmdpbmcgdGhlIDIgZG9jdW1lbnRzPw0K PiA+Pj4+PiAgPiAgPiA+ICAgICAgSSBoYXZlIG5vdCBzZWVuIGFueSBkaXNjdXNzaW9uIG9yIGV4 cGxhbmF0aW9uIG9uIHRoaXMuDQo+ID4+Pj4+ICA+ICA+ID4gICAgICBJIG1heSBoYXZlIG1pc3Nl ZCBpdC4NCj4gPj4+Pj4gID4gID4gPiAgICAgIFBsZWFzZSBjbGFyaWZ5IG9yLCBnaXZlIHNvbWUg cG9pbnRlcnMuDQo+ID4+Pj4+ICA+DQo+ID4+Pj4+ICA+ICBBcyBtZW50aW9uZWQgaW4gdGhlIGlu dHJvZHVjdGlvbjoNCj4gPj4+Pj4gID4NCj4gPj4+Pj4gID4gICAgIHRoaXMgbWVtbyBkZXNjcmli ZXMgbWFuYWdlZCBvYmplY3RzIGNvbW1vbiB0byBib3RoIFZQTFMNCj4gPj4+Pj4gID4gICAgIE11 bHRpY2FzdCBbUkZDNzExN10gYW5kIE1WUE4gW1JGQzY1MTMsIFJGQzY1MTRdLg0KPiA+Pj4+PiAg PiAgICAgTVZQTi1NSUIgaXMgZm9yIE1WUE4uIFRoZXJlIHdhcyBhbm90aGVyIFZQTFMgTXVsdGlj YXN0IE1JQg0KPiA+Pj4+PiAgPiAgICAgaW4gdGhlIHdvcmsgYW5kIGJvdGggd291bGQgcmVmZXJl bmNlIGNvbW1vbg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgPiAgICAgb2JqZWN0cyBkZWZpbmVkIGluIHRo aXMgTUlCLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBPSy4gU28geW91IGFyZSBzYXlpbmcgdGhhdCB0aGlz IE1JQiBjb250YWlucyBjb3JlIG9iamVjdHMgdGhhdA0KPiA+Pj4+PiB3aWxsIGJlIHVzZWQgdG8g bWFuYWdlIGltcGxlbWVudGF0aW9ucyBvZiB2YXJpb3VzIG11bHRpY2FzdCBWUE4NCj4gPj4+Pj4g cHJvdG9jb2xzIGUuZy4gW1JGQzcxMTddLCBbUkZDNjUxM10sW1JGQzY1MTRdID8gSXQgd2lsbCBo ZWxwIGlmDQo+ID4+Pj4+IHlvdSBzcGVsbCBpdCBvdXQgYXQgdGhlIGJlZ2lubmluZy4NCj4gPj4+ Pg0KPiA+Pj4+IFllcy4gSSB0aG91Z2h0IEkgZGlkIGl0IGFscmVhZHk6DQo+ID4+Pj4NCj4gPj4+ PiAxLiAgSW50cm9kdWN0aW9uDQo+ID4+Pj4NCj4gPj4+PiAgICAuLi4gYW5kIHRoaXMgbWVtbyBk ZXNjcmliZXMgbWFuYWdlZCBvYmplY3RzIGNvbW1vbiB0byBib3RoIFZQTFMNCj4gPj4+PiAgICBN dWx0aWNhc3QgW1JGQzcxMTddIGFuZCBNVlBOIFtSRkM2NTEzLCBSRkM2NTE0XS4NCj4gPj4+Pg0K PiA+Pj4+IFRoYW5rcyENCj4gPj4+PiBKZWZmcmV5DQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0NCj4gPj4+Pj4NCj4gPj4+Pj4gT24gMjAxNi8wNC8xNiAyMTo0Nywg SmVmZnJleSAoWmhhb2h1aSkgWmhhbmcgd3JvdGU6DQo+ID4+Pj4+PiBHbGVubiwNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIEkndmUgYWRkcmVzc2VkIG1vc3Qg b2YgeW91ciBjb21tZW50cyBpbg0KPiA+Pj4+Pj4gdGhlDQo+ID4+Pj4+IG5ldyByZXZpc2lvbjoN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLWJlc3MtDQo+ID4+Pj4+IGwybDMtdnBuLW1jYXN0LW1pYi0wMy50eHQN Cj4gPj4+Pj4+IFN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1iZXNzLWwybDMtDQo+ID4+Pj4+IHZwbi1tY2FzdC1taWIvDQo+ID4+Pj4+PiBIdG1saXpl ZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmVzcy1sMmwzLXZwbi0N Cj4gPj4+Pj4gbWNhc3QtbWliLTAzDQo+ID4+Pj4+PiBEaWZmOg0KPiA+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmVzcy1sMmwzLQ0KPiA+Pj4+PiB2 cG4tbWNhc3QtbWliLTAzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUGxlYXNlIHNlZSBiZWxvdy4NCj4g Pj4+Pj4+DQo+ID4+Pj4+Pj4gMS4gIEFic3RyYWN0Og0KPiA+Pj4+Pj4+IDEuMSBBIHNlbnRlbmNl IG9uIGhvdyB0aGUgbWFuYWdlZCBvYmplY3RzIHdpbGwgYmUgdXNlZCBieQ0KPiA+Pj4+Pj4+ICAg ICBhcHBsaWNhdGlvbnMgZm9yIG9wZXJhdGlvbnMsIG1vbml0b3JpbmcgYW5kIG1hbmFnZW1lbnQN Cj4gPj4+Pj4+PiAgICAgd291bGQgYmUgZ29vZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJIGhhZCB0 aG91Z2h0IHRoaXMgd291bGQgYmUgc3RhbmRhcmQvb2J2aW91cyBmb3IgYWxsIE1JQiBvYmplY3Rz DQo+ID4+Pj4+PiAtIHRoZQ0KPiA+Pj4+PiByZWFkLXdyaXRlIG9uZXMgYXJlIHVzZWQgdG8gY29u dHJvbCBob3cgYSBkZXZpY2Ugd29ya3MsIGFuZCB0aGUNCj4gPj4+Pj4gcmVhZC1vbmx5DQo+ID4+ Pj4+IG9uZXMgYXJlIHVzZWQgZm9yIG1vbml0b3JpbmcuIERvIEkgcmVhbGx5IG5lZWQgdG8gc2F5 IGl0IGV4cGxpY2l0bHk/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBzZWUgUkZDIDQzODIgaGFzIHRo ZSBmb2xsb3dpbmc6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgVGhpcyBtZW1vIGRlZmluZXMgYSBw b3J0aW9uIG9mIHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UNCj4gPj4+Pj4+IChNSUIp DQo+ID4+Pj4+PiAgICBmb3IgdXNlIHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBp biB0aGUgSW50ZXJuZXQNCj4gPj4+Pj4+IGNvbW11bml0eS4NCj4gPj4+Pj4+ICAgIEluIHBhcnRp Y3VsYXIsIGl0IGRlc2NyaWJlcyBtYW5hZ2VkIG9iamVjdHMgdG8gY29uZmlndXJlIGFuZC9vcg0K PiA+Pj4+Pj4gICAgbW9uaXRvciBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBMYXllci0z IFZpcnR1YWwgUHJpdmF0ZQ0KPiA+Pj4+Pj4gICAgTmV0d29ya3Mgb24gYSBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZyAoTVBMUykgTGFiZWwNCj4gPj4+Pj4+IFN3aXRjaGluZw0KPiA+Pj4+ Pj4gICAgUm91dGVyIChMU1IpIHN1cHBvcnRpbmcgdGhpcyBmZWF0dXJlLg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IElzIGl0IGVub3VnaCB0byBzYXkgc29tZXRoaW5nIHNpbWlsYXI/IEZvciBleGFtcGxl Og0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICAgICAgSW4gcGFydGljdWxhciwgaXQgZGVzY3JpYmVz IGNvbW1vbiBtYW5hZ2VkIG9iamVjdHMgdXNlZCB0bw0KPiA+Pj4+PiBjb25maWd1cmUNCj4gPj4+ Pj4+ICAgICAgICAgYW5kL29yIG1vbml0b3IgYm90aCBMMiBhbmQgTDMgVlBOIE11bHRpY2FzdC4N Cj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAyLiAgSW50cm9kdWN0aW9uDQo+ID4+Pj4+ Pj4gMi4xIFBsZWFzZSBnaXZlIHRoZSBmdWxsIGV4cGFuc2lvbiBvZiB0aGUgYWJicmV2aWF0aW9u cw0KPiA+Pj4+Pj4+ICAgICBhcHBlYXJpbmcgZm9yIHRoZSBmaXJzdCB0aW1lLiAgKFBFLCBWUExT LC4uKQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEZpeGVkLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+IDIuMiBUaGUgdGVybWlub2xvZ3kgc2VjdGlvbiBpcyBhIGJpdCB0ZXJzZS4gRXhwbGFp bmluZyB0aGUNCj4gPj4+Pj4+PiAgICAgdGVybXMgdGhhdCBhcmUgdXNlZCwgbmljZWx5IHdpdGgg cmVmZXJlbmNlIHRvIHRoZSBwcm90b2NvbA0KPiA+Pj4+Pj4+ICAgICBkb2N1bWVudHMgd2lsbCBp bXByb3ZlIHJlYWRhYmlsaXR5Lg0KPiA+Pj4+Pj4+ICAgICBlLmcuDQo+ID4+Pj4+Pj4gICAgICAt IFBNU0ksIEktUE1TSSwgUy1QTVNJLCBwcm92aWRlciB0dW5uZWxzDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gQXMgdGhlIHBhcmFncmFwaCBhbGx1ZGVkIHRvLCB0aGlzIE1JQiBuZWVkcyB0byBiZSB1bmRl cnN0b29kIGluIHRoZQ0KPiA+Pj4+PiBnZW5lcmFsIGNvbnRleHQgb2YgTDIvTDMgbXVsdGljYXN0 IFZQTiBhbmQgcHJvdmlkaW5nIGdvb2QNCj4gPj4+Pj4gZXhwbGFuYXRpb24gb2YNCj4gPj4+Pj4g dGhlIHRlcm1zIGlzIG5vdCBhdHRlbXB0ZWQuIFRoZSByZWZlcmVuY2VzIGZvciB0aGUgdGVybXMg YXJlIHRoZSB0aGUNCj4gPj4+Pj4gUkZDcw0KPiA+Pj4+PiBmb3IgdGhlIHJlbGV2YW50IHRlY2hu b2xvZ2llcy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBIYXZpbmcgc2FpZCB0aGF0LCBJJ2xsIGV4cGxh aW4gUE1TSSBhIGJpdCBmdXJ0aGVyLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiAyLjMgSXMgdGhlcmUg YSBkaWZmZXJlbmNlIGJldHdlZW4NCj4gPj4+Pj4+PiAgICAgICAgIm11bHRpY2FzdCBpbiBMYXll ciAyIGFuZCBMYXllciAzIFZQTnMgLCBkZWZpbmVkIGJ5DQo+ID4+Pj4+Pj4gICAgICAgICBSRkMg NzExNyBhbmQgUkZDIDY1MTMvNjUxNCINCj4gPj4+Pj4+PiAgICAgdXNlZCBpbiB0aGUgREVTQ1JJ UFRJT04gaW4gdGhlIE1PRFVMRS1JREVOVElUWQ0KPiA+Pj4+Pj4+ICAgICBhbmQNCj4gPj4+Pj4+ PiAgICAgICAgIm11bHRpY2FzdCBpbiBCR1AvTVBMUyBMMiBvciBJUCBWUE4iDQo+ID4+Pj4+Pj4g ICAgIHVzZWQgaW4gdGhlIERFU0NSSVBUSU9OIG9mIEwyTDNWcG5NY2FzdFByb3ZpZGVyVHVubmVs VHlwZSA/DQo+ID4+Pj4+Pj4gICAgIElmIHRoZXNlIGFyZSB0aGUgc2FtZSwgaXQgd2lsbCBiZSBo ZWxwZnVsIHRvIHN0aWNrIHRvIHRoZQ0KPiA+Pj4+Pj4+ICAgICBzYW1lIGV4cHJlc3Npb24uIElm IHRoZXNlIGFyZSBub3QgdGhlIHNhbWUsIHRoZSBkaWN0aW5jdGlvbg0KPiA+Pj4+Pj4+ICAgICBz aG91bGQgYmUgY2xhcmlmaWVkLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE5vIGRpZmZlcmVuY2UuIEkg d2FzIHVzaW5nICJMYXllciAzIiBvciAiTDMiIGJ1dCBpdCB3YXMgcG9pbnRlZCBvdXQNCj4gPj4+ Pj4+IHRoYXQNCj4gPj4+Pj4gdGhlIGxheWVyIDMgVlBOIGlzIG9mdGVuIHJlZmVycmVkIHRvIElQ IFZQTiBpbiBvdGhlciBSRkNzIGFuZCBJIHdhcw0KPiA+Pj4+PiBhZHZpc2VkIHRvIGNoYW5nZSBp dCBhY2NvcmRpbmdseS4gTG9va3MgbGlrZSBJIGRpZCBub3QgY2hhbmdlIGFsbA0KPiB0aGUNCj4g Pj4+Pj4gY2FzZXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gdGhlIG90aGVyIGhhbmQsIEkgbm90 aWNlZCB0aGF0IFJGQyA0MzgyIGRvZXMgdXNlICJMYXllciAzIFZQTiINCj4gc28NCj4gPj4+Pj4g SSdsbCBjaGFuZ2UgaXQgYmFjay4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+IDMuICBTdW1tYXJ5IG9mIE1JQiBNb2R1bGUuDQo+ID4+Pj4+Pj4gICAgIEFuIG92ZXJ2 aWV3IG9mIHRoZSBMMkwzLVZQTi1NQ0FTVC1NSUIgd2lsbCBiZSBnb29kLSB0aGUNCj4gPj4+Pj4+ PiAgICAgc3RydWN0dXJlIG9mIHRoZSBNSUIsIHNob3J0IGRlc2NyaXB0aW9ucyBvZiB0aGUgdGFi bGUocykNCj4gPj4+Pj4+PiAgICAgaW5jbHVkaW5nIHVzYWdlIG9mIHRoZSB0YWJsZShzKSBmb3Ig bWFuYWdlbWVudCBhbmQvb3IgYnkNCj4gPj4+Pj4+PiAgICAgb3RoZXIgTUlCKHMpLg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+IEkgaGFkIHRoYXQsIGJ1dCBoYXZlIGFkZGVkIG9uZSBzZW50ZW5jZSBhYm91 dCB0aGUgb25seSB0YWJsZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBNSUIgZGVm aW5pdGlvbnM6DQo+ID4+Pj4+Pj4gNC4gTUlCIHN5bnRheCBjaGVja2luZzoNCj4gPj4+Pj4+PiAg ICBzbWlsaW50IC1zIC1lIC1sIDUgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUINCj4gPj4+Pj4+PiAy PkwyTDMtVlBOLU1DQVNULU1JQi50eHQNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJIHVzZWQgc2ltcGxl d2ViJ3MgdmFsaWRhdGlvbiB0b29sIGJ1dCBsb29rcyBsaWtlIEkgZGlkIG5vdCB1c2UgdGhlDQo+ ID4+Pj4+IHN0cmljdGVzdCBsZXZlbCBvZiB2YWxpZGF0aW9uLiBJJ3ZlIG5vdyBmaXhlZCB0aGUg Zm9sbG93aW5nIGlzc3Vlcw0KPiA+Pj4+PiBhbmQNCj4gPj4+Pj4gdmVyaWZpZWQuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUI6NjM6IFs0 XSB7aHlwaGVuLWluLWxhYmVsfSB3YXJuaW5nOg0KPiBuYW1lZA0KPiA+Pj4+PiBudW1iZXIgYHJz dnAtcDJtcCcgbXVzdCBub3QgaW5jbHVkZSBhIGh5cGhlbiBpbiBTTUl2Mg0KPiA+Pj4+Pj4+ICAg IG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjY0OiBbNF0ge2h5cGhlbi1pbi1sYWJlbH0gd2Fybmlu ZzoNCj4gbmFtZWQNCj4gPj4+Pj4gbnVtYmVyIGBsZHAtcDJtcCcgbXVzdCBub3QgaW5jbHVkZSBh IGh5cGhlbiBpbiBTTUl2Mg0KPiA+Pj4+Pj4+ICAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjY1 OiBbNF0ge2h5cGhlbi1pbi1sYWJlbH0gd2FybmluZzoNCj4gbmFtZWQNCj4gPj4+Pj4gbnVtYmVy IGBwaW0tYXNtJyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVuIGluIFNNSXYyDQo+ID4+Pj4+Pj4g ICAgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUI6NjY6IFs0XSB7aHlwaGVuLWluLWxhYmVsfSB3YXJu aW5nOg0KPiBuYW1lZA0KPiA+Pj4+PiBudW1iZXIgYHBpbS1zc20nIG11c3Qgbm90IGluY2x1ZGUg YSBoeXBoZW4gaW4gU01JdjINCj4gPj4+Pj4+PiAgICBtaWJzL0wyTDMtVlBOLU1DQVNULU1JQjo2 NzogWzRdIHtoeXBoZW4taW4tbGFiZWx9IHdhcm5pbmc6DQo+IG5hbWVkDQo+ID4+Pj4+IG51bWJl ciBgcGltLWJpZGlyJyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVuIGluIFNNSXYyDQo+ID4+Pj4+ Pj4gICAgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUI6Njg6IFs0XSB7aHlwaGVuLWluLWxhYmVsfSB3 YXJuaW5nOg0KPiBuYW1lZA0KPiA+Pj4+PiBudW1iZXIgYGluZ3Jlc3MtcmVwbGljYXRpb24nIG11 c3Qgbm90IGluY2x1ZGUgYSBoeXBoZW4gaW4gU01JdjINCj4gPj4+Pj4+PiAgICBtaWJzL0wyTDMt VlBOLU1DQVNULU1JQjo2OTogWzRdIHtoeXBoZW4taW4tbGFiZWx9IHdhcm5pbmc6DQo+IG5hbWVk DQo+ID4+Pj4+IG51bWJlciBgbGRwLW1wMm1wJyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVuIGlu IFNNSXYyDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gU2VlIGxhdGVyIHF1ZXN0aW9uL2NvbW1lbnRzIGJl bG93Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiAgICBtaWJzL0wyTDMtVlBOLU1DQVNULU1JQjoyMTU6 IFs1XSB7Z3JvdXAtdW5yZWZ9IHdhcm5pbmc6IGN1cnJlbnQNCj4gPj4+Pj4gZ3JvdXAgYGwyTDNW cG5NY2FzdE9wdGlvbmFsR3JvdXAnIGlzIG5vdCByZWZlcmVuY2VkIGluIHRoaXMgbW9kdWxlDQo+ ID4+Pj4+Pj4gICAgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUI6NDogWzVdIHtpbXBvcnQtdW51c2Vk fSB3YXJuaW5nOg0KPiA+Pj4+Pj4+IGlkZW50aWZpZXINCj4gPj4+Pj4gYE5PVElGSUNBVElPTi1U WVBFJyBpbXBvcnRlZCBmcm9tIG1vZHVsZSBgU05NUHYyLVNNSScgaXMgbmV2ZXIgdXNlZA0KPiA+ Pj4+Pj4+ICAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjU6IFs1XSB7aW1wb3J0LXVudXNlZH0g d2FybmluZzoNCj4gPj4+Pj4+PiBpZGVudGlmaWVyDQo+ID4+Pj4+IGBVbnNpZ25lZDMyJyBpbXBv cnRlZCBmcm9tIG1vZHVsZSBgU05NUHYyLVNNSScgaXMgbmV2ZXIgdXNlZA0KPiA+Pj4+Pj4+ICAg IG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjg6IFs1XSB7aW1wb3J0LXVudXNlZH0gd2FybmluZzoN Cj4gPj4+Pj4+PiBpZGVudGlmaWVyDQo+ID4+Pj4+IGBOT1RJRklDQVRJT04tR1JPVVAnIGltcG9y dGVkIGZyb20gbW9kdWxlIGBTTk1QdjItQ09ORicgaXMgbmV2ZXINCj4gdXNlZA0KPiA+Pj4+Pj4+ ICAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjExOiBbNV0ge2ltcG9ydC11bnVzZWR9IHdhcm5p bmc6DQo+ID4+Pj4+Pj4gaWRlbnRpZmllcg0KPiA+Pj4+PiBgVHJ1dGhWYWx1ZScgaW1wb3J0ZWQg ZnJvbSBtb2R1bGUgYFNOTVB2Mi1UQycgaXMgbmV2ZXIgdXNlZA0KPiA+Pj4+Pj4+ICAgIG1pYnMv TDJMMy1WUE4tTUNBU1QtTUlCOjExOiBbNV0ge2ltcG9ydC11bnVzZWR9IHdhcm5pbmc6DQo+ID4+ Pj4+Pj4gaWRlbnRpZmllcg0KPiA+Pj4+PiBgUm93U3RhdHVzJyBpbXBvcnRlZCBmcm9tIG1vZHVs ZSBgU05NUHYyLVRDJyBpcyBuZXZlciB1c2VkDQo+ID4+Pj4+Pj4gICAgbWlicy9MMkwzLVZQTi1N Q0FTVC1NSUI6MTI6IFs1XSB7aW1wb3J0LXVudXNlZH0gd2FybmluZzoNCj4gPj4+Pj4+PiBpZGVu dGlmaWVyDQo+ID4+Pj4+IGBUaW1lU3RhbXAnIGltcG9ydGVkIGZyb20gbW9kdWxlIGBTTk1QdjIt VEMnIGlzIG5ldmVyIHVzZWQNCj4gPj4+Pj4+PiAgICBtaWJzL0wyTDMtVlBOLU1DQVNULU1JQjox MjogWzVdIHtpbXBvcnQtdW51c2VkfSB3YXJuaW5nOg0KPiA+Pj4+Pj4+IGlkZW50aWZpZXINCj4g Pj4+Pj4gYFRpbWVJbnRlcnZhbCcgaW1wb3J0ZWQgZnJvbSBtb2R1bGUgYFNOTVB2Mi1UQycgaXMg bmV2ZXIgdXNlZA0KPiA+Pj4+Pj4+ICAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjE1OiBbNV0g e2ltcG9ydC11bnVzZWR9IHdhcm5pbmc6DQo+ID4+Pj4+Pj4gaWRlbnRpZmllcg0KPiA+Pj4+PiBg U25tcEFkbWluU3RyaW5nJyBpbXBvcnRlZCBmcm9tIG1vZHVsZSBgU05NUC1GUkFNRVdPUkstTUlC JyBpcyBuZXZlcg0KPiA+Pj4+PiB1c2VkDQo+ID4+Pj4+Pj4gICAgbWlicy9MMkwzLVZQTi1NQ0FT VC1NSUI6MTg6IFs1XSB7aW1wb3J0LXVudXNlZH0gd2FybmluZzoNCj4gPj4+Pj4+PiBpZGVudGlm aWVyDQo+ID4+Pj4+IGBJbmV0QWRkcmVzcycgaW1wb3J0ZWQgZnJvbSBtb2R1bGUgYElORVQtQURE UkVTUy1NSUInIGlzIG5ldmVyIHVzZWQNCj4gPj4+Pj4+PiAgICBtaWJzL0wyTDMtVlBOLU1DQVNU LU1JQjoxODogWzVdIHtpbXBvcnQtdW51c2VkfSB3YXJuaW5nOg0KPiA+Pj4+Pj4+IGlkZW50aWZp ZXINCj4gPj4+Pj4gYEluZXRBZGRyZXNzVHlwZScgaW1wb3J0ZWQgZnJvbSBtb2R1bGUgYElORVQt QUREUkVTUy1NSUInIGlzIG5ldmVyDQo+ID4+Pj4+IHVzZWQNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBS ZW1vdmVkIHRoZSBhYm92ZSB1bnVzZWQgaW1wb3J0cy4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PiA1LiBSRUZFUkVOQ0UgY2xhdXNlczogUGxlYXNlIHVzZSBSRUZFUkVOQ0UgY2xhdXNl cyBsaWJlcmFsbHkuDQo+ID4+Pj4+Pj4gICAgV2hlcmV2ZXIgcG9zc2libGUsIHByb3ZpZGUgcmVm ZXJlbmNlcyBmb3Igb2JqZWN0cyB1c2VkIGluDQo+ID4+Pj4+Pj4gICAgdGhlIE1JQi4gVGhlIHJl ZmVyZW5jZXMgd2lsbCBwb2ludCB0byBzcGVjaWZpYyBzZWN0aW9ucy8NCj4gPj4+Pj4+PiAgICBz dWItc2VjdGlvbnMgb2YgdGhlIFJGQ3MgZGVmaW5pbmcgdGhlIHByb3RvY29sIGZvciB3aGljaCB0 aGUNCj4gPj4+Pj4+PiAgICBNSUIgaXMgYmVpbmcgZGVzaWduZWQuIEl0IHdpbGwgZ3JlYXRseSBp bXByb3ZlIHRoZSByZWFkYWJpbGl0eQ0KPiA+Pj4+Pj4+ICAgIG9mIHRoZSBkb2N1bWVudC4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBBZGRlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiA2 LiBJTVBPUlRTIGNsYXVzZQ0KPiA+Pj4+Pj4+ICAgIE1JQiBtb2R1bGVzIGZyb20gd2hpY2ggaXRl bXMgYXJlIGltcG9ydGVkIG11c3QgYmUgY2l0ZWQgYW5kDQo+ID4+Pj4+Pj4gICAgaW5jbHVkZWQg aW4gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzLg0KPiA+Pj4+Pj4+ICAgIFRoZSBjb252ZW50aW9u YWwgc3R5bGUgaXMNCj4gPj4+Pj4+PiAgICAgIG1wbHNTdGRNSUINCj4gPj4+Pj4+PiAgICAgICAg IEZST00gTVBMUy1UQy1TVEQtTUlCIC0tIFtSRkMzODExXQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEFk ZGVkLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IDcuIFBsZWFzZSB1cGRhdGUgdGhl IE1PRFVMRS1JREVOVElUWS4gKFRoZXJlIGFyZSBubyBzeW50YW50aWMNCj4gPj4+Pj4+PiBlcnJv cnMuKQ0KPiA+Pj4+Pj4+IDcuMSBDT05UQUNULUlORk8NCj4gPj4+Pj4+PiAgICAgRm9sbG93aW5n IHRoZSBjb252ZW50aW9ucyAoaW5jbHVkaW5nIGluZGVudGF0aW9uIHN0eWxlKSB3aWxsDQo+ID4+ Pj4+Pj4gICAgIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5LiAoZS5nLiBSRkM0MzgyLCBSRkM1MTMy KS4NCj4gPj4+Pj4+PiAgICAgV2lsbCBiZSBnb29kIGlmIGl0IGRvZXMgbm90IG92ZXJmbG93IGlu dG8gdGhlIG5leHQgcGFnZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBGaXhlZC4NCj4gPj4+Pj4+DQo+ ID4+Pj4+Pj4NCj4gPj4+Pj4+PiA3LjIgUkVWSVNJT04gY2xhdXNlOiBmb2xsb3cgdGhlIGNvbnZl bnRpb24gcmVjb21tZW5kZWQgaW4gUkZDNDE4MQ0KPiA+Pj4+Pj4+ICAgICBzZWMgNC41DQo+ID4+ Pj4+Pj4gICAgICAgICAgIFJFVklTSU9OICAgICIyMDAyMTIxMzIzNThaIiAgLS0gRGVjZW1iZXIg MTMsIDIwMDINCj4gPj4+Pj4+PiAgICAgICAgICAgREVTQ1JJUFRJT04gIkluaXRpYWwgdmVyc2lv biwgcHVibGlzaGVkIGFzIFJGQyB5eXl5LiINCj4gPj4+Pj4+PiAgICAtLSBSRkMgRWQuOiByZXBs YWNlIHl5eXkgd2l0aCBhY3R1YWwgUkZDIG51bWJlciAmIHJlbW92ZSB0aGlzDQo+ID4+Pj4+Pj4g bm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBGaXhlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gNy4z IE9JRCBhc3NpZ25tZW50OiBmb2xsb3cgdGhlIGNvbnZlbnRpb24gcmVjb21tZW5kZWQgaW4gUkZD NDE4MQ0KPiA+Pj4+Pj4+ICAgICBzZWMgNC41IGkNCj4gPj4+Pj4+PiAgICAgcmVwbGFjZQ0KPiA+ Pj4+Pj4+ICAgICAgICAgICA6Oj0geyBleHBlcmltZW50YWwgOTkgfSAtLSBudW1iZXIgdG8gYmUg YXNzaWduZWQNCj4gPj4+Pj4+PiAgICAgYnkNCj4gPj4+Pj4+PiAgICAgICAgICAgOjo9IHsgPHN1 YnRyZWU+IFhYWCB9DQo+ID4+Pj4+Pj4gICAgLS0gUkZDIEVkLjogcmVwbGFjZSBYWFggd2l0aCBJ QU5BLWFzc2lnbmVkIG51bWJlciAmIHJlbW92ZSB0aGlzDQo+ID4+Pj4+Pj4gbm90ZQ0KPiA+Pj4+ Pj4+ICAgIDxzdWJ0cmVlPiB3aWxsIGJlIHRoZSBzdWJ0cmVlIHVuZGVyIHdoaWNoIHRoZSBtb2R1 bGUgd2lsbCBiZQ0KPiA+Pj4+Pj4+ICAgIHJlZ2lzdGVyZWQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBJIGtlcHQgImV4cGVyaW1lbnRhbCA5OSIgc28gdGhhdCBJIGNvdWxkIGNvbnRp bnVlIHRvIHVzZSBtaWINCj4gPj4+Pj4+IHRvb2xzIHRvDQo+ID4+Pj4+IHZhbGlkYXRlOyBidXQg SSBhZGRlZCBub3RlcyBmb3IgdGhlIGVkaXRvciB0byByZXBsYWNlIHRoZW0gYXMgeW91DQo+ID4+ Pj4+IGluZGljYXRlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiA4LiBTcGVjaWZp YyBNTyBhbmQgVEMgcmVsYXRlZCBjb21tZW50cy4NCj4gPj4+Pj4+PiAgICAgICBMMkwzVnBuTWNh c3RQcm92aWRlclR1bm5lbFR5cGUgOjo9IFRFWFRVQUwtQ09OVkVOVElPTg0KPiA+Pj4+Pj4+ICAg ICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQNCj4gPj4+Pj4+PiAgICAgICAgIERFU0NSSVBUSU9O DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgIlR5cGVzIG9mIHByb3ZpZGVyIHR1bm5lbHMgdXNlZCBm b3IgbXVsdGljYXN0IGluDQo+ID4+Pj4+Pj4gICAgICAgICAgICAgIEJHUC9NUExTIEwyIG9yIElQ IFZQTi4iDQo+ID4+Pj4+Pj4gICAgICAgICBTWU5UQVggICAgICAgSU5URUdFUiB7IHVuY29uZmln dXJlZCAoMCksDQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJzdnAt cDJtcCAoMSksDQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxkcC1w Mm1wICgyKSwNCj4gPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGltLWFz bSAoMyksDQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBpbS1zc20g KDQpLA0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwaW0tYmlkaXIg KDUpLA0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmdyZXNzLXJl cGxpY2F0aW9uICg2KSwNCj4gPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bGRwLW1wMm1wICg3KQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgIG8gV291bGQgYmUgbmljZSB0 byBhbGlnbiB0aGUgZW51bWVyYXRpb24gbGFiZWxzIHdpdGggdGhlDQo+ID4+Pj4+Pj4gICAgICAg bGFiZWxzIGluIHRoZSBwcm90b2NvbCBkb2N1bWVudCBSRkMgNjUxNCB1bmxlc3MgdGhlcmUgaXMN Cj4gPj4+Pj4+PiAgICAgICBhIGdvb2QgcmVhc29uIGZvciBub3QgZG9pbmcgc28uIChZb3Ugd2ls bCBoYXZlIHRvIHRha2UNCj4gPj4+Pj4+PiAgICAgICBjYXJlIG9mIHRoZSBzbWkgY29tcGlsYXRp b24gZXJyb3JzIHRvbzsgJy0nIGlzIG5vdCBhbGxvd2VkICkuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g QXJlIHNwYWNlcyBhbGxvd2VkPyBJIGRvbid0IGtub3cgc28gSSB1c2VkIGh5cGhlbi4gRm9yIG5v dyBJDQo+IHJlcGxhY2UNCj4gPj4+Pj4gd2l0aCB0aGluZ3MgbGlrZSByc3ZwUDJtcC4NCj4gPj4+ Pj4+IE9yIGNvdWxkL3Nob3VsZCBJIGp1c3QgcmVtb3ZlIHRoZSBkZWZpbml0aW9ucywgc28gdGhh dCBpZiBhIG5ldw0KPiA+Pj4+Pj4gdHlwZSBpcw0KPiA+Pj4+PiBkZWZpbmVkIGluIHRoZSBmdXR1 cmUgdGhlcmUgaXMgbm8gbmVlZCB0byB1cGRhdGUgdGhlIE1JQj8NCj4gPj4+Pj4+DQo+ID4+Pj4+ Pj4NCj4gPj4+Pj4+PiA4LjEgIGwyTDNWcG5NY2FzdFBtc2lUdW5uZWxBdHRyaWJ1dGVFbnRyeSBP QkpFQ1QtVFlQRQ0KPiA+Pj4+Pj4+ICAgICAgICAgIFNZTlRBWCBMMkwzVnBuTWNhc3RQbXNpVHVu bmVsQXR0cmlidXRlRW50cnkNCj4gPj4+Pj4+PiAgICAgICAgICBNQVgtQUNDRVNTICAgIG5vdC1h Y2Nlc3NpYmxlDQo+ID4+Pj4+Pj4gICAgICAgICAgU1RBVFVTICAgICAgICBjdXJyZW50DQo+ID4+ Pj4+Pj4gICAgICAgICAgREVTQ1JJUFRJT04NCj4gPj4+Pj4+PiAgICAgICAgICAgICAgIkFuIGVu dHJ5IGluIHRoaXMgdGFibGUgY29ycmVzcG9uZHMgdG8gYW4gUE1TSQ0KPiA+Pj4+Pj4+IGF0dHJp YnV0ZQ0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgdGhhdCBpcyBhZHZlcnRpc2VkL3JlY2VpdmVk IG9uIHRoaXMgcm91dGVyLg0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgRm9yIEJHUC1iYXNlZCBz aWduYWxpbmcgKGZvciBJLVBNU0kgdmlhDQo+ID4+Pj4+Pj4gYXV0by1kaXNjb3ZlcnkNCj4gPj4+ Pj4+PiAgICAgICAgICAgICAgIHByb2NlZHVyZSwgb3IgZm9yIFMtUE1TSSB2aWEgUy1QTVNJIEEt RCByb3V0ZXMpLA0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgdGhleSBhcmUganVzdCBhcyBzaWdu YWxlZCBieSBCR1AgKFJGQyA2NTE0IHNlY3Rpb24gNSwNCj4gPj4+Pj4+PiAgICAgICAgICAgICAg ICdQTVNJIFR1bm5lbCBhdHRyaWJ1dGUnKS4NCj4gPj4+Pj4+PiAgICAgICAgICAgICAgIEZvciBV RFAtYmFzZWQgUy1QTVNJIHNpZ25hbGluZyBmb3IgUElNLU1WUE4sDQo+ID4+Pj4+Pj4gICAgICAg ICAgICAgICB0aGV5J3JlIGRlcml2ZWQgZnJvbSBTLVBNU0kgSm9pbiBNZXNzYWdlDQo+ID4+Pj4+ Pj4gICAgICAgICAgICAgICAoUkZDIDY1MTMgc2VjdGlvbiA3LjQuMiwgJ1VEUC1iYXNlZCBQcm90 b2NvbCcpLi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgTm90ZSB0aGF0IEJH UC1iYXNlZCBzaWduYWxpbmcgbWF5IGJlIHVzZWQgZm9yDQo+ID4+Pj4+Pj4gICAgICAgICAgICAg ICBQSU0tTVZQTiBhcyB3ZWxsLiINCj4gPj4+Pj4+PiAgICAgbyBGaXggdGhlICIuLiIgaW4gIidV RFAtYmFzZWQgUHJvdG9jb2wnKS4uIiBhYm92ZS4NCj4gPj4+Pj4+PiAgICAgbyBQbGVhc2UgZ2l2 ZSB0aGUgcmVmZXJlbmNlIGZvciB0aGlzIFRhYmxlLg0KPiA+Pj4+Pj4+ICAgICAgIElzIGl0LSAg IlBNU0kgVHVubmVsIGF0dHJpYnV0ZSIgaW4gUkZDIDY1MTMgU2VjLjQgID8NCj4gPj4+Pj4+PiAg ICAgICAgICAgICAgICJQTVNJIFR1bm5lbCBhdHRyaWJ1dGUiIGluIFJGQyA2NTE0IFNlYy41ICA/ DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICAgYm90aD8NCj4gPj4+Pj4+PiAgICAgICBBbnkgb3Ro ZXIgcG9pbnRlcnM/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gRml4ZWQuDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gOC4yICAgbDJMM1Zwbk1jYXN0UG1zaVR1bm5lbEF0dHJpYnV0ZUZsYWdz IE9CSkVDVC1UWVBFDQo+ID4+Pj4+Pj4gICAgICAgICAgU1lOVEFYICAgICAgICBPQ1RFVCBTVFJJ TkcgKFNJWkUgKDEpKQ0KPiA+Pj4+Pj4+ICAgICAgICAgIE1BWC1BQ0NFU1MgICAgbm90LWFjY2Vz c2libGUNCj4gPj4+Pj4+PiAgICAgICAgICBTVEFUVVMgICAgICAgIGN1cnJlbnQNCj4gPj4+Pj4+ PiAgICAgICAgICBERVNDUklQVElPTg0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAiRm9yIFVEUC1i YXNlZCBTLVBNU0kgc2lnbmFsaW5nIGZvciBQSU0tTVZQTiwgdGhpcw0KPiA+Pj4+Pj4+IGlzIDAu DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICBGb3IgQkdQLWJhc2VkIEkvUy1QTVNJIHNpZ25hbGlu ZywgdGhpcyBpcyB0aGUgRmxhZ3MNCj4gPj4+Pj4+PiAgICAgICAgICAgICAgIGZpZWxkIGluIFBN U0kgVHVubmVsIEF0dHJpYnV0ZSBvZiB0aGUgY29ycmVzcG9uZGluZw0KPiA+Pj4+Pj4+ICAgICAg ICAgICAgICAgSS9TLVBNU0kgQS1EIHJvdXRlLiINCj4gPj4+Pj4+PiAgICAgICAgICA6Oj0geyBs MkwzVnBuTWNhc3RQbXNpVHVubmVsQXR0cmlidXRlRW50cnkgMSB9DQo+ID4+Pj4+Pj4gICAgIG8g IFBsZWFzZSBjb25maXJtIHRoYXQgdGhlIGFib3ZlIGlzIGEgY29tcGxldGUgZW51bWVyYXRpb24N Cj4gPj4+Pj4+PiBvZiB0aGUNCj4gPj4+Pj4+PiAgICAgICAgdHlwZXMgb2Ygc2lnbmFsbGluZy4N Cj4gPj4+Pj4+PiAgICAgbyAgUkZDIDY1MTQgU2VjLjUgc2F5cyB0aGF0IHRoZSBGbGFncyBmaWVs ZCBpbmRpY2F0ZXMNCj4gPj4+Pj4+PiAgICAgICAgIkxlYWYgSW5mb3JtYXRpb24gUmVxdWlyZWQi LiBUaGF0IGlzIHVzZWZ1bCBpbmZvcm1hdGlvbi4NCj4gPj4+Pj4+PiAgICAgICAgUGxlYXNlIGlu Y2x1ZGUgaW4gdGhlIGRlc2NyaXB0aW9uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBpbnRlbnQg aXMgdG8gc2ltcGx5IHJldHVybiB0aGUgb2N0ZXQgdmFsdWUgb2YgdGhlIGZsYWdzDQo+ID4+Pj4+ PiBmaWVsZCwgdy9vDQo+ID4+Pj4+IGxpc3RpbmcgaW5kaXZpZHVhbCBiaXRzIGxpa2UgIkxlYWYg SW5mb3JtYXRpb24gUmVxdWlyZWQiLiBNb3JlIGJpdHMNCj4gPj4+Pj4gY291bGQNCj4gPj4+Pj4g YmUgZGVmaW5lZCBpbiB0aGUgZnV0dXJlIGJ1dCB0aGUgTUlCIHdvdWxkIG5vdCBjaGFuZ2UuDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gSXMgdGhhdCBPSz8NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+PiA4LjMgICBsMkwzVnBuTWNhc3RQbXNpVHVubmVsQXR0cmlidXRlSWQgT0JKRUNULVRZUEUN Cj4gPj4+Pj4+PiAgICAgICAgICBTWU5UQVggICAgICAgIE9DVEVUIFNUUklORyAoIFNJWkUgKDAu LjM3KSApDQo+ID4+Pj4+Pj4gICAgICAgICAgTUFYLUFDQ0VTUyAgICBub3QtYWNjZXNzaWJsZQ0K PiA+Pj4+Pj4+ICAgICAgICAgIFNUQVRVUyAgICAgICAgY3VycmVudA0KPiA+Pj4+Pj4+ICAgICAg ICAgIERFU0NSSVBUSU9ODQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICJGb3IgVURQLWJhc2VkIFMt UE1TSSBzaWduYWxpbmcgZm9yIFBJTS1NVlBOLCB0aGUNCj4gPj4+Pj4+PiBmaXJzdA0KPiA+Pj4+ Pj4+ICAgICAgICAgICAgICAgZm91ciBvciBzaXh0ZWVuIG9jdGV0cyBvZiB0aGlzIGF0dHJpYnV0 ZSBhcmUgZmlsbGVkDQo+ID4+Pj4+Pj4gd2l0aA0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgdGhl IHByb3ZpZGVyIHR1bm5lbCBncm91cCBhZGRyZXNzIChJUHY0IG9yIElQdjYpLi4NCj4gPj4+Pj4+ PiAgICAgICAgICAgICAgIEZvciBCR1AtYmFzZWQgSS9TLVBNU0kgc2lnbmFsaW5nLCB0aGlzIGlz IHRoZSBUdW5uZWwNCj4gPj4+Pj4gSWRlbnRpZmllcg0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAg RmllbGQgaW4gUE1TSSBUdW5uZWwgQXR0cmlidXRlIG9mIHRoZSBjb3JyZXNwb25kaW5nDQo+ID4+ Pj4+Pj4gSS9TLQ0KPiA+Pj4+PiBQTVNJDQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICBBLUQgcm91 dGUuIg0KPiA+Pj4+Pj4+ICAgICBvIENoZWNrIHRoZSBzaXplIHNwZWNpZmljYXRpb25zLiBUaGUg c3BlY3MgYWJvdmUgc2F5IGl0IGNhbiBiZQ0KPiA+Pj4+Pj4+ICAgICAgIGFsbCBzaXplcyAwLi4z Ny4gVGhhdCBpcyBub3QgY2xlYXIgZnJvbSB0aGUgREVTQ1JJUFRJT04NCj4gPj4+Pj4+PiBjbGF1 c2UuDQo+ID4+Pj4+Pj4gICAgIG8gRml4IHRoZSAiLi4iIGluICIoSVB2NCBvciBJUHY2KS4uIiBh Ym92ZS4NCj4gPj4+Pj4+PiAgICAgbyBSRkMgNjUxNCBTZWMgNS4gIFBNU0kgVHVubmVsIEF0dHJp YnV0ZSBnaXZlcyB0aGUgVHVubmVsDQo+ID4+Pj4+IElkZW50aWZpZXJzDQo+ID4+Pj4+Pj4gICAg ICAgZm9yIG1MRFAsIFBJTS1TTSwgUElNLVNTTSwgQklESVItUElNLEluZ3Jlc3MNCj4gPj4+Pj4+ PiBSZXBsaWNhdGlvbixNUDJNUC4NCj4gPj4+Pj4+PiAgICAgICBJdCBhcHBlYXJzIHRoYXQgdGhl IHNpemVzIChyYW5nZSkgZm9yIGVhY2ggY2FzZSB3aWxsIGJlDQo+ID4+Pj4+Pj4gZGlmZmVyZW50 Lg0KPiA+Pj4+Pj4+ICAgICAgIFBsZWFzZSBjbGFyaWZ5IHRoYXQsIGFuZCBpZiB0aGVyZSBhcmUg ZGlzY3JldGUgc2l6ZXMsDQo+IHNwZWNpZnkNCj4gPj4+Pj4+PiAgICAgICBhY2NvcmRpbmdseS4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBEZXBlbmRpbmcgb24gdGhlIHR1bm5lbCB0eXBlLCB0aGVyZSBj b3VsZCBiZSBkaWZmZXJlbnQgc2l6ZXMuDQo+IEZ1dHVyZQ0KPiA+Pj4+PiB0dW5uZWwgdHlwZXMg Y291bGQgaGF2ZSBvdGhlciBzaXplcyB0aGF0IG5vdCBzcGVjaWZpZWQgdG9kYXkuIEkgd2FzDQo+ ID4+Pj4+IHRoaW5raW5nIHRvIGp1c3QgZ2l2ZSBhIHNpemUgcmFuZ2Ugc28gdGhhdCBpdCBpcyBm bGV4aWJsZS4gSXMgdGhhdA0KPiA+Pj4+PiBvaz8NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IDguMyAgbDJMM1Zwbk1jYXN0UG1zaVR1bm5lbFBvaW50ZXIgT0JKRUNU LVRZUEUNCj4gPj4+Pj4+PiAgICAgICAgIFNZTlRBWCAgICAgICAgUm93UG9pbnRlcg0KPiA+Pj4+ Pj4+ICAgICAgICAgTUFYLUFDQ0VTUyAgICByZWFkLW9ubHkNCj4gPj4+Pj4+PiAgICAgICAgIFNU QVRVUyAgICAgICAgY3VycmVudA0KPiA+Pj4+Pj4+ICAgICAgICAgREVTQ1JJUFRJT04NCj4gPj4+ Pj4+PiAgICAgICAgICAgICAiSWYgdGhlIHR1bm5lbCBleGlzdHMgaW4gc29tZSBNSUIgdGFibGUs IHRoaXMgaXMgdGhlDQo+ID4+Pj4+Pj4gICAgICAgICAgICAgIHJvdyBwb2ludGVyIHRvIGl0LiIN Cj4gPj4+Pj4+PiAgICAgbyAic29tZSBNSUIgdGFibGUiIDogc3BlY2lmeSB3aGljaCBNSUIgdGFi bGUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBjYW4gZ2l2ZSBhbiBleGFtcGxlLCBsaWtlIG1wbHNU dW5uZWxUYWJsZSBbUkZDIDM4MTJdLiBJdCBjb3VsZCBiZQ0KPiA+Pj4+PiB3aGF0ZXZlciB0YWJs ZSB0aGF0IGEgdHVubmVsIG1heSBiZSBwdXQgaW50by4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gICAg IG8gSW4gd2hhdCBjYXNlIHdpbGwgdGhlIHR1bm5lbCBleGlzdCBhbmQgaW4gd2hhdCBjYXNlIHdp bGwgaXQNCj4gPj4+Pj4+PiBub3Q/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSWYgYSBkZXZpY2Ugc3Vw cG9ydHMgbXBsc1R1bm5lbFRhYmxlIGFuZCB0aGUgdHVubmVsIGlzIHJlcHJlc2VudGVkDQo+ID4+ Pj4+PiB0aGVyZSwNCj4gPj4+Pj4gdGhlbiBpdCBleGlzdHMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+ ICAgICBvIFdoYXQgd2lsbCBiZSB0aGUgYmVoYXZpb3VyIGlmIHRoZSBhYm92ZSBjb25kaXRpb24g aXMgbm90DQo+ID4+Pj4+IHNhdGlzZmllZD8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBIG51bGwgcG9p bnRlciBzaG91bGQgYmUgZ2l2ZW4uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gOC40 ICBsMkwzVnBuTWNhc3RQbXNpVHVubmVsSWYgT0JKRUNULVRZUEUNCj4gPj4+Pj4+PiAgICAgICAg IFNZTlRBWCAgICAgICAgUm93UG9pbnRlcg0KPiA+Pj4+Pj4+ICAgICAgICAgTUFYLUFDQ0VTUyAg ICByZWFkLW9ubHkNCj4gPj4+Pj4+PiAgICAgICAgIFNUQVRVUyAgICAgICAgY3VycmVudA0KPiA+ Pj4+Pj4+ICAgICAgICAgREVTQ1JJUFRJT04NCj4gPj4+Pj4+PiAgICAgICAgICAgICAiSWYgdGhl IHR1bm5lbCBoYXMgYSBjb3JyZXNwb25kaW5nIGludGVyZmFjZSwgdGhpcw0KPiA+Pj4+Pj4+IGlz IHRoZQ0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICByb3cgcG9pbnRlciB0byB0aGUgaWZOYW1lIHRh YmxlLiINCj4gPj4+Pj4+PiAgICAgIG8gREVTQ1JJUFRJT04gbG9va3MgaW5jb3JyZWN0LiBQbGVh c2UgZml4IGl0LiBEbyB5b3Ugd2FudA0KPiA+Pj4+Pj4+IHRvIHNheQ0KPiA+Pj4+Pj4+ICAgICAg ICB0aGlzIG9iamVjdCBwb2ludHMgdG8gdGhlIGNvcnJlc3BvbmRpbmcgcm93IGluIHRoZSBpZlRh YmxlPw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFllcy4gRml4ZWQuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+ ICAgICAgbyBJbiB3aGF0IGNhc2UgZG9lcyB0aGUgVHVubmVsSWYgZXhpc3QgYW5kIGluIHdoYXQg Y2FzZQ0KPiA+Pj4+Pj4+IHdpbGwgaXQNCj4gPj4+Pj4gbm90Pw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IFNvbWUgdHVubmVscyBtYXkgbm90IGhhdmUgYSBjb3JyZXNwb25kaW5nIGludGVyZmFjZS4NCj4g Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgICBvIFdoYXQgd2lsbCBiZSBleHBlY3RlZCBpZiB0aGUgdHVu bmVsIGRvZXMgbm90IGhhdmUgYQ0KPiA+Pj4+PiBjb3JyZXNwb25kaW5nDQo+ID4+Pj4+Pj4gICAg ICAgIGludGVyZmFjZT8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBOdWxsIHJvdyBwb2ludGVyLg0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IDkuIFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uIGRvZXMgbm90IGZvbGxvdyB0aGUNCj4gU2VjdXJpdHkNCj4gPj4+Pj4+PiAgICBH dWlkZWxpbmVzIGZvciBJRVRGIE1JQiBNb2R1bGVzDQo+ID4+Pj4+Pj4gaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9vcHMvdHJhYy93aWtpL21pYi1zZWN1cml0eS4NCj4gPj4+Pj4+PiAg ICBQbGVhc2UgZml4Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgd2FzIHJlYWxseSBob3BpbmcgdGhh dCBpdCB3b3VsZCBub3QgaGF2ZSB0byBiZSB0aGF0IHRlZGlvdXMuDQo+ID4+Pj4+PiBTTk1QL01J Qg0KPiA+Pj4+PiBzZWN1cml0eSBzaG91bGQgYmUgbm8gZGlmZmVyZW50IGZyb20gdGhlIENMSSBz ZWN1cml0eSAtIG9uY2UgeW91DQo+ID4+Pj4+IHNlY3VyZQ0KPiA+Pj4+PiB0aGUgaW5mcmFzdHJ1 Y3R1cmUgdGhlbiB3aGF0J3MgbW9yZSB0byBkbz8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJJ2xsIG5l ZWQgbW9yZSB0aW1lIHRvIHdvcmsgb24gdGhpcy4gTGV0IG1lIHRyeSB0byBhZGRyZXNzIHRoZQ0K PiA+Pj4+Pj4gaXNzdWVzIGluDQo+ID4+Pj4+IHRoZSBvdGhlciBtaWIgZmlyc3QgYW5kIGNvbWUg YmFjayB0byB0aGlzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g MTAuSUQtbml0cw0KPiA+Pj4+Pj4+IDEwLjEgQ2hlY2tpbmcgbml0cyBhY2NvcmRpbmcgdG8NCj4g Pj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkLWluZm8vY2hlY2tsaXN0IDoNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+PiAtLS0tLS0tLS0NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+ICAgICAgKiogVGhlcmUgYXJlIDQgaW5zdGFuY2VzIG9mIHRvbyBsb25nIGxpbmVzIGlu IHRoZSBkb2N1bWVudCwNCj4gPj4+Pj4+PiB0aGUNCj4gPj4+Pj4gbG9uZ2VzdCBvbmUNCj4gPj4+ Pj4+PiAgICAgICAgIGJlaW5nIDMgY2hhcmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gSSBmaXhlZCBzb21lIGJ1dCB0aGVyZSBzdGlsbCB0aHJlZSB0b28gbG9uZyBs aW5lczoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgIGwyTDNWcG5NY2FzdFBtc2lUdW5uZWxBdHRy aWJ1dGVUeXBlDQo+ID4+Pj4+PiBMMkwzVnBuTWNhc3RQcm92aWRlclR1bm5lbFR5cGUsDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gICBsMkwzVnBuTWNhc3RHcm91cHMgICAgICBPQkpFQ1QgSURFTlRJRklF UiA6Oj0NCj4gPj4+Pj4+IHtsMkwzVnBuTWNhc3RDb25mb3JtYW5jZQ0KPiA+Pj4+PiAxfQ0KPiA+ Pj4+Pj4gICBsMkwzVnBuTWNhc3RDb21wbGlhbmNlcyBPQkpFQ1QgSURFTlRJRklFUiA6Oj0NCj4g Pj4+Pj4+IHtsMkwzVnBuTWNhc3RDb25mb3JtYW5jZQ0KPiA+Pj4+PiAyfQ0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IFNob3VsZCBJIGJyZWFrIHRoZW0gaW50byBkaWZmZXJlbnQgbGluZXMgb3IganVzdCBr ZWVwIHRoZW0gYXMgaXM/DQo+ID4+Pj4+PiBBbnkNCj4gPj4+Pj4gZXhhbXBsZSBvZiBleHBlY3Rl ZCBpbmRlbnRhdGlvbiBpZiBJIGJyZWFrIHRoZSBsaW5lcz8NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+PiAxMC4yIENoZWNraW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czog UHJvcG9zZWQgU3RhbmRhcmQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+ PiAtLS0tLS0tLS0NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAgPT0gTWlzc2luZyBSZWZlcmVu Y2U6ICdSRkMgNzExNycgaXMgbWVudGlvbmVkIG9uIGxpbmUgNzYsIGJ1dA0KPiA+Pj4+Pj4+IG5v dA0KPiA+Pj4+Pj4+ICAgICAgICAgZGVmaW5lZA0KPiA+Pj4+Pj4+ICAgICAgICAgJ2Rlc2NyaWJl ZCBpbiBbUkZDNjUxMywgUkZDNjUxNCwgUkZDIDcxMTddIGFuZCBvdGhlcg0KPiA+Pj4+Pj4+IGRv Y3VtZW50cw0KPiA+Pj4+PiB0aGEuLi4nDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBob3BlIEkgdW5k ZXJzdG9vZCBhbmQgZml4ZWQgaXQgKHJlbW92aW5nIHRoZSBzcGFjZSBpbiAiUkZDIDcxMTciKS4N Cj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAxMS4gIFRoZXJlIGlzIGFub3RoZXIgV0lQ IE1WUE4tTUlCIGluDQo+ID4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZXNzLW12cG4tbWliLTAyLnR4dA0K PiA+Pj4+Pj4+ICAgICAgTVZQTi1NSUIgaGFzIG9iamVjdHMgdGhhdCByZWZlciB0byBMMkwzLVZQ Ti1NQ0FTVC1NSUIuDQo+ID4+Pj4+Pj4gICAgICBJcyB0aGVyZSBhIGdvb2QgcmVhc29uIGZvciBu b3QgbWVyZ2luZyB0aGUgMiBkb2N1bWVudHM/IEkNCj4gaGF2ZQ0KPiA+Pj4+Pj4+IG5vdA0KPiA+ Pj4+PiBzZWVuDQo+ID4+Pj4+Pj4gICAgICBhbnkgZGlzY3Vzc2lvbiBvciBleHBsYW5hdGlvbiBv biB0aGlzLiBJIG1heSBoYXZlIG1pc3NlZCBpdC4NCj4gPj4+Pj4gUGxlYXNlDQo+ID4+Pj4+Pj4g ICAgICBjbGFyaWZ5IG9yLCBnaXZlIHNvbWUgcG9pbnRlcnMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g QXMgbWVudGlvbmVkIGluIHRoZSBpbnRyb2R1Y3Rpb246DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAg dGhpcyBtZW1vIGRlc2NyaWJlcyBtYW5hZ2VkIG9iamVjdHMgY29tbW9uIHRvIGJvdGggVlBMUw0K PiA+Pj4+Pj4gICAgTXVsdGljYXN0IFtSRkM3MTE3XSBhbmQgTVZQTiBbUkZDNjUxMywgUkZDNjUx NF0uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTVZQTi1NSUIgaXMgZm9yIE1WUE4uIFRoZXJlIHdhcyBh bm90aGVyIFZQTFMgTXVsdGljYXN0IE1JQiBpbiB0aGUNCj4gPj4+Pj4+IHdvcmsNCj4gPj4+Pj4g YW5kIGJvdGggd291bGQgcmVmZXJlbmNlIGNvbW1vbiBvYmplY3RzIGRlZmluZWQgaW4gdGhpcyBN SUIuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmtzIQ0KPiA+Pj4+Pj4gSmVmZnJleQ0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+IEZyb206 IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHbGVubg0K PiA+Pj4+Pj4+IE1hbnNmaWVsZA0KPiA+Pj4+Pj4+IEtlZW5pDQo+ID4+Pj4+Pj4gU2VudDogVHVl c2RheSwgQXByaWwgMTIsIDIwMTYgMjoyOCBBTQ0KPiA+Pj4+Pj4+IFRvOiBCZW5vaXQgQ2xhaXNl IDxiY2xhaXNlQGNpc2NvLmNvbT47IEVYVCAtDQo+ID4+Pj4+Pj4gdGhvbWFzLm1vcmluQG9yYW5n ZS5jb20NCj4gPj4+Pj4+PiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+DQo+ID4+Pj4+Pj4gQ2M6 IEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIDx6emhhbmdAanVuaXBlci5uZXQ+OyBvcHMtYWRzQGll dGYub3JnOw0KPiA+Pj4+PiBNYXJ0aW4NCj4gPj4+Pj4+PiBWaWdvdXJldXggPG1hcnRpbi52aWdv dXJldXhAbm9raWEuY29tPjsgYmVzc0BpZXRmLm9yZzsgTWFjaCBDaGVuDQo+ID4+Pj4+Pj4gPG1h Y2guY2hlbkBodWF3ZWkuY29tPg0KPiA+Pj4+Pj4+IFN1YmplY3Q6IFtiZXNzXSBNSUJEb2MgcmV2 aWV3IG9mDQo+ID4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZXNzLWwybDMtdnBuLW1jYXN0LW1pYi0NCj4g Pj4+Pj4gMDIudHh0DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBIaSwNCj4gPj4+Pj4+PiBJIGhhdmUg YmVlbiBhc2tlZCB0byBkbyBhIE1JQiBEb2N0b3JzIHJldmlldyBvZg0KPiA+Pj4+Pj4+IGRyYWZ0 LWlldGYtYmVzcy1sMmwzLXZwbi1tY2FzdC1taWItMDIudHh0Lg0KPiA+Pj4+Pj4+IE15IGtub3ds ZWRnZSBvZiBMMkwzVlBOIE11bHRpY2FzdCBpcyBsaW1pdGVkIHRvIHRoZSByZWFkaW5nDQo+ID4+ Pj4+Pj4gb2YgdGhpcyBkb2N1bWVudCBhbmQgYnJvd3NpbmcgdGhyb3VnaCB0aGUgZG9jdW1lbnRz IHJlZmVycmVkDQo+ID4+Pj4+Pj4gdG8gaW4gdGhlIGRyYWZ0IGFuZCBiZXNzLXdnIG1haWxpbmcg bGlzdCBhcmNoaXZlcy4oIHJlYWQNCj4gPj4+Pj4+PiAic2hhbGxvdyIpLg0KPiA+Pj4+Pj4+IFNv IHNvbWUgb2YgdGhlIGRvdWJ0cyBhbmQgcXVlc3Rpb25zIG1heSBzb3VuZCB0cml2aWFsIG9yDQo+ ID4+Pj4+Pj4gc3RyYW5nZS4gUGxlYXNlIGJlYXIgd2l0aCBtZSBhbmQgaGVscCBtZSBoZWxwIHlv dSBtYWtlDQo+ID4+Pj4+Pj4gdGhpcyBpbnRvIGEgYmV0dGVyIGRvY3VtZW50IDotKQ0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gVGhlIGNvbW1lbnRzIGFyZSBhdHRhY2hlZC4NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+IEdsZW5uDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gQkVTUyBtYWlsaW5n IGxpc3QNCj4gPj4+Pj4+IEJFU1NAaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmVzcw0KPiA+Pj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+Pj4gTUlCLURPQ1RPUlMgbWFpbGluZyBsaXN0DQo+ID4+PiBNSUIt RE9DVE9SU0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9taWItZG9jdG9ycw0KPiA+Pj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gTUlCLURPQ1RPUlMgbWFpbGluZyBsaXN0 DQo+ID4+IE1JQi1ET0NUT1JTQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWliLWRvY3RvcnMNCj4gPg0KPiA+IC4NCj4gPg0KDQo= From nobody Thu Oct 6 21:47:46 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA0712944C; Thu, 6 Oct 2016 21:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l09SPfCe2Vqs; Thu, 6 Oct 2016 21:47:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DAF129506; Thu, 6 Oct 2016 21:47:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D8DC2B8111A; Thu, 6 Oct 2016 21:47:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161007044742.D8DC2B8111A@rfc-editor.org> Date: Thu, 6 Oct 2016 21:47:42 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] RFC 7988 on Ingress Replication Tunnels in Multicast VPN X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 04:47:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7988 Title: Ingress Replication Tunnels in Multicast VPN Author: E. Rosen, Ed., K. Subramanian, Z. Zhang Status: Standards Track Stream: IETF Date: October 2016 Mailbox: erosen@juniper.net, karthik@sproute.com, zzhang@juniper.net Pages: 23 Characters: 55979 Updates: RFC 6513, RFC 6514 I-D Tag: draft-ietf-bess-ir-05.txt URL: https://www.rfc-editor.org/info/rfc7988 DOI: http://dx.doi.org/10.17487/RFC7988 RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. This document is a product of the BGP Enabled Services 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 Official Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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 nobody Fri Oct 7 18:19:36 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFFE1294DC; Fri, 7 Oct 2016 18:19:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147588957184.8979.9679990211419542360.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2016 18:19:31 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-df-election-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 01:19:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : A new Designated Forwarder Election for the EVPN Authors : Satya Ranjan Mohanty Keyur Patel Ali Sajassi John Drake Antoni Przygienda Filename : draft-ietf-bess-evpn-df-election-01.txt Pages : 15 Date : 2016-10-07 Abstract: This document describes an improved EVPN Designated Forwarder Election (DF) algorithm which can be used to enhance operational experience in terms of convergence speed and robustness over a WAN deploying EVPN The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-df-election-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 nobody Tue Oct 11 01:52:30 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE931297DC; Tue, 11 Oct 2016 01:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHPF2hHYFXtz; Tue, 11 Oct 2016 01:52:28 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0781297D0; Tue, 11 Oct 2016 01:52:28 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B88315D891D; Tue, 11 Oct 2016 10:52:26 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id B0D4B5D890E; Tue, 11 Oct 2016 10:52:26 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Tue, 11 Oct 2016 10:52:26 +0200 To: References: From: Thomas Morin Organization: Orange Message-ID: Date: Tue, 11 Oct 2016 10:52:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jorge Rabadan , draft-rabadan-bess-evpn-ac-df@ietf.org Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 08:52:30 -0000 Hi everyone, We have a new WG document. Authors, can you please repost as draft-ietf-bess-evpn-ac-df-00 ? Thanks in advance, -Thomas/Martin 2016-08-30, Thomas Morin: > Hello working group, > > This email starts a two-week poll on adopting > draft-rabadan-bess-evpn-ac-df-05 [1] as a Working Group document. > > Please state on the list if you support adoption or not (in both cases, > please also state the reasons). > > This poll runs until *September 14th*. > > We are also polling for knowledge of any undisclosed IPR that applies to > this document, 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 an author or contributor** of this document > please respond to this email and indicate whether or not you are aware > of any relevant undisclosed IPR. The document won't progress without > answers from all the authors and contributors. > > At this date, no IPR has been disclosed against this Document. > > If you 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 > bess chairs > > [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-ac-df > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Oct 11 02:02:47 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 069341297EE; Tue, 11 Oct 2016 02:02:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147617656602.32035.5888121750114238025.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 02:02:46 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-ac-df-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 09:02:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : AC-Influenced Designated Forwarder Election for EVPN Authors : Jorge Rabadan Kiran Nagaraj Senthil Sathappan Vinod Prabhu Wim Henderickx Autumn Liu Wen Lin Filename : draft-ietf-bess-evpn-ac-df-00.txt Pages : 10 Date : 2016-10-11 Abstract: The Designated Forwarder (DF) in EVPN networks is the PE responsible for sending multicast, broadcast and unknown unicast traffic to a multi-homed CE, on a given Ethernet Tag on a particular Ethernet Segment (ES). The DF is selected based on the list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network. While PE node or link failures trigger the DF re-election for a given , individual Attachment Circuit (AC) or MAC-VRF failures do not trigger such DF re-election and the traffic may therefore be permanently impacted, even though there is an alternative path. This document improves the DF election algorithm so that the AC status can influence the result of the election and this type of "logical" failures can be protected too. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ac-df/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-ac-df-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 nobody Tue Oct 11 08:01:05 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0012941C for ; Tue, 11 Oct 2016 08:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS2cuRtmwyg0 for ; Tue, 11 Oct 2016 08:01:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A00129605 for ; Tue, 11 Oct 2016 08:01:00 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0EFE2F96A1F8C for ; Tue, 11 Oct 2016 15:00:55 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9BF0vYN023940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Oct 2016 15:00:58 GMT 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 u9BF0v9I031582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Oct 2016 17:00:57 +0200 Received: from [135.224.203.10] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Oct 2016 17:00:57 +0200 Message-ID: <57FCFEA8.3070400@nokia.com> Date: Tue, 11 Oct 2016 17:00:56 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: BESS Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: [bess] Lack of implementation for draft-ietf-bess-virtual-subnet-fib-reduction - submit to IESG? X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 15:01:04 -0000 WG, we have recently LCed draft-ietf-bess-virtual-subnet-fib-reduction and there was sufficient support to move forward. However we haven't received any input on existing implementations. As per [1] we are thus asking the WG whether we should nevertheless move this to IESG or wait until implementations exist. Please respond. Thank you. M&T [1]: https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw From nobody Tue Oct 11 08:11:52 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA32D129602 for ; Tue, 11 Oct 2016 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWbCQ3POqEaL for ; Tue, 11 Oct 2016 08:11:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9929F12960C for ; Tue, 11 Oct 2016 08:11:46 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id CCD7BFDB92AF2 for ; Tue, 11 Oct 2016 15:11:41 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9BFBiKD008042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Oct 2016 15:11:45 GMT 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 u9BFBbZG025126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Oct 2016 17:11:44 +0200 Received: from [135.224.203.10] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Oct 2016 17:11:43 +0200 Message-ID: <57FD012F.4000307@nokia.com> Date: Tue, 11 Oct 2016 17:11:43 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <57B308FA.4090201@nokia.com> In-Reply-To: <57B308FA.4090201@nokia.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 15:11:51 -0000 WG there is support to adopt this document in BESS. *Important note* however, please be informed that we did not get responses, to the IPR question, from two Contributors. So, before we adopt this document I'd like to give you the opportunity to reflect on that and express your opinion on the way forward for this document. target deadline: 25th of October 2016 Thank you -m Le 16/08/2016 14:37, Martin Vigoureux a écrit : > Hello working group, > > This email starts a two-week poll on adopting > draft-zzhang-bess-evpn-bum-procedure-updates-03 [1] as a Working Group > Document. > > Please state on the list if you support adoption or not (in both cases, > please also state the reasons). > > This poll runs until *the 30th of August*. > > We are also polling for knowledge of any undisclosed IPR that applies > to this Document, 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 an Author or Contributor of this Document please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR. The Document won't progress without answers > from all the Authors and Contributors. > No IPR has been disclosed against this Document > > If you 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 > bess chairs > > [1] > https://datatracker.ietf.org/doc/draft-zzhang-bess-evpn-bum-procedure-updates/ > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > From nobody Tue Oct 11 19:22:50 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EAD12949F for ; Tue, 11 Oct 2016 19:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZBfvp6MVOlI for ; Tue, 11 Oct 2016 19:22:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E03129436 for ; Tue, 11 Oct 2016 19:22:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXZ03151; Wed, 12 Oct 2016 02:22:43 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 12 Oct 2016 03:22:40 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 12 Oct 2016 10:22:32 +0800 From: Lizhenbin To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 Thread-Index: AQHSI9HtLeoX/o6i2UKLziyI6bUfpKCkFv3w Date: Wed, 12 Oct 2016 02:22:31 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8D4E83D5@nkgeml514-mbx.china.huawei.com> References: <57B308FA.4090201@nokia.com> <57FD012F.4000307@nokia.com> In-Reply-To: <57FD012F.4000307@nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57FD9E73.0126, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 60b72c1f94bc4591c9fdb13726f47beb Archived-At: Subject: [bess] =?gb2312?b?tPC4tDogIFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16?= =?gb2312?b?emhhbmctYmVzcy1ldnBuLWJ1bS1wcm9jZWR1cmUtdXBkYXRlcy0wMw==?= X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 02:22:48 -0000 SGksDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uLiBBbmQgSSBhbSBub3QgYXdhcmUgb2YgYW55IElS UCByZWxhdGVkIHdpdGggdGhlIGRyYWZ0LlwNCg0KQmVzdCBSZWdhcmRzLA0KWmhlbmJpbiAoUm9i aW4pDQoNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogQkVTUyBbbWFpbHRvOmJlc3Mt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SBNYXJ0aW4gVmlnb3VyZXV4DQq3osvNyrG85DogMjAxNsTq MTDUwjExyNUgMjM6MTINCsrVvP7IyzogYmVzc0BpZXRmLm9yZw0K1vfM4jogUmU6IFtiZXNzXSBQ b2xsIGZvciBhZG9wdGlvbjogZHJhZnQtenpoYW5nLWJlc3MtZXZwbi1idW0tcHJvY2VkdXJlLXVw ZGF0ZXMtMDMNCg0KV0cNCg0KdGhlcmUgaXMgc3VwcG9ydCB0byBhZG9wdCB0aGlzIGRvY3VtZW50 IGluIEJFU1MuDQoNCipJbXBvcnRhbnQgbm90ZSogaG93ZXZlciwgcGxlYXNlIGJlIGluZm9ybWVk IHRoYXQgd2UgZGlkIG5vdCBnZXQgcmVzcG9uc2VzLCB0byB0aGUgSVBSIHF1ZXN0aW9uLCBmcm9t IHR3byBDb250cmlidXRvcnMuDQoNClNvLCBiZWZvcmUgd2UgYWRvcHQgdGhpcyBkb2N1bWVudCBJ J2QgbGlrZSB0byBnaXZlIHlvdSB0aGUgb3Bwb3J0dW5pdHkgdG8gcmVmbGVjdCBvbiB0aGF0IGFu ZCBleHByZXNzIHlvdXIgb3BpbmlvbiBvbiB0aGUgd2F5IGZvcndhcmQgZm9yIHRoaXMgZG9jdW1l bnQuDQoNCnRhcmdldCBkZWFkbGluZTogMjV0aCBvZiBPY3RvYmVyIDIwMTYNCg0KVGhhbmsgeW91 DQotbQ0KDQpMZSAxNi8wOC8yMDE2IDE0OjM3LCBNYXJ0aW4gVmlnb3VyZXV4IGEgqKZjcml0IDoN Cj4gSGVsbG8gd29ya2luZyBncm91cCwNCj4NCj4gVGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2Vl ayBwb2xsIG9uIGFkb3B0aW5nDQo+IGRyYWZ0LXp6aGFuZy1iZXNzLWV2cG4tYnVtLXByb2NlZHVy ZS11cGRhdGVzLTAzIFsxXSBhcyBhIFdvcmtpbmcgR3JvdXAgDQo+IERvY3VtZW50Lg0KPg0KPiBQ bGVhc2Ugc3RhdGUgb24gdGhlIGxpc3QgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3Igbm90IChp biBib3RoIA0KPiBjYXNlcywgcGxlYXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KPg0KPiBU aGlzIHBvbGwgcnVucyB1bnRpbCAqdGhlIDMwdGggb2YgQXVndXN0Ki4NCj4NCj4gV2UgYXJlIGFs c28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSB1bmRpc2Nsb3NlZCBJUFIgdGhhdCBhcHBs aWVzIA0KPiB0byB0aGlzIERvY3VtZW50LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2UgDQo+IHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgDQo+IGRldGFpbHMpLg0KPiBJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhbiBBdXRob3Igb3IgQ29udHJpYnV0b3Igb2YgdGhpcyBEb2N1bWVudCBw bGVhc2UgDQo+IHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBu b3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgDQo+IHJlbGV2YW50IHVuZGlzY2xvc2VkIElQUi4gVGhl IERvY3VtZW50IHdvbid0IHByb2dyZXNzIHdpdGhvdXQgYW5zd2VycyANCj4gZnJvbSBhbGwgdGhl IEF1dGhvcnMgYW5kIENvbnRyaWJ1dG9ycy4NCj4gTm8gSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBh Z2FpbnN0IHRoaXMgRG9jdW1lbnQNCj4NCj4gSWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIEF1 dGhvciBvciBDb250cmlidXRvciwgdGhlbiBwbGVhc2UgDQo+IGV4cGxpY2l0bHkgcmVzcG9uZCBv bmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IA0KPiBiZWVu IGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQo+DQo+IFRoYW5rIHlv dQ0KPg0KPiBNYXJ0aW4gJiBUaG9tYXMNCj4gYmVzcyBjaGFpcnMNCj4NCj4gWzFdDQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXp6aGFuZy1iZXNzLWV2cG4tYnVtLXBy b2NlZHVyZS0NCj4gdXBkYXRlcy8NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gQkVTUyBtYWlsaW5nIGxpc3QNCj4gQkVTU0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCj4NCj4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJFU1MgbWFp bGluZyBsaXN0DQpCRVNTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Jlc3MNCg== From nobody Thu Oct 13 02:38:04 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4D012970F for ; Thu, 13 Oct 2016 02:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGbFSgx0U8YJ for ; Thu, 13 Oct 2016 02:38:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90839127076 for ; Thu, 13 Oct 2016 02:37:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTC46062; Thu, 13 Oct 2016 09:37:56 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Oct 2016 10:37:55 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 13 Oct 2016 17:37:51 +0800 From: Xuxiaohu To: Martin Vigoureux , BESS Thread-Topic: [bess] Lack of implementation for draft-ietf-bess-virtual-subnet-fib-reduction - submit to IESG? Thread-Index: AQHSI9CAMxhRpI49lkaEqAUVJVjcm6CmG3yA Date: Thu, 13 Oct 2016 09:37:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21BE1@NKGEML515-MBX.china.huawei.com> References: <57FCFEA8.3070400@nokia.com> In-Reply-To: <57FCFEA8.3070400@nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57FF55F5.0007, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 574c18ad15d43dabb6684189f0c9ef3b Archived-At: Subject: [bess] =?gb2312?b?tPC4tDogIExhY2sgb2YgaW1wbGVtZW50YXRpb24gZm9y?= =?gb2312?b?IGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC1maWItcmVkdWN0aW9u?= =?gb2312?b?IC0gc3VibWl0IHRvIElFU0c/?= X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 09:38:03 -0000 SGkgTWFydGluLA0KDQpXZSBoYXZlIGp1c3QgaW1wbGVtZW50ZWQgUkZDNzgxNCBhIGNvdXBsZSBv ZiBtb250aHMgYmVmb3JlIGluIHJlc3BvbnNlIHRvIHRoZSBkZW1hbmRzIG9mIHNvbWUgb2Ygb3Vy IGN1c3RvbWVycywgYW5kIHRob3NlIGN1c3RvbWVycyBoYXZlIGRlcGxveWVkIHRoaXMgTDMtYmFz ZWQgb3ZlcmxheSB0ZWNobm9sb2d5IHdpdGhpbiB0aGVpciBoeXBlci1zY2FsZSBjbG91ZCBkYXRh IGNlbnRlciBuZXR3b3JrIGVudmlyb25tZW50IHJlY2VudGx5LiBXZSBhcmUgcGxhbm5pbmcgdG8g aW1wbGVtZW50IGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC1maWItcmVkdWN0aW9uIGlu IHRoZSBuZXh0IHN0ZXAuDQoNCkkgaGF2ZSBqdXN0IG5vdGljZWQgdGhlIGZvbGxvd2luZyBzdGF0 ZW1lbnQgZnJvbSAoaHR0cHM6Ly93d3cucmF2ZWxsb3N5c3RlbXMuY29tL2Jsb2cvY2xvdWQtbmV0 d29ya2luZy1sYXllci0yLWFjY2Vzcy1hbWF6b24tZWMyLyk6DQoNCiIuLi4gQWxsIG1ham9yIGNs b3VkcywgaW5jbHVkaW5nIEFtYXpvbiBFQzIsIEFtYXpvbiBWUEMsIEdvb2dsZSBDb21wdXRlIEVu Z2luZSBhbmQgTWljcm9zb2Z0IEF6dXJlLCBhbGxvdyBvbmx5IHVuaWNhc3QgZGF0YWdyYW1zIHdp dGggSVAgcGF5bG9hZHMuIEJyb2FkY2FzdCBkYXRhZ3JhbXMgYW5kIG5vbi1JUCBwYXlsb2FkcyBh cmUgbm90IGFsbG93ZWQgKHdpdGggdmVyeSBsaW1pdGVkIGV4Y2VwdGlvbnMgdG8gbWFrZSBwYXJ0 cyBvZiB0aGUgZXNzZW50aWFsIEFSUCBhbmQgREhDUCBwcm90b2NvbHMgd29yaykuICINCg0KSU1I Tywgd2hlbiB0aGUgTDMgb3ZlcmxheSB0ZWNobm9sb2d5IGlzIG1vcmUgd2lkZWx5IGRlcGxveWVk IGluIGh5cGVyLXNjYWxlIGRhdGEgY2VudGVycywgdGhlIG9uLWRlbWFuZCBGSUIgaW5zdGFsbGF0 aW9uIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1iZXNzLXZpcnR1YWwtc3Vi bmV0LWZpYi1yZWR1Y3Rpb24gd291bGQgYmVjb21lIHNpZ25pZmljYW50bHkgaW1wb3J0YW50IHRv IHRoZSBvcGVyYXRvcnMgb2YgdGhvc2UgaHlwZXItc2NhbGUgZGF0YSBjZW50ZXJzIC4gT25jZSB0 aGlzIG1lY2hhbmlzbSBiZWNvbWVzIGFuIElFVEYgc3RhbmRhcmQsIHRob3NlIG9wZXJhdG9ycyB3 b3VsZCBhc2sgdGhlaXIgdmVuZG9ycyB0byBpbXBsZW1lbnQgaXQuIEluIGZhY3QsIHRoaXMgaXMg dGhlIGNhc2Ugb2Ygb3VyIGltcGxlbWVudGF0aW9uIG9mIFJGQzc4MTQuIEhlbmNlLCBJIHN0cm9u Z2x5IHN1Z2dlc3QgdG8gbW92ZSB0aGlzIHRvIElFU0cuDQoNCkJUVywgc2luY2UgaXQgaGFzIGJl Y29tZSBhIGZhY3QgdGhhdCB2YXJpb3VzIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiBzY2hlbWVz IGNvdWxkIGJlIHVzZWQgZm9yIHRoZSBMM1ZQTiBzb2x1dGlvbiwgaGVuY2UgSSB3b25kZXIgd2hl dGhlciB0aGUgaW1wbGVtZW50YXRpb24gb2YgTDMgQ29udmVyc2F0aW9uYWwgTGVhcm5pbmcgb2Yg REZBIGFzIGRlc2NyaWJlZCBvbiBwYWdlIDM2IG9mIChodHRwOi8vd3d3LnZhbGxleXRhbGsub3Jn L3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDEzLzA4L2Npc2NvREZBLnBkZikgY291bGQgYmUgbG9va2Vk IGFzIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uOikNCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogQkVTUyBbbWFpbHRvOmJlc3MtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBNYXJ0aW4gVmlnb3VyZXV4DQo+ILeiy83KsbzkOiAyMDE2xOox MNTCMTHI1SAyMzowMQ0KPiDK1bz+yMs6IEJFU1MNCj4g1vfM4jogW2Jlc3NdIExhY2sgb2YgaW1w bGVtZW50YXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtYmVzcy12aXJ0dWFsLXN1Ym5ldC1maWItcmVk dWN0aW9uIC0gc3VibWl0IHRvIElFU0c/DQo+IA0KPiBXRywNCj4gDQo+IHdlIGhhdmUgcmVjZW50 bHkgTENlZCBkcmFmdC1pZXRmLWJlc3MtdmlydHVhbC1zdWJuZXQtZmliLXJlZHVjdGlvbiBhbmQg dGhlcmUgd2FzDQo+IHN1ZmZpY2llbnQgc3VwcG9ydCB0byBtb3ZlIGZvcndhcmQuIEhvd2V2ZXIg d2UgaGF2ZW4ndCByZWNlaXZlZCBhbnkgaW5wdXQgb24NCj4gZXhpc3RpbmcgaW1wbGVtZW50YXRp b25zLg0KPiANCj4gQXMgcGVyIFsxXSB3ZSBhcmUgdGh1cyBhc2tpbmcgdGhlIFdHIHdoZXRoZXIg d2Ugc2hvdWxkIG5ldmVydGhlbGVzcyBtb3ZlIHRoaXMNCj4gdG8gSUVTRyBvciB3YWl0IHVudGls IGltcGxlbWVudGF0aW9ucyBleGlzdC4NCj4gDQo+IFBsZWFzZSByZXNwb25kLiBUaGFuayB5b3Uu DQo+IA0KPiANCj4gTSZUDQo+IA0KPiBbMV06DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvYmVzcy9jRzNYMXRUcWJfdlBDNHJnNTZTRWRranFEcHcNCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJFU1MgbWFpbGlu ZyBsaXN0DQo+IEJFU1NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9iZXNzDQo= From nobody Tue Oct 18 01:28:32 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94421298AA for ; Tue, 18 Oct 2016 01:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyKCwLEVKqvU for ; Tue, 18 Oct 2016 01:28:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EA3129883 for ; Tue, 18 Oct 2016 01:28:27 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 009847F75C66B for ; Tue, 18 Oct 2016 08:28:24 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9I8SPCQ010423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Oct 2016 08:28:25 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9I8S09v004999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Oct 2016 10:28:24 +0200 Received: from [135.224.207.194] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 18 Oct 2016 10:28:15 +0200 Message-ID: <5805DD1E.4000400@nokia.com> Date: Tue, 18 Oct 2016 10:28:14 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "bess@ietf.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] Archived-At: Subject: [bess] Slots requests for BESS WG session - IETF 97 - Seoul X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 08:28:30 -0000 All, it is time we start building the BESS WG agenda for Seoul. The IETF agenda is available at: https://datatracker.ietf.org/meeting/97/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Monday, 14th of November, Afternoon session I 13:30-15:30 (local time) Please send us your request for a presentation slot, indicating draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 30th of October. Thank you M&T From nobody Tue Oct 18 04:04:59 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A561295EE for ; Tue, 18 Oct 2016 04:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3beEGyJms-X for ; Tue, 18 Oct 2016 04:04:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4979A12940B for ; Tue, 18 Oct 2016 04:04:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYK55145; Tue, 18 Oct 2016 11:04:51 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 18 Oct 2016 12:04:48 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 18 Oct 2016 19:04:44 +0800 From: Zhangjunlin To: "martin.vigoureux@nokia.com" Thread-Topic: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 Thread-Index: AQHSKS9uDWpoGnue2EiWxJi+n2FJJg== Date: Tue, 18 Oct 2016 11:04:43 +0000 Message-ID: <5D43198FB8818F46B1464F1862F7A525AA253422@NKGEML515-MBX.china.huawei.com> References: <19AB2A007F56DB4E8257F949A2FB9858C879C540@NKGEML515-MBX.china.huawei.com> In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858C879C540@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.167.10] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.580601D4.01CD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1b9873a4c2b6e2b4d5d678b1d7ba8933 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 11:04:58 -0000 SGksDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uLiBBbmQgSSBhbSBub3QgYXdhcmUgb2YgYW55IElS UCByZWxhdGVkIHdpdGggdGhlIGRyYWZ0Lg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBCRVNTIFttYWlsdG86YmVzcy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE1hcnRpbiBWaWdvdXJl dXgNCreiy83KsbzkOiAyMDE2xOoxMNTCMTHI1SAyMzoxMg0KytW8/sjLOiBiZXNzQGlldGYub3Jn DQrW98ziOiBSZTogW2Jlc3NdIFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16emhhbmctYmVzcy1l dnBuLWJ1bS1wcm9jZWR1cmUtdXBkYXRlcy0wMw0KDQpXRw0KDQp0aGVyZSBpcyBzdXBwb3J0IHRv IGFkb3B0IHRoaXMgZG9jdW1lbnQgaW4gQkVTUy4NCg0KKkltcG9ydGFudCBub3RlKiBob3dldmVy LCBwbGVhc2UgYmUgaW5mb3JtZWQgdGhhdCB3ZSBkaWQgbm90IGdldCByZXNwb25zZXMsIHRvIHRo ZSBJUFIgcXVlc3Rpb24sIGZyb20gdHdvIENvbnRyaWJ1dG9ycy4NCg0KU28sIGJlZm9yZSB3ZSBh ZG9wdCB0aGlzIGRvY3VtZW50IEknZCBsaWtlIHRvIGdpdmUgeW91IHRoZSBvcHBvcnR1bml0eSB0 byByZWZsZWN0IG9uIHRoYXQgYW5kIGV4cHJlc3MgeW91ciBvcGluaW9uIG9uIHRoZSB3YXkgZm9y d2FyZCBmb3IgdGhpcyBkb2N1bWVudC4NCg0KdGFyZ2V0IGRlYWRsaW5lOiAyNXRoIG9mIE9jdG9i ZXIgMjAxNg0KDQpUaGFuayB5b3UNCi1tDQoNCkxlIDE2LzA4LzIwMTYgMTQ6MzcsIE1hcnRpbiBW aWdvdXJldXggYSCopmNyaXQgOg0KPiBIZWxsbyB3b3JraW5nIGdyb3VwLA0KPg0KPiBUaGlzIGVt YWlsIHN0YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gYWRvcHRpbmcNCj4gZHJhZnQtenpoYW5nLWJl c3MtZXZwbi1idW0tcHJvY2VkdXJlLXVwZGF0ZXMtMDMgWzFdIGFzIGEgV29ya2luZyBHcm91cCAN Cj4gRG9jdW1lbnQuDQo+DQo+IFBsZWFzZSBzdGF0ZSBvbiB0aGUgbGlzdCBpZiB5b3Ugc3VwcG9y dCBhZG9wdGlvbiBvciBub3QgKGluIGJvdGggDQo+IGNhc2VzLCBwbGVhc2UgYWxzbyBzdGF0ZSB0 aGUgcmVhc29ucykuDQo+DQo+IFRoaXMgcG9sbCBydW5zIHVudGlsICp0aGUgMzB0aCBvZiBBdWd1 c3QqLg0KPg0KPiBXZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IHVuZGlz Y2xvc2VkIElQUiB0aGF0IGFwcGxpZXMgDQo+IHRvIHRoaXMgRG9jdW1lbnQsIHRvIGVuc3VyZSB0 aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSANCj4gd2l0aCBJRVRGIElQ UiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSANCj4g ZGV0YWlscykuDQo+IElmIHlvdSBhcmUgbGlzdGVkIGFzIGFuIEF1dGhvciBvciBDb250cmlidXRv ciBvZiB0aGlzIERvY3VtZW50IHBsZWFzZSANCj4gcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBp bmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSANCj4gcmVsZXZhbnQg dW5kaXNjbG9zZWQgSVBSLiBUaGUgRG9jdW1lbnQgd29uJ3QgcHJvZ3Jlc3Mgd2l0aG91dCBhbnN3 ZXJzIA0KPiBmcm9tIGFsbCB0aGUgQXV0aG9ycyBhbmQgQ29udHJpYnV0b3JzLg0KPiBObyBJUFIg aGFzIGJlZW4gZGlzY2xvc2VkIGFnYWluc3QgdGhpcyBEb2N1bWVudA0KPg0KPiBJZiB5b3UgYXJl IG5vdCBsaXN0ZWQgYXMgYW4gQXV0aG9yIG9yIENvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSANCj4g ZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg aGFzIG5vdCB5ZXQgDQo+IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBy dWxlcy4NCj4NCj4gVGhhbmsgeW91DQo+DQo+IE1hcnRpbiAmIFRob21hcw0KPiBiZXNzIGNoYWly cw0KPg0KPiBbMV0NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtenpo YW5nLWJlc3MtZXZwbi1idW0tcHJvY2VkdXJlLQ0KPiB1cGRhdGVzLw0KPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBCRVNTIG1haWxpbmcg bGlzdA0KPiBCRVNTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYmVzcw0KPg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KQkVTUyBtYWlsaW5nIGxpc3QNCkJFU1NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVzcw0K From nobody Tue Oct 18 04:07:16 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4A3129A01 for ; Tue, 18 Oct 2016 04:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPMQlCk5Yagu for ; Tue, 18 Oct 2016 04:07:13 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9BB12946D for ; Tue, 18 Oct 2016 04:07:13 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 3EB1B5429959C for ; Tue, 18 Oct 2016 11:07:09 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9IB7ABj025042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Oct 2016 11:07:11 GMT 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 u9IB7AeJ031495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Oct 2016 13:07:10 +0200 Received: from [135.224.215.175] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 18 Oct 2016 13:07:10 +0200 Message-ID: <5806025D.50303@nokia.com> Date: Tue, 18 Oct 2016 13:07:09 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <57B308FA.4090201@nokia.com> In-Reply-To: <57B308FA.4090201@nokia.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 11:07:15 -0000 WG, we have now all the IPR answers and support for adopting the document. Authors, please republish as draft-ietf-bess-evpn-bum-procedure-updates-00 Thank you -m Le 16/08/2016 14:37, Martin Vigoureux a écrit : > Hello working group, > > This email starts a two-week poll on adopting > draft-zzhang-bess-evpn-bum-procedure-updates-03 [1] as a Working Group > Document. > > Please state on the list if you support adoption or not (in both cases, > please also state the reasons). > > This poll runs until *the 30th of August*. > > We are also polling for knowledge of any undisclosed IPR that applies > to this Document, 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 an Author or Contributor of this Document please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR. The Document won't progress without answers > from all the Authors and Contributors. > No IPR has been disclosed against this Document > > If you 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 > bess chairs > > [1] > https://datatracker.ietf.org/doc/draft-zzhang-bess-evpn-bum-procedure-updates/ > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > From nobody Tue Oct 18 06:46:40 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA62B129A6B; Tue, 18 Oct 2016 06:46:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147679839472.30843.5809335209552066562.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 06:46:34 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-bum-procedure-updates-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 13:46:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Updates on EVPN BUM Procedures Authors : Zhaohui Zhang Wen Lin Jorge Rabadan Keyur Patel Filename : draft-ietf-bess-evpn-bum-procedure-updates-00.txt Pages : 16 Date : 2016-10-18 Abstract: This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-bum-procedure-updates-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 nobody Wed Oct 19 14:12:56 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5A1296DA; Wed, 19 Oct 2016 14:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyRFrUs-av2i; Wed, 19 Oct 2016 14:12:48 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CFB128E18; Wed, 19 Oct 2016 14:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24427; q=dns/txt; s=iport; t=1476911568; x=1478121168; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/EXzgwI1iunbS8BX11b/wDm0r7/RSl4e2EKZ4YTGTeo=; b=LNGTi4gcLXNOPr0z8h17pkKjKYojtFuDUdIw8QeuW5qTeOahGKwgnQZZ oanrhARQwPsCJmiWFgvz3S6IGCj0/FjSVhAkArXZsvDbZrm6sIixK1yFZ 3gRIPcF3wpJW5ePuNsC/opqZxBQW1+yyPKvDhifX0Q+LdY9ULH5vAyDxK I=; X-Files: =?utf-8?b?T3V0bG9va0Vtb2ppLfCfmIoucG5nIDogNDg4?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQCQ4AdY/4QNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgwg2AQEBAQEdgVQHjS2We5EhgxqCCIYhAhqBZz8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQQFHmYCAQgRAwECBgEBAR8DAgICFQEODBQJCAIEAREBBggNiDe2b40LA?= =?us-ascii?q?QEBAQEBAQECAQEBAQEBARIOig2BBYRngmSCWwWMP4dzhVsBg0CBeYpQgW6EaYM?= =?us-ascii?q?3hWuMfoN/AR42VYMKF4FTcoc9gQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,516,1473120000"; d="png'150?scan'150,208,217,150";a="337866022" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2016 21:12:47 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u9JLClh5030441 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Oct 2016 21:12:47 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 17:12:46 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Wed, 19 Oct 2016 17:12:46 -0400 From: "Ali Sajassi (sajassi)" To: Keyur Patel , "bess-chairs@ietf.org" , "bess@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [bess] RTG Dir QA review: draft-ietf-bess-evpn-overlay-04.txt Thread-Index: AQHSB8Gs2FQD5hIOJ0qWQD+BeJeuuKCwWUKA Date: Wed, 19 Oct 2016 21:12:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/mixed; boundary="_004_D42D04451BE68Esajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] RTG Dir QA review: draft-ietf-bess-evpn-overlay-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 21:12:50 -0000 --_004_D42D04451BE68Esajassiciscocom_ Content-Type: multipart/alternative; boundary="_000_D42D04451BE68Esajassiciscocom_" --_000_D42D04451BE68Esajassiciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpLZXl1ciwNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXcuIFBsZWFzZSByZWZl ciB0byB0aGUgY29tbWVudCByZXNvbHV0aW9ucyBiZWxvdyBhbmQgbGV0IHVzIGtub3cgaWYgdGhl cmUgYXJlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLg0KDQpGcm9tOiBCRVNTIDxiZXNzLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmJlc3MtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBLZXl1 ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbTxtYWlsdG86a2V5dXJAYXJyY3VzLmNvbT4+DQpEYXRl OiBNb25kYXksIFNlcHRlbWJlciA1LCAyMDE2IGF0IDM6MzQgUE0NClRvOiAiYmVzcy1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOmJlc3MtY2hhaXJzQGlldGYub3JnPiIgPGJlc3MtY2hhaXJzQGlldGYu b3JnPG1haWx0bzpiZXNzLWNoYWlyc0BpZXRmLm9yZz4+LCAiYmVzc0BpZXRmLm9yZzxtYWlsdG86 YmVzc0BpZXRmLm9yZz4iIDxiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPj4sICJy dGctZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPiIgPHJ0Zy1kaXJAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW2Jlc3NdIFJURyBEaXIgUUEg cmV2aWV3OiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LTA0LnR4dA0KDQoNCkhlbGxvLA0K DQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBRQSByZXZp ZXdlciBmb3IgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheS0wNC50eHQuDQoNCg0KVGhlIFJv dXRpbmcgRGlyZWN0b3JhdGUgUUEgcmV2aWV3cyBhcmUgaW50ZW5kZWQgdG8gYmUgYSBzdXBwb3J0 IHRvIGltcHJvdmUgdGhlIHF1YWxpdHkgb2YgUlRHIEFyZWEgZG9jdW1lbnRzIGFzIHRoZXkgcGFz cyB0aHJvdWdoIHRoZSBJRVRGIHByb2Nlc3MuIFRoaXMgaXMgdGhlIFFBIHJldmlldyBhdCB0aGUg dGltZSBvZiB0aGUgV0cgZG9jdW1lbnQgYWRvcHRpb24gcG9sbC4NCg0KDQpTdW1tYXJ5Og0KDQoN ClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBFdGhlcm5ldCBWUE4gKEVWUE4pIFtSRkM3NDMy XSBjYW4gYmUgdXNlZCBhcyBhIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gT3ZlcmxheSAoTlZPKSBz b2x1dGlvbiBhbmQgZXhwbG9yZXMgdGhlIHZhcmlvdXMgdHVubmVsIGVuY2Fwc3VsYXRpb24gb3B0 aW9ucyBvdmVyIElQIGFuZCB0aGVpciBpbXBhY3Qgb24gdGhlIEVWUE4gY29udHJvbC1wbGFuZSBh bmQgcHJvY2VkdXJlcy4gSW4gcGFydGljdWxhciwgdGhlIGZvbGxvd2luZyBlbmNhcHN1bGF0aW9u IG9wdGlvbnMgYXJlIGFuYWx5emVkOiBWWExBTiwgTlZHUkUsIGFuZCBNUExTIG92ZXIgR1JFLg0K DQoNCg0KVGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiwgZWFzeSB0byByZWFkIGFuZCBmb2xs b3cuIFNvbWUgbWlub3IgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxvdzoNCg0KDQpDb21tZW50czoN Cg0KDQoxKSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBzdWdnZXN0cyB4bXBwIGJhc2VkIGFwcHJvYWNo IGFzIGFuIGFsdGVybmF0aXZlIHRvIHRoZSBCR1AgYXMgYSBjb250cm9sIHBsYW5lLiBJdCBpcyB1 bmNsZWFyIGhvdyB0aGUgZHJhZnQgc2VjdGlvbnMgOC0xMCBhbmQgdGhlIHNlY3VyaXR5IHNlY3Rp b24gMTIgcmVsYXRlIHRvIHRoZSBhbHRlcm5hdGl2ZSBzb2x1dGlvbi4gTXkgc3VnZ2VzdGlvbiB3 b3VsZCBiZSB0byByZW1vdmUgdGhlIHJlZmVyZW5jZSBpZiBwb3NzaWJsZSBjb25zaWRlcmluZyB0 aGUgZHJhZnQgaXMgc3BlY2lmaWMgdG8gQkdQIGFzIGEgY29udHJvbCBwbGFuZS4NCg0KQWdyZWVk LiBJIHdpbGwgcmVtb3ZlIGl0Lg0KDQoNCjIpIFNlY3Rpb24gNS4xLjIuMSBkZWZpbmVzIEF1dG9k ZXJpdmF0aW9uIFJUIHdoaWNoIHN1Z2dlc3RzIHRoZSB1c2Ugb2YgMiBieXRlIEFTIG51bWJlci4g RG8gd2UgbmVlZCB0byBjb25zaWRlciA0IGJ5dGUgQVMgbnVtYmVyIGFzIHdlbGw/IFs/P10NCg0K Tm8sIEF1dG8tZGVyaXZhdGlvbiBvZiBSVCB3aWxsIG5vdCBiZSBzdXBwb3J0ZWQgZm9yIDQtYnl0 ZSBBUy4NCg0KDQozKSBTZWN0aW9uIDY6IE1pbm9yIE5pdC4gQ29uc2lkZXIgcmVwbGFjaW5nICJz dGF0aWNhbGx5IiB3aXRoICJsb2NhbGx5Ii4NCg0KRG9uZS4NCg0KDQo0KSBTZWN0aW9uIDcuMTog VGFsa3MgYWJvdXQgdXNpbmcgUkQgdmFsdWUgb2YgMC4gUkQgYXMgYSB0eXBlOnZhbHVlIGZpZWxk LiBUeXBlIDAgUkQgcmVxdWlyZXMgdGhlIHVzYWdlIG9mIDIgYnl0ZSBBUyBudW1iZXIgKHByaXZh dGUgdmFsdWVzIGFyZSBzdHJvbmdseSBkaXNjb3VyYWdlZCkgd2hpY2ggbmVlZHMgdG8gYmUgMCBm b3IgUkQgdmFsdWUgdG8gYmUgMC4gQVMgMCBhY2NvcmRpbmcgdG8gSUFOQSBpcyByZXNlcnZlZC4g U2VlbXMgdG8gYmUgbGlrZSB1c2FnZSBvZiBBUyAwIGlzIHByb2hpYml0ZWQuIFdvdWxkIGEgcmVz ZXJ2ZSBSRCB2YWx1ZSBiZSBtb3JlIGFwcHJvcHJpYXRlPw0KDQpTaW5jZSB0aGUgcmVjb21tZW5k YXRpb24gaXMgdG8gdXNlIGEgdW5pcXVlIFJEIHZhbHVlIHBlciBSRkM3NDMyLCB0aGUgdGV4dCBj b3JyZXNwb25kaW5nIHRvIFJEIHZhbHVlIG9mIDAgaXMgcmVtb3ZlZC4NCg0KDQo1KSBzZWN0aW9u IDguMy4xIGRlc2NyaWJlcyB0aGUgZHJhZnQgY29uc3RyYWluIHdydCBtcGxzIG92ZXIgZ3JlIHZl cnN1cyB2eGxhbi9udmdyZS4gUGVyaGFwcyBpdCB3b3VsZCBiZSBncmVhdCB0byBoaWdobGlnaHQg dGhlIGNvbnN0cmFpbiB1cGZyb250IGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbj8NCg0KT0su IFdlIGhpZ2hsaWdodGVkIHRoaXMgY29uc3RyYWluIHVwZnJvbnQgaW4gc2VjdGlvbiA4Lg0KDQoN CjYpIERvIHlvdSBuZWVkIHRvIGFkZCB0ZXh0IHRvIGRlc2NyaWJlIEFSUC9ORCBzdXBwcmVzc2lv biBpbiBwcmVzZW5jZSBvZiBkZWZhdWx0IHJvdXRlPw0KDQpUaGF0IGlzIGNvdmVyZWQgaW4gbW9y ZSBkZXB0aCBpbiBzb21lIG90aGVyIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KQWxpDQoNCg0KQmVzdCBS ZWdhcmRzLA0KDQpLZXl1cg0K --_000_D42D04451BE68Esajassiciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <626CA3768FB24D479D839E314A62F9B0@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0K PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+PGZvbnQgY29sb3I9IiNmZjAwMDAiPktleXVyLDwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+PGJyPg0KPC9mb250PjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPjxmb250IGNvbG9yPSIjZmYwMDAwIj5UaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJl dmlldy4gUGxlYXNlIHJlZmVyIHRvIHRoZSBjb21tZW50IHJlc29sdXRpb25zIGJlbG93IGFuZCBs ZXQgdXMga25vdyBpZiB0aGVyZSBhcmUgYW55IGZ1cnRoZXIgY29tbWVudHMuPC9mb250PjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpMdWNpZGEgR3JhbmRlOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5CRVNTICZsdDs8YSBocmVmPSJtYWlsdG86YmVzcy1i b3VuY2VzQGlldGYub3JnIj5iZXNzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYg b2YgS2V5dXIgUGF0ZWwgJmx0OzxhIGhyZWY9Im1haWx0bzprZXl1ckBhcnJjdXMuY29tIj5rZXl1 ckBhcnJjdXMuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RGF0ZTogPC9zcGFuPk1vbmRheSwgU2VwdGVtYmVyIDUsIDIwMTYgYXQgMzozNCBQTTxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1h aWx0bzpiZXNzLWNoYWlyc0BpZXRmLm9yZyI+YmVzcy1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86YmVzcy1jaGFpcnNAaWV0Zi5vcmciPmJlc3MtY2hhaXJzQGll dGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIj5iZXNz QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJl c3NAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWRpckBpZXRm Lm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGct ZGlyQGlldGYub3JnIj5ydGctZGlyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltiZXNzXSBSVEcgRGlyIFFBIHJldmll dzogZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheS0wNC50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9ImRpc3BsYXk6 bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0tPjwvc3R5bGU+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBzdHlsZT0i Zm9udC1zaXplOjEycHQ7Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5kLWNvbG9yOiNGRkZGRkY7Zm9u dC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiPg0KPHByZSBjbGFz cz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsg cGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVy IE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsg dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsiPkhlbGxvLA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91 dGluZyBEaXJlY3RvcmF0ZSBRQSByZXZpZXdlciBmb3IgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MWVtOyBmb250LXdlaWdodDogYm9sZDsiPmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXktMDQu dHh0Ljwvc3Bhbj48YnI+DQoNClRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIFFBIHJldmlld3MgYXJl IGludGVuZGVkIHRvIGJlIGEgc3VwcG9ydCB0byBpbXByb3ZlIHRoZSBxdWFsaXR5IG9mIFJURyBB cmVhIGRvY3VtZW50cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCB0aGUgSUVURiBwcm9jZXNzLiBUaGlz IGlzIHRoZSBRQSByZXZpZXcgYXQgdGhlIHRpbWUgb2YgdGhlIFdHIGRvY3VtZW50IGFkb3B0aW9u IHBvbGwuPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBmb250LWZh bWlseTogQ291cmllciwgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7 IGxpbmUtaGVpZ2h0OiBpbmhlcml0OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PGJyPjwvcHJlPg0KPHByZSBj bGFzcz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw eDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3Vy aWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJp dDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQt d3JhcDogYnJlYWstd29yZDsiPlN1bW1hcnk6PC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIg c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWRkaW5nOiAwcHg7 IGJvcmRlcjogMHB4OyBmb250LWZhbWlseTogQ291cmllciwgJ0NvdXJpZXIgTmV3JywgbW9ub3Nw YWNlOyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBpbmhlcml0OyB2ZXJ0aWNhbC1hbGln bjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3Jk OyI+PGJyPjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1m YW1pbHk6IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4 OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1z cGFjZTogcHJlLXdyYXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPlRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGhvdyBFdGhlcm5ldCBWUE4gKEVWUE4pIFtSRkM3NDMyXSBjYW4gYmUgdXNlZCBhcyBh IE5ldHdvcmsgVmlydHVhbGl6YXRpb24gT3ZlcmxheSAoTlZPKSBzb2x1dGlvbiBhbmQgZXhwbG9y ZXMgdGhlIHZhcmlvdXMgdHVubmVsIGVuY2Fwc3VsYXRpb24gb3B0aW9ucyBvdmVyIElQIGFuZCB0 aGVpciBpbXBhY3Qgb24gdGhlIEVWUE4gY29udHJvbC1wbGFuZSBhbmQgcHJvY2VkdXJlcy4gSW4g cGFydGljdWxhciwgdGhlIGZvbGxvd2luZyBlbmNhcHN1bGF0aW9uIG9wdGlvbnMgYXJlIGFuYWx5 emVkOiBWWExBTiwgTlZHUkUsIGFuZCBNUExTIG92ZXIgR1JFLjwvcHJlPg0KPHByZSBjbGFzcz0i d29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFk ZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVyIE5l dycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVy dGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3JhcDog YnJlYWstd29yZDsiPiA8L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFyZ2lu LXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7 IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6 ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsg d2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij5UaGUgZG9jdW1l bnQgaXMgd2VsbCB3cml0dGVuLCBlYXN5IHRvIHJlYWQgYW5kIGZvbGxvdy4gU29tZSBtaW5vciBj b21tZW50cyBhcmUgbGlzdGVkIGJlbG93OjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0 eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFkZGluZzogMHB4OyBi b3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFj ZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246 IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsi Pjxicj48L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4 OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFt aWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsg bGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3Bh Y2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij5Db21tZW50czogPC9wcmU+DQo8 cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRv bTogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBmb250LWZhbWlseTogQ291cmllciwg J0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBp bmhlcml0OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsg d29yZC13cmFwOiBicmVhay13b3JkOyI+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48L3ByZT48cHJlIHN0eWxlPSJm b250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+MSkg SW50cm9kdWN0aW9uIHNlY3Rpb24gc3VnZ2VzdHMgeG1wcCBiYXNlZCBhcHByb2FjaCBhcyBhbiBh bHRlcm5hdGl2ZSB0byB0aGUgQkdQIGFzIGEgY29udHJvbCBwbGFuZS4gSXQgaXMgdW5jbGVhciBo b3cgdGhlIGRyYWZ0IHNlY3Rpb25zIDgtMTAgYW5kIHRoZSBzZWN1cml0eSBzZWN0aW9uIDEyIHJl bGF0ZSB0byB0aGUgYWx0ZXJuYXRpdmUgc29sdXRpb24uIE15IHN1Z2dlc3Rpb24gd291bGQgYmUg dG8gcmVtb3ZlIHRoZSByZWZlcmVuY2UgaWYgcG9zc2libGUgY29uc2lkZXJpbmcgdGhlIGRyYWZ0 IGlzIHNwZWNpZmljIHRvIEJHUCBhcyBhIGNvbnRyb2wgcGxhbmUuPC9wcmU+PC9wcmU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxmb250IGNvbG9y PSIjZmYwMDAwIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPkFncmVlZC4mbmJzcDtJ IHdpbGwgcmVtb3ZlIGl0LjwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0 O2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGli cmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Ij4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBz dHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsg Ym9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3Bh Y2U7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWdu OiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 Ij48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyI+PGJyPjwvcHJlPjxwcmUgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgbWFyZ2lu LXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij4yKSBTZWN0aW9uIDUuMS4yLjEgZGVmaW5l cyBBdXRvZGVyaXZhdGlvbiBSVCB3aGljaCBzdWdnZXN0cyB0aGUgdXNlIG9mIDIgYnl0ZSBBUyBu dW1iZXIuIERvIHdlIG5lZWQgdG8gY29uc2lkZXIgNCBieXRlIEFTIG51bWJlciBhcyB3ZWxsPyA8 aW1nIGNsYXNzPSJFbW9qaUluc2VydCIgaWQ9Ik9XQUVtb2ppMjI2MjQ5IiBhbHQ9Ij8/IiBzdHls ZT0idmVydGljYWwtYWxpZ246IGJvdHRvbTsiIHNyYz0iY2lkOmYwOWQxODM1LTNlZWItNDZmZi1i ZGMyLWYzOWUzNzMwZGYxYSI+IDwvcHJlPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8Zm9udCBjb2xvcj0iI2ZmMDAwMCI+Tm8sIEF1dG8t ZGVyaXZhdGlvbiBvZiBSVCB3aWxsIG5vdCBiZSBzdXBwb3J0ZWQgZm9yIDQtYnl0ZSBBUy48L2Zv bnQ+PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAs IDAsIDApOyI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0 d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1j b2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2Vy aWY7Ij4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5OiBD b3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1o ZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHBy ZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij48cHJlIHN0eWxlPSJmb250LXNpemU6IDEz cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGJyPjwvcHJlPjxwcmUg c3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7Ij4zKSBTZWN0aW9uIDY6IE1pbm9yIE5pdC4gQ29uc2lkZXIgcmVwbGFjaW5nICZxdW90O3N0 YXRpY2FsbHkmcXVvdDsgd2l0aCAmcXVvdDtsb2NhbGx5JnF1b3Q7LjwvcHJlPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pjxmb250IGNvbG9yPSIjZmYwMDAwIj5Eb25lLjwvZm9udD48L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBzdHlsZT0iZm9udC1zaXpl OjEycHQ7Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5kLWNvbG9yOiNGRkZGRkY7Zm9udC1mYW1pbHk6 Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiPg0KPHByZSBjbGFzcz0id29yZHdy YXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFkZGluZzog MHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1v bm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwt YWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3JhcDogYnJlYWst d29yZDsiPjxwcmUgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7Ij48YnI+PC9wcmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjQpIFNlY3Rpb24gNy4xOiBUYWxr cyBhYm91dCB1c2luZyBSRCB2YWx1ZSBvZiAwLiBSRCBhcyBhIHR5cGU6dmFsdWUgZmllbGQuIFR5 cGUgMCBSRCByZXF1aXJlcyB0aGUgdXNhZ2Ugb2YgMiBieXRlIEFTIG51bWJlciAocHJpdmF0ZSB2 YWx1ZXMgYXJlIHN0cm9uZ2x5IGRpc2NvdXJhZ2VkKSB3aGljaCBuZWVkcyB0byBiZSAwIGZvciBS RCB2YWx1ZSB0byBiZSAwLiBBUyAwIGFjY29yZGluZyB0byBJQU5BIGlzIHJlc2VydmVkLiBTZWVt cyB0byBiZSBsaWtlIHVzYWdlIG9mIEFTIDAgaXMgcHJvaGliaXRlZC4gV291bGQgYSByZXNlcnZl IFJEIHZhbHVlIGJlIG1vcmUgYXBwcm9wcmlhdGU/IDwvcHJlPjwvcHJlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxmb250IGNv bG9yPSIjZmYwMDAwIj5TaW5jZSB0aGUgcmVjb21tZW5kYXRpb24gaXMgdG8gdXNlIGEgdW5pcXVl IFJEIHZhbHVlIHBlciBSRkM3NDMyLCB0aGUgdGV4dCBjb3JyZXNwb25kaW5nIHRvIFJEIHZhbHVl IG9mIDAgaXMgcmVtb3ZlZC48L2ZvbnQ+PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9y OiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmksQXJp YWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Ij4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVy OiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZv bnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij48cHJl IHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyI+PGJyPjwvcHJlPjxwcmUgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgbWFyZ2luLXRvcDog MHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij41KSBzZWN0aW9uIDguMy4xIGRlc2NyaWJlcyB0aGUg ZHJhZnQgY29uc3RyYWluIHdydCBtcGxzIG92ZXIgZ3JlIHZlcnN1cyB2eGxhbi9udmdyZS4gUGVy aGFwcyBpdCB3b3VsZCBiZSBncmVhdCB0byBoaWdobGlnaHQgdGhlIGNvbnN0cmFpbiB1cGZyb250 IGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbj88L3ByZT48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9 IiNmZjAwMDAiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+T0suIFdlIGhpZ2hsaWdo dGVkIHRoaXMgY29uc3RyYWluIHVwZnJvbnQgaW4gc2VjdGlvbiA4LjwvZm9udD48L2ZvbnQ+PC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDAp OyI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBl ciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjoj RkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Ij4N CjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVy LCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6 IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFw OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1h cmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGJyPjwvcHJlPjxwcmUgc3R5bGU9 ImZvbnQtc2l6ZTogMTNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij42 KSBEbyB5b3UgbmVlZCB0byBhZGQgdGV4dCB0byBkZXNjcmliZSBBUlAvTkQgc3VwcHJlc3Npb24g aW4gcHJlc2VuY2Ugb2YgZGVmYXVsdCByb3V0ZT8gPC9wcmU+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGZvbnQgY29s b3I9IiNmZjAwMDAiPlRoYXQgaXMgY292ZXJlZCBpbiBtb3JlIGRlcHRoIGluIHNvbWUgb3RoZXIg ZHJhZnQuPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxmb250IGNvbG9yPSIjZmYwMDAwIj48YnI+DQo8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+PGZvbnQgY29sb3I9IiNmZjAwMDAiPlJlZ2FyZHMsPC9mb250 PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPjxmb250IGNvbG9yPSIjZmYwMDAwIj5BbGk8L2ZvbnQ+PC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8 ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciIgc3R5 bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZG O2ZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Ij4NCjxwcmUg Y2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291 cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVy aXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7Ij48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGJyPjwvcHJlPjxwcmUgc3R5bGU9ImZvbnQt c2l6ZTogMTNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij5CZXN0IFJl Z2FyZHMsPC9wcmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDBweDsiPktleXVyPC9wcmU+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D42D04451BE68Esajassiciscocom_-- --_004_D42D04451BE68Esajassiciscocom_ Content-Type: image/png; name="=?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?=" Content-Description: =?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?= Content-Disposition: attachment; filename="=?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?="; size=488; creation-date="Wed, 19 Oct 2016 21:12:46 GMT"; modification-date="Wed, 19 Oct 2016 21:12:46 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABMAAAATCAYAAAByUDbMAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAYpJREFUeNpi/P//PwO1ACM2wf9njBWAVD4QBwCxApLUAyDeAMQTGU3O PkDRA3QUIxaD+oFUAREOaQQa2IDTMKBB84FUAgk+WwA0MBFmGBOaixJIDKYEoD6465igBjkge+3C rW94TUCTr4eGMdxl8TCZxMYHDIZR1xk2HPiA1SCQOEgepA4J5CMbFgAPhM1vwfTFW9+xGgYTh6lD 1s8IdKIAkH4PEz1w9jOYVpBiZ1CQZMMw7MHzXwwPnv0Esx2MeRESxmcYWYCUAbJiFAVYAMgCbJbA vPmAWjmACZqS4aHdOOs5wdgEBcWE5a8Y0HIGPAIOwETtjXkYJqIqxAAgeQM1ThTzkQ2biB5mC7a8 xZ7kgeICvMzoYTsRJaMDY3U9chIBpaMHz34xxPsKgwMcFIsLgckB5KL+YllkgyYAg6oQJW9Ck8h+ 5NgFhd3GAx/humAGI2cGIHYEGvYBW0YHGTgf2YX4MjkQF4IMwlkEIeXVfByGwsqzAwTLMywGg7wN cvED9AIR3TCAAAMAqh+p+YMVeBQAAAAASUVORK5CYII= --_004_D42D04451BE68Esajassiciscocom_-- From nobody Wed Oct 19 14:23:22 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8E5129704; Wed, 19 Oct 2016 14:23:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147691219689.5713.10984703287619180065.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2016 14:23:16 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-overlay-05.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 21:23:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : A Network Virtualization Overlay Solution using EVPN Authors : Ali Sajassi John Drake Nabil Bitar R. Shekhar James Uttaro Wim Henderickx Filename : draft-ietf-bess-evpn-overlay-05.txt Pages : 28 Date : 2016-10-19 Abstract: This document describes how Ethernet VPN (EVPN) [RFC7432] can be used as an Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures. In particular, the following encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-overlay-05 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 nobody Wed Oct 19 23:15:40 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2112952E; Wed, 19 Oct 2016 23:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IRl2u6eRY_W; Wed, 19 Oct 2016 23:15:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFC012946B; Wed, 19 Oct 2016 23:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=96746; q=dns/txt; s=iport; t=1476944132; x=1478153732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZZmpwyqVpFoKRS6wG9AfkMcu9u/IsO8bPC+0fom4CvE=; b=Wck9dVeQZDuaH7udw0J4YpQ1fndt4oQ1Zk/FvBxAm9Jf32EqtiD2bcpI xaWY6EnFjE85aBBeVKJxA/fZ3w2DVUxC+Wf9SwEyW8fDgsrAMryQny0sx BouSH6fCn74CHip7+cNxHvvS/gkWJKNFbNrgFm29qfsNGH/lYKHn6KfQ3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQAdYAhY/4UNJK1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMINgEBAQEBHVd9B40tlnyUO4III4IjAYNaAoIAPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRiAQEBBBoBDEUBBQQDEAIBCBEDAQIhAQYHMhQJCAIEAQ0FFAeINw7DX?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARcFixKEH0iFPwWIQItyhVsBhiiDBoZbgW6?= =?us-ascii?q?EaYM3hWuHEoVsg38BHjZUhHRyhhIFgSqBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,517,1473120000"; d="scan'208,217";a="163986279" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2016 06:15:30 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u9K6FTdw013827 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Oct 2016 06:15:29 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Oct 2016 02:15:28 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Thu, 20 Oct 2016 02:15:28 -0400 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "draft-ietf-bess-evpn-etree@ietf.org" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS Thread-Topic: shepherd review of draft-ietf-bess-evpn-etree Thread-Index: AQHSAgSQiVios9dTSUOmTfNWP8T6rqBlA4UAgAGT+oCASmTegA== Date: Thu, 20 Oct 2016 06:15:28 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> In-Reply-To: <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/alternative; boundary="_000_D42D4E861BE849sajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 06:15:38 -0000 --_000_D42D4E861BE849sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks again for your additional comments. Below, please find my comment re= solutions. Let me know please if there are any further comments. Regards, Ali From: Thomas Morin = > Organization: Orange Date: Friday, September 2, 2016 at 8:11 AM To: Cisco Employee >, "draft-ie= tf-bess-evpn-etree@ietf.org" >, Loa Andersson >, "George Swallow -X (swal= low - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" >, Eric Rosen >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Resent-From: > Resent-To: Cisco Employee >, >, >, >, >, > Resent-Date: Friday, September 2, 2016 at 8:11 AM Hi Ali, Thanks for the quick respin, which covers many of the points. (inlined below, skipping the resolved points) 2016-09-02, Ali Sajassi (sajassi): sites albeit for different EVIs. +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+---ES1----+--+ | | | MPLS | | | +--+----ES2-----+CE2| +---+ (Root) | |MAC| | | /IP | | |MAC| | (Leaf) +---+ | |VRF| | | | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+----ES3-----+CE3| | +---+ | +------+ | +---+ | (Leaf) +---+ +---------+ +---------+ Figure 1: Scenario 1 In such scenario, an EVPN PE implementation MAY provide E-TREE service using topology constraint among the PEs belonging to the same "topology constraint" is a bit opaque as a term, perhaps "using tailored BG= P RT import/export policies" would be more descriptive (assuming I understo= od your intent) Done. Changed it to =93topology constraint tailored by BGP Route Target (RT= ) import/export policies" (I still think that "topology" is not a helpful terme to use here.) Removed =93topology=94. It now reads =93using tailored Route Target (RT) im= port/export =85." EVI. The purpose of this topology constraint is to avoid having PEs with only Leaf sites importing and processing BGP MAC routes from each other. To support such topology constrain in EVPN, two BGP Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is associated with the Root sites and the other is associated with the Leaf sites. On a per EVI basis, every PE exports the single RT associated with its type of site(s). Furthermore, a PE with Root site(s) imports both Root and Leaf RTs, whereas a PE with Leaf site(s) only imports the Root RT. The text seems to imply that the above is sufficient to deliver the service= , but I fail to see what would prevent Leaf-to-Leaf traffic between Leaves = bound to the same MAC-VRF (ES2 and ES3 in firgure1). Shouldn't the text me= ntion the use of a split-horizon in Leaf MAC-VRFs ? Agree, nice catch!. I changed the first sentence from: "In such scenario, an EVPN PE implementation MAY provide E-TREE service usi= ng topology constraint among the PEs belonging to the same EVI." TO "In such scenario, topology constraint, provided by BGP Route Target (RT) i= mport/export policies among the PEs belonging to the same EVI, can be used = to restrict the communications among Leaf PEs." The sentence above does not address my question in fact, which was about co= mmunication between Leaf ACs (rather than about communication between Leaf = PEs) Let me restate here, more clearly: I fail to see what would prevent Leaf-t= o-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 and ES3 in fi= rgure1). Shouldn't the text mention the use of a split-horizon in Leaf MAC= -VRFs ? OK. I mentioned the use of split-horizon filtering explicitly for blocking = inter-Leaf communication within the same PE. "In such scenario, using tailored BGP Route Target (RT) import/export polic= ies among the PEs belonging to the same EVI, can be used to restrict the co= mmunications among Leaf PEs. To restrict the communications among leaf site= s connected to the same PE and belonging to the same EVI, split-horizon fi= ltering is used - i.e., the interfaces associated with Leaf sites are place= d in the same split-horizon group. " (assuming the previous point is resolved:) With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ? (it seems to me that the assymet= ric import/export RT would do what is needed to build an E-TREE, we would j= ust have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a gi= ven E-TREE end up on a single PE) That=92s not possible because per definition of an EVI, there is only a sin= gle MAC-VRF per EVI for a PE. Where can I read such a definition ? (the Terminology section in RFC7432 do= es not say that, unless I'm missing something). And that seems a completely arbitrary restriction. (just thinking that a given PE device can be split in two logical devices s= how that it can work) Section 6 of RFC7432 where it gives definitions for different service inter= face types, it specifies the relationship between MAC-VRF and VLAN (bridge = table) and how many MAC-VRF (and bridge tables) can be per EVI. In bridging= world, there can only be a single bridge table per VLAN in a device. Besides, I don=92t understand what good does it do to have two MAC-VRFs on = the same PE (one for Leafs and another for Roots) Well, the "what is good for" is pretty simple: it means you can have, just = by tailoring the import/export policies like in 2.1, something as useful as= the scenario in 2.2. There can only be a single bridge table per VLAN. Now even if you add some = kind of logic to form two logical PEs in single physical PE, you end up rep= licating all the MAC addresses associated with the root sites in two bridge= tables. because Leafs and Roots need to talk to each other and thus we want them to= be in the same MAC-VRF. The fact that Leafs and Roots need to talk to each other does not mean that= they *have* to be in the same MAC-VRF, you can rely on the local MPLS data= plane inside the PE to carry the traffic between Roots and Leaves can be pa= ssed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implem= ent a shortcut not involving MPLS encap/decap). Anything is possible but at what cost. The current proposal is very efficie= nt in terms of forwarding path as well as control plane. However, Leafs should not talk among themselves and thus we can put all the= Leaf ACs in a split-horizon group. Yes, this is the meaning of my initial comment above and it is true indepen= dently of whether or not you consider the possibility of having both a Root= s MAC-VRF and Leaf MAC-VRF on a same PE. Yes, incorporated the split-horizon filtering comment. If this is not possible, I think the text should explain why. I don=92t think we need an explanation because of the above reason but if y= ou think otherwise, then please suggest a text as what do you think I shoul= d add. Two possibilities: - if indeed there is no possibility of having, for a given E-Tree, both a R= oot MAC-VRF and a Leaf MAC-VRF, on a given PE, then the text only misses an= explanation of why it is not possible - else, if the possibility exists, t= hen it means that the asymetric RT procedure currently described in 2.1 are= in fact another way of addressing the scenario supported by 2.2 ("a PE rec= eives traffic from either Root OR Leaf sites (but not both) on a given Atta= chment Circuit (AC) of an EVI.") - so the content of 2.1 and 2.2 would be = two approaches for supporting this scenario and (2.1 --> "Approach A, Root= MAC-VRF + Leaf MAC-VRF, two RTs", and 2.2 -> "Approach B, Root/Leaf MAC-VR= F, single RT" ) As mentioned before, a VLAN can only have a single bridge table. Having two= bridge tables results in duplicating some of the MAC addresses. Furthermor= e, the job of the standard is not to explain what is not =93doing=94 but ra= ther to describe clearly what it is =93doing=94. 2.2 Scenario 2: Leaf OR Root site(s) per AC In this scenario, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either associated with a Root or Leaf (but not both). s/with a Root or Leaf/with Roots or Leaves/ ? Agree =96 Changed it to "Root(s) or Leaf(s)" Re-reading and thinking a bit: "an AC is either a Root AC or a Leaf AC (but= not both)" would be much much clearer ? Done. or "an AC is either associated as a Root or as a Leaf (but not both)" perha= ps. (but my initial suggestion wasn't great) +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2 In this scenario, if there are PEs with only root (or leaf) sites per EVI, then the RT constrain procedures described in section 2.1 can also be used here. However, when a Root site is added to a Leaf PE, then that PE needs to process MAC routes from all other Leaf PEs and add them to its forwarding table. This is the case in 2.1 as well, isn't it ? It can start as 2.1 but as soon as you add Root site to a Leaf PE, then it = becomes different (per last sentence of the above para). I guess we need to first conclude the discussion about the section 2.1, bef= ore the above can be discussed efficiently. Hope it is concluded. For this scenario, if for a given EVI, the majority of PEs will eventually have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead. Why this recommendation ? Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves. So "it is recommended" above, deserves to be explained more, I think. OK, I changed =93majority=94 to =93vast majority=94 :-) My point was not to nit pick on "majority", but was that you should explain= why you recommend that. As the text currently reads, the cost of the recommendation can be identifi= ed: having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not to sa= y explained. Hence: why ? (Why is it a useful tradeoff to have useless routes on some, even if only o= ne, PE ?) Changed the last sentence from: "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead.=94 To "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead at the expense of having unwanted MAC a= ddresses on the Leaf PEs." is on a per MAC address. This scenario is considered in this draft for EVPN service with only known unicast traffic - i.e., there is no BUM traffic. "there is no BUM" is quite a bold claim ! :=3D Maybe the text should say "no BUM traffic is supported (BUM traffic will be= dropped)" ? (possibly "BUM traffic from Leaves will be dropped" would be sufficient ?) Changed it to =93BUM traffic is not supported in this scenario and it is dr= opped=94. adding "by the ingress PE" ? Done. +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Root) | | E | | | MPLS | | | E | | (Leaf/Root)+---+ | | V | | | /IP | | | V | | | | I | | | | | | I | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Leaf) +---+ +---------+ +---------+ Figure 3: Scenario 3 3 Operation for EVPN [RFC7432] defines the notion of ESI MPLS label used for split-horizon filtering of BUM traffic at the egress PE. Such egress filtering capabilities can be leveraged in provision of E-TREE services as seen shortly. In other words, [RFC7432] has inherent capability to support E-TREE services without defining any new BGP routes but by just defining a new BGP Extended Community for leaf indication as shown later in this document. 3.1 Known Unicast Traffic Since in EVPN, MAC learning is performed in control plane via advertisement of BGP routes, the filtering needed by E-TREE service for known unicast traffic can be performed at the ingress PE, thus providing very efficient filtering and avoiding sending known unicast traffic over MPLS/IP core to be filtered at the egress PE as done in traditional E-TREE solutions (e.g., E-TREE for VPLS). To provide such ingress filtering for known unicast traffic, a PE MUST indicate to other PEs what kind of sites (root or leaf) its MAC addresses are associated with by advertising a leaf indication flag (via an Extended Community) along with each of its MAC/IP Advertisement route. The lack of such flag indicates that the MAC address is associated with a root site. This scheme applies to all scenarios described in section 2. Furthermore, for multi-homing scenario of section 2.2, where an AC is either root or leaf (but not both), the PE MAY advertise leaf indication along with the Ethernet A-D per EVI route. This advertisement is used for sanity checking in control-plane to ensure that there is no discrepancy in configuration among different PEs of the same redundancy group. For example, if a leaf site is multi-homed to PE1 an PE2, and PE1 advertises the Ethernet A-D per EVI corresponding to this leaf site with the leaf-indication flag but PE2 does not, then the receiving PE notifies the operator of such discrepancy and ignore the leaf-indication flag on PE1. In other words, in case of discrepancy, the multi-homing for that pair of PEs is assumed to be in default "root" mode for that or . The leaf indication flag on Ethernet A-D per EVI route tells the receiving PEs that all MAC addresses associated with this or are from a leaf site. Therefore, if a PE receives a leaf indication for an AC via the Ethernet A-D per EVI route but doesn't receive a leaf indication in the corresponding MAC route,then it notify the operator and ignore the leaf indication on the Ethernet A-D per EVI route. The procedure above should I think be rephrased to provide unambiguous inte= rpretation in the case where a given MAC is being announced in more than on= e MAC/IP advertisement route, possibly carrying a different leaf indication= (and even possibly from different ESes, or from PEs not advertising Ethern= et A-D route). Are you talking about MAC move where a MAC can move between Root and Leaf s= ites? If so, MAC mobility procedure takes precedence. I have added the foll= owing paragraph toward the end of this section: "In situation where MAC moves are allowed among Leaf and Root sites (e.g., = non-static MAC), PEs can receive multiple MAC/IP advertisements routes for = the same MAC address with different Leaf/Root indications (and possibly dif= ferent ESIs for multi-homing scenarios). In such situations, MAC mobility p= rocedures take precedence to first identify the location of the MAC before = associating that MAC with a Root or a Leaf site." Tagging MAC addresses with a leaf indication enables remote PEs to perform ingress filtering for known unicast traffic - i.e., on the ingress PE, the MAC destination address lookup yields, in addition to the forwarding adjacency, a flag which indicates whether the target MAC is associated with a Leaf site or not. Ditto, more or less: the procedure above should I think be rephrased to pro= vide unambiguous interpretation in the case where a given MAC is being anno= unced in more than one MAC/IP advertisement route, possibly carrying a diff= erent leaf indication. The new paragraph will take care of it. The new paragraph takes care of the MAC mobility case, but there possibly r= emains the case of a MAC being advertised in two distinct MAC/IP advertisem= ent route for a same dual-homed ES, in the case where this ES is flagged as= Leaf or Root consistently from the two dual-homing PEs. In that case, both advertisement carry the same indication (either Root or = Leaf). So, there is no issue !! This is normal EVPN process where a MAC for= an all-active multi-homed ES can get advertised by all the multi-homing PE= s and the receiving PE build multiple adjacencies for that MAC. The ingress PE cross- checks this flag with the status of the originating AC, and if both are Leafs, then the packet is not forwarded. To support the above ingress filtering functionality, a new E-TREE Extended Community with a Leaf indication flag is introduced [section 5.2]. This new Extended Community MUST be advertised with MAC/IP Advertisement route and MAY be advertised with an Ethernet A-D per EVI route as described above. 3.2 BUM Traffic For BUM traffic, it is not possible to perform filtering on the ingress PE, as is the case with known unicast, because of the multi- destination nature of the traffic. Saying "it is not possible" without more explanation is not very useful (th= e reader may think about using RPF-like techniques on the egress PE). It seems to me more reasonable to formulate things in terms of "This specif= ication does not provide support for filtering BUM traffic on the ingress P= E", and avoid a sentence like the one above. OK, Changed the sentence to: "This specification does not provide support for filtering BUM traffic on t= he ingress PE because it is not possible to perform filtering of BUM traffi= c on the ingress PE, as is the case with known unicast described above, due= to the multi-destination nature of BUM traffic." Ok. As such, the solution relies on egress filtering. In order to apply the proper egress filtering, which varies based on whether a packet is sent from a Leaf AC or a root AC, the MPLS-encapsulated frames MUST be tagged with an indication when they originated from a Leaf AC. In other words, leaf indication for BUM traffic is done at the granularity of AC. This can be achieved in EVPN through the use of a MPLS label where it can be used to either identify the Ethernet segment of origin per [RFC7432] (i.e., ESI label) or it can be used to indicate that the packet is originated from a leaf site (Leaf label). BUM traffic sent over a P2MP LSP or ingress replication, may need to carry an upstream assigned or downstream assigned MPLS label (respectively) for the purpose of egress filtering to indicate to the egress PEs whether this packet is originated from a leaf AC. The main difference between downstream and upstream assigned MPLS label is that in case of downstream assigned not all egress PE devices need to receive the label just like ingress replication procedures defined in [RFC7432]. There are four scenarios to consider as follow. In all these scenarios, the imposition PE imposes the right MPLS label associated with the originated Ethernet Segment (ES) depending on whether the Ethernet frame originated from a Root or a Leaf site on that Ethernet Segment (ESI or Leaf label). The mechanism by which the PE identifies whether a given frame originated from a Root or a Leaf site on the segment is based on the Ethernet Tag associated with the frame (e.g., whether the frame received on a leaf or a root AC). First comment: it seems that the formulation should also support the case w= here an AC does not use .1q. Agree. Change the sentence to: "The mechanism by which the PE identifies whether a given frame originated = from a Root or a Leaf site on the segment is based on the AC identifier for= that segment (e.g., Ethernet Tag of the frame for 802.1Q frames). Other me= chanisms for identifying root or leaf (e.g., on a per MAC address basis) is= beyond the scope of this document." Ok. (side comment: doing the identification based on the source MAC address wou= ld seem to allow BUM in the context of 2.3; it is out of the scope of my re= view to extend the scope of these specs, but I'm curious why it is not prop= osed....) If we went for per MAC root/leaf identification, then this would have expan= ded the scope of DF election and egress filtering beyond that of RFC 7432. = Currently, we don=92t have any such requirements from operators and service= providers. Does the above mean that scenario 2.3 excludes BUM because the DF Election = mechanism would not be compatible with the egress filtering mechanism ? Providing the explanation in 2.3 would I think be helpful. Done. 4.2 BUM Traffic For BUM traffic, the PEs must perform egress filtering. When a PE receives a MAC advertisement route (which will be used as a source B- MAC), it updates its Ethernet Segment egress filtering function The "its Ethernet Segment egress filtering function" phrase makes it sounds= like we're talking about a wellknown function defined somewhere. If this is indeed the case, providing a reference would be in order. If not, then explaining what this function is would be required. Changed the sentence to: "When a PE receives a MAC advertisement route (which will be used as a sour= ce B-MAC for BUM traffic), it updates its egress filtering (based on the so= urce B-MAC address), as follows:" (Are you talking about doing something similar to what 3.2 specifies for th= e non-PBB procedures ?) Correct. Similar to 3.2 but based on B-MAC address. Ok. (based on the source B-MAC address), as follows: - If the MAC Advertisement route indicates that the advertised B-MAC is a Leaf, and the local Ethernet Segment is a Leaf as well, then the source B-MAC address is added to the B-MAC filtering list. Changed it to: =93=85 is added to its B-MAC list used for egress filtering." Implicitly we can guess that this "filtering list" is a list of things to i= nclude, rather than a list of things to include, but the text should I thin= k be explicit. Changed it as above. We still don't know if the list is a list of B-MAC to reject or to accept ? (filter out what is specified in the list vs. filter to keep only what is s= pecified in the list) Change the sentence to: "then the source B-MAC address is added to its B-MAC list used for egress f= iltering - i.e., to block traffic from that B-MAC address." 5.2 PMSI Tunnel Attribute [RFC6514] defines PMSI Tunnel attribute which is an optional transitive attribute with the following format: +---------------------------------+ | Flags (1 octet) | +---------------------------------+ | Tunnel Type (1 octets) | +---------------------------------+ | MPLS Label (3 octets) | +---------------------------------+ | Tunnel Identifier (variable) | +---------------------------------+ This draft uses all the fields per existing definition except for the following modifications to the Tunnel Type and Tunnel Identifier: When receiver ingress-replication label is needed, the high-order bit of the tunnel type field (C bit - Composite tunnel bit) is set while the remaining low-order seven bits indicate the tunnel type as before. When this C bit is set, the "tunnel identifier" field would begin with a three-octet label, followed by the actual tunnel identifier for the transmit tunnel. PEs that don't understand the new meaning of the high-order bit would treat the tunnel type as an invalid tunnel type. For the PEs that do understand the new meaning of the high-order, if ingress replication is desired when sending BUM traffic, the PE will use the the label in the Tunnel Identifier field when sending its BUM traffic. Additionally, since RFC7385 has created a registry for PMSI Tunnel attribut= e tunnel types, taking the most significant bit from this field can't be do= ne without a significant change of how this registry is organized (because= now you can't take value in 0x7b-0x7f without colliding into values which = are Experimental or Reserved). Achieving the above requires an update of RFC7385, so I would suggest addin= g an 8.1 section saying this: --- The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" regis= try in the "Border Gateway Protocol (BGP) Parameters" registry needs to be = updated to reflect the use of the most significant bit to advertise the use= of "composite tunnels" (section 5.2). For this purpose, this document updates RFC7385. The registry is to be updated, by removing the entries for 0xFB-0xFE and 0x= 0F, and replacing them by: - 0x7B-0x7E Reserved for Experimental Use [this document] - 0x7F Reserved [this document] - 0x80-0xFF Not Allocatable, corresponds to Composite tunnel types [this do= cument] The allocation policy for values 0x00 to 0x7A is IETF Review [RFC5226]. The range for experimental use is now 0x7B-0x7E, and value in this range ar= e not to be assigned. The status of 0x7F may only be changed through Standards Action [RFC5226]. Done. Thanks for providing the text. It was very helpful. Ok. One thing: in the revised text, line breaks are missing for the bullet list= ("- 0x7B-0x7E Reserved for Experimental Use [this document]- 0x7F Reserved= [this document]- 0x80-0xFF Not Allocatable, corresponds to Composite tunne= l types [this document]"). Done. --_000_D42D4E861BE849sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Thomas,

Thanks again= for your additional comments. Below, please find my comment resolutions. L= et me know please if there are any further comments. 

Regards,
Ali

From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Friday, September 2, 2016 at = 8:11 AM
To: Cisco Employee <sajassi@cisco.com>, "draft-ietf-bess-evpn-etree@ietf.org" <draft-i= etf-bess-evpn-etree@ietf.org>, Loa Andersson <loa@pi.nu>, "Ge= orge Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)&quo= t; <swallow@cisco.com>, Eric= Rosen <erosen@juniper.net>= , BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree
Resent-From: <alias-bounces@ietf.org>
Resent-To: Cisco Employee <sajassi@cisco.com>, <ssalam@cisco.com>, <ju1738@att.com>, <jdrake@juniper.net>, <sboutros@vmware.com>, &l= t;jorge.rabadan@nokia.com>= ;
Resent-Date: Friday, September 2, 2= 016 at 8:11 AM

Hi Ali,

Thanks for the quick respin, which covers many of the points.

(inlined below, skipping the resolved points)

2016-09-02, Ali Sajassi (sajassi):

=
   sites albeit for different EVIs.


            &nb= sp;      +---------+   &nbs= p;        +---------+
            &nb= sp;      |   PE1   | &nbs= p;          |   PE2&= nbsp;  |
    +---+       &= nbsp;  |  +---+  |  +------+  |&nb= sp; +---+  |        &n= bsp;   +---+
    |CE1+---ES1----+--+   |  |&nb= sp; | MPLS |  |  |   +--+----ES2-----+CE2|<= br>     +---+  (Root)  |  |MAC|  |&n= bsp; |  /IP |  |  |MAC|  |   (Leaf) &nbs= p; +---+
            &nb= sp;      |  |VRF|  |  |  =     |  |  |VRF|  |
            &nb= sp;      |  |   |  |  |&n= bsp;     |  |  |   |  | &= nbsp;          +---+             &nb= sp;      |  |   |  |  |&n= bsp;     |  |  |   +--+----= ES3-----+CE3|
            &nb= sp;      |  +---+  |  += ------+  |  +---+  |   (Leaf) &nb= sp; +---+
            &nb= sp;      +---------+   &nbs= p;        +---------+

   Figure 1: Scenario 1

   In such scenario, an EVPN PE implementation MAY provide E-TREE=
   service using topology constraint among the PEs belonging to t= he same

"topology constraint" is a bit opaque as a term, perhaps "us= ing tailored BGP RT import/export policies" would be more descriptive = (assuming I understood your intent)

Done. Changed = it to =93topology constraint tailored by BGP Route Target (RT) import/= export policies"


(I still think that "topology" is not a helpful terme to use here= .)

Removed =93topology=94. It now reads =93= using tailored Route Target (RT) import/export =85."
   EVI. The purpose of this topology constraint is to avoid havin= g PEs
   with only  Leaf sites importing and processing BGP MAC ro= utes from
   each other. To support such topology constrain in EVPN, two BG= P
   Route-Targets (RTs) are used for every EVPN Instance (EVI): on= e RT is
   associated with the Root sites and the other is associated wit= h the
   Leaf sites. On a per EVI basis, every PE exports the single RT=
   associated with its type of site(s). Furthermore, a PE with Ro= ot
   site(s) imports both Root and Leaf RTs, whereas a PE with Leaf=
   site(s) only imports the Root RT.

The text seems to imply that the above is sufficient to deliver the service= , but I fail to see what would prevent Leaf-to-Leaf traffic between Leaves = bound to the same MAC-VRF (ES2 and ES3 in firgure1).  Shouldn't the te= xt mention the use of a split-horizon in Leaf MAC-VRFs ?

Agree, nice catch= !. I changed the first sentence from:
"In suc= h scenario, an EVPN PE implementation MAY provide E-TREE service using topology constr= aint among the PEs belonging to the same EVI."
TO
"In such scenario, topology constraint, provid= ed by BGP Route Target (RT) import/export policies among the PEs belonging = to the same EVI, can be used to restrict the communications among Leaf PEs.= "

The sentence above does not address my qu= estion in fact, which was about communication between Leaf ACs (rather than= about communication between Leaf PEs)
Let me restate here, more clearly:  = I fail to see what would pr= event Leaf-to-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 and ES3 in firgure1).  Shouldn't the t= ext mention the use of a split-horizon in Leaf MAC-VRFs ?

OK. I mentioned the use of split-horizon filte= ring explicitly for blocking inter-Leaf communication within the same PE.

"In such scenario, using tailored BGP Route Ta= rget (RT) import/export policies among the PEs belonging to the same EVI, c= an be used to restrict the communications among Leaf PEs. To restrict the c= ommunications among leaf sites connected to the same PE  and belonging to the same EVI, split-horizon filterin= g is used - i.e., the interfaces associated with Leaf sites are placed in t= he same split-horizon group. "


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ?   (it seems to me that t= he assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a= Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)<= /p>


That=92s not possible because per definition of an = EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the= Terminology section in RFC7432 does not say that, unless I'm missing somet= hing).
And that seems a completely arbitrary res= triction.
(just thinking that a given PE device can= be split in two logical devices show that it can work)

Section 6 of= RFC7432 where it gives definitions for different service interface types, = it specifies the relationship between MAC-VRF and VLAN (bridge table) and h= ow many MAC-VRF (and bridge tables) can be per EVI. In bridging world, there can only be a single bridge table= per VLAN in a device.

Besides, I don=92t understand what good does i= t do to have two MAC-VRFs on the same PE (one for Leafs and another for Roo= ts)

Well, the "what is good for" is= pretty simple: it means you can have, just by tailoring the import/export = policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridg= e table per VLAN. Now even if you add some kind of logic to form two logica= l PEs in single physical PE, you end up replicating all the MAC addresses associated with = the root sites in two bridge tables.


because Leafs and Roots need to talk to each other = and thus we want them to be in the same MAC-VRF.

The fact that Leafs and Roots need= to talk to each other does not mean that they *have* to be in the same MAC= -VRF, you can rely on the local MPLS dataplane inside the PE to carry the traffic between Roots and Leaves can = be passed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly i= mplement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost. The current proposal is ve= ry efficient in terms of forwarding path as well as control plane.
However, Leafs should not talk among themselves and= thus we can put all the Leaf ACs in a split-horizon group.

Yes, this is the meaning of my ini= tial comment above and it is true independently of whether or not you consi= der the possibility of having both a Roots MAC-VRF and Leaf MAC-VRF on a same PE.

Yes, incorporated the split-horizon filtering comment.


If this= is not possible, I think the text should explain why.

I don=92t think we need = an explanation because of the above reason but if you think otherwise, then= please suggest a text as what do you think I should add.


Two possibilities:
- if indeed there is no possibilit= y of having, for a given E-Tree, both a Root MAC-VRF and a Leaf MAC-VRF, on= a given PE, then the text only misses an explanation of why it is not possible - else, if the possibility exists= , then it means that the asymetric RT procedure currently described in 2.1 = are in fact another way of addressing the scenario supported by 2.2 ("= a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI.= ")  - so the content of 2.1 and 2.2 would be two approaches for s= upporting this scenario and (2.1 -->  "Approach A, Root MAC-VR= F + Leaf MAC-VRF, two RTs", and 2.2 -> "Approach B, Root/L= eaf MAC-VRF, single RT" )

As mentioned befo= re, a VLAN can only have a single bridge table. Having two bridge tables re= sults in duplicating some of the MAC addresses. Furthermore, the job of the= standard is not to explain what is not =93doing=94 but rather to describe clearly what it is =93doi= ng=94. 

2.2 Scenario 2: Leaf OR Root site(s) per AC

   In this scenario, a PE receives traffic from either Root OR Le= af
   sites (but not both) on a given Attachment Circuit (AC) of an = EVI. In
   other words, an AC (ES or ES/VLAN) is either associated with a= Root
   or Leaf (but not both).

s/with a Root or Leaf/with Roots or Leaves/ ?

Agree =96=  Changed it to "Root(s) or Leaf(s)"


Re-reading and thinking a bit: &qu= ot;an AC is either a Root AC or a Leaf AC (but not both)" would be muc= h much clearer ?
Done.

or "an AC is either associate= d as a Root or as a Leaf (but not both)" perhaps.
(but my initial suggestion wasn't = great)


            &nb= sp;        +---------+ &nbs= p;          +---------+= ;
            &nb= sp;        |   PE1  = |            | = ;  PE2   |
    +---+       &= nbsp;    |  +---+  |  +------+= ;  |  +---+  |      &n= bsp;     +---+
    |CE1+-----ES1----+--+   |  |&= nbsp; |      |  |  |   +--= +---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MA= C|  |  | MPLS |  |  |MAC|  |   (Leaf)&nb= sp;  +---+
            &nb= sp;        |  |VRF|  |  |=   /IP |  |  |VRF|  |
            &nb= sp;        |  |   | = |  |      |  |  |   |&nb= sp; |            = 3;---+
            &nb= sp;        |  |   | = |  |      |  |  |   += ;--+---ES2/AC2--+CE3|
            &nb= sp;        |  +---+  |=   +------+  |  +---+  |   (Ro= ot)   +---+
            &nb= sp;        +---------+ &nbs= p;          +---------+= ;

   Figure 2: Scenario 2

   In this scenario, if there are PEs with only root (or leaf) si= tes per
   EVI, then the RT constrain procedures described in section 2.1= can
   also be used here. However, when a Root site is added to a Lea= f PE,
   then that PE needs to process MAC routes from all other Leaf P= Es and
   add them to its forwarding table.

This is the case in 2.1 as well, isn't it ?

It can start as 2.1 but as soon as you add Root site to a Leaf= PE, then it becomes different (per last sentence of the above para).


I guess we need to first conclude = the discussion about the section 2.1, before the above can be discussed eff= iciently.
Hope it is concluded.


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Ro= ot
   sites attached, even though they may start as Root-only or Lea= f-only
   PEs, then it is recommended to use a single RT per EVI and avo= id
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves.

So "it is recommended" above, deserves to be explained more, I th= ink.

OK, I changed =93majority=94 to =93vast m= ajority=94 :-)

My point was not to nit pick on &q= uot;majority", but was that you should explain why you recommend that.=
As the text currently reads, the c= ost of the recommendation can be identified: having useless routes on the f= raction of PEs having only Leaves.
But the gain brought by the recomm= endation is not even mentioned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to ha= ve useless routes on some, even if only one, PE ?)

Changed the last sentence from:
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead.=94
To
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead = at the expense of having unwanted MAC addresses on the Leaf PEs."


is on a per MAC address. This scenario is considered in
   this draft for EVPN service with only known unicast traffic - = i.e.,
   there is no BUM traffic.

"there is no BUM" is quite a bold claim ! :=3D

Maybe the text should say "no BUM traffic is supported (BUM traffic wi= ll be dropped)" ?

(possibly "BUM traffic from Leaves will be dropped" would be suff= icient ?)

Changed it to&= nbsp;=93BUM traffic is not supported in this scenario and it is dropped=94.


adding "by the ingress PE&quo= t; ?

Done.


            &nb= sp;        +---------+ &nbs= p;          +---------+= ;
            &nb= sp;        |   PE1  = |            | = ;  PE2   |
    +---+       &= nbsp;    |  +---+  |  +------+= ;  |  +---+  |      &n= bsp;     +---+
    |CE1+-----ES1----+--+   |  |&= nbsp; |      |  |  |   +--= +---ES2/AC1--+CE2|
    +---+    (Root)  |  | E= |  |  | MPLS |  |  | E |  | (Leaf/Root)+---&#= 43;
            &nb= sp;        |  | V |  |  |=   /IP |  |  | V |  |
            &nb= sp;        |  | I |  |  |=       |  |  | I |  |  &nb= sp;         +---+
            &nb= sp;        |  |   | = |  |      |  |  |   += ;--+---ES2/AC2--+CE3|
            &nb= sp;        |  +---+  |=   +------+  |  +---+  |   (Le= af)   +---+
            &nb= sp;        +---------+ &nbs= p;          +---------+= ;

   Figure 3: Scenario 3

3 Operation for EVPN

   [RFC7432] defines the notion of ESI MPLS label used for split-= horizon
   filtering of BUM traffic at the egress PE. Such egress filteri= ng
   capabilities can be leveraged in provision of E-TREE services = as seen
   shortly. In other words, [RFC7432] has inherent capability to = support
   E-TREE services without defining any new BGP routes but by jus= t
   defining a new BGP Extended Community for leaf indication as s= hown
   later in this document.

3.1 Known Unicast Traffic

   Since in EVPN, MAC learning is performed in control plane via<= br>    advertisement of BGP routes, the filtering needed by E-TREE se= rvice
   for known unicast traffic can be performed at the ingress PE, = thus
   providing very efficient filtering and avoiding sending known = unicast
   traffic over MPLS/IP core to be filtered at the egress PE as d= one in
   traditional E-TREE solutions (e.g., E-TREE for VPLS).

   To provide such ingress filtering for known unicast traffic, a= PE
   MUST indicate to other PEs what kind of sites (root or leaf) i= ts MAC
   addresses are associated with by advertising a leaf indication= flag
   (via an Extended Community) along with each of its MAC/IP
   Advertisement route. The lack of such flag indicates that the = MAC
   address is associated with a root site.



  This scheme applies to all
   scenarios described in section 2.

   Furthermore, for multi-homing scenario of section 2.2, where a= n AC is
   either root or leaf (but not both), the PE MAY advertise leaf<= br>    indication along with the Ethernet A-D per EVI route. This
   advertisement is used for sanity checking in control-plane to = ensure
   that there is no discrepancy in configuration among different = PEs of
   the same redundancy group. For example, if a leaf site is mult= i-homed
   to PE1 an PE2, and PE1 advertises the Ethernet A-D per EVI
   corresponding to this leaf site with the leaf-indication flag = but PE2
   does not, then the receiving PE notifies the operator of such<= br>    discrepancy and ignore the leaf-indication flag on PE1. In oth= er
   words, in case of discrepancy, the multi-homing for that pair = of PEs
   is assumed to be in default "root" mode for that <= ;ESI, EVI> or <ESI,
   EVI/VLAN>. The leaf indication flag on Ethernet A-D per EVI= route
   tells the receiving PEs that all MAC addresses associated with= this
   <ESI, EVI> or <ESI, EVI/VLAN> are from a leaf site= . Therefore, if a
   PE receives a leaf indication for an AC via the Ethernet A-D p= er EVI
   route but doesn't receive a leaf indication in the correspondi= ng MAC
   route,then it notify the operator and ignore the leaf indicati= on on
the Ethernet A-D per EVI route.


The pro= cedure above should I think be rephrased to provide unambiguous interpretat= ion in the case where a given MAC is being announced in more than one MAC/IP advertisement route, possibly carrying a different= leaf indication (and even possibly from different ESes, or from PEs not ad= vertising Ethernet A-D route).

Are you talking a= bout MAC move where a MAC can move between Root and Leaf sites? If so, MAC = mobility procedure takes precedence. I have added the following paragr= aph toward the end of this section:
"In situation where MAC moves are allowed amon= g Leaf and Root sites (e.g., non-static MAC), PEs can receive multiple MAC/= IP advertisements routes for the same MAC address with different Leaf/Root = indications (and possibly different ESIs for multi-homing scenarios). In such situations, MAC mobility procedures t= ake precedence to first identify the location of the MAC before associating= that MAC with a Root or a Leaf site."


   Tagging MAC addresses with a leaf indication enables remote PE= s to
   perform ingress filtering for known unicast traffic - i.e., on= the
   ingress PE, the MAC destination address lookup yields, in addi= tion to
   the forwarding adjacency, a flag which indicates whether the t= arget
   MAC is associated with a Leaf site or not.

Ditto, = more or less: the procedure above should I think be rephrased to provide un= ambiguous interpretation in the case where a given MAC is being announced in more than one MAC/IP advertisement route, possib= ly carrying a different leaf indication.

The new paragraph will take care of it.

The new paragraph takes care of th= e MAC mobility case, but there possibly remains the case of a MAC being adv= ertised in two distinct MAC/IP advertisement route for a same dual-homed ES, in the case where this ES is flagged as Le= af or Root consistently from the two dual-homing PEs.

In that case, both advertisement carry the same ind= ication (either Root or Leaf). So, there is no issue !! This is normal EVPN= process where a MAC for an all-active multi-homed ES can get advertised by= all the multi-homing PEs and the receiving PE build multiple adjacencies for that MAC. 

The ingress PE cross-
   checks this flag with the status of the originating AC, and if= both
   are Leafs, then the packet is not forwarded.

   To support the above ingress filtering functionality, a new E-= TREE
   Extended Community with a Leaf indication flag is introduced [= section
   5.2]. This new Extended Community MUST be advertised with MAC/= IP
   Advertisement route and MAY be advertised with an Ethernet A-D= per
   EVI route as described above.

3.2 BUM Traffic

   For BUM traffic, it is not possible to perform filtering on th= e
   ingress PE, as is the case with known unicast, because of the = multi-
   destination nature of the traffic.

Saying = "it is not possible" without more explanation is not very useful = (the reader may think about using RPF-like techniques on the egress PE).
It seem= s to me more reasonable to formulate things in terms of "This specific= ation does not provide support for filtering BUM traffic on the ingress PE", and avoid a sentence like the one above.

OK, Changed the sentence to:
"This specification does not provide support f= or filtering BUM traffic on the ingress PE because it is not possible to pe= rform filtering of BUM traffic on the ingress PE, as is the case with known= unicast described above, due to the multi-destination nature of BUM traffic."

Ok.




As such, the solution relies on
   egress filtering. In order to apply the proper egress filterin= g,
   which varies based on whether a packet is sent from a Leaf AC = or a
   root AC, the MPLS-encapsulated frames MUST be tagged with an    indication when they originated from a Leaf AC. In other words= , leaf
   indication for BUM traffic is done at the granularity of AC. T= his can
   be achieved in EVPN through the use of a MPLS label where it c= an be
   used to either identify the Ethernet segment of origin per [RF= C7432]
   (i.e., ESI label) or it can be used to indicate that the packe= t is
   originated from a leaf site (Leaf label).

   BUM traffic sent over a P2MP LSP or ingress replication, may n= eed to
   carry an upstream assigned or downstream assigned MPLS label    (respectively) for the purpose of egress filtering to indicate= to the
   egress PEs whether this packet is originated from a leaf AC.
   The main difference between downstream and upstream assigned M= PLS
   label is that in case of downstream assigned not all egress PE=
   devices need to receive the label just like ingress replicatio= n
   procedures defined in [RFC7432].

   There are four scenarios to consider as follow. In all these    scenarios, the imposition PE imposes the right MPLS label asso= ciated
   with the originated Ethernet Segment (ES) depending on whether= the
   Ethernet frame originated from a Root or a Leaf site on that E= thernet
   Segment (ESI or Leaf label).

The mechanism by which the PE identifies
   whether a given frame originated from a Root or a Leaf site on= the
   segment is based on the Ethernet Tag associated with the frame= (e.g.,
   whether the frame received on a leaf or a root AC).
First c= omment: it seems that the formulation should also support the case where an= AC does not use .1q.

Agree. Change the sentence to:
"The mechanism by which the PE identifies whet= her a given frame originated from a Root or a Leaf site on the segment is b= ased on the AC identifier for that segment (e.g., Ethernet Tag of the frame= for 802.1Q frames). Other mechanisms for identifying root or leaf (e.g., on a per MAC address basis) is beyond the = scope of this document."


Ok.


(side c= omment: doing the identification based on the source MAC address would seem= to allow BUM in the context of 2.3; it is out of the scope of my review to extend the scope of these specs, but I'm curious= why it is not proposed....)

If we went for per MAC root/leaf identification, th= en this would have expanded the scope of DF election and egress filtering b= eyond that of RFC 7432. Currently, we don=92t have any such requirements fr= om operators and service providers.

Does the above mean that scenario = 2.3 excludes BUM because the DF Election mechanism would not be compatible = with the egress filtering mechanism ?
Providing the explanation in 2.3 w= ould I think be helpful.

Done.


4.2 BUM Traffic

   For BUM traffic, the PEs must perform egress filtering. When a= PE
   receives a MAC advertisement route (which will be used as a so= urce B-
   MAC), it updates its Ethernet Segment egress filtering functio= n

The &qu= ot;its Ethernet Segment egress filtering function" phrase makes it sou= nds like we're talking about a wellknown function defined somewhere.=
If this= is indeed the case, providing a reference would be in order.
If not,= then explaining what this function is would be required.

Changed the sentence to:
"When a PE receives a MAC advertisement route = (which will be used as a source B-MAC for BUM traffic), it updates its egre= ss filtering (based on the source B-MAC address), as follows:"<= /div>

(Are yo= u talking about doing something similar to what 3.2 specifies for the non-P= BB procedures ?)
Correct. Similar to 3.2 but based on B-MAC address.=

Ok.

   (based on the source B-MAC address), as follows:

   - If the MAC Advertisement route indicates that the advertised= B-MAC
   is a Leaf, and the local Ethernet Segment is a Leaf as well, t= hen the
   source B-MAC address is added to the B-MAC filtering list.
Changed it to:
=93=85 is added to its B-MAC list used for egr= ess filtering."

Impli= citly we can guess that this "filtering list" is a list of things= to include, rather than a list of things to include, but the text should I think be explicit.

Changed it as above.

We still don't know if the list is= a list of B-MAC to reject or to accept ?
(filter out what is specified in t= he list vs. filter to keep only what is specified in the list)

Change the sentence to: 
"then the source B-MAC address is added t= o its B-MAC list used for egress filtering - i.e., to block traffic from th= at B-MAC address."



5.2 PMSI Tunnel Attribute

   [RFC6514] defines PMSI Tunnel attribute which is an optional    transitive attribute with the following format:

         +---------------------= ------------+
         |  Flags (1 octet)&nb= sp;            =    |
         +---------------------= ------------+
         |  Tunnel Type (1 oct= ets)         |
         +---------------------= ------------+
         |  MPLS Label (3 octe= ts)          |
         +---------------------= ------------+
         |  Tunnel Identifier = (variable)   |
         +---------------------= ------------+

   This draft uses all the fields per existing definition except = for the
   following modifications to the Tunnel Type and Tunnel Identifi= er:

   When receiver ingress-replication label is needed, the high-or= der bit
   of the tunnel type field (C bit - Composite tunnel bit) is set= while
   the remaining low-order seven bits indicate the tunnel type as=
   before. When this C bit is set, the "tunnel identifier&qu= ot; field would
   begin with a three-octet label, followed by the actual tunnel<= br>    identifier for the transmit tunnel.  PEs that don't under= stand the
   new meaning of the high-order bit would treat the tunnel type = as an
   invalid tunnel type. For the PEs that do understand the new me= aning
   of the high-order, if ingress replication is desired when send= ing BUM
   traffic, the PE will use the the label in the Tunnel Identifie= r field
   when sending its BUM traffic.
Addit= ionally, since RFC7385 has created a registry for PMSI Tunnel attribute tun= nel types, taking the most significant bit from this field can't be done without a significa= nt change of how this registry is organized  (because now you can't ta= ke value in 0x7b-0x7f without colliding into values which are Experimental = or Reserved).

Achie= ving the above requires an update of RFC7385, so I would suggest adding an = 8.1 section saying this:

---
The &= quot;P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" = registry in the "Border Gateway Protocol (BGP) Parameters" regist= ry needs to be updated to reflect the use of the most significant bit to adve= rtise the use of "composite tunnels" (section 5.2).
 = ;
For t= his purpose, this document updates RFC7385.

The r= egistry is to be updated, by removing the entries for 0xFB-0xFE and 0x0F, a= nd replacing them by:
- 0x7= B-0x7E Reserved for Experimental Use [this document]
- 0x7= F  Reserved [this document]
- 0x8= 0-0xFF Not Allocatable, corresponds to Composite tunnel types [this documen= t]

The a= llocation policy for values 0x00 to 0x7A is IETF Review [RFC5226= ].
The r= ange for experimental use is now 0x7B-0x7E, and value in this range are not= to be assigned.
The s= tatus of 0x7F may only be changed through Standards Action [RFC5226= ].

Done. Thanks for providing the text. It was very he= lpful.

Ok.
One thing: in the revised text, li= ne breaks are missing for the bullet list ("- 0x7B-0x7E Reserved for E= xperimental Use [this document]- 0x7F Reserved [this document]- 0x80-0xFF Not Allocatable, corresponds to Composite tunne= l types [this document]").
Done.


 --_000_D42D4E861BE849sajassiciscocom_-- From nobody Fri Oct 21 10:27:30 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B012961B for ; Fri, 21 Oct 2016 10:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kTG5GOkATOC for ; Fri, 21 Oct 2016 10:27:24 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F2812957F for ; Fri, 21 Oct 2016 10:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1131; q=dns/txt; s=iport; t=1477070844; x=1478280444; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=M4vS/k2fxAUfe88aECcX1RpoYOIjtL7ey8IpDP5FsRM=; b=U48bZJDtqFtpk5fSMb9eEOTgC49Z/46tJr5jyNWVKHxOYmj6p4sro0is 9o9sjKei2FTMpIjzfFUL4ykWN8OF3D2wPcvRykv+7CBfpKlxgaD6ZMQ/0 DD9qkOAnku+k5WXuZCWW8m5ILrIgGJciRISGxms/3uJiKO2hU+2ZTcxto 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AQCmTgpY/5FdJa1ZAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM+AQEBAQEdV30HAY0sqzuCBxwLhXoCgWg/FAECAQEBAQEBAWIohGM?= =?us-ascii?q?BAQQBAQE3LAgZAgIBCDYQGwwLJQIEARKIUg7DIAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARwFhjiEVYRoERWFGAWOSItLAYYoiWeBbk6EH4kmhxSFboN/AR42WYR/cgG?= =?us-ascii?q?HRwF/AQEB?= X-IronPort-AV: E=Sophos;i="5.31,377,1473120000"; d="scan'208";a="338521641" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2016 17:27:23 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u9LHRNJV001779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 17:27:23 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 13:27:22 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1210.000; Fri, 21 Oct 2016 13:27:22 -0400 From: "Patrice Brissette (pbrisset)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Slots requests for BESS WG session - IETF 97 - Seoul Thread-Index: AQHSK8BiELDzJhJMyUWMeurfAg2LDQ== Date: Fri, 21 Oct 2016 17:27:22 +0000 Message-ID: References: <5805DD1E.4000400@nokia.com> In-Reply-To: <5805DD1E.4000400@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.181] Content-Type: text/plain; charset="us-ascii" Content-ID: <34010A40018C264EB804105256936FEA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Slots requests for BESS WG session - IETF 97 - Seoul X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 17:27:29 -0000 Martin, Usual Yang update Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com On 2016-10-18, 4:28 AM, "BESS on behalf of Martin Vigoureux" wrote: >All, > >it is time we start building the BESS WG agenda for Seoul. >The IETF agenda is available at: >https://datatracker.ietf.org/meeting/97/agenda.html >Please note that it is still a preliminary agenda. > >The BESS WG session (2h) is currently scheduled on >Monday, 14th of November, Afternoon session I 13:30-15:30 (local time) > >Please send us your request for a presentation slot, indicating >draft name, speaker and desired duration (covering presentation + >discussion) > >Please send the requests no later than the 30th of October. >Thank you > >M&T > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Fri Oct 21 11:39:46 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFDE129872 for ; Fri, 21 Oct 2016 11:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCt7PKz-mCqN for ; Fri, 21 Oct 2016 11:39:39 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33536129859 for ; Fri, 21 Oct 2016 11:39:39 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s8so61151304pfj.2 for ; Fri, 21 Oct 2016 11:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=7g2940aKsVWeXDmWRR7q3pPB1tFj9SM/7q3tASb5eo8=; b=sDekS2bROzqjPIHfYHNjj8fUEtOTOKTpSFETPwdH1aOmyb/G4kknDOxoBrlZlUAafA 6drkB4khd4dXv0lkPwpNH8NxtN1B0ovdqiiZt7wwdlFuRIyFGtZ5i+Sc9gz6mZMg80k7 pnU4Ce/8zjXKwDi50PMHsn9XzKfBOWn5Ov+5IuGKxabctSmD+zY+Y6Zmg+/MKikmBFd8 YNKDq+DeGSRtsTtqwM/01yyzXAvcWAWbNul3UA10hQx1PTGXMFcfBq3lb9+o+avFeAk6 zCXmGwhuT5fHhdmzTU7VL8TT53EG4dLc9ux7jsMKBRjlWmrpoeGVuK2XwEXjCogV+E/v JnBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7g2940aKsVWeXDmWRR7q3pPB1tFj9SM/7q3tASb5eo8=; b=SMedNY6yOTprtzEnodamqjUcDuQX9f8Vp8vBbWtT+jBNfE4AEo3O2dA8/mm44bx4Ij G9u2IgopsUn/qWvz7+Z7pkY8JXleH9DTdFH4ORjXhwVGxWLOj1Qzuwy0a6tAnVL0Arrn OUlCaA9DybusUMgZL05Rxo05UqqdGQdom00zOAakMOswDRyJ137D//x9yXCLu/F5R1j+ Un60Z9OPrbGk66LqlCYnqTxoP9/Ev1IMwvHsHzujzCaFCED2TPBr7w4nlqmBvwxk6ywm wIvQcEIz3et3Ta0aQ4OQVnsLVqvW9XXS7g21XCIjP/KnF0GbblCvJMM2Pha22w6WW1v8 vioQ== X-Gm-Message-State: ABUngvd2FmLglVbIajyam4u90MdKDn++McMCoT+v9i+w6ybLl/zXg04J2zjiUMb0Ue8OPg== X-Received: by 10.99.163.1 with SMTP id s1mr3418164pge.126.1477075178799; Fri, 21 Oct 2016 11:39:38 -0700 (PDT) Received: from ?IPv6:2601:642:4400:5082:991d:886e:c5b3:63b4? ([2601:642:4400:5082:991d:886e:c5b3:63b4]) by smtp.gmail.com with ESMTPSA id 70sm6845588pfc.50.2016.10.21.11.39.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 21 Oct 2016 11:39:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D65B9140-DF66-4C65-9754-ABE2C9CE738C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sami Boutros In-Reply-To: <5805DD1E.4000400@nokia.com> Date: Fri, 21 Oct 2016 11:42:37 -0700 Message-Id: References: <5805DD1E.4000400@nokia.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] Slots requests for BESS WG session - IETF 97 - Seoul X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 18:39:44 -0000 --Apple-Mail=_D65B9140-DF66-4C65-9754-ABE2C9CE738C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, I would like to present 3 old drafts with 5 mins for each draft a total = of 15 mins. draft-boutros-bess-evpn-auto-provisoning = draft-boutros-bess-evpn-vpws-service-edge-gateway = draft-boutros-bess-vxlan-evpn = Thanks, Sami > On Oct 18, 2016, at 1:28 AM, Martin Vigoureux = wrote: >=20 > All, >=20 > it is time we start building the BESS WG agenda for Seoul. > The IETF agenda is available at: > https://datatracker.ietf.org/meeting/97/agenda.html > Please note that it is still a preliminary agenda. >=20 > The BESS WG session (2h) is currently scheduled on > Monday, 14th of November, Afternoon session I 13:30-15:30 (local time) >=20 > Please send us your request for a presentation slot, indicating > draft name, speaker and desired duration (covering presentation + > discussion) >=20 > Please send the requests no later than the 30th of October. > Thank you >=20 > M&T >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --Apple-Mail=_D65B9140-DF66-4C65-9754-ABE2C9CE738C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Martin,

I would like to present 3 old drafts with 5 mins for each = draft a total of 15 mins.

draft-boutros-bess-evpn-auto-provisoning

draft-boutros-bess-evpn-vpws-service-edge-gateway

draft-boutros-bess-vxlan-evpn


Thanks,

Sami

On Oct 18, 2016, at 1:28 AM, Martin Vigoureux = <martin.vigoureux@nokia.com> wrote:

All,

it is time we start = building the BESS WG agenda for Seoul.
The IETF agenda is = available at:
https://datatracker.ietf.org/meeting/97/agenda.html
Please note that it is still a preliminary agenda.

The BESS WG session (2h) is currently = scheduled on
Monday, 14th of November, Afternoon session I = 13:30-15:30 (local time)

Please send us = your request for a presentation slot, indicating
draft = name, speaker and desired duration (covering presentation +
discussion)

Please send the = requests no later than the 30th of October.
Thank you

M&T

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

= --Apple-Mail=_D65B9140-DF66-4C65-9754-ABE2C9CE738C-- From nobody Fri Oct 21 11:43:20 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F8512987D; Fri, 21 Oct 2016 11:43:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147707539673.28129.12078330197429534230.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 11:43:16 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-boutros-bess-vxlan-evpn-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 18:43:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : VXLAN DCI Using EVPN Authors : Sami Boutros Ali Sajassi Samer Salam Dennis Cai Samir Thoria Tapraj Singh John Drake Jeff Tantsura Filename : draft-boutros-bess-vxlan-evpn-02.txt Pages : 15 Date : 2016-10-21 Abstract: This document describes how Ethernet VPN (E-VPN) technology can be used to interconnect VXLAN or NVGRE networks over an MPLS/IP network. This is to provide intra-subnet connectivity at Layer 2 and control- plane separation among the interconnected VXLAN or NVGRE networks. The scope of the learning of host MAC addresses in VXLAN or NVGRE network is limited to data plane learning in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boutros-bess-vxlan-evpn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-boutros-bess-vxlan-evpn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-boutros-bess-vxlan-evpn-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 nobody Fri Oct 21 16:28:54 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26558129996; Fri, 21 Oct 2016 16:21:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208315.28214.11459449190359460796.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:23 -0700 Archived-At: Cc: aretana@cisco.com, bess@ietf.org Subject: [bess] bess - Requested session has been scheduled for IETF 97 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:26 -0000 Dear Martin Vigoureux, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. bess Session 1 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Grand Ballroom 3 size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: BGP Enabled ServiceS Area Name: Routing Area Session Requester: Martin Vigoureux Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: rtgwg spring idr sfc sidr l3sm Second Priority: mpls pim nvo3 bier pals Third Priority: i2rs Special Requests: not on Friday please (will not be in Seoul that day), thank you --------------------------------------------------------- From nobody Fri Oct 21 16:36:33 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377FF1296D8 for ; Fri, 21 Oct 2016 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJdyTNyucqxD for ; Fri, 21 Oct 2016 16:36:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD2512986A for ; Fri, 21 Oct 2016 16:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1027; q=dns/txt; s=iport; t=1477092807; x=1478302407; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1twGD57pMGn7bN4uXN1obIrK7fNiv71v9i9r3/24J+0=; b=kPWxan/DcHV3MBBEhYNJ2L2I3a6lYs33N/UvSCbzEwMnhD5RoUvnEFuD PHhNM9h2mVZlGzjp2FSlm7xVEcDzLdObEhtuyUu6jiOT9eTVQXCjHhQWL pOC9nw0OGTQYNkn31tI0zScDYyeDQ9x6nMjTJeNwJpx1hZ/7rq/iY9t8H Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQAEpQpY/4gNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz4BAQEBAR1XfQeNLas7ggccC4V6AoFqPxQBAgEBAQEBAQFiKIRjAQE?= =?us-ascii?q?EAQEBaxsCAQhGJwslAgQBEohSDsMPAQEBAQEBAQEBAQEBAQEBAQEBARkFixKEe?= =?us-ascii?q?YUtBY5IO4sQAYYoiWeBboRtiSaRAQEeNlmEf3IBh0KBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,527,1473120000"; d="scan'208";a="164712889" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2016 23:33:26 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9LNXQIH029451 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 23:33:26 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 19:33:25 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Fri, 21 Oct 2016 19:33:25 -0400 From: "Ali Sajassi (sajassi)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Slots requests for BESS WG session - IETF 97 - Seoul Thread-Index: AQHSKRmgQZsqmkx4ZUa2JuEKMJhlOKCzYomA Date: Fri, 21 Oct 2016 23:33:25 +0000 Message-ID: References: <5805DD1E.4000400@nokia.com> In-Reply-To: <5805DD1E.4000400@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <673836349958524D9539286FB0CC12F7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Slots requests for BESS WG session - IETF 97 - Seoul X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:36:29 -0000 Hi Martin, I=B9d like to request for two time slots: 1) draft-sajassi-bess-evpn-vpws-fxc, 10 min 2) draft-sajassi-bess-evpn-igmp-mld-proxy, 10 min Regards, Ali On 10/18/16, 1:28 AM, "BESS on behalf of Martin Vigoureux" wrote: >All, > >it is time we start building the BESS WG agenda for Seoul. >The IETF agenda is available at: >https://datatracker.ietf.org/meeting/97/agenda.html >Please note that it is still a preliminary agenda. > >The BESS WG session (2h) is currently scheduled on >Monday, 14th of November, Afternoon session I 13:30-15:30 (local time) > >Please send us your request for a presentation slot, indicating >draft name, speaker and desired duration (covering presentation + >discussion) > >Please send the requests no later than the 30th of October. >Thank you > >M&T > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Fri Oct 28 15:01:19 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A1B129481 for ; Fri, 28 Oct 2016 15:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z24IbjyEobDQ for ; Fri, 28 Oct 2016 15:01:14 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD61129672 for ; Fri, 28 Oct 2016 15:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12986; q=dns/txt; s=iport; t=1477692074; x=1478901674; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7DrfvP3cLY4vU6KwV8aMNGmTds8ghBfjTZ9aJQ2RDqI=; b=ZDhTe4n33XSgzzW6/9bvyegkIrFtOAFx+tZ+B97/tEsmEALVcRclUtJf 8oSmoiLsMz00fnE2jPFdL8WaBhitN9zLsT6xSXl9Zg51e2xK90yyEbK1Q EUFYhFeS4P7V1s80/cVlkLKDnDpMLA1iS2y6ATCDvq+DZ2Ei7bj5AXs4z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQBSyhNY/5ldJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM3AQEBAQEfWH0HjS+mKIUWggcdAQqFewIagWs/FAECAQEBAQEBAWI?= =?us-ascii?q?dC4RjAQEEAQEBIEsbAgEIJBsDAgICJQsUBwEGAwIEE4hUDrFqjGgBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEXBYY9gX0IglCHSyyCLwWIRYt1hV4BhiyJepAEkQ8BHjZ?= =?us-ascii?q?fhQpyhmqBCQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,560,1473120000"; d="scan'208,217";a="340135546" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 22:01:13 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u9SM1DOl009429 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Oct 2016 22:01:13 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Oct 2016 17:01:12 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 28 Oct 2016 17:01:12 -0500 From: "Alvaro Retana (aretana)" To: "bess@ietf.org" Thread-Topic: Internal WG Review: L2VPN Service Model (l2sm) Thread-Index: AQHSIuE2EmSyX/cerkmJhunT5KEgJKC+mJgA Date: Fri, 28 Oct 2016 22:01:12 +0000 Message-ID: <47F0070B-D231-4F7D-9115-B1EB96175531@cisco.com> References: <147609537861.31412.12808919218828694338.idtracker@ietfa.amsl.com> In-Reply-To: <147609537861.31412.12808919218828694338.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_47F0070BD2314F7D9115B1EB96175531ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [bess] FW: Internal WG Review: L2VPN Service Model (l2sm) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 22:01:16 -0000 --_000_47F0070BD2314F7D9115B1EB96175531ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCklmIHlvdSBoYXZlbuKAmXQgZG9uZSBzbywgaXQgd291bGQgYmUgYSBnb29kIGlkZWEg Zm9yIHRoZSBwYXJ0aWNpcGFudHMgaW4gdGhpcyBXRyB0byByZXZpZXcgdGhpcyBjaGFydGVyLg0K DQpUaGFua3MhDQoNCkFsdmFyby4NCg0KT24gMTAvMTAvMTYsIDY6MjkgQU0sICJpZXNnIG9uIGJl aGFsZiBvZiBJRVRGIFNlY3JldGFyaWF0IiA8aWVzZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpp ZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBpZXRmLXNlY3JldGFyaWF0LXJlcGx5 QGlldGYub3JnPG1haWx0bzppZXRmLXNlY3JldGFyaWF0LXJlcGx5QGlldGYub3JnPj4gd3JvdGU6 DQoNCg0KQSBuZXcgSUVURiBXRyBpcyBiZWluZyBjb25zaWRlcmVkIGluIHRoZSBJRVRGLiBUaGUg ZHJhZnQgY2hhcnRlciBmb3IgdGhpcw0KV0cgaXMgcHJvdmlkZWQgYmVsb3cgZm9yIHlvdXIgcmV2 aWV3IGFuZCBjb21tZW50Lg0KDQpSZXZpZXcgdGltZSBpcyBvbmUgd2Vlay4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KTDJWUE4gU2VydmljZSBNb2RlbCAobDJzbSkNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpDdXJyZW50IHN0YXR1czogUHJvcG9zZWQgV0cNCg0KQ2hhaXJzOg0KICBUQkQNCg0KQXNzaWdu ZWQgQXJlYSBEaXJlY3RvcjoNCiAgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb208bWFp bHRvOmJjbGFpc2VAY2lzY28uY29tPj4NCg0KT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVh IERpcmVjdG9yczoNCiAgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJj bGFpc2VAY2lzY28uY29tPj4NCiAgSm9lbCBKYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPG1haWx0 bzpqb2VsamFAYm9ndXMuY29tPj4NCk1haWxpbmcgbGlzdDoNCiAgQWRkcmVzczogbDJzbUBpZXRm Lm9yZzxtYWlsdG86bDJzbUBpZXRmLm9yZz4NCiAgVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wyc20NCiAgQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9sMnNtLw0KDQpDaGFydGVyOiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtbDJzbS8NCg0K --_000_47F0070BD2314F7D9115B1EB96175531ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9y OndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5J ZiB5b3UgaGF2ZW7igJl0IGRvbmUgc28sIGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIGZvciB0aGUg cGFydGljaXBhbnRzIGluIHRoaXMgV0cgdG8gcmV2aWV3IHRoaXMgY2hhcnRlci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWx2YXJv LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6 My43NXB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6YmxhY2siPk9uIDEwLzEwLzE2LCA2OjI5IEFNLCAmcXVvdDtpZXNnIG9uIGJl aGFsZiBvZiBJRVRGIFNlY3JldGFyaWF0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZy1i b3VuY2VzQGlldGYub3JnIj5pZXNnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0K PGEgaHJlZj0ibWFpbHRvOmlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmciPmlldGYtc2Vj cmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+QSBu ZXcgSUVURiBXRyBpcyBiZWluZyBjb25zaWRlcmVkIGluIHRoZSBJRVRGLiBUaGUgZHJhZnQgY2hh cnRlciBmb3IgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5XRyBpcyBwcm92aWRlZCBiZWxvdyBmb3IgeW91ciByZXZp ZXcgYW5kIGNvbW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5SZXZpZXcgdGltZSBpcyBv bmUgd2Vlay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5MMlZQTiBTZXJ2aWNlIE1vZGVsIChsMnNtKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5DdXJyZW50IHN0YXR1czogUHJvcG9zZWQgV0c8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPkNoYWlyczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7VEJEPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5Bc3NpZ25lZCBBcmVhIERpcmVjdG9yOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDtCZW5vaXQgQ2xhaXNlICZsdDs8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNj by5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2si Pk9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBEaXJlY3RvcnM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwO0Jlbm9pdCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNv bSI+YmNsYWlzZUBjaXNjby5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtKb2VsIEph ZWdnbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2VsamFAYm9ndXMuY29tIj5qb2VsamFAYm9ndXMu Y29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+TWFpbGluZyBsaXN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtB ZGRyZXNzOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86bDJzbUBpZXRmLm9yZyI+bDJzbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7VG8gc3Vic2NyaWJlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2wyc20iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJzbTwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7QXJjaGl2ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL2Jyb3dzZS9sMnNtLyI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L2Jyb3dzZS9sMnNtLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkNoYXJ0ZXI6PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1sMnNtLyI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLWwyc20vPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_47F0070BD2314F7D9115B1EB96175531ciscocom_-- From nobody Sun Oct 30 09:19:22 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF0F12946F for ; Sun, 30 Oct 2016 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ejADdcm_-rI for ; Sun, 30 Oct 2016 09:19:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5111293DC for ; Sun, 30 Oct 2016 09:19:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9UGJD10004803 for ; Sun, 30 Oct 2016 16:19:13 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9UGJBDk004771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 30 Oct 2016 16:19:12 GMT From: "Adrian Farrel" To: References: <147784375838.20673.15513470878299688311.idtracker@ietfa.amsl.com> In-Reply-To: <147784375838.20673.15513470878299688311.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2016 16:19:08 -0000 Message-ID: <000901d232c9$5841d390$08c57ab0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKVZufArLcLzqLuyg8zmKTt0aD7MJ86wzjQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22670.001 X-TM-AS-Result: No--12.167-10.0-31-10 X-imss-scan-details: No--12.167-10.0-31-10 X-TMASE-MatchedRID: kNb5oX97tjirmmW6xY+ZmAbts0Qkqy42AHN/Ezu9EnHadW4iYSMjUae7 nmhJA6kzvQYIBOd3rqrwx43j/HRRryWvhQBtQUwTU+OjsPhIWDiz4D778GcgEQuKAULAAChW5Hv ZOgCRb7CQm6BojE/Wzy5ShDQVR9yTj56IjTnLR+lCvapcIkxJXx83WxJo1IH1+Cckfm+bb6DJTt eBOzpbgtDbef4/mkgx8eW7KU5mDVqE05Xibv2u9GJn9JR2v1jq1pnvzMqQcsYwplGJ7NxS087in RkoFrPqgEBR2HjnXiv27vlZQBKDdDcpdZ3fQiLdgxsfzkNRlfL9b0xgYrma7dRnEQCUU+jzjocz muoPCq0jihi5qEP2DUUdQqS0WDNz1KvL85+Y3GlnbV8CAZRXxFNSWKI/iwnB Archived-At: Subject: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 16:19:21 -0000 Hi Bess WG, We made some updates to this document to tidy it and to get the = terminology in line with RFC 7665. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 30 October 2016 16:09 > To: Eric Rosen; Adrian Farrel; John Drake; Jim Uttaro; Luay Jalil > Subject: New Version Notification for = draft-mackie-bess-nsh-bgp-control-plane- > 01.txt >=20 >=20 > A new version of I-D, draft-mackie-bess-nsh-bgp-control-plane-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-mackie-bess-nsh-bgp-control-plane > Revision: 01 > Title: BGP Control Plane for NSH SFC > Document date: 2016-10-30 > Group: Individual Submission > Pages: 37 > URL: = https://www.ietf.org/internet-drafts/draft-mackie-bess-nsh-bgp- > control-plane-01.txt > Status: = https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control- > plane/ > Htmlized: = https://tools.ietf.org/html/draft-mackie-bess-nsh-bgp-control- > plane-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mackie-bess-nsh-bgp-control- > plane-01 >=20 > Abstract: > This document describes the use of BGP as a control plane for > networks that support Service Function Chaining (SFC). The = document > introduces a new BGP address family called the SFC AFI/SAFI with = two > route types. One route type is originated by a node to advertise > that it hosts a particular instance of a specified service = function. > This route type also provides "instructions" on how to send a = packet > to the hosting node in a way that indicates that the service = function > has to be applied to the packet. The other route type is used by a > Controller to advertise the paths of "chains" of service functions, > and to give a unique designator to each such path so that they can = be > used in conjunction with the Network Service Header. >=20 > This document adopts the SFC architecture described in RFC 7665. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Sun Oct 30 09:59:40 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6567B1293F3 for ; Sun, 30 Oct 2016 09:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SckhP5XN4MEG for ; Sun, 30 Oct 2016 09:59:38 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8FF124281 for ; Sun, 30 Oct 2016 09:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 241B0240654; Sun, 30 Oct 2016 09:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1477846778; bh=WvDZy3JomBh+r6HXJmW0fLXLbI2LCC75Jh51ctTvd8M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lhCUsaocaWzKfoVMNTQ7oMV72e7RmJuHzTTBDYdizWiXiqqPwGoP8QCEm4pcrxvhu 9Emh+FKhGE5UN3vvRJEaYQxxalmyXbMVEu0zdFtk2TDfORgj0XJqdJ2RkW5QKCEdLs DUKZJu3GrhfzvF029F2V97ZsnUa4aMfD3sMEDOUs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9D751240614; Sun, 30 Oct 2016 09:59:37 -0700 (PDT) To: adrian@olddog.co.uk, bess@ietf.org References: <147784375838.20673.15513470878299688311.idtracker@ietfa.amsl.com> <000901d232c9$5841d390$08c57ab0$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Sun, 30 Oct 2016 13:00:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <000901d232c9$5841d390$08c57ab0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 16:59:39 -0000 Thank you authors. Reading through this, I have a few questions. 1) I like the idea of being able to support multiple SFC overlays. I can see circumstances when this would be valuable. However, I can not see how it works. (I presume I am missing something obvious.) If the SPI are unique, then sure, it works, but they are not really separate overlays. They are merely administrative slices of the same overlay. The text in section 5 bullet 1 starts with observing that the path state is RT specific. That part is fine. It then asserts that the SFF that receives a packet can somehow tell which RT the packet goes with. How? Since the unerlay is not partitioned into RTs (only the overlay) the transport mechanism does not indicate that. And the data packet does not carry an RT. 2) The Path hop information (for a specific SPI, SI) allows for carrying multiple SFTs. It allows for multiple SFIs, which is important and useful. The multiple SFTs seems to be intended to allow for the case where SFT A or B can be done at hops 9 or 8. Which would be nice to allow. But since the second SFF (at hop 8) will not know whether the first SFF (at hop 9) chose A or B, I do not see how it can correctly choose the opposite. Are there additional assumptions made to enable this? The text in the example of section 8.4 seems to imply a different sort of use case for this multiple SFT at a hop situation. But I can not see how that will be implemented interoperably. Having control know magically that the SFF can correctly select an SFT based on unspecified information seems problematic. 3) I am a bit confused by section 6.1 on looping, jumping, and branching. Looping (more accurately spiraling) should not require any special handling. Simply put the same SFI information at two different SIs in the same SPI, and spiraling occurs. No special handling needed. Jumping seems to be a special case of reclassificaiton. So I would prefer to see it simply handled by the same mechanism (why have two mechanisms that can do the same job.) Branching seems not to handle the most common case where we need to branch. That is the situation where packets in a given SFP, as a result of processing by an SF, will usually continue down the SFP, but under some circumstances (and there are a range of them) will need to take a different path. The Assumption in the SFC work is that the SF indicates the need for reclassificiation by adjusting the flags in the NSH header, and that a classifier co-resident with the SFF then performs reclassification. The mechanism you describe in section 6.1 does not seem to support that. 3') Also, that is why we do not usually describe the classifier as a service function. Classifiers (including in path reclassifiers) are permitted to overwrite the SFP ID. Service functions are not permitted to do that. 4) I notice that the examples still show the SI being adjusted by more than 1. The NSH draft has been clarified, at the request of the AD and WG, to make it clear that the SI is decremented by 1 at each hop. (If that were not the case, we would need additional information in the control as to how much to decrement the SI. Which would be a complication with no value.) Yours, Joel On 10/30/16 12:19 PM, Adrian Farrel wrote: > Hi Bess WG, > > We made some updates to this document to tidy it and to get the terminology in line with RFC 7665. > > Adrian From nobody Mon Oct 31 02:09:39 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF7D129563; Mon, 31 Oct 2016 02:09:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147790496816.32516.13893566095015887903.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 02:09:28 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-service-chaining-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 09:09:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Service Chaining using Virtual Networks with BGP VPNs Authors : Rex Fernando Stuart Mackie Dhananjaya Rao Bruno Rijsman Maria Napierala Filename : draft-ietf-bess-service-chaining-01.txt Pages : 41 Date : 2016-10-31 Abstract: This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-service-chaining-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-service-chaining-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 nobody Mon Oct 31 10:34:11 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E13F0129965; Mon, 31 Oct 2016 10:34:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147793524491.32466.10790268781657268010.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 10:34:04 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-l2vpn-yang-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 17:34:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : YANG Data Model for MPLS-based L2VPN Authors : Himanshu Shah Patrice Brissette Ing-When Chen Iftekar Hussain Bin Wen Filename : draft-ietf-bess-l2vpn-yang-01.txt Pages : 53 Date : 2016-10-31 Abstract: This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2vpn-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2vpn-yang-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 nobody Mon Oct 31 13:07:19 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDCD129AE0; Mon, 31 Oct 2016 13:07:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147794443811.23205.1818388434325303954.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 13:07:18 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-l2vpn-yang-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 20:07:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : YANG Data Model for MPLS-based L2VPN Authors : Himanshu Shah Patrice Brissette Ing-When Chen Iftekar Hussain Bin Wen Filename : draft-ietf-bess-l2vpn-yang-02.txt Pages : 53 Date : 2016-10-31 Abstract: This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2vpn-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2vpn-yang-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 nobody Mon Oct 31 16:44:37 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEBB129BE4; Mon, 31 Oct 2016 16:44:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795746877.23158.10719693280211525406.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 16:44:28 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-service-chaining-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 23:44:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Service Chaining using Virtual Networks with BGP VPNs Authors : Rex Fernando Stuart Mackie Dhananjaya Rao Bruno Rijsman Maria Napierala Thomas Morin Filename : draft-ietf-bess-service-chaining-02.txt Pages : 41 Date : 2016-10-31 Abstract: This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-service-chaining-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-service-chaining-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/